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

우리는 서신을 저장하기 위해 PostgreSQL 데이터베이스의 구조를 성공적으로 설계했으며 XNUMX년이 지났고 사용자가 적극적으로 이를 채우고 있으며 이제 수백만 개의 기록, 그리고... 뭔가 속도가 느려지기 시작했습니다.

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

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

여기가 구출하러 오는 곳이야 단면화.

우리는 샤딩(sharding), 즉 서로 다른 데이터베이스나 서버 간에 데이터를 배포하는 것에 대해 이야기하고 있지 않다는 점에 주목하겠습니다. 데이터를 분할하기 때문에 여러 서버에서는 시간이 지남에 따라 인덱스가 "부풀어오르는" 문제를 제거할 수 없습니다. 매일 새 서버를 가동할 여유가 있다면 문제는 더 이상 특정 데이터베이스 영역에 있지 않을 것임이 분명합니다.

우리는 "하드웨어에서" 파티셔닝을 구현하기 위한 특정 스크립트가 아니라 접근 방식 자체(무엇을 어떻게 "슬라이스로 잘라야"하는지, 그리고 그러한 욕구가 무엇으로 이어지는지)를 고려할 것입니다.

개념

목표를 다시 한 번 정의해 보겠습니다. 오늘, 내일, 그리고 XNUMX년 후에도 읽기/쓰기 작업 중에 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
);

꽤 많은 돈을 절약하세요

음, not을 사용하면 어떨까요? 클래식 단면 옵션 필드 값의 분포(트리거 및 상속 또는 PARTITION BY를 통해)와 애플리케이션 수준의 "수동"을 기반으로 분할 키 값이 이미 테이블 자체 이름에 저장되어 있음을 알 수 있습니다.

그러니 당신이 그렇다면 저장되는 데이터의 양이 너무 걱정되시나요?, 그런 다음 이러한 "추가" 필드를 제거하고 특정 테이블을 처리할 수 있습니다. 사실, 이 경우 여러 섹션의 모든 선택 사항은 애플리케이션 측으로 전송되어야 합니다.

출처 : habr.com