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, ແລະເຄື່ອງມືທີ່ຄ້າຍຄືກັນສໍາລັບ Linux kernel. ປະກອບສ່ວນເຂົ້າໃນ Go ເປັນຕົວກໍານົດເວລາ goroutine ທີ່ສາມາດປັບຂະ ໜາດ ໄດ້, ນັກສຳຫຼວດເຄືອຂ່າຍ, ແລະຕົວເກັບຂີ້ເຫຍື້ອຂະໜານ. ລາວເປັນຜູ້ຊ່ຽວຊານໃນ multithreading, ຜູ້ຂຽນຂອງ algorithms ທີ່ບໍ່ມີການຂັດຂວາງໃຫມ່ແລະເປັນເຈົ້າຂອງ. ສາຍແອວດຳ 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