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

ບົດ​ຄວາມ​ທີ່​ໄດ້​ຮັບ​ການ​ກະ​ກຽມ​ໂດຍ​ອີງ​ໃສ່​ຄໍາ​ປາ​ໄສ​ທີ່ @DatabasesMeetup, ຈັດຕັ້ງ Mail.ru Cloud Solutions. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ຕ້ອງ​ການ​ອ່ານ​, ທ່ານ​ສາ​ມາດ​ເບິ່ງ​:

ບົດ​ຄວາມ​ຈະ​ມີ​ສາມ​ພາກ​ສ່ວນ​:

• ວິທີການຮັບປະກັນການເຊື່ອມຕໍ່.
• ການກວດສອບການປະຕິບັດແລະວິທີການບັນທຶກສິ່ງທີ່ເກີດຂື້ນໃນດ້ານຖານຂໍ້ມູນແລະການເຊື່ອມຕໍ່ກັບມັນ.
• ວິທີການປົກປ້ອງຂໍ້ມູນໃນຖານຂໍ້ມູນຂອງມັນເອງແລະເຕັກໂນໂລຢີໃດທີ່ມີຢູ່ສໍາລັບການນີ້.

ສາມອົງປະກອບຂອງຄວາມປອດໄພ DBMS: ການປົກປ້ອງການເຊື່ອມຕໍ່, ການກວດສອບກິດຈະກໍາແລະການປົກປ້ອງຂໍ້ມູນ

ຮັບປະກັນການເຊື່ອມຕໍ່ຂອງທ່ານ

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

ກ່ອນທີ່ຈະເວົ້າກ່ຽວກັບການປົກປ້ອງການເຊື່ອມຕໍ່, ທ່ານຈໍາເປັນຕ້ອງຕອບຄໍາຖາມທີ່ສໍາຄັນທີ່ກໍານົດວ່າມາດຕະການຄວາມປອດໄພຈະມີໂຄງສ້າງແນວໃດ:

• ຜູ້ໃຊ້ທຸລະກິດຫນຶ່ງແມ່ນທຽບເທົ່າກັບຜູ້ໃຊ້ DBMS ຫນຶ່ງບໍ?
• ການເຂົ້າເຖິງຂໍ້ມູນ DBMS ແມ່ນໃຫ້ຜ່ານ API ທີ່ທ່ານຄວບຄຸມເທົ່ານັ້ນ, ຫຼືວ່າຕາຕະລາງຖືກເຂົ້າເຖິງໂດຍກົງ;
• DBMS ໄດ້ຖືກຈັດສັນໃຫ້ພາກສ່ວນປ້ອງກັນແຍກຕ່າງຫາກ, ໃຜພົວພັນກັບມັນແລະວິທີການ;
• ບໍ່ວ່າຈະເປັນ pooling/proxy ແລະ intermediate layers ຖືກນໍາໃຊ້, ເຊິ່ງສາມາດປ່ຽນແປງຂໍ້ມູນກ່ຽວກັບການເຊື່ອມຕໍ່ທີ່ຖືກສ້າງຂຶ້ນແລະຜູ້ທີ່ກໍາລັງໃຊ້ຖານຂໍ້ມູນ.

ຕອນນີ້ເຮົາມາເບິ່ງວ່າມີເຄື່ອງມືໃດແດ່ທີ່ສາມາດໃຊ້ເພື່ອຮັບປະກັນການເຊື່ອມຕໍ່ໄດ້:

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

   ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບຫນ້າທີ່ການຈັດອັນດັບຜູ້ໃຊ້ ທີ່ນີ້, ທ່ານຍັງສາມາດຊອກຫາກ່ຽວກັບ MS SQL Vulnerability Assessmen ທີ່ນີ້. 

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

ນີ້ຈະມີຜົນກະທົບແນວໃດຕໍ່ການປະຕິບັດຂອງ DBMS?

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

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

ທົດສອບ 1 ໂດຍບໍ່ມີ SSL ແລະໃຊ້ SSL - ການ​ເຊື່ອມ​ຕໍ່​ແມ່ນ​ໄດ້​ຮັບ​ການ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ສໍາ​ລັບ​ແຕ່​ລະ​ທຸ​ລະ​ກໍາ​:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

ທົດສອບ 2 ໂດຍບໍ່ມີ SSL ແລະໃຊ້ SSL - ທຸລະກໍາທັງຫມົດແມ່ນດໍາເນີນຢູ່ໃນການເຊື່ອມຕໍ່ດຽວ:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

ການຕັ້ງຄ່າອື່ນໆ:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

ຜົນການທົດສອບ:

 
ບໍ່ມີ SSL
SSL

ການເຊື່ອມຕໍ່ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນສໍາລັບທຸກໆທຸລະກໍາ

latency ສະເລ່ຍ
ms 171.915
ms 187.695

tps ລວມທັງການເຊື່ອມຕໍ່ການສ້າງຕັ້ງ
58.168112
53.278062

tps ບໍ່ລວມການເຊື່ອມຕໍ່ການສ້າງຕັ້ງ
64.084546
58.725846

CPU
24%
28%

ທຸລະກໍາທັງຫມົດແມ່ນດໍາເນີນຢູ່ໃນການເຊື່ອມຕໍ່ດຽວ

latency ສະເລ່ຍ
ms 6.722
ms 6.342

tps ລວມທັງການເຊື່ອມຕໍ່ການສ້າງຕັ້ງ
1587.657278
1576.792883

tps ບໍ່ລວມການເຊື່ອມຕໍ່ການສ້າງຕັ້ງ
1588.380574
1577.694766

CPU
17%
21%

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

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

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

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

ການກວດສອບການປະຕິບັດ

ການກວດສອບສາມາດບໍ່ພຽງແຕ່ DBMS ເທົ່ານັ້ນ. ການກວດສອບແມ່ນກ່ຽວກັບການໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນໃນພາກສ່ວນຕ່າງໆ. ນີ້ສາມາດເປັນຖານຂໍ້ມູນ firewall ຫຼືລະບົບປະຕິບັດການທີ່ DBMS ຖືກສ້າງຂຶ້ນ.

ໃນລະດັບວິສາຫະກິດການຄ້າ DBMSs ທຸກສິ່ງທຸກຢ່າງແມ່ນດີກັບການກວດສອບ, ແຕ່ໃນແຫຼ່ງເປີດ - ບໍ່ສະເຫມີໄປ. ນີ້ແມ່ນສິ່ງທີ່ PostgreSQL ມີ:

• default log - ການບັນທຶກໃນຕົວ;
• extensions: pgaudit - ຖ້າການບັນທຶກເລີ່ມຕົ້ນບໍ່ພຽງພໍສໍາລັບທ່ານ, ທ່ານສາມາດນໍາໃຊ້ການຕັ້ງຄ່າແຍກຕ່າງຫາກທີ່ແກ້ໄຂບັນຫາບາງຢ່າງ.

ເພີ່ມເຕີມຕໍ່ກັບບົດລາຍງານໃນວິດີໂອ:

"ການບັນທຶກການຖະແຫຼງການພື້ນຖານສາມາດສະຫນອງໃຫ້ໂດຍສະຖານທີ່ບັນທຶກມາດຕະຖານທີ່ມີ log_statement = ທັງຫມົດ.

ນີ້ແມ່ນຍອມຮັບໄດ້ສໍາລັບການຕິດຕາມກວດກາແລະການນໍາໃຊ້ອື່ນໆ, ແຕ່ບໍ່ໄດ້ສະຫນອງລະດັບຂອງລາຍລະອຽດປົກກະຕິທີ່ຕ້ອງການສໍາລັບການກວດສອບ.

ມັນບໍ່ພຽງພໍທີ່ຈະມີບັນຊີລາຍຊື່ຂອງການດໍາເນີນງານທັງຫມົດທີ່ດໍາເນີນຢູ່ໃນຖານຂໍ້ມູນ.

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

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

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

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

DO$$
ເລີ່ມຕົ້ນ
ດໍາເນີນການ 'ສ້າງການນໍາເຂົ້າຕາຕະລາງ' || 'ant_table(id int)';
END$$;

ການບັນທຶກມາດຕະຖານຈະໃຫ້ທ່ານນີ້:

LOG: ຖະແຫຼງການ: ເຮັດ $$
ເລີ່ມຕົ້ນ
ດໍາເນີນການ 'ສ້າງການນໍາເຂົ້າຕາຕະລາງ' || 'ant_table(id int)';
END$$;

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

ນີ້ບໍ່ແມ່ນຄວາມເຫມາະສົມ, ຍ້ອນວ່າມັນຈະມັກພຽງແຕ່ຄົ້ນຫາໂດຍຊື່ຕາຕະລາງ.

ນີ້ແມ່ນບ່ອນທີ່ pgAudit ມີປະໂຫຍດ.

ສໍາລັບການປ້ອນຂໍ້ມູນດຽວກັນ, ມັນຈະຜະລິດຜົນຜະລິດນີ້ຢູ່ໃນບັນທຶກ:

ການກວດສອບ: Session,33,1,FUNCTION,DO,,,"DO $$
ເລີ່ມຕົ້ນ
ດໍາເນີນການ 'ສ້າງການນໍາເຂົ້າຕາຕະລາງ' || 'ant_table(id int)';
END$$;"
ການກວດສອບ: SESSION,33,2,DDL,CREATE Table,Table,public.important_table,CREATE TABLE important_table (id INT)

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

ເມື່ອບັນທຶກຂໍ້ຄວາມ SELECT ແລະ DML, pgAudit ສາມາດຖືກຕັ້ງຄ່າເພື່ອບັນທຶກລາຍການແຍກຕ່າງຫາກສໍາລັບແຕ່ລະຄວາມສໍາພັນທີ່ອ້າງອີງໃນຄໍາຖະແຫຼງການ.

ບໍ່ຈໍາເປັນຕ້ອງມີການແຍກວິເຄາະເພື່ອຊອກຫາຄໍາຖະແຫຼງທັງຫມົດທີ່ແຕະຕາຕາລາງໃດນຶ່ງ(*) ».

ນີ້ຈະມີຜົນກະທົບແນວໃດຕໍ່ການປະຕິບັດຂອງ DBMS?

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

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

postgresql.conf

log_destination = 'stderr'
logging_collector = ເປີດ
log_truncate_on_rotation = ເປີດ
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = ເປີດ
debug_print_rewritten = ເປີດ
debug_print_plan = ເປີດ
debug_pretty_print = ເປີດ
log_checkpoints = ສຸດ
log_connections = ເປີດ
log_disconnections = ເປີດ
log_duration = ສຸດ
log_hostname = on
log_lock_waits = ເປີດ
log_replication_commands = on
log_temp_files = 0
log_timezone = 'ເອີຣົບ/ມອດໂກ'

ໃນ PostgreSQL DBMS ທີ່ມີພາລາມິເຕີຂອງ 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, ພວກເຮົາດໍາເນີນການສາມການທົດສອບການໂຫຼດໂດຍໃຊ້ຄໍາສັ່ງ:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

ຜົນການທົດສອບ:

ບໍ່ມີການບັນທຶກ
ດ້ວຍການລົງທືນ

ເວລາຕື່ມຂໍ້ມູນຖານຂໍ້ມູນທັງໝົດ
43,74 sec
53,23 sec

RAM
24%
40%

CPU
72%
91%

ການທົດສອບ 1 (50 ການເຊື່ອມຕໍ່)

ຈໍານວນການເຮັດທຸລະກໍາໃນ 10 ນາທີ
74169
32445

ທຸລະກຳ/ວິນາທີ
123
54

Latency ສະເລ່ຍ
405 ms
925 ms

ການທົດສອບ 2 (150 ການເຊື່ອມຕໍ່ກັບ 100 ທີ່ເປັນໄປໄດ້)

ຈໍານວນການເຮັດທຸລະກໍາໃນ 10 ນາທີ
81727
31429

ທຸລະກຳ/ວິນາທີ
136
52

Latency ສະເລ່ຍ
550 ms
1432 ms

ກ່ຽວກັບຂະຫນາດ

ຂະໜາດ DB
2251 MB
2262 MB

ຂະໜາດບັນທຶກຖານຂໍ້ມູນ
0 MB
4587 MB

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

ໃຫ້ເບິ່ງຕົວກໍານົດການອື່ນໆ:

• ຄວາມໄວບໍ່ປ່ຽນແປງຫຼາຍ: ໂດຍບໍ່ມີການບັນທຶກ - 43,74 ວິນາທີ, ດ້ວຍບັນທຶກ - 53,23 ວິນາທີ.
• ການເຮັດວຽກຂອງ RAM ແລະ CPU ຈະທົນທຸກ, ດັ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງສ້າງໄຟລ໌ການກວດສອບ. ນີ້ຍັງສັງເກດເຫັນໃນການຜະລິດ.

ເມື່ອຈໍານວນຂອງການເຊື່ອມຕໍ່ເພີ່ມຂຶ້ນ, ຕາມທໍາມະຊາດ, ການປະຕິບັດຈະຫຼຸດລົງເລັກນ້ອຍ.

ໃນບໍລິສັດທີ່ມີການກວດສອບແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ:

• ມີຂໍ້ມູນຫຼາຍ;
• ການກວດສອບແມ່ນຈໍາເປັນບໍ່ພຽງແຕ່ຜ່ານ syslog ໃນ SIEM, ແຕ່ຍັງຢູ່ໃນໄຟລ໌: ຖ້າບາງສິ່ງບາງຢ່າງເກີດຂື້ນກັບ syslog, ຕ້ອງມີໄຟລ໌ທີ່ຢູ່ໃກ້ກັບຖານຂໍ້ມູນທີ່ຂໍ້ມູນຖືກບັນທຶກໄວ້;
• shelf ແຍກຕ່າງຫາກແມ່ນຈໍາເປັນສໍາລັບການກວດສອບເພື່ອບໍ່ໃຫ້ເສຍ I/O ແຜ່ນ, ເນື່ອງຈາກວ່າມັນໃຊ້ເວລາເຖິງຫຼາຍພື້ນທີ່;
• ມັນເກີດຂື້ນວ່າພະນັກງານຄວາມປອດໄພຂໍ້ມູນຕ້ອງການມາດຕະຖານ GOST ຢູ່ທົ່ວທຸກແຫ່ງ, ພວກເຂົາຕ້ອງການການກໍານົດຂອງລັດ.

ຈໍາກັດການເຂົ້າເຖິງຂໍ້ມູນ

ຂໍໃຫ້ເບິ່ງເຕັກໂນໂລຢີທີ່ຖືກນໍາໃຊ້ເພື່ອປົກປ້ອງຂໍ້ມູນແລະເຂົ້າເຖິງມັນໃນ DBMSs ການຄ້າແລະແຫຼ່ງເປີດ.

ສິ່ງ​ທີ່​ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ໂດຍ​ທົ່ວ​ໄປ​:

1. ການເຂົ້າລະຫັດແລະການຂັດຂວາງຂັ້ນຕອນແລະຫນ້າທີ່ (Wrapping) - ນັ້ນແມ່ນ, ເຄື່ອງມືແຍກຕ່າງຫາກແລະຜົນປະໂຫຍດທີ່ເຮັດໃຫ້ລະຫັດທີ່ບໍ່ສາມາດອ່ານໄດ້. ແທ້ຈິງແລ້ວ, ມັນບໍ່ສາມາດປ່ຽນແປງຫຼື refactored ກັບຄືນ. ວິທີການນີ້ແມ່ນບາງຄັ້ງຕ້ອງການຢ່າງຫນ້ອຍໃນດ້ານ DBMS - ເຫດຜົນຂອງການຈໍາກັດໃບອະນຸຍາດຫຼືເຫດຜົນການອະນຸຍາດແມ່ນຖືກເຂົ້າລະຫັດຢ່າງແນ່ນອນໃນລະດັບຂັ້ນຕອນແລະຫນ້າທີ່.
2. ການຈໍາກັດການເບິ່ງເຫັນຂໍ້ມູນໂດຍແຖວ (RLS) ແມ່ນເວລາທີ່ຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນເຫັນຕາຕະລາງຫນຶ່ງ, ແຕ່ອົງປະກອບທີ່ແຕກຕ່າງກັນຂອງແຖວຢູ່ໃນນັ້ນ, ນັ້ນແມ່ນ, ບາງສິ່ງບາງຢ່າງບໍ່ສາມາດສະແດງໃຫ້ຜູ້ໃດຜູ້ຫນຶ່ງຢູ່ໃນລະດັບແຖວ.
3. ການແກ້ໄຂຂໍ້ມູນທີ່ສະແດງ (Masking) ແມ່ນເວລາທີ່ຜູ້ໃຊ້ຢູ່ໃນຖັນຫນຶ່ງຂອງຕາຕະລາງເບິ່ງຂໍ້ມູນຫຼືພຽງແຕ່ດາວ, ນັ້ນແມ່ນ, ສໍາລັບຜູ້ໃຊ້ບາງຄົນຂໍ້ມູນຈະຖືກປິດ. ເທກໂນໂລຍີກໍານົດວ່າຜູ້ໃຊ້ໃດຖືກສະແດງສິ່ງທີ່ອີງໃສ່ລະດັບການເຂົ້າເຖິງຂອງພວກເຂົາ.
4. ຄວາມປອດໄພຂອງ DBA / Application DBA / DBA ການຄວບຄຸມການເຂົ້າເຖິງແມ່ນ, ແທນທີ່ຈະ, ກ່ຽວກັບການຈໍາກັດການເຂົ້າເຖິງ DBMS ຕົວຂອງມັນເອງ, ນັ້ນແມ່ນ, ພະນັກງານຄວາມປອດໄພຂໍ້ມູນສາມາດແຍກອອກຈາກຜູ້ບໍລິຫານຖານຂໍ້ມູນແລະຜູ້ບໍລິຫານແອັບພລິເຄຊັນ. ມີເທກໂນໂລຍີດັ່ງກ່າວບໍ່ຫຼາຍປານໃດໃນແຫຼ່ງເປີດ, ແຕ່ມີຈໍານວນຫລາຍໃນ DBMSs ການຄ້າ. ພວກເຂົາຕ້ອງການໃນເວລາທີ່ມີຜູ້ໃຊ້ຫຼາຍຄົນທີ່ມີການເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍຂອງຕົນເອງ.
5. ການຈໍາກັດການເຂົ້າເຖິງໄຟລ໌ໃນລະດັບລະບົບໄຟລ໌. ທ່ານສາມາດໃຫ້ສິດແລະການເຂົ້າເຖິງສິດທິພິເສດກັບໄດເລກະທໍລີເພື່ອໃຫ້ຜູ້ບໍລິຫານແຕ່ລະຄົນສາມາດເຂົ້າເຖິງຂໍ້ມູນທີ່ຈໍາເປັນເທົ່ານັ້ນ.
6. ການເຂົ້າເຖິງບັງຄັບແລະການລ້າງຄວາມຊົງຈໍາ - ເຕັກໂນໂລຢີເຫຼົ່ານີ້ບໍ່ຄ່ອຍຖືກນໍາໃຊ້.
7. ການເຂົ້າລະຫັດ end-to-end ໂດຍກົງຈາກ DBMS ແມ່ນການເຂົ້າລະຫັດຂ້າງລູກຄ້າທີ່ມີການຄຸ້ມຄອງທີ່ສໍາຄັນໃນດ້ານເຊີຟເວີ.
8. ການເຂົ້າລະຫັດຂໍ້ມູນ. ຕົວຢ່າງ, ການເຂົ້າລະຫັດຖັນແມ່ນເມື່ອທ່ານໃຊ້ກົນໄກທີ່ເຂົ້າລະຫັດຖັນດຽວຂອງຖານຂໍ້ມູນ.

ນີ້ມີຜົນກະທົບແນວໃດຕໍ່ການປະຕິບັດຂອງ DBMS?

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

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

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

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

ເລືອກຈາກຕາຕະລາງທີ່ບໍ່ມີຟັງຊັນການເຂົ້າລະຫັດ:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

ໂມງຈັບເວລາເປີດຢູ່.

  id | text1 | ຂໍ້ຄວາມ2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 ເສັ້ນ)

ເວລາ: 1,386 ms

ການເລືອກຈາກຕາຕະລາງທີ່ມີຟັງຊັນການເຂົ້າລະຫັດ:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

ໂມງຈັບເວລາເປີດຢູ່.

  id | ຖອດລະຫັດ | ຖອດລະຫັດ
——+——————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 ເສັ້ນ)

ເວລາ: 50,203 ms

ຜົນການທົດສອບ:

 
ບໍ່ມີການເຂົ້າລະຫັດ
Pgcrypto (ຖອດລະຫັດ)

ຕົວຢ່າງ 1000 ແຖວ
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

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

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

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

ຕົວຢ່າງຂອງການເຂົ້າລະຫັດດັ່ງກ່າວໃນ MongoDB

ຄຸນນະສົມບັດຄວາມປອດໄພໃນການຄ້າແລະແຫຼ່ງເປີດ DBMS

ຟັງຊັນ
ປະເພດ
ນະໂຍບາຍລະຫັດຜ່ານ
ການກວດສອບ
ການປົກປ້ອງລະຫັດແຫຼ່ງຂອງຂັ້ນຕອນແລະຫນ້າທີ່
RLS
ການເຂົ້າລະຫັດ

Oracle
ການ​ຄ້າ
+
+
+
+
+

MsSql
ການ​ຄ້າ
+
+
+
+
+

ຢາທາໂບ
ການ​ຄ້າ
+
+
+
+
ການຂະຫຍາຍ

PostgreSQL
Free
ການຂະຫຍາຍ
ການຂະຫຍາຍ
-
+
ການຂະຫຍາຍ

MongoDb
Free
-
+
-
-
ມີຢູ່ໃນ MongoDB Enterprise ເທົ່ານັ້ນ

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

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

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

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

ບົດລາຍງານນີ້ໄດ້ຖືກນໍາສະເຫນີຄັ້ງທໍາອິດຢູ່ທີ່ @Databases Meetup ໂດຍ Mail.ru Cloud Solutions. ເບິ່ງ видео ການສະແດງອື່ນໆ ແລະສະໝັກຮັບການປະກາດເຫດການໃນ Telegram ປະມານ Kubernetes ຢູ່ Mail.ru Group.

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານກ່ຽວກັບຫົວຂໍ້:

1. ຫຼາຍກວ່າ Ceph: MCS cloud block storage.
2. ວິທີການເລືອກຖານຂໍ້ມູນສໍາລັບໂຄງການດັ່ງນັ້ນທ່ານບໍ່ຈໍາເປັນຕ້ອງເລືອກອີກເທື່ອຫນຶ່ງ.

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