Basis data Messenger (bagean 2): partisi "kanggo bathi"

Kita wis sukses ngrancang struktur database PostgreSQL kanggo nyimpen korespondensi, wis setahun kepungkur, pangguna aktif ngisi, lan saiki ngemot mayuta-yuta cathetan, lan... soko wiwit alon mudhun.

• Bagean 1: ngrancang pigura dhasar
• Bagean 2: bagean "kanggo laba"

Titik iku Minangka ukuran meja mundak akeh, uga "ambane" indeks. - sanajan logaritma. Nanging liwat wektu iki meksa server nindakake tugas maca / nulis sing padha ngolah data kaping pirang-pirang kacatinimbang ing wiwitan.

Iki ngendi teka kanggo ngluwari bagean.

Elinga yen kita ora ngomong babagan sharding, yaiku nyebarake data ing antarane database utawa server sing beda. Amarga malah dibagi data menyang sawetara server, sampeyan ora bakal njaluk nyisihaken saka masalah indeks "abuh" liwat wektu. Cetha yen sampeyan bisa nindakake server anyar saben dina, mula masalah sampeyan ora bakal ana maneh ing bidang database tartamtu.

Kita ora bakal nimbang skrip khusus kanggo ngleksanakake partisi "ing hardware", nanging pendekatan dhewe - apa lan carane kudu "dipotong dadi irisan", lan apa sing dikarepake.

Konsep

Ayo nemtokake tujuane maneh: kita pengin mesthekake yen dina iki, sesuk, lan setaun, jumlah data sing diwaca PostgreSQL sajrone operasi maca / nulis tetep kira-kira padha.

Kanggo sembarang data akumulasi kronologis (pesen, dokumen, log, arsip, ...) pilihan alami minangka kunci partisi tanggal / wektu acara. Ing kasus kita, acara kuwi wayahe ngirim pesen.

Elinga yen pangguna meh tansah bisa mung karo "paling anyar". data kuwi - padha maca pesen paling anyar, njelasno log paling anyar, ... Ora, mesthi, padha bisa nggulung luwih bali ing wektu, nanging padha nindakake iki arang banget.

Saka kendala kasebut jelas yen solusi pesen sing paling optimal yaiku bagean "saben dina". - sawise kabeh, pangguna kita meh tansah maca apa sing teka marang dheweke "dina iki" utawa "wingi".

Yen kita nulis lan maca meh mung ing siji bagean sak dina, iki uga menehi kita luwih efisien nggunakake memori lan disk - wiwit kabeh indeks bagean gampang pas menyang RAM, ing kontras kanggo "gedhe lan lemak" ing saindhenging meja.

langkah-langkah

Umumé, kabeh ngandika ndhuwur muni kaya siji terus-terusan MediaWiki. Lan bisa digayuh, nanging iki kita kudu nyoba hard - amarga kaputusan kanggo pemisahan siji saka èntitas ndadékaké kanggo perlu kanggo "weruh" gadhah.

Pesen, sifat lan proyeksi

Amarga kita mutusake kanggo ngethok pesen miturut tanggal, mula uga kudu dibagi entitas-properti sing gumantung marang dheweke (file sing dilampirake, dhaptar panampa), lan uga miturut tanggal pesen.

Amarga salah sawijining tugas khas kita yaiku ndeleng dhaptar pesen kanthi tepat (durung diwaca, mlebu, kabeh), uga logis kanggo "nggambar" menyang partisi miturut tanggal pesen.

Kita nambah tombol partisi (tanggal pesen) menyang kabeh tabel: panampa, file, registri. Sampeyan ora kudu nambah menyang pesen dhewe, nanging nggunakake ana DateTime.

Topik

Amarga mung ana siji topik kanggo sawetara pesen, ora ana cara kanggo "motong" ing model sing padha; sampeyan kudu ngandelake liyane. Ing kasus kita iku becik tanggal pesen pisanan ing korespondensi - yaiku, wayahe nggawe, nyatane, topik kasebut.

Tambah tombol partisi (tanggal topik) menyang kabeh tabel: topik, peserta.

Nanging saiki kita duwe rong masalah sekaligus:

• Ing bagean endi aku kudu nggoleki pesen babagan topik kasebut?
• Ing bagean endi aku kudu nggoleki topik saka pesen kasebut?

Kita bisa, mesthi, terus nelusuri ing kabeh bagean, nanging iki bakal sedih banget lan bakal negate kabeh winnings kita. Mula, kanggo ngerti endi sing kudu dideleng, kita bakal nggawe pranala logis / pointer menyang bagean:

• kita bakal nambah ing pesen lapangan tanggal topik
• ayo nambahi topik pesen tanggal disetel korespondensi iki (bisa dadi tabel sing kapisah, utawa sawetara tanggal)

Awit bakal ana sawetara modifikasi ing dhaptar tanggal pesen kanggo saben korespondensi individu (sawise kabeh, meh kabeh pesen tiba ing 1-2 dina jejer), aku bakal fokus ing pilihan iki.

Secara total, struktur database kita njupuk formulir ing ngisor iki, njupuk partisi akun:

Tabel: RU, yen sampeyan ora seneng karo aksara Sirilik ing jeneng tabel / kolom, luwih becik ora katon.

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

Ngirit sen cantik

Inggih, apa yen kita nggunakake ora opsi bagean klasik adhedhasar distribusi nilai lapangan (liwat pemicu lan warisan utawa PARTITION BY), lan "kanthi manual" ing tingkat aplikasi, sampeyan bakal weruh yen nilai tombol partisi wis disimpen ing jeneng tabel kasebut.

Dadi yen sampeyan mangkono Apa sampeyan kuwatir banget babagan jumlah data sing disimpen?, banjur sampeyan bisa nyisihake kolom "ekstra" iki lan alamat tabel tartamtu. Bener, kabeh pilihan saka sawetara bagean ing kasus iki kudu ditransfer menyang sisih aplikasi.

Source: www.habr.com