მესენჯერის მონაცემთა ბაზა (ნაწილი 1): საბაზისო ჩარჩოს დიზაინი

როგორ შეგიძლიათ თარგმნოთ ბიზნესის მოთხოვნები მონაცემთა კონკრეტულ სტრუქტურებში მესინჯერის მონაცემთა ბაზის ნულიდან დიზაინის მაგალითის გამოყენებით.

• ნაწილი 1: ბაზის ჩარჩოს დიზაინი
• ნაწილი 2: განყოფილება "მოგებისთვის"

ჩვენი ბაზა არ იქნება ისეთი დიდი და განაწილებული, როგორც VKontakte ან Badoo, მაგრამ "ისე რომ იყო", მაგრამ კარგი იყო - ფუნქციონალური, სწრაფი და ჯდება ერთ სერვერზე PostgreSQL - ასე რომ თქვენ შეგიძლიათ განათავსოთ სერვისის ცალკეული ინსტანცია სადღაც მხარეს, მაგალითად.

ამიტომ, ჩვენ არ შევეხებით შერწყმის, რეპლიკაციისა და გეო-განაწილებული სისტემების საკითხებს, მაგრამ ყურადღებას გავამახვილებთ მონაცემთა ბაზის შიგნით მიკროსქემის გადაწყვეტებზე.

ნაბიჯი 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: ჭკვიანი დენორმალიზაცია

ჩვენი ორივე პრობლემა მოგვარდება დამატებითი ცხრილებით, რომლებშიც ჩვენ მოვაგვარებთ მონაცემების ნაწილის დუბლიკატი, აუცილებელია მათზე ჩვენი ამოცანებისთვის შესაფერისი ინდექსების ჩამოყალიბება.


მაგიდები: 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