Hifadhidata ya Mjumbe (sehemu ya 2): kugawanya "kwa faida"

Tumefanikiwa kuunda muundo wa hifadhidata yetu ya PostgreSQL kwa ajili ya kuhifadhi mawasiliano, mwaka umepita, watumiaji wanaijaza kikamilifu, na sasa ina mamilioni ya rekodi, na ... kitu kilianza kupungua.

• Sehemu ya 1: kubuni sura ya msingi
• Sehemu ya 2: sehemu "kwa faida"

Ukweli ni kwamba Kadiri ukubwa wa jedwali unavyokua, ndivyo "kina" cha indexes kinakua. - pamoja na logarithmically. Lakini baada ya muda hii inalazimisha seva kufanya kazi sawa za kusoma / kuandika kuchakata kurasa nyingi za datakuliko mwanzo.

Hapa ndipo inakuja kuwaokoa kugawa.

Napenda kutambua kwamba hatuzungumzii juu ya kugawanyika, yaani, kusambaza data kati ya hifadhidata tofauti au seva. Kwa sababu hata kugawanya data ndani baadhi seva, hautaondoa shida ya "uvimbe" wa faharisi kwa wakati. Ni wazi kuwa ikiwa unaweza kumudu kuweka seva mpya katika operesheni kila siku, basi shida zako hazitalala tena kwenye ndege ya hifadhidata maalum.

Hatutazingatia maandishi maalum ya kutekeleza kizigeu "katika vifaa", lakini mbinu yenyewe - ni nini na jinsi inapaswa "kukatwa vipande vipande", na ni nini hamu kama hiyo inaongoza.

Dhana

Hebu tufafanue lengo letu kwa mara nyingine tena: tunataka kuhakikisha kwamba leo, kesho, na katika mwaka, kiasi cha data iliyosomwa na PostgreSQL wakati wa operesheni yoyote ya kusoma / kuandika inabaki takriban sawa.

Kwa yoyote data iliyokusanywa kwa mpangilio (ujumbe, hati, kumbukumbu, kumbukumbu, ...) chaguo asili kama ufunguo wa kugawa ni tarehe/saa ya tukio. Kwa upande wetu, tukio kama hilo ni wakati wa kutuma ujumbe.

Kumbuka kuwa watumiaji karibu kila wakati fanya kazi tu na zile "za hivi karibuni". data kama hizo - wanasoma ujumbe wa hivi karibuni, kuchambua kumbukumbu za hivi karibuni, ... Hapana, bila shaka, wanaweza kusonga mbele zaidi kwa wakati, lakini hufanya hivyo mara chache sana.

Kutoka kwa vikwazo hivi ni wazi kuwa suluhisho bora la ujumbe litakuwa sehemu za "kila siku". - baada ya yote, mtumiaji wetu karibu kila wakati atasoma kile kilichomjia "leo" au "jana".

Ikiwa tunaandika na kusoma karibu tu katika sehemu moja wakati wa mchana, basi hii pia inatupa matumizi bora zaidi ya kumbukumbu na diski - kwa kuwa faharisi zote za sehemu zinafaa kwa urahisi kwenye RAM, tofauti na zile "kubwa na mafuta" kwenye jedwali.

hatua kwa hatua

Kwa ujumla, kila kitu kilichosemwa hapo juu kinasikika kama faida moja inayoendelea. Na inawezekana, lakini kwa hili tutalazimika kujaribu kwa bidii - kwa sababu uamuzi wa kugawa moja ya vyombo husababisha hitaji la "kuona" inayohusishwa.

Ujumbe, mali na makadirio yake

Kwa kuwa tuliamua kukata ujumbe kwa tarehe, inaleta maana pia kugawanya huluki-mali zinazotegemea (faili zilizoambatishwa, orodha ya wapokeaji), na pia kwa tarehe ya ujumbe.

Kwa kuwa moja ya kazi zetu za kawaida ni kuangalia kwa usahihi rejista za ujumbe (hazijasomwa, zinazoingia, zote), pia ni jambo la busara "kuzivuta" katika kugawanya kwa tarehe za ujumbe.

Tunaongeza ufunguo wa kugawa (tarehe ya ujumbe) kwa meza zote: wapokeaji, faili, usajili. Sio lazima uiongeze kwenye ujumbe wenyewe, lakini tumia DateTime iliyopo.

Topics

Kwa kuwa kuna mada moja tu ya ujumbe kadhaa, hakuna njia ya "kuikata" kwa mfano sawa; lazima utegemee kitu kingine. Kwa upande wetu ni bora tarehe ya ujumbe wa kwanza katika mawasiliano - yaani, wakati wa uumbaji, kwa kweli, wa mada.

Ongeza kitufe cha kugawa (tarehe ya mada) kwa majedwali yote: mada, mshiriki.

Lakini sasa tuna shida mbili mara moja:

• Ni katika sehemu gani ninapaswa kutafuta ujumbe juu ya mada?
• Ni katika sehemu gani nitafute mada kutoka kwa ujumbe?

Tunaweza, kwa kweli, kuendelea kutafuta katika sehemu zote, lakini hii itakuwa ya kusikitisha sana na itapuuza ushindi wetu wote. Kwa hivyo, ili kujua ni wapi pa kuangalia, tutafanya viungo/viashiria vya kimantiki kwa sehemu:

• tutaongeza kwenye ujumbe uwanja wa tarehe ya mada
• tuongeze kwenye mada tarehe ya ujumbe imewekwa mawasiliano haya (yanaweza kuwa jedwali tofauti, au safu ya tarehe)

Kwa kuwa kutakuwa na marekebisho machache kwenye orodha ya tarehe za ujumbe kwa kila mawasiliano ya mtu binafsi (baada ya yote, karibu ujumbe wote huanguka siku 1-2 zilizo karibu), nitazingatia chaguo hili.

Kwa jumla, muundo wa hifadhidata yetu ulichukua fomu ifuatayo, kwa kuzingatia ugawaji:

Jedwali: RU, ikiwa una chuki kwa alfabeti ya Cyrilli katika majina ya jedwali / uwanja, ni bora kutoangalia.

-- секции по дате сообщения
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
);

Okoa senti nzuri

Kweli, ikiwa hatutumii chaguo la ugawaji wa classic kulingana na usambazaji wa maadili ya uwanja (kupitia vichochezi na urithi au PARTITION BY), na "kwa mikono" katika kiwango cha maombi, utaona kuwa thamani ya ufunguo wa kugawa tayari imehifadhiwa kwa jina la jedwali yenyewe.

Hivyo kama wewe ni hivyo Je, una wasiwasi sana kuhusu kiasi cha data iliyohifadhiwa?, basi unaweza kuondokana na mashamba haya "ya ziada" na kushughulikia meza maalum. Kweli, chaguzi zote kutoka kwa sehemu kadhaa katika kesi hii zitalazimika kuhamishiwa upande wa maombi.

Chanzo: mapenzi.com