ຄຸນລັກສະນະຂອງການອອກແບບຕົວແບບຂໍ້ມູນສໍາລັບ NoSQL

ການນໍາສະເຫນີ

“ເຈົ້າຕ້ອງແລ່ນໃຫ້ໄວເທົ່າທີ່ຈະເຮັດໄດ້ ເພື່ອຈະຢູ່ບ່ອນນັ້ນ,
ແລະເພື່ອໄປບ່ອນໃດບ່ອນໜຶ່ງ, ເຈົ້າຕ້ອງແລ່ນໄວກວ່າສອງເທົ່າ!”
(c) Alice in Wonderland

ບາງຄັ້ງກ່ອນຫນ້ານີ້ຂ້ອຍໄດ້ຖືກຂໍໃຫ້ບັນຍາຍ ນັກວິເຄາະ ບໍລິສັດຂອງພວກເຮົາກ່ຽວກັບຫົວຂໍ້ຂອງການອອກແບບແບບຈໍາລອງຂໍ້ມູນ, ເນື່ອງຈາກວ່ານັ່ງຢູ່ໃນໂຄງການສໍາລັບເວລາດົນນານ (ບາງຄັ້ງເປັນເວລາຫລາຍປີ) ພວກເຮົາສູນເສຍການເບິ່ງເຫັນສິ່ງທີ່ເກີດຂື້ນຢູ່ອ້ອມຮອບພວກເຮົາໃນໂລກຂອງເຕັກໂນໂລຢີ IT. ໃນບໍລິສັດຂອງພວກເຮົາ (ມັນເກີດຂຶ້ນຫຼາຍ) ໂຄງການຈໍານວນຫຼາຍບໍ່ໄດ້ໃຊ້ຖານຂໍ້ມູນ NoSQL (ຢ່າງຫນ້ອຍສໍາລັບໃນປັດຈຸບັນ), ດັ່ງນັ້ນໃນບົດບັນຍາຍຂອງຂ້ອຍຂ້ອຍໄດ້ເອົາໃຈໃສ່ບາງສ່ວນໃຫ້ພວກເຂົາໂດຍໃຊ້ຕົວຢ່າງຂອງ HBase ແລະພະຍາຍາມທິດທາງການນໍາສະເຫນີຂອງອຸປະກອນເຫຼົ່ານັ້ນ. ຜູ້ທີ່ບໍ່ເຄີຍໃຊ້ພວກມັນໄດ້ຜົນ. ໂດຍສະເພາະ, ຂ້າພະເຈົ້າໄດ້ສະແດງໃຫ້ເຫັນບາງລັກສະນະຂອງການອອກແບບຕົວແບບຂໍ້ມູນໂດຍໃຊ້ຕົວຢ່າງທີ່ຂ້ອຍອ່ານຫລາຍປີກ່ອນ ໃນບົດຄວາມ "ການແນະນໍາ HB ase Schema Design" ໂດຍ Amandeep Khurana. ເມື່ອວິເຄາະຕົວຢ່າງ, ຂ້າພະເຈົ້າໄດ້ປຽບທຽບທາງເລືອກຫຼາຍຢ່າງສໍາລັບການແກ້ໄຂບັນຫາດຽວກັນເພື່ອຖ່າຍທອດແນວຄວາມຄິດຕົ້ນຕໍໃຫ້ກັບຜູ້ຊົມໄດ້ດີຂຶ້ນ.

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

ຕົວຢ່າງການວິເຄາະ

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

ໃຫ້ພິຈາລະນາບັນຫາ "ສັງເຄາະ" ຕໍ່ໄປນີ້, ເຊິ່ງພວກເຮົາຈະສືບຕໍ່ເຮັດວຽກ:

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

• ຕອບຄໍາຖາມວ່າຜູ້ໃຊ້ A ອ່ານຜູ້ໃຊ້ B (ຮູບແບບການອ່ານ)
• ອະ​ນຸ​ຍາດ​ໃຫ້​ເພີ່ມ / ລົບ​ການ​ເຊື່ອມ​ຕໍ່​ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ການ​ສະ​ຫມັກ / unsubscribe ຂອງ​ຜູ້​ໃຊ້ A ຈາກ​ຜູ້​ໃຊ້ B (ແມ່​ແບບ​ການ​ປ່ຽນ​ແປງ​ຂໍ້​ມູນ​)

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

user_id
friend_id

Vasya
ເປໂຕ

Vasya
Olya

ຕໍ່ໄປນີ້, ເພື່ອຄວາມຊັດເຈນແລະຄວາມເຂົ້າໃຈດີຂຶ້ນ, ຂ້ອຍຈະຊີ້ບອກຊື່ແທນ IDs

ໃນກໍລະນີຂອງ HBase, ພວກເຮົາຮູ້ວ່າ:

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

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

RowKey
ລໍາໂພງ

Vasya
1: Petya
2: ໂອລີຢາ
3: Dasha

ເປໂຕ
1: Masha
2: Vasya

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

• ຄວາມສາມາດໃນການປ່ຽນອົງປະກອບຂອງຖັນແບບເຄື່ອນໄຫວ (ເພີ່ມເພື່ອນ -> ເພີ່ມຖັນ, ເອົາເພື່ອນ -> ລຶບຖັນ)
• ແຖວຕ່າງໆອາດມີອົງປະກອບຖັນທີ່ແຕກຕ່າງກັນ

ໃຫ້ກວດເບິ່ງໂຄງສ້າງຂອງພວກເຮົາສໍາລັບການປະຕິບັດຕາມຄວາມຕ້ອງການຂອງວຽກງານ:

• ການອ່ານຂໍ້ມູນ: ເພື່ອເຂົ້າໃຈວ່າ Vasya ລົງທະບຽນກັບ Olya, ພວກເຮົາຈະຕ້ອງລົບອອກ ເສັ້ນທັງຫມົດ ໂດຍປຸ່ມ RowKey = "Vasya" ແລະຈັດລຽງຕາມຄ່າຂອງຖັນຈົນກ່ວາພວກເຮົາ "ພົບ" Olya ໃນພວກມັນ. ຫຼື iterate ຜ່ານຄ່າຂອງຄໍລໍາທັງຫມົດ, "ບໍ່ຕອບສະຫນອງ" Olya ແລະກັບຄືນຄໍາຕອບ False;
• ການແກ້ໄຂຂໍ້ມູນ: ເພີ່ມເພື່ອນ: ສໍາລັບວຽກງານທີ່ຄ້າຍຄືກັນພວກເຮົາຍັງຈໍາເປັນຕ້ອງໄດ້ລົບ ເສັ້ນທັງຫມົດ ໃຊ້ປຸ່ມ RowKey = "Vasya" ເພື່ອຄິດໄລ່ຈໍານວນຫມູ່ເພື່ອນຂອງລາວທັງຫມົດ. ພວກເຮົາຕ້ອງການຈໍານວນເພື່ອນທັງຫມົດນີ້ເພື່ອກໍານົດຈໍານວນຄໍລໍາທີ່ພວກເຮົາຕ້ອງການຂຽນ ID ຂອງເພື່ອນໃຫມ່.
• ການປ່ຽນແປງຂໍ້ມູນ: ການລຶບເພື່ອນ:
  • ຕ້ອງການລົບ ເສັ້ນທັງຫມົດ ໂດຍປຸ່ມ RowKey = "Vasya" ແລະຈັດຮຽງຕາມຖັນເພື່ອຊອກຫາຫນຶ່ງທີ່ເພື່ອນທີ່ຈະລຶບໄດ້ຖືກບັນທຶກໄວ້;
  • ຕໍ່ໄປ, ຫຼັງຈາກການລຶບເພື່ອນ, ພວກເຮົາຈໍາເປັນຕ້ອງ "ປ່ຽນ" ຂໍ້ມູນທັງຫມົດເຂົ້າໄປໃນຖັນດຽວເພື່ອບໍ່ໃຫ້ "ຊ່ອງຫວ່າງ" ໃນຕົວເລກຂອງພວກເຂົາ.

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

• ການອ່ານຂໍ້ມູນ: ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະລົບເສັ້ນທັງຫມົດແລະ iterate ຜ່ານຖັນທັງຫມົດຂອງມັນຢູ່ໃນຂອບເຂດຈໍາກັດ. ນີ້ຫມາຍຄວາມວ່າການຄາດຄະເນດ້ານເທິງຂອງຄ່າໃຊ້ຈ່າຍຈະເປັນປະມານ O(n)
• ການແກ້ໄຂຂໍ້ມູນ: ເພີ່ມເພື່ອນ: ເພື່ອກໍານົດຈໍານວນຫມູ່ເພື່ອນ, ທ່ານຈໍາເປັນຕ້ອງເຮັດຊ້ໍາທຸກຖັນຂອງແຖວ, ແລະຫຼັງຈາກນັ້ນໃສ່ຖັນໃຫມ່ => O(n)
• ການປ່ຽນແປງຂໍ້ມູນ: ການລຶບເພື່ອນ:
  • ຄ້າຍຄືກັບການເພີ່ມ - ທ່ານຈໍາເປັນຕ້ອງຜ່ານຖັນທັງຫມົດໃນຂອບເຂດຈໍາກັດ => O(n)
  • ຫຼັງຈາກຖອນຄໍລໍາ, ພວກເຮົາຈໍາເປັນຕ້ອງ "ຍ້າຍ" ພວກມັນ. ຖ້າ​ຫາກ​ທ່ານ​ປະ​ຕິ​ບັດ "ຫົວ​ຫນ້າ​" ນີ້​, ຫຼັງ​ຈາກ​ນັ້ນ​ໃນ​ຂອບ​ເຂດ​ຈໍາ​ກັດ​ທີ່​ທ່ານ​ຈະ​ຕ້ອງ​ການ​ເຖິງ (n​-1​) ການ​ດໍາ​ເນີນ​ງານ​. ແຕ່ໃນທີ່ນີ້ແລະຕໍ່ໄປໃນພາກປະຕິບັດ, ພວກເຮົາຈະນໍາໃຊ້ວິທີການທີ່ແຕກຕ່າງກັນ, ເຊິ່ງຈະປະຕິບັດ "pseudo-shift" ສໍາລັບຈໍານວນການດໍາເນີນງານຄົງທີ່ - ນັ້ນແມ່ນ, ເວລາຄົງທີ່ຈະຖືກໃຊ້ກັບມັນ, ບໍ່ວ່າຈະເປັນ n. ເວລາຄົງທີ່ນີ້ (O(2) ເປັນທີ່ແນ່ນອນ) ສາມາດຖືກລະເລີຍທຽບກັບ O(n). ວິທີການແມ່ນສະແດງໃຫ້ເຫັນໃນຮູບຂ້າງລຸ່ມນີ້: ພວກເຮົາພຽງແຕ່ຄັດລອກຂໍ້ມູນຈາກຖັນ "ສຸດທ້າຍ" ໄປຫາຫນຶ່ງທີ່ພວກເຮົາຕ້ອງການລຶບຂໍ້ມູນ, ແລະຫຼັງຈາກນັ້ນລຶບຖັນສຸດທ້າຍ:
    

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

RowKey
ລໍາໂພງ

Vasya
1: Petya
2: ໂອລີຢາ
3: Dasha
ນັບ: 3

ເປໂຕ
1: Masha
2: Vasya

ນັບ: 2

ເມື່ອປຽບທຽບກັບທາງເລືອກທໍາອິດ:

• ການອ່ານຂໍ້ມູນ: ເພື່ອໃຫ້ໄດ້ຮັບຄໍາຕອບຂອງຄໍາຖາມ "Vasya ອ່ານ Olya ບໍ?" ບໍ່ມີຫຍັງປ່ຽນແປງ => O(n)
• ການແກ້ໄຂຂໍ້ມູນ: ເພີ່ມເພື່ອນ: ພວກເຮົາໄດ້ເຮັດໃຫ້ການແຊກຂອງເພື່ອນໃຫມ່ງ່າຍດາຍ, ນັບຕັ້ງແຕ່ນີ້ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງອ່ານເສັ້ນທັງຫມົດແລະ iterate ໃນຖັນຂອງມັນ, ແຕ່ພຽງແຕ່ສາມາດໄດ້ຮັບຄ່າຂອງຖັນ "ນັບ", ແລະອື່ນໆ. ທັນທີກໍານົດຕົວເລກຖັນເພື່ອແຊກເພື່ອນໃຫມ່. ອັນ​ນີ້​ເຮັດ​ໃຫ້​ການ​ຫຼຸດ​ຜ່ອນ​ຄວາມ​ສັບ​ສົນ​ໃນ​ການ​ຄິດ​ໄລ່ O(1​)
• ການປ່ຽນແປງຂໍ້ມູນ: ການລຶບເພື່ອນ: ເມື່ອລຶບເພື່ອນອອກ, ພວກເຮົາຍັງສາມາດໃຊ້ຖັນນີ້ເພື່ອຫຼຸດຈໍານວນການດຳເນີນການ I/O ເມື່ອ “ປ່ຽນ” ຂໍ້ມູນໜຶ່ງຕາລາງໄປທາງຊ້າຍ. ແຕ່​ຄວາມ​ຈໍາ​ເປັນ​ທີ່​ຈະ iterate ຜ່ານ​ຖັນ​ເພື່ອ​ຊອກ​ຫາ​ຫນຶ່ງ​ທີ່​ຕ້ອງ​ການ​ລົບ​ຍັງ​ຄົງ​ຢູ່​, ສະ​ນັ້ນ => O(n)
• ໃນອີກດ້ານຫນຶ່ງ, ໃນປັດຈຸບັນໃນເວລາທີ່ການປັບປຸງຂໍ້ມູນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປັບປຸງຖັນ "ນັບ" ທຸກໆຄັ້ງ, ແຕ່ນີ້ໃຊ້ເວລາຄົງທີ່, ຊຶ່ງສາມາດຖືກລະເລີຍໃນກອບຂອງສັນຍາລັກ O.

ໂດຍທົ່ວໄປ, ທາງເລືອກ 2 ເບິ່ງຄືວ່າດີທີ່ສຸດ, ແຕ່ມັນຄ້າຍຄືກັບ "ວິວັດທະນາການແທນທີ່ຈະເປັນການປະຕິວັດ." ເພື່ອເຮັດໃຫ້ "ການປະຕິວັດ" ພວກເຮົາຕ້ອງການ ທາງ​ເລືອກ 3 (col).
ໃຫ້ຫັນທຸກສິ່ງທຸກຢ່າງ "ກັບ": ພວກເຮົາຈະມອບຫມາຍ ID ຜູ້ໃຊ້ຊື່ຖັນ! ສິ່ງທີ່ຈະຖືກຂຽນໄວ້ໃນຄໍລໍາຕົວມັນເອງບໍ່ສໍາຄັນສໍາລັບພວກເຮົາ, ໃຫ້ມັນເປັນອັນດັບ 1 (ໂດຍທົ່ວໄປ, ສິ່ງທີ່ເປັນປະໂຫຍດສາມາດຖືກເກັບໄວ້ຢູ່ທີ່ນັ້ນ, ຕົວຢ່າງ, ກຸ່ມ "ຄອບຄົວ / ຫມູ່ເພື່ອນ / ແລະອື່ນໆ."). ວິທີການນີ້ອາດຈະປະຫລາດໃຈກັບ "layman" ທີ່ບໍ່ໄດ້ກະກຽມທີ່ບໍ່ມີປະສົບການທີ່ຜ່ານມາເຮັດວຽກກັບຖານຂໍ້ມູນ NoSQL, ແຕ່ວ່າມັນແມ່ນແນ່ນອນວິທີການນີ້ອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ທ່າແຮງຂອງ HBase ໃນວຽກງານນີ້ຢ່າງມີປະສິດທິພາບຫຼາຍ:

RowKey
ລໍາໂພງ

Vasya
Petya: 1
ໂອລີຢາ: 1
Dasha: 1

ເປໂຕ
Masha: 1
ວາດສະໜາ: 1

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

• ການອ່ານຂໍ້ມູນ: ເພື່ອຕອບຄໍາຖາມວ່າ Vasya ລົງທະບຽນກັບ Olya, ມັນພຽງພໍທີ່ຈະອ່ານຫນຶ່ງຄໍລໍາ "Olya": ຖ້າມັນຢູ່ທີ່ນັ້ນ, ຄໍາຕອບແມ່ນຖືກຕ້ອງ, ຖ້າບໍ່ແມ່ນ - False => O(1)
• ການແກ້ໄຂຂໍ້ມູນ: ເພີ່ມເພື່ອນ: ການເພີ່ມໝູ່: ພຽງແຕ່ເພີ່ມຖັນໃໝ່ “Friend ID” => O(1)
• ການປ່ຽນແປງຂໍ້ມູນ: ການລຶບເພື່ອນ: ພຽງແຕ່ເອົາຖັນ Friend ID => O(1)

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

ທ່ານ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ puzzled ແລະ​ໄປ​ອີກ​ເລັກ​ນ້ອຍ​ຕາມ​ເສັ້ນ​ທາງ​ຂອງ​ການ​ປັບ​ປະ​ສິດ​ທິ​ພາບ​ແລະ​ການ​ຫຼຸດ​ຜ່ອນ​ການ​ດໍາ​ເນີນ​ງານ I/O ໃນ​ເວ​ລາ​ທີ່​ການ​ເຂົ້າ​ເຖິງ​ຖານ​ຂໍ້​ມູນ. ຈະເປັນແນວໃດຖ້າພວກເຮົາເກັບຂໍ້ມູນຄວາມສໍາພັນທີ່ສົມບູນໂດຍກົງຢູ່ໃນປຸ່ມແຖວຕົວມັນເອງ? ນັ້ນແມ່ນ, ເຮັດໃຫ້ອົງປະກອບທີ່ສໍາຄັນເຊັ່ນ userID.friendID? ໃນກໍລະນີນີ້, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງອ່ານຄໍລໍາຂອງແຖວເລີຍ (ຕົວເລືອກ 4 (ແຖວ)):

RowKey
ລໍາໂພງ

Vasya.Petya
Petya: 1

Vasya.Olya
ໂອລີຢາ: 1

Vasya.Dasha
Dasha: 1

Petya.Masha
Masha: 1

Petya.Vasya
ວາດສະໜາ: 1

ແນ່ນອນ, ການປະເມີນສະຖານະການການຈັດການຂໍ້ມູນທັງຫມົດໃນໂຄງສ້າງດັ່ງກ່າວ, ຄືກັບສະບັບທີ່ຜ່ານມາ, ຈະເປັນ O(1). ຄວາມແຕກຕ່າງກັບທາງເລືອກ 3 ຈະເປັນພຽງປະສິດທິພາບຂອງການປະຕິບັດງານ I/O ໃນຖານຂໍ້ມູນ.

ແລ້ວ, " bow " ສຸດທ້າຍ. ມັນງ່າຍທີ່ຈະເຫັນວ່າໃນທາງເລືອກ 4, ແຖວເກັດທີ່ຢູ່ຈະມີຄວາມຍາວປ່ຽນແປງ, ເຊິ່ງອາດຈະສົ່ງຜົນກະທົບຕໍ່ການປະຕິບັດ (ທີ່ນີ້ພວກເຮົາຈື່ຈໍາວ່າ HBase ເກັບຮັກສາຂໍ້ມູນເປັນຊຸດຂອງ bytes ແລະແຖວໃນຕາຕະລາງຖືກຈັດຮຽງໂດຍຄີ). ນອກຈາກນັ້ນ, ພວກເຮົາມີຕົວແຍກທີ່ອາດຈະຕ້ອງໄດ້ຮັບການຈັດການໃນບາງສະຖານະການ. ເພື່ອລົບລ້າງອິດທິພົນນີ້, ທ່ານສາມາດນໍາໃຊ້ hashes ຈາກ userID ແລະ friendID, ແລະນັບຕັ້ງແຕ່ທັງສອງ hashes ຈະມີຄວາມຍາວຄົງທີ່, ທ່ານພຽງແຕ່ສາມາດ concatenate ໃຫ້ເຂົາເຈົ້າ, ໂດຍບໍ່ມີການແຍກ. ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນໃນຕາຕະລາງຈະມີລັກສະນະນີ້ (ທາງ​ເລືອກ 5 (hash​)):

RowKey
ລໍາໂພງ

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ໂອລີຢາ: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
ວາດສະໜາ: 1

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

ກຳລັງເພີ່ມໝູ່
ກຳລັງກວດສອບໝູ່
ການລຶບເພື່ອນ

ທາງເລືອກ 1 (ຄ່າເລີ່ມຕົ້ນ)
O (n)
O (n)
O (n)

ທາງເລືອກ 2 (ນັບ)
O (1)
O (n)
O (n)

ຕົວເລືອກ 3 (ຖັນ)
O (1)
O (1)
O (1)

ທາງເລືອກ 4 (ແຖວ)
O (1)
O (1)
O (1)

ທາງ​ເລືອກ 5 (hash​)
O (1)
O (1)
O (1)

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

ການກະກຽມການທົດລອງ

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

• ເພີ່ມໝູ່ໃໝ່ໜຶ່ງຄົນ
• ກວດເບິ່ງວ່າຜູ້ໃຊ້ A ແມ່ນເພື່ອນຂອງຜູ້ໃຊ້ B
• ການ​ລົບ​ຫມູ່​ຫນຶ່ງ​

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

• ການບັນທຶກຂໍ້ມູນ. Random ສ້າງເຄືອຂ່າຍເບື້ອງຕົ້ນຂອງຂະຫນາດ n. ເພື່ອໃຫ້ໄດ້ໃກ້ຊິດກັບ "ໂລກທີ່ແທ້ຈິງ", ຈໍານວນຂອງຫມູ່ເພື່ອນທີ່ຜູ້ໃຊ້ແຕ່ລະຄົນມີຍັງເປັນຕົວແປແບບສຸ່ມ. ວັດແທກເວລາທີ່ມັນໃຊ້ສໍາລັບ "ຄໍາຮ້ອງສະຫມັກທີ່ມີເງື່ອນໄຂ" ຂອງພວກເຮົາເພື່ອຂຽນຂໍ້ມູນທັງຫມົດທີ່ສ້າງຂຶ້ນໃນ HBase. ຫຼັງຈາກນັ້ນ, ແບ່ງເວລາຜົນໄດ້ຮັບດ້ວຍຈໍານວນເພື່ອນທີ່ເພີ່ມ - ນີ້ແມ່ນວິທີທີ່ພວກເຮົາໄດ້ຮັບເວລາສະເລ່ຍສໍາລັບ "ການດໍາເນີນງານທຸລະກິດ" ຫນຶ່ງ.
• ການອ່ານຂໍ້ມູນ. ສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນ, ສ້າງບັນຊີລາຍຊື່ຂອງ "ບຸກຄະລິກກະພາບ" ທີ່ທ່ານຈໍາເປັນຕ້ອງໄດ້ຮັບຄໍາຕອບວ່າຜູ້ໃຊ້ໄດ້ລົງທະບຽນໃຫ້ເຂົາເຈົ້າຫຼືບໍ່. ຄວາມຍາວຂອງບັນຊີລາຍຊື່ = ປະມານຈໍານວນຫມູ່ເພື່ອນຂອງຜູ້ໃຊ້, ແລະສໍາລັບເຄິ່ງຫນຶ່ງຂອງຫມູ່ເພື່ອນທີ່ກວດເບິ່ງຄໍາຕອບຄວນຈະເປັນ "ແມ່ນ", ແລະອີກເຄິ່ງຫນຶ່ງ - "ບໍ່". ການກວດສອບແມ່ນປະຕິບັດໃນຄໍາສັ່ງທີ່ຄໍາຕອບ "ແມ່ນ" ແລະ "ບໍ່" ສະຫຼັບກັນ (ນັ້ນແມ່ນ, ໃນທຸກໆກໍລະນີທີ່ສອງພວກເຮົາຈະຕ້ອງຜ່ານຖັນທັງຫມົດຂອງແຖວສໍາລັບທາງເລືອກ 1 ແລະ 2). ເວລາກວດທັງໝົດແມ່ນແບ່ງດ້ວຍຈຳນວນໝູ່ທີ່ທົດສອບເພື່ອໃຫ້ໄດ້ເວລາກວດໂດຍສະເລ່ຍຕໍ່ວິຊາ.
• ກຳລັງລຶບຂໍ້ມູນ. ເອົາໝູ່ທັງໝົດອອກຈາກຜູ້ໃຊ້. ຍິ່ງໄປກວ່ານັ້ນ, ຄໍາສັ່ງລຶບແມ່ນແບບສຸ່ມ (ນັ້ນແມ່ນ, ພວກເຮົາ "shuffle" ບັນຊີລາຍຊື່ຕົ້ນສະບັບທີ່ໃຊ້ໃນການບັນທຶກຂໍ້ມູນ). ເວລາກວດທັງໝົດແມ່ນແບ່ງອອກດ້ວຍຈຳນວນໝູ່ທີ່ເອົາອອກເພື່ອໃຫ້ໄດ້ເວລາສະເລ່ຍຕໍ່ການກວດ.

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

• ອັນທໍາອິດແມ່ນສໍາລັບການແຊກ
• ອັນທີສອງແມ່ນສໍາລັບການກວດສອບ
• ທີສາມ - ສໍາລັບການລຶບ

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

ການທົດລອງໄດ້ດໍາເນີນຢູ່ໃນຄອມພິວເຕີໂນດບຸກທີ່ໃຊ້ Windows 10, ບ່ອນທີ່ HBase ແລ່ນຢູ່ໃນຖັງ Docker ຫນຶ່ງ, ແລະ Python ກັບ Jupyter Notebook ກໍາລັງແລ່ນຢູ່ໃນບ່ອນອື່ນ. Docker ໄດ້ຖືກຈັດສັນ 2 ແກນ CPU ແລະ 2 GB ຂອງ RAM. ເຫດຜົນທັງຫມົດ, ເຊັ່ນການຈໍາລອງຂອງ "ຄໍາຮ້ອງສະຫມັກທີ່ມີເງື່ອນໄຂ" ແລະ "ທໍ່" ສໍາລັບການສ້າງຂໍ້ມູນການທົດສອບແລະເວລາການວັດແທກ, ໄດ້ຖືກຂຽນໄວ້ໃນ Python. ຫ້ອງສະຫມຸດໄດ້ຖືກນໍາໃຊ້ເພື່ອເຮັດວຽກກັບ HBase Happybase, ເພື່ອຄິດໄລ່ hashes (MD5) ສໍາລັບທາງເລືອກ 5 - hashlib

ໂດຍຄໍານຶງເຖິງພະລັງງານຄອມພິວເຕີຂອງຄອມພິວເຕີໂນດບຸກໂດຍສະເພາະ, ການເປີດຕົວສໍາລັບ n = 10, 30, … ໄດ້ຖືກເລືອກທົດລອງ. 170 – ເມື່ອເວລາປະຕິບັດການທັງໝົດຂອງຮອບທົດສອບເຕັມຮູບແບບ (ທຸກສະຖານະການສຳລັບທຸກທາງເລືອກສຳລັບ n) ແມ່ນສົມເຫດສົມຜົນຫຼາຍ ຫຼືໜ້ອຍກວ່າ ແລະພໍດີໃນລະຫວ່າງງານລ້ຽງຊາ (ໂດຍສະເລ່ຍ 15 ນາທີ).

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

ຜົນການທົດລອງ

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

ທາງເລືອກ 3-5, ຕາມທີ່ຄາດໄວ້, ສະແດງໃຫ້ເຫັນເວລາ "ການເຮັດທຸລະກໍາ" ເກືອບຄົງທີ່, ເຊິ່ງບໍ່ຂຶ້ນກັບການຂະຫຍາຍຕົວຂອງຂະຫນາດເຄືອຂ່າຍແລະຄວາມແຕກຕ່າງທີ່ບໍ່ສາມາດແຍກໄດ້ໃນການປະຕິບັດ.
ທາງ​ເລືອກ 2 ຍັງ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ການ​ຄົງ​ທີ່​, ແຕ່​ວ່າ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ຮ້າຍ​ແຮງ​ກວ່າ​ເລັກ​ນ້ອຍ​, ເກືອບ 2 ເທົ່າ​ກັບ​ທາງ​ເລືອກ 3-5​. ແລະນີ້ບໍ່ສາມາດແຕ່ປິຕິຍິນດີ, ເພາະວ່າມັນກ່ຽວຂ້ອງກັບທິດສະດີ - ໃນສະບັບນີ້ຈໍານວນຂອງການດໍາເນີນງານ I / O ກັບ / ຈາກ HBase ແມ່ນຫຼາຍກວ່າ 2 ເທົ່າ. ນີ້ສາມາດເປັນຫຼັກຖານທາງອ້ອມວ່າ bench ການທົດສອບຂອງພວກເຮົາ, ໃນຫຼັກການ, ສະຫນອງຄວາມຖືກຕ້ອງທີ່ດີ.
ທາງເລືອກ 1 ຍັງ, ຕາມທີ່ຄາດໄວ້, ກາຍເປັນຊ້າທີ່ສຸດແລະສະແດງໃຫ້ເຫັນເຖິງການເພີ່ມຂຶ້ນເສັ້ນໃນເວລາທີ່ໃຊ້ເວລາໃນການເພີ່ມເຊິ່ງກັນແລະກັນກັບຂະຫນາດຂອງເຄືອຂ່າຍ.
ຕອນນີ້ໃຫ້ເບິ່ງຜົນຂອງການທົດສອບຄັ້ງທີສອງ.

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

ດີ, ເສັ້ນສະແດງສຸດທ້າຍແມ່ນຜົນຂອງການທົດສອບການໂຍກຍ້າຍ.

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

ທາງເລືອກ 1 ແລະ 2, ຕາມທີ່ຄາດໄວ້, ສະແດງໃຫ້ເຫັນເຖິງການເພີ່ມຂຶ້ນຕາມເສັ້ນກົງຕາມເວລາ. ໃນຂະນະດຽວກັນ, ທາງເລືອກ 2 ແມ່ນຄົງທີ່ຊ້າກວ່າທາງເລືອກ 1 - ເນື່ອງຈາກການປະຕິບັດ I/O ເພີ່ມເຕີມເພື່ອ "ຮັກສາ" ຖັນນັບ.

ບົດສະຫຼຸບທົ່ວໄປຂອງການທົດລອງ:

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

Epilogue

ການທົດລອງທີ່ຫຍາບຄາຍທີ່ດໍາເນີນໄປນັ້ນບໍ່ຄວນຖືເປັນຄວາມຈິງຢ່າງແທ້ຈິງ. ມີຫຼາຍປັດໃຈທີ່ບໍ່ໄດ້ພິຈາລະນາແລະບິດເບືອນຜົນໄດ້ຮັບ (ການເຫນັງຕີງເຫຼົ່ານີ້ແມ່ນເຫັນໄດ້ຊັດເຈນໃນກາຟທີ່ມີຂະຫນາດເຄືອຂ່າຍຂະຫນາດນ້ອຍ). ສໍາລັບຕົວຢ່າງ, ຄວາມໄວຂອງ thrift, ເຊິ່ງຖືກນໍາໃຊ້ໂດຍ happybase, ປະລິມານແລະວິທີການປະຕິບັດເຫດຜົນທີ່ຂ້ອຍຂຽນໃນ Python (ຂ້ອຍບໍ່ສາມາດອ້າງວ່າລະຫັດຖືກຂຽນຢ່າງຖືກຕ້ອງແລະມີປະສິດທິພາບນໍາໃຊ້ຄວາມສາມາດຂອງອົງປະກອບທັງຫມົດ), ບາງທີ. ຄຸນ​ນະ​ສົມ​ບັດ​ຂອງ HBase caching​, ກິດ​ຈະ​ກໍາ​ພື້ນ​ຖານ​ຂອງ Windows 10 ໃນ​ຄອມ​ພິວ​ເຕີ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​, ແລະ​ອື່ນໆ​. ໂດຍທົ່ວໄປ, ພວກເຮົາສາມາດສົມມຸດວ່າການຄິດໄລ່ທາງທິດສະດີທັງຫມົດໄດ້ທົດລອງສະແດງໃຫ້ເຫັນຄວາມຖືກຕ້ອງຂອງພວກເຂົາ. ດີ, ຫຼືຢ່າງຫນ້ອຍມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະປະຕິເສດພວກເຂົາດ້ວຍ "ການໂຈມຕີຫົວ".

ສະຫຼຸບແລ້ວ, ຄຳແນະນຳສຳລັບທຸກຄົນທີ່ຫາກໍ່ເລີ່ມອອກແບບຕົວແບບຂໍ້ມູນໃນ HBase: abstract ຈາກປະສົບການທີ່ຜ່ານມາທີ່ເຮັດວຽກກັບຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ ແລະຈື່ “ຄຳສັ່ງ”:

• ໃນເວລາທີ່ການອອກແບບ, ພວກເຮົາດໍາເນີນການຈາກຫນ້າວຽກແລະຮູບແບບຂອງການຫມູນໃຊ້ຂໍ້ມູນ, ແລະບໍ່ແມ່ນມາຈາກຮູບແບບໂດເມນ
• ການ​ເຂົ້າ​ເຖິງ​ປະ​ສິດ​ທິ​ພາບ (ໂດຍ​ບໍ່​ມີ​ການ​ສະ​ແກນ​ຕາ​ຕະ​ລາງ​ເຕັມ​) – ພຽງ​ແຕ່​ໂດຍ​ການ​ກະ​ແຈ​
• ການປັບຕົວຜິດປົກກະຕິ
• ແຖວຕ່າງໆສາມາດບັນຈຸຖັນທີ່ແຕກຕ່າງກັນ
• ອົງປະກອບແບບໄດນາມິກຂອງລໍາໂພງ

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