페이스 북과 같이 복잡한 벽에 DB를 설계하는 방법

Question

페이스 북과 같은 소셜 네트워크 웹 사이트를 만들고 있습니다. 내 "벽"의 경우 상태, 메시지, 사용자가 페이지를 좋아하거나 싫어하는 등 여러 가지 종류의 정보를 가지고 있습니다 ...

DB를 디자인하는 방법을 알고 싶습니다. 벽 관련 테이블)을 벽에있는 항목을 가져올 때 속도면에서 가능한 한 효율적으로 설정해야합니다.

미리 감사드립니다.

편집 :

1. 모든 가능성을 처리 할 수있는 충분한 열이있는 큰 테이블이 (user_a, user_a, 메시지, 페이지, is_like, is_dislike, ...) : 나는이 개 아이디어를 가지고있다. 빠르지 만 많은 'NULL'값을 가지며 DB에서 많은 공간을 차지합니다.
2. 벽 항목의 각 종류에 대한 테이블 (id, user_a, user_b)과 테이블이 세 개인 'wall_item' 메시지, 좋아요, 상태, ...). 정규화되지만 모든 정보를 얻는 데 필요한 왼쪽 결합의 수 때문에 시간이 많이 걸립니다.

Answer 1

콘텐츠 테이블과 좋아요/싫어요 테이블 중 두 개의 테이블이 있다고 제안합니다. null 값을 많이 가지는 것은 문제가되지 않습니다. nulls는 공간을 차지하지 않습니다. 좋아하는 일/싫어하는 일은 따로 보관하는 것이 필요할 것입니다. 일이 많이 일어나고 만족하지 않기 때문입니다.

시스템을 확장 가능하게하려면 JOIN-s를 피하십시오. 많은 JOIN-s가있는 하나의 거대한 대규모 쿼리보다 2-3 개의 쿼리를 연속으로 실행하는 것이 좋습니다. 또한 READ 작업이 많고 WRITE 횟수가 많지 않은 경우 WRITE 중에 추가 작업을 수행하는 것이 좋습니다.

예를 들어 벽 (사용자 ID 및 게시물 ID 포함)에 대한 별도의 테이블을 가질 수 있습니다. 누군가 새로운 게시물을 만들면 각 친구의 게시물 ID가 WALL 테이블에 기록됩니다. 따라서 벽을 표시하는 것은 WALL 테이블에서 게시물 ID를 읽고 표시하는 동안 모든 사용자의 게시물에서 콘텐츠를 검색하는 것이 아니라 콘텐츠를 가져 오는 것입니다.

그리고 새로운 사람들이 친구가되면 가장 최근 게시물의 ID를 서로에게 복사합니다. 프로젝트와 함께 행운을 빌어 요!

Answer 2

나는 성능을 높이기 위해 NOSQL이 사용된다고 생각한다. 모든 대형 테이블 db 액세스는 조인 된 테이블은 물론, 이런 종류의 응용 프로그램에서는 느려집니다.