ອັນໃດດີກວ່າ – Oracle ຫຼື Redis ຫຼືວິທີການປັບຕົວທາງເລືອກຂອງເວທີ

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

Yuliy Dubov, "ຄວາມຊົ່ວຮ້າຍຫນ້ອຍ"

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

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

ແຮງກະຕຸ້ນ

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

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

ໃນບໍລິສັດຂະຫນາດໃຫຍ່, ກົງກັນຂ້າມມັກຈະເປັນຄວາມຈິງ - ນ້ໍາຫນັກຄ່າໃຊ້ຈ່າຍບໍ່ຕໍ່າກວ່າ 50%, ແລະອາດຈະຫຼາຍກວ່າ 60%. ໃນຕົວຢ່າງຂອງຕົວແບບ, ທັງຫມົດທີ່ສໍາຄັນແມ່ນວ່ານ້ໍາຫນັກລວມຂອງ nodes ຂອງເດັກນ້ອຍຂອງ node ພໍ່ແມ່ຕ້ອງເປັນ 100%.

ເງື່ອນໄຂການຕັດ

ເວັບໄຊທ໌ db-engines.com ມີປະມານ 500 ລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນທີ່ຮູ້ຈັກ. ຕາມທໍາມະຊາດ, ຖ້າທ່ານເລືອກເວທີເປົ້າຫມາຍຈາກຫຼາຍທາງເລືອກ, ທ່ານອາດຈະສິ້ນສຸດດ້ວຍບົດຄວາມທົບທວນ, ແຕ່ບໍ່ແມ່ນໂຄງການການຄ້າ. ເພື່ອຫຼຸດຜ່ອນພື້ນທີ່ທາງເລືອກ, ເງື່ອນໄຂການຕັດແມ່ນໄດ້ຖືກສ້າງຂື້ນ, ແລະຖ້າເວທີບໍ່ຕອບສະຫນອງເງື່ອນໄຂເຫຼົ່ານີ້, ມັນບໍ່ໄດ້ຖືກພິຈາລະນາ.

ເງື່ອນໄຂການຕັດອອກອາດຈະກ່ຽວຂ້ອງກັບລັກສະນະເຕັກໂນໂລຢີ, ຕົວຢ່າງ:

• ການຄໍ້າປະກັນ ACID;
• ຮູບແບບຂໍ້ມູນຄວາມສໍາພັນ;
• ສະຫນັບສະຫນູນພາສາ SQL (ຫມາຍເຫດ, ນີ້ບໍ່ແມ່ນຄືກັນກັບ "ຕົວແບບທີ່ກ່ຽວຂ້ອງ");
• ຄວາມເປັນໄປໄດ້ຂອງການປັບຂະຫນາດຕາມແນວນອນ.

ອາດ​ຈະ​ມີ​ມາດ​ຕະ​ຖານ​ທົ່ວ​ໄປ​:

• ມີການສະຫນັບສະຫນູນດ້ານການຄ້າໃນລັດເຊຍ;
• ແຫຼ່ງເປີດ;
• ຄວາມພ້ອມຂອງເວທີການຈົດທະບຽນຂອງກະຊວງໂທລະຄົມແລະການສື່ສານມະຫາຊົນ;
• ການປະກົດຕົວຂອງເວທີໃນບາງການຈັດອັນດັບ (ຕົວຢ່າງ, ໃນຮ້ອຍທໍາອິດຂອງການຈັດອັນດັບ db-engines.com);
• ການປະກົດຕົວຂອງຜູ້ຊ່ຽວຊານໃນຕະຫຼາດ (ຕົວຢ່າງ, ອີງໃສ່ຜົນໄດ້ຮັບຂອງການຄົ້ນຫາຊື່ຂອງເວທີໃນຊີວະປະຫວັດຫຍໍ້ຢູ່ໃນເວັບໄຊທ໌ hh.ru).

ຫຼັງຈາກທີ່ທັງຫມົດ, ອາດຈະມີເງື່ອນໄຂສະເພາະວິສາຫະກິດ:

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

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

ການ​ຄາດ​ຄະ​ເນ​ຄ່າ​ໃຊ້​ຈ່າຍ​

ຄ່າໃຊ້ຈ່າຍຂອງການແກ້ໄຂແນ່ນອນປະກອບດ້ວຍຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດ, ຄ່າໃຊ້ຈ່າຍໃນການສະຫນັບສະຫນູນແລະຄ່າໃຊ້ຈ່າຍຂອງອຸປະກອນ.

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

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

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

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

ທ່ານ​ສາ​ມາດ​ສະ​ເຫມີ​ພາບ​ເງື່ອນ​ໄຂ​ການ​ຄິດ​ໄລ່​ໃນ​ສາມ​ວິ​ທີ​:

1. ໃຊ້ Oracle ໂດຍບໍ່ມີການສະຫນັບສະຫນູນ (ໃນຄວາມເປັນຈິງນີ້ບໍ່ໄດ້ເກີດຂຶ້ນ).
2. ຊື້ການສະຫນັບສະຫນູນສໍາລັບ PostgreSQL - ຕົວຢ່າງ, ຈາກ Postgres Professional.
3. ຄໍານຶງເຖິງຄວາມສ່ຽງທີ່ກ່ຽວຂ້ອງກັບການຂາດການສະຫນັບສະຫນູນ.

ຕົວຢ່າງ, ການຄິດໄລ່ຄວາມສ່ຽງອາດຈະມີລັກສະນະນີ້: ໃນກໍລະນີທີ່ຖານຂໍ້ມູນລົ້ມເຫລວ, ການຢຸດລະບົບຈະເປັນ 1 ມື້ເຮັດວຽກ. ຄາດ​ຄະ​ເນ​ຜົນ​ກຳ​ໄລ​ຈາກ​ການ​ນຳ​ໃຊ້​ລະ​ບົບ​ແມ່ນ 40 ຕື້ MNT ຕໍ່​ປີ, ອັດ​ຕາ​ການ​ເກີດ​ອຸ​ບັດ​ຕິ​ເຫດ​ຄາດ​ຄະ​ເນ​ວ່າ​ແມ່ນ 1/400, ດັ່ງ​ນັ້ນ​ຄວາມ​ສ່ຽງ​ຂອງ​ການ​ຂາດ​ສະ​ຫນັບ​ສະ​ຫນູນ​ແມ່ນ​ປະ​ມານ 100 ລ້ານ MNT ຕໍ່​ປີ. ແນ່ນອນ, "ກໍາໄລທີ່ວາງແຜນ" ແລະ "ຄວາມຖີ່ຂອງອຸປະຕິເຫດທີ່ຄາດຄະເນ" ແມ່ນມູນຄ່າ virtual, ແຕ່ມັນກໍ່ດີກວ່າທີ່ຈະມີຮູບແບບດັ່ງກ່າວຫຼາຍກ່ວາບໍ່ມີ.

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

ໃຫ້ພວກເຮົາສົມມຸດວ່າຫຼັງຈາກການຄິດໄລ່ທັງຫມົດ, ຄ່າໃຊ້ຈ່າຍຂອງແພລະຕະຟອມປະຕິບັດງານ A ສໍາລັບ 5 ປີກາຍເປັນ 800 ລ້ານ MNT, ຄ່າໃຊ້ຈ່າຍຂອງເວທີການປະຕິບັດການ B ແມ່ນ 650 ລ້ານ MNT, ແລະຄ່າໃຊ້ຈ່າຍຂອງແພລະຕະຟອມປະຕິບັດການ C ແມ່ນ 600 ລ້ານ MNT. Platform C, ເປັນຜູ້ຊະນະ, ໄດ້ຮັບຈຸດເຕັມສໍາລັບລາຄາ, ໃນຂະນະທີ່ເວທີ A ແລະ B ໄດ້ຮັບຫນ້ອຍລົງ, ໃນອັດຕາສ່ວນກັບຈໍານວນຄັ້ງທີ່ພວກເຂົາມີລາຄາແພງກວ່າ. ໃນກໍລະນີນີ້ - 0.75 ແລະ 0.92 ຈຸດ, ຕາມລໍາດັບ.

ການປະເມີນໂອກາດ

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

ຫນ້າ​ທີ່​ການ​ພັດ​ທະ​ນາ​ປະ​ກອບ​ມີ​:

• ຄວາມງ່າຍຂອງການຫມູນໃຊ້ຂໍ້ມູນ;
• ການປັບຂະຫນາດ;
• ການປະກົດຕົວຂອງດັດຊະນີຂັ້ນສອງ.

ບັນຊີລາຍຊື່ຂອງເງື່ອນໄຂ, ເຊັ່ນດຽວກັນກັບນ້ໍາຫນັກຂອງພວກເຂົາ, ແມ່ນຫົວຂໍ້ຫຼາຍ. ເຖິງແມ່ນວ່າໃນເວລາທີ່ແກ້ໄຂບັນຫາດຽວກັນ, ບັນຊີລາຍຊື່ເຫຼົ່ານີ້, ນ້ໍາຫນັກລາຍການ, ແລະຄໍາຕອບຈະແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຂຶ້ນຢູ່ກັບອົງປະກອບຂອງທີມງານຂອງທ່ານ. ຕົວຢ່າງ, Facebook ໃຊ້ MySQL ເພື່ອເກັບຂໍ້ມູນ, ແລະ Instagram ຖືກສ້າງຂຶ້ນໃນ Cassandra. ມັນຄົງຈະບໍ່ເປັນທີ່ນັກພັດທະນາຂອງຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ໄດ້ຕື່ມຂໍ້ມູນໃສ່ຕາຕະລາງດັ່ງກ່າວ. ຄົນເຮົາພຽງແຕ່ສາມາດຄາດເດົາໄດ້ວ່າ Mark Zuckerberg ເລືອກຮູບແບບຄວາມສໍາພັນທີ່ສົມບູນ, ຈ່າຍຄ່າມັນກັບຄວາມຕ້ອງການສໍາລັບການນໍາໃຊ້ sharding, ໃນຂະນະທີ່ Kevin Systrom ກໍ່ສ້າງຂະຫນາດໂດຍໃຊ້ເວທີ, ການເສຍສະລະຄວາມສະດວກໃນການເຂົ້າເຖິງຂໍ້ມູນ.

ຫນ້າທີ່ບໍລິຫານປະກອບມີ:

• ຄວາມສາມາດຂອງລະບົບສໍາຮອງ;
• ຄວາມງ່າຍຂອງການຕິດຕາມ;
• ຄວາມ​ງ່າຍ​ຂອງ​ການ​ຄຸ້ມ​ຄອງ​ຄວາມ​ສາ​ມາດ – ແຜ່ນ​ແລະ​ຂໍ້​;
• ຄວາມສາມາດໃນການຈໍາລອງຂໍ້ມູນ.

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ຄໍາ​ຖາມ​ຈະ​ຕ້ອງ​ໄດ້​ຮັບ​ຄໍາ​ສັບ​ຕ່າງໆ​ໃນ​ລັກ​ສະ​ນະ​ປະ​ລິ​ມານ​. ທ່ານສາມາດຕົກລົງເຫັນດີກ່ຽວກັບວິທີການປະເມີນຫນ້າທີ່ສະເພາະໃດຫນຶ່ງ. ຕົວຢ່າງ, ໃຫ້ລອງປະເມີນເຄື່ອງມືສຳຮອງໂດຍໃຊ້ຕົວຢ່າງຂອງເຄື່ອງມືທີ່ສະໜອງໃຫ້ Oracle DBMS:

ເຄື່ອງມື
ຄວາມຄິດເຫັນ
ການປະເມີນຜົນ

imp/exp
ກຳລັງອັບໂຫລດ ແລະໂຫຼດຂໍ້ມູນ
0.1

ເລີ່ມ/ສິ້ນສຸດການສຳຮອງຂໍ້ມູນ
ສຳເນົາໄຟລ໌
0.3

RMAN
ຄວາມ​ສາ​ມາດ​ສໍາ​ເນົາ​ເພີ່ມ​ຂຶ້ນ​
0.7

ZDLRA
ພຽງ​ແຕ່​ເພີ່ມ​ການ​ສໍາ​ເນົາ​, ການ​ຟື້ນ​ຕົວ​ໄວ​ທີ່​ສຸດ​ເພື່ອ​ຈຸດ​
1.0

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

ສຸດທ້າຍ, ພວກເຮົາພຽງແຕ່ບອກຫນ້າທີ່ຄວາມປອດໄພຂອງຂໍ້ມູນ:

• ຄວາມພ້ອມຂອງນະໂຍບາຍການຄຸ້ມຄອງລະຫັດຜ່ານ;
• ຄວາມສາມາດໃນການເຊື່ອມຕໍ່ເຄື່ອງມືການກວດສອບພາຍນອກ (LDAP, Kerberos);
• ຕົວແບບຂອງການເຂົ້າເຖິງ;
• ຄວາມສາມາດໃນການກວດສອບ;
• ການເຂົ້າລະຫັດຂໍ້ມູນໃນແຜ່ນ;
• ການເຂົ້າລະຫັດໃນລະຫວ່າງການສົ່ງຜ່ານເຄືອຂ່າຍ (TLS);
• ການປົກປ້ອງຂໍ້ມູນຈາກຜູ້ບໍລິຫານ.

ການທົດສອບປະສິດທິພາບ

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

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

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

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

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

ຜົນ

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

ດັ່ງທີ່ເຈົ້າເຂົ້າໃຈ, ໂດຍການປ່ຽນແປງການວັດແທກແລະການປັບການຈັດອັນດັບທີ່ເຈົ້າສາມາດບັນລຸຜົນທີ່ຕ້ອງການ, ແຕ່ນັ້ນແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນຫມົດ ...

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