메신저 데이터베이스(2부): "이익을 위한" 파티셔닝

우리는 서신을 저장하기 위한 PostgreSQL 데이터베이스의 구조를 성공적으로 설계했습니다. 1년이 지났고 사용자들이 적극적으로 이를 채우고 있으며 이미 수백만 개의 레코드, 그리고... 무언가가 느려지기 시작했습니다.

• 1부: 기본 프레임 설계
• 2부: "라이브" 섹션화

그건 사실입니다 테이블 크기가 커짐에 따라 인덱스의 "깊이"도 커집니다. — 대수적으로라도요. 그러나 시간이 지나면서 서버는 동일한 읽기/쓰기 작업을 수행해야 합니다. 몇 배 더 많은 데이터 페이지를 처리합니다처음보다.

여기가 구출의 현장입니다 섹션화.

우리가 이야기하는 것은 샤딩, 즉 서로 다른 데이터베이스나 서버 간에 데이터를 분산하는 것에 대한 것이 아니라는 점에 유의하세요. 왜냐하면 우리가 데이터를 다음과 같이 나누어도 여러 서버를 사용해도 시간이 지남에 따라 인덱스가 "부풀어 오르는" 문제는 해결할 수 없습니다. 매일 새로운 서버를 가동할 여력이 있다면 문제가 더 이상 특정 데이터베이스에 국한되지 않을 것이라는 점은 분명합니다.

우리는 "하드웨어"에서 섹션화를 구현하기 위한 구체적인 스크립트를 고려하지 않고, 접근 방식 자체, 즉 무엇을 어떻게 "조각으로 잘라야" 하는지, 그리고 그러한 요구가 무엇으로 이어지는지에 대해서만 고려할 것입니다.

개념

다시 한번 목표를 정의해 보겠습니다. 오늘, 내일 그리고 1년 후에도 PostgreSQL에서 읽기/쓰기 작업을 위해 읽는 데이터 양이 거의 동일하게 유지되도록 하는 것입니다.

어떤 것에 대해서든 연대순으로 누적된 데이터 (메시지, 문서, 로그, 아카이브 등) 파티션 키로 자연스럽게 선택되는 것은 다음과 같습니다. 행사 날짜/시간. 우리의 경우 그러한 이벤트는 메시지가 전송된 순간.

사용자는 거의 항상 "최신"으로만 작업하세요 이런 데이터 - 그들은 최신 메시지를 읽고, 최신 로그를 분석합니다... 아니요, 물론, 그들은 시간을 거슬러 스크롤할 수도 있지만, 그럴 일은 거의 없습니다.

이러한 제약조건에서 메시지에 대한 최적의 솔루션은 다음과 같다는 것이 분명해집니다. "매일" 섹션 — 결국, 우리 사용자는 항상 "오늘"이나 "어제" 받은 내용을 읽을 것입니다.

우리가 하루 중 실질적으로 한 섹션만 쓰고 읽는다면 이것도 우리에게 도움이 됩니다. 메모리와 디스크의 더 효율적인 사용 — 테이블 전체에 있는 "크고 굵은" 인덱스와 달리 모든 섹션 인덱스는 RAM에 쉽게 들어갑니다.

단계별

전반적으로 위에서 언급한 내용은 모두 큰 이익처럼 들립니다. 그리고 그것은 달성 가능하지만 우리는 그것을 위해 열심히 노력해야 합니다. 엔터티 중 하나를 분할하기로 결정하면 관련된 엔터티를 "볼" 필요성이 발생합니다..

메시지, 그 속성 및 투영

날짜별로 메시지를 잘라내기로 결정했기 때문에 해당 메시지에 종속된 엔터티 속성(첨부 파일, 수신자 목록)도 분할하는 것이 합리적입니다. 메시지 날짜로도.

일반적인 업무 중 하나가 메시지 등록부(읽지 않음, 수신, 모두)를 보는 것이므로, 이를 메시지 날짜별로 섹션으로 나누어 "작성"하는 것도 논리적입니다.

모든 테이블(수신자, 파일, 레지스트리)에 파티션 키(메시지 날짜)를 추가합니다. 메시지 자체에 추가할 필요는 없지만 기존 DateTime을 사용하면 됩니다.

스레드

주제가 여러 메시지에 대한 하나이기 때문에 더 이상 동일한 모델에서 "잘라내기"가 불가능합니다. 우리는 다른 것에 의지해야 합니다. 우리의 경우에는 완벽합니다 서신의 첫 번째 메시지 날짜 — 즉, 주제 자체가 생성되는 순간입니다.

모든 테이블에 파티션 키(주제 날짜)를 추가합니다: 주제, 참여자.

하지만 이제 우리는 동시에 두 가지 문제에 직면하게 되었습니다.

• 해당 주제에 대한 메시지를 검색하려면 어느 섹션을 선택해야 합니까?
• 어느 섹션에서 메시지 주제를 찾아야 합니까?

물론, 모든 섹션을 계속 검색할 수도 있지만, 그렇게 하면 매우 안타까운 일이고 우리가 얻은 모든 상금이 무효화됩니다. 따라서 정확히 어디를 살펴봐야 할지 알기 위해 섹션에 대한 논리적 링크/포인터를 만들어 보겠습니다.

• 우리는 그것을 메시지에 추가할 것입니다 주제 날짜 필드
• 주제에 추가해 보자 메시지 날짜 집합 이러한 대응(별도의 표 또는 날짜 배열일 수 있음)

각 개별 서신의 메시지 날짜 목록에는 거의 수정 사항이 없으므로(결국 거의 모든 메시지가 1~2일 이내에 도착함) 이 옵션에 중점을 두겠습니다.

결과적으로, 우리 데이터베이스의 구조는 파티셔닝을 고려하여 다음과 같은 형태를 갖추게 되었습니다.

테이블: RU, 테이블/필드 이름에 키릴 문자가 싫다면 찾아보지 않는 것이 좋습니다.

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

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

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

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

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

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

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

한 푼이라도 아끼다

그럼, 우리가 사용하지 않으면 어떻게 될까요? 섹션화의 클래식 버전 필드 값의 분포(트리거 및 상속 또는 PARTITION BY를 통해)와 애플리케이션 수준에서 "수동으로" 파티션 키 값이 이미 테이블 자체의 이름에 저장되어 있음을 확인할 수 있습니다.

그러니 만약 당신이 그렇다면 저장된 데이터의 양에 대해 매우 우려하고 있습니다그러면 이러한 "추가" 필드를 제거하고 특정 테이블에 액세스할 수 있습니다. 그렇습니다. 이 경우에는 여러 섹션의 모든 선택 사항을 애플리케이션 쪽으로 옮겨야 합니다.

출처 : habr.com