ຖານຂໍ້ມູນ Messenger (ສ່ວນ 1): ການອອກແບບກອບພື້ນຖານ

ວິທີທີ່ທ່ານສາມາດແປຄວາມຕ້ອງການຂອງທຸລະກິດເຂົ້າໄປໃນໂຄງສ້າງຂໍ້ມູນສະເພາະໂດຍໃຊ້ຕົວຢ່າງຂອງການອອກແບບຖານຂໍ້ມູນ messenger ຈາກ scratch.

• ສ່ວນທີ 1: ການອອກແບບກອບພື້ນຖານ
• ພາກ​ທີ 2​: ພາກ​ສ່ວນ "ເພື່ອ​ຜົນ​ກໍາ​ໄລ​"

ພື້ນຖານຂອງພວກເຮົາຈະບໍ່ຂະຫນາດໃຫຍ່ແລະແຈກຢາຍ, ຄືກັບ VKontakte ຫຼື Badoo, ແຕ່ "ດັ່ງນັ້ນມັນແມ່ນ", ແຕ່ມັນດີ - ມີປະໂຫຍດ, ໄວແລະ ເຫມາະກັບເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ PostgreSQL - ເພື່ອໃຫ້ທ່ານສາມາດປະຕິບັດຕົວຢ່າງແຍກຕ່າງຫາກຂອງການບໍລິການຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ສໍາລັບການຍົກຕົວຢ່າງ.

ດັ່ງນັ້ນ, ພວກເຮົາຈະບໍ່ສໍາຜັດກັບບັນຫາຂອງ sharding, replication ແລະ geo-distributed ລະບົບ, ແຕ່ຈະສຸມໃສ່ການແກ້ໄຂວົງຈອນພາຍໃນຖານຂໍ້ມູນ.

ຂັ້ນຕອນທີ 1: ບາງທຸລະກິດສະເພາະ

ພວກເຮົາຈະບໍ່ອອກແບບການສົ່ງຂໍ້ຄວາມຂອງພວກເຮົາແບບບໍ່ມີຕົວຕົນ, ແຕ່ຈະປະສົມປະສານມັນເຂົ້າໃນສະພາບແວດລ້ອມ ເຄືອຂ່າຍສັງຄົມຂອງບໍລິສັດ. ນັ້ນແມ່ນ, ປະຊາຊົນຂອງພວກເຮົາບໍ່ພຽງແຕ່ "ຕອບສະຫນອງ", ແຕ່ຕິດຕໍ່ສື່ສານກັບກັນແລະກັນໃນສະພາບການແກ້ໄຂບັນຫາທຸລະກິດບາງຢ່າງ.

ແລະວຽກງານຂອງທຸລະກິດແມ່ນຫຍັງ?.. ລອງເບິ່ງຕົວຢ່າງຂອງ Vasily, ຫົວໜ້າພະແນກພັດທະນາ.

• "Nikolai, ສໍາລັບວຽກງານນີ້ພວກເຮົາຕ້ອງການ patch ໃນມື້ນີ້!"
  ນີ້ຫມາຍຄວາມວ່າການຕິດຕໍ່ພົວພັນສາມາດດໍາເນີນການໃນສະພາບການຂອງບາງ ເອກະສານ.
• "Kolya, ເຈົ້າຈະໄປ Dota ຕອນແລງນີ້ບໍ?"
  ນັ້ນແມ່ນ, ເຖິງແມ່ນວ່າຄູ່ interlocutors ສາມາດສື່ສານພ້ອມກັນໄດ້ ໃນ​ຫົວ​ຂໍ້​ຕ່າງໆ​.
• "Peter, Nikolay, ເບິ່ງໃນເອກະສານຄັດຕິດສໍາລັບລາຍການລາຄາສໍາລັບເຄື່ອງແມ່ຂ່າຍໃຫມ່."
  ດັ່ງນັ້ນ, ຂໍ້ຄວາມຫນຶ່ງສາມາດມີ ຜູ້​ຮັບ​ຈໍາ​ນວນ​ຫນຶ່ງ​. ໃນກໍລະນີນີ້, ຂໍ້ຄວາມອາດມີ ໄຟລ໌ແນບ.
• "Semyon, ເບິ່ງຄືກັນ."
  ແລະຄວນຈະມີໂອກາດທີ່ຈະເຂົ້າໄປໃນຈົດຫມາຍສະບັບທີ່ມີຢູ່ແລ້ວ ເຊີນສະມາຊິກໃໝ່.

ຂໍໃຫ້ຢູ່ໃນບັນຊີລາຍຊື່ຂອງຄວາມຕ້ອງການ "ຈະແຈ້ງ" ໃນເວລານີ້.

ໂດຍບໍ່ມີການເຂົ້າໃຈສະເພາະການນໍາໃຊ້ຂອງບັນຫາແລະຂໍ້ຈໍາກັດທີ່ໃຫ້ມັນ, ການອອກແບບ ມີປະສິດທິພາບ schema ຖານຂໍ້ມູນເພື່ອແກ້ໄຂມັນເກືອບເປັນໄປບໍ່ໄດ້.

ຂັ້ນຕອນທີ 2: ວົງຈອນຕາມເຫດຜົນໜ້ອຍທີ່ສຸດ

ມາຮອດປັດຈຸບັນ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຄ້າຍຄືກັນກັບການຕອບອີເມວ - ເຄື່ອງມືທຸລະກິດແບບດັ້ງເດີມ. ແມ່ນແລ້ວ, "ສູດການຄິດໄລ່" ບັນຫາທຸລະກິດຫຼາຍແມ່ນຄ້າຍຄືກັນກັບກັນແລະກັນ, ດັ່ງນັ້ນເຄື່ອງມືສໍາລັບການແກ້ໄຂບັນຫາຈະຄ້າຍຄືກັນກັບໂຄງສ້າງ.

ໃຫ້ແກ້ໄຂແຜນວາດຢ່າງມີເຫດຜົນຂອງຄວາມສຳພັນຂອງນິຕິບຸກຄົນ. ເພື່ອເຮັດໃຫ້ແບບຈໍາລອງຂອງພວກເຮົາເຂົ້າໃຈງ່າຍຂຶ້ນ, ພວກເຮົາຈະໃຊ້ຕົວເລືອກການສະແດງຜົນເບື້ອງຕົ້ນທີ່ສຸດ ແບບ ER ໂດຍບໍ່ມີອາການແຊກຊ້ອນຂອງ UML ຫຼື IDEF notations:

ໃນຕົວຢ່າງຂອງພວກເຮົາ, ບຸກຄົນ, ເອກະສານແລະສອງ "ຮ່າງກາຍ" ຂອງໄຟລ໌ແມ່ນ "ພາຍນອກ" ຫນ່ວຍງານທີ່ມີເອກະລາດໂດຍບໍ່ມີການໃຫ້ບໍລິການຂອງພວກເຮົາ. ດັ່ງນັ້ນ, ພວກເຮົາພຽງແຕ່ຈະຮັບຮູ້ພວກມັນໃນອະນາຄົດເປັນບາງການເຊື່ອມຕໍ່ "ບາງບ່ອນ" ໂດຍ UUID.

ແຕ້ມ ແຜນວາດທີ່ງ່າຍດາຍເທົ່າທີ່ເປັນໄປໄດ້ - ຄົນສ່ວນໃຫຍ່ທີ່ເຈົ້າຈະສະແດງໃຫ້ເຂົາເຈົ້າບໍ່ແມ່ນຜູ້ຊ່ຽວຊານໃນການອ່ານ UML/IDEF. ແຕ່ໃຫ້ແນ່ໃຈວ່າແຕ້ມ.

ຂັ້ນຕອນທີ 3: ການແຕ້ມໂຄງສ້າງຕາຕະລາງ

ກ່ຽວກັບຕາຕະລາງແລະຊື່ພາກສະຫນາມຊື່ "ພາສາລັດເຊຍ" ຂອງທົ່ງນາແລະຕາຕະລາງສາມາດປະຕິບັດແຕກຕ່າງກັນ, ແຕ່ນີ້ແມ່ນເລື່ອງຂອງລົດຊາດ. ເນື່ອງຈາກວ່າ ທີ່ນີ້ທີ່ Tensor ບໍ່ມີນັກພັດທະນາຕ່າງປະເທດ, ແລະ PostgreSQL ອະນຸຍາດໃຫ້ພວກເຮົາຕັ້ງຊື່ເຖິງແມ່ນວ່າໃນ hieroglyphs, ຖ້າພວກເຂົາ ຫຸ້ມຢູ່ໃນວົງຢືມຫຼັງຈາກນັ້ນ, ພວກເຮົາມັກຕັ້ງຊື່ວັດຖຸຢ່າງບໍ່ຊັດເຈນ ແລະຊັດເຈນເພື່ອບໍ່ໃຫ້ມີຄວາມແຕກຕ່າງ.
ເນື່ອງຈາກຫຼາຍຄົນຂຽນຂໍ້ຄວາມຫາພວກເຮົາໃນຄັ້ງດຽວ, ບາງຄົນກໍ່ອາດຈະເຮັດແບບນີ້ ອອບໄລນ໌, ຫຼັງຈາກນັ້ນທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນ ໃຊ້ UUIDs ເປັນຕົວລະບຸ ບໍ່ພຽງແຕ່ສໍາລັບຫນ່ວຍງານພາຍນອກ, ແຕ່ຍັງສໍາລັບວັດຖຸທັງຫມົດທີ່ຢູ່ໃນການບໍລິການຂອງພວກເຮົາ. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຂົາສາມາດສ້າງໄດ້ເຖິງແມ່ນວ່າຢູ່ໃນຝ່າຍລູກຄ້າ - ນີ້ຈະຊ່ວຍໃຫ້ພວກເຮົາສະຫນັບສະຫນູນການສົ່ງຂໍ້ຄວາມໃນເວລາທີ່ຖານຂໍ້ມູນບໍ່ສາມາດໃຊ້ໄດ້ຊົ່ວຄາວ, ແລະຄວາມເປັນໄປໄດ້ຂອງການປະທະກັນແມ່ນຕໍ່າທີ່ສຸດ.

ໂຄງສ້າງຕາຕະລາງຮ່າງໃນຖານຂໍ້ມູນຂອງພວກເຮົາຈະມີລັກສະນະນີ້:
ຕາຕະລາງ: 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
);

ຕາຕະລາງ: 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
);

ສິ່ງທີ່ງ່າຍດາຍທີ່ສຸດໃນເວລາທີ່ອະທິບາຍຮູບແບບແມ່ນເພື່ອເລີ່ມຕົ້ນ "unwinding" ເສັ້ນສະແດງການເຊື່ອມຕໍ່ ຈາກຕາຕະລາງທີ່ບໍ່ໄດ້ອ້າງອີງ ດ້ວຍ​ຕົນ​ເອງ​ເພື່ອ​ບໍ່​ມີ​ໃຜ.

ຂັ້ນຕອນທີ 4: ຊອກຫາຄວາມຕ້ອງການທີ່ບໍ່ຊັດເຈນ

ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ອອກແບບຖານຂໍ້ມູນທີ່ທ່ານສາມາດຂຽນຢ່າງສົມບູນແລະ ບາງຢ່າງ ອ່ານ.

ໃຫ້ເຮົາໃສ່ເກີບຂອງຜູ້ໃຊ້ບໍລິການຂອງພວກເຮົາ - ພວກເຮົາຕ້ອງການເຮັດແນວໃດກັບມັນ?

• ຂໍ້ຄວາມສຸດທ້າຍ
  ນີ້ ຈັດຮຽງຕາມລຳດັບ ການລົງທະບຽນຂໍ້ຄວາມ "ຂອງຂ້ອຍ" ໂດຍອີງໃສ່ເງື່ອນໄຂຕ່າງໆ. ບ່ອນທີ່ຂ້ອຍເປັນຫນຶ່ງໃນຜູ້ຮັບ, ບ່ອນທີ່ຂ້ອຍເປັນຜູ້ຂຽນ, ບ່ອນທີ່ພວກເຂົາຂຽນຫາຂ້ອຍແລະຂ້ອຍບໍ່ໄດ້ຕອບ, ບ່ອນທີ່ພວກເຂົາບໍ່ຕອບຂ້ອຍ, ...
• ຜູ້ເຂົ້າຮ່ວມການຕອບໂຕ້
  ແມ່ນແຕ່ໃຜເຂົ້າຮ່ວມໃນການສົນທະນາທີ່ຍາວນານນີ້?

ໂຄງສ້າງຂອງພວກເຮົາອະນຸຍາດໃຫ້ພວກເຮົາແກ້ໄຂບັນຫາເຫຼົ່ານີ້ທັງສອງ "ໂດຍທົ່ວໄປ," ແຕ່ບໍ່ແມ່ນໄວ. ບັນຫາແມ່ນວ່າສໍາລັບການຈັດລຽງພາຍໃນວຽກງານທໍາອິດ ບໍ່ສາມາດສ້າງດັດສະນີໄດ້, ທີ່ເຫມາະສົມສໍາລັບແຕ່ລະຄົນຂອງຜູ້ເຂົ້າຮ່ວມ (ແລະທ່ານຈະຕ້ອງໄດ້ສະກັດບັນທຶກທັງຫມົດ), ແລະແກ້ໄຂອັນທີສອງທີ່ທ່ານຕ້ອງການ. ສະກັດຂໍ້ຄວາມທັງຫມົດ ກ່ຽວກັບຫົວຂໍ້ນີ້.

ວຽກງານຂອງຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ຕັ້ງໃຈອາດຈະເຮັດໃຫ້ກ້າຫານ ຂ້າມ​ກັບ​ການ​ຜະ​ລິດ​ຕະ​ພັນ​.

ຂັ້ນຕອນທີ 5: Smart Denormalization

ທັງສອງບັນຫາຂອງພວກເຮົາຈະຖືກແກ້ໄຂໂດຍຕາຕະລາງເພີ່ມເຕີມທີ່ພວກເຮົາຈະ ຊ້ໍາກັນສ່ວນຫນຶ່ງຂອງຂໍ້ມູນ, ມີຄວາມຈໍາເປັນທີ່ຈະປະກອບເປັນຕົວຊີ້ວັດທີ່ເຫມາະສົມສໍາລັບວຽກງານຂອງພວກເຮົາ.


ຕາຕະລາງ: RU

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

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

ຕາຕະລາງ: 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)
);

ໃນ​ທີ່​ນີ້​ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ສອງ​ວິ​ທີ​ການ​ປົກ​ກະ​ຕິ​ທີ່​ໃຊ້​ໃນ​ການ​ສ້າງ​ຕາ​ຕະ​ລາງ​ຊ່ວຍ​:

• ການຄູນບັນທຶກ
  ການນໍາໃຊ້ບັນທຶກຂໍ້ຄວາມເບື້ອງຕົ້ນຫນຶ່ງ, ພວກເຮົາສ້າງບັນທຶກການຕິດຕາມຫຼາຍໆຄັ້ງໃນປະເພດທີ່ແຕກຕ່າງກັນຂອງການລົງທະບຽນສໍາລັບເຈົ້າຂອງທີ່ແຕກຕ່າງກັນ - ທັງສໍາລັບຜູ້ສົ່ງແລະຜູ້ຮັບ. ແຕ່ແຕ່ລະທະບຽນໃນປັດຈຸບັນຕົກຢູ່ໃນດັດຊະນີ - ຫຼັງຈາກທີ່ທັງຫມົດ, ໃນກໍລະນີປົກກະຕິ, ພວກເຮົາຈະຕ້ອງການເບິ່ງພຽງແຕ່ຫນ້າທໍາອິດ.
• ບັນທຶກທີ່ເປັນເອກະລັກ
  ທຸກໆຄັ້ງທີ່ທ່ານສົ່ງຂໍ້ຄວາມພາຍໃນຫົວຂໍ້ສະເພາະ, ມັນພຽງພໍທີ່ຈະກວດເບິ່ງວ່າລາຍການດັ່ງກ່າວມີຢູ່ແລ້ວ. ຖ້າບໍ່, ເພີ່ມມັນໃສ່ "ວັດຈະນານຸກົມ" ຂອງພວກເຮົາ.

ໃນສ່ວນຕໍ່ໄປຂອງບົດຄວາມພວກເຮົາຈະສົນທະນາກ່ຽວກັບ ການ​ປະ​ຕິ​ບັດ​ການ​ແບ່ງ​ປັນ​ ເຂົ້າໄປໃນໂຄງສ້າງຂອງຖານຂໍ້ມູນຂອງພວກເຮົາ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com