NewSQL = NoSQL+ACID

ຈົນກ່ວາບໍ່ດົນມານີ້, Odnoklassniki ເກັບຮັກສາຂໍ້ມູນປະມານ 50 TB ທີ່ຖືກປຸງແຕ່ງໃນເວລາຈິງໃນ SQL Server. ສໍາລັບປະລິມານດັ່ງກ່າວ, ມັນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະສະຫນອງໄວແລະເຊື່ອຖືໄດ້, ແລະເຖິງແມ່ນວ່າການເຂົ້າເຖິງຄວາມລົ້ມເຫຼວຂອງສູນຂໍ້ມູນໂດຍໃຊ້ SQL DBMS. ໂດຍປົກກະຕິ, ໃນກໍລະນີດັ່ງກ່າວ, ຫນຶ່ງໃນການເກັບຮັກສາ NoSQL ຖືກນໍາໃຊ້, ແຕ່ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງສາມາດຖືກໂອນໄປຫາ NoSQL: ບາງຫນ່ວຍງານຕ້ອງການການຮັບປະກັນການເຮັດທຸລະກໍາ ACID.

ນີ້ໄດ້ນໍາພວກເຮົາໄປສູ່ການນໍາໃຊ້ການເກັບຮັກສາ NewSQL, ນັ້ນແມ່ນ DBMS ທີ່ສະຫນອງຄວາມທົນທານຕໍ່ຄວາມຜິດ, ຂະຫນາດແລະການປະຕິບັດຂອງລະບົບ NoSQL, ແຕ່ໃນເວລາດຽວກັນການຮັກສາ ACID ຮັບປະກັນຄວາມຄຸ້ນເຄີຍກັບລະບົບຄລາສສິກ. ມີລະບົບອຸດສາຫະກໍາທີ່ເຮັດວຽກຫນ້ອຍຂອງຊັ້ນຮຽນໃຫມ່ນີ້, ດັ່ງນັ້ນພວກເຮົາໄດ້ປະຕິບັດລະບົບດັ່ງກ່າວດ້ວຍຕົວເອງແລະເຮັດໃຫ້ມັນເຂົ້າໄປໃນການດໍາເນີນງານທາງການຄ້າ.

ມັນເຮັດວຽກແນວໃດແລະສິ່ງທີ່ເກີດຂຶ້ນ - ອ່ານພາຍໃຕ້ການຕັດ.

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

ພວກເຮົາໄດ້ໃຊ້ Cassandra ຕັ້ງແຕ່ປີ 2010, ເລີ່ມຕົ້ນດ້ວຍສະບັບ 0.6. ມື້​ນີ້​ມີ​ຫຼາຍ​ສິບ​ກຸ່ມ​ໃນ​ການ​ດໍາ​ເນີນ​ງານ​. ກຸ່ມທີ່ໄວທີ່ສຸດປະມວນຜົນຫຼາຍກ່ວາ 4 ລ້ານການດໍາເນີນງານຕໍ່ວິນາທີ, ແລະເກັບຮັກສາທີ່ໃຫຍ່ທີ່ສຸດ 260 TB.

ຢ່າງໃດກໍຕາມ, ເຫຼົ່ານີ້ແມ່ນກຸ່ມ NoSQL ທໍາມະດາທັງຫມົດທີ່ໃຊ້ສໍາລັບການເກັບຮັກສາ ການ​ປະ​ສານ​ງານ​ອ່ອນ​ແອ​ ຂໍ້ມູນ. ພວກເຮົາຕ້ອງການທົດແທນການເກັບຮັກສາທີ່ສອດຄ່ອງຕົ້ນຕໍ, Microsoft SQL Server, ເຊິ່ງໄດ້ຖືກນໍາໃຊ້ນັບຕັ້ງແຕ່ການກໍ່ຕັ້ງຂອງ Odnoklassniki. ການເກັບຮັກສາປະກອບດ້ວຍເຄື່ອງຈັກ SQL Server Standard Edition ຫຼາຍກວ່າ 300 ເຄື່ອງ, ເຊິ່ງບັນຈຸຂໍ້ມູນ 50 TB - business entities . ຂໍ້ມູນນີ້ຖືກດັດແກ້ເປັນສ່ວນໜຶ່ງຂອງທຸລະກຳ ACID ແລະຕ້ອງການ ຄວາມສອດຄ່ອງສູງ.

ເພື່ອແຈກຢາຍຂໍ້ມູນທົ່ວ SQL Server nodes, ພວກເຮົາໄດ້ໃຊ້ທັງແນວຕັ້ງ ແລະແນວນອນ ການແບ່ງສ່ວນ (sharding). ໃນປະຫວັດສາດ, ພວກເຮົາໄດ້ນໍາໃຊ້ໂຄງການແບ່ງປັນຂໍ້ມູນແບບງ່າຍດາຍ: ແຕ່ລະຫນ່ວຍງານແມ່ນກ່ຽວຂ້ອງກັບ token - ຫນ້າທີ່ຂອງ entity ID. ຫນ່ວຍງານທີ່ມີ token ດຽວກັນໄດ້ຖືກຈັດໃສ່ໃນເຄື່ອງແມ່ຂ່າຍ SQL ດຽວກັນ. ການພົວພັນລາຍລະອຽດຕົ້ນສະບັບໄດ້ຖືກປະຕິບັດເພື່ອໃຫ້ໂທເຄັນຂອງບັນທຶກຕົ້ນຕໍແລະລູກຈັບຄູ່ສະເຫມີແລະຕັ້ງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນ. ໃນເຄືອຂ່າຍສັງຄົມ, ບັນທຶກເກືອບທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນໃນນາມຂອງຜູ້ໃຊ້ - ຊຶ່ງຫມາຍຄວາມວ່າຂໍ້ມູນຜູ້ໃຊ້ທັງຫມົດພາຍໃນລະບົບຍ່ອຍທີ່ມີປະໂຫຍດແມ່ນເກັບໄວ້ໃນເຄື່ອງແມ່ຂ່າຍດຽວ. ນັ້ນແມ່ນ, ການເຮັດທຸລະກໍາເກືອບສະເຫມີມີຕາຕະລາງຈາກເຄື່ອງແມ່ຂ່າຍ SQL ຫນຶ່ງ, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ເພື່ອຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນໂດຍໃຊ້ທຸລະກໍາ ACID ທ້ອງຖິ່ນ, ໂດຍບໍ່ຕ້ອງໃຊ້. ຊ້າແລະບໍ່ຫນ້າເຊື່ອຖື ການເຮັດທຸລະກໍາ ACID ທີ່ແຈກຢາຍ.

ຂໍຂອບໃຈກັບ sharding ແລະເລັ່ງ SQL:

• ພວກເຮົາບໍ່ໄດ້ໃຊ້ຂໍ້ຈໍາກັດຂອງລະຫັດຕ່າງປະເທດ, ເນື່ອງຈາກວ່າໃນເວລາທີ່ sharding ID entity ອາດຈະຕັ້ງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍອື່ນ.
• ພວກເຮົາບໍ່ໃຊ້ຂັ້ນຕອນທີ່ເກັບໄວ້ແລະ triggers ເນື່ອງຈາກການໂຫຼດເພີ່ມເຕີມໃນ CPU DBMS.
• ພວກເຮົາບໍ່ໃຊ້ JOINs ເພາະວ່າທັງໝົດຂ້າງເທິງນີ້ແລະການອ່ານແບບສຸ່ມຫຼາຍຈາກແຜ່ນ.
• ຢູ່ນອກການເຮັດທຸລະກໍາ, ພວກເຮົາໃຊ້ລະດັບການໂດດດ່ຽວ Read Uncommitted ເພື່ອຫຼຸດຜ່ອນຄວາມຕາຍ.
• ພວກເຮົາເຮັດທຸລະກໍາສັ້ນເທົ່ານັ້ນ (ໂດຍສະເລ່ຍສັ້ນກວ່າ 100 ms).
• ພວກເຮົາບໍ່ໄດ້ໃຊ້ຫຼາຍແຖວ UPDATE ແລະ DELETE ເນື່ອງຈາກການປິດຕາຍຈໍານວນຫລາຍ - ພວກເຮົາອັບເດດພຽງແຕ່ຫນຶ່ງບັນທຶກຕໍ່ຄັ້ງ.
• ພວກເຮົາສະເຫມີປະຕິບັດການສອບຖາມພຽງແຕ່ຢູ່ໃນດັດສະນີ - ຄໍາຖາມທີ່ມີແຜນການສະແກນຕາຕະລາງເຕັມສໍາລັບພວກເຮົາຫມາຍຄວາມວ່າ overloading ຖານຂໍ້ມູນແລະເຮັດໃຫ້ມັນລົ້ມເຫລວ.

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

ບັນຫາກັບ SQL

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

ແຕ່ບັນຫາຕົ້ນຕໍແມ່ນ

ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​

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

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

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

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

ສໍາລັບນີ້ພວກເຮົາສາມາດນໍາໃຊ້ Multi-Master replication ສ້າງຂຶ້ນໃນ SQL Server. ການແກ້ໄຂນີ້ແມ່ນລາຄາແພງກວ່າຫຼາຍຍ້ອນຄ່າໃຊ້ຈ່າຍຂອງຊອບແວແລະທົນທຸກຈາກບັນຫາທີ່ມີຊື່ສຽງກັບການຈໍາລອງ - ການຊັກຊ້າການເຮັດທຸລະກໍາທີ່ບໍ່ສາມາດຄາດເດົາໄດ້ກັບການຈໍາລອງແບບ synchronous ແລະຄວາມລ່າຊ້າໃນການສະຫມັກ replications (ແລະ, ດັ່ງນັ້ນ, ການສູນເສຍການດັດແກ້) ກັບການຈໍາລອງແບບ asynchronous. ຄວາມຫມາຍ ການ​ແກ້​ໄຂ​ຂໍ້​ຂັດ​ແຍ່ງ​ດ້ວຍ​ມື​ ເຮັດໃຫ້ທາງເລືອກນີ້ໃຊ້ບໍ່ໄດ້ຢ່າງສົມບູນກັບພວກເຮົາ.

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

ທຸລະກໍາງ່າຍດາຍ

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

1. ພວກເຮົາບລັອກອັນລະບັ້ມດ້ວຍລະຫັດ.
2. ສ້າງລາຍການໃນຕາຕະລາງຮູບພາບ.
3. ຖ້າຮູບມີສະຖານະສາທາລະນະ, ຫຼັງຈາກນັ້ນເພີ່ມຕົວນັບຮູບສາທາລະນະໃສ່ອະລະບໍ້າ, ອັບເດດບັນທຶກແລະເຮັດທຸລະກໍາ.

ຫຼືໃນ pseudocode:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

ອື່ນໆ, ບໍ່ມີຄວາມສໍາຄັນຫນ້ອຍ, ຄວາມຕ້ອງການແມ່ນ:

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

ການຕັດສິນໃຈ, ການຕັດສິນໃຈ

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

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

ທາງ​ເລືອກ​ທີ​ສອງ​ແມ່ນ​ການ​ນໍາ​ໃຊ້​ການ​ເກັບ​ຮັກ​ສາ NoSQL ກຽມ​ພ້ອມ​ທີ່​ມີ​ການ​ຂະ​ຫຍາຍ​ການ​ປະ​ຕິ​ບັດ​, ກຸ່ມ​ການ​ລົ້ມ​ເຫຼວ​, ການ​ແກ້​ໄຂ​ຂໍ້​ຂັດ​ແຍ່ງ​, ແລະ​ປະ​ຕິ​ບັດ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ແລະ SQL ຕົວ​ທ່ານ​ເອງ​. ຢູ່ glance ທໍາອິດ, ເຖິງແມ່ນວ່າວຽກງານຂອງການປະຕິບັດ SQL, ບໍ່ໄດ້ກ່າວເຖິງການເຮັດທຸລະກໍາ ACID, ເບິ່ງຄືວ່າເປັນວຽກງານທີ່ຈະໃຊ້ເວລາຫຼາຍປີ. ແຕ່ຫຼັງຈາກນັ້ນພວກເຮົາຮູ້ວ່າຄຸນສົມບັດ SQL ທີ່ພວກເຮົາໃຊ້ໃນການປະຕິບັດແມ່ນຢູ່ໄກຈາກ ANSI SQL Cassandra CQL ໄກຈາກ ANSI SQL. ການເບິ່ງທີ່ໃກ້ຊິດຢູ່ໃນ CQL, ພວກເຮົາຮູ້ວ່າມັນໃກ້ຊິດກັບສິ່ງທີ່ພວກເຮົາຕ້ອງການ.

Cassandra ແລະ CQL

ດັ່ງນັ້ນ, ສິ່ງທີ່ຫນ້າສົນໃຈກ່ຽວກັບ Cassandra, ມັນມີຄວາມສາມາດອັນໃດແດ່?

ກ່ອນອື່ນ ໝົດ, ທີ່ນີ້ທ່ານສາມາດສ້າງຕາຕະລາງທີ່ສະຫນັບສະຫນູນປະເພດຂໍ້ມູນຕ່າງໆ; ທ່ານສາມາດເຮັດ SELECT ຫຼື UPDATE ໃນລະຫັດຫຼັກ.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

ເພື່ອຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນຈໍາລອງ, Cassandra ໃຊ້ ວິທີການຂອງກຸ່ມ. ໃນກໍລະນີງ່າຍດາຍທີ່ສຸດ, ນີ້ຫມາຍຄວາມວ່າເມື່ອສາມ replicas ຂອງແຖວດຽວກັນຖືກຈັດໃສ່ໃນ nodes ທີ່ແຕກຕ່າງກັນຂອງ cluster, ການຂຽນແມ່ນຖືວ່າປະສົບຜົນສໍາເລັດຖ້າຫາກວ່າສ່ວນໃຫຍ່ຂອງ nodes (ນັ້ນແມ່ນ, ສອງໃນສາມ) ໄດ້ຢືນຢັນຜົນສໍາເລັດຂອງການດໍາເນີນງານການຂຽນນີ້. . ຂໍ້ມູນແຖວແມ່ນຖືວ່າສອດຄ່ອງຖ້າ, ເມື່ອອ່ານ, ສ່ວນໃຫຍ່ຂອງ nodes ໄດ້ຖືກ polled ແລະຢືນຢັນພວກມັນ. ດັ່ງນັ້ນ, ດ້ວຍສາມ replicas, ຄວາມສອດຄ່ອງຂອງຂໍ້ມູນຄົບຖ້ວນແລະທັນທີແມ່ນຮັບປະກັນຖ້າຫາກວ່າຫນຶ່ງ node ລົ້ມເຫລວ. ວິທີການນີ້ອະນຸຍາດໃຫ້ພວກເຮົາປະຕິບັດໂຄງການທີ່ຫນ້າເຊື່ອຖືຫຼາຍ: ສົ່ງຄໍາຮ້ອງຂໍໃຫ້ທັງສາມ replicas, ລໍຖ້າການຕອບສະຫນອງຈາກສອງອັນທີ່ໄວທີ່ສຸດ. ການຕອບໂຕ້ຊ້າຂອງ replica ທີສາມແມ່ນຖືກຍົກເລີກໃນກໍລະນີນີ້. node ທີ່ຊັກຊ້າໃນການຕອບສະຫນອງອາດຈະມີບັນຫາທີ່ຮ້າຍແຮງ - ເບກ, ການເກັບຂີ້ເຫຍື້ອໃນ JVM, ການຍຶດຫນ່ວຍຄວາມຈໍາໂດຍກົງໃນ Linux kernel, ຄວາມລົ້ມເຫຼວຂອງຮາດແວ, ການເຊື່ອມຕໍ່ຈາກເຄືອຂ່າຍ. ຢ່າງໃດກໍ່ຕາມ, ນີ້ບໍ່ມີຜົນຕໍ່ການດໍາເນີນງານຫຼືຂໍ້ມູນຂອງລູກຄ້າໃນທາງໃດກໍ່ຕາມ.

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

ຜົນປະໂຫຍດອີກອັນຫນຶ່ງຂອງ Cassandra ແມ່ນ Batchlog, ກົນໄກທີ່ຮັບປະກັນວ່າຊຸດການປ່ຽນແປງທີ່ທ່ານເຮັດຈະຖືກນໍາໃຊ້ຢ່າງເຕັມທີ່ຫຼືບໍ່ໄດ້ນໍາໃຊ້ທັງຫມົດ. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາແກ້ໄຂ A ໃນ ACID - atomicity out of the box .

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

ສິ່ງທີ່ພວກເຮົາຂາດຫາຍໄປໃນ Cassandra

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

C*One

ດັ່ງນັ້ນຈຶ່ງເກີດ DBMS ໃໝ່ C*One, ປະກອບດ້ວຍສາມປະເພດຂອງຂໍ້ຂອງເຄື່ອງແມ່ຂ່າຍ:

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

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

ລູກຄ້າ

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

C*One ຜູ້ປະສານງານທຸລະກໍາ

ຜູ້ປະສານງານແມ່ນສິ່ງທີ່ພວກເຮົາປະຕິບັດສໍາລັບ C*One ຕັ້ງແຕ່ເລີ່ມຕົ້ນ. ມັນຮັບຜິດຊອບໃນການຄຸ້ມຄອງການເຮັດທຸລະກໍາ, locks, ແລະຄໍາສັ່ງໃນການປະຕິບັດທຸລະກໍາ.

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

ລັອກ

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

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

ເນື່ອງຈາກວ່າໃນກໍລະນີຂອງພວກເຮົາຂໍ້ມູນໄດ້ຖືກແຈກຢາຍແລ້ວໃນບັນດາກຸ່ມການເຮັດທຸລະກໍາທ້ອງຖິ່ນໃນ SQL, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະມອບກຸ່ມທຸລະກໍາທ້ອງຖິ່ນໃຫ້ກັບຜູ້ປະສານງານ: ຜູ້ປະສານງານຫນຶ່ງເຮັດທຸລະກໍາທັງຫມົດດ້ວຍ tokens ຈາກ 0 ຫາ 9, ທີສອງ - ມີ tokens ຈາກ 10 ຫາ 19, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ແຕ່ລະຕົວຢ່າງຂອງຜູ້ປະສານງານກາຍເປັນແມ່ບົດຂອງກຸ່ມທຸລະກໍາ.

ຫຼັງຈາກນັ້ນ, locks ສາມາດຖືກປະຕິບັດໃນຮູບແບບຂອງ HashMap banal ໃນຄວາມຊົງຈໍາຂອງຜູ້ປະສານງານ.

ຜູ້ປະສານງານລົ້ມເຫລວ

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

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

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

ຂໍ້ຄວາມການເຕັ້ນຂອງຫົວໃຈແມ່ນຖືກສົ່ງໄປດ້ວຍຄວາມຖີ່ສູງ, ປະມານ 20 ເທື່ອຕໍ່ວິນາທີ, ມີໄລຍະເວລາ 50 ms. ໃນ Java, ມັນຍາກທີ່ຈະຮັບປະກັນການຕອບສະ ໜອງ ຂອງແອັບພລິເຄຊັນພາຍໃນ 50 ms ເນື່ອງຈາກໄລຍະເວລາທີ່ປຽບທຽບກັນຂອງການຢຸດທີ່ເກີດຈາກຜູ້ເກັບຂີ້ເຫຍື້ອ. ພວກເຮົາສາມາດບັນລຸເວລາຕອບສະຫນອງນີ້ໂດຍໃຊ້ເຄື່ອງເກັບຂີ້ເຫຍື້ອ G1, ເຊິ່ງຊ່ວຍໃຫ້ພວກເຮົາກໍານົດເປົ້າຫມາຍສໍາລັບໄລຍະເວລາຂອງການຢຸດ GC. ຢ່າງໃດກໍຕາມ, ບາງຄັ້ງ, ຂ້ອນຂ້າງບໍ່ຄ່ອຍ, ຕົວເກັບຄ່າຢຸດເກີນ 50 ms, ເຊິ່ງສາມາດນໍາໄປສູ່ການກວດພົບຄວາມຜິດທີ່ບໍ່ຖືກຕ້ອງ. ເພື່ອປ້ອງກັນການນີ້ເກີດຂຶ້ນ, ຜູ້ປະສານງານບໍ່ໄດ້ລາຍງານຄວາມລົ້ມເຫຼວຂອງ node ຫ່າງໄກສອກຫຼີກໃນເວລາທີ່ຂໍ້ຄວາມເຕັ້ນຫົວໃຈທໍາອິດຈາກມັນຫາຍໄປ, ພຽງແຕ່ຖ້າຫາກວ່າຈໍານວນຫຼາຍໄດ້ຫາຍໄປຕິດຕໍ່ກັນ. ນີ້ແມ່ນວິທີທີ່ພວກເຮົາຈັດການເພື່ອກວດພົບຄວາມລົ້ມເຫຼວຂອງ node coordinator ໃນ 200. ນາງ​ສາວ.

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

ການຈອງ

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

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

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

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

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

ວິທີການເຮັດທຸລະກໍາ

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

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

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

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

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

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

ແລະເພື່ອ rollback, ຜູ້ປະສານງານພຽງແຕ່ຕ້ອງການປົດປ່ອຍຄວາມຊົງຈໍາທີ່ຄອບຄອງໂດຍສະຖານະທຸລະກໍາ.

ຜົນຂອງການປັບປຸງຂ້າງເທິງ, ພວກເຮົາໄດ້ປະຕິບັດຫຼັກການ ACID:

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

ການອ່ານໂດຍດັດສະນີ

ໃຫ້​ເຮົາ​ໃຊ້​ຕາ​ຕະ​ລາງ​ງ່າຍ​ດາຍ​:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

ມັນມີ ID (ລະຫັດຫຼັກ), ເຈົ້າຂອງ ແລະວັນທີດັດແກ້. ທ່ານຈໍາເປັນຕ້ອງເຮັດຄໍາຮ້ອງຂໍງ່າຍດາຍຫຼາຍ - ເລືອກຂໍ້ມູນເຈົ້າຂອງກັບວັນທີປ່ຽນແປງ "ສໍາລັບມື້ສຸດທ້າຍ".

SELECT *
WHERE owner=?
AND modified>?

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

ດັດຊະນີໃນ C*One

ມີຕາຕະລາງແຫຼ່ງທີ່ມີຮູບຖ່າຍເຊິ່ງ ID ບັນທຶກແມ່ນກຸນແຈຫຼັກ.

ສໍາລັບດັດສະນີ, C*One ສ້າງຕາຕະລາງໃຫມ່ທີ່ເປັນສໍາເນົາຂອງຕົ້ນສະບັບ. ກຸນແຈແມ່ນຄືກັນກັບການສະແດງອອກຂອງດັດຊະນີ, ແລະມັນຍັງປະກອບມີລະຫັດຫຼັກຂອງບັນທຶກຈາກຕາຕະລາງແຫຼ່ງ:

ໃນປັດຈຸບັນຄໍາຖາມສໍາລັບ "ເຈົ້າຂອງສໍາລັບມື້ສຸດທ້າຍ" ສາມາດຖືກຂຽນຄືນໃຫມ່ເປັນທາງເລືອກຈາກຕາຕະລາງອື່ນ:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

ເກີດ​ຫຍັງ​ຂຶ້ນ

ພວກເຮົາໄດ້ພັດທະນາ C*One ເມື່ອສາມປີກ່ອນແລະເປີດຕົວມັນໄປສູ່ການດໍາເນີນງານທາງການຄ້າ.

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

ເມື່ອພວກເຮົາໃຊ້ SQL ກັບ replication factor = 1 (ແຕ່ໃນ RAID 10), photo metainformation ໄດ້ຖືກເກັບໄວ້ໃນ cluster ທີ່ມີຢູ່ສູງຂອງ 32 ເຄື່ອງທີ່ໃຊ້ Microsoft SQL Server (ບວກກັບ 11 backups). 10 ເຊີບເວີຍັງໄດ້ຖືກຈັດສັນສໍາລັບການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ. ລົດລາຄາແພງທັງໝົດ 50 ຄັນ. ໃນເວລາດຽວກັນ, ລະບົບໄດ້ດໍາເນີນການຢູ່ໃນການໂຫຼດການຈັດອັນດັບ, ໂດຍບໍ່ມີການສະຫງວນ.

ຫຼັງຈາກການເຄື່ອນຍ້າຍໄປສູ່ລະບົບໃຫມ່, ພວກເຮົາໄດ້ຮັບ replication factor = 3 - ສໍາເນົາໃນແຕ່ລະສູນຂໍ້ມູນ. ລະບົບປະກອບດ້ວຍ 63 ​​ໂຫນດການເກັບຮັກສາ Cassandra ແລະ 6 ເຄື່ອງປະສານງານ, ສໍາລັບເຄື່ອງແມ່ຂ່າຍທັງຫມົດ 69 ເຄື່ອງ. ແຕ່ເຄື່ອງຈັກເຫຼົ່ານີ້ແມ່ນລາຄາຖືກກວ່າຫຼາຍ, ຄ່າໃຊ້ຈ່າຍທັງຫມົດຂອງພວກເຂົາແມ່ນປະມານ 30% ຂອງຄ່າໃຊ້ຈ່າຍຂອງລະບົບ SQL. ໃນເວລາດຽວກັນ, ການໂຫຼດແມ່ນເກັບຮັກສາໄວ້ 30%.

ດ້ວຍການແນະນໍາ C*One, latency ຍັງຫຼຸດລົງ: ໃນ SQL, ການປະຕິບັດການຂຽນໄດ້ປະມານ 4,5 ms. ໃນ C*One - ປະມານ 1,6 ms. ໄລຍະເວລາການເຮັດທຸລະກໍາແມ່ນສະເລ່ຍຫນ້ອຍກວ່າ 40 ms, ຄໍາຫມັ້ນສັນຍາແມ່ນສໍາເລັດໃນ 2 ms, ໄລຍະເວລາອ່ານແລະຂຽນແມ່ນໂດຍສະເລ່ຍ 2 ms. 99th ເປີເຊັນ - ພຽງແຕ່ 3-3,1 ms, ຈໍານວນເວລາຫມົດເວລາໄດ້ຫຼຸດລົງ 100 ເທື່ອ - ທັງຫມົດແມ່ນຍ້ອນການນໍາໃຊ້ຢ່າງກວ້າງຂວາງຂອງການຄາດຄະເນ.

ໃນປັດຈຸບັນ, ສ່ວນໃຫຍ່ຂອງ SQL Server nodes ໄດ້ຖືກຍົກເລີກ; ຜະລິດຕະພັນໃຫມ່ແມ່ນໄດ້ຖືກພັດທະນາໂດຍໃຊ້ C * One ເທົ່ານັ້ນ. ພວກເຮົາດັດແປງ C*One ເພື່ອເຮັດວຽກຢູ່ໃນຄລາວຂອງພວກເຮົາ one-cloud, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ເພື່ອເລັ່ງການປັບຕົວຂອງກຸ່ມໃຫມ່, ເຮັດໃຫ້ການຕັ້ງຄ່າງ່າຍແລະອັດຕະໂນມັດການດໍາເນີນງານ. ຖ້າບໍ່ມີລະຫັດແຫຼ່ງ, ການເຮັດແບບນີ້ຈະມີຄວາມຫຍຸ້ງຍາກແລະຫຍຸ້ງຍາກຫຼາຍ.

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

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