Messenger маалымат базасы (1-бөлүк): базалык негизди долбоорлоо

Мессенджер базасын нөлдөн баштап долбоорлоонун мисалын колдонуп, бизнес талаптарын конкреттүү маалымат структураларына кантип которо аласыз.

• 1-бөлүк: базалык кадрды долбоорлоо
• 2-бөлүк: "пайда үчүн" бөлүм

Биздин база анчалык чоң эмес жана бөлүштүрүлбөйт, VKontakte сыяктуу же Айканыш, жана "ошондой эле", бирок ал жакшы болду - функционалдык, тез жана бир серверге туура келет PostgreSQL - мисалы, сиз кызматтын өзүнчө нускасын капталда жайгаштыра аласыз.

Ошондуктан, биз sharding, репликация жана гео-бөлүштүрүлгөн системалар маселелерине токтолбойбуз, бирок маалымат базасынын ичиндеги схемалардын чечимдерине көңүл бурабыз.

1-кадам: Кээ бир бизнес өзгөчөлүктөрү

Биз билдирүүлөрүбүздү абстракттуу түрдө түзбөйбүз, бирок аны чөйрөгө интеграциялайбыз корпоративдик социалдык тармак. Башкача айтканда, биздин адамдар «жөн эле кат алышуу» эмес, айрым бизнес көйгөйлөрүн чечүүнүн алкагында бири-бири менен байланышып турушат.

Ал эми ишкананын милдеттери кандай?.. Өнүктүрүү бөлүмүнүн башчысы Василийдин мисалына кайрылалы.

• "Николай, бул иш үчүн бизге бүгүн жамаачы керек!"
  Бул кат алышуу айрымдардын контекстинде жүргүзүлүшү мүмкүн дегенди билдирет документ.
• "Коля, сен бүгүн кечинде Дотага барасыңбы?"
  Башкача айтканда, бир эле учурда бир түгөй баарлаша алат ар кандай темалар боюнча.
• "Петр, Николай, жаңы сервердин прейскуранты үчүн тиркемеден кара."
  Ошентип, бир билдирүү болушу мүмкүн бир нече алуучулар. Бул учурда, билдирүү камтышы мүмкүн Тиркелген файлдар.
• -Семён, сен да карачы.
  Ал эми болгон корреспонденцияга кирүү мүмкүнчүлүгү болушу керек жаңы мүчө чакыруу.

Келгиле, азыр "ачык" муктаждыктардын бул тизмесине токтололу.

Проблеманын колдонулуучу өзгөчөлүктөрүн жана ага берилген чектөөлөрдү түшүнбөстөн, долбоорлоо натыйжалуу аны чечүү үчүн маалымат базасы схемасы дээрлик мүмкүн эмес.

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

Таблицалар: EN

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-кадам: Smart Denormalization

Биздин эки маселебиз дагы кошумча таблицалар аркылуу чечилет маалыматтардын бир бөлүгүн кайталоо, алар боюнча биздин милдеттерибизге ылайыктуу индекстерди түзүү зарыл.


Таблицалар: RU

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

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

Таблицалар: EN

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

Бул жерде биз көмөкчү таблицаларды түзүүдө колдонулган эки типтүү ыкманы колдондук:

• Жазууларды көбөйтүү
  Бир баштапкы билдирүү жазуусун колдонуу менен, биз ар кандай ээлер үчүн - жөнөтүүчү үчүн да, алуучу үчүн да реестрлердин ар кандай түрлөрүндө бир нече кийинки жазууларды түзөбүз. Бирок регистрлердин ар бири азыр индекске туура келет - бардык учурда, адатта, биз биринчи бетти гана көргүбүз келет.
• Уникалдуу рекорддор
  Белгилүү бир теманын ичинде билдирүү жөнөткөн сайын, мындай жазуу бар же жок экенин текшерүү жетиштүү. Болбосо, аны биздин “сөздүгүбүзгө” кошуңуз.

Макаланын кийинки бөлүгүндө биз сөз болот бөлүүнү ишке ашыруу биздин маалымат базасынын структурасына.

Source: www.habr.com