მესენჯერის მონაცემთა ბაზა (ნაწილი 2): დაყოფა „მოგების მიზნით“

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

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

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

სწორედ აქ მოდის საქმე სამაშველოში განყოფილება.

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

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

Შინაარსი

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

ნებისმიერისთვის ქრონოლოგიურად დაგროვილი მონაცემები (შეტყობინებები, დოკუმენტები, ჟურნალები, არქივები, ...) ბუნებრივი არჩევანი, როგორც დანაყოფის გასაღები არის ღონისძიების თარიღი/დრო. ჩვენს შემთხვევაში ასეთი მოვლენაა შეტყობინების გაგზავნის მომენტი.

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

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

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

ნაბიჯ - ნაბიჯ

ზოგადად, ყველაფერი, რაც ზემოთ არის ნათქვამი, ერთ უწყვეტ მოგებას ჰგავს. და ეს მიღწევადია, მაგრამ ამისთვის ბევრი უნდა ვეცადოთ - იმიტომ ერთ-ერთი სუბიექტის დაყოფის გადაწყვეტილება იწვევს ასოცირებულის „დანახვის“ აუცილებლობას.

შეტყობინება, მისი თვისებები და პროგნოზები

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

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

ჩვენ ვამატებთ დანაყოფის გასაღებს (შეტყობინების თარიღს) ყველა ცხრილს: მიმღებებს, ფაილებს, რეესტრებს. თქვენ არ გჭირდებათ მისი დამატება თავად შეტყობინებაში, მაგრამ გამოიყენეთ არსებული DateTime.

Темы

ვინაიდან რამდენიმე მესიჯისთვის მხოლოდ ერთი თემაა, არ არსებობს მისი ერთ მოდელში „გაჭრის“ გზა, თქვენ უნდა დაეყრდნოთ სხვა რამეს. ჩვენს შემთხვევაში იდეალურია მიმოწერაში პირველი შეტყობინების თარიღი — ანუ, ფაქტობრივად, თემის შექმნის მომენტი.

დაამატეთ დანაყოფის გასაღები (თემის თარიღი) ყველა ცხრილს: თემა, მონაწილე.

მაგრამ ახლა ჩვენ გვაქვს ორი პრობლემა ერთდროულად:

• რომელ განყოფილებაში უნდა ვეძიო შეტყობინებები თემაზე?
• რომელ განყოფილებაში უნდა ვეძიო თემა მესიჯიდან?

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

• შეტყობინებაში დავამატებთ თემის თარიღის ველი
• თემას დავამატოთ დაყენებულია შეტყობინების თარიღი ეს მიმოწერა (შეიძლება იყოს ცალკე ცხრილი ან თარიღების მასივი)

იმის გამო, რომ შეტყობინებების თარიღების სიაში რამდენიმე ცვლილება იქნება თითოეული ინდივიდუალური მიმოწერისთვის (ბოლოს და ბოლოს, თითქმის ყველა შეტყობინება მოდის 1-2 მიმდებარე დღეს), მე ყურადღებას გავამახვილებ ამ ვარიანტზე.

საერთო ჯამში, ჩვენი მონაცემთა ბაზის სტრუქტურამ მიიღო შემდეგი ფორმა დაყოფის გათვალისწინებით:

ცხრილები: RU, თუ თქვენ გაქვთ ზიზღი კირიული ანბანის მიმართ ცხრილების/ველების სახელებში, ჯობია არ შეხედოთ

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

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

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

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

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

დაზოგე საკმაოდ პენი

რა მოხდება, თუ არ გამოვიყენებთ კლასიკური განყოფილების ვარიანტი ველის მნიშვნელობების განაწილების საფუძველზე (ტრიგერები და მემკვიდრეობა ან PARTITION BY) და „ხელით“ აპლიკაციის დონეზე, შეამჩნევთ, რომ დანაყოფის გასაღების მნიშვნელობა უკვე ინახება თავად ცხრილის სახელში.

ასე რომ, თუ ასე ხარ ძალიან გაწუხებთ შენახული მონაცემების რაოდენობა?, მაშინ შეგიძლიათ მოიცილოთ ეს „დამატებითი“ ველები და მიმართოთ კონკრეტულ ცხრილებს. მართალია, ამ შემთხვევაში რამდენიმე სექციიდან ყველა არჩევანი უნდა გადავიდეს განაცხადის მხარეს.

წყარო: www.habr.com