Við höfum hannað uppbyggingu PostgreSQL gagnagrunnsins okkar til að geyma bréfaskipti, ár er liðið, notendur eru virkir að fylla hann og nú inniheldur hann milljónir skráa, og... eitthvað fór að hægja á sér.
- Hluti 2: skipting „í hagnaðarskyni“
Staðreyndin er sú að Eftir því sem töflustærðin stækkar, eykst „dýpt“ vísitölanna. - þó logaritmískt. En með tímanum neyðir þetta netþjóninn til að framkvæma sömu lestur/skrifa verkefni vinna margfalt fleiri síður af gögnumen í upphafi.
Þetta er þar sem það kemur til bjargar skipting.
Leyfðu mér að taka fram að við erum ekki að tala um sharding, það er að dreifa gögnum á milli mismunandi gagnagrunna eða netþjóna. Vegna þess að jafnvel deila gögnunum í sumar netþjóna, muntu ekki losna við vandamálið með því að vísitölur „bólga“ með tímanum. Það er ljóst að ef þú hefur efni á að setja nýjan netþjón í notkun á hverjum degi, þá munu vandamál þín alls ekki liggja lengur á plani ákveðins gagnagrunns.
Við munum ekki íhuga sérstakar forskriftir til að útfæra skiptingu „í vélbúnaði“, heldur nálgunina sjálfa - hvað og hvernig ætti að „skera í sneiðar“ og til hvers slík löngun leiðir.
Hugtak
Við skulum skilgreina markmið okkar enn og aftur: við viljum ganga úr skugga um að í dag, á morgun og eftir ár verði gagnamagnið sem PostgreSQL les við allar lestur/skrifaðgerðir um það bil það sama.
Fyrir hvaða gögn sem safnast í tímaröð (skilaboð, skjöl, annálar, skjalasafn, ...) eðlilegt val sem skiptingarlykill er dagsetning/tími viðburðar. Í okkar tilviki er slíkur atburður augnabliki við að senda skilaboðin.
Athugaðu að notendur næstum alltaf vinna aðeins með „nýjustu“ slík gögn - þeir lesa nýjustu skilaboðin, greina nýjustu login,... Nei, auðvitað geta þeir flett lengra aftur í tímann, en þeir gera þetta mjög sjaldan.
Af þessum takmörkunum er ljóst að ákjósanlegasta skilaboðalausnin væri „daglega“ hluta - þegar allt kemur til alls mun notandi okkar næstum alltaf lesa það sem kom til hans „í dag“ eða „í gær“.
Ef við skrifum og lesum nánast aðeins í einum hluta yfir daginn, þá gefur þetta okkur líka skilvirkari notkun minni og disks - þar sem allar hlutavísitölur passa auðveldlega inn í vinnsluminni, öfugt við þær „stóru og feitu“ í töflunni.
skref fyrir skref
Almennt séð hljómar allt sem sagt er hér að ofan eins og einn samfelldur hagnaður. Og það er hægt, en fyrir þetta verðum við að reyna mikið - vegna þess ákvörðunin um að skipta einni af einingunum í sundur leiðir til þess að þurfa að „sá“ tilheyrandi.
Skilaboð, eiginleikar þess og spár
Þar sem við ákváðum að klippa skilaboð eftir dagsetningum er skynsamlegt að skipta einnig einingar-eiginleikum sem eru háðar þeim (meðfylgjandi skrár, listi yfir viðtakendur) og einnig eftir dagsetningu skilaboða.
Þar sem eitt af dæmigerðum verkefnum okkar er einmitt að skoða skilaboðaskrár (ólesnar, mótteknar, allt), er líka rökrétt að „teikna þær inn“ í skiptingu eftir skilaboðadögum.
Við bætum skiptingarlyklinum (skilaboðsdagsetningu) við allar töflur: viðtakendur, skrá, skrár. Þú þarft ekki að bæta því við skilaboðin sjálf, heldur nota núverandi DateTime.
þræðir
Þar sem það er aðeins eitt efni fyrir nokkur skilaboð, þá er engin leið að „klippa“ það í sömu gerð; þú verður að treysta á eitthvað annað. Í okkar tilviki er það tilvalið dagsetning fyrstu skilaboða í bréfaskiptum — það er, í raun og veru sköpunarstund efnisins.
Bættu skiptingarlyklinum (dagsetning efnis) við allar töflur: efni, þátttakandi.
En núna erum við með tvö vandamál í einu:
- Í hvaða hluta ætti ég að leita að skilaboðum um efnið?
- Í hvaða hluta ætti ég að leita að efninu úr skilaboðunum?
Við getum að sjálfsögðu haldið áfram að leita í öllum köflum en þetta verður mjög sorglegt og dregur úr öllum vinningum okkar. Þess vegna, til að vita hvar nákvæmlega á að leita, munum við búa til rökrétta hlekki / ábendingar á hluta:
- við bætum við í skilaboðunum efnisdagsetningarreitur
- bætum við efnið skilaboðadagsetning sett þessi samsvörun (getur verið aðskilin tafla, eða fjöldi dagsetninga)
Þar sem það verða litlar breytingar á listanum yfir skilaboðadagsetningar fyrir hverja einstaka bréfaskipti (eftir allt saman falla næstum öll skilaboð á 1-2 samliggjandi daga), mun ég einbeita mér að þessum valkosti.
Alls tók uppbygging gagnagrunnsins okkar eftirfarandi mynd, að teknu tilliti til skiptingar:
Töflur: HR, ef þú hefur andúð á kyrillíska stafrófinu í nöfnum á töflum/reitum, þá er betra að líta ekki
-- секции по дате сообщения
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
);
Sparaðu dágóðan eyri
Jæja, hvað ef við notum það ekki byggt á dreifingu svæðisgilda (með kveikjum og arfleifð eða PARTITION BY), og „handvirkt“ á umsóknarstigi, muntu taka eftir því að gildi skiptingarlykilsins er þegar geymt í nafni töflunnar sjálfrar.
Svo ef þú ert það Hefur þú miklar áhyggjur af magni gagna sem geymt er?, þá geturðu losað þig við þessa „auka“ reiti og tekið á tilteknum töflum. Að vísu verður að flytja allt val úr nokkrum hlutum í þessu tilfelli yfir á umsóknarhliðina.
Heimild: www.habr.com