SQL 소셜 네트워크, 메시지를 보관할 올바른 방법?

Question

저는 소셜 네트워크를 구축 중이며 지금은 문제에 직면했습니다.

그래서, 어느 쪽이 (메시지를 유지하기 위해) 빠른 :

새로운 사용자 당 하나의 데이터베이스, 를하고 (메시지) 새 테이블을 만들려면? 이처럼

:

CREATE DATABASE 'user_messages'; 

CREATE TABLE 'user_id' (

    id int(32) NOT NULL PRIMARY KEY, 
    new ENUM ('Y', 'N') NOT NULL DEFAULT 'Y', 
    time timestamp NOT NULL, 
    from_id int(32) 
); 

OR,

이 (복제) 하나 개의 테이블에있는 모든 메시지를 유지하려면 ??? (INDEXes 사용) 10 억 개의 행이 있으면 어떻게됩니까? 이처럼 :

INSERT INTO 'user_messages' (id, new, time, from_id) VALUES ('id_value', 'Y', now(), 'friend_id'); 

Answer 1

는이 동적으로 생성 된 SQL 모든 시간을 사용하지 않고 쿼리 악몽이 될 것이다 사용자 당 하나 개의 테이블 만들기.

더 나은 옵션은 하나의 단일 테이블을 만들고이 테이블에있는 모든 사용자의 모든 메시지를 사용자 테이블에 외래 키와 함께 저장하는 것입니다. 외래 키는 인덱싱되므로 대규모 성능 문제가 없어야합니다. 수십억 개의 행 (또는 메시지)이 필요하다면 데이터베이스 아키텍처는 그에 따라 데이터 양을 처리해야하지만 데이터베이스 디자인을 변경해서는 안됩니다.

Answer 2

그래서, 하나는 빠른 인 (메시지를 유지) :

을 그것은 가능성이 없다 어느 쪽도 빠르고, 내가 SQL 서버가가 상한있어보다 훨씬 작은 테이블에 대한 상한을 가지고 생각하지만, 행. 그리고 다른 데이터베이스에 걸친 트랜잭션으로 인해 미끄러운 성능 저하가 발생하는지는 알 수 없습니다.

올바른 데이터베이스 디자인은 단일 테이블을 지정합니다.

(INDEX 사용) 10 억 개의 행이 있다면 어떻게 될까요? 이렇게 :

글쎄, 어쩌면 당신은 그 문제를 해결하기 전에 10 억 행에 도달해야합니다. 그러나 일반적으로 성능을 위해 여러 가지 이유로 데이터를 분할 할 수 있습니다 (Google SQL Server 테이블 분할).