Messenger ma'lumotlar bazasi (1-qism): asosiy ramkani loyihalash

Noldan messenjer ma'lumotlar bazasini loyihalash misolidan foydalanib, qanday qilib biznes talablarini ma'lum ma'lumotlar tuzilmalariga tarjima qilishingiz mumkin.

• 1-qism: asosiy ramkani loyihalash
• 2-qism: "foyda uchun" bo'limi

Bizning bazamiz unchalik katta va taqsimlanmagan bo'ladi, VKontakte kabi yoki Badoo, lekin "shunday bo'ldi", lekin u yaxshi edi - funktsional, tez va bitta serverga mos keladi PostgreSQL - bu xizmatning alohida nusxasini, masalan, yon tomonda joylashtirishingiz mumkin.

Shuning uchun biz sharding, replikatsiya va geo-tarqatilgan tizimlar masalalariga to'xtalmaymiz, balki ma'lumotlar bazasi ichidagi sxema echimlariga e'tibor qaratamiz.

1-qadam: Ba'zi biznes xususiyatlari

Biz o'z xabarlarimizni mavhum tarzda yaratmaymiz, balki uni atrof-muhitga integratsiya qilamiz korporativ ijtimoiy tarmoq. Ya’ni, xalqimiz “shunchaki yozishma” bilan cheklanib qolmaydi, balki bir-biri bilan muayyan biznes muammolarini hal qilish doirasida muloqot qiladi.

Korxonaning vazifalari nimalardan iborat?.. Rivojlanish bo'limi boshlig'i Vasiliy misolini ko'rib chiqaylik.

• "Nikolay, bu vazifa uchun bizga bugun yamoq kerak!"
  Bu shuni anglatadiki, yozishmalar ba'zilar kontekstida o'tkazilishi mumkin hujjat.
• "Kolya, bugun kechqurun Dotaga borasizmi?"
  Ya'ni, hatto bir juft suhbatdosh ham bir vaqtning o'zida muloqot qilishi mumkin turli mavzularda.
• "Piter, Nikolay, yangi server uchun narxlar ro'yxatini ilovaga qarang."
  Shunday qilib, bitta xabar bo'lishi mumkin bir nechta oluvchilar. Bunday holda, xabar o'z ichiga olishi mumkin Biriktirilgan fayllar.
• - Semyon, siz ham bir ko'ring.
  Va mavjud yozishmalarga kirish imkoniyati bo'lishi kerak yangi a'zoni taklif qiling.

Keling, hozircha ushbu "aniq" ehtiyojlar ro'yxatiga to'xtalib o'tamiz.

Muammoning qo'llaniladigan xususiyatlarini va unga berilgan cheklovlarni tushunmasdan, dizayn samarali uni hal qilish uchun ma'lumotlar bazasi sxemasi deyarli mumkin emas.

2-qadam: Minimal mantiqiy sxema

Hozircha hamma narsa elektron pochta yozishmalariga juda o'xshaydi - an'anaviy biznes vositasi. Ha, "algoritmik" ko'plab biznes muammolari bir-biriga o'xshash, shuning uchun ularni hal qilish vositalari tizimli ravishda o'xshash bo'ladi.

Keling, mavjud munosabatlarning allaqachon olingan mantiqiy diagrammasini tuzatamiz. Bizning modelimizni tushunishni osonlashtirish uchun biz eng oddiy displey variantidan foydalanamiz ER modellari UML yoki IDEF belgilarining asoratlarisiz:

Bizning misolimizda, faylning shaxsi, hujjati va ikkilik "tanasi" bizning xizmatimizsiz mustaqil ravishda mavjud bo'lgan "tashqi" ob'ektlardir. Shuning uchun, biz ularni kelajakda UUID tomonidan "qaerdadir" havolalar sifatida qabul qilamiz.

Chizish diagrammalar iloji boricha sodda - Siz ularga ko'rsatadigan odamlarning aksariyati UML/IDEF o'qish bo'yicha mutaxassislar emas. Lekin chizishga ishonch hosil qiling.

3-qadam: Jadval strukturasini chizish

Jadval va maydon nomlari haqidaMaydonlar va jadvallarning "ruscha" nomlariga boshqacha munosabatda bo'lish mumkin, ammo bu ta'mga bog'liq. Chunki bu erda Tensorda chet el ishlab chiquvchilari yo'q va PostgreSQL bizga hatto ierogliflarda ham nom berishga imkon beradi, agar ular bo'lsa. qo'shtirnoq ichiga olingan, keyin biz hech qanday nomuvofiqliklar bo'lmasligi uchun ob'ektlarni aniq va aniq nomlashni afzal ko'ramiz.
Ko'p odamlar bir vaqtning o'zida bizga xabar yozishganligi sababli, ularning ba'zilari buni qilishlari mumkin oflayn, keyin eng oddiy variant identifikator sifatida UUIDlardan foydalaning nafaqat tashqi ob'ektlar uchun, balki bizning xizmatimiz ichidagi barcha ob'ektlar uchun ham. Bundan tashqari, ular hatto mijoz tomonida ham yaratilishi mumkin - bu ma'lumotlar bazasi vaqtincha ishlamay qolganda va to'qnashuv ehtimoli juda past bo'lganda xabarlarni yuborishni qo'llab-quvvatlashga yordam beradi.

Bizning ma'lumotlar bazasidagi qoralama jadval tuzilishi quyidagicha ko'rinadi:
Jadvallar: 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
);

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

Formatni tavsiflashda eng oddiy narsa ulanish grafigini "echish" ni boshlashdir havola qilinmagan jadvallardan o'zlarini hech kimga.

4-qadam: Aniq bo'lmagan ehtiyojlarni aniqlang

Hammasi shu, biz siz mukammal yozishingiz mumkin bo'lgan ma'lumotlar bazasini yaratdik qandaydir tarzda o'qing.

Keling, o'zimizni xizmatimiz foydalanuvchisi o'rniga qo'yaylik - biz u bilan nima qilmoqchimiz?

• Oxirgi xabarlar
  bu xronologik tartiblangan turli mezonlarga asoslangan "mening" xabarlar reestri. Qaerda men qabul qiluvchilardan biriman, qayerda men muallifman, qayerda ular menga yozishgan va men javob bermaganman, qaerda menga javob berishmagan, ...
• Muloqot ishtirokchilari
  Bu uzoq va uzoq suhbatda kim ishtirok etadi?

Bizning strukturamiz bu ikkala muammoni ham "umuman" hal qilishga imkon beradi, lekin tez emas. Muammo shundaki, birinchi vazifa doirasida tartiblash uchun indeks yaratish mumkin emas, har bir ishtirokchi uchun mos (va siz barcha yozuvlarni olishingiz kerak bo'ladi) va ikkinchisini hal qilish uchun sizga kerak barcha xabarlarni chiqarib oling ushbu mavzu bo'yicha.

Ko'zda tutilmagan foydalanuvchi vazifalari qalin bo'lishi mumkin mahsuldorlikka o'zaro bog'liqlik.

5-qadam: Aqlli denormalizatsiya

Bizning ikkala muammomiz ham qo'shimcha jadvallar yordamida hal qilinadi ma'lumotlar qismini takrorlash, ular bo'yicha bizning vazifalarimizga mos indekslarni shakllantirish kerak.


Jadvallar: RU

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

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

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

Bu erda biz yordamchi jadvallarni yaratishda qo'llaniladigan ikkita odatiy yondashuvni qo'lladik:

• Yozuvlarni ko'paytirish
  Bitta dastlabki xabar yozuvidan foydalanib, biz turli egalar uchun - jo'natuvchi uchun ham, qabul qiluvchi uchun ham har xil turdagi registrlarda bir nechta kuzatuv yozuvlarini yaratamiz. Ammo registrlarning har biri endi indeksga to'g'ri keladi - axir, odatda, biz faqat birinchi sahifani ko'rishni xohlaymiz.
• Noyob yozuvlar
  Har safar ma'lum bir mavzu doirasida xabar yuborganingizda, bunday yozuv allaqachon mavjudligini tekshirish kifoya. Agar yo'q bo'lsa, uni "lug'atimizga" qo'shing.

Maqolaning keyingi qismida biz bu haqda gaplashamiz qismlarga ajratishni amalga oshirish bizning ma'lumotlar bazamiz tuzilishiga.

Manba: www.habr.com