ທິດສະດີແລະການປະຕິບັດຂອງການນໍາໃຊ້ HBase

ສະ​ບາຍ​ດີ​ຕອນ​ສວາຍ ຂ້ອຍຊື່ Danil Lipovoy, ທີມງານຂອງພວກເຮົາຢູ່ Sbertech ເລີ່ມໃຊ້ HBase ເປັນການເກັບຮັກສາຂໍ້ມູນການດໍາເນີນງານ. ໃນໄລຍະການສຶກສາມັນ, ປະສົບການໄດ້ສະສົມທີ່ຂ້ອຍຕ້ອງການໃຫ້ລະບົບແລະອະທິບາຍ (ພວກເຮົາຫວັງວ່າມັນຈະເປັນປະໂຫຍດກັບຫຼາຍໆຄົນ). ການທົດລອງທັງໝົດລຸ່ມນີ້ຖືກປະຕິບັດດ້ວຍ HBase ເວີຊັ່ນ 1.2.0-cdh5.14.2 ແລະ 2.0.0-cdh6.0.0-beta1.

1. ສະຖາປັດຕະຍະກໍາທົ່ວໄປ
2. ກຳລັງຂຽນຂໍ້ມູນໃສ່ HBASE
3. ກຳລັງອ່ານຂໍ້ມູນຈາກ HBASE
4. ການເກັບຂໍ້ມູນ
5. ການປະມວນຜົນຂໍ້ມູນຊຸດ MultiGet/MultiPut
6. ຍຸດ​ທະ​ສາດ​ການ​ແຍກ​ຕາ​ຕະ​ລາງ​ອອກ​ເປັນ​ພາກ​ພື້ນ (splitting​)
7. ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​, ຫນາ​ແຫນ້ນ​ແລະ​ທ້ອງ​ຖິ່ນ​ຂໍ້​ມູນ​
8. ການຕັ້ງຄ່າແລະການປະຕິບັດ
9. ການທົດສອບຄວາມກົດດັນ
10. ການຄົ້ນພົບ

1. ສະຖາປັດຕະຍະກຳທົ່ວໄປ

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

2. ຂຽນຂໍ້ມູນໃສ່ HBASE

ກ່ອນອື່ນ, ໃຫ້ເບິ່ງກໍລະນີທີ່ງ່າຍດາຍທີ່ສຸດ - ການຂຽນວັດຖຸທີ່ມີຄ່າໃນຕາຕະລາງໂດຍໃຊ້ put(rowkey). ທໍາອິດລູກຄ້າຕ້ອງຊອກຫາບ່ອນທີ່ Root Region Server (RRS), ເຊິ່ງເກັບຮັກສາ hbase: meta table, ຕັ້ງຢູ່. ລາວໄດ້ຮັບຂໍ້ມູນນີ້ຈາກ ZooKeeper. ຫຼັງຈາກນັ້ນ, ມັນເຂົ້າເຖິງ RRS ແລະອ່ານຕາຕະລາງ hbase: meta, ຈາກທີ່ມັນສະກັດຂໍ້ມູນກ່ຽວກັບ RegionServer (RS) ຮັບຜິດຊອບສໍາລັບການເກັບຮັກສາຂໍ້ມູນສໍາລັບ rowkey ທີ່ກໍານົດໄວ້ໃນຕາຕະລາງຄວາມສົນໃຈ. ສໍາລັບການນໍາໃຊ້ໃນອະນາຄົດ, ຕາຕະລາງ meta ຖືກເກັບໄວ້ໂດຍລູກຄ້າແລະດັ່ງນັ້ນການໂທຕໍ່ມາໄວຂຶ້ນ, ໂດຍກົງກັບ RS.

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

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

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

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

ນອກເຫນືອໄປຈາກຂະບວນການໂຫຼດໄດ້ອະທິບາຍຂ້າງເທິງ, ມີຂັ້ນຕອນທີ່ມີປະສິດທິພາບຫຼາຍ, ເຊິ່ງອາດຈະເປັນດ້ານທີ່ເຂັ້ມແຂງທີ່ສຸດຂອງຖານຂໍ້ມູນນີ້ - BulkLoad. ມັນຢູ່ໃນຄວາມຈິງທີ່ວ່າພວກເຮົາປະກອບເປັນ HFiles ເປັນເອກະລາດແລະເອົາໃສ່ໃນແຜ່ນ, ເຊິ່ງຊ່ວຍໃຫ້ພວກເຮົາສາມາດຂະຫນາດໄດ້ຢ່າງສົມບູນແລະບັນລຸຄວາມໄວທີ່ເຫມາະສົມຫຼາຍ. ໃນຄວາມເປັນຈິງ, ຂໍ້ຈໍາກັດຢູ່ທີ່ນີ້ບໍ່ແມ່ນ HBase, ແຕ່ຄວາມສາມາດຂອງຮາດແວ. ຂ້າງລຸ່ມນີ້ແມ່ນຜົນການບູດຢູ່ໃນກຸ່ມທີ່ປະກອບດ້ວຍ 16 RegionServers ແລະ 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase ຮຸ່ນ 1.2.0-cdh5.14.2.

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

ນອກນັ້ນທ່ານຍັງສາມາດເລີ່ມຕົ້ນການໂຫຼດເຂົ້າໄປໃນສອງຕາຕະລາງໃນເວລາດຽວກັນແລະໄດ້ຮັບຄວາມໄວສອງເທົ່າ. ຂ້າງລຸ່ມນີ້ທ່ານສາມາດເບິ່ງວ່າການຂຽນບລັອກ 10 KB ໄປຫາສອງຕາຕະລາງໃນເວລາດຽວເກີດຂື້ນດ້ວຍຄວາມໄວປະມານ 600 MB / ວິນາທີໃນແຕ່ລະ (ທັງຫມົດ 1275 MB / ວິນາທີ), ເຊິ່ງກົງກັບຄວາມໄວຂອງການຂຽນໄປຫາຕາຕະລາງຫນຶ່ງ 623 MB / ວິນາທີ (ເບິ່ງ. ອັນດັບທີ 11 ຂ້າງເທິງ)

ແຕ່ການແລ່ນຄັ້ງທີສອງທີ່ມີບັນທຶກ 50 KB ສະແດງໃຫ້ເຫັນວ່າຄວາມໄວການດາວໂຫລດແມ່ນເຕີບໂຕເລັກນ້ອຍ, ເຊິ່ງຊີ້ໃຫ້ເຫັນວ່າມັນໃກ້ກັບຄ່າຈໍາກັດ. ໃນເວລາດຽວກັນ, ທ່ານ ຈຳ ເປັນຕ້ອງຈື່ໄວ້ວ່າຕົວຈິງແລ້ວບໍ່ມີການໂຫຼດທີ່ສ້າງຂຶ້ນໃນ HBASE ຕົວມັນເອງ, ທຸກຢ່າງທີ່ຕ້ອງການແມ່ນໃຫ້ຂໍ້ມູນຈາກ hbase:meta, ແລະຫຼັງຈາກສາຍ HFiles, ຣີເຊັດຂໍ້ມູນ BlockCache ແລະບັນທຶກຂໍ້ມູນ. MemStore buffer ກັບ disk, ຖ້າມັນບໍ່ແມ່ນຫວ່າງເປົ່າ.

3. ການອ່ານຂໍ້ມູນຈາກ HBASE

ຖ້າພວກເຮົາສົມມຸດວ່າລູກຄ້າມີຂໍ້ມູນທັງຫມົດແລ້ວຈາກ hbase:meta (ເບິ່ງຈຸດ 2), ຫຼັງຈາກນັ້ນຄໍາຮ້ອງຂໍຈະໄປຫາ RS ໂດຍກົງບ່ອນທີ່ລະຫັດທີ່ຕ້ອງການຖືກເກັບໄວ້. ຫນ້າທໍາອິດ, ການຄົ້ນຫາແມ່ນດໍາເນີນຢູ່ໃນ MemCache. ໂດຍບໍ່ສົນເລື່ອງວ່າມີຂໍ້ມູນຢູ່ທີ່ນັ້ນຫຼືບໍ່, ການຄົ້ນຫາຍັງດໍາເນີນຢູ່ໃນ buffer BlockCache ແລະ, ຖ້າຈໍາເປັນ, ໃນ HFiles. ຖ້າຂໍ້ມູນຖືກພົບເຫັນຢູ່ໃນໄຟລ໌, ມັນຖືກຈັດໃສ່ໃນ BlockCache ແລະຈະຖືກສົ່ງຄືນໄວຂຶ້ນໃນການຮ້ອງຂໍຕໍ່ໄປ. ການຊອກຫາໃນ HFile ແມ່ນຂ້ອນຂ້າງໄວຍ້ອນການນໍາໃຊ້ຕົວກອງ Bloom, i.e. ດ້ວຍການອ່ານຂໍ້ມູນຈໍານວນນ້ອຍໆ, ມັນຈະກໍານົດທັນທີວ່າໄຟລ໌ນີ້ມີລະຫັດທີ່ຕ້ອງການຫຼືບໍ່, ຫຼັງຈາກນັ້ນຍ້າຍໄປອັນຕໍ່ໄປ.

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

4. ການເກັບຂໍ້ມູນ

MemStore ແລະ BlockCache buffers ຄອບຄອງເຖິງ 80% ຂອງຫນ່ວຍຄວາມຈໍາ RS ໃນ heap ທີ່ຖືກຈັດສັນ (ສ່ວນທີ່ເຫຼືອແມ່ນສະຫງວນໄວ້ສໍາລັບວຽກງານການບໍລິການ RS). ຖ້າຮູບແບບການນໍາໃຊ້ແບບປົກກະຕິແມ່ນຂະບວນການຂຽນແລະອ່ານຂໍ້ມູນດຽວກັນທັນທີ, ມັນສົມເຫດສົມຜົນທີ່ຈະຫຼຸດຜ່ອນ BlockCache ແລະເພີ່ມ MemStore, ເພາະວ່າ ເມື່ອຂຽນຂໍ້ມູນບໍ່ໄດ້ເຂົ້າໄປໃນແຄດສໍາລັບການອ່ານ, BlockCache ຈະຖືກນໍາໃຊ້ຫນ້ອຍລົງເລື້ອຍໆ. BlockCache buffer ປະກອບດ້ວຍສອງພາກສ່ວນ: LruBlockCache (ຢູ່ສະເຫມີຢູ່ໃນ heap) ແລະ BucketCache (ປົກກະຕິແລ້ວ off-heap ຫຼືຢູ່ໃນ SSD). BucketCache ຄວນຖືກນໍາໃຊ້ໃນເວລາທີ່ມີການຮ້ອງຂໍການອ່ານຈໍານວນຫລາຍແລະພວກມັນບໍ່ເຫມາະສົມກັບ LruBlockCache, ເຊິ່ງນໍາໄປສູ່ການເຮັດວຽກຢ່າງຫ້າວຫັນຂອງເຄື່ອງເກັບຂີ້ເຫຍື້ອ. ໃນເວລາດຽວກັນ, ທ່ານບໍ່ຄວນຄາດຫວັງວ່າການເພີ່ມຂື້ນຢ່າງຫຼວງຫຼາຍໃນການປະຕິບັດຈາກການໃຊ້ cache ອ່ານ, ແຕ່ພວກເຮົາຈະກັບຄືນໄປຫານີ້ໃນວັກ 8.

ມີຫນຶ່ງ BlockCache ສໍາລັບ RS ທັງຫມົດ, ແລະມີ MemStore ຫນຶ່ງສໍາລັບແຕ່ລະຕາຕະລາງ (ຫນຶ່ງສໍາລັບແຕ່ລະ Column Family).

ວິ​ທີ​ການ ອະທິບາຍ ໃນທາງທິດສະດີ, ເມື່ອຂຽນ, ຂໍ້ມູນບໍ່ໄດ້ເຂົ້າໄປໃນ cache ແລະແທ້ຈິງແລ້ວ, ຕົວກໍານົດການດັ່ງກ່າວ CACHE_DATA_ON_WRITE ສໍາລັບຕາຕະລາງແລະ "Cache DATA on Write" ສໍາລັບ RS ຖືກຕັ້ງເປັນຜິດ. ຢ່າງໃດກໍຕາມ, ໃນການປະຕິບັດ, ຖ້າພວກເຮົາຂຽນຂໍ້ມູນໃສ່ MemStore, ຫຼັງຈາກນັ້ນ flush ມັນເຂົ້າໄປໃນແຜ່ນ (ດັ່ງນັ້ນການລ້າງມັນ), ຫຼັງຈາກນັ້ນລຶບໄຟລ໌ຜົນໄດ້ຮັບ, ຫຼັງຈາກນັ້ນໂດຍການດໍາເນີນການຮ້ອງຂໍຮັບພວກເຮົາຈະໄດ້ຮັບຂໍ້ມູນສົບຜົນສໍາເລັດ. ຍິ່ງໄປກວ່ານັ້ນ, ເຖິງແມ່ນວ່າທ່ານຈະປິດການໃຊ້ງານ BlockCache ຢ່າງສົມບູນແລະຕື່ມຂໍ້ມູນໃສ່ຕາຕະລາງໃຫມ່, ຫຼັງຈາກນັ້ນປັບ MemStore ເປັນແຜ່ນ, ລຶບພວກມັນແລະຮ້ອງຂໍໃຫ້ເຂົາເຈົ້າຈາກກອງປະຊຸມອື່ນ, ພວກມັນຍັງຈະຖືກດຶງມາຈາກບ່ອນໃດບ່ອນຫນຶ່ງ. ດັ່ງນັ້ນ HBase ບໍ່ພຽງແຕ່ເກັບຮັກສາຂໍ້ມູນ, ແຕ່ຍັງມີຄວາມລຶກລັບທີ່ລຶກລັບ.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

ພາຣາມິເຕີ "Cache DATA on Read" ຖືກຕັ້ງເປັນຜິດ. ຖ້າ​ຫາກ​ທ່ານ​ມີ​ຄວາມ​ຄິດ​ເຫັນ​ໃດ​ຫນຶ່ງ​, ຍິນ​ດີ​ຕ້ອນ​ຮັບ​ເພື່ອ​ປຶກ​ສາ​ຫາ​ລື​ໃນ​ຄໍາ​ເຫັນ​.

5. ການປະມວນຜົນຂໍ້ມູນ batch MultiGet/MultiPut

ການປະມວນຜົນການຮ້ອງຂໍດຽວ (Get / Put / Delete) ແມ່ນຂ້ອນຂ້າງເປັນການດໍາເນີນງານລາຄາແພງ, ດັ່ງນັ້ນ, ຖ້າເປັນໄປໄດ້, ທ່ານຄວນລວມພວກມັນເຂົ້າໄປໃນບັນຊີລາຍຊື່ຫຼືລາຍຊື່, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານໄດ້ຮັບການເພີ່ມປະສິດທິພາບຢ່າງຫຼວງຫຼາຍ. ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະສໍາລັບການດໍາເນີນການຂຽນ, ແຕ່ໃນເວລາທີ່ອ່ານມີ pitfall ດັ່ງຕໍ່ໄປນີ້. ເສັ້ນສະແດງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນເວລາທີ່ຈະອ່ານ 50 ບັນທຶກຈາກ MemStore. ການອ່ານໄດ້ຖືກປະຕິບັດໃນຫນຶ່ງກະທູ້ແລະແກນອອກຕາມລວງນອນສະແດງໃຫ້ເຫັນຈໍານວນຂອງຄີໃນຄໍາຮ້ອງຂໍ. ໃນທີ່ນີ້ທ່ານສາມາດເຫັນໄດ້ວ່າເມື່ອເພີ່ມຂຶ້ນເປັນພັນກະແຈໃນຫນຶ່ງຄໍາຮ້ອງຂໍ, ເວລາການປະຕິບັດຫຼຸດລົງ, i.e. ຄວາມ​ໄວ​ເພີ່ມ​ຂຶ້ນ​. ຢ່າງໃດກໍຕາມ, ດ້ວຍຮູບແບບ MSLAB ທີ່ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ຫຼັງຈາກຂອບເຂດນີ້, ການປະຕິບັດການຫຼຸດລົງຢ່າງຫຼວງຫຼາຍເລີ່ມຕົ້ນ, ແລະຈໍານວນຂໍ້ມູນໃນບັນທຶກຂະຫນາດໃຫຍ່, ເວລາປະຕິບັດງານດົນຂຶ້ນ.

ການທົດສອບໄດ້ຖືກປະຕິບັດຢູ່ໃນເຄື່ອງ virtual, 8 cores, ຮຸ່ນ HBase 2.0.0-cdh6.0.0-beta1.

ໂຫມດ MSLAB ຖືກອອກແບບມາເພື່ອຫຼຸດຜ່ອນການແບ່ງສ່ວນຂອງ heap, ເຊິ່ງເກີດຂື້ນຍ້ອນການປະສົມຂໍ້ມູນການຜະລິດໃຫມ່ແລະເກົ່າ. ໃນ​ຖາ​ນະ​ເປັນ​ການ​ແກ້​ໄຂ​, ໃນ​ເວ​ລາ​ທີ່ MSLAB ຖືກ​ເປີດ​ໃຫ້​ໃຊ້​ງານ​, ຂໍ້​ມູນ​ໄດ້​ຖືກ​ຈັດ​ໃສ່​ໃນ​ຈຸ​ລັງ​ທີ່​ຂ້ອນ​ຂ້າງ​ຂະ​ຫນາດ​ນ້ອຍ (chunks​) ແລະ​ປະ​ມວນ​ຜົນ​ເປັນ​ຕ່ອນ​. ດັ່ງນັ້ນ, ເມື່ອປະລິມານໃນຊຸດຂໍ້ມູນທີ່ຮ້ອງຂໍເກີນຂະຫນາດທີ່ຈັດສັນ, ການປະຕິບັດຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ໃນທາງກົງກັນຂ້າມ, ການປິດໂຫມດນີ້ກໍ່ບໍ່ສົມຄວນ, ເພາະວ່າມັນຈະນໍາໄປສູ່ການຢຸດເຊົາເນື່ອງຈາກ GC ໃນຊ່ວງເວລາຂອງການປະມວນຜົນຂໍ້ມູນແບບສຸມ. ການແກ້ໄຂທີ່ດີແມ່ນການເພີ່ມປະລິມານຂອງເຊນໃນກໍລະນີຂອງການຂຽນຢ່າງຫ້າວຫັນຜ່ານໃສ່ໃນເວລາດຽວກັນກັບການອ່ານ. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າບັນຫາບໍ່ເກີດຂື້ນຖ້າ, ຫຼັງຈາກການບັນທຶກ, ທ່ານດໍາເນີນການຄໍາສັ່ງ flush, ເຊິ່ງຕັ້ງ MemStore ກັບແຜ່ນ, ຫຼືຖ້າທ່ານໂຫລດໂດຍໃຊ້ BulkLoad. ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວ່າການສອບຖາມຈາກ MemStore ສໍາລັບຂໍ້ມູນຂະຫນາດໃຫຍ່ (ແລະຈໍານວນດຽວກັນ) ສົ່ງຜົນໃຫ້ຊ້າລົງ. ຢ່າງໃດກໍຕາມ, ໂດຍການເພີ່ມ chunksize ພວກເຮົາກັບຄືນເວລາການປຸງແຕ່ງເປັນປົກກະຕິ.

ນອກເຫນືອຈາກການເພີ່ມ chunksize, ການແຍກຂໍ້ມູນໂດຍພາກພື້ນຊ່ວຍ, i.e. ການ​ແຍກ​ຕາ​ຕະ​ລາງ​. ນີ້ເຮັດໃຫ້ການຮ້ອງຂໍຫນ້ອຍລົງໄປຫາແຕ່ລະພາກພື້ນແລະຖ້າພວກມັນເຫມາະກັບຫ້ອງ, ການຕອບສະຫນອງຍັງຄົງດີ.

6. ຍຸດ​ທະ​ສາດ​ການ​ແບ່ງ​ຕາ​ຕະ​ລາງ​ອອກ​ເປັນ​ພາກ​ພື້ນ (splitting​)

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

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

1000001
1000002
...
1100003

ເນື່ອງຈາກກະແຈຖືກເກັບໄວ້ເປັນ byte array, ພວກມັນທັງໝົດຈະເລີ່ມອັນດຽວກັນ ແລະເປັນຂອງພາກພື້ນດຽວກັນ #1 ເກັບຮັກສາລະຫັດນີ້ໄວ້. ມີຫຼາຍຍຸດທະສາດການແບ່ງສ່ວນ:

HexStringSplit – ປ່ຽນລະຫັດໃຫ້ເປັນສະຕຣິງທີ່ເຂົ້າລະຫັດເລກຖານສິບຫົກໃນໄລຍະ "00000000" => "FFFFFFFF" ແລະວາງຊ້າຍດ້ວຍສູນ.

UniformSplit – ປ່ຽນກະແຈເປັນ byte array ດ້ວຍການເຂົ້າລະຫັດເລກຖານສິບຫົກໃນໄລຍະ "00" => "FF" ແລະ padding ຢູ່ເບື້ອງຂວາດ້ວຍສູນ.

ນອກ​ຈາກ​ນັ້ນ​, ທ່ານ​ສາ​ມາດ​ກໍາ​ນົດ​ໄລ​ຍະ​ໃດ​ຫນຶ່ງ​ຫຼື​ຊຸດ​ຂອງ​ກະ​ແຈ​ສໍາ​ລັບ​ການ​ແຍກ​ແລະ​ການ​ຕັ້ງ​ຄ່າ​ການ​ແຍກ​ອັດ​ຕະ​ໂນ​ມັດ​. ຢ່າງໃດກໍຕາມ, ຫນຶ່ງໃນວິທີການທີ່ງ່າຍດາຍທີ່ສຸດແລະປະສິດທິພາບຫຼາຍທີ່ສຸດແມ່ນ UniformSplit ແລະການນໍາໃຊ້ hash concatenation, ສໍາລັບການຍົກຕົວຢ່າງ, ຄູ່ທີ່ສໍາຄັນຂອງ bytes ຈາກການແລ່ນຄີໂດຍຜ່ານຟັງຊັນ CRC32 (rowkey) ແລະ rowkey ຕົວຂອງມັນເອງ:

hash + rowkey

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

7. ຄວາມທົນທານຄວາມຜິດແລະຂໍ້ມູນທ້ອງຖິ່ນ

ເນື່ອງຈາກມີພຽງແຕ່ພາກພື້ນຫນຶ່ງທີ່ຮັບຜິດຊອບສໍາລັບແຕ່ລະຊຸດຂອງກະແຈ, ການແກ້ໄຂບັນຫາທີ່ກ່ຽວຂ້ອງກັບ RS crashs ຫຼື decommissioning ແມ່ນເພື່ອເກັບຮັກສາຂໍ້ມູນທີ່ຈໍາເປັນທັງຫມົດໃນ HDFS. ເມື່ອ RS ຕົກ, ແມ່ບົດກວດພົບນີ້ໂດຍຜ່ານການຂາດການເຕັ້ນຂອງຫົວໃຈຢູ່ໃນຂໍ້ ZooKeeper. ຫຼັງຈາກນັ້ນ, ມັນມອບຫມາຍພາກພື້ນທີ່ຮັບຜິດຊອບໃຫ້ກັບ RS ອື່ນແລະນັບຕັ້ງແຕ່ HFiles ຖືກເກັບໄວ້ໃນລະບົບໄຟລ໌ທີ່ແຈກຢາຍ, ເຈົ້າຂອງໃຫມ່ອ່ານພວກເຂົາແລະສືບຕໍ່ໃຫ້ບໍລິການຂໍ້ມູນ. ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກວ່າບາງຂໍ້ມູນອາດຈະຢູ່ໃນ MemStore ແລະບໍ່ມີເວລາທີ່ຈະເຂົ້າໄປໃນ HFiles, WAL, ເຊິ່ງຍັງຖືກເກັບໄວ້ໃນ HDFS, ຖືກນໍາໃຊ້ເພື່ອຟື້ນຟູປະຫວັດການດໍາເນີນງານ. ຫຼັງຈາກການປ່ຽນແປງໄດ້ຖືກນໍາໃຊ້, RS ສາມາດຕອບສະຫນອງຄໍາຮ້ອງຂໍ, ແຕ່ການເຄື່ອນໄຫວນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າບາງຂໍ້ມູນແລະຂະບວນການທີ່ໃຫ້ບໍລິການພວກເຂົາສິ້ນສຸດລົງໃນ nodes ທີ່ແຕກຕ່າງກັນ, i.e. ທ້ອງ​ຖິ່ນ​ແມ່ນ​ຫຼຸດ​ລົງ.

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

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

ການທົດສອບໄດ້ຖືກປະຕິບັດໃນ 3 DataNodes ແລະ 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ເວີຊັນ 1.2.0-cdh5.14.2

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

ນອກຈາກນີ້, ການບີບອັດທີ່ສໍາຄັນບໍ່ມີຜົນກະທົບຕໍ່ສະຖານະຂອງ MemStore; ເພື່ອລ້າງມັນໃສ່ແຜ່ນດິດແລະຫນາແຫນ້ນ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. ການຕັ້ງຄ່າແລະການປະຕິບັດ

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

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

— ເອົາ
— ໄດ້​ຮັບ
- ເອົາ + ໃສ່

• ແຕ່ລະທ່ອນໄມ້ປະຕິບັດ 50 ຊ້ຳຂອງການປະຕິບັດງານຂອງມັນ.
• ຂະໜາດບລັອກຂອງບັນທຶກແມ່ນ 100 bytes, 1000 bytes ຫຼື 10000 bytes (ສຸ່ມ).
• Blocks ໄດ້ຖືກເປີດຕົວດ້ວຍຕົວເລກທີ່ແຕກຕ່າງກັນຂອງກະແຈທີ່ຮ້ອງຂໍ (ບໍ່ວ່າຈະເປັນລະຫັດຫນຶ່ງຫຼື 10).
• ຕັນໄດ້ຖືກດໍາເນີນການພາຍໃຕ້ການຕັ້ງຄ່າຕາຕະລາງທີ່ແຕກຕ່າງກັນ. ຕົວກໍານົດການມີການປ່ຽນແປງ:

- BlockCache = ເປີດ ຫຼື ປິດ
- BlockSize = 65 KB ຫຼື 16 KB
- ການແບ່ງສ່ວນ = 1, 5 ຫຼື 30
— MSLAB = ເປີດ ຫຼື ປິດໃຊ້ງານ

ດັ່ງນັ້ນ, ຕັນເບິ່ງຄືວ່ານີ້:

ກ. ໂໝດ MSLAB ຖືກເປີດ/ປິດແລ້ວ.
ຂ. ຕາຕະລາງໄດ້ຖືກສ້າງຂື້ນເພື່ອກໍານົດພາລາມິເຕີຕໍ່ໄປນີ້: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
ຄ. ການບີບອັດຖືກຕັ້ງເປັນ GZ.
ງ. 10 ກະທູ້ຖືກເປີດຕົວພ້ອມໆກັນເຮັດ 1/10 put/get/get+ ປະຕິບັດການໃສ່ໃນຕາຕະລາງນີ້ດ້ວຍບັນທຶກ 100/1000/10000 bytes, ປະຕິບັດ 50 ຄໍາຖາມຕິດຕໍ່ກັນ (ກະແຈແບບສຸ່ມ).
e. ຈຸດ d ຖືກຊ້ໍາສາມເທື່ອ.
f. ເວລາປະຕິບັດງານຂອງຫົວຂໍ້ທັງຫມົດແມ່ນສະເລ່ຍ.

ການປະສົມທີ່ເປັນໄປໄດ້ທັງຫມົດໄດ້ຖືກທົດສອບ. ມັນຄາດເດົາໄດ້ວ່າຄວາມໄວຈະຫຼຸດລົງເນື່ອງຈາກຂະຫນາດຂອງບັນທຶກເພີ່ມຂຶ້ນ, ຫຼືວ່າການປິດການເກັບຂໍ້ມູນຈະເຮັດໃຫ້ຊ້າລົງ. ຢ່າງໃດກໍ່ຕາມ, ເປົ້າຫມາຍແມ່ນເພື່ອເຂົ້າໃຈລະດັບແລະຄວາມມີຄວາມສໍາຄັນຂອງອິດທິພົນຂອງແຕ່ລະຕົວກໍານົດການ, ດັ່ງນັ້ນຂໍ້ມູນທີ່ເກັບກໍາໄດ້ຖືກປ້ອນເຂົ້າໃນການປ້ອນຂໍ້ມູນຂອງຫນ້າທີ່ regression ເສັ້ນ, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປະເມີນຄວາມສໍາຄັນໂດຍໃຊ້ສະຖິຕິ t. ຂ້າງລຸ່ມນີ້ແມ່ນຜົນໄດ້ຮັບຂອງທ່ອນໄມ້ທີ່ປະຕິບັດການດໍາເນີນການ Put. ຊຸດຄົບຊຸດ 2*2*3*2*3 = 144 ໂຕເລືອກ + 72 ໂຕ. ບາງຄົນໄດ້ເຮັດສອງຄັ້ງ. ດັ່ງນັ້ນ, ມີທັງໝົດ 216 ແລ່ນ:

ການທົດສອບໄດ້ຖືກດໍາເນີນຢູ່ໃນ mini-cluster ປະກອບດ້ວຍ 3 DataNodes ແລະ 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ເວີຊັນ 1.2.0-cdh5.14.2.

ຄວາມໄວການແຊກສູງສຸດຂອງ 3.7 ວິນາທີແມ່ນໄດ້ຮັບດ້ວຍໂຫມດ MSLAB ປິດ, ໃນຕາຕະລາງທີ່ມີການແບ່ງປັນຫນຶ່ງ, ດ້ວຍ BlockCache ເປີດໃຊ້, BlockSize = 16, ບັນທຶກ 100 bytes, 10 ຊິ້ນຕໍ່ຊອງ.
ຄວາມໄວການແຊກຕ່ໍາສຸດຂອງ 82.8 ວິນາທີແມ່ນໄດ້ຮັບດ້ວຍໂຫມດ MSLAB ທີ່ເປີດໃຊ້, ໃນຕາຕະລາງທີ່ມີການແບ່ງປັນຫນຶ່ງ, ດ້ວຍ BlockCache ເປີດໃຊ້, BlockSize = 16, ບັນທຶກຂອງ 10000 bytes, 1 ແຕ່ລະຄົນ.

ຕອນນີ້ໃຫ້ເບິ່ງຕົວແບບ. ພວກເຮົາເຫັນຄຸນນະພາບທີ່ດີຂອງຕົວແບບໂດຍອີງໃສ່ R2, ແຕ່ວ່າມັນເປັນທີ່ຊັດເຈນຢ່າງແທ້ຈິງວ່າ extrapolation ແມ່ນ contraindicated ຢູ່ທີ່ນີ້. ພຶດຕິກໍາຕົວຈິງຂອງລະບົບໃນເວລາທີ່ການປ່ຽນແປງຕົວກໍານົດການຈະບໍ່ເປັນເສັ້ນ; ຮູບແບບນີ້ບໍ່ຈໍາເປັນສໍາລັບການຄາດເດົາ, ແຕ່ສໍາລັບການເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນພາຍໃນຕົວກໍານົດການ. ຕົວຢ່າງ, ໃນທີ່ນີ້ພວກເຮົາເຫັນເງື່ອນໄຂຂອງນັກຮຽນວ່າຕົວກໍານົດການ BlockSize ແລະ BlockCache ບໍ່ສໍາຄັນສໍາລັບການປະຕິບັດງານ Put (ເຊິ່ງໂດຍທົ່ວໄປແລ້ວແມ່ນຂ້ອນຂ້າງຄາດເດົາ):

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

ຕອນນີ້ໃຫ້ພວກເຮົາປະເມີນຜົນໄດ້ຮັບຂອງການປະຕິບັດ Get blocks:

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

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

ຕົວກໍານົດການທັງຫມົດແມ່ນມີຄວາມສໍາຄັນຢູ່ທີ່ນີ້. ແລະຜົນໄດ້ຮັບຂອງຜູ້ນໍາ:

9. ການທົດສອບການໂຫຼດ

ແລ້ວ, ສຸດທ້າຍພວກເຮົາຈະເປີດຕົວການໂຫຼດທີ່ເຫມາະສົມຫຼາຍຫຼືຫນ້ອຍ, ແຕ່ມັນສະເຫມີທີ່ຫນ້າສົນໃຈຫຼາຍໃນເວລາທີ່ທ່ານມີບາງສິ່ງບາງຢ່າງທີ່ຈະປຽບທຽບກັບ. ຢູ່ໃນເວັບໄຊທ໌ຂອງ DataStax, ຜູ້ພັດທະນາທີ່ສໍາຄັນຂອງ Cassandra, ມີ ຜົນໄດ້ຮັບ NT ຂອງຈໍານວນການເກັບຮັກສາ NoSQL, ລວມທັງ HBase ຮຸ່ນ 0.98.6-1. ການໂຫຼດໄດ້ຖືກປະຕິບັດໂດຍ 40 ກະທູ້, ຂະຫນາດຂໍ້ມູນ 100 bytes, ແຜ່ນ SSD. ຜົນຂອງການທົດສອບການດໍາເນີນການ Read-Modify-Write ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້.

ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, ການອ່ານໄດ້ຖືກປະຕິບັດຢູ່ໃນບລັອກຂອງ 100 ບັນທຶກແລະສໍາລັບ 16 HBase nodes, ການທົດສອບ DataStax ສະແດງໃຫ້ເຫັນການປະຕິບັດ 10 ພັນຕໍ່ວິນາທີ.

ມັນໂຊກດີທີ່ກຸ່ມຂອງພວກເຮົາຍັງມີ 16 nodes, ແຕ່ມັນບໍ່ "ໂຊກດີ" ທີ່ແຕ່ລະຄົນມີ 64 cores (ກະທູ້), ໃນຂະນະທີ່ໃນການທົດສອບ DataStax ມີພຽງແຕ່ 4. ໃນທາງກົງກັນຂ້າມ, ພວກມັນມີໄດ SSD, ໃນຂະນະທີ່ພວກເຮົາມີ HDDs. ຫຼືຫຼາຍກວ່ານັ້ນ, ຮຸ່ນໃຫມ່ຂອງ HBase ແລະການນໍາໃຊ້ CPU ໃນລະຫວ່າງການໂຫຼດໄດ້ປະຕິບັດບໍ່ໄດ້ເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ (ເບິ່ງໂດຍ 5-10 ເປີເຊັນ). ຢ່າງໃດກໍຕາມ, ໃຫ້ພະຍາຍາມເລີ່ມຕົ້ນການນໍາໃຊ້ການຕັ້ງຄ່ານີ້. ການຕັ້ງຄ່າຕາຕະລາງເລີ່ມຕົ້ນ, ການອ່ານແມ່ນປະຕິບັດຢູ່ໃນລະດັບທີ່ສໍາຄັນຈາກ 0 ຫາ 50 ລ້ານແບບສຸ່ມ (i. e. ເປັນສິ່ງຈໍາເປັນໃຫມ່ທຸກໆຄັ້ງ). ຕາຕະລາງປະກອບດ້ວຍ 50 ລ້ານບັນທຶກ, ແບ່ງອອກເປັນ 64 ພາກສ່ວນ. ກະແຈຖືກແກັດໂດຍໃຊ້ crc32. ການຕັ້ງຄ່າຕາຕະລາງແມ່ນຄ່າເລີ່ມຕົ້ນ, MSLAB ຖືກເປີດໃຊ້. ການເປີດຕົວ 40 ກະທູ້, ແຕ່ລະກະທູ້ຈະອ່ານຊຸດຂອງກະແຈແບບສຸ່ມ 100 ແລະຂຽນ 100 bytes ທີ່ສ້າງຂຶ້ນໃນທັນທີກັບຄືນໄປຫາກະແຈເຫຼົ່ານີ້.

Stand: 16 DataNode ແລະ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ເວີຊັນ 1.2.0-cdh5.14.2.

ຜົນໄດ້ຮັບສະເລ່ຍແມ່ນໃກ້ຊິດກັບ 40 ພັນການດໍາເນີນງານຕໍ່ວິນາທີ, ເຊິ່ງດີກວ່າໃນການທົດສອບ DataStax. ຢ່າງໃດກໍຕາມ, ສໍາລັບຈຸດປະສົງທົດລອງ, ທ່ານສາມາດປ່ຽນເງື່ອນໄຂເລັກນ້ອຍ. ມັນຂ້ອນຂ້າງເປັນໄປບໍ່ໄດ້ວ່າວຽກງານທັງຫມົດຈະຖືກດໍາເນີນຢູ່ໃນຕາຕະລາງດຽວ, ແລະພຽງແຕ່ໃສ່ກະແຈທີ່ເປັນເອກະລັກເທົ່ານັ້ນ. ໃຫ້ສົມມຸດວ່າມີຊຸດກະແຈ "ຮ້ອນ" ທີ່ແນ່ນອນທີ່ເຮັດໃຫ້ເກີດການໂຫຼດຕົ້ນຕໍ. ດັ່ງນັ້ນ, ໃຫ້ພະຍາຍາມສ້າງການໂຫຼດທີ່ມີບັນທຶກທີ່ໃຫຍ່ກວ່າ (10 KB), ຍັງເປັນ batch ຂອງ 100, ໃນ 4 ຕາຕະລາງທີ່ແຕກຕ່າງກັນແລະຈໍາກັດຂອບເຂດຂອງລະຫັດທີ່ຮ້ອງຂໍໃຫ້ 50 ພັນ. ເສັ້ນສະແດງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນການເປີດຕົວຂອງ 40 thread, ແຕ່ລະກະທູ້ອ່ານ. ຊຸດຂອງກະແຈ 100 ແລະທັນທີຂຽນແບບສຸ່ມ 10 KB ໃສ່ກະແຈເຫຼົ່ານີ້ຄືນ.

Stand: 16 DataNode ແລະ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ເວີຊັນ 1.2.0-cdh5.14.2.

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

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

Stand: 16 DataNode ແລະ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ເວີຊັນ 1.2.0-cdh5.14.2.

10. ບົດສະຫຼຸບ

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

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

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