База на податоци за Messenger (дел 1): дизајнирање на основната рамка

Како можете да ги преведете деловните барања во специфични структури на податоци користејќи го примерот за дизајнирање на база на податоци за гласник од нула.

• Дел 1: дизајнирање на основната рамка
• Дел 2: дел „за профит“

Нашата база нема да биде толку голема и дистрибуирана, како VKontakte или Badoo, но „така што беше“, но беше добро - функционално, брзо и се вклопуваат на еден сервер PostgreSQL - за да можете да распоредите посебна инстанца на услугата некаде на страна, на пример.

Затоа, ние нема да ги допираме прашањата за раздвојување, репликација и гео-дистрибуирани системи, туку ќе се фокусираме на решенија за кола во базата на податоци.

Чекор 1: Некои деловни специфики

Ние нема да ги дизајнираме нашите пораки апстрактно, туку ќе ги интегрираме во околината корпоративна социјална мрежа. Односно, нашите луѓе не „само кореспондираат“, туку меѓусебно комуницираат во контекст на решавање на одредени деловни проблеми.

А кои се задачите на еден бизнис?.. Да го погледнеме примерот на Василиј, шеф на одделот за развој.

• „Николај, за оваа задача ни треба лепенка денес!
  Ова значи дека кореспонденцијата може да се води во контекст на некои документ.
• „Колја, ќе одиш на Дота оваа вечер?
  Односно, дури и еден пар соговорници можат да комуницираат истовремено на различни теми.
• „Петар, Николај, побарај го ценовникот за новиот сервер во прилогот“.
  Значи, една порака може да има неколку примачи. Во овој случај, пораката може да содржи Прикачени датотеки.
• „Семјон, погледни и ти“.
  И треба да има можност да се влезе во постоечка кореспонденција покани нов член.

Ајде да се задржиме на оваа листа на „очигледни“ потреби засега.

Без разбирање на применетите специфики на проблемот и ограничувањата што му се дадени, дизајн ефективни база на податоци шема да се реши тоа е речиси невозможно.

Чекор 2: Минимално логичко коло

Досега, сè функционира многу слично на кореспонденцијата преку е-пошта - традиционална деловна алатка. Да, „алгоритамски“ многу деловни проблеми се слични едни на други, затоа алатките за нивно решавање ќе бидат структурно слични.

Да го поправиме веќе добиениот логички дијаграм на односите на ентитетите. За да го направиме нашиот модел полесно разбирлив, ќе ја користиме најпримитивната опција за прикажување ЕР модели без компликации на 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
);

Табели: МК

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("Тема", "Персона")
);

Табели: МК

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)
);

Овде применивме два типични пристапи што се користат при креирање на помошни табели:

• Множење записи
  Користејќи еден почетен запис за пораки, создаваме неколку последователни записи во различни типови на регистри за различни сопственици - и за испраќачот и за примачот. Но, секој од регистрите сега паѓа на индексот - на крајот на краиштата, во типичен случај, ќе сакаме да ја видиме само првата страница.
• Уникатни рекорди
  Секој пат кога ќе испратите порака во рамките на одредена тема, доволно е да проверите дали таков запис веќе постои. Ако не, додадете го во нашиот „речник“.

Во следниот дел од статијата ќе зборуваме за имплементација на партиционирање во структурата на нашата база на податоци.

Извор: www.habr.com