Me bi serfirazî strukturên databasa xwe ya PostgreSQL ji bo hilanîna pêwendiyan sêwirand, salek derbas bû, bikarhêner bi çalak wê tije dikin, û naha ew tê de ye bi milyonan tomar, û ... tiştek dest pê kir ku hêdî.
- Beş 2: beşa "ji bo qezencê"
Rast e ku Her ku mezinahiya tabloyê mezin dibe, "kûrahiya" nîşanan jî zêde dibe. - her çend bi logarîtmîkî be. Lê bi demê re ev server neçar dike ku heman karên xwendinê/nivîsandinê pêk bîne gelek caran bêtir rûpelên daneyê pêvajoyê bikinji destpêkê.
Ev e ku ew ji bo rizgariyê tê beşkirin.
Bihêle ku ez zanibim ku em ne li ser parvekirinê diaxivin, ango belavkirina daneyan di navbera databases an serverên cihêreng de. Ji ber ku heta dabeşkirina daneyan nav çend pêşkêşkeran, hûn ê bi demê re ji pirsgirêka "werimandina" indexan xilas nebin. Eşkere ye ku ger hûn bikaribin her roj serverek nû bixebitînin, wê hingê pirsgirêkên we dê êdî di balafirek databasek taybetî de nemînin.
Em ê ne skrîptên taybetî yên ji bo pêkanîna dabeşkirinê "di hardware" de, lê nêzîkatiya xwe bihesibînin - çi û çawa divê were "qurtandin", û xwestekek wusa ber bi çi ve dibe.
Reşik
Werin em careke din armanca xwe diyar bikin: em dixwazin piştrast bikin ku îro, sibê û salek şûn de, hêjmara daneya ku ji hêla PostgreSQL ve di dema her xebata xwendinê/nivîsandinê de tê xwendin hema hema heman bimîne.
Ji bo her daneyên berhevkirî yên kronolojîk (peyam, belge, têketin, arşîv, ...) bijartina xwezayî wekî mifteya dabeşkirinê ye dîroka bûyerê / dem. Li cem me bûyereke wisa ye dema şandina peyamê.
Têbînî ku bikarhêner hema hema her gav tenê bi yên "dawî" re bixebitin Daneyên weha - ew peyamên herî dawî dixwînin, têketinên herî dawî analîz dikin,... Na, bê guman, ew dikarin di wextê de bêtir bi paş ve bigerin, lê ew vê yekê pir kêm dikin.
Ji van astengan diyar e ku çareseriya peyama çêtirîn dê bibe beşên "rojane". - her tiştî, bikarhênerê me dê hema hema her gav tiştê ku jê re "îro" an "duh" hatî bixwîne.
Ger em di nava rojê de hema hema di yek beşê de binivîsin û bixwînin, wê demê ev jî dide me bikaranîna bikêrtir bîra û dîskê - ji ber ku hemî navnîşên beşan bi hêsanî di RAM-ê de cih digirin, berevajî yên "mezin û qelew" li seranserê tabloyê.
gav bi gav
Bi gelemperî, her tiştê ku li jor hatî gotin wekî yek qezencek domdar xuya dike. Û ew pêkan e, lê ji bo vê yekê em ê hewce bikin ku pir hewl bidin - ji ber biryara dabeşkirina yek ji saziyan dibe sedema hewcedariya "dît"ê ya têkildar.
Peyam, taybetmendî û pêşniyarên wê
Ji ber ku me biryar da ku em peyaman li gorî mêjûyan qut bikin, maqûl e ku em sazî-taybetmendiyên ku bi wan ve girêdayî ne jî dabeş bikin (pelên pêvekirî, navnîşa wergiran), û her weha ji hêla roja peyamê ve.
Ji ber ku yek ji peywirên me yên tîpîk bi rastî temaşekirina tomarên peyaman e (nexwendî, hatin, hemî), di heman demê de mentiqî ye ku meriv "wan bikişîne hundurê" nav dabeşkirina li gorî tarîxên peyamê.
Em mifteya dabeşkirinê (roja peyamê) li hemî tabloyan zêde dikin: wergir, pel, tomar. Ne hewce ye ku hûn wê li peyamê bixwe lê zêde bikin, lê DateTime-ya heyî bikar bînin.
Mijar
Ji ber ku ji bo çend peyaman tenê mijarek heye, rê tune ku meriv wê di heman modelê de "bibire"; divê hûn xwe bispêrin tiştek din. Di rewşa me de îdeal e dîroka peyama yekem di hevpeyivînê de - ango dema afirandinê, bi rastî, mijarê.
Mifteya dabeşkirinê (roja mijarê) li hemû tabloyan zêde bikin: mijar, beşdar.
Lê niha du pirsgirêkên me di carekê de hene:
- Divê ez li kîjan beşê li peyamên li ser mijarê bigerim?
- Divê ez li kîjan beşê li mijarê ji peyamê bigerim?
Bê guman, em dikarin di hemî beşan de lêgerîna xwe bidomînin, lê ev ê pir xemgîn be û dê hemî destkeftiyên me red bike. Ji ber vê yekê, ji bo ku em zanibin tam li ku binihêrin, em ê girêdan/nîşaneyên mentiqî ji beşan re çêbikin:
- em ê di peyamê de zêde bikin qada dîroka mijarê
- em li mijarê zêde bikin date message set ev hevpeyivîn (dibe ku tabloyek veqetandî, an rêzek dîrokan be)
Ji ber ku dê di navnîşa tarîxên peyamê de ji bo her hevpeyivînek kesane çend guheztin hebin (ji ber vê yekê, hema hema hemî peyam di 1-2 rojên nêz de dikevin), ez ê li ser vê vebijarkê bisekinim.
Bi tevahî, strukturên databasa me forma jêrîn girt, ku dabeşkirinê li ber çavan digire:
Tablo: RU, ger di navên tabloyan/qadan de ji alfabeya kîrîlî nefret hebe, çêtir e ku meriv nenihêre.
-- секции по дате сообщения
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
);
Pûçek xweşik xilas bike
Baş e, heke em bikar neynin li ser bingeha dabeşkirina nirxên zeviyê (bi rêça tetik û mîras an PARTITION BY), û "bi destan" di asta serîlêdanê de, hûn ê bibînin ku nirxa mifteya dabeşkirinê jixwe di navê tabloyê bixwe de hatî hilanîn.
Îcar eger hûn wisa bin Ma hûn ji rêjeya daneyên hilandî pir bi fikar in?, wê hingê hûn dikarin ji van zeviyên "zêde" xilas bibin û tabloyên taybetî navnîş bikin. Rast e, di vê rewşê de hemî bijare ji çend beşan dê bêne veguheztin alîyê serîlêdanê.
Source: www.habr.com