ວິທີການຢູ່ລອດຖານຂໍ້ມູນ SQL ໃນສະຕະວັດທີ 21: clouds, Kubernetes ແລະ PostgreSQL multimaster

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

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

webinar ໄດ້ຈັດຂຶ້ນ Valery Bezrukov, Google Cloud Practice Delivery Manager at EPAM Systems.

ເມື່ອຕົ້ນໄມ້ນ້ອຍ...

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

ໃນທ້າຍຊຸມປີ 90 ແລະຕົ້ນຊຸມປີ 2, ມັນບໍ່ມີທາງເລືອກໃດໆໃນເວລາທີ່ມັນມາກັບຖານຂໍ້ມູນທີ່ສາມາດຂະຫຍາຍໄດ້ໃນອຸດສາຫະກໍາ. ແມ່ນແລ້ວ, ມີ IBM DBXNUMX, Sybase ແລະບາງຖານຂໍ້ມູນອື່ນໆທີ່ມາແລະໄປ, ແຕ່ໂດຍທົ່ວໄປແລ້ວພວກມັນບໍ່ສັງເກດເຫັນຫຼາຍຕໍ່ກັບພື້ນຖານຂອງ Oracle. ຕາມນັ້ນແລ້ວ, ທັກສະຂອງນັກວິສະວະກອນໃນສະໄໝນັ້ນໄດ້ຖືກຜູກມັດກັບທາງເລືອກດຽວທີ່ມີຢູ່.

Oracle DBA ຈະຕ້ອງສາມາດ:

• ຕິດຕັ້ງ Oracle Server ຈາກຊຸດແຈກຢາຍ;
• ຕັ້ງຄ່າ Oracle Server:

• init.ora ;
• listener.ora;

- ສ້າງ:

• ພື້ນທີ່ໂຕະ;
• ແຜນການ;
• ຜູ້ໃຊ້;

— ປະ​ຕິ​ບັດ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ແລະ​ການ​ຟື້ນ​ຟູ​;
— ປະ​ຕິ​ບັດ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​;
— ຈັດ​ການ​ກັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ເຫມາະ​ສົມ​.

ໃນເວລາດຽວກັນ, ບໍ່ມີຄວາມຕ້ອງການພິເສດຈາກ Oracle DBA:

• ສາມາດເລືອກ DBMS ທີ່ດີທີ່ສຸດຫຼືເຕັກໂນໂລຢີອື່ນໆສໍາລັບການເກັບຮັກສາແລະການປຸງແຕ່ງຂໍ້ມູນ;
• ສະຫນອງການມີໃຫ້ສູງແລະການຂະຫຍາຍອອກຕາມລວງນອນ (ນີ້ບໍ່ແມ່ນບັນຫາ DBA ສະເຫມີ);
• ຄວາມຮູ້ທີ່ດີຂອງສາຂາວິຊາ, ພື້ນຖານໂຄງລ່າງ, ສະຖາປັດຕະຍະກໍາຄໍາຮ້ອງສະຫມັກ, OS;
• ໂຫຼດແລະຍົກເລີກຂໍ້ມູນ, ຍ້າຍຂໍ້ມູນລະຫວ່າງ DBMSs ທີ່ແຕກຕ່າງກັນ.

ໂດຍທົ່ວໄປ, ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບທາງເລືອກໃນຍຸກນັ້ນ, ມັນຄ້າຍຄືກັບທາງເລືອກໃນຮ້ານໂຊວຽດໃນທ້າຍປີ 80s:

ເວລາຂອງພວກເຮົາ

ນັບຕັ້ງແຕ່ນັ້ນມາ, ແນ່ນອນ, ຕົ້ນໄມ້ໄດ້ເຕີບໃຫຍ່, ໂລກໄດ້ປ່ຽນແປງ, ແລະມັນໄດ້ກາຍເປັນເຊັ່ນນີ້:

ຕະຫຼາດ DBMS ຍັງມີການປ່ຽນແປງ, ດັ່ງທີ່ເຫັນໄດ້ຊັດເຈນຈາກບົດລາຍງານຫຼ້າສຸດຈາກ Gartner:

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

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

ແມ່ນ​ຫຍັງ​ຕໍ່?

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

ຄຽງຄູ່ກັບຄໍາຖາມທາງເລືອກ, ຍັງມີ ປັດໄຈຈໍາກັດ:

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

ສິ່ງທີ່ຄາດຫວັງຈາກ DA/DE ໃນປັດຈຸບັນ:

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

ຕົວຢ່າງຂ້າງລຸ່ມນີ້ ອີງໃສ່ GCP ສະແດງໃຫ້ເຫັນວິທີການທາງເລືອກຂອງເຕັກໂນໂລຊີຫນຶ່ງຫຼືອື່ນສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນເຮັດວຽກຂຶ້ນກັບໂຄງສ້າງຂອງມັນ:

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

ມັນຄວນຈະສັງເກດວ່າທາງເລືອກນີ້ບໍ່ຊັດເຈນສະເຫມີ, ດັ່ງນັ້ນນັກພັດທະນາແອັບພລິເຄຊັນມັກຈະຖືກນໍາພາໂດຍ intuition.

ລວມ:

1. ຍິ່ງເຈົ້າໄປຫຼາຍເທົ່າໃດ, ຄຳຖາມຂອງການເລືອກກໍ່ຍິ່ງກົດຂື້ນ. ແລະເຖິງແມ່ນວ່າທ່ານເບິ່ງພຽງແຕ່ຢູ່ໃນ GCP, ການບໍລິການທີ່ຖືກຄຸ້ມຄອງແລະ SaaS, ຫຼັງຈາກນັ້ນບາງຄໍາເວົ້າຂອງ RDBMS ປາກົດຢູ່ໃນຂັ້ນຕອນທີ 4 (ແລະມີ Spanner ຢູ່ໃກ້ໆ). ນອກຈາກນັ້ນ, ທາງເລືອກຂອງ PostgreSQL ປາກົດຢູ່ໃນຂັ້ນຕອນທີ 5, ແລະຕໍ່ໄປມັນຍັງມີ MySQL ແລະ SQL Server, ນັ້ນແມ່ນ. ມີຫຼາຍທຸກສິ່ງທຸກຢ່າງ, ແຕ່ວ່າທ່ານຕ້ອງເລືອກ.
2. ພວກເຮົາຕ້ອງບໍ່ລືມກ່ຽວກັບຂໍ້ຈໍາກັດຕໍ່ກັບພື້ນຖານຂອງການລໍ້ລວງ. ໂດຍພື້ນຖານແລ້ວທຸກຄົນຕ້ອງການ Spanner, ແຕ່ມັນມີລາຄາແພງ. ດັ່ງນັ້ນ, ການຮ້ອງຂໍປົກກະຕິເບິ່ງຄືວ່າບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້: "ກະລຸນາເຮັດໃຫ້ພວກເຮົາເປັນ Spanner ແຕ່ສໍາລັບລາຄາຂອງ Cloud SQL, ທ່ານເປັນມືອາຊີບ!"

ຂ້ອຍ​ຄວນ​ເຮັດ​ແນວ​ໃດ?

ໂດຍບໍ່ມີການອ້າງວ່າເປັນຄວາມຈິງສູງສຸດ, ໃຫ້ເວົ້າວ່າດັ່ງຕໍ່ໄປນີ້:

ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນວິທີການຂອງພວກເຮົາໃນການຮຽນຮູ້:

• ບໍ່ມີຈຸດໃດໃນການສອນວິທີການສອນ DBAs ກ່ອນ;
• ຄວາມຮູ້ກ່ຽວກັບຜະລິດຕະພັນຫນຶ່ງແມ່ນບໍ່ພຽງພໍ;
• ແຕ່ການຮູ້ຫລາຍສິບຄົນໃນລະດັບຫນຶ່ງແມ່ນເປັນໄປບໍ່ໄດ້.

ທ່ານ ຈຳ ເປັນຕ້ອງຮູ້ບໍ່ພຽງແຕ່ແລະບໍ່ແມ່ນຜະລິດຕະພັນຫຼາຍປານໃດ, ແຕ່:

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

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

ກໍລະນີທີ່ແທ້ຈິງ

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

• ສ້າງ CI/CD;
• ທົບທວນຄືນສະຖາປັດຕະຍະກໍາ;
• ເອົາມັນທັງຫມົດເຂົ້າໄປໃນການດໍາເນີນງານ.

ແອັບພລິເຄຊັນຕົວມັນເອງແມ່ນບໍລິການຈຸລະພາກ, ແລະລະຫັດ Python / Django ໄດ້ຖືກພັດທະນາຕັ້ງແຕ່ເລີ່ມຕົ້ນແລະໂດຍກົງໃນ GCP. ສໍາລັບຜູ້ຊົມເປົ້າຫມາຍ, ມັນສົມມຸດວ່າຈະມີສອງພາກພື້ນ - ສະຫະລັດແລະ EU, ແລະການຈະລາຈອນໄດ້ຖືກແຈກຢາຍຜ່ານ Global Load balancer. Workloads ແລະ compute workload ທັງໝົດແລ່ນຢູ່ໃນ Google Kubernetes Engine.

ສໍາລັບຂໍ້ມູນ, ມີ 3 ໂຄງສ້າງ:

• Cloud Storage;
• ບ່ອນເກັບຂໍ້ມູນ;
• Cloud SQL (PostgreSQL).

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

ສໍາລັບກໍລະນີຂອງພວກເຮົາ, Cloud SQL ຖືກເລືອກສໍາລັບເຫດຜົນຕໍ່ໄປນີ້:

1. ດັ່ງທີ່ໄດ້ກ່າວມາ, ແອັບພລິເຄຊັນໄດ້ຖືກພັດທະນາໂດຍໃຊ້ Django, ແລະມັນມີຮູບແບບສໍາລັບແຜນທີ່ຂໍ້ມູນຄົງທີ່ຈາກຖານຂໍ້ມູນ SQL ໄປຫາວັດຖຸ Python (Django ORM).
2. ກອບຕົວມັນເອງໄດ້ສະຫນັບສະຫນູນບັນຊີລາຍຊື່ຂອງ DBMSs ທີ່ຈໍາກັດພໍສົມຄວນ:

• PostgreSQL;
• MariaDB;
• MySQL;
• ໂອລາ;
• SQLite.

ດັ່ງນັ້ນ, PostgreSQL ໄດ້ຖືກເລືອກຈາກບັນຊີລາຍຊື່ນີ້ແທນທີ່ຈະ intuitively (ດີ, ມັນບໍ່ແມ່ນ Oracle ທີ່ຈະເລືອກເອົາ, ແທ້).

ສິ່ງທີ່ຂາດຫາຍໄປ:

• ຄໍາຮ້ອງສະຫມັກໄດ້ຖືກປະຕິບັດພຽງແຕ່ໃນ 2 ພາກພື້ນ, ແລະອັນທີ 3 ປາກົດຢູ່ໃນແຜນການ (ອາຊີ);
• ຖານຂໍ້ມູນຕັ້ງຢູ່ໃນພາກພື້ນອາເມລິກາເຫນືອ (ໄອໂອວາ);
• ໃນສ່ວນຂອງລູກຄ້າມີຄວາມກັງວົນກ່ຽວກັບຄວາມເປັນໄປໄດ້ ຄວາມລ່າຊ້າໃນການເຂົ້າເຖິງ ຈາກເອີຣົບແລະອາຊີແລະ ການຂັດຂວາງ ໃນການບໍລິການ ໃນກໍລະນີຂອງການຢຸດ DBMS.

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

ຄວາມຫຍຸ້ງຍາກແມ່ນວ່າລູກຄ້າບໍ່ຕ້ອງການທີ່ຈະປະຖິ້ມການບໍລິການທີ່ມີການຄຸ້ມຄອງແລະ Cloud SQL. ແລະຄວາມສາມາດຂອງ Cloud SQL ແມ່ນມີຈໍາກັດໃນປັດຈຸບັນ. Cloud SQL ຮອງຮັບການມີໃຫ້ສູງ (HA) ແລະ Read Replica (RR), ແຕ່ RR ດຽວກັນແມ່ນຮອງຮັບໃນພາກພື້ນດຽວເທົ່ານັ້ນ. ໄດ້ສ້າງຖານຂໍ້ມູນໃນພາກພື້ນອາເມລິກາ, ທ່ານບໍ່ສາມາດສ້າງແບບຈໍາລອງການອ່ານຢູ່ໃນພາກພື້ນເອີຣົບໂດຍໃຊ້ Cloud SQL, ເຖິງແມ່ນວ່າ Postgres ຕົວຂອງມັນເອງບໍ່ໄດ້ປ້ອງກັນທ່ານຈາກການເຮັດສິ່ງນີ້. ການຕອບສະ ໜອງ ກັບພະນັກງານຂອງ Google ບໍ່ໄດ້ ນຳ ພາໄປໃສແລະສິ້ນສຸດລົງດ້ວຍ ຄຳ ສັນຍາໃນແບບຂອງ "ພວກເຮົາຮູ້ບັນຫາແລະ ກຳ ລັງເຮັດວຽກຢູ່, ມື້ໃດບັນຫາຈະຖືກແກ້ໄຂ."

ຖ້າພວກເຮົາບອກຄວາມສາມາດຂອງ Cloud SQL ໂດຍຫຍໍ້, ມັນຈະມີລັກສະນະນີ້:

1. ຄວາມພ້ອມສູງ (HA):

• ພາຍໃນຫນຶ່ງພາກພື້ນ;
• ຜ່ານການຈໍາລອງແຜ່ນ;
• ເຄື່ອງຈັກ PostgreSQL ບໍ່ໄດ້ຖືກນໍາໃຊ້;
• ການຄວບຄຸມອັດຕະໂນມັດແລະຄູ່ມືທີ່ເປັນໄປໄດ້ - ລົ້ມເຫລວ / ລົ້ມເຫລວ;
• ເມື່ອປ່ຽນ, DBMS ບໍ່ສາມາດໃຊ້ໄດ້ເປັນເວລາຫຼາຍນາທີ.

2. ອ່ານ Replica (RR):

• ພາຍໃນຫນຶ່ງພາກພື້ນ;
• ສະແຕນບາຍຮ້ອນ;
• PostgreSQL streaming replication.

ນອກຈາກນັ້ນ, ຕາມປະເພນີ, ເມື່ອເລືອກເຕັກໂນໂລຢີທີ່ເຈົ້າຕ້ອງປະເຊີນກັບບາງຄົນ ຂໍ້ຈຳກັດ:

• ລູກຄ້າບໍ່ຕ້ອງການສ້າງຫນ່ວຍງານແລະນໍາໃຊ້ IaaS, ຍົກເວັ້ນຜ່ານ GKE;
• ລູກຄ້າບໍ່ຢາກນຳໃຊ້ບໍລິການຕົນເອງ PostgreSQL/MySQL;
• ດີ, ໂດຍທົ່ວໄປ, Google Spanner ຈະເຫມາະສົມຫຼາຍຖ້າມັນບໍ່ແມ່ນສໍາລັບລາຄາຂອງມັນ, ຢ່າງໃດກໍຕາມ, Django ORM ບໍ່ສາມາດເຮັດວຽກກັບມັນໄດ້, ແຕ່ມັນເປັນສິ່ງທີ່ດີ.

ພິຈາລະນາສະຖານະການ, ລູກຄ້າໄດ້ຮັບຄໍາຖາມຕິດຕາມ: "ທ່ານສາມາດເຮັດບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນເພື່ອໃຫ້ມັນຄ້າຍຄືກັບ Google Spanner, ແຕ່ຍັງເຮັດວຽກກັບ Django ORM?"

ທາງເລືອກການແກ້ໄຂ 0

ສິ່ງທໍາອິດທີ່ເຂົ້າມາໃນໃຈ:

• ຢູ່ພາຍໃນ CloudSQL;
• ຈະບໍ່ມີການຈໍາລອງແບບກໍ່ສ້າງລະຫວ່າງພາກພື້ນໃນຮູບແບບໃດກໍ່ຕາມ;
• ພະຍາຍາມຄັດຕິດ replica ກັບ Cloud SQL ທີ່ມີຢູ່ແລ້ວໂດຍ PostgreSQL;
• ເປີດຕົວຢ່າງ PostgreSQL ຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ ແລະບາງບ່ອນ, ແຕ່ຢ່າງນ້ອຍຢ່າແຕະຕ້ອງແມ່ແບບ.

ອະນິຈາ, ມັນບໍ່ສາມາດເຮັດໄດ້, ເພາະວ່າບໍ່ມີການເຂົ້າເຖິງເຈົ້າພາບ (ມັນຢູ່ໃນໂຄງການທີ່ແຕກຕ່າງກັນທັງຫມົດ) - pg_hba ແລະອື່ນໆ, ແລະບໍ່ມີການເຂົ້າເຖິງພາຍໃຕ້ superuser.

ທາງເລືອກການແກ້ໄຂ 1

ຫຼັງຈາກການສະທ້ອນຕື່ມອີກແລະຄໍານຶງເຖິງສະຖານະການທີ່ຜ່ານມາ, ການຝຶກອົບຮົມຄວາມຄິດໄດ້ປ່ຽນແປງບາງຢ່າງ:

• ພວກເຮົາຍັງພະຍາຍາມຢູ່ພາຍໃນ CloudSQL, ແຕ່ພວກເຮົາກໍາລັງປ່ຽນເປັນ MySQL, ເພາະວ່າ Cloud SQL ໂດຍ MySQL ມີແມ່ບົດພາຍນອກ, ເຊິ່ງ:

— ເປັນຕົວແທນສໍາລັບ MySQL ພາຍນອກ;
- ເບິ່ງຄືວ່າເປັນຕົວຢ່າງ MySQL;
- invented ສໍາ​ລັບ​ການ​ເຄື່ອນ​ຍ້າຍ​ຂໍ້​ມູນ​ຈາກ​ຟັງ​ອື່ນໆ​ຫຼື​ໃນ​ສະ​ຖານ​ທີ່​.

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

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

ທາງເລືອກການແກ້ໄຂ 2

ເນື່ອງຈາກມັນບໍ່ສາມາດຢູ່ໃນຂອບຂອງ Cloud SQL ໄດ້, ພວກເຮົາພະຍາຍາມສ້າງຄວາມຕ້ອງການສໍາລັບການແກ້ໄຂການປະນີປະນອມ. ຂໍ້​ກໍາ​ນົດ​ໄດ້​ກາຍ​ເປັນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ເຮັດວຽກຢູ່ໃນ Kubernetes, ການນໍາໃຊ້ສູງສຸດຂອງຊັບພະຍາກອນແລະຄວາມສາມາດຂອງ Kubernetes (DCS, ...) ແລະ GCP (LB, ... );
• ຂາດ ballast ຈາກຊໍ່ຂອງສິ່ງທີ່ບໍ່ຈໍາເປັນໃນຟັງເຊັ່ນ HA proxy;
• ຄວາມສາມາດໃນການດໍາເນີນການ PostgreSQL ຫຼື MySQL ໃນພາກພື້ນ HA ຕົ້ນຕໍ; ໃນພາກພື້ນອື່ນໆ - HA ຈາກ RR ຂອງພາກພື້ນຕົ້ນຕໍບວກກັບສໍາເນົາຂອງມັນ (ສໍາລັບຄວາມຫນ້າເຊື່ອຖື);
• multi master (ຂ້ອຍບໍ່ຢາກຕິດຕໍ່ກັບລາວ, ແຕ່ມັນບໍ່ສໍາຄັນຫຼາຍ)

.
ເປັນຜົນມາຈາກຄວາມຕ້ອງການເຫຼົ່ານີ້, pDBMS ທີ່ເຫມາະສົມແລະທາງເລືອກການຜູກມັດ:

• MySQL Galera;
• CockroachDB;
• ເຄື່ອງມື PostgreSQL

:
- pgpool-II;
— Patroni.

MySQL Galera

ເທກໂນໂລຍີ MySQL Galera ຖືກພັດທະນາໂດຍ Codership ແລະເປັນ plugin ສໍາລັບ InnoDB. ລັກສະນະພິເສດ:

• multi master;
• ການຈໍາລອງແບບ synchronous;
• ອ່ານຈາກ node ໃດ;
• ການບັນທຶກກັບ node ໃດ;
• ກົນໄກ HA ກໍ່ສ້າງໃນ;
• ມີຕາຕະລາງ Helm ຈາກ Bitnami.

cockroachDB

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

ໂບນັດທີ່ດີແມ່ນການສະຫນັບສະຫນູນສໍາລັບໂປໂຕຄອນການເຊື່ອມຕໍ່ post-gress.

Pgpool

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

Patroni

ນີ້ແມ່ນສິ່ງສຸດທ້າຍທີ່ຕາຂອງຂ້ອຍຕົກຢູ່ໃນ, ແລະ, ຍ້ອນວ່າມັນໄດ້ຫັນອອກ, ບໍ່ໄດ້ຢູ່ໃນ vain. Patroni ແມ່ນຜົນປະໂຫຍດແຫຼ່ງເປີດ, ເຊິ່ງເປັນສິ່ງຈໍາເປັນ Python daemon ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຮັກສາກຸ່ມ PostgreSQL ໂດຍອັດຕະໂນມັດດ້ວຍປະເພດຕ່າງໆຂອງການຈໍາລອງແລະການປ່ຽນບົດບາດອັດຕະໂນມັດ. ສິ່ງທີ່ໄດ້ຫັນອອກເປັນທີ່ຫນ້າສົນໃຈຫຼາຍ, ເນື່ອງຈາກວ່າມັນປະສົມປະສານໄດ້ດີກັບ cuber ແລະບໍ່ໄດ້ແນະນໍາຫນ່ວຍງານໃຫມ່ໃດໆ.

ເຈົ້າເລືອກອັນໃດໃນທີ່ສຸດ?

ທາງເລືອກບໍ່ແມ່ນເລື່ອງງ່າຍ:

1. cockroachDB - ໄຟ, ແຕ່ຊ້ໍາ;
2. MySQL Galera - ຍັງບໍ່ດີ, ມັນຖືກນໍາໃຊ້ໃນຫຼາຍບ່ອນ, ແຕ່ MySQL;
3. Pgpool — ຫຼາຍ​ຂອງ​ຫນ່ວຍ​ງານ​ທີ່​ບໍ່​ຈໍາ​ເປັນ​, ດັ່ງ​ນັ້ນ​ການ​ເຊື່ອມ​ໂຍງ​ກັບ​ຟັງ​ແລະ K8s​;
4. Patroni - ການເຊື່ອມໂຍງທີ່ດີເລີດກັບ K8s, ບໍ່ມີຫນ່ວຍງານທີ່ບໍ່ຈໍາເປັນ, ປະສົມປະສານໄດ້ດີກັບ GCP LB.

ດັ່ງນັ້ນ, ທາງເລືອກໄດ້ຕົກຢູ່ໃນ Patroni.

ການຄົ້ນພົບ

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

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

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