ຖານຂໍ້ມູນ Messenger (ສ່ວນ 2): ການແບ່ງສ່ວນ “ເພື່ອຜົນກໍາໄລ”

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

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

ຄວາມຈິງແມ່ນວ່າ ເມື່ອຂະຫນາດຕາຕະລາງເພີ່ມຂຶ້ນ, "ຄວາມເລິກ" ຂອງດັດຊະນີ. - ແມ້​ກະ​ທັ້ງ logarithm​. ແຕ່ເມື່ອເວລາຜ່ານໄປ, ນີ້ບັງຄັບໃຫ້ເຄື່ອງແມ່ຂ່າຍປະຕິບັດຫນ້າທີ່ອ່ານ / ຂຽນດຽວກັນ ປະມວນຜົນຂໍ້ມູນຫຼາຍເທື່ອຫຼາຍໜ້າກ່ວາໃນຕອນເລີ່ມຕົ້ນ.

ນີ້ແມ່ນບ່ອນທີ່ມັນມາກັບກູ້ໄພ ພາກສ່ວນ.

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

ພວກເຮົາຈະພິຈາລະນາບໍ່ແມ່ນສະຄິບສະເພາະສໍາລັບການປະຕິບັດການແບ່ງສ່ວນ "ໃນຮາດແວ", ແຕ່ວິທີການຂອງມັນເອງ - ສິ່ງທີ່ຄວນ "ຕັດເປັນຕ່ອນ", ແລະສິ່ງທີ່ຄວາມປາຖະຫນາດັ່ງກ່າວນໍາໄປສູ່.

ແນວຄວາມຄິດ

ຂໍໃຫ້ກໍານົດເປົ້າຫມາຍຂອງພວກເຮົາອີກເທື່ອຫນຶ່ງ: ພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າມື້ນີ້, ມື້ອື່ນ, ແລະໃນປີຫນຶ່ງ, ຈໍານວນຂໍ້ມູນທີ່ອ່ານໂດຍ PostgreSQL ໃນລະຫວ່າງການດໍາເນີນການອ່ານ / ຂຽນໃດໆຍັງຄົງຢູ່ປະມານດຽວກັນ.

ສໍາລັບການໃດໆ ຂໍ້ມູນສະສົມຕາມລຳດັບ (ຂໍ້​ຄວາມ, ເອ​ກະ​ສານ, ຂໍ້​ມູນ​ບັນ​ທຶກ, ຮວບ​ຮວມ, ... ) ທາງ​ເລືອກ​ທໍາ​ມະ​ຊາດ​ເປັນ​ທີ່​ສໍາ​ຄັນ​ການ​ແບ່ງ​ປັນ​ແມ່ນ​ ວັນທີ/ເວລາເຫດການ. ໃນກໍລະນີຂອງພວກເຮົາ, ເຫດການດັ່ງກ່າວແມ່ນ ປັດ​ຈຸ​ບັນ​ຂອງ​ການ​ສົ່ງ​ຂໍ້​ຄວາມ​.

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

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

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

ບາດກ້າວໂດຍຂັ້ນຕອນ

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

ຂໍ້ຄວາມ, ຄຸນສົມບັດແລະການຄາດຄະເນຂອງມັນ

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

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

ພວກເຮົາເພີ່ມລະຫັດການແບ່ງສ່ວນ (ວັນທີຂໍ້ຄວາມ) ໃນຕາຕະລາງທັງຫມົດ: ຜູ້ຮັບ, ໄຟລ໌, ທະບຽນ. ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງເພີ່ມມັນໃສ່ຂໍ້ຄວາມຂອງມັນເອງ, ແຕ່ໃຊ້ DateTime ທີ່ມີຢູ່.

ກະທູ້

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

ເພີ່ມການແບ່ງສ່ວນທີ່ສໍາຄັນ (ວັນທີຫົວຂໍ້) ກັບຕາຕະລາງທັງຫມົດ: ຫົວຂໍ້, ຜູ້ເຂົ້າຮ່ວມ.

ແຕ່ດຽວນີ້ພວກເຮົາມີສອງບັນຫາໃນເວລາດຽວກັນ:

• ຂ້ອຍຄວນຊອກຫາຂໍ້ຄວາມໃນຫົວຂໍ້ໃດ?
• ຂ້ອຍຄວນຊອກຫາຫົວຂໍ້ໃດຈາກຂໍ້ຄວາມ?

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

• ພວກເຮົາຈະເພີ່ມໃນຂໍ້ຄວາມ ຊ່ອງໃສ່ວັນທີຫົວຂໍ້
• ໃຫ້ເຮົາຕື່ມໃສ່ຫົວຂໍ້ ຕັ້ງວັນທີຂໍ້ຄວາມ ຈົດຫມາຍສະບັບນີ້ (ສາມາດເປັນຕາຕະລາງແຍກຕ່າງຫາກ, ຫຼື array ຂອງວັນທີ)

ເນື່ອງຈາກຈະມີການດັດແກ້ຈໍານວນຫນ້ອຍກ່ຽວກັບບັນຊີລາຍຊື່ຂອງວັນທີຂໍ້ຄວາມສໍາລັບແຕ່ລະຈົດຫມາຍສ່ວນບຸກຄົນ (ຫຼັງຈາກທັງຫມົດ, ຂໍ້ຄວາມເກືອບທັງຫມົດຕົກຢູ່ໃນ 1-2 ມື້ຕິດກັນ), ຂ້າພະເຈົ້າຈະສຸມໃສ່ທາງເລືອກນີ້.

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

ຕາຕະລາງ: RU, ຖ້າທ່ານມີຄວາມກຽດຊັງກັບຕົວອັກສອນ Cyrillic ໃນຊື່ຂອງຕາຕະລາງ / ຊ່ອງ, ມັນດີກວ່າທີ່ຈະບໍ່ເບິ່ງ.

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

ປະຫຍັດເງິນຫຼາຍ

ແລ້ວ, ຖ້າພວກເຮົາບໍ່ໃຊ້ ທາງ​ເລືອກ​ພາກ​ສ່ວນ​ຄລາ​ສ​ສິກ​ ໂດຍອີງໃສ່ການແຈກຢາຍຄ່າພາກສະຫນາມ (ຜ່ານ triggers ແລະ inheritance ຫຼື PARTITION BY), ແລະ "ຄູ່ມື" ໃນລະດັບຄໍາຮ້ອງສະຫມັກ, ທ່ານຈະສັງເກດເຫັນວ່າມູນຄ່າຂອງ partitioning key ໄດ້ຖືກເກັບໄວ້ໃນຊື່ຂອງຕາຕະລາງຕົວມັນເອງ.

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

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