메신저 데이터베이스(1부): 기본 프레임워크 설계

메신저 데이터베이스를 처음부터 설계하는 예를 사용하여 비즈니스 요구 사항을 특정 데이터 구조로 변환하는 방법.

• 1부: 베이스 프레임 설계
• 2부: "이익을 위한" 구분

우리의 기반은 그렇게 크지도 분산되지도 않을 것입니다. VKontakte처럼 또는 Badoo, 그러나 "그래서"였지만 좋았습니다. 기능적이고 빠르며 하나의 서버에 적합 PostgreSQL - 예를 들어 측면 어딘가에 별도의 서비스 인스턴스를 배포할 수 있습니다.

따라서 샤딩, 복제 및 지리적 분산 시스템 문제는 다루지 않고 데이터베이스 내부의 회로 솔루션에 중점을 둘 것입니다.

1단계: 일부 비즈니스 세부사항

우리는 메시지를 추상적으로 디자인하지 않고 환경에 통합할 것입니다. 기업 소셜 네트워크. 즉, 우리 직원들은 단지 "서신을 주고받는" 것이 아니라 특정 비즈니스 문제를 해결하는 맥락에서 서로 소통합니다.

그리고 비즈니스의 임무는 무엇입니까?.. 개발 부서장인 Vasily의 예를 살펴보겠습니다.

• "Nikolai, 이 작업을 위해서는 오늘 패치가 필요합니다!"
  이는 서신이 일부 상황에서 수행될 수 있음을 의미합니다. 문서.
• “콜야, 오늘 저녁에 도타에 갈 거야?”
  즉, 한 쌍의 대화 상대라도 동시에 의사소통이 가능합니다. 다양한 주제에.
• “피터, 니콜라이, 첨부 파일에서 새 서버 가격표를 찾아보세요.”
  따라서 하나의 메시지에는 여러 수신자. 이 경우 메시지에는 다음이 포함될 수 있습니다. 첨부 파일.
• “세면아, 너도 좀 봐봐.”
  그리고 기존 서신을 작성할 기회가 있어야 합니다. 새 회원을 초대하다.

지금은 "명백한" 요구 사항 목록을 살펴보겠습니다.

문제의 적용 세부 사항과 그에 따른 제한 사항을 이해하지 못한 채 디자인 유효한 이를 해결하기 위한 데이터베이스 스키마는 거의 불가능합니다.

2단계: 최소 논리 회로

지금까지는 모든 것이 전통적인 비즈니스 도구인 이메일 서신과 매우 유사하게 작동합니다. 예, "알고리즘적으로" 많은 비즈니스 문제는 서로 유사하므로 문제를 해결하기 위한 도구도 구조적으로 유사합니다.

이미 얻은 엔터티 관계의 논리 다이어그램을 수정해 보겠습니다. 모델을 더 쉽게 이해할 수 있도록 가장 원시적인 표시 옵션을 사용하겠습니다. ER 모델 UML 또는 IDEF 표기법의 복잡함 없이:

이 예에서 파일의 사람, 문서 및 바이너리 "본문"은 서비스 없이 독립적으로 존재하는 "외부" 엔터티입니다. 따라서 우리는 미래에 이를 UUID의 "어딘가" 링크로 인식할 것입니다.

그리다 가능한 한 간단한 다이어그램 - 당신이 보여줄 사람들의 대부분은 UML/IDEF 읽기 전문가가 아닙니다. 하지만 꼭 그려보세요.

3단계: 테이블 구조 스케치

테이블 및 필드 이름 정보필드와 테이블의 "러시아어" 이름은 다르게 취급될 수 있지만 이는 취향의 문제입니다. 왜냐하면 여기 텐서에서 외국 개발자는 없으며 PostgreSQL에서는 상형 문자로도 이름을 지정할 수 있습니다. 따옴표로 둘러싸여 있습니다, 그런 다음 불일치가 없도록 객체의 이름을 명확하고 명확하게 지정하는 것을 선호합니다.
많은 사람들이 동시에 우리에게 메시지를 쓰기 때문에 그들 중 일부는 이런 일을 할 수도 있습니다. 오프라인, 가장 간단한 옵션은 UUID를 식별자로 사용 외부 엔터티뿐만 아니라 서비스 내부의 모든 개체에도 적용됩니다. 또한 클라이언트 측에서도 생성될 수 있습니다. 이는 데이터베이스를 일시적으로 사용할 수 없고 충돌 가능성이 매우 낮을 때 메시지 전송을 지원하는 데 도움이 됩니다.

데이터베이스의 초안 테이블 구조는 다음과 같습니다.
테이블 : RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

테이블: KO

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

형식을 설명할 때 가장 간단한 방법은 연결 그래프를 "풀기" 시작하는 것입니다. 참조되지 않은 테이블에서 누구에게도 자신을.

4단계: 명확하지 않은 요구사항 파악

그게 다입니다. 우리는 당신이 완벽하게 글을 쓸 수 있는 데이터베이스를 설계했습니다. 어떻게 든 읽을 수 있습니다.

우리 서비스 사용자의 입장에서 생각해 봅시다. 우리는 이 서비스로 무엇을 하고 싶습니까?

• 최근 게시물
  그것 시간순으로 정렬 다양한 기준에 따른 "나의" 메시지 등록. 내가 수신자 중 한 명인 곳, 내가 저자인 곳, 그들이 나에게 편지를 썼지만 내가 대답하지 않은 곳, 그들이 나에게 대답하지 않은 곳, ...
• 서신 참가자
  이 길고 긴 대화에 누가 참여하고 있는 걸까요?

우리의 구조를 통해 이 두 가지 문제를 "일반적으로" 해결할 수 있지만 신속하게 해결할 수는 없습니다. 문제는 첫 번째 작업 내에서 정렬하는 것입니다. 인덱스를 생성할 수 없습니다, 각 참가자에게 적합하며 (모든 기록을 추출해야 함) 필요한 두 번째 문제를 해결하려면 모든 메시지 추출 이 주제에 대해.

의도하지 않은 사용자 작업으로 인해 굵게 표시될 수 있음 생산성을 넘어서다.

5단계: 스마트 비정규화

두 가지 문제 모두 추가 테이블을 통해 해결될 것입니다. 데이터의 일부가 중복됨, 우리 작업에 적합한 색인을 형성하는 데 필요합니다.


테이블 : RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

테이블: KO

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

여기서는 보조 테이블을 생성할 때 사용되는 두 가지 일반적인 접근 방식을 적용했습니다.

• 레코드 곱하기
  하나의 초기 메시지 레코드를 사용하여 다양한 소유자(발신자와 수신자 모두)에 대해 다양한 유형의 레지스터에 여러 후속 레코드를 생성합니다. 그러나 이제 각 레지스터는 인덱스에 속하게 됩니다. 결국 일반적인 경우에는 첫 번째 페이지만 보려고 합니다.
• 고유한 기록
  특정 주제에 대한 메시지를 보낼 때마다 해당 항목이 이미 존재하는지 확인하는 것으로 충분합니다. 그렇지 않은 경우 "사전"에 추가하십시오.

이 기사의 다음 부분에서 우리는 파티셔닝 구현 우리 데이터베이스의 구조에.

출처 : habr.com