ProHoster > Blog > Administrasi > Database Messenger (bagian 2): ngabagi "kanggo kauntungan"

Database Messenger (bagian 2): ngabagi "kanggo kauntungan"

Kami parantos suksés ngararancang struktur database PostgreSQL kami pikeun nyimpen korespondensi, sataun parantos kapengker, pangguna aktip ngeusianana, sareng ayeuna ngandung jutaan rékaman, jeung... hiji hal mimiti ngalambatkeun turun.

Database Messenger (bagian 2): ngabagi "kanggo kauntungan"
Point nu Salaku ukuran tabel tumuwuh, jadi teu "jero" tina indexes. - sanajan logaritmik. Tapi kana waktosna ieu maksakeun server pikeun ngalaksanakeun tugas maca / nyerat anu sami ngolah sababaraha kali deui kaca datati mimiti.

Ieu dimana datang pikeun nyalametkeun babagian.

Hayu atuh dicatet yén urang teu ngobrol ngeunaan sharding, nyaeta, ngadistribusikaeun data antara database atawa server béda. Kusabab malah ngabagi data kana sababaraha server, anjeun moal meunang leupas tina masalah indexes "bareuh" kana waktu. Éta jelas yén upami anjeun mampuh nempatkeun server énggal unggal dinten, maka masalah anjeun moal aya deui dina pesawat databés khusus.

Kami bakal nganggap sanés naskah khusus pikeun ngalaksanakeun partisi "dina hardware", tapi pendekatanna sorangan - naon sareng kumaha kedah "dipotong irisan", sareng naon anu dipilampah ku kahayang sapertos kitu.

Konsep

Hayu urang ngartikeun tujuan urang sakali deui: urang hoyong mastikeun yén dinten ayeuna, énjing, sareng dina sataun, jumlah data anu dibaca ku PostgreSQL salami operasi maca / nyerat tetep sami.

Pikeun naon waé data akumulasi kronologis (pesen, dokumén, log, arsip, ...) pilihan alam salaku konci partisi tanggal / waktos acara. Dina hal urang, acara sapertos kitu momen ngirim pesen.

Catet yén pamaké ampir sok ngan ukur dianggo sareng anu "panganyarna". data sapertos - aranjeunna maca seratan panganyarna, nganalisis log panganyarna, ... Taya, tangtosna, aranjeunna tiasa ngagulung salajengna deui dina jangka waktu nu, tapi maranéhna ngalakukeun ieu pisan jarang.

Tina konstrain ieu jelas yén solusi pesen anu optimal bakal bagian "sapopoe". - Barina ogé, pamaké urang bakal ampir sok maca naon datang ka anjeunna "dinten" atawa "kamari".

Upami urang nyerat sareng maca ampir ngan ukur dina hiji bagian sadinten, maka ieu ogé masihan urang pamakéan leuwih efisien memori sareng disk - saprak sakabéh indexes bagian gampang pas kana RAM, kontras jeung "badag jeung gajih" sakuliah tabél.

léngkah-léngkah

Sacara umum, sagalana ceuk luhur disada kawas hiji kauntungan kontinyu. Sareng éta tiasa dihontal, tapi pikeun ieu urang kedah usaha keras - sabab kaputusan pikeun partisi salah sahiji entitas ngabalukarkeun kudu "ningali" pakait.

Pesen, sipat sarta projections na

Kusabab urang mutuskeun pikeun motong pesen dumasar kaping, masuk akal pikeun ogé ngabagi éntitas-sipat anu gumantung kana aranjeunna (file napel, daptar panarima), sareng ogé dumasar tanggal pesen.

Kusabab salah sahiji tugas khas urang nyaéta ningali daptar pesen (teu dibaca, asup, sadayana), logis ogé pikeun "ngagambar" kana partisi dumasar tanggal pesen.

Database Messenger (bagian 2): ngabagi "kanggo kauntungan"

Kami nambihan konci partisi (tanggal pesen) ka sadaya tabel: panarima, file, pendaptaran. Anjeun teu kedah nambihkeun kana pesen sorangan, tapi nganggo DateTime anu tos aya.

Jejer

Kusabab ngan ukur aya hiji topik pikeun sababaraha pesen, teu aya deui jalan pikeun "motong" dina modél anu sami; anjeun kedah ngandelkeun anu sanés. Dina hal urang éta idéal tanggal pesen munggaran dina susuratan - nyaeta, momen kreasi, kanyataanna, topik.

Database Messenger (bagian 2): ngabagi "kanggo kauntungan"

Tambahkeun konci partisi (tanggal topik) ka sadaya tabel: topik, pamilon.

Tapi ayeuna urang gaduh dua masalah sakaligus:

  • Dina bagian mana kuring kedah milarian pesen ngeunaan topik éta?
  • Dina bagian mana kuring kedah milarian topik tina pesen?

Urang tiasa, tangtosna, neruskeun milarian dina sakabéh bagian, tapi ieu bakal pisan hanjelu tur negate sagala winnings urang. Ku alatan éta, dina raraga terang dimana persis kasampak, urang bakal nyieun tumbu logis / pointers ka bagian:

  • urang bakal nambahan dina pesen widang tanggal topik
  • hayu urang tambahkeun kana topik tanggal pesen diatur susuratan ieu (tiasa tabel misah, atawa susunan kaping)

Database Messenger (bagian 2): ngabagi "kanggo kauntungan"

Kusabab bakal aya sababaraha modifikasi kana daptar tanggal pesen pikeun tiap korespondensi individu (sanggeus kabeh, ampir kabéh pesen ragrag dina 1-2 poé padeukeut), Kuring baris difokuskeun pilihan ieu.

Dina total, struktur database kami nyandak bentuk di handap ieu, nyandak partisi akun:

Tabél: RU, upami anjeun teu resep kana alfabét Sirilik dina nami tabel / widang, éta langkung saé henteu ningali

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

Nyimpen hiji Penny geulis

Nya, kumaha upami urang henteu nganggo pilihan sectioning Palasik dumasar kana distribusi nilai lapangan (ngaliwatan pemicu sareng warisan atanapi PARTITION BY), sareng "sacara manual" dina tingkat aplikasi, anjeun bakal perhatikeun yén nilai konci partisi parantos disimpen dina nami méja sorangan.

Janten upami anjeun kitu Naha anjeun hariwang pisan ngeunaan jumlah data anu disimpen?, teras anjeun tiasa nyingkirkeun widang "tambahan" ieu sareng alamat tabel khusus. Leres, sadaya pilihan tina sababaraha bagian dina hal ieu kedah ditransfer ka sisi aplikasi.

sumber: www.habr.com

Tambahkeun komentar