채팅 시스템에 대한 Db 디자인에 대해 논의하는 게시물이 많이 있다는 것을 알고 있지만 해당 디자인의 확장성에 대해 설명하지 않았으므로 여기에서 제 질문입니다.
2 명 이상의 사용자 간의 실시간 채팅 Db를 설계하고 싶습니다. 먼저 2 명의 사용자를 대상으로하겠습니다.
1 번 테이블:
이름 : 사용자
필드 : ID, 이름
표 2
이름 : 대화방
필드 : id, user1, user2
표 3 :
이름 : 메시지
필드 : Chat_room_id, user_id, message
이제 페이스 북을 고려하면 매달 약 20 억 명의 활성 사용자가 있으며 그중 10 억 명은 채팅에 빠져 각 사용자가 100 개의 메시지를 보냅니다.
테이블에 1,000 억 개의 항목이 생성됩니다. Message 이므로 질문은
"Mysql 또는 Postgres가이 많은 항목을 처리하고 특정 대화방 메시지를 실시간으로 표시 할 수 있습니까?" 그렇지 않다면 그것을 따르는 최선의 방법은 RDBMS가 설치된 서버에 따라 다르지만 여전히 최적의 아키텍처를 알고 싶어한다는 것을 알고 있습니다.
추신 : 비동기 동작을 위해 Django를 백엔드로 사용하고 AngularJ를 사용하고 있습니다.
한 테이블의 1000 억 행은 온라인에서 작동하지 않습니다. 가능한 모든 파티셔닝 방법을 적용하여 크기를 줄일뿐만 아니라 활성 / 수동 데이터 전략을 분리합니다. 그럼에도 불구하고 모든 고등학생들에게 답은 :
Postgres는 실제로 빅 데이터 자체로 작업하는 데 효과적입니다.
아직 :
Postgres는 열악한 디자인에 맞서기위한 충분한 전략이 없습니다.
예를보십시오. chat_room 테이블 은 두 명의 사용자를 별도의 열에 나열합니다. 무엇을 위해? users.id를 참조하는 메시지에 user_id가 있습니다. 그리고 그 안에 chat_room.id가 있으므로 해당 chat_room에 있던 사용자 데이터가 있습니다. 이제 시간이 지남에 따라 또는 전혀 chat_room에 참여한 사용자를 사전 집계하려는 아이디어라면 하나의 배열 열로 만드십시오 (chat_room.id int, users_id bigint[]). 활성 / 수동 데이터는 활성과 다른 관계에서 보관 된 채팅방을 사용하여 구현할 수 있습니다. 해당 채팅방에 참여한 사람에 대한 Btw 집계는 이러한 보관에 대해 수행 할 수 있습니다.
위는 행동 지침이 아니라 표현 일뿐입니다. 데이터베이스 스키마에 대한 모범 사례는 없습니다. 먼저 채팅이 무엇을 할 것인지 명확한 계획을 세우고, 모든 것이 작동 할 때까지 db 스키마를 만들고, 시도하고, 개선하고, 시도하고, 개선하고, 시도하고, 개선합니다. 천억 개의 행에서 작동하는 방법에 대해 우려되는 경우-채우고 확인하십시오.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다