ປະຫຍັດເງິນໃນປະລິມານຂະຫນາດໃຫຍ່ໃນ PostgreSQL

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

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

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

ຄວາມລັບນ້ອຍໆຂອງຂໍ້ມູນໃຫຍ່

ໂດຍໂປຣໄຟລ໌ວຽກ ບໍລິການຂອງພວກເຮົາ, ພວກເຂົາເຈົ້າເປັນປົກກະຕິບິນໄປຫາພຣະອົງຈາກ lairs ໄດ້ ຊຸດຂໍ້ຄວາມ.

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

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

CREATE TABLE rawdata_orig(
  pack -- PK
    uuid NOT NULL
, recno -- PK
    smallint NOT NULL
, dt -- ключ секции
    date
, data -- самое главное
    text
, PRIMARY KEY(pack, recno)
);

ສັນຍາລັກປົກກະຕິ (ແມ່ນພາກສ່ວນແລ້ວ, ແນ່ນອນ, ດັ່ງນັ້ນນີ້ແມ່ນແມ່ແບບພາກ), ເຊິ່ງສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນຂໍ້ຄວາມ. ບາງຄັ້ງຂ້ອນຂ້າງ voluminous.

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

PostgreSQL ໃຊ້ຂະຫນາດຫນ້າຄົງທີ່ (ປົກກະຕິ 8 KB), ແລະບໍ່ອະນຸຍາດໃຫ້ tuples ຂະຫຍາຍຫຼາຍຫນ້າ. ດັ່ງນັ້ນ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເກັບຮັກສາຄ່າພາກສະຫນາມທີ່ມີຂະຫນາດໃຫຍ່ຫຼາຍໂດຍກົງ. ເພື່ອເອົາຊະນະຂໍ້ຈໍາກັດນີ້, ຄ່າພາກສະຫນາມຂະຫນາດໃຫຍ່ຖືກບີບອັດແລະ / ຫຼືແບ່ງອອກໃນທົ່ວສາຍທາງດ້ານຮ່າງກາຍຫຼາຍ. ນີ້ເກີດຂື້ນໂດຍຜູ້ໃຊ້ບໍ່ໄດ້ສັງເກດເຫັນແລະມີຜົນກະທົບເລັກນ້ອຍຕໍ່ລະຫັດເຊີຟເວີສ່ວນໃຫຍ່. ວິທີການນີ້ເອີ້ນວ່າ TOAST ...

ໃນຄວາມເປັນຈິງ, ສໍາລັບທຸກໆຕາຕະລາງທີ່ມີຊ່ອງຂໍ້ມູນ "ຂະຫນາດໃຫຍ່", ອັດຕະໂນມັດ ຕາຕະລາງຄູ່ກັບ "slicing" ແມ່ນຖືກສ້າງຂຶ້ນ ແຕ່ລະບັນທຶກ "ຂະຫນາດໃຫຍ່" ໃນ 2KB segments:

TOAST(
  chunk_id
    integer
, chunk_seq
    integer
, chunk_data
    bytea
, PRIMARY KEY(chunk_id, chunk_seq)
);

ນັ້ນແມ່ນ, ຖ້າພວກເຮົາຕ້ອງຂຽນຂໍ້ຄວາມທີ່ມີຄ່າ "ໃຫຍ່". data, ຫຼັງຈາກນັ້ນການບັນທຶກທີ່ແທ້ຈິງຈະເກີດຂຶ້ນ ບໍ່ພຽງແຕ່ຕາຕະລາງຕົ້ນຕໍແລະ PK ຂອງມັນ, ແຕ່ຍັງກັບ TOAST ແລະ PK ຂອງມັນ.

ການຫຼຸດຜ່ອນອິດທິພົນຂອງ TOAST

ແຕ່ບັນທຶກຂອງພວກເຮົາສ່ວນໃຫຍ່ຍັງບໍ່ໃຫຍ່ປານໃດ, ຄວນພໍດີກັບ 8KB - ຂ້ອຍສາມາດປະຫຍັດເງິນໄດ້ແນວໃດ? ..

ນີ້ແມ່ນບ່ອນທີ່ຄຸນລັກສະນະມາໃຫ້ການຊ່ວຍເຫຼືອຂອງພວກເຮົາ STORAGE ຢູ່ໃນຖັນຕາຕະລາງ:

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

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

ALTER TABLE rawdata_orig ALTER COLUMN data SET STORAGE MAIN;

ວິທີການປະເມີນຜົນກະທົບ

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

ພາກສ່ວນ ກ່ອນທີ່ຈະມີການປ່ຽນແປງ:

heap  = 37GB (39%)
TOAST = 54GB (57%)
PK    =  4GB ( 4%)

ພາກສ່ວນ ຫຼັງ​ຈາກ​ການ​ປ່ຽນ​ແປງ​:

heap  = 37GB (67%)
TOAST = 16GB (29%)
PK    =  2GB ( 4%)

ໃນຄວາມເປັນຈິງ, ພວກເຮົາ ເລີ່ມຂຽນໃສ່ TOAST ໜ້ອຍລົງ 2 ເທື່ອ, ເຊິ່ງ unloaded ບໍ່ພຽງແຕ່ແຜ່ນ, ແຕ່ຍັງ CPU ໄດ້:

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

ໃຜສາມາດດໍາລົງຊີວິດໄດ້ດີໃນ PostgreSQL 11

ຫຼັງ​ຈາກ​ການ​ປັບ​ປຸງ​ເປັນ PG11​, ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ສືບ​ຕໍ່ "ປັບ​" TOAST ແລະ​ສັງ​ເກດ​ເຫັນ​ວ່າ​ການ​ເລີ່ມ​ຕົ້ນ​ຈາກ​ສະ​ບັບ​ນີ້​ພາ​ລາ​ມິ​ເຕີ​ໄດ້​ມີ​ໃຫ້​ສໍາ​ລັບ​ການ​ປັບ toast_tuple_target:

ລະຫັດການປະມວນຜົນ TOAST ພຽງແຕ່ໄຟໄຫມ້ເມື່ອຄ່າແຖວທີ່ຈະເກັບໄວ້ໃນຕາຕະລາງໃຫຍ່ກວ່າ TOAST_TUPLE_THRESHOLD bytes (ປົກກະຕິ 2 KB). ລະຫັດ TOAST ຈະບີບອັດ ແລະ/ຫຼື ຍ້າຍຄ່າຊ່ອງຂໍ້ມູນອອກຈາກຕາຕະລາງຈົນກ່ວາຄ່າແຖວກາຍເປັນໜ້ອຍກວ່າ TOAST_TUPLE_TARGET bytes (ຄ່າຕົວແປ, ປົກກະຕິແມ່ນ 2 KB) ຫຼືຂະໜາດບໍ່ສາມາດຫຼຸດໄດ້.

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

ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);

ມາເບິ່ງວ່າການຕັ້ງຄ່າໃໝ່ສົ່ງຜົນກະທົບຕໍ່ການໂຫຼດແຜ່ນຫຼັງຈາກການຕັ້ງຄ່າຄືນໃໝ່ແນວໃດ:

ບໍ່ດີ! ສະເລ່ຍ ແຖວໄປຫາແຜ່ນໄດ້ຫຼຸດລົງ ປະມານ 1.5 ເທື່ອ, ແລະແຜ່ນ “ບໍ່ຫວ່າງ” ແມ່ນ 20 ເປີເຊັນ! ແຕ່ບາງທີນີ້ອາດຈະສົ່ງຜົນກະທົບຕໍ່ CPU ບໍ?

ຢ່າງຫນ້ອຍມັນບໍ່ຮ້າຍແຮງກວ່າເກົ່າ. ເຖິງແມ່ນວ່າ, ມັນເປັນການຍາກທີ່ຈະຕັດສິນວ່າເຖິງແມ່ນວ່າປະລິມານດັ່ງກ່າວຍັງບໍ່ສາມາດເພີ່ມການໂຫຼດ CPU ໂດຍສະເລ່ຍສູງຂຶ້ນ 5%.

ໂດຍການປ່ຽນແປງສະຖານທີ່ຂອງຂໍ້ກໍານົດ, ຜົນລວມ ... ປ່ຽນແປງ!

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

ເນື່ອງຈາກວ່າ ການຈັດຮຽງຂໍ້ມູນ ນີ້ແມ່ນກົງໄປກົງມາ ຜົນກະທົບຕໍ່ປະລິມານຜົນໄດ້ຮັບ:

ສະຖາປັດຕະຍະກໍາຈໍານວນຫຼາຍສະຫນອງການຈັດລໍາດັບຂໍ້ມູນໃນຂອບເຂດຄໍາສັບຂອງເຄື່ອງຈັກ. ຕົວຢ່າງ, ໃນລະບົບ 32-bit x86, integers (integer type, 4 bytes) ຈະຖືກຈັດໃສ່ໃນຂອບເຂດຂອງຄໍາ 4-byte, ຄືກັນກັບຈະ double precision floating point (double precision floating point, 8 bytes). ແລະໃນລະບົບ 64-bit, ຄ່າສອງເທົ່າຈະຖືກສອດຄ່ອງກັບຂອບເຂດຄໍາສັບ 8-byte. ນີ້ແມ່ນເຫດຜົນອື່ນສໍາລັບການບໍ່ເຂົ້າກັນໄດ້.

ເນື່ອງຈາກການຈັດຮຽງ, ຂະໜາດຂອງແຖວຕາຕະລາງແມ່ນຂຶ້ນກັບລຳດັບຂອງຊ່ອງຂໍ້ມູນ. ປົກກະຕິແລ້ວຜົນກະທົບນີ້ແມ່ນບໍ່ສັງເກດເຫັນຫຼາຍ, ແຕ່ໃນບາງກໍລະນີມັນສາມາດນໍາໄປສູ່ການເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍໃນຂະຫນາດ. ຕົວຢ່າງ, ຖ້າເຈົ້າປະສົມ char(1) ແລະ integer fields, ໂດຍປົກກະຕິຈະມີ 3 bytes ເສຍໄປລະຫວ່າງພວກມັນ.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຕົວແບບສັງເຄາະ:

SELECT pg_column_size(ROW(
  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
, '2019-01-01'::date
));
-- 48 байт

SELECT pg_column_size(ROW(
  '2019-01-01'::date
, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
));
-- 46 байт

ສອງສາມ bytes ພິເສດມາຈາກໃສໃນກໍລະນີທໍາອິດ? ມັນ​ເປັນ​ງ່າຍ​ດາຍ - ຂະໜາດນ້ອຍ 2-byte ຈັດຮຽງຢູ່ໃນຂອບເຂດ 4-byte ກ່ອນທີ່ຈະພາກສະຫນາມຕໍ່ໄປ, ແລະໃນເວລາທີ່ມັນເປັນອັນສຸດທ້າຍ, ບໍ່ມີຫຍັງແລະບໍ່ຈໍາເປັນຕ້ອງສອດຄ່ອງ.

ໃນທາງທິດສະດີ, ທຸກສິ່ງທຸກຢ່າງແມ່ນດີແລະທ່ານສາມາດຈັດແຈງທົ່ງນາຄືນໃຫມ່ຕາມທີ່ທ່ານຕ້ອງການ. ໃຫ້ກວດເບິ່ງມັນຢູ່ໃນຂໍ້ມູນທີ່ແທ້ຈິງໂດຍໃຊ້ຕົວຢ່າງຂອງຕາຕະລາງຫນຶ່ງ, ສ່ວນປະຈໍາວັນທີ່ຄອບຄອງ 10-15GB.

ໂຄງສ້າງເບື້ອງຕົ້ນ:

CREATE TABLE public.plan_20190220
(
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  dt date,
  CONSTRAINT plan_20190220_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190220_dt_check CHECK (dt = '2019-02-20'::date)
)
INHERITS (public.plan)

ພາກສ່ວນຫຼັງຈາກການປ່ຽນແປງລໍາດັບຖັນ - ແທ້ ທົ່ງນາດຽວກັນ, ພຽງແຕ່ຄໍາສັ່ງທີ່ແຕກຕ່າງກັນ:

CREATE TABLE public.plan_20190221
(
-- Унаследована from table plan:  dt date NOT NULL,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
  CONSTRAINT plan_20190221_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190221_dt_check CHECK (dt = '2019-02-21'::date)
)
INHERITS (public.plan)

ປະລິມານທັງຫມົດຂອງພາກແມ່ນຖືກກໍານົດໂດຍຈໍານວນຂອງ "ຂໍ້ເທັດຈິງ" ແລະຂຶ້ນກັບພຽງແຕ່ຂະບວນການພາຍນອກ, ສະນັ້ນໃຫ້ພວກເຮົາແບ່ງຂະຫນາດຂອງ heap ໄດ້ (pg_relation_size) ໂດຍຈໍານວນຂອງບັນທຶກໃນມັນ - ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ຮັບ ຂະຫນາດສະເລ່ຍຂອງການບັນທຶກຕົວຈິງ:

ລົບ 6%., ຍິ່ງໃຫຍ່!

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

...ຍັງຢູ່ທີ່ນີ້ຄືກັນ ບັນທຶກ 1.5%ໂດຍບໍ່ມີການປ່ຽນເສັ້ນດຽວຂອງລະຫັດ. ແມ່ນແລ້ວ!

ຂ້າພະເຈົ້າສັງເກດວ່າທາງເລືອກຂ້າງເທິງສໍາລັບການຈັດແຈງພື້ນທີ່ບໍ່ແມ່ນຄວາມຈິງທີ່ວ່າມັນແມ່ນດີທີ່ສຸດ. ເພາະວ່າເຈົ້າບໍ່ຕ້ອງການ "ຈີກ" ບາງພື້ນທີ່ຂອງທົ່ງນາດ້ວຍເຫດຜົນດ້ານຄວາມງາມ - ຕົວຢ່າງ, ຄູ່ຜົວເມຍ. (pack, recno), ຊຶ່ງເປັນ PK ສໍາລັບຕາຕະລາງນີ້.

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

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