19 ຫົວ hydra. ພາບລວມທີ່ຍິ່ງໃຫຍ່ຂອງໂຄງການ

ກອງປະຊຸມຈະຈັດຂຶ້ນໃນວັນທີ 11-12 ກໍລະກົດທີ່ St Hydra, ອຸທິດຕົນເພື່ອການພັດທະນາລະບົບຂະຫນານແລະແຈກຢາຍ. trick ຂອງ Hydra ແມ່ນວ່າມັນ unites ນັກວິທະຍາສາດເຢັນ (ຜູ້ທີ່ປົກກະຕິແລ້ວສາມາດພົບເຫັນພຽງແຕ່ຢູ່ໃນກອງປະຊຸມວິທະຍາສາດຕ່າງປະເທດ) ແລະວິສະວະກອນການປະຕິບັດທີ່ມີຊື່ສຽງເຂົ້າໄປໃນໂຄງການຂະຫນາດໃຫຍ່ຫນຶ່ງທີ່ຕັດກັນຂອງວິທະຍາສາດແລະການປະຕິບັດ.

Hydra ແມ່ນຫນຶ່ງໃນກອງປະຊຸມທີ່ສໍາຄັນທີ່ສຸດຂອງພວກເຮົາໃນສອງສາມປີຜ່ານມາ. ມັນໄດ້ຖືກນໍາຫນ້າໂດຍການກະກຽມທີ່ຮ້າຍແຮງຫຼາຍ, ການຄັດເລືອກລໍາໂພງແລະບົດລາຍງານ. ອາທິດທີ່ຜ່ານມາກ່ຽວກັບເລື່ອງນີ້ ການສໍາພາດ habro ອອກມາ ກັບຜູ້ອໍານວຍການ JUG.ru Group, Alexey Fedorov (23derevo).

ພວກ​ເຮົາ ບອກແລ້ວ ກ່ຽວກັບສາມຜູ້ເຂົ້າຮ່ວມທີ່ສໍາຄັນ, ຜູ້ກໍ່ຕັ້ງທິດສະດີຂອງລະບົບແຈກຢາຍ - Leslie Lamport, Maurice Herlihy ແລະ Michael Scott. ມັນເປັນເວລາທີ່ຈະສົນທະນາໃນລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບໂຄງການທັງຫມົດ!

ແຮງກະຕຸ້ນ

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

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

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

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

ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາມີວິສະວະກອນຊັ້ນນໍາຫຼາຍຄົນທີ່ເຮັດວຽກກ່ຽວກັບບັນຫາກົດດັນໃນລະບົບການແຈກຢາຍໃນປັດຈຸບັນ, ແລະພວກເຂົາແນ່ນອນມີຫຼາຍທີ່ຈະບອກ. ແຕ່ນີ້ແມ່ນບັນຫາ - ພວກເຂົາ работают, ແລະເວລາຂອງພວກເຂົາແມ່ນມີຄຸນຄ່າ. ແມ່ນແລ້ວ, ຖ້າທ່ານເປັນພະນັກງານຂອງ Microsoft, Google ຫຼື JetBrains, ຄວາມເປັນໄປໄດ້ຂອງການພົບກັບລໍາໂພງທີ່ມີຊື່ສຽງໃນເຫດການພາຍໃນເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ, ແຕ່ໂດຍທົ່ວໄປ, ບໍ່, ນີ້ບໍ່ໄດ້ເກີດຂຶ້ນທຸກໆມື້.

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

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

ຄຳສຳຄັນ

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

Cliff Click H2O ແຈກຢາຍ K/V algorithm

Cliff ເປັນນິທານໃນໂລກ Java. ໃນທ້າຍຊຸມປີ 90, ສໍາລັບທິດສະດີປະລິນຍາເອກຂອງລາວ, ລາວໄດ້ຂຽນເອກະສານທີ່ມີຊື່ວ່າ "ລວມການວິເຄາະ, ປະສົມປະສານການເພີ່ມປະສິດທິພາບ", ເຊິ່ງບາງຄັ້ງຕໍ່ມາກາຍເປັນພື້ນຖານສໍາລັບ HotSpot JVM Server Compiler. ສອງປີຕໍ່ມາ, ລາວໄດ້ເຮັດວຽກຢູ່ Sun Microsystems ໃນ JVM ແລະສະແດງໃຫ້ເຫັນທົ່ວໂລກວ່າ JIT ມີສິດທີ່ຈະມີຢູ່. ເລື່ອງທັງຫມົດນີ້ກ່ຽວກັບວິທີການ Java ເປັນຫນຶ່ງໃນ runtime ທີ່ທັນສະໄຫມທີ່ໄວທີ່ສຸດທີ່ມີການເພີ່ມປະສິດທິພາບທີ່ສະຫລາດແລະໄວທີ່ສຸດແມ່ນມາຈາກ Cliff Click. ໃນຕອນເລີ່ມຕົ້ນ, ມັນເຊື່ອວ່າຖ້າບາງສິ່ງບາງຢ່າງສາມາດເຂົ້າເຖິງຕົວລວບລວມແບບຄົງທີ່, ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງພະຍາຍາມໃສ່ມັນ. ຂໍຂອບໃຈກັບການເຮັດວຽກຂອງ Cliff ແລະທີມງານ, ທຸກໆພາສາໃຫມ່ເລີ່ມຕົ້ນຖືກສ້າງຂື້ນດ້ວຍຄວາມຄິດຂອງການລວບລວມ JIT ໂດຍຄ່າເລີ່ມຕົ້ນ. ແນ່ນອນ, ນີ້ບໍ່ແມ່ນວຽກດຽວ, ແຕ່ Cliff ມີບົດບາດສໍາຄັນຫຼາຍ.

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

ບົດ​ລາຍ​ງານ​ອີກ​ອັນ​ໜຶ່ງ​ທີ່ Cliff ຈະ​ໃຫ້​ແມ່ນ ປະສົບການການເຮັດທຸລະກໍາຂອງຮາດແວ Azul. ສ່ວນຫນຶ່ງຂອງຊີວະປະຫວັດຂອງລາວ - ສິບປີ ເຮັດວຽກຢູ່ Azul, ບ່ອນທີ່ທ່ານໄດ້ປັບປຸງແລະປັບປຸງຫຼາຍຢ່າງໃນຮາດແວແລະເທກໂນໂລຍີ Azul: compilers JIT, runtime, thread model, ຄວາມຜິດພາດການຈັດການ, stack, hardware interrupts, class loading, ແລະອື່ນໆແລະອື່ນໆ - ດີ, ທ່ານໄດ້ຮັບ. ຄວາມຄິດ.

ພາກສ່ວນທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ສຸດໄດ້ເລີ່ມຕົ້ນໃນເວລາທີ່ພວກເຂົາສ້າງຮາດແວສໍາລັບທຸລະກິດຂະຫນາດໃຫຍ່ - supercomputer ເພື່ອດໍາເນີນການ Java. ມັນເປັນສິ່ງທີ່ສ້າງສັນ, ປັບແຕ່ງສະເພາະສໍາລັບ Java, ເຊິ່ງມີຄວາມຕ້ອງການພິເສດ - ອ່ານອຸປະສັກຂອງຫນ່ວຍຄວາມຈໍາສໍາລັບການເກັບຂີ້ເຫຍື້ອຕ່ໍາ, arrays ທີ່ມີການກວດສອບຂອບເຂດ, ການໂທ virtual ... ຫນຶ່ງໃນເຕັກໂນໂລຢີທີ່ເຢັນທີ່ສຸດແມ່ນຫນ່ວຍຄວາມຈໍາການເຮັດທຸລະກໍາຂອງຮາດແວ. L1 ທັງຫມົດຂອງ 864 cores ສາມາດເຂົ້າຮ່ວມໃນການຂຽນທຸລະກໍາ, ເຊິ່ງເປັນສິ່ງສໍາຄັນໂດຍສະເພາະສໍາລັບການເຮັດວຽກກັບ locks ໃນ Java (ຕັນ synchronized ສາມາດເຮັດວຽກຂະຫນານໄດ້ຕາບໃດທີ່ບໍ່ມີຄວາມຂັດແຍ້ງກ່ຽວກັບຄວາມຈໍາທີ່ແທ້ຈິງ). ແຕ່ຄວາມຄິດທີ່ສວຍງາມໄດ້ຖືກທໍາລາຍໂດຍຄວາມເປັນຈິງທີ່ຮຸນແຮງ - ແລະໃນການສົນທະນານີ້ Cliff ຈະບອກທ່ານວ່າເປັນຫຍັງ HTM ແລະ STM ບໍ່ເຫມາະສົມກັບຄວາມຕ້ອງການປະຕິບັດຂອງຄອມພິວເຕີ້ຫຼາຍເສັ້ນ.

Michael Scott - ໂຄງສ້າງຂໍ້ມູນຄູ່

Michael Scott - ສາດສະດາຈານວິທະຍາສາດຄອມພິວເຕີຢູ່ມະຫາວິທະຍາໄລ Rochester, ເຊິ່ງພົວພັນຊຶ່ງພົວພັນເຖິງລາວ ແລ້ວ 34 ປີ, ແລະຢູ່ມະຫາວິທະຍາໄລ Wisconsin-Madison ບ້ານຂອງລາວ, ລາວເປັນຄະນະບໍດີເປັນເວລາຫ້າປີ. ລາວຄົ້ນຄວ້າ ແລະສອນນັກຮຽນກ່ຽວກັບການຂຽນໂປຣແກຣມແບບຂະໜານ ແລະແຈກຢາຍ ແລະການອອກແບບພາສາ.

ໂລກທັງຫມົດຮູ້ວ່າ Michael ຂອບໃຈກັບປື້ມແບບຮຽນ "ພາສາການຂຽນໂປຼແກຼມ", ສະບັບຫລ້າສຸດຂອງທີ່ໄດ້ຈັດພີມມາຂ້ອນຂ້າງບໍ່ດົນມານີ້ - ໃນປີ 2015. ວຽກຂອງລາວ "Algorithms ສໍາລັບ synchronization ທີ່ສາມາດປັບຂະ ໜາດ ໄດ້ໃນຕົວປະມວນຜົນຫຼາຍໜ່ວຍຄວາມ ຈຳ ທີ່ແບ່ງປັນ" ໄດ້ຮັບ ລາງວັນ Dijkstra ເປັນ​ຫນຶ່ງ​ໃນ​ທີ່​ມີ​ຊື່​ສຽງ​ທີ່​ສຸດ​ໃນ​ພາກ​ສະ​ຫນາມ​ຂອງ​ຄອມ​ພິວ​ເຕີ​ແຈກ​ຢາຍ​ແລະ​ ນອນຢ່າງເປີດເຜີຍ ທີ່ມະຫາວິທະຍາໄລ Rochester Online Library. ທ່ານອາດຈະຮູ້ຈັກລາວເປັນຜູ້ຂຽນຂອງ algorithm Michael-Scott ຫຼາຍຈາກ "ງ່າຍດາຍ, ໄວ, ແລະປະຕິບັດບໍ່ໄດ້ສະກັດແລະສະກັດລະບົບລໍາດັບຄິວພ້ອມກັນ".

ສໍາລັບໂລກ Java, ນີ້ແມ່ນກໍລະນີພິເສດ: ຮ່ວມກັນກັບ Doug Lea, ລາວໄດ້ພັດທະນາລະບົບສູດການຄິດໄລ່ທີ່ບໍ່ສະກັດກັ້ນແລະແຖວ synchronous ທີ່ຫ້ອງສະຫມຸດ Java ເຮັດວຽກ. ນີ້ແມ່ນສິ່ງທີ່ຫົວຂໍ້ສໍາຄັນ "ໂຄງສ້າງຂໍ້ມູນຄູ່" ຈະເວົ້າກ່ຽວກັບ - ການນໍາສະເຫນີໂຄງສ້າງເຫຼົ່ານີ້ໃນ Java SE 6 ໄດ້ປັບປຸງການປະຕິບັດ 10 ເທົ່າ. java.util.concurrent.ThreadPoolExecutor. ຖ້າທ່ານສົງໄສລ່ວງຫນ້າວ່າ "ໂຄງສ້າງຂໍ້ມູນຄູ່" ເຫຼົ່ານີ້ແມ່ນແນວໃດ, ຫຼັງຈາກນັ້ນມີຂໍ້ມູນກ່ຽວກັບມັນ ວຽກ​ງານ​ທີ່​ກ່ຽວ​ຂ້ອງ​.

Maurice Herlihy - Blockchains ແລະອະນາຄົດຂອງຄອມພິວເຕີ້ແຈກຢາຍ

Maurice Herlihy - ຜູ້ຊະນະສອງລາງວັນ Dijkstra. ອັນທໍາອິດແມ່ນສໍາລັບການເຮັດວຽກ "ການຊິ້ງຂໍ້ມູນລໍຖ້າຟຣີ" (ມະຫາວິທະຍາໄລ Brown), ແລະທີສອງ, ບໍ່ດົນມານີ້ - "ຫນ່ວຍຄວາມຈໍາການເຮັດທຸລະກໍາ: ການສະຫນັບສະຫນູນສະຖາປັດຕະຍະກໍາສໍາລັບໂຄງສ້າງຂໍ້ມູນທີ່ບໍ່ມີການລັອກ" (Virginia Tech University). ລາງວັນ Dijkstra ຮັບຮູ້ເຖິງວຽກງານທີ່ມີຄວາມສໍາຄັນແລະຜົນກະທົບທີ່ເຫັນໄດ້ຊັດເຈນຢ່າງຫນ້ອຍສິບປີ, ແລະ Maurice ແມ່ນຫນຶ່ງໃນບັນດາຜູ້ຊ່ຽວຊານທີ່ມີຊື່ສຽງຫຼາຍທີ່ສຸດໃນຂົງເຂດ. ໃນປັດຈຸບັນລາວເຮັດວຽກເປັນສາດສະດາຈານຢູ່ມະຫາວິທະຍາໄລ Brown ແລະມີບັນຊີລາຍຊື່ຂອງຜົນສໍາເລັດທີ່ຍາວໄກ.

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

ໃນເດືອນກໍລະກົດ 2017, Maurice ໄດ້ມາລັດເຊຍແລ້ວເພື່ອເຂົ້າໂຮງຮຽນ SPTDC, ເຂົ້າຮ່ວມໃນກອງປະຊຸມ JUG.ru, ແລະການບັນທຶກສາມາດເບິ່ງໄດ້ໃນ YouTube:

ໂຄງການຕົ້ນຕໍ

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

Leslie Lamport - ຖາມແລະຕອບ

Leslie Lamport ເປັນຜູ້ຂຽນຂອງວຽກງານ seminal ໃນຄອມພິວເຕີ້ແຈກຢາຍ. "LaTeX" ຫຍໍ້ມາຈາກ "Lamport TeX". ມັນແມ່ນຜູ້ທີ່ທໍາອິດ, ກັບຄືນໄປບ່ອນໃນປີ 1979, ນໍາສະເຫນີແນວຄວາມຄິດ ຄວາມສອດຄ່ອງຕາມລໍາດັບ, ແລະບົດຄວາມຂອງລາວ "ວິທີການສ້າງຄອມພິວເຕີ Multiprocessor ທີ່ປະຕິບັດໂຄງການ Multiprocess ໄດ້ຢ່າງຖືກຕ້ອງ" ໄດ້ຮັບລາງວັນ Dijkstra.

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

ແນວຄວາມຄິດແມ່ນງ່າຍດາຍ - ທ່ານເບິ່ງສອງບົດລາຍງານໃນ YouTube: "ການຂຽນໂປຼແກຼມຄວນຈະຫຼາຍກວ່າການຂຽນລະຫັດ" и "ຖ້າທ່ານບໍ່ໄດ້ຂຽນໂປຼແກຼມ, ຢ່າໃຊ້ພາສາການຂຽນໂປຼແກຼມ." ແລະກະກຽມຢ່າງຫນ້ອຍຫນຶ່ງຄໍາຖາມ, ແລະ Leslie ຄໍາຕອບ.

ວິດີໂອທໍາອິດຂອງສອງອັນນີ້ພວກເຮົາມີຢູ່ແລ້ວ ກາຍເປັນບົດຄວາມ habro. ຖ້າທ່ານບໍ່ມີເວລາຫນຶ່ງຊົ່ວໂມງເພື່ອເບິ່ງວິດີໂອ, ທ່ານສາມາດອ່ານມັນທັງຫມົດໃນຮູບແບບຂໍ້ຄວາມ.

ໝາຍເຫດ: ມີຫຼາຍວິດີໂອ Leslie Lamport ຢູ່ໃນ YouTube. ຕົວຢ່າງ, ມີສິ່ງທີ່ດີເລີດ ຫຼັກສູດ TLA+. ສະບັບອອຟໄລຂອງຫຼັກສູດທັງຫມົດນີ້ແມ່ນມີຢູ່ ຫນ້າທໍາອິດຂອງຜູ້ຂຽນ, ແລະລາວໄດ້ອັບໂຫລດມັນໃສ່ YouTube ສໍາລັບການເບິ່ງງ່າຍຂຶ້ນໃນອຸປະກອນມືຖື.

Martin Kleppmann - ການຊິງຄ໌ຂໍ້ມູນໃນທົ່ວອຸປະກອນຜູ້ໃຊ້ສໍາລັບການຮ່ວມມືແບບແຈກຢາຍ

Martin Kleppmann ເປັນນັກຄົ້ນຄວ້າຢູ່ມະຫາວິທະຍາໄລ Cambridge ທີ່ເຮັດວຽກກ່ຽວກັບ CRDT ແລະການກວດສອບລະບົບສູດການຄິດໄລ່ຢ່າງເປັນທາງການ. ປື້ມຂອງ Martin "ການອອກແບບແອັບພລິເຄຊັນທີ່ໃຊ້ຂໍ້ມູນຫຼາຍ", ຈັດພີມມາໃນປີ 2017, ພິສູດວ່າປະສົບຜົນສໍາເລັດຫຼາຍແລະເຮັດໃຫ້ມັນເຂົ້າໄປໃນບັນຊີລາຍຊື່ທີ່ຂາຍດີທີ່ສຸດໃນຂົງເຂດການເກັບຮັກສາຂໍ້ມູນແລະການປຸງແຕ່ງ. Kevin Scott, CTO ຢູ່ Microsoft, ເວົ້າເທື່ອໜຶ່ງ: “ປຶ້ມຫົວນີ້ຄວນມີສຳລັບນັກວິສະວະກອນຊອບແວ. ນີ້ແມ່ນຊັບພະຍາກອນທີ່ຫາຍາກທີ່ປະສົມປະສານທິດສະດີແລະການປະຕິບັດເພື່ອຊ່ວຍໃຫ້ນັກພັດທະນາສະຫລາດກວ່າໃນການອອກແບບແລະປະຕິບັດໂຄງສ້າງພື້ນຖານແລະລະບົບຂໍ້ມູນ." ຜູ້ສ້າງ Kafka ແລະ CTO ຂອງ Confluent, Jay Kreps, ເວົ້າບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ.

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

• Rapportive, ອຸທິດຕົນເພື່ອສະແດງໂປຣໄຟລ໌ສັງຄົມຂອງການຕິດຕໍ່ຈາກອີເມວຂອງທ່ານ, ທີ່ LinkedIn ຊື້ໃນປີ 2012;
• ໄປທົດສອບມັນ, ການບໍລິການສໍາລັບການທົດສອບອັດຕະໂນມັດເວັບໄຊທ໌ໃນຕົວທ່ອງເວັບຕ່າງໆ, ເຊິ່ງ RedGate ຊື້ໃນປີ 2009.

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

ໃນການສົນທະນານີ້, Martin ຈະເວົ້າກ່ຽວກັບຫົວຂໍ້ທີ່ໃກ້ຊິດກັບການຄົ້ນຄວ້າທາງວິຊາການຂອງລາວ. ໃນ Google Docs ແລະ sofas ການແກ້ໄຂເອກະສານທີ່ຄ້າຍຄືກັນ, "ການແກ້ໄຂຮ່ວມກັນ" ຫມາຍເຖິງວຽກງານການຈໍາລອງ: ຜູ້ໃຊ້ແຕ່ລະຄົນມີການສໍາເນົາຂອງຕົນເອງຂອງເອກະສານທີ່ແບ່ງປັນ, ເຊິ່ງພວກເຂົາດັດແປງ, ແລະການປ່ຽນແປງທັງຫມົດແມ່ນຖືກສົ່ງໄປຫາສ່ວນທີ່ເຫຼືອຂອງເຄືອຂ່າຍ. ຜູ້ເຂົ້າຮ່ວມ. ການປ່ຽນແປງເອກະສານແບບອອບໄລນ໌ນໍາໄປສູ່ຄວາມບໍ່ສອດຄ່ອງຊົ່ວຄາວຂອງເອກະສານທີ່ກ່ຽວຂ້ອງກັບຜູ້ເຂົ້າຮ່ວມອື່ນໆ, ແລະການ synchronization ອີກເທື່ອຫນຶ່ງຮຽກຮ້ອງໃຫ້ມີການຈັດການຂໍ້ຂັດແຍ່ງ. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຂົາມີຢູ່ແທ້ໆ ປະເພດຂໍ້ມູນແບບຈຳລອງທີ່ບໍ່ມີຂໍ້ຂັດແຍ່ງ (CRDT), ໃນຄວາມເປັນຈິງ, ເປັນສິ່ງໃຫມ່ທີ່ຂ້ອນຂ້າງ, ໂດຍເນື້ອແທ້ແລ້ວຂອງທີ່ໄດ້ສ້າງຕັ້ງຂຶ້ນພຽງແຕ່ໃນປີ 2011. ການສົນທະນານີ້ປຶກສາຫາລືກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນນັບຕັ້ງແຕ່ນັ້ນມາໃນໂລກຂອງ CRDT, ຄວາມກ້າວຫນ້າທີ່ຜ່ານມາແມ່ນຫຍັງ, ວິທີການສ້າງຄໍາຮ້ອງສະຫມັກທ້ອງຖິ່ນທໍາອິດໂດຍທົ່ວໄປແລະການນໍາໃຊ້ຫ້ອງສະຫມຸດແຫຼ່ງເປີດ. ອັດໂນມັດ ໂດຍ​ສະ​ເພາະ.

ໃນອາທິດຕໍ່ໄປພວກເຮົາຈະເຜີຍແຜ່ການສໍາພາດຍາວກັບ Martin on Habré, ມັນຈະເປັນຫນ້າສົນໃຈ.

Pedro Ramalhete - ໂຄງສ້າງຂໍ້ມູນທີ່ບໍ່ມີການລໍຖ້າ ແລະທຸລະກຳທີ່ບໍ່ມີການລໍຖ້າ

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

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

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

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

Heidi Howard - ປົດປ່ອຍຄວາມເຫັນດີເຫັນພ້ອມທີ່ແຈກຢາຍ

Heidi Howard ແມ່ນ, ຄືກັບ Martin, ນັກຄົ້ນຄວ້າລະບົບແຈກຢາຍຢູ່ມະຫາວິທະຍາໄລ Cambridge. ລັກສະນະພິເສດຂອງນາງແມ່ນຄວາມສອດຄ່ອງ, ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ, ການປະຕິບັດແລະການແຈກຢາຍເປັນເອກະສັນກັນ. ນາງເປັນທີ່ຮູ້ຈັກດີທີ່ສຸດສໍາລັບການທົ່ວໄປຂອງນາງຂອງ Paxos algorithm ເອີ້ນວ່າ Paxos ປ່ຽນແປງໄດ້.

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

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

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

Alex Petrov — ຫຼຸດຄ່າໃຊ້ຈ່າຍໃນການເກັບຮັກສາຂອງທ່ານດ້ວຍການຈຳລອງແບບຊົ່ວຄາວ ແລະ ໂຄຣມລາຄາຖືກ

Alex ເປັນຜູ້ຊ່ຽວຊານດ້ານຖານຂໍ້ມູນແລະລະບົບການເກັບຮັກສາ, ແລະສໍາຄັນຫຼາຍສໍາລັບພວກເຮົາ, committer ໃນ Cassandra. ໃນປັດຈຸບັນລາວກໍາລັງເຮັດວຽກຢູ່ໃນປຶ້ມ, Database Internals, ກັບ O'Reilly.

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

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

ໃນໄລຍະບົດລາຍງານພວກເຮົາຈະພິຈາລະນາ ແບບຈຳລອງຂອງພະຍານ, ຮູບແບບການຈໍາລອງທີ່ໃຊ້ໃນ Spanner и ຮ້ານຄ້າໃຫຍ່, ແລະການປະຕິບັດແນວຄວາມຄິດນີ້ໃນ Apache Cassandra ເອີ້ນວ່າ ການຈຳລອງແບບຊົ່ວຄາວ ແລະ ໂຄຣມລາຄາຖືກ.

Dmitry Vyukov - Goutines ເປີດເຜີຍ

Dmitry ເປັນນັກພັດທະນາຢູ່ Google ທີ່ເຮັດວຽກກ່ຽວກັບການທົດສອບແບບໄດນາມິກສຳລັບ C/C++ ແລະ Go — Address/Memory/ThreadSanitizer, ແລະເຄື່ອງມື kernel ທີ່ຄ້າຍຄືກັນ. Linuxລາວໄດ້ປະກອບສ່ວນເຄື່ອງມືກຳນົດເວລາ goroutine ທີ່ສາມາດຂະຫຍາຍໄດ້, ເຄື່ອງມືສຳຫຼວດເຄືອຂ່າຍ, ແລະ ຕົວເກັບຂີ້ເຫຍື້ອແບບຂະໜານໃຫ້ກັບ Go. ລາວເປັນຜູ້ຊ່ຽວຊານດ້ານ multithreading, ເປັນຜູ້ຂຽນອັລກໍຣິທຶມທີ່ບໍ່ບລັອກໃໝ່ຫຼາຍສິບອັນ, ແລະ ເປັນຜູ້ຖື ສາຍແອວດຳ Intel

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

Dmitry Bugaichenko - ເລັ່ງການວິເຄາະກາຟທີ່ແຈກຢາຍດ້ວຍຮູບແຕ້ມທີ່ອາດຈະເປັນໄປໄດ້ ແລະອື່ນໆອີກ

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

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

Denis Rystsov - ຫຼຸດຄ່າໃຊ້ຈ່າຍໃນການເກັບຮັກສາຂອງທ່ານດ້ວຍການຈຳລອງແບບຊົ່ວຄາວ ແລະ ໂຄຣມລາຄາຖືກ

Denis - ນັກພັດທະນາ Cosmos DB, ຜູ້ຊ່ຽວຊານໃນການກວດສອບແບບຈໍາລອງຄວາມສອດຄ່ອງ, ສູດການຄິດໄລ່ຄວາມເຫັນດີເຫັນພ້ອມ, ແລະການເຮັດທຸລະກໍາທີ່ແຈກຢາຍ. ໃນປັດຈຸບັນລາວເຮັດວຽກຢູ່ Microsoft, ແລະກ່ອນຫນ້ານັ້ນລາວໄດ້ເຮັດວຽກກ່ຽວກັບລະບົບແຈກຢາຍຢູ່ Amazon ແລະ Yandex.

ໃນການສົນທະນານີ້, ພວກເຮົາຈະພິຈາລະນາກ່ຽວກັບໂປໂຕຄອນການເຮັດທຸລະກໍາທີ່ແຈກຢາຍທີ່ຖືກປະດິດຂື້ນໃນສອງສາມປີຜ່ານມາ, ເຊິ່ງສາມາດປະຕິບັດໄດ້ໃນດ້ານລູກຄ້າຢູ່ເທິງສຸດຂອງຮ້ານຂໍ້ມູນໃດໆທີ່ສະຫນັບສະຫນູນການປັບປຸງເງື່ອນໄຂ (ປຽບທຽບແລະກໍານົດ). ເສັ້ນທາງລຸ່ມແມ່ນວ່າຊີວິດບໍ່ໄດ້ສິ້ນສຸດລົງດ້ວຍຄໍາຫມັ້ນສັນຍາສອງໄລຍະ, ການເຮັດທຸລະກໍາສາມາດຖືກເພີ່ມຢູ່ເທິງຖານຂໍ້ມູນໃດໆ - ໃນລະດັບຄໍາຮ້ອງສະຫມັກ, ແຕ່ໂປໂຕຄອນທີ່ແຕກຕ່າງກັນ (2PC, Percolator, RAMP) ມີການຊື້ຂາຍທີ່ແຕກຕ່າງກັນແລະບໍ່ໄດ້ມອບໃຫ້ພວກເຮົາ. ຟຣີ.

Alexey Zinoviev - ບໍ່ແມ່ນທຸກ ML algorithms ເຮັດໃຫ້ມັນໄປສູ່ສະຫວັນ

Alexei (zaleslaw) ເປັນ​ຜູ້​ເວົ້າ​ທີ່​ໃຊ້​ເວ​ລາ​ດົນ​ນານ​ແລະ​ເປັນ​ສະ​ມາ​ຊິກ​ຂອງ​ຄະ​ນະ​ກໍາ​ມະ​ການ​ໂຄງ​ການ​ໃນ​ກອງ​ປະ​ຊຸມ​ອື່ນໆ​. ຝຶກຊ້ອມຢູ່ EPAM Systems, ແລະເປັນເພື່ອນກັບ Hadoop/Spark ແລະຂໍ້ມູນໃຫຍ່ອື່ນໆຕັ້ງແຕ່ປີ 2012.

ໃນການສົນທະນານີ້, Alexey ຈະເວົ້າກ່ຽວກັບບັນຫາຂອງການປັບຕົວວິທີການຮຽນຮູ້ເຄື່ອງຈັກຄລາສສິກສໍາລັບການປະຕິບັດໃນຮູບແບບການແຈກຢາຍໂດຍອີງໃສ່ປະສົບການຂອງລາວທີ່ເຮັດວຽກກັບ Apache Spark ML, Apache Mahout, Apache Flink ML ແລະປະສົບການຂອງການສ້າງ Apache Ignite ML. Alexey ຍັງຈະເວົ້າກ່ຽວກັບການປະຕິບັດ ML algorithms ທີ່ແຈກຢາຍຢູ່ໃນກອບເຫຼົ່ານີ້.

ແລະສຸດທ້າຍ, ສອງບົດລາຍງານຈາກ Yandex ກ່ຽວກັບຖານຂໍ້ມູນ Yandex.

Vladislav Kuznetsov - ຖານຂໍ້ມູນ Yandex - ວິທີທີ່ພວກເຮົາຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດ

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

Semyon Checherinda - ການເຮັດທຸລະກໍາທີ່ແຈກຢາຍຢູ່ໃນ YDB

Semyon ແມ່ນນັກພັດທະນາໃນກຸ່ມແພລະຕະຟອມແຈກຢາຍຢູ່ Yandex, ເຮັດວຽກກ່ຽວກັບຄວາມເປັນໄປໄດ້ຂອງການນໍາໃຊ້ຫຼາຍຜູ້ເຊົ່າຂອງການຕິດຕັ້ງ YDB.

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

ຈະເປັນແນວໃດຕໍ່ໄປ?

ໂຄງການກອງປະຊຸມຍັງສືບຕໍ່ເຕັມໄປດ້ວຍບົດລາຍງານໃຫມ່. ໂດຍສະເພາະ, ພວກເຮົາຄາດວ່າບົດລາຍງານຈາກ Nikita Koval (ndkoval) ຈາກ JetBrains ແລະ Oleg Anastasyev (m0ຄິດ) ຈາກບໍລິສັດ Odnoklassniki. Nikita ເຮັດວຽກກ່ຽວກັບສູດການຄິດໄລ່ສໍາລັບ coroutines ໃນທີມງານ Kotlin, ແລະ Oleg ພັດທະນາສະຖາປັດຕະຍະກໍາແລະການແກ້ໄຂສໍາລັບລະບົບການໂຫຼດສູງໃນເວທີ Odnoklassniki. ນອກຈາກນັ້ນ, ຍັງມີອີກ 1 ຊ່ອງຫວ່າງທີ່ມີເງື່ອນໄຂ, ຄະນະກໍາມະການໂຄງການກໍາລັງເຮັດວຽກກັບຜູ້ສະຫມັກສໍາລັບມັນໃນປັດຈຸບັນ.

ກອງປະຊຸມ Hydra ຈະຈັດຂຶ້ນໃນວັນທີ 11-12 ກໍລະກົດທີ່ St. ປີ້ມີໃຫ້ ຊື້ຢູ່ໃນເວັບໄຊທ໌ທາງການ. ກະ​ລຸ​ນາ​ໃສ່​ໃຈ​ກັບ​ການ​ມີ​ຂອງ​ປີ້​ອອນ​ໄລ​ນ​໌ - ຖ້າ​ຫາກ​ວ່າ​ສໍາ​ລັບ​ເຫດ​ຜົນ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ບໍ່​ສາ​ມາດ​ໄປ St. Petersburg ໃນ​ມື້​ນີ້​.

ແລ້ວພົບກັນທີ່ Hydra!

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