Google Cloud Spanner: ດີ, ບໍ່ດີ, ຂີ້ຮ້າຍ

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

ຈັດພີມມາໃນເບື້ອງຕົ້ນໃນ ບລັອກ Lightspeed HQ.

ໃນຖານະເປັນບໍລິສັດທີ່ສະຫນອງການແກ້ໄຂບັນຫາ POS ເທິງເມຄສໍາລັບຮ້ານຂາຍຍ່ອຍ, ຮ້ານອາຫານ, ແລະຜູ້ຄ້າອອນໄລນ໌ທົ່ວໂລກ, Lightspeed ໃຊ້ເວທີຖານຂໍ້ມູນຫຼາຍປະເພດເພື່ອຄວາມຫລາກຫລາຍຂອງການເຮັດທຸລະກໍາ, ການວິເຄາະ, ແລະການນໍາໃຊ້ການຄົ້ນຫາ. ແຕ່ລະແພລະຕະຟອມຖານຂໍ້ມູນເຫຼົ່ານີ້ມີຈຸດແຂງແລະຈຸດອ່ອນຂອງຕົນເອງ. ດັ່ງນັ້ນ, ເມື່ອ Google ນໍາສະເຫນີ Cloud Spanner ສູ່ຕະຫຼາດ - ລັກສະນະທີ່ໂດດເດັ່ນທີ່ບໍ່ເຫັນຢູ່ໃນໂລກຂອງຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ, ເຊັ່ນ: ການຂະຫຍາຍອອກຕາມລວງນອນ virtually unlimited ແລະ 99,999% ຂໍ້ຕົກລົງລະດັບການບໍລິການ (SLA) , ພວກເຮົາບໍ່ສາມາດຜ່ານໂອກາດທີ່ຈະມີນາງຢູ່ໃນມືຂອງພວກເຮົາ!

ເພື່ອໃຫ້ພາບລວມທີ່ສົມບູນແບບຂອງປະສົບການຂອງພວກເຮົາກັບ Cloud Spanner, ເຊັ່ນດຽວກັນກັບເງື່ອນໄຂການປະເມີນຜົນທີ່ພວກເຮົາໃຊ້, ພວກເຮົາຈະກວມເອົາຫົວຂໍ້ຕໍ່ໄປນີ້:

1. ເງື່ອນໄຂການປະເມີນຜົນຂອງພວກເຮົາ
2. Cloud Spanner ໂດຍຫຍໍ້
3. ການປະເມີນຂອງພວກເຮົາ
4. ການຄົ້ນພົບຂອງພວກເຮົາ

1. ເງື່ອນໄຂການປະເມີນຜົນຂອງພວກເຮົາ

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

• ເປັນການທົດແທນການແກ້ໄຂບັນຫາຖານຂໍ້ມູນ SQL ແບບດັ້ງເດີມ (ທົ່ວໄປ).
• ເປັນການແກ້ໄຂ OLTP ທີ່ເປີດໃຊ້ OLAP

ຫມາຍເຫດ: ເພື່ອຄວາມສະດວກໃນການປຽບທຽບ, ບົດຄວາມນີ້ຈະປຽບທຽບ Cloud Spanner ກັບ MySQL variants ຂອງ GCP Cloud SQL ແລະ Amazon AWS RDS solution family.

ການນໍາໃຊ້ Cloud Spanner ເປັນການທົດແທນການແກ້ໄຂຖານຂໍ້ມູນ SQL ແບບດັ້ງເດີມ

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

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

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

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

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

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

ລັກສະນະເຕັມທີ່ DBMS ເປັນບໍລິການ ຕ້ອງໄດ້ຮັບການປະເມີນຈາກທັດສະນະທີ່ແຕກຕ່າງກັນ. ເປັນພື້ນຖານ, ພວກເຮົາໄດ້ເອົາ DBMS ທີ່ນິຍົມທີ່ສຸດໃນຄລາວ - ສໍາລັບ Google, GCP Cloud SQL ແລະສໍາລັບ Amazon, AWS RDS. ໃນການປະເມີນຜົນຂອງພວກເຮົາ, ພວກເຮົາໄດ້ສຸມໃສ່ປະເພດດັ່ງຕໍ່ໄປນີ້:

• ແຜນທີ່ຄຸນນະສົມບັດ: ຂອບເຂດ SQL, DDL, DML; ຫ້ອງສະຫມຸດການເຊື່ອມຕໍ່ / ຕົວເຊື່ອມຕໍ່, ການສະຫນັບສະຫນູນການເຮັດທຸລະກໍາ, ແລະອື່ນໆ.
• ການສະຫນັບສະຫນູນການພັດທະນາ: ຄວາມງ່າຍຂອງການພັດທະນາແລະການທົດສອບ.
• ສະຫນັບສະຫນູນການບໍລິຫານ: ການຈັດການຕົວຢ່າງເຊັ່ນ: ການຂະຫຍາຍຂຶ້ນ / ລົງແລະການຍົກລະດັບຕົວຢ່າງ; SLA, ສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູ; ຄວາມ​ປອດ​ໄພ / ການ​ຄວບ​ຄຸມ​ການ​ເຂົ້າ​ເຖິງ​.

ການນໍາໃຊ້ Cloud Spanner ເປັນການແກ້ໄຂ OLTP ທີ່ເປີດໃຊ້ OLAP

ໃນຂະນະທີ່ Google ບໍ່ໄດ້ລະບຸຢ່າງຊັດເຈນວ່າ Cloud Spanner ແມ່ນສໍາລັບການວິເຄາະ, ມັນແບ່ງປັນຄຸນລັກສະນະບາງຢ່າງກັບເຄື່ອງຈັກອື່ນໆເຊັ່ນ Apache Impala & Kudu ແລະ YugaByte ທີ່ຖືກອອກແບບມາສໍາລັບວຽກງານ OLAP.

ເຖິງແມ່ນວ່າມີໂອກາດເລັກນ້ອຍທີ່ Cloud Spanner ໄດ້ລວມເອົາເຄື່ອງຈັກ HTAP (Hybrid Transactional/Analytic Processing) ທີ່ສອດຄ່ອງກັນກັບຊຸດຄຸນສົມບັດ OLAP (ຫຼາຍ ຫຼືໜ້ອຍກວ່າ) ທີ່ໃຊ້ໄດ້, ພວກເຮົາຄິດວ່າມັນສົມຄວນໄດ້ຮັບຄວາມສົນໃຈຂອງພວກເຮົາ.

ດ້ວຍວ່າຢູ່ໃນໃຈ, ພວກເຮົາໄດ້ເບິ່ງປະເພດຕໍ່ໄປນີ້:

• ການໂຫຼດຂໍ້ມູນ, ດັດສະນີແລະການແບ່ງສ່ວນສະຫນັບສະຫນູນ
• ການປະຕິບັດການສອບຖາມ ແລະ DML

2. Cloud Spanner ໂດຍຫຍໍ້

Google Spanner ເປັນລະບົບການຈັດການຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງແບບກຸ່ມ (RDBMS) ທີ່ Google ໃຊ້ສໍາລັບການບໍລິການຂອງຕົນເອງຫຼາຍອັນ. Google ໄດ້ເຮັດໃຫ້ມັນເປີດເຜີຍຕໍ່ສາທາລະນະກັບຜູ້ໃຊ້ Google Cloud Platform ໃນຕົ້ນປີ 2017.

ນີ້ແມ່ນບາງຄຸນລັກສະນະຂອງ Cloud Spanner:

• ມີຄວາມສອດຄ່ອງສູງ, ຂະຫຍາຍກຸ່ມ RDBMS: ໃຊ້ການ synchronization ເວລາຮາດແວເພື່ອຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນ.
• ສະຫນັບສະຫນູນການເຮັດທຸລະກໍາຂ້າມຕາຕະລາງ: ການເຮັດທຸລະກໍາສາມາດຂະຫຍາຍຕາຕະລາງຫຼາຍ - ບໍ່ຈໍາເປັນຕ້ອງຈໍາກັດຢູ່ໃນຕາຕະລາງດຽວ (ບໍ່ຄືກັບ Apache HBase ຫຼື Apache Kudu).
• ຕາຕະລາງພື້ນຖານຫຼັກ: ຕາຕະລາງທັງຫມົດຕ້ອງມີລະຫັດຫຼັກ (PC), ເຊິ່ງສາມາດປະກອບດ້ວຍຖັນຕາຕະລາງຫຼາຍ. ຂໍ້ມູນ Tabular ຖືກເກັບໄວ້ໃນຄໍາສັ່ງ PC, ເຊິ່ງເຮັດໃຫ້ມັນມີປະສິດທິພາບຫຼາຍແລະໄວສໍາລັບການຄົ້ນຫາ PC. ເຊັ່ນດຽວກັນກັບລະບົບອື່ນໆທີ່ໃຊ້ PC, ການປະຕິບັດຕ້ອງໄດ້ຮັບການສ້າງແບບຈໍາລອງຕໍ່ກັບກໍລະນີການນໍາໃຊ້ preconceived ເພື່ອໃຫ້ບັນລຸໄດ້ ປະສິດທິພາບທີ່ດີທີ່ສຸດ.
• ຕາຕະລາງທີ່ມີເສັ້ນດ່າງ: ຕາຕະລາງສາມາດມີຄວາມເພິ່ງພາອາໄສທາງດ້ານຮ່າງກາຍເຊິ່ງກັນແລະກັນ. ແຖວຂອງຕາຕະລາງເດັກນ້ອຍສາມາດຖືກຈັບຄູ່ກັບແຖວຂອງຕາຕະລາງພໍ່ແມ່. ວິທີການນີ້ເລັ່ງການຄົ້ນຫາຄວາມສໍາພັນທີ່ສາມາດກໍານົດໄດ້ໃນຂັ້ນຕອນການສ້າງແບບຈໍາລອງຂໍ້ມູນ, ຕົວຢ່າງ, ເມື່ອວາງລູກຄ້າແລະໃບເກັບເງິນຂອງພວກເຂົາຮ່ວມກັນ.
• ດັດຊະນີ: Cloud Spanner ຮອງຮັບດັດຊະນີຂັ້ນສອງ. ດັດຊະນີປະກອບດ້ວຍຖັນທີ່ຖືກດັດສະນີ ແລະຖັນ PC ທັງໝົດ. ທາງເລືອກອື່ນ, ດັດຊະນີຍັງສາມາດບັນຈຸຖັນອື່ນໆທີ່ບໍ່ແມ່ນດັດສະນີ. ດັດຊະນີສາມາດຖືກແຊກແຊງກັບຕາຕະລາງແມ່ເພື່ອເລັ່ງການສອບຖາມ. ຂໍ້ຈໍາກັດຫຼາຍຢ່າງນໍາໃຊ້ກັບດັດສະນີ, ເຊັ່ນວ່າຈໍານວນສູງສຸດຂອງຖັນເພີ່ມເຕີມທີ່ສາມາດຖືກເກັບໄວ້ໃນດັດສະນີ. ນອກຈາກນີ້, ການສອບຖາມຜ່ານດັດສະນີອາດຈະບໍ່ກົງໄປກົງມາຄືກັບ RDBMSs ອື່ນໆ.

“Cloud Spanner ເລືອກດັດສະນີອັດຕະໂນມັດສະເພາະໃນກໍລະນີທີ່ຫາຍາກ. ໂດຍສະເພາະ, Cloud Spanner ບໍ່ໄດ້ເລືອກດັດຊະນີທີສອງໂດຍອັດຕະໂນມັດຖ້າການສອບຖາມຮ້ອງຂໍຖັນໃດໆທີ່ບໍ່ໄດ້ເກັບໄວ້ໃນ. ດັດຊະນີ ".

• ຂໍ້ຕົກລົງລະດັບການບໍລິການ (SLA): ການນຳໃຊ້ພາກພື້ນດຽວກັບ 99,99% SLA; ການນຳໃຊ້ຫຼາຍພາກພື້ນດ້ວຍ SLA 99,999%. ໃນຂະນະທີ່ SLA ຕົວຂອງມັນເອງແມ່ນພຽງແຕ່ຂໍ້ຕົກລົງແລະບໍ່ແມ່ນການຄໍ້າປະກັນຂອງປະເພດໃດກໍ່ຕາມ, ຂ້ອຍເຊື່ອວ່າຄົນ Google ມີຂໍ້ມູນບາງຢ່າງທີ່ຍາກໃນການຮຽກຮ້ອງທີ່ເຂັ້ມແຂງ. (ສໍາລັບການອ້າງອີງ, 99,999% ຫມາຍຄວາມວ່າ 26,3 ວິນາທີຂອງການຢຸດການບໍລິການຕໍ່ເດືອນ.)
• ເພີ່ມເຕີມ: https://cloud.google.com/spanner/

ຫມາຍເຫດ: ໂຄງການ Apache Tephra ເພີ່ມການສະຫນັບສະຫນູນການເຮັດທຸລະກໍາແບບພິເສດໃຫ້ກັບ Apache HBase (ປະຈຸບັນຍັງປະຕິບັດຢູ່ໃນ Apache Phoenix ເປັນເບຕ້າ).

3. ການປະເມີນຂອງພວກເຮົາ

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

ພວກເຮົາໃຫ້ຄະແນນ Cloud Spanner ເປັນການທົດແທນ Sharded MySQL

Google Cloud SQL ແລະ Amazon AWS RDS, ສອງຖານຂໍ້ມູນ OLTP ທີ່ນິຍົມທີ່ສຸດໃນຕະຫຼາດຄລາວ, ມີຊຸດຄຸນສົມບັດຂະຫນາດໃຫຍ່ຫຼາຍ. ຢ່າງໃດກໍຕາມ, ເພື່ອຂະຫຍາຍຖານຂໍ້ມູນເຫຼົ່ານີ້ເກີນຂະຫນາດຂອງ node ດຽວ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ປະຕິບັດການແບ່ງປັນຄໍາຮ້ອງສະຫມັກ. ວິທີການນີ້ສ້າງຄວາມສັບສົນເພີ່ມເຕີມສໍາລັບທັງຄໍາຮ້ອງສະຫມັກແລະການບໍລິຫານ. ພວກເຮົາໄດ້ເບິ່ງວິທີການ Spanner ເຫມາະສົມກັບສະຖານະການຂອງການລວມເອົາຫຼາຍ shards ເຂົ້າໄປໃນຕົວຢ່າງດຽວແລະລັກສະນະໃດ (ຖ້າມີ) ອາດຈະຕ້ອງເສຍສະລະ.

ສະຫນັບສະຫນູນ SQL, DML ແລະ DDL, ເຊັ່ນດຽວກັນກັບຕົວເຊື່ອມຕໍ່ແລະຫ້ອງສະຫມຸດບໍ?

ທໍາອິດ, ເມື່ອເລີ່ມຕົ້ນດ້ວຍຖານຂໍ້ມູນໃດກໍ່ຕາມ, ທ່ານຈໍາເປັນຕ້ອງສ້າງແບບຈໍາລອງຂໍ້ມູນ. ຖ້າທ່ານຄິດວ່າທ່ານສາມາດເຊື່ອມຕໍ່ JDBC Spanner ກັບເຄື່ອງມື SQL ທີ່ທ່ານມັກ, ທ່ານຈະພົບວ່າທ່ານສາມາດສອບຖາມຂໍ້ມູນຂອງທ່ານກັບມັນ, ແຕ່ທ່ານບໍ່ສາມາດໃຊ້ມັນເພື່ອສ້າງຕາຕະລາງຫຼືການປັບປຸງ (DDL) ຫຼືໃສ່ / ປັບປຸງ / ລຶບ. ການດໍາເນີນງານ (DML). JDBC ຢ່າງເປັນທາງການຂອງ Google ບໍ່ສະຫນັບສະຫນູນທັງສອງ.

"ປະຈຸບັນໄດເວີບໍ່ຮອງຮັບຄໍາຖະແຫຼງການ DML ຫຼື DDL."
ເອກະສານ Spanner

ສະຖານະການບໍ່ດີຂຶ້ນກັບ GCP console - ທ່ານພຽງແຕ່ສາມາດສົ່ງຄໍາຖາມ SELECT. ໂຊກດີມີຜູ້ຂັບຂີ່ JDBC ທີ່ມີການສະຫນັບສະຫນູນ DML ແລະ DDL ຈາກຊຸມຊົນລວມທັງການເຮັດທຸລະກໍາ github.com/olavloite/spanner-jdbc. ໃນຂະນະທີ່ຄົນຂັບນີ້ເປັນປະໂຫຍດທີ່ສຸດ, ການບໍ່ມີຕົວຂັບ JDBC ຂອງ Google ຂອງຕົນເອງແມ່ນຫນ້າປະຫລາດໃຈ. ໂຊກດີ, Google ສະຫນອງການສະຫນັບສະຫນູນຫ້ອງສະຫມຸດລູກຄ້າຢ່າງກວ້າງຂວາງ (ອີງໃສ່ gRPC): C#, Go, Java, node.js, PHP, Python, ແລະ Ruby.

ການໃຊ້ APIs ແບບກຳນົດເອງຂອງ Cloud Spanner (ເນື່ອງຈາກຂາດ DDL ແລະ DML ໃນ JDBC) ສົ່ງຜົນໃຫ້ມີຂໍ້ຈຳກັດບາງສ່ວນຂອງລະຫັດ ເຊັ່ນ: ການເຊື່ອມໂຍງການເຊື່ອມຕໍ່ ຫຼືກອບການຜູກມັດຖານຂໍ້ມູນ (ເຊັ່ນ: Spring MVC). ໂດຍທົ່ວໄປແລ້ວ, ເມື່ອໃຊ້ JDBC, ທ່ານສາມາດເລືອກສະນຸກເກີການເຊື່ອມຕໍ່ທີ່ທ່ານມັກ (ເຊັ່ນ: HikariCP, DBCP, C3PO, ແລະອື່ນໆ) ທີ່ໄດ້ຮັບການທົດສອບແລະເຮັດວຽກໄດ້ດີ. ໃນກໍລະນີຂອງ APIs Spanner ແບບກໍານົດເອງ, ພວກເຮົາຕ້ອງອີງໃສ່ກອບ / ການຜູກມັດ / ເຊດຊັນທີ່ພວກເຮົາໄດ້ສ້າງຕົວເອງ.

ການອອກແບບຮັດກຸມຫຼັກ (PC) ຊ່ວຍໃຫ້ Cloud Spanner ໄວຫຼາຍເມື່ອເຂົ້າເຖິງຂໍ້ມູນຜ່ານ PC, ແຕ່ຍັງແນະນໍາບາງບັນຫາການສອບຖາມ.

• ທ່ານບໍ່ສາມາດອັບເດດຄ່າຂອງລະຫັດຫຼັກໄດ້; ກ່ອນ​ອື່ນ​ຫມົດ​ທ່ານ​ຕ້ອງ​ໄດ້​ລົບ​ການ​ເຂົ້າ PC ຕົ້ນ​ສະ​ບັບ​ແລະ​ໃສ່​ຄືນ​ໃຫມ່​ທີ່​ມີ​ຄ່າ​ໃຫມ່​. (ນີ້​ແມ່ນ​ຄ້າຍ​ຄື​ກັນ​ກັບ​ຖານ​ຂໍ້​ມູນ PC oriented ອື່ນໆ / ເຄື່ອງ​ຈັກ​ເກັບ​ຮັກ​ສາ​.)
• ການອັບເດດ ແລະລຶບຂໍ້ຄວາມໃດໆກໍຕາມຈະຕ້ອງລະບຸ PC ຢູ່ໃນບ່ອນໃດ, ສະນັ້ນ, ຈຶ່ງບໍ່ສາມາດຫວ່າງເປົ່າໄດ້ DELETE ຂໍ້ຄວາມທັງໝົດ - ມັນຕ້ອງມີການສອບຖາມຍ່ອຍສະເໝີ, ຕົວຢ່າງ: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• ການຂາດຕົວເລືອກການເພີ່ມອັດຕະໂນມັດຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນທີ່ກໍານົດລໍາດັບສໍາລັບພາກສະຫນາມ PC. ສໍາລັບການນີ້ເຮັດວຽກ, ມູນຄ່າທີ່ສອດຄ້ອງກັນຕ້ອງຖືກສ້າງຢູ່ໃນດ້ານຄໍາຮ້ອງສະຫມັກ.

ດັດຊະນີທີສອງ?

Google Cloud Spanner ມີການສະຫນັບສະຫນູນໃນຕົວສໍາລັບດັດສະນີຮອງ. ນີ້ແມ່ນຄຸນສົມບັດທີ່ດີຫຼາຍທີ່ບໍ່ສະເຫມີຢູ່ໃນເຕັກໂນໂລຢີອື່ນໆ. Apache Kudu ປະຈຸບັນບໍ່ສະຫນັບສະຫນູນດັດສະນີຂັ້ນສອງທັງຫມົດ, ແລະ Apache HBase ບໍ່ສະຫນັບສະຫນູນດັດສະນີໂດຍກົງ, ແຕ່ສາມາດເພີ່ມພວກມັນຜ່ານ Apache Phoenix.

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

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

ການເປັນຕົວແທນ?

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

ເບິ່ງເອກະສານ Cloud Spanner ສໍາລັບພາກສ່ວນທີ່ລາຍລະອຽດກ່ຽວກັບໂຄຕ້າ ແລະຂໍ້ຈໍາກັດ (spanner/quotas), ມີຫນຶ່ງໂດຍສະເພາະທີ່ສາມາດເປັນບັນຫາສໍາລັບບາງຄໍາຮ້ອງສະຫມັກ: Cloud Spanner ອອກຈາກກ່ອງມີຖານຂໍ້ມູນສູງສຸດ 100 ຕໍ່ຕົວຢ່າງ. ແນ່ນອນ, ນີ້ສາມາດເປັນອຸປະສັກທີ່ສໍາຄັນສໍາລັບຖານຂໍ້ມູນທີ່ຖືກອອກແບບມາເພື່ອຂະຫນາດຫຼາຍກວ່າ 100 ຖານຂໍ້ມູນ. ໂຊກດີ, ຫຼັງຈາກເວົ້າກັບຜູ້ຕາງຫນ້າດ້ານວິຊາການຂອງ Google ຂອງພວກເຮົາ, ພວກເຮົາພົບວ່າຂອບເຂດຈໍາກັດນີ້ສາມາດເພີ່ມຂຶ້ນເກືອບທຸກມູນຄ່າໂດຍຜ່ານການສະຫນັບສະຫນູນຂອງ Google.

ສະຫນັບສະຫນູນການພັດທະນາ?

Cloud Spanner ສະຫນອງການສະຫນັບສະຫນູນພາສາການຂຽນໂປຼແກຼມທີ່ດີສໍາລັບການເຮັດວຽກກັບ API ຂອງມັນ. ຫ້ອງສະຫມຸດທີ່ໄດ້ຮັບການສະຫນັບສະຫນູນຢ່າງເປັນທາງການແມ່ນຢູ່ໃນພື້ນທີ່ຂອງ C#, Go, Java, node.js, PHP, Python, ແລະ Ruby. ເອກະສານແມ່ນມີລາຍລະອຽດພໍສົມຄວນ, ແຕ່ເຊັ່ນດຽວກັນກັບເຕັກໂນໂລຢີທີ່ທັນສະ ໄໝ ອື່ນໆ, ຊຸມຊົນແມ່ນຂ້ອນຂ້າງນ້ອຍເມື່ອທຽບໃສ່ກັບເຕັກໂນໂລຢີຖານຂໍ້ມູນທີ່ນິຍົມຫລາຍທີ່ສຸດ, ເຊິ່ງສາມາດສົ່ງຜົນໃຫ້ໃຊ້ເວລາຫຼາຍໃນກໍລະນີທີ່ໃຊ້ທົ່ວໄປຫນ້ອຍຫຼືບັນຫາ.

ດັ່ງນັ້ນ, ການສະຫນັບສະຫນູນການພັດທະນາທ້ອງຖິ່ນແມ່ນຫຍັງ?

ພວກເຮົາບໍ່ໄດ້ຊອກຫາວິທີທີ່ຈະສ້າງຕົວຢ່າງ Cloud Spanner ຢູ່ໃນສະຖານທີ່. ໃກ້ທີ່ສຸດທີ່ພວກເຮົາໄດ້ຮັບແມ່ນຮູບພາບ Docker cockroachDBເຊິ່ງແມ່ນຄ້າຍຄືກັນໃນຫຼັກການ, ແຕ່ແຕກຕ່າງກັນຫຼາຍໃນການປະຕິບັດ. ຕົວຢ່າງ CockroachDB ສາມາດໃຊ້ PostgreSQL JDBC. ເນື່ອງຈາກສະພາບແວດລ້ອມການພັດທະນາຄວນຈະໃກ້ຊິດເທົ່າທີ່ເປັນໄປໄດ້ກັບສະພາບແວດລ້ອມການຜະລິດ, Cloud Spanner ແມ່ນບໍ່ເຫມາະສົມເພາະວ່າທ່ານຈໍາເປັນຕ້ອງອີງໃສ່ຕົວຢ່າງ Spanner ຢ່າງເຕັມທີ່. ເພື່ອປະຫຍັດຄ່າໃຊ້ຈ່າຍ, ທ່ານສາມາດເລືອກຕົວຢ່າງພາກພື້ນດຽວ.

ສະຫນັບສະຫນູນການບໍລິຫານ?

ການສ້າງຕົວຢ່າງ Cloud Spanner ແມ່ນງ່າຍດາຍຫຼາຍ. ທ່ານ​ພຽງ​ແຕ່​ຕ້ອງ​ການ​ທີ່​ຈະ​ເລືອກ​ເອົາ​ລະ​ຫວ່າງ​ການ​ສ້າງ​ຫຼາຍ​ພາກ​ພື້ນ​ຫຼື​ພາກ​ພື້ນ​ດຽວ​, ລະ​ບຸ​ພາກ​ພື້ນ (s​) ແລະ​ຈໍາ​ນວນ​ຂອງ nodes​. ໃນເວລາໜ້ອຍກວ່າໜຶ່ງນາທີ, ຕົວຢ່າງຈະເປີດຂຶ້ນ ແລະເຮັດວຽກ.

ການວັດແທກຂັ້ນຕົ້ນຫຼາຍອັນແມ່ນມີໃຫ້ໂດຍກົງຢູ່ໃນໜ້າ Spanner ໃນ Google Console. ມຸມເບິ່ງລາຍລະອຽດເພີ່ມເຕີມແມ່ນມີຢູ່ຜ່ານ Stackdriver, ບ່ອນທີ່ທ່ານສາມາດກໍານົດຂອບເຂດ metric ແລະນະໂຍບາຍເຕືອນໄດ້.

ການເຂົ້າເຖິງຊັບພະຍາກອນ?

MySQL ສະຫນອງການຕັ້ງຄ່າການອະນຸຍາດ / ບົດບາດຂອງຜູ້ໃຊ້ຢ່າງກວ້າງຂວາງແລະລະອຽດຫຼາຍ. ທ່ານສາມາດປັບແຕ່ງການເຂົ້າເຖິງຕາຕະລາງສະເພາະ, ຫຼືແມ້ກະທັ້ງພຽງແຕ່ຊຸດຍ່ອຍຂອງຖັນຂອງມັນ. Cloud Spanner ໃຊ້ເຄື່ອງມືຂອງ Google Identity & Access Management (IAM), ເຊິ່ງພຽງແຕ່ອະນຸຍາດໃຫ້ທ່ານຕັ້ງນະໂຍບາຍແລະການອະນຸຍາດໃນລະດັບສູງຫຼາຍ. ທາງເລືອກທີ່ລະອຽດທີ່ສຸດແມ່ນການອະນຸຍາດລະດັບຖານຂໍ້ມູນ, ເຊິ່ງບໍ່ເຫມາະສົມກັບກໍລະນີການຜະລິດສ່ວນໃຫຍ່. ຂໍ້ຈໍາກັດນີ້ບັງຄັບໃຫ້ທ່ານເພີ່ມມາດຕະການຄວາມປອດໄພເພີ່ມເຕີມໃສ່ລະຫັດ, ໂຄງສ້າງພື້ນຖານຂອງທ່ານ, ຫຼືທັງສອງເພື່ອປ້ອງກັນການນໍາໃຊ້ຊັບພະຍາກອນ Spanner ໂດຍບໍ່ມີການອະນຸຍາດ.

ສຳຮອງ?

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

ການປະຕິບັດການສອບຖາມ?

ພວກເຮົາໃຊ້ Yahoo! ເພື່ອໂຫຼດຂໍ້ມູນ ແລະທົດສອບແບບສອບຖາມ. Cloud Serving Benchmark. ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນ B YCSB workload ທີ່ມີອັດຕາສ່ວນການຂຽນ 95% ຫາ 5%.

* ການທົດສອບການໂຫຼດໄດ້ດໍາເນີນຢູ່ໃນ n1-standard-32 Compute Engine (CE) (32 vCPUs, ຫນ່ວຍຄວາມຈໍາ 120 GB) ແລະຕົວຢ່າງການທົດສອບບໍ່ເຄີຍເປັນຂໍ້ບົກຜ່ອງໃນການທົດສອບ.
** ຈໍາ​ນວນ​ສູງ​ສຸດ​ຂອງ​ກະ​ທູ້​ໃນ​ຫນຶ່ງ YCSB instance ແມ່ນ 400. ລວມ​ທັງ​ຫມົດ, ຫົກ​ຕົວ​ຢ່າງ​ຂະ​ຫນານ​ຂອງ​ການ​ທົດ​ສອບ YCSB ຕ້ອງ​ໄດ້​ຮັບ​ການ​ດໍາ​ເນີນ​ການ​ເພື່ອ​ໃຫ້​ໄດ້​ທັງ​ຫມົດ 2400 threads.

ຊອກຫາຢູ່ໃນຜົນໄດ້ຮັບ benchmark, ໂດຍສະເພາະການປະສົມປະສານຂອງການໂຫຼດ CPU ແລະ TPS, ພວກເຮົາເຫັນໄດ້ຊັດເຈນວ່າ Cloud Spanner scales ຂ້ອນຂ້າງດີ. ການໂຫຼດຂະຫນາດໃຫຍ່ທີ່ສ້າງຂຶ້ນໂດຍຈໍານວນຫລາຍຂອງກະທູ້ແມ່ນຖືກຊົດເຊີຍໂດຍຈໍານວນຈໍານວນຫລາຍຂອງ nodes ໃນກຸ່ມ Cloud Spanner. ເຖິງແມ່ນວ່າການ latency ເບິ່ງຂ້ອນຂ້າງສູງ, ໂດຍສະເພາະໃນເວລາທີ່ແລ່ນຢູ່ທີ່ 2400 threads, ມັນອາດຈະຈໍາເປັນຕ້ອງໄດ້ທົດສອບໃຫມ່ກັບ 6 ຕົວຢ່າງຂະຫນາດນ້ອຍຂອງເຄື່ອງຈັກຄອມພິວເຕີ້ເພື່ອໃຫ້ໄດ້ຕົວເລກທີ່ຖືກຕ້ອງກວ່າ. ແຕ່ລະຕົວຢ່າງຈະດໍາເນີນການຫນຶ່ງການທົດສອບ YCSB ແທນທີ່ຈະເປັນຕົວຢ່າງ CE ຂະຫນາດໃຫຍ່ຫນຶ່ງທີ່ມີ 6 ການທົດສອບຂະຫນານ. ນີ້ຈະເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການຈໍາແນກລະຫວ່າງການຊັກຊ້າຄໍາຮ້ອງຂໍຂອງ Cloud Spanner ແລະຄວາມລ່າຊ້າທີ່ເພີ່ມໂດຍການເຊື່ອມຕໍ່ເຄືອຂ່າຍລະຫວ່າງ Cloud Spanner ແລະ CE instance ທີ່ດໍາເນີນການທົດສອບ.

Cloud Spanner ເຮັດວຽກເປັນ OLAP ແນວໃດ?

ການແບ່ງສ່ວນ?

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

Cloud Spanner ບໍ່ຮອງຮັບການແບ່ງສ່ວນຕໍ່ se. ມັນແຍກຂໍ້ມູນພາຍໃນເປັນອັນທີ່ເອີ້ນວ່າ ແບ່ງປັນ-s ອີງໃສ່ຊ່ວງຫຼັກໆ. ການແບ່ງສ່ວນແມ່ນເຮັດໂດຍອັດຕະໂນມັດເພື່ອດຸ່ນດ່ຽງການໂຫຼດຢູ່ໃນກຸ່ມ Cloud Spanner. ຄຸນສົມບັດທີ່ມີປະໂຫຍດຫຼາຍຂອງ Cloud Spanner ແມ່ນການແບ່ງການໂຫຼດພື້ນຖານຂອງຕາຕະລາງຫຼັກ (ຕາຕະລາງທີ່ບໍ່ໄດ້ແຊກແຊງກັບອັນອື່ນ). Spanner ກວດພົບອັດຕະໂນມັດຖ້າມັນມີ ແບ່ງປັນ ຂໍ້​ມູນ​ທີ່​ຖືກ​ອ່ານ​ເລື້ອຍໆ​ກ​່​ວາ​ຂໍ້​ມູນ​ໃນ​ອື່ນໆ​ ແບ່ງປັນ-ah, ແລະອາດຈະຕັດສິນໃຈກ່ຽວກັບການແຍກຕ່າງຫາກຕື່ມອີກ. ດັ່ງນັ້ນ, nodes ຫຼາຍສາມາດມີສ່ວນຮ່ວມໃນການຮ້ອງຂໍ, ເຊິ່ງຍັງປະສິດທິຜົນເພີ່ມ throughput.

ກຳລັງໂຫຼດຂໍ້ມູນບໍ?

ວິທີການ Cloud Spanner ສໍາລັບຂໍ້ມູນຈໍານວນຫລາຍແມ່ນຄືກັນກັບການອັບໂຫລດປົກກະຕິ. ເພື່ອປະສິດທິພາບສູງສຸດ, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດຕາມຄໍາແນະນໍາບາງຢ່າງ, ລວມທັງ:

• ຈັດຮຽງຂໍ້ມູນຂອງທ່ານຕາມລະຫັດຫຼັກ.
• ແບ່ງພວກມັນດ້ວຍ 10*ຈໍານວນຂອງ nodes ພາກ​ສ່ວນ​ບຸກ​ຄົນ​.
• ສ້າງຊຸດຂອງວຽກງານຂອງພະນັກງານທີ່ໂຫຼດຂໍ້ມູນໃນຂະຫນານ.

ການໂຫຼດຂໍ້ມູນນີ້ໃຊ້ Cloud Spanner nodes ທັງໝົດ.

ພວກເຮົາໄດ້ໃຊ້ວຽກ A YCSB ເພື່ອສ້າງຊຸດຂໍ້ມູນ 10M ແຖວ.

* ການທົດສອບການໂຫຼດໄດ້ດໍາເນີນຢູ່ໃນເຄື່ອງຈັກຄອມພິວເຕີ້ n1-standard-32 (32 vCPUs, ຫນ່ວຍຄວາມຈໍາ 120 GB) ແລະຕົວຢ່າງການທົດສອບບໍ່ເຄີຍເປັນຂໍ້ບົກຜ່ອງໃນການທົດສອບ.
** A 1 node setup ແມ່ນບໍ່ແນະນໍາໃຫ້ສໍາລັບການເຮັດວຽກການຜະລິດໃດໆ.

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, Cloud Spanner ອັດຕະໂນມັດຂະບວນການແບ່ງປັນຂຶ້ນກັບການໂຫຼດຂອງພວກເຂົາ, ດັ່ງນັ້ນຜົນໄດ້ຮັບຈະປັບປຸງຫຼັງຈາກການທົດສອບຫຼາຍໆຄັ້ງຕິດຕໍ່ກັນ. ຜົນໄດ້ຮັບທີ່ນໍາສະເຫນີນີ້ແມ່ນຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດທີ່ພວກເຮົາໄດ້ຮັບ. ຊອກຫາຢູ່ໃນຕົວເລກຂ້າງເທິງ, ພວກເຮົາສາມາດເຫັນໄດ້ວ່າ Cloud Spanner scales (ດີ) ຍ້ອນວ່າຈໍານວນ nodes ໃນ cluster ເພີ່ມຂຶ້ນ. ຕົວເລກທີ່ໂດດເດັ່ນແມ່ນ latency ສະເລ່ຍຕໍ່າທີ່ສຸດ, ເຊິ່ງກົງກັນຂ້າມກັບຜົນໄດ້ຮັບຈາກວຽກປະສົມ (95% ອ່ານແລະ 5% ຂຽນ) ດັ່ງທີ່ອະທິບາຍໄວ້ໃນພາກຂ້າງເທິງ.

ປັບຂະໜາດ?

ການເພີ່ມ ແລະ ຫຼຸດຈຳນວນຂອງ Cloud Spanner nodes ເປັນວຽກທີ່ຄລິກດຽວ. ຖ້າທ່ານຕ້ອງການໂຫລດຂໍ້ມູນຢ່າງໄວວາ, ທ່ານອາດຈະຕ້ອງການພິຈາລະນາການເພີ່ມຕົວຢ່າງໃຫ້ສູງສຸດ (ໃນກໍລະນີຂອງພວກເຮົາມັນແມ່ນ 25 nodes ໃນພາກພື້ນສະຫະລັດ - ຕາເວັນອອກ) ແລະຫຼັງຈາກນັ້ນຫຼຸດລົງຈໍານວນຂອງ nodes ທີ່ເຫມາະສົມສໍາລັບການໂຫຼດປົກກະຕິຂອງທ່ານຫຼັງຈາກຂໍ້ມູນທັງຫມົດ. ໃນຖານຂໍ້ມູນ, ຈື່ໄວ້ວ່າ 2 TB/node limit.

ພວກເຮົາໄດ້ຖືກເຕືອນກ່ຽວກັບຂອບເຂດຈໍາກັດນີ້ເຖິງແມ່ນວ່າມີຖານຂໍ້ມູນຂະຫນາດນ້ອຍກວ່າຫຼາຍ. ຫຼັງຈາກການທົດສອບການໂຫຼດຫຼາຍໆຄັ້ງ, ຖານຂໍ້ມູນຂອງພວກເຮົາມີຂະຫນາດປະມານ 155 GB, ແລະເມື່ອຫຼຸດລົງເປັນ 1 node instance, ພວກເຮົາໄດ້ຮັບຂໍ້ຜິດພາດຕໍ່ໄປນີ້:

ພວກເຮົາສາມາດປັບຂະຫນາດລົງຈາກ 25 ຫາ 2 ຕົວຢ່າງ, ແຕ່ພວກເຮົາຕິດຢູ່ໃນສອງຂໍ້.

ການເພີ່ມ ແລະຫຼຸດຈຳນວນຂອງ nodes ໃນກຸ່ມ Cloud Spanner ສາມາດອັດຕະໂນມັດໂດຍໃຊ້ REST API. ນີ້ສາມາດເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບການຫຼຸດຜ່ອນການໂຫຼດທີ່ເພີ່ມຂຶ້ນໃນລະບົບໃນເວລາຫວ່າງ.

ການປະຕິບັດການສອບຖາມ OLAP?

ໃນເບື້ອງຕົ້ນພວກເຮົາວາງແຜນທີ່ຈະອຸທິດເວລາຢ່າງຫຼວງຫຼາຍໃຫ້ກັບການປະເມີນຜົນຂອງພວກເຮົາກ່ຽວກັບ Spanner ໃນສ່ວນນີ້. ຫຼັງຈາກສອງສາມ SELECT COUNT, ພວກເຮົາຮູ້ທັນທີວ່າການທົດສອບຈະສັ້ນແລະ Spanner ຈະບໍ່ເປັນເຄື່ອງຈັກທີ່ເຫມາະສົມສໍາລັບ OLAP. ໂດຍບໍ່ຄໍານຶງເຖິງຈໍານວນຂອງ nodes ໃນ cluster, ພຽງແຕ່ເລືອກຈໍານວນຂອງແຖວໃນຕາຕະລາງແຖວ 10M ໄດ້ໃຊ້ເວລາ 55 ຫາ 60 ວິນາທີ. ນອກຈາກນີ້, ການສອບຖາມໃດໆທີ່ຕ້ອງການຄວາມຊົງຈໍາເພີ່ມເຕີມເພື່ອເກັບຜົນໄດ້ຮັບລະດັບປານກາງລົ້ມເຫລວດ້ວຍຄວາມຜິດພາດ OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

ບາງຕົວເລກສໍາລັບການສອບຖາມ TPC-H ສາມາດພົບໄດ້ໃນບົດຄວາມຂອງ Todd Lipcon nosql-kudu-spanner-slides.html, slides 42 ແລະ 43. ຕົວເລກເຫຼົ່ານີ້ແມ່ນສອດຄ່ອງກັບຜົນໄດ້ຮັບຂອງພວກເຮົາເອງ (ຫນ້າເສຍດາຍ).

4. ການຄົ້ນພົບຂອງພວກເຮົາ

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

ເມື່ອພວກເຮົາເລີ່ມປະເມີນ Cloud Spanner, ພວກເຮົາຄາດວ່າຄຸນສົມບັດການຈັດການຂອງມັນຈະທຽບເທົ່າກັບ, ຫຼືຢ່າງຫນ້ອຍບໍ່ໄກຈາກການແກ້ໄຂ Google SQL ອື່ນໆ. ແຕ່ພວກເຮົາຕົກຕະລຶງໂດຍການຂາດການສໍາຮອງຂໍ້ມູນທີ່ສົມບູນແລະການຄວບຄຸມການເຂົ້າເຖິງຊັບພະຍາກອນທີ່ຈໍາກັດຫຼາຍ. ບໍ່ໄດ້ກ່າວເຖິງບໍ່ມີທັດສະນະ, ບໍ່ມີສະພາບແວດລ້ອມການພັດທະນາທ້ອງຖິ່ນ, ລໍາດັບທີ່ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ, JDBC ໂດຍບໍ່ມີການສະຫນັບສະຫນູນ DML ແລະ DDL, ແລະອື່ນໆ.

ດັ່ງນັ້ນ, ບ່ອນທີ່ຈະໄປສໍາລັບຜູ້ທີ່ຕ້ອງການຂະຫນາດຖານຂໍ້ມູນການເຮັດທຸລະກໍາ? ເບິ່ງ​ຄື​ວ່າ​ບໍ່​ມີ​ການ​ແກ້​ໄຂ​ດຽວ​ໃນ​ຕະ​ຫຼາດ​ທັນ​ທີ​ທີ່​ເຫມາະ​ສົມ​ກັບ​ກໍ​ລະ​ນີ​ການ​ນໍາ​ໃຊ້​ທັງ​ຫມົດ​. ມີຫຼາຍວິທີແກ້ໄຂປິດແລະແຫຼ່ງເປີດ (ບາງອັນທີ່ໄດ້ກ່າວມາໃນບົດຄວາມນີ້), ແຕ່ລະຄົນມີຈຸດແຂງແລະຈຸດອ່ອນຂອງຕົນເອງ, ແຕ່ບໍ່ມີໃຜສະເຫນີ SaaS ກັບ 99,999% SLA ແລະຄວາມສອດຄ່ອງສູງ. ຖ້າ SLA ສູງແມ່ນເປົ້າຫມາຍຕົ້ນຕໍຂອງທ່ານແລະທ່ານບໍ່ມີແນວໂນ້ມທີ່ຈະສ້າງການແກ້ໄຂຂອງທ່ານເອງສໍາລັບຫຼາຍໆ clouds, Cloud Spanner ອາດຈະເປັນການແກ້ໄຂທີ່ທ່ານກໍາລັງຊອກຫາ. ແຕ່ທ່ານຄວນຮູ້ເຖິງຂໍ້ຈໍາກັດຂອງມັນທັງຫມົດ.

ເພື່ອໃຫ້ມີຄວາມຍຸຕິທໍາ, Cloud Spanner ໄດ້ຖືກປ່ອຍອອກມາຕໍ່ສາທາລະນະພຽງແຕ່ໃນພາກຮຽນ spring ຂອງ 2017, ສະນັ້ນມັນສົມເຫດສົມຜົນທີ່ຈະຄາດຫວັງວ່າບາງຂໍ້ບົກພ່ອງໃນປະຈຸບັນຂອງມັນອາດຈະຫາຍໄປ (ຫວັງວ່າ), ແລະເມື່ອມັນເກີດຂຶ້ນ, ມັນອາດຈະມີການປ່ຽນແປງເກມ. ຫຼັງຈາກທີ່ທັງຫມົດ, Cloud Spanner ບໍ່ພຽງແຕ່ເປັນໂຄງການຂ້າງຄຽງສໍາລັບ Google. Google ໃຊ້ມັນເປັນພື້ນຖານສໍາລັບຜະລິດຕະພັນອື່ນໆຂອງ Google. ແລະເມື່ອບໍ່ດົນມານີ້ Google ໄດ້ປ່ຽນແທນ Megastore ໃນ Google Cloud Storage ດ້ວຍ Cloud Spanner, ມັນອະນຸຍາດໃຫ້ Google Cloud Storage ມີຄວາມສອດຄ່ອງສູງສໍາລັບລາຍການວັດຖຸໃນຂອບເຂດທົ່ວໂລກ (ເຊິ່ງບໍ່ແມ່ນກໍລະນີສໍາລັບ. Amazon ຂອງ S3).

ດັ່ງນັ້ນ, ຍັງມີຄວາມຫວັງ ... ພວກເຮົາຫວັງວ່າ.

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

ພວກເຮົາເຊີນທຸກຄົນມາຢ້ຽມຢາມຂອງພວກເຮົາ webinar ຟຣີ ໃນທີ່ພວກເຮົາຈະບອກທ່ານໃນລາຍລະອຽດກ່ຽວກັບຫຼັກສູດ "AWS ສໍາລັບນັກພັດທະນາ" ຈາກ OTUS.

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