ສິ່ງທີ່ແລະເປັນຫຍັງພວກເຮົາເຮັດໃນຖານຂໍ້ມູນ Open Source. Andrey Borodin (Yandex.Cloud)

ການປະກອບສ່ວນຂອງ Yandex ກັບຖານຂໍ້ມູນຕໍ່ໄປນີ້ຈະຖືກທົບທວນຄືນ.

• ກົດປຸ່ມ
• Odyssey
• ການ​ຟື້ນ​ຕົວ​ເຖິງ​ຈຸດ​ໃນ​ເວ​ລາ (WAL-G​)
• PostgreSQL (ລວມທັງ logerrors, Amcheck, heapcheck)
• ສີຂຽວພຸ່ມ

ວິດີໂອ:

ສະ​ບາຍ​ດີ​ຊາວ​ໂລກ! ຂ້ອຍຊື່ Andrey Borodin. ແລະສິ່ງທີ່ຂ້ອຍເຮັດຢູ່ Yandex.Cloud ແມ່ນການພັດທະນາຖານຂໍ້ມູນຄວາມສໍາພັນທີ່ເປີດຢູ່ໃນຜົນປະໂຫຍດຂອງລູກຄ້າ Yandex.Cloud ແລະ Yandex.Cloud.

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

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

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

ມີວິທີການໃດແດ່ໃນການເຮັດວຽກກ່ຽວກັບຊອບແວແຫຼ່ງເປີດ?

• ວິທີການທີ່ກົງໄປກົງມາທີ່ສຸດແມ່ນການນໍາໃຊ້ຊອບແວ. ຖ້າທ່ານໃຊ້ໂປໂຕຄອນ, ຖ້າທ່ານໃຊ້ມາດຕະຖານ, ຖ້າທ່ານໃຊ້ຮູບແບບ, ຖ້າທ່ານຂຽນຄໍາຖາມໃນຊໍແວແຫຼ່ງເປີດ, ຫຼັງຈາກນັ້ນທ່ານສະຫນັບສະຫນູນມັນແລ້ວ.
• ທ່ານກຳລັງເຮັດໃຫ້ລະບົບນິເວດຂອງມັນໃຫຍ່ຂຶ້ນ. ທ່ານເຮັດໃຫ້ຄວາມເປັນໄປໄດ້ຂອງການກວດຫາແມງໄມ້ໄດ້ໄວຂຶ້ນ. ທ່ານເພີ່ມຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບນີ້. ທ່ານເພີ່ມຄວາມພ້ອມຂອງນັກພັດທະນາໃນຕະຫຼາດ. ທ່ານປັບປຸງຊອບແວນີ້. ເຈົ້າເປັນຜູ້ປະກອບສ່ວນຢູ່ແລ້ວ ຖ້າເຈົ້າຫາກໍ່ເຮັດແບບ ແລະ ຫຼົງໄຫຼກັບສິ່ງທີ່ຢູ່ນັ້ນ.
• ອີກວິທີໜຶ່ງທີ່ເຂົ້າໃຈໄດ້ແມ່ນການສະໜັບສະໜູນຊອບແວແຫຼ່ງເປີດ. ຕົວຢ່າງ, ໂຄງການ Google Summer of Code ທີ່ມີຊື່ສຽງ, ເມື່ອ Google ຈ່າຍເງິນຈໍານວນຫຼວງຫຼາຍຂອງນັກຮຽນຈາກທົ່ວໂລກທີ່ເຂົ້າໃຈໄດ້ເພື່ອໃຫ້ພວກເຂົາພັດທະນາໂຄງການຊອບແວທີ່ເປີດທີ່ຕອບສະຫນອງຄວາມຕ້ອງການໃບອະນຸຍາດທີ່ແນ່ນອນ.
• ນີ້ແມ່ນວິທີການທີ່ຫນ້າສົນໃຈຫຼາຍເພາະວ່າມັນຊ່ວຍໃຫ້ຊອບແວພັດທະນາໂດຍບໍ່ມີການປ່ຽນຈຸດສຸມອອກຈາກຊຸມຊົນ. Google, ເປັນຍັກໃຫຍ່ດ້ານເຕັກໂນໂລຢີ, ບໍ່ໄດ້ເວົ້າວ່າພວກເຮົາຕ້ອງການຄຸນສົມບັດນີ້, ພວກເຮົາຕ້ອງການແກ້ໄຂຂໍ້ບົກພ່ອງນີ້ແລະນີ້ແມ່ນບ່ອນທີ່ພວກເຮົາຕ້ອງການຂຸດ. Google ເວົ້າວ່າ: “ເຮັດໃນສິ່ງທີ່ເຈົ້າເຮັດ. ພຽງ​ແຕ່​ເຮັດ​ຕາມ​ແບບ​ທີ່​ເຈົ້າ​ໄດ້​ເຮັດ​ແລ້ວ​ແລະ​ທຸກ​ຢ່າງ​ຈະ​ດີ.”
• ວິທີການຕໍ່ໄປໃນການເຂົ້າຮ່ວມໃນແຫຼ່ງເປີດແມ່ນການມີສ່ວນຮ່ວມ. ໃນເວລາທີ່ທ່ານມີບັນຫາໃນຊອບແວແຫຼ່ງເປີດແລະມີນັກພັດທະນາ, ນັກພັດທະນາຂອງທ່ານເລີ່ມແກ້ໄຂບັນຫາ. ພວກເຂົາເລີ່ມເຮັດໃຫ້ໂຄງສ້າງພື້ນຖານຂອງທ່ານມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ໂຄງການຂອງທ່ານໄວຂຶ້ນແລະເຊື່ອຖືໄດ້ຫຼາຍຂຶ້ນ.

ຫນຶ່ງໃນໂຄງການ Yandex ທີ່ມີຊື່ສຽງທີ່ສຸດໃນຂົງເຂດຊອບແວແຫຼ່ງເປີດແມ່ນ ClickHouse. ນີ້ແມ່ນຖານຂໍ້ມູນທີ່ເກີດມາເປັນການຕອບສະຫນອງຕໍ່ສິ່ງທ້າທາຍທີ່ກໍາລັງປະເຊີນກັບ Yandex.Metrica.

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

ໃນ Yandex.Cloud, ພວກເຮົາໄດ້ສ້າງ ClickHouse ຢູ່ເທິງສຸດຂອງ Yandex Object Storage, i.e. ຢູ່ເທິງສຸດຂອງການເກັບຮັກສາຟັງ.

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

ມັນສາມາດເຮັດໄດ້ແນວໃດ? ນີ້ແມ່ນຈຸດສໍາຄັນໃນບົດລາຍງານນີ້.

• ພວກເຮົາສາມາດປະຕິບັດ ClickHouse ໃນໄລຍະ MDS. MDS ເປັນການໂຕ້ຕອບການເກັບຮັກສາຟັງ Yandex ພາຍໃນ. ມັນມີຄວາມຊັບຊ້ອນຫຼາຍກ່ວາອະນຸສັນຍາ S3 ທົ່ວໄປ, ແຕ່ວ່າມັນແມ່ນເຫມາະສົມສໍາລັບອຸປະກອນຕັນ. ມັນດີກວ່າສໍາລັບການບັນທຶກຂໍ້ມູນ. ມັນຮຽກຮ້ອງໃຫ້ມີການຂຽນໂປລແກລມຫຼາຍຂຶ້ນ. ນັກຂຽນໂປລແກລມຈະຂຽນໂປລແກລມ, ມັນດີ, ມັນຫນ້າສົນໃຈ.
• S3 ແມ່ນວິທີການທົ່ວໄປຫຼາຍທີ່ເຮັດໃຫ້ການໂຕ້ຕອບງ່າຍດາຍໃນຄ່າໃຊ້ຈ່າຍຂອງການປັບຕົວຫນ້ອຍລົງກັບບາງປະເພດຂອງວຽກ.

ຕາມທໍາມະຊາດ, ຕ້ອງການທີ່ຈະສະຫນອງການທໍາງານຂອງລະບົບນິເວດ ClickHouse ທັງຫມົດແລະເຮັດວຽກທີ່ຈໍາເປັນພາຍໃນ Yandex.Cloud, ພວກເຮົາຕັດສິນໃຈໃຫ້ແນ່ໃຈວ່າຊຸມຊົນ ClickHouse ທັງຫມົດຈະໄດ້ຮັບຜົນປະໂຫຍດຈາກມັນ. ພວກເຮົາໄດ້ປະຕິບັດ ClickHouse ໃນໄລຍະ S3, ບໍ່ແມ່ນ ClickHouse ໃນໄລຍະ MDS. ແລະນີ້ແມ່ນການເຮັດວຽກຫຼາຍ.

ເອກະສານອ້າງອີງ:

https://github.com/ClickHouse/ClickHouse/pull/7946 "ຊັ້ນ abstraction ຂອງລະບົບໄຟລ໌"
https://github.com/ClickHouse/ClickHouse/pull/8011 "ການເຊື່ອມໂຍງ AWS SDK S3"
https://github.com/ClickHouse/ClickHouse/pull/8649 "ການປະຕິບັດພື້ນຖານຂອງ IDisk interafce ສໍາລັບ S3"
https://github.com/ClickHouse/ClickHouse/pull/8356 "ການເຊື່ອມໂຍງຂອງເຄື່ອງຈັກໃນການເກັບຮັກສາບັນທຶກທີ່ມີການໂຕ້ຕອບ IDisk"
https://github.com/ClickHouse/ClickHouse/pull/8862 "ສະຫນັບສະຫນູນເຄື່ອງຈັກສໍາລັບ S3 ແລະ SeekableReadBuffer"
https://github.com/ClickHouse/ClickHouse/pull/9128 "ຮອງຮັບ Stripe Log S3"
https://github.com/ClickHouse/ClickHouse/pull/9415 "ການສະຫນັບສະຫນູນເບື້ອງຕົ້ນການເກັບຮັກສາ MergeTree ສໍາລັບ S3"
https://github.com/ClickHouse/ClickHouse/pull/9646 "MergeTree ສະຫນັບສະຫນູນຢ່າງເຕັມທີ່ສໍາລັບ S3"
https://github.com/ClickHouse/ClickHouse/pull/10126 "ສະ​ຫນັບ​ສະ​ຫນູນ ReplicatedMergeTree ໃນ​ໄລ​ຍະ S3​"
https://github.com/ClickHouse/ClickHouse/pull/11134 "ເພີ່ມຂໍ້ມູນປະຈໍາຕົວເລີ່ມຕົ້ນແລະສ່ວນຫົວທີ່ກໍາຫນົດເອງສໍາລັບການເກັບຮັກສາ s3"
https://github.com/ClickHouse/ClickHouse/pull/10576 "S3 ທີ່ມີການຕັ້ງຄ່າພຣັອກຊີແບບໄດນາມິກ"
https://github.com/ClickHouse/ClickHouse/pull/10744 "S3 ກັບຕົວແກ້ໄຂຕົວແທນ"

ນີ້ແມ່ນບັນຊີລາຍຊື່ການຮ້ອງຂໍດຶງສໍາລັບການປະຕິບັດລະບົບໄຟລ໌ virtual ໃນ ClickHouse. ນີ້ແມ່ນການຮ້ອງຂໍດຶງຈໍານວນຫລາຍ.

ເອກະສານອ້າງອີງ:

https://github.com/ClickHouse/ClickHouse/pull/9760 "ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ Hardlinks DiskS3"
https://github.com/ClickHouse/ClickHouse/pull/11522 "ລູກຄ້າ S3 HTTP - ຫຼີກເວັ້ນການຄັດລອກກະແສການຕອບສະຫນອງເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາ"
https://github.com/ClickHouse/ClickHouse/pull/11561 "ຫຼີກເວັ້ນການຄັດລອກການຕອບສະຫນອງທັງຫມົດເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາໃນ S3 HTTP
ລູກ​ຄ້າ"
https://github.com/ClickHouse/ClickHouse/pull/13076 "ຄວາມສາມາດໃນການ cache mark ແລະດັດສະນີໄຟລ໌ສໍາລັບ S3 disk"
https://github.com/ClickHouse/ClickHouse/pull/13459 "ຍ້າຍພາກສ່ວນຈາກ DiskLocal ໄປ DiskS3 ໃນຂະຫນານ"

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

ເອກະສານອ້າງອີງ:

https://github.com/ClickHouse/ClickHouse/pull/12638 "ເພີ່ມ SelectedRows ແລະ SelectedBytes ເຫດການ"
https://github.com/ClickHouse/ClickHouse/pull/12464 "ເພີ່ມເຫດການ profileing ຈາກຄໍາຮ້ອງຂໍ S3 ກັບ system.events"
https://github.com/ClickHouse/ClickHouse/pull/13028 "ເພີ່ມ QueryTimeMicroseconds, SelectQueryTimeMicroseconds ແລະ InsertQueryTimeMicroseconds"

ແລະຫຼັງຈາກນັ້ນມັນຈໍາເປັນຕ້ອງເຮັດໃຫ້ມັນສາມາດວິນິດໄສ, ຕັ້ງຄ່າການຕິດຕາມແລະເຮັດໃຫ້ມັນສາມາດຄຸ້ມຄອງໄດ້.

ແລະທັງຫມົດນີ້ໄດ້ຖືກເຮັດເພື່ອໃຫ້ຊຸມຊົນທັງຫມົດ, ລະບົບນິເວດ ClickHouse ທັງຫມົດ, ໄດ້ຮັບຜົນຂອງການເຮັດວຽກນີ້.

ໃຫ້ກ້າວໄປສູ່ຖານຂໍ້ມູນການເຮັດທຸລະກໍາ, ໄປຫາຖານຂໍ້ມູນ OLTP, ເຊິ່ງໃກ້ຊິດກັບຂ້ອຍສ່ວນຕົວ.

ນີ້ແມ່ນພະແນກການພັດທະນາ DBMS ແຫຼ່ງເປີດ. ຄົນເຫຼົ່ານີ້ກໍາລັງເຮັດ magic street ເພື່ອປັບປຸງຖານຂໍ້ມູນເປີດການເຮັດທຸລະກໍາ.

ຫນຶ່ງໃນໂຄງການ, ການນໍາໃຊ້ຕົວຢ່າງທີ່ພວກເຮົາສາມາດສົນທະນາກ່ຽວກັບວິທີການແລະສິ່ງທີ່ພວກເຮົາເຮັດ, ແມ່ນ Connection Pooler ໃນ Postgres.

Postgres ແມ່ນຖານຂໍ້ມູນຂະບວນການ. ນີ້ຫມາຍຄວາມວ່າຖານຂໍ້ມູນຄວນຈະມີການເຊື່ອມຕໍ່ເຄືອຂ່າຍຫນ້ອຍເທົ່າທີ່ເປັນໄປໄດ້ທີ່ຈັດການທຸລະກໍາ.

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

ພວກ​ເຮົາ​ສາ​ມາດ​ເວົ້າ​ໄດ້​ວ່າ​ຕົວ​ກໍາ​ນົດ​ການ​ເຊື່ອມ​ຕໍ່​ແມ່ນ​ຜູ້​ປະ​ຕິ​ບັດ​ການ​ໂທລະ​ສັບ​ທີ່ rearranges bytes ເພື່ອ​ໃຫ້​ເຂົາ​ເຈົ້າ​ມີ​ປະ​ສິດ​ທິ​ພາບ​ໄປ​ເຖິງ​ຖານ​ຂໍ້​ມູນ​.

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

https://pgconf.ru/2017/92899

ພວກເຮົາໄດ້ສືບສວນຕົວເຊື່ອມຕໍ່ທີ່ເໝາະສົມກັບກຸ່ມ postgres ທີ່ມີການຈັດການ. ແລະ PgBouncer ແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດສໍາລັບພວກເຮົາ. ແຕ່ພວກເຮົາພົບບັນຫາຈໍານວນຫນຶ່ງກັບ PgBouncer. ຫລາຍປີກ່ອນ, Volodya Borodin ໃຫ້ລາຍງານວ່າພວກເຮົາໃຊ້ PgBouncer, ພວກເຮົາມັກທຸກສິ່ງທຸກຢ່າງ, ແຕ່ວ່າມີ nuances, ມີບາງສິ່ງບາງຢ່າງທີ່ຈະເຮັດວຽກ.

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

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

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

ພວກເຮົາມາຮອດການສະຫລຸບທີ່ພວກເຮົາສ້າງຕົວເຊື່ອມຕໍ່ຂອງພວກເຮົາເອງ, ເຊິ່ງເອີ້ນວ່າ Odyssey. ພວກເຮົາຂຽນມັນຈາກ scratch.

https://www.pgcon.org/2019/schedule/events/1312.en.html

ໃນປີ 2019, ໃນກອງປະຊຸມ PgCon, ຂ້າພະເຈົ້າໄດ້ນໍາສະເຫນີ pooler ນີ້ກັບຊຸມຊົນນັກພັດທະນາ. ໃນປັດຈຸບັນພວກເຮົາມີຫນ້ອຍກວ່າ 2 ດາວຢູ່ໃນ GitHub, i.e. ໂຄງການແມ່ນມີຊີວິດຢູ່, ໂຄງການເປັນທີ່ນິຍົມ.

ແລະຖ້າທ່ານສ້າງກຸ່ມ Postgres ໃນ Yandex.Cloud, ມັນຈະເປັນກຸ່ມທີ່ມີ Odyssey ສ້າງຂຶ້ນ, ເຊິ່ງຖືກຕັ້ງຄ່າຄືນໃຫມ່ເມື່ອປັບຂະຫນາດຂອງກຸ່ມກັບຄືນຫຼືອອກໄປ.

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

PgBouncer ເລີ່ມພັດທະນາໄວຂຶ້ນ.

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

ກໍລະນີອື່ນຂອງການເຮັດວຽກກັບຊຸມຊົນ postgres ແມ່ນການຟື້ນຟູຄືນໃຫມ່ໃນເວລາ. ນີ້ແມ່ນການຟື້ນຕົວຫຼັງຈາກຄວາມລົ້ມເຫຼວ, ນີ້ແມ່ນການຟື້ນຕົວຈາກການສໍາຮອງຂໍ້ມູນ.

ມີການສໍາຮອງຂໍ້ມູນຈໍານວນຫຼາຍແລະພວກເຂົາທັງຫມົດແມ່ນແຕກຕ່າງກັນ. ເກືອບທຸກຜູ້ຂາຍ Postgres ມີການແກ້ໄຂສໍາຮອງຂໍ້ມູນຂອງຕົນເອງ.

ຖ້າທ່ານເອົາລະບົບສໍາຮອງທັງຫມົດ, ສ້າງເມຕຣິກດ້ານຄຸນສົມບັດແລະຄໍານວນຕົວກໍານົດໃນ matrix ນີ້ແບບຕະຫຼົກ, ມັນຈະເປັນສູນ. ນີ້ຫມາຍຄວາມວ່າແນວໃດ? ຈະເປັນແນວໃດຖ້າຫາກວ່າທ່ານເອົາໄຟລ໌ສໍາຮອງຂໍ້ມູນສະເພາະໃດຫນຶ່ງ, ຫຼັງຈາກນັ້ນມັນບໍ່ສາມາດປະກອບຈາກຕ່ອນຂອງອື່ນໆທັງຫມົດ. ມັນເປັນເອກະລັກໃນການປະຕິບັດ, ມັນເປັນເອກະລັກໃນຈຸດປະສົງຂອງມັນ, ມັນເປັນເອກະລັກໃນແນວຄວາມຄິດທີ່ຝັງຢູ່ໃນມັນ. ແລະພວກເຂົາທັງຫມົດແມ່ນສະເພາະ.

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

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

https://github.com/wal-g/wal-g/graphs/contributors

ໃນປັດຈຸບັນມີຜູ້ພັດທະນາຫຼາຍສິບຄົນໃນໂຄງການນີ້, ແຕ່ຜູ້ປະກອບສ່ວນ 10 ອັນດັບສູງສຸດຂອງ WAL-G ປະກອບມີ 6 Yandexoids. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ເອົາ​ຫຼາຍ​ຂອງ​ຄວາມ​ຄິດ​ຂອງ​ພວກ​ເຮົາ​ທີ່​ນັ້ນ​. ແລະ, ແນ່ນອນ, ພວກເຮົາປະຕິບັດພວກມັນດ້ວຍຕົນເອງ, ທົດສອບຕົວເອງ, ມ້ວນພວກມັນອອກໃນການຜະລິດຕົວເຮົາເອງ, ພວກເຮົາໃຊ້ຕົວເອງ, ພວກເຮົາຄິດອອກບ່ອນທີ່ຈະຍ້າຍອອກໄປ, ໃນຂະນະທີ່ພົວພັນກັບຊຸມຊົນ WAL-G ຂະຫນາດໃຫຍ່.

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

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

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

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

ແລະພວກເຮົາໄດ້ສົ່ງເສີມຄວາມຄິດທີ່ງ່າຍດາຍນີ້. ແລະ, ມັນເບິ່ງຄືວ່າພວກເຮົາ, ພວກເຮົາໄດ້ຈັດການເພື່ອປະຕິບັດມັນ.

ແຕ່ນັ້ນບໍ່ແມ່ນທັງຫມົດ. ພວກເຮົາຕ້ອງການສິ່ງເລັກນ້ອຍອີກອັນໜຶ່ງ. ພວກເຮົາຕ້ອງການຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນຫຼາຍ. ບໍ່ແມ່ນລູກຄ້າທັງໝົດຂອງພວກເຮົາໃຊ້ Postgres. ບາງຄົນໃຊ້ MySQL, MongoDB. ໃນຊຸມຊົນ, ຜູ້ພັດທະນາອື່ນໆໄດ້ສະຫນັບສະຫນູນ FoundationDB. ແລະບັນຊີລາຍຊື່ນີ້ແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ.

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

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

ມີຖານຂໍ້ມູນດັ່ງກ່າວເປັນ Postgres. ຂ້ອຍມັກ Postgres ຫຼັກທີ່ສຸດ. ຂ້ອຍໃຊ້ເວລາຫຼາຍໃນການພັດທະນາຫຼັກ Postgres ກັບຊຸມຊົນ.

ແຕ່ໃນທີ່ນີ້ມັນຕ້ອງເວົ້າວ່າ Yandex.Cloud ມີການຕິດຕັ້ງພາຍໃນຂອງຖານຂໍ້ມູນທີ່ຖືກຄຸ້ມຄອງ. ແລະມັນໄດ້ເລີ່ມຕົ້ນເປັນເວລາດົນນານກ່ອນຫນ້ານີ້ໃນ Yandex.Mail. ຄວາມຊໍານານທີ່ປະຈຸບັນໄດ້ນໍາໄປສູ່ການຄຸ້ມຄອງ Postgres ໄດ້ຖືກສະສົມໃນເວລາທີ່ເມລຕ້ອງການຍ້າຍເຂົ້າໄປໃນ Postgres.

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

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

ໃນປັດຈຸບັນການຕິດຕັ້ງພາຍໃນຂອງ Postgres ແມ່ນບາງ petabytes ຂອງຂໍ້ມູນ. ເຫຼົ່ານີ້ແມ່ນບາງລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ. ເຫຼົ່ານີ້ແມ່ນຫລາຍພັນກຸ່ມ. ມັນເປັນຂະຫນາດໃຫຍ່ຫຼາຍ.

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

ແລະໃນຊ່ວງເວລາທີ່ແນ່ນອນໃນສະພາບແວດລ້ອມການທົດສອບພວກເຮົາໄດ້ຮັບຂໍ້ຄວາມທີ່ຊີ້ໃຫ້ເຫັນວ່າ invariants ພາຍໃນຂອງດັດສະນີຖານຂໍ້ມູນໄດ້ຖືກລະເມີດ.

invariant ແມ່ນບາງປະເພດຂອງຄວາມສໍາພັນທີ່ພວກເຮົາຄາດຫວັງວ່າຈະຖືສະເຫມີ.

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

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

ແລະໃນທີ່ນີ້ສະຖານະການເກີດຂື້ນທີ່ແນະນໍາວ່າອາດຈະມີສະຖານະການທີ່ພວກເຮົາອາດຈະບໍ່ກຽມພ້ອມ. ແລະພວກເຮົາໄດ້ເລີ່ມກະກຽມສໍາລັບສະຖານະການນີ້.

https://commitfest.postgresql.org/23/2171/

ສິ່ງທໍາອິດທີ່ພວກເຮົາໄດ້ເຮັດແມ່ນຝັງໄມ້ທ່ອນຈາກຫຼາຍພັນກຸ່ມເຫຼົ່ານີ້. ພວກ​ເຮົາ​ພົບ​ເຫັນ​ວ່າ​ກຸ່ມ​ໃດ​ຢູ່​ໃນ​ແຜ່ນ​ທີ່​ມີ​ເຟີມ​ແວ​ທີ່​ມີ​ບັນ​ຫາ​ທີ່​ສູນ​ເສຍ​ການ​ອັບ​ເດດ​ໜ້າ​ຂໍ້​ມູນ. ໝາຍລະຫັດຂໍ້ມູນ Postgres ທັງໝົດແລ້ວ. ແລະພວກເຮົາໄດ້ໝາຍຂໍ້ຄວາມເຫຼົ່ານັ້ນທີ່ສະແດງເຖິງການລະເມີດຂອງຕົວປ່ຽນແປງພາຍໃນດ້ວຍລະຫັດທີ່ຖືກອອກແບບມາເພື່ອກວດຫາຂໍ້ມູນເສຍຫາຍ.

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

ຫຼັງ​ຈາກ​ນີ້​, ພວກ​ເຮົາ​ໄດ້​ມາ​ເຖິງ​ຈຸດ​ທີ່​ພວກ​ເຮົາ​ມີ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ທີ່​ບັນ​ທຶກ scans​. ແລະໃນກໍລະນີທີ່ມີຂໍ້ຄວາມທີ່ຫນ້າສົງໄສ, ລາວປຸກເຈົ້າຫນ້າທີ່, ແລະເຈົ້າຫນ້າທີ່ປະຕິບັດການສ້ອມແປງມັນ.

ແຕ່! ບັນທຶກການສະແກນແມ່ນການດໍາເນີນງານລາຄາຖືກຢູ່ໃນກຸ່ມດຽວ ແລະລາຄາແພງທີ່ຮ້າຍກາດສໍາລັບຫນຶ່ງພັນ clusters.

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

ການຂະຫຍາຍນີ້ໄດ້ຖືກຮັບຮອງເອົາ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ repository ສໍາລັບ CentOS. ຖ້າທ່ານຕ້ອງການໃຊ້ມັນ, ທ່ານສາມາດຕິດຕັ້ງມັນເອງ. ແນ່ນອນວ່າມັນເປັນແຫຼ່ງເປີດ.

https://www.postgresql.org/message-id/flat/[email protected]

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

ແລະພວກເຮົາພົບວ່າຖ້າທ່ານປະຕິບັດມັນໃນລະດັບຂະຫນາດ, ມີແມງໄມ້. ພວກເຮົາເລີ່ມແກ້ໄຂພວກມັນ. ການແກ້ໄຂຂອງພວກເຮົາໄດ້ຮັບການຍອມຮັບ.

https://www.postgresql.org/message-id/flat/[email protected]

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

https://commitfest.postgresql.org/29/2667/

ແລະພວກເຮົາຍັງໄດ້ຄົ້ນພົບວ່າໃນເວລາທີ່ການກວດສອບດັດສະນີສໍາລັບການລະເມີດກ່ຽວກັບຜູ້ນໍາ replication, ກ່ຽວກັບແມ່ບົດ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກໄດ້ດີ, ແຕ່ວ່າໃນ replicas, ກ່ຽວກັບຜູ້ຕິດຕາມ, ການຊອກຫາການສໍ້ລາດບັງຫຼວງແມ່ນບໍ່ມີຜົນດີ. ບໍ່ແມ່ນຕົວປ່ຽນແປງທັງໝົດຖືກກວດສອບ. ແລະ invariant ຫນຶ່ງ bothered ພວກເຮົາຫຼາຍ. ແລະພວກເຮົາໄດ້ໃຊ້ເວລາ XNUMX ປີເຄິ່ງເພື່ອຕິດຕໍ່ສື່ສານກັບຊຸມຊົນເພື່ອໃຫ້ສາມາດກວດສອບການຈໍາລອງໄດ້.

ພວກເຮົາຂຽນລະຫັດທີ່ຄວນປະຕິບັດຕາມ can... protocols. ພວກເຮົາໄດ້ສົນທະນາກ່ຽວກັບການແກ້ໄຂນີ້ສໍາລັບເວລາໃດຫນຶ່ງກັບ Peter Gaghan ຈາກ Crunchy Data. ລາວຕ້ອງດັດແປງ B-tree ທີ່ມີຢູ່ກ່ອນແລ້ວໃນ Postgres ເລັກນ້ອຍເພື່ອຍອມຮັບເອົາແຜ່ນນີ້. ລາວໄດ້ຮັບການຍອມຮັບ. ແລະໃນປັດຈຸບັນການກວດສອບດັດສະນີກ່ຽວກັບ replicas ໄດ້ກາຍເປັນປະສິດທິພາບພຽງພໍທີ່ຈະກວດພົບການລະເມີດທີ່ພວກເຮົາພົບ. ນັ້ນແມ່ນ, ເຫຼົ່ານີ້ແມ່ນການລະເມີດທີ່ສາມາດເກີດຈາກຄວາມຜິດພາດໃນ firmware ແຜ່ນ, ແມງໄມ້ໃນ Postgres, ແມງໄມ້ໃນ Linux kernel, ແລະບັນຫາຮາດແວ. ຂ້ອນຂ້າງບັນຊີລາຍຊື່ຢ່າງກວ້າງຂວາງຂອງແຫຼ່ງຂອງບັນຫາທີ່ພວກເຮົາໄດ້ກະກຽມ.

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

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

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

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

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

ຊຸມຊົນຕອບວ່າ, "ໂອ້, ພວກເຮົາຕ້ອງແກ້ໄຂມັນແທ້ໆ."

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

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

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

ຖານຂໍ້ມູນທີ່ຫນ້າສົນໃຈແມ່ນ Greenplum. ມັນເປັນຖານຂໍ້ມູນທີ່ມີຄວາມຂະຫນານກັນສູງໂດຍອີງໃສ່ລະຫັດ Postgres, ທີ່ຂ້ອຍຄຸ້ນເຄີຍຫຼາຍ.

https://greenplum.org/greenplum-database-tables-compression/

ແລະ Greenplum ມີຫນ້າທີ່ທີ່ຫນ້າສົນໃຈ - append optimized tables . ເຫຼົ່ານີ້ແມ່ນຕາຕະລາງທີ່ທ່ານສາມາດເພີ່ມໄດ້ໄວ. ພວກເຂົາສາມາດເປັນຖັນຫຼືແຖວ.

ແຕ່ບໍ່ມີກຸ່ມ, i.e. ບໍ່ມີການເຮັດວຽກທີ່ທ່ານສາມາດຈັດລຽງຂໍ້ມູນທີ່ຢູ່ໃນຕາຕະລາງຕາມລໍາດັບທີ່ຢູ່ໃນຫນຶ່ງໃນດັດຊະນີ.

ຜູ້ຊາຍຈາກລົດແທັກຊີ່ມາຫາຂ້ອຍແລະເວົ້າວ່າ: "Andrey, ເຈົ້າຮູ້ຈັກ Postgres. ແລະໃນທີ່ນີ້ມັນເກືອບຄືກັນ. ປ່ຽນເປັນ 20 ນາທີ. ເຈົ້າເອົາມັນແລະເຮັດມັນ." ຂ້ອຍຄິດວ່າແມ່ນແລ້ວ, ຂ້ອຍຮູ້ Postgres, ປ່ຽນເວລາ 20 ນາທີ - ຂ້ອຍຈໍາເປັນຕ້ອງເຮັດສິ່ງນີ້.

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

ແຕ່ບໍ່, ມັນບໍ່ແມ່ນ 20 ນາທີ, ຂ້ອຍຂຽນມັນຫຼາຍເດືອນ. ໃນກອງປະຊຸມ PgConf.Russia, ຂ້າພະເຈົ້າໄດ້ເຂົ້າຫາ Heikki Linakangas ຈາກ Pivotal ແລະຖາມວ່າ: "ມີບັນຫາກັບເລື່ອງນີ້ບໍ? ເປັນຫຍັງຈຶ່ງບໍ່ມີສ່ວນຊ້ອນທ້າຍຕາຕະລາງທີ່ປັບແຕ່ງໃຫ້ເໝາະສົມ?” ລາວ​ເວົ້າ​ວ່າ: “ເຈົ້າ​ເອົາ​ຂໍ້​ມູນ. ທ່ານຈັດຮຽງ, ທ່ານຈັດຮຽງໃຫມ່. ມັນເປັນພຽງແຕ່ວຽກ." ຂ້ອຍ: "ໂອ້, ແມ່ນແລ້ວ, ເຈົ້າພຽງແຕ່ຕ້ອງການເອົາມັນແລະເຮັດມັນ." ລາວເວົ້າວ່າ: "ແມ່ນແລ້ວ, ພວກເຮົາຕ້ອງການມືທີ່ບໍ່ເສຍຄ່າເພື່ອເຮັດສິ່ງນີ້." ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ຈໍາ​ເປັນ​ຕ້ອງ​ເຮັດ​ສິ່ງ​ນີ້​ແນ່​ນອນ.

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

https://github.com/greenplum-db/gpdb/issues/10150

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

https://github.com/greenplum-db/gpdb/pull/10290

ຂ້ອຍແກ້ໄຂ bug ນີ້. ສົ່ງຄໍາຮ້ອງຂໍດຶງໄປຫາຜູ້ແກ້ໄຂ. ລາວໄດ້ຖືກຂ້າຕາຍ.

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

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

https://github.com/greenplum-db/gpdb/pull/10565

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

ຂ້ອຍເລີ່ມຂຽນເອກະສານ. ໂຊກດີ, ນັກສາລະຄະດີຈາກ Pivotal ມາພ້ອມ. ພາສາອັງກິດເປັນພາສາກໍາເນີດຂອງເຂົາເຈົ້າ. ພວກເຂົາຊ່ວຍຂ້ອຍໃນເອກະສານ. ໃນຄວາມເປັນຈິງ, ພວກເຂົາເອງຂຽນຄືນສິ່ງທີ່ຂ້ອຍສະເຫນີເປັນພາສາອັງກິດທີ່ແທ້ຈິງ.

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

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

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

ຫມົດ​ເທົ່າ​ນີ້. ຂໍໃຫ້ກ້າວໄປສູ່ຄໍາຖາມ.

ກອງ​ປະ​ຊຸມ​ຄໍາ​ຖາມ​

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

ລະບົບສຳຮອງໃນ WAL-G ແມ່ນຂຽນໃນ Go. ນີ້ແມ່ນໜຶ່ງໃນບັນດາໂຄງການໃໝ່ກວ່າທີ່ພວກເຮົາໄດ້ເຮັດວຽກ. ລາວມີອາຍຸພຽງແຕ່ 3 ປີເທົ່ານັ້ນ. ແລະຖານຂໍ້ມູນມັກຈະກ່ຽວກັບຄວາມຫນ້າເຊື່ອຖື. ແລະນີ້ຫມາຍຄວາມວ່າຖານຂໍ້ມູນແມ່ນຂ້ອນຂ້າງເກົ່າແລະພວກເຂົາມັກຈະຖືກຂຽນໄວ້ໃນ C. ໂຄງການ Postgres ໄດ້ເລີ່ມຕົ້ນປະມານ 30 ປີກ່ອນຫນ້ານີ້. ຫຼັງຈາກນັ້ນ C89 ແມ່ນທາງເລືອກທີ່ຖືກຕ້ອງ. ແລະ Postgres ຖືກຂຽນໃສ່ມັນ. ຖານຂໍ້ມູນທີ່ທັນສະໄຫມຫຼາຍເຊັ່ນ ClickHouse ມັກຈະຂຽນໃນ C ++. ການພັດທະນາລະບົບທັງໝົດແມ່ນອີງໃສ່ C ແລະ C ++.

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

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

ຄໍາຖາມອີກອັນຫນຶ່ງ: "ຄວາມຕ້ອງການຂອງຜູ້ໃຊ້ພາຍນອກທີ່ອາໄສຢູ່ໃນ Yandex.Cloud ແຕກຕ່າງຈາກຜູ້ໃຊ້ພາຍໃນທີ່ອາໄສຢູ່ໃນ Cloud ພາຍໃນບໍ?"

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

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

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

ເຈົ້າເວົ້າຫຼາຍກ່ຽວກັບມາຣາທອນ. ຂ້ອຍຮູ້ວ່າເຈົ້າແລ່ນມາຣາທອນຢູ່ມອດໂກ. ຜົນໄດ້ຮັບ? ເອົາຊະນະຄົນຈາກ PostgreSQL ບໍ?

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

ເຈົ້າເວົ້າວ່າບໍ່ມີນັກແລ່ນຢູ່ ClickHouse ບໍ?

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

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

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

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

ນີ້ແມ່ນຄໍາຖາມທີ່ຫນ້າສົນໃຈ: "ບ່ອນທີ່ຈະເລີ່ມຕົ້ນ?" ປົກກະຕິແລ້ວມັນຂ້ອນຂ້າງຍາກທີ່ຈະເລີ່ມຕົ້ນດ້ວຍບາງສິ່ງບາງຢ່າງໃນແກ່ນ. ສໍາລັບຕົວຢ່າງ, ໃນ Postgres, ມີລາຍການທີ່ຕ້ອງເຮັດ. ແຕ່​ໃນ​ຄວາມ​ເປັນ​ຈິງ, ນີ້​ແມ່ນ​ແຜ່ນ​ຂອງ​ສິ່ງ​ທີ່​ເຂົາ​ເຈົ້າ​ພະ​ຍາ​ຍາມ​ເຮັດ​, ແຕ່​ບໍ່​ສໍາ​ເລັດ​. ເຫຼົ່ານີ້ແມ່ນສິ່ງທີ່ສັບສົນ. ແລະປົກກະຕິແລ້ວທ່ານສາມາດຊອກຫາສິ່ງອໍານວຍຄວາມສະດວກບາງຢ່າງໃນລະບົບນິເວດ, ບາງສ່ວນຂະຫຍາຍທີ່ສາມາດປັບປຸງໄດ້, ທີ່ດຶງດູດຄວາມສົນໃຈຫນ້ອຍລົງຈາກຜູ້ພັດທະນາ kernel. ແລະ, ຕາມຄວາມເຫມາະສົມ, ມີຈຸດເພີ່ມເຕີມສໍາລັບການຂະຫຍາຍຕົວຢູ່ທີ່ນັ້ນ. ຢູ່ໃນ Google Summer of code program, ທຸກໆປີຊຸມຊົນ postgres ສະເຫນີຫົວຂໍ້ທີ່ແຕກຕ່າງກັນຫຼາຍທີ່ສາມາດແກ້ໄຂໄດ້. ຂ້າພະເຈົ້າຄິດວ່າປີນີ້ພວກເຮົາມີນັກຮຽນສາມຄົນ. ຜູ້ຫນຶ່ງກໍ່ຂຽນໃນ WAL-G ກ່ຽວກັບຫົວຂໍ້ທີ່ມີຄວາມສໍາຄັນກັບ Yandex. ໃນ Greenplum, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍກວ່າໃນຊຸມຊົນ Postgres, ເພາະວ່າແຮກເກີ Greenplum ປະຕິບັດການຮ້ອງຂໍດຶງໄດ້ດີຫຼາຍແລະເລີ່ມຕົ້ນການທົບທວນຄືນທັນທີ. ການສົ່ງ patch ໄປ Postgres ແມ່ນໃຊ້ເວລາຫຼາຍເດືອນ, ແຕ່ Greenplum ຈະມາໃນມື້ຫນຶ່ງແລະເບິ່ງສິ່ງທີ່ທ່ານໄດ້ເຮັດ. ສິ່ງອື່ນແມ່ນວ່າ Greenplum ຕ້ອງການແກ້ໄຂບັນຫາໃນປະຈຸບັນ. Greenplum ບໍ່ໄດ້ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງ, ດັ່ງນັ້ນການຊອກຫາບັນຫາຂອງທ່ານແມ່ນຂ້ອນຂ້າງຍາກ. ແລະທໍາອິດຂອງການທັງຫມົດ, ພວກເຮົາຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາ, ແນ່ນອນ.

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