ເກັບຮັກສາໄຟລ໌ຂະຫນາດນ້ອຍຫຼາຍຮ້ອຍລ້ານຢ່າງມີປະສິດທິພາບ. ການແກ້ໄຂຕົນເອງເປັນເຈົ້າພາບ

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

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

ແນວຄວາມຄິດແມ່ນນີ້:

ໃນຄໍາສັບຕ່າງໆງ່າຍໆ, ໄຟລ໌ຂະຫນາດນ້ອຍຖືກອັບໂຫລດຜ່ານເຄື່ອງແມ່ຂ່າຍ, ພວກມັນຖືກບັນທຶກໄວ້ໂດຍກົງໃນບ່ອນເກັບມ້ຽນ, ແລະຍັງອ່ານຈາກມັນ, ແລະໄຟລ໌ຂະຫນາດໃຫຍ່ຖືກວາງໄວ້ຂ້າງຄຽງ. ໂຄງ​ການ​: 1 folder = 1 archive​, ລວມ​ທັງ​ຫມົດ​ພວກ​ເຮົາ​ມີ​ຫຼາຍ​ລ້ານ​ເກັບ​ທີ່​ມີ​ໄຟລ​໌​ຂະ​ຫນາດ​ນ້ອຍ​, ແລະ​ບໍ່​ແມ່ນ​ຫຼາຍ​ຮ້ອຍ​ລ້ານ​ໄຟລ​໌​. ແລະທັງຫມົດນີ້ໄດ້ຖືກປະຕິບັດຢ່າງເຕັມສ່ວນ, ໂດຍບໍ່ມີການສະຄິບໃດໆຫຼືການວາງໄຟລ໌ເຂົ້າໄປໃນແຟ້ມ tar / zip.

ຂ້ອຍຈະພະຍາຍາມໃຫ້ມັນສັ້ນ, ຂ້ອຍຂໍໂທດລ່ວງ ໜ້າ ຖ້າໂພດຍາວ.

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

ສໍາລັບຜູ້ທີ່ບໍ່ມັກອ່ານບົດຄວາມ, ເອກະສານເລັກນ້ອຍແມ່ນງ່າຍກວ່າ:

ທີ່ນີ້ и ທີ່ນີ້.

ແລະ docker ໃນເວລາດຽວກັນ, ຕອນນີ້ມີທາງເລືອກພຽງແຕ່ກັບ nginx ພາຍໃນກໍລະນີ:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

ຕໍ່ໄປ:

ຖ້າມີໄຟລ໌ຫຼາຍ, ຊັບພະຍາກອນທີ່ສໍາຄັນແມ່ນຈໍາເປັນ, ແລະສ່ວນທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນວ່າບາງສ່ວນຂອງພວກມັນຖືກສູນເສຍ. ຕົວຢ່າງ, ເມື່ອໃຊ້ລະບົບໄຟລ໌ທີ່ເປັນກຸ່ມ (ໃນກໍລະນີນີ້, MooseFS), ໄຟລ໌, ບໍ່ວ່າຈະເປັນຂະຫນາດທີ່ແທ້ຈິງຂອງມັນ, ສະເຫມີໃຊ້ເວລາເຖິງຢ່າງຫນ້ອຍ 64 KB. ນັ້ນແມ່ນ, ສໍາລັບໄຟລ໌ທີ່ມີຂະຫນາດ 3, 10 ຫຼື 30 KB, ຕ້ອງການ 64 KB ໃນແຜ່ນ. ຖ້າມີຫນຶ່ງສ່ວນສີ່ຂອງພັນລ້ານໄຟລ໌, ພວກເຮົາສູນເສຍຈາກ 2 ຫາ 10 terabytes. ມັນຈະບໍ່ສາມາດສ້າງໄຟລ໌ໃຫມ່ໄດ້ຢ່າງບໍ່ຢຸດຢັ້ງ, ເນື່ອງຈາກວ່າ MooseFS ມີຂໍ້ຈໍາກັດ: ບໍ່ເກີນ 1 ຕື້ກັບຫນຶ່ງ replica ຂອງແຕ່ລະໄຟລ໌.

ເມື່ອຈໍານວນໄຟລ໌ເພີ່ມຂຶ້ນ, RAM ຫຼາຍແມ່ນຈໍາເປັນສໍາລັບ metadata. ການຖິ້ມເມຕາເດຕາຂະໜາດໃຫຍ່ເລື້ອຍໆຍັງປະກອບສ່ວນເຮັດໃຫ້ການສວມໃສ່ຂອງ SSD drives.

ເຊີບເວີ wZD. ພວກເຮົາຈັດວາງສິ່ງທີ່ເປັນລະບຽບຢູ່ໃນແຜ່ນ.

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

ໃນຈໍານວນທັງຫມົດ, ແທນທີ່ຈະເປັນຫນຶ່ງສ່ວນສີ່ຂອງພັນລ້ານໄຟລ໌, ໃນກໍລະນີຂອງຂ້ອຍມີພຽງແຕ່ 10 ລ້ານ Bolt archives ເຫຼືອ. ຖ້າຂ້ອຍມີໂອກາດທີ່ຈະປ່ຽນໂຄງສ້າງໄຟລ໌ໄດເລກະທໍລີໃນປະຈຸບັນ, ມັນເປັນໄປໄດ້ທີ່ຈະຫຼຸດລົງປະມານ 1 ລ້ານໄຟລ໌.

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

ສະຖາປັດຕະຍະກໍາແລະລັກສະນະຂອງເຄື່ອງແມ່ຂ່າຍ wZD.

ເຊີບເວີເຮັດວຽກພາຍໃຕ້ລະບົບປະຕິບັດການ Linux, BSD, Solaris ແລະ OSX. ຂ້ອຍພຽງແຕ່ທົດສອບສະຖາປັດຕະຍະກໍາ AMD64 ພາຍໃຕ້ Linux, ແຕ່ມັນຄວນຈະເຮັດວຽກສໍາລັບ ARM64, PPC64, MIPS64.

ຄຸນ​ນະ​ສົມ​ບັດ​ຕົ້ນ​ຕໍ​:

• Multithreading;
• Multiserver, ການສະຫນອງຄວາມທົນທານຄວາມຜິດແລະການດຸ່ນດ່ຽງການໂຫຼດ;
• ຄວາມໂປ່ງໃສສູງສຸດສໍາລັບຜູ້ໃຊ້ຫຼືຜູ້ພັດທະນາ;
• ວິທີການ HTTP ທີ່ຮອງຮັບ: GET, HEAD, PUT ແລະ DELETE;
• ການຄວບຄຸມພຶດຕິກໍາການອ່ານແລະການຂຽນຜ່ານຫົວລູກຄ້າ;
• ສະຫນັບສະຫນູນສໍາລັບການເປັນເຈົ້າພາບ virtual ປ່ຽນແປງໄດ້;
• ສະຫນັບສະຫນູນຄວາມສົມບູນຂອງຂໍ້ມູນ CRC ໃນເວລາທີ່ຂຽນ / ອ່ານ;
• buffers ເຄິ່ງໄດນາມິກສໍາລັບການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຫນ້ອຍທີ່ສຸດແລະການປັບປະສິດທິພາບເຄືອຂ່າຍທີ່ດີທີ່ສຸດ;
• ເລື່ອນຂໍ້ມູນການບີບອັດ;
• ນອກຈາກນັ້ນ, archiver ຫຼາຍກະທູ້ wZA ໄດ້ຖືກສະຫນອງໃຫ້ສໍາລັບການຍ້າຍໄຟລ໌ໂດຍບໍ່ມີການຢຸດເຊົາການບໍລິການ.

ປະສົບການຕົວຈິງ:

ຂ້ອຍໄດ້ພັດທະນາແລະທົດສອບເຄື່ອງແມ່ຂ່າຍແລະ archiver ໃນຂໍ້ມູນສົດສໍາລັບເວລາດົນນານ, ຕອນນີ້ມັນໄດ້ປະສົບຜົນສໍາເລັດໃນກຸ່ມທີ່ປະກອບມີ 250,000,000 ໄຟລ໌ຂະຫນາດນ້ອຍ (ຮູບພາບ) ທີ່ຢູ່ໃນ 15,000,000 ໄດເລກະທໍລີໃນ SATA drives ແຍກຕ່າງຫາກ. ກຸ່ມຂອງ 10 ເຊີບເວີແມ່ນເຄື່ອງແມ່ຂ່າຍຕົ້ນສະບັບທີ່ຕິດຕັ້ງຢູ່ຫລັງເຄືອຂ່າຍ CDN. ເພື່ອໃຫ້ບໍລິການ, 2 ເຊີບເວີ Nginx + 2 ເຄື່ອງແມ່ຂ່າຍ wZD ຖືກໃຊ້.

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

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

ຂະໜາດຂອງໄຟລ໌ທີ່ບີບອັດນ້ອຍລົງ, ການປະຕິບັດການ GET ແລະ PUT ທີ່ໄວກວ່າຈະຖືກປະຕິບັດກັບມັນ. ໃຫ້ສົມທຽບເວລາທັງຫມົດສໍາລັບການຂຽນລູກຄ້າ HTTP ກັບໄຟລ໌ປົກກະຕິແລະການເກັບ Bolt, ເຊັ່ນດຽວກັນກັບການອ່ານ. ເຮັດວຽກກັບໄຟລ໌ຂະຫນາດ 32 KB, 256 KB, 1024 KB, 4096 KB ແລະ 32768 KB ຖືກປຽບທຽບ.

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

ຂ້ອຍໄດ້ເຮັດການທົດສອບປະສິດທິພາບໃນ SSD drives, ເພາະວ່າການທົດສອບໃນ SATA drives ບໍ່ສະແດງໃຫ້ເຫັນຄວາມແຕກຕ່າງທີ່ຊັດເຈນ.

ກຣາບອີງຕາມຜົນການທົດສອບ:

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ສໍາລັບໄຟລ໌ຂະຫນາດນ້ອຍ, ຄວາມແຕກຕ່າງຂອງເວລາອ່ານແລະຂຽນລະຫວ່າງໄຟລ໌ທີ່ເກັບໄວ້ແລະບໍ່ຖືກເກັບໄວ້ແມ່ນຂະຫນາດນ້ອຍ.

ພວກ​ເຮົາ​ໄດ້​ຮັບ​ຮູບ​ພາບ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຫມົດ​ໃນ​ເວ​ລາ​ທີ່​ການ​ທົດ​ສອບ​ການ​ອ່ານ​ແລະ​ການ​ຂຽນ​ໄຟລ​໌​ຂອງ 32 MB ໃນ​ຂະ​ຫນາດ​:

ຄວາມແຕກຕ່າງເວລາລະຫວ່າງການອ່ານໄຟລ໌ພາຍໃນ 5-25 ms. ດ້ວຍການບັນທຶກ, ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າ, ຄວາມແຕກຕ່າງແມ່ນປະມານ 150 ms. ແຕ່ໃນກໍລະນີນີ້ບໍ່ຈໍາເປັນຕ້ອງອັບໂຫລດໄຟລ໌ຂະຫນາດໃຫຍ່, ມັນບໍ່ມີຈຸດສໍາຄັນທີ່ຈະເຮັດແນວນັ້ນ; ພວກເຂົາສາມາດຢູ່ແຍກຕ່າງຫາກຈາກບ່ອນເກັບມ້ຽນ.

*ທາງເທັກນິກ, ທ່ານສາມາດໃຊ້ເຊີບເວີນີ້ສຳລັບວຽກທີ່ຕ້ອງການ NoSQL.

ວິທີການພື້ນຖານຂອງການເຮັດວຽກກັບເຄື່ອງແມ່ຂ່າຍ wZD:

ກຳລັງໂຫຼດໄຟລ໌ປົກກະຕິ:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

ການອັບໂຫລດໄຟລ໌ໃສ່ບ່ອນເກັບມ້ຽນ Bolt (ຖ້າຕົວກໍານົດການຂອງເຊີຟເວີ fmaxsize, ເຊິ່ງກໍານົດຂະຫນາດໄຟລ໌ສູງສຸດທີ່ສາມາດຖືກລວມເຂົ້າໃນການເກັບ, ແມ່ນບໍ່ເກີນ; ຖ້າມັນເກີນ, ໄຟລ໌ຈະຖືກອັບໂຫລດຕາມປົກກະຕິຕໍ່ໄປກັບບ່ອນເກັບມ້ຽນ):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

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

curl -o test.jpg http://localhost/test/test.jpg

ການດາວໂຫຼດໄຟລ໌ຈາກແຟ້ມ Bolt (ບັງຄັບ):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

ລາຍລະອຽດຂອງວິທີການອື່ນໆແມ່ນຢູ່ໃນເອກະສານ.

ເອກະສານ wZD
ເອກະສານ WSA

ຕອນນີ້ເຊີບເວີພຽງແຕ່ຮອງຮັບ HTTP protocol ເທົ່ານັ້ນ; ມັນບໍ່ໄດ້ເຮັດວຽກກັບ HTTPS ເທື່ອ. ວິທີການ POST ຍັງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ (ມັນຍັງບໍ່ທັນໄດ້ຕັດສິນໃຈວ່າມັນຕ້ອງການຫຼືບໍ່).

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

ສິ່ງທີ່ຕ້ອງເຮັດ:

• ການ​ພັດ​ທະ​ນາ replicator ແລະ​ຈໍາ​ຫນ່າຍ​ຂອງ​ທ່ານ​ເອງ + geo ສໍາ​ລັບ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ຂອງ​ການ​ນໍາ​ໃຊ້​ໃນ​ລະ​ບົບ​ຂະ​ຫນາດ​ໃຫຍ່​ໂດຍ​ບໍ່​ມີ​ລະ​ບົບ​ໄຟລ​໌ cluster (ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ສໍາ​ລັບ​ຜູ້​ໃຫຍ່​)
• ຄວາມ​ເປັນ​ໄປ​ໄດ້​ຂອງ​ການ​ຟື້ນ​ຕົວ​ຢ່າງ​ສົມ​ບູນ​ຂອງ metadata ຖ້າ​ຫາກ​ວ່າ​ມັນ​ໄດ້​ຖືກ​ສູນ​ເສຍ​ຢ່າງ​ສົມ​ບູນ (ຖ້າ​ຫາກ​ວ່າ​ການ​ນໍາ​ໃຊ້​ຈໍາ​ຫນ່າຍ​)
• ໂປຣໂຕຄໍຕົ້ນສະບັບສໍາລັບຄວາມສາມາດໃນການໃຊ້ການເຊື່ອມຕໍ່ເຄືອຂ່າຍຢ່າງຕໍ່ເນື່ອງແລະໄດເວີສໍາລັບພາສາການຂຽນໂປຼແກຼມທີ່ແຕກຕ່າງກັນ
• ຄວາມເປັນໄປໄດ້ຂັ້ນສູງສໍາລັບການນໍາໃຊ້ອົງປະກອບ NoSQL
• ການບີບອັດຂອງປະເພດຕ່າງໆ (gzip, zstd, snappy) ສໍາລັບໄຟລ໌ຫຼືຄ່າພາຍໃນ Bolt archives ແລະສໍາລັບໄຟລ໌ປົກກະຕິ
• ການເຂົ້າລະຫັດຂອງປະເພດຕ່າງໆສໍາລັບໄຟລ໌ຫຼືຄ່າພາຍໃນ Bolt archives ແລະສໍາລັບໄຟລ໌ປົກກະຕິ
• ການປ່ຽນວິດີໂອຂ້າງເຊີບເວີລ່າຊ້າ, ລວມທັງໃນ GPU

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

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