ໂຫຼດການເພີ່ມປະສິດທິພາບໃນໂຄງການ Highload ດ້ວຍ ElasticSearch

ສະບາຍດີ, Habr! ຂ້ອຍຊື່ Maxim Vasiliev, ຂ້ອຍເຮັດວຽກເປັນນັກວິເຄາະແລະຜູ້ຈັດການໂຄງການຢູ່ FINCH. ມື້ນີ້ຂ້າພະເຈົ້າຢາກບອກທ່ານວ່າ, ການນໍາໃຊ້ ElasticSearch, ພວກເຮົາສາມາດດໍາເນີນການ 15 ລ້ານຄໍາຖາມໃນ 6 ນາທີແລະເພີ່ມປະສິດທິພາບການໂຫຼດປະຈໍາວັນຢູ່ໃນເວັບໄຊທ໌ຂອງລູກຄ້າຂອງພວກເຮົາ. ແຕ່ຫນ້າເສຍດາຍ, ພວກເຮົາຈະຕ້ອງເຮັດໂດຍບໍ່ມີຊື່, ເນື່ອງຈາກວ່າພວກເຮົາມີ NDA, ພວກເຮົາຫວັງວ່າເນື້ອໃນຂອງບົດຄວາມຈະບໍ່ທົນທຸກຈາກນີ້. ໄປ​ກັນ​ເລີຍ.

ໂຄງການເຮັດວຽກແນວໃດ

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

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

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

ປະຫວັດຫຍໍ້

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

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

ເພື່ອເຂົ້າໃຈ, ຈໍານວນກອງປະຊຸມປະຈໍາປີ 2017 ຢູ່ໃນເວັບໄຊທ໌ desktop ດຽວແມ່ນ 131 ລ້ານ. ໃນປີ 2018 - 125 ລ້ານ. ໃນປີ 2019 ອີກເທື່ອຫນຶ່ງ 130 ລ້ານ. ເພີ່ມອີກ 100-200 ລ້ານຈາກສະບັບມືຖືຂອງເວັບໄຊທ໌ແລະຄໍາຮ້ອງສະຫມັກມືຖື, ແລະທ່ານ. ຈະ​ໄດ້​ຮັບ​ຈໍາ​ນວນ​ຫຼວງ​ຫຼາຍ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​.

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

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

1. ຄວາມໄວດັດສະນີຊ້າຍ້ອນວ່າປະລິມານຂໍ້ມູນໃນດັດຊະນີເຕີບໂຕ. ດ້ວຍ Elastic, ຄວາມໄວບໍ່ຂຶ້ນກັບປະລິມານຂໍ້ມູນ.
2. ບໍ່ມີການຊອກຫາຂໍ້ຄວາມເຕັມ

ດັ່ງນັ້ນພວກເຮົາເລືອກ Elastic ສໍາລັບຕົວເຮົາເອງແລະກະກຽມສໍາລັບການຫັນປ່ຽນ.

ປ່ຽນເປັນ Elastic

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

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

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

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

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

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

ໄລຍະເວລາ

ດຽວນີ້ການອັບເດດຖືກຕັ້ງຄ່າຕາມເຫດການ, ອີງຕາມເງື່ອນໄຂຕໍ່ໄປນີ້:

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

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

ວິທີການປະສົມປະສານ

ມີ 2 ວິທີທີ່ຈະປະສົມປະສານກັບ Elastic:

1. ຜ່ານລູກຄ້າພື້ນເມືອງຜ່ານ TCP. ຄົນຂັບພື້ນເມືອງແມ່ນຄ່ອຍໆຕາຍໄປ: ມັນບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນອີກຕໍ່ໄປ, ແລະ syntax ຂອງມັນບໍ່ສະດວກຫຼາຍ. ເພາະສະນັ້ນ, ພວກເຮົາປະຕິບັດບໍ່ໄດ້ໃຊ້ມັນແລະພະຍາຍາມປະຖິ້ມມັນຢ່າງສົມບູນ.
2. ຜ່ານອິນເຕີເຟດ HTTP ທີ່ທ່ານສາມາດນໍາໃຊ້ທັງຄໍາຮ້ອງຂໍ JSON ແລະ syntax Lucene. ອັນສຸດທ້າຍແມ່ນເຄື່ອງຈັກຂໍ້ຄວາມທີ່ Elastic ໃຊ້. ໃນຕົວເລືອກນີ້, ພວກເຮົາໄດ້ຮັບຄວາມສາມາດໃນການ Batch ຜ່ານຄໍາຮ້ອງຂໍ JSON ຜ່ານ HTTP. ນີ້ແມ່ນທາງເລືອກທີ່ພວກເຮົາກໍາລັງພະຍາຍາມໃຊ້.

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

ບາງຕົວເລກສໍາລັບການປຽບທຽບ:

• ປະຢັດຜູ້ໃຊ້ທີ່ໄດ້ຮັບລາງວັນໃນ Postgres ໃນ 20 ກະທູ້ໂດຍບໍ່ມີການຈັດກຸ່ມ: 460713 ບັນທຶກໃນ 42 ວິນາທີ
• Elastic + reactive client ສໍາລັບ 10 threads + batch ສໍາລັບ 1000 ອົງປະກອບ: 596749 ບັນທຶກໃນ 11 ວິນາທີ
• Elastic + reactive client ສໍາລັບ 10 threads + batch ສໍາລັບ 1000 ອົງປະກອບ: 23801684 ບັນທຶກໃນ 4 ນາທີ

ຕອນນີ້ພວກເຮົາໄດ້ຂຽນຕົວຈັດການການຮ້ອງຂໍ HTTP ທີ່ສ້າງ JSON ເປັນ Batch/non-Batch ແລະສົ່ງຜ່ານລູກຄ້າ HTTP ໃດກໍ່ຕາມ, ບໍ່ວ່າຈະເປັນຫ້ອງສະຫມຸດ. ນອກນັ້ນທ່ານຍັງສາມາດເລືອກທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍ synchronously ຫຼື asynchronously.

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

ການສົ່ງເສີມການໃຫຍ່

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

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

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

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

ບົດສະຫຼຸບ/ບົດສະຫຼຸບ

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

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

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

⌘⌘⌘

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

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