Database Messenger (bagian 1): ngarancang kerangka dasar

Kumaha anjeun tiasa narjamahkeun syarat bisnis kana struktur data khusus nganggo conto ngarancang database utusan ti mimiti.

• Bagian 1: ngarancang pigura dasar
• Bagian 2: bagian "kanggo kauntungan"

Basis kami moal ageung sareng disebarkeun, kawas VKontakte atawa Badoo, tapi "supaya éta", tapi éta alus - fungsi, gancang jeung pas dina hiji server PostgreSQL - supados anjeun tiasa nyebarkeun conto anu misah tina jasa di tempat anu sanés, contona.

Kituna, urang moal noél kana masalah sharding, réplikasi jeung sistem geo-disebarkeun, tapi bakal difokuskeun solusi sirkuit jero database.

Lengkah 1: Sababaraha spésifik bisnis

Kami moal mendesain olahtalatah urang sacara abstrak, tapi bakal ngahijikeun kana lingkungan jaringan sosial perusahaan. Hartina, jalma urang teu "ngan pakait," tapi saling komunikasi dina konteks ngarengsekeun masalah bisnis tangtu.

Sareng naon tugas bisnis?.. Hayu urang tingali conto Vasily, kapala departemen pangwangunan.

• "Nikolai, pikeun tugas ieu urang peryogi patch dinten ieu!"
  Ieu ngandung harti yén korespondensi bisa dilaksanakeun dina konteks sababaraha surat penting.
• "Kolya, anjeun badé dota wengi ayeuna?"
  Hartina, sanajan hiji pasangan interlocutors bisa komunikasi sakaligus dina rupa-rupa jejer.
• "Peter, Nikolay, tingali dina lampiran pikeun daptar harga pikeun server anyar."
  Janten, hiji pesen tiasa gaduh sababaraha panarima. Dina hal ieu, pesen bisa ngandung file napel.
• "Semyon, tingali ogé."
  Sareng kedah aya kasempetan pikeun asup kana korespondensi anu aya ngajak anggota anyar.

Hayu urang cicing dina daptar ieu kabutuhan "jelas" pikeun ayeuna.

Tanpa ngartos spésifik anu diterapkeun tina masalah sareng watesan anu dipasihkeun ka éta, desain éféktif schema database pikeun ngajawab éta ampir teu mungkin.

Lengkah 2: Sirkuit Logika Minimal

Sajauh ieu, sagalana jalan kaluar pisan sarupa email susuratan - a traditional business tool . Leres, "algoritma" seueur masalah bisnis anu sami sareng anu sanés, janten alat pikeun ngarengsekeunana bakal sami sacara struktural.

Hayu urang ngalereskeun diagram logis tina hubungan éntitas anu parantos dicandak. Pikeun ngajantenkeun modél urang langkung gampang kahartos, urang bakal nganggo pilihan tampilan anu paling primitif modél ER tanpa komplikasi notasi UML atanapi IDEF:

Dina conto urang, jalma, dokumén sareng binér "awak" file mangrupikeun éntitas "éksternal" anu aya sacara mandiri tanpa jasa kami. Ku alatan éta, urang ngan saukur bakal ngarasa aranjeunna dina mangsa nu bakal datang salaku sababaraha tumbu "dimana" ku UUID.

Ngagambar diagram sakumaha basajan sabisa - Seuseueurna jalma anu anjeun bakal nunjukkeun ka aranjeunna sanés ahli maca UML / IDEF. Tapi pastikeun ngagambar.

Lengkah 3: Sketching struktur tabel

Ngeunaan ngaran tabel sarta widangNgaran "Rusia" tina widang jeung tabel bisa diolah béda, tapi ieu masalah rasa. Kusabab éta didieu di Tensor teu aya pamekar asing, sareng PostgreSQL ngamungkinkeun urang masihan nami bahkan dina hiéroglif, upami aranjeunna diapit ku kutipan, mangka urang leuwih milih ngaran objék unambiguously tur jelas ku kituna teu aya discrepancies.
Kusabab seueur jalma anu nyerat pesen ka kami sakaligus, sababaraha di antarana tiasa ngalakukeun ieu offline, teras pilihan pangbasajanna nyaéta ngagunakeun UUIDs salaku identifiers henteu ngan pikeun éntitas éksternal, tapi ogé pikeun sakabéh objék jero jasa kami. Leuwih ti éta, maranéhna bisa dihasilkeun malah di sisi klien - ieu bakal nulungan urang ngarojong ngirim pesen lamun database samentara teu sadia, sarta likelihood tina tabrakan pisan low.

Struktur tabel draf dina pangkalan data urang bakal katingali sapertos kieu:
Tabél: RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

Tabél: EN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

Hal pangbasajanna nalika ngajelaskeun format nyaéta ngamimitian "unwinding" grafik sambungan ti tabel nu teu referenced sorangan ka saha.

Lengkah 4: Panggihan kabutuhan anu teu jelas

Éta waé, kami parantos ngararancang pangkalan data dimana anjeun tiasa nyerat sampurna sareng kumaha waé ogé maca.

Hayu urang nempatkeun diri dina sapatu pangguna jasa kami - naon anu urang hoyong laksanakeun?

• pesen panungtungan
  ieu kronologis diurutkeun a pendaptaran pesen "abdi" dumasar kana rupa kriteria. Dimana kuring salah sahiji panampi, dimana kuring panulis, dimana aranjeunna nyerat ka kuring sareng kuring henteu ngawaler, dimana aranjeunna henteu ngawaler kuring, ...
• Pamilon nu susuratan
  Saha anu milu ngobrol panjang sareng panjang ieu?

Struktur kami ngamungkinkeun urang pikeun ngajawab duanana masalah ieu "sacara umum," tapi teu gancang. Masalahna nyaéta pikeun nyortir dina tugas munggaran teu bisa nyieun indéks, cocog pikeun tiap pamilon (sareng anjeun kedah nimba sadaya rékaman), sareng pikeun ngabéréskeun anu kadua anjeun peryogi nimba sadaya pesen dina topik ieu.

Tugas pamaké nu teu dihaja bisa nempatkeun kandel cross on produktivitas.

Lengkah 5: Smart Denormalization

Duanana masalah urang bakal direngsekeun ku tabel tambahan nu urang bakal bagian duplikat tina data, diperlukeun pikeun ngabentuk dina éta indéks cocog pikeun tugas urang.


Tabél: RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

Tabél: EN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

Di dieu kami geus nerapkeun dua pendekatan has dipaké nalika nyieun tabel bantu:

• Ngalikeun rékaman
  Ngagunakeun hiji catetan pesen awal, urang nyieun sababaraha rékaman nurutan-up dina tipena béda registers pikeun boga béda - boh pikeun ngirim jeung panarima. Tapi unggal registers ayeuna ragrag kana indéks - sanggeus kabeh, dina kasus has, urang bakal hoyong ningali ngan kaca munggaran.
• rékaman unik
  Unggal-unggal anjeun ngirim pesen dina topik anu khusus, cukup pikeun pariksa naha éntri sapertos kitu parantos aya. Lamun henteu, tambahkeun kana "kamus" urang.

Dina bagian saterusna artikel urang bakal ngobrol ngeunaan palaksanaan partitioning kana struktur database urang.

sumber: www.habr.com