ProHoster > Блог > басқарма > Messenger деректер қоры (1-бөлім): базалық фреймворкті жобалау

Messenger деректер қоры (1-бөлім): базалық фреймворкті жобалау

Хабарлама дерекқорын нөлден бастап жобалау мысалын пайдаланып, бизнес талаптарын нақты деректер құрылымдарына қалай аударуға болады.

Messenger деректер қоры (1-бөлім): базалық фреймворкті жобалау
Біздің база соншалықты үлкен және таратылмайды, ВКонтакте сияқты немесе Badoo, бірақ «сондай болды», бірақ ол жақсы болды - функционалды, жылдам және бір серверге сәйкес келеді PostgreSQL - мысалы, бір жерде қызметтің бөлек данасын орналастыруға болады.

Сондықтан біз бөлу, репликация және гео-таратылған жүйелер мәселелерін қозғамаймыз, бірақ дерекқор ішіндегі схема шешімдеріне назар аударамыз.

1-қадам: Кейбір бизнес ерекшеліктері

Біз хабар алмасуды абстрактілі түрде жасамаймыз, бірақ оны қоршаған ортаға біріктіреміз корпоративтік әлеуметтік желі. Яғни, біздің адамдар «жай хат жазысып» қоймай, бір-бірімен бизнестің белгілі бір мәселелерін шешу аясында араласады.

Ал бизнестің міндеттері қандай?.. Даму бөлімінің меңгерушісі Василийдің мысалын қарастырайық.

  • «Николай, бұл тапсырма үшін бізге бүгін патч керек!»
    Бұл хат алмасу кейбір контекстте жүргізілуі мүмкін дегенді білдіреді құжат.
  • «Коля, сен бүгін кешке Дотаға барасың ба?»
    Яғни, тіпті бір жұп әңгімелесушілер бір уақытта сөйлесе алады әртүрлі тақырыптарда.
  • «Питер, Николай, жаңа сервердің бағалар тізімін қосымшадан қараңыз.»
    Сонымен, бір хабарлама болуы мүмкін бірнеше алушы. Бұл жағдайда хабарлама болуы мүмкін Тіркелген файлдар.
  • -Семён, сен де қарашы.
    Ал бар корреспонденцияға түсуге мүмкіндік болуы керек жаңа мүше шақыру.

Әзірге осы «айқын» қажеттіліктер тізіміне тоқталайық.

Мәселенің қолданбалы ерекшеліктерін және оған берілген шектеулерді түсінбей, жобалау тиімді оны шешу мүмкін емес дерлік дерекқор схемасы.

2-қадам: Минималды логикалық схема

Әзірге барлығы электрондық пошта арқылы хат алмасуға өте ұқсас - дәстүрлі бизнес құралы. Иә, «алгоритмдік» көптеген бизнес мәселелері бір-біріне ұқсас, сондықтан оларды шешу құралдары құрылымдық жағынан ұқсас болады.

Алынған субъекті қатынастарының логикалық диаграммасын түзетейік. Модельді түсінуді жеңілдету үшін біз ең қарапайым дисплей опциясын қолданамыз ER үлгілері UML немесе IDEF белгілерінің қиындықтарынсыз:

Messenger деректер қоры (1-бөлім): базалық фреймворкті жобалау

Біздің мысалда файлдың тұлғасы, құжаты және екілік «денесі» біздің қызметімізсіз тәуелсіз өмір сүретін «сыртқы» нысандар болып табылады. Сондықтан, біз оларды болашақта 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

Біздің екі мәселеміз де біз болатын қосымша кестелер арқылы шешіледі деректердің қайталанатын бөлігі, олар бойынша біздің міндетімізге сәйкес келетін индекстерді қалыптастыру қажет.
Messenger деректер қоры (1-бөлім): базалық фреймворкті жобалау

Кестелер: 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)
);

Мұнда біз көмекші кестелерді құру кезінде қолданылатын екі типтік тәсілді қолдандық:

  • Жазбаларды көбейту
    Бір бастапқы хабарлама жазбасын пайдалана отырып, біз әр түрлі иелер үшін - жіберуші үшін де, алушы үшін де регистрлердің әртүрлі түрлерінде бірнеше кейінгі жазбаларды жасаймыз. Бірақ регистрлердің әрқайсысы қазір индекске түседі - әдеттегі жағдайда біз тек бірінші бетті көргіміз келеді.
  • Бірегей жазбалар
    Белгілі бір тақырыпта хабарлама жіберген сайын, мұндай жазбаның бар-жоғын тексеру жеткілікті. Егер жоқ болса, оны біздің «сөздікке» қосыңыз.

Мақаланың келесі бөлігінде біз сөйлесетін боламыз бөлуді жүзеге асыру дерекқорымыздың құрылымына енгізіңіз.

Ақпарат көзі: www.habr.com

пікір қалдыру