"الأدوات ليست بنفس أهمية القدرة على التفكير في الأنظمة التي تنشئها." مقابلة رائعة مع مارتن كليبمان

مارتن كليبمان باحث في جامعة كامبريدج يعمل على CRDT والتحقق الرسمي من الخوارزميات. أصبح كتابه " تصميم تطبيقات كثيفة البيانات" ، الذي نُشر عام 2017 ، أكثر الكتب مبيعًا في تخزين ومعالجة البيانات.

قال كيفن سكوت (CTO في Microsoft) ذات مرة: "يجب أن يكون هذا الكتاب ضروريًا لمهندسي التطوير. "هذا مورد نادر يجمع بين النظرية والتطبيق ، مما يساعد المطورين على التفكير بشكل أعمق في تصميم وتنفيذ البنية التحتية وأنظمة معالجة البيانات." قال شي كريب شيئًا مماثلاً ، خالق أباتشي كافكا والرئيس التنفيذي لشركة كونفلوينت.

قبل بدء البحث الأكاديمي ، عمل مارتن في الصناعة وشارك في تأسيس شركتين ناشبتين ناجحتين: Rapportive (اشترتها شركة LinkedIn في عام 2012) و Go Test It (اشترتها شركة RedGate).

هذا habrapost هو مقابلة مفصلة مع مارتن. نماذج موضوعات المناقشة:

• الانتقال من الأعمال إلى البحث الأكاديمي ؛
  
• المتطلبات الأساسية لكتابة تطبيقات تصميم البيانات المكثفة ؛
  
• الحس السليم ضد الضجيج الاصطناعي وأدوات الدعاية ؛
  
• عدم ضرورة نظرية CAP وأخطاء الصناعة الأخرى ؛
  
• فائدة اللامركزية ؛
  
• Block Block ، Dat ، IPFS ، Filecoin ، WebRTC ؛
  
• CRDT جديد. التحقق الرسمي في إيزابيل ؛
  
• مناقشة حول مصادر الحدث. نهج مستوى منخفض. معاملات XA
  
• Apache Kafka، PostgreSQL، Memcached، Redis، Elasticsearch؛
  
• استخدام كل شيء في الحياة الحقيقية ؛
  
• عتبة إدخال تقارير مارتن ومؤتمر هيدرا.
  

أجرى المقابلة فاديم تسيسكو ( incubos ) - وهو مطور رائد في فريق شركة Odnoklassniki Platform. تتعلق اهتمامات Vadim العلمية والهندسية بالأنظمة الموزعة ومستودعات البيانات ، بالإضافة إلى التحقق من أنظمة البرمجيات.

من العمل إلى البحث الأكاديمي

فاديم : أود أن أبدأ بسؤال مهم للغاية بالنسبة لي شخصياً. لقد أسست Go Test It and Rapportive ، ولفترة طويلة شاركت في تطوير أنظمة كبيرة على LinkedIn ، لكنك قررت بعد ذلك ترك التطوير التجاري وإجراء البحوث في الجامعة. هل يمكن أن تخبرني ما الذي دفعك إلى هذا؟ ما هي فوائد العمل في الجامعة وما الذي ضحت به؟

مارتن : لقد كان انتقال مثير للغاية. كما أفهمها ، أنت مهتم بقراري نظرًا لحقيقة أن عددًا لا بأس به من الناس يغادرون للبحث الأكاديمي من التطوير التجاري ، وغالبًا ما توجد حركة في الاتجاه المعاكس. هذا أمر مفهوم ، نظرًا لأن الأرباح في الجامعات أقل بكثير من الأرباح في الأعمال التجارية. أنا شخصياً منجذبة إلى منصب باحث من خلال حقيقة أنني أستطيع أن أقرر بنفسي الموضوعات التي يجب العمل عليها ، وأقوم بهذا الاختيار على أساس ما يبدو أنه مهم ومهم بالنسبة لي ، حتى إذا كان العمل على موضوع ما لا يعد بجني ربح خلال الستة أيام القادمة أشهر. يجب بيع كل شيء تعمل فيه في شركة بشكل أو بآخر. في الوقت الحالي ، أعمل على مواضيع مهمة لمستقبل الإنترنت والبرامج ، لكن فهمنا لها لم يتعمق بعد بما يكفي لإنشاء منتج نهائي. حتى الآن ، ليس لدينا حتى فكرة عامة عن كيفية عمل هذه التقنيات. نظرًا لأن هذه الدراسات أساسية ، فقد قررت أنه من الأفضل إجراءها في الجامعة وليس في الشركة: تتمتع الجامعة بمزيد من الحرية ، حيث يمكنك القيام بأشياء لن تحقق أي ربح لمدة 10 سنوات أخرى. أفق التخطيط أوسع بكثير.

كتاب تصميم تطبيقات البيانات المكثفة

فاديم : سنعود بالتأكيد إلى موضوع البحث ، ولكن الآن دعنا نتحدث عن كتابك ، تصميم تطبيقات مكثفة للبيانات . في رأيي ، هذا أحد أفضل الأدلة على الأنظمة الموزعة الحديثة ، ويكاد يكون موسوعة: إنه يسرد جميع الإنجازات الأكثر أهمية التي توجد اليوم.

مارتن : شكرا لك ، أنا سعيد لأنه جاء في متناول يدي.

فاديم : من غير المرجح أن يكون قراءنا على دراية به حتى الآن ، ولكن فقط في الحالة المناسبة ، فلنناقش أهم الإنجازات في مجال النظم الموزعة التي تكتب عنها.

مارتن : في الواقع ، عند كتابة هذا الكتاب ، لم أضع هدفًا لوصف بعض التقنيات. بدلاً من ذلك ، أردت أن أقدم دليلًا حول العالم للأنظمة المستخدمة لتخزين ومعالجة البيانات. يوجد الآن عدد كبير من قواعد البيانات ، ومعالجات الدفق ، وأدوات معالجة الدُفعات ، وجميع أنواع أدوات النسخ المتماثل وما شابه ، لذلك يصعب تكوين صورة شاملة لهذه المنطقة. وإذا كنت بحاجة إلى قاعدة بيانات لحل مشكلة معينة ، فمن الصعب اختيار واحدة من العديد منها. العديد من الكتب المكتوبة حول مثل هذه الأنظمة هي ببساطة عديمة الفائدة في هذه الحالة. على سبيل المثال ، في كتاب عن Apache Cassandra ، قد يكون مكتوبًا عن مدى روعة Cassandra ، لكن لن يتم قول أي شيء عن المهام التي لا تناسبها. لذلك ، في كتابي ، أحاول تحديد الأسئلة الأساسية التي تحتاج إلى طرحها على نفسك عند كتابة أنظمة كبيرة. ستساعد الإجابات على هذه الأسئلة على تحديد التقنيات المناسبة لحل المشكلة الحالية وأيها غير جيدة. الشيء الرئيسي هو أنه لا توجد تقنية يمكنها القيام بكل شيء. أحاول إظهار مزايا وعيوب التقنيات المختلفة في سياقات مختلفة.

فاديم : في الواقع ، العديد من التقنيات لها ميزات ووظائف مشتركة وتوفر نفس نموذج البيانات. في الوقت نفسه ، لا يمكن للمرء أن يثق في الإعلان ، ولكي يفهم الهيكل الداخلي للنظام ، لا يجب على المرء أن يقرأ التقارير الفنية والوثائق فحسب ، بل حتى أكواد المصدر.

الحس السليم مقابل الضجيج الاصطناعي والإعلان أداة

مارتن : علاوة على ذلك ، يجب عليك في كثير من الأحيان أن تقرأ بين السطور ، لأن الوثائق لا تحدد المهام التي لا تكون قاعدة البيانات مناسبة لها. في الواقع ، فإن أي قاعدة بيانات لها قيودها الخاصة ، لذلك يجب أن تعرف دائما أي منها. غالبًا ما يتعين عليك قراءة أدلة النشر وإعادة تشغيل العملية الداخلية للنظام.

فاديم : نعم ، هذا مثال رائع. لا تظن أنه في هذا المجال لا يوجد ما يكفي من المفردات المشتركة أو مجموعة واحدة من المعايير ، والتي يمكن من خلالها مقارنة الحلول المختلفة لمشكلة واحدة؟ الآن يتم استخدام أسماء مختلفة لنفس الأشياء ، والعديد من الجوانب التي يجب توضيحها بوضوح وبشكل واضح لم يتم ذكرها على الإطلاق - على سبيل المثال ، ضمانات المعاملة.

مارتن : نعم ، إنه حقا. لسوء الحظ ، يوجد في صناعتنا في كثير من الأحيان إثارة مفرطة حول الأدوات المختلفة. وهذا أمر مفهوم ، حيث يتم إنشاء هذه الأدوات من قبل الشركات المهتمة بالترويج لمنتجاتها. لذلك ، ترسل هذه الشركات أشخاصًا إلى المؤتمرات ، وهم يتحدثون ، في جوهرها ، عن ماهية هذه المنتجات الرائعة. هذا يتنكر كتقارير فنية ، لكنه في جوهره إعلان. لن يؤذينا كصناعة أن نكون أكثر صدقًا بشأن مزايا وعيوب منتجاتنا. أحد المصطلحات اللازمة لهذا المصطلح هو المصطلحات العامة ؛ وبدون ذلك ، يستحيل مقارنة الأشياء. ولكن إلى جانب ذلك ، هناك حاجة إلى طرق لتحليل مزايا وعيوب مختلف التقنيات.

لا لزوم لها النظريات CAP والأخطاء الصناعة الأخرى

فاديم : سؤالي التالي حساس للغاية. هل يمكن أن تخبرنا عن أي أخطاء شائعة في صناعتنا واجهتها خلال حياتك المهنية؟ على سبيل المثال ، حول بعض التقنيات المفرطة أو الحل المستخدم على نطاق واسع والذي يجب أن تتخلص منه منذ فترة طويلة؟ قد لا يكون هذا أفضل مثال ، ولكن يتبادر إلى ذهني استخدام JSON عبر HTTP / 1.1 بدلاً من gRPC عبر HTTP / 2. أو ربما كنت لا نشارك وجهة النظر هذه؟

مارتن : في أغلب الأحيان ، عند إنشاء الأنظمة ، من أجل تحقيق شيء واحد ، تحتاج إلى التضحية بشيء آخر ، وهنا أفضل عدم الحديث عن الأخطاء. في حالة الاختيار بين JSON عبر HTTP / 1.1 ، على سبيل المثال ، مخازن البروتوكول على HTTP / 2 ، يكون لكلا الخيارين الحق في الوجود. إذا قررت استخدام Protocol Buffers ، فأنت بحاجة إلى تحديد مخطط ، وقد يكون ذلك مفيدًا للغاية ، لأنه يساعد في تحديد سلوك النظام بدقة. لكن في بعض الحالات ، لا يسبب هذا المخطط أي شيء سوى الإزعاج ، خاصة في المراحل الأولى من التطوير ، عندما تتغير تنسيقات البيانات في كثير من الأحيان. مرة أخرى ، من أجل تحقيق هدف معين ، يجب على المرء التضحية بشيء ما ، وفي بعض الحالات يكون هذا مبررًا ، لكن في حالات أخرى ، لا يكون ذلك. لا توجد الكثير من الحلول التي يمكن أن تسمى خطأ. ولكن بما أننا نتحدث عن هذا ، فلنتحدث عن نظرية CAP - في رأيي ، لا يوجد أي فائدة على الإطلاق. عندما يتم استخدامه في تصميم النظم ، إما أن يكون هناك سوء فهم لمعنى نظرية CAP ، أو أن البيانات البديهية مثبتة بمساعدة ذلك. يستخدم نموذجًا محددًا للغاية من الاتساق - الخطية ، ونموذجًا محددًا للغاية لإمكانية الوصول - يجب أن تكون كل نسخة طبق الأصل قابلة للوصول بشكل كامل ، حتى إذا لم تتمكن من تأسيس اتصال مع أي نسخة متماثلة أخرى. من ناحية ، هذه التعريفات صحيحة تمامًا ، لكنها ، من ناحية أخرى ، ضيقة للغاية: العديد من التطبيقات لا تحتاج ببساطة إلى مثل هذا التعريف للتناسق أو إمكانية الوصول. وإذا كان التطبيق يستخدم تعريفا مختلفا لهذه الكلمات ، فإن نظرية CAP غير مجدية بالنسبة له. لذلك لا أرى فائدة كبيرة في تطبيقه. بالمناسبة ، منذ أن بدأنا الحديث عن الأخطاء في صناعتنا ، دعونا نعترف بصدق أن تعدين العملة المشفرة هو مضيعة كاملة للكهرباء. لا أفهم كيف يمكنك فعل ذلك بجدية.

فاديم : بالإضافة إلى ذلك ، أصبحت معظم تقنيات التخزين قابلة للتخصيص الآن لمهمة محددة ، أي يمكنك تحديد الوضع المناسب للعملية في وجود حالات فشل.

مارتن : هذا صحيح. علاوة على ذلك ، لا يندرج جزء كبير من التقنيات ضمن التعريف الصارم للتناسق وإمكانية الوصول إلى نظرية CAP ، أي أنها ليست CP ، وليس AP ولا CA ، ولكن فقط P. لا أحد سيكتب عن هذا البرنامج مباشرةً ، ولكن في الواقع يمكن كن استراتيجية تنمية عقلانية تمامًا. هذا أحد الأسباب التي تجعلني أؤمن بأن CAP عند تحليل البرامج أكثر ضررًا من النفع: جزء كبير من قرارات التصميم لا يتم تقديمه بأي شكل من الأشكال ، ويمكن أن يكون حلولًا عقلانية تمامًا ، لكن CAP لا يسمح بوصفهم.

فوائد اللامركزية

فاديم : ما هي أكثر المشاكل حدة في تطوير تطبيقات البيانات المكثفة الآن؟ ما هي المواضيع التي يتم استكشافها بنشاط أكبر؟ بقدر ما أعرف ، فأنت مؤيد لتخزين البيانات اللامركزية وتخزين البيانات.

مارتن : نعم. إحدى النقاط التي أثبتتها في بحثي هي أننا نعتمد حاليًا بشكل كبير على الخوادم والمركزية. في الأيام الأولى للإنترنت ، عندما تطورت من ARPANET ، تم تصميمها كشبكة مستقرة للغاية حيث يمكن إرسال الحزم عبر طرق مختلفة ، وما زالت تحقق هدفها. في حالة حدوث انفجار نووي في أي مدينة في أمريكا ، سيستمر الجزء الباقي من الشبكة في العمل ، وسيتم ببساطة استخدام طرق بديلة لتجاوز الأجزاء الفاشلة. لقد كان مخططًا ولدته الحرب الباردة. لكن بعد ذلك قررنا وضع كل شيء في السحابة ، لذلك الآن كل شيء تقريباً يمر بطريقة أو بأخرى عبر أحد مراكز AWS في مكان ما في فرجينيا ، في شرق الولايات المتحدة. في مرحلة ما ، تخلينا عن المثل الأعلى للاستخدام اللامركزي لمختلف أجزاء الشبكة وحددنا الخدمات التي يعتمد عليها كل شيء الآن. أنا أعتبر أنه من المهم العودة إلى نهج لامركزي ، حيث ينتمي المزيد من التحكم في البيانات ليس إلى الخدمات ، ولكن إلى المستخدمين النهائيين.

عندما يتعلق الأمر باللامركزية ، فإنها في كثير من الأحيان تعني أشياء مثل العملات المشفرة ، لأن لديهم شبكات من الوكلاء المتفاعلين التي لا توجد فيها سلطة مركزية واحدة مثل البنك. ولكن هذا ليس هو اللامركزية التي أتحدث عنها ، لأنه ، في رأيي ، العملات المشفرة هي أيضًا مركزية للغاية: إذا كنت بحاجة إلى إكمال صفقة مع Bitcoin ، فيجب أن يتم ذلك من خلال شبكة Bitcoin ، لذلك كل شيء مركزي حول هذه الشبكة. بنية الشبكة غير مركزية بمعنى أنها لا تحتوي على مركز تنظيم واحد ، ولكن الشبكة ككل مركزية للغاية ، حيث يجب أن تتم كل معاملة من خلال هذه الشبكة ولا شيء آخر. وأعتقد أن هذا هو أيضا شكل من أشكال المركزية. في حالة العملات المشفرة ، هذا أمر لا مفر منه ، لأنه من الضروري ضمان عدم وجود تكاليف مزدوجة ، وهذا أمر صعب التحقيق دون وجود شبكة توفر إجماعًا على المعاملات التي تم إنجازها وما شابه. ولكن هناك العديد من التطبيقات التي لا تتطلب نظامًا مثل blockchain ؛ يمكن أن تعمل مع نموذج بيانات أكثر مرونة. هذه الأنظمة اللامركزية هي التي تهمني أكثر.

فاديم : منذ أن ذكرت بلوكشين ، هل يمكن أن تخبرنا عن التقنيات الواعدة أو غير المعروفة في مجال الأنظمة اللامركزية؟ لعبت بنفسي مع IPFS ، لكن لديك خبرة أكثر في هذا المجال.

مارتن : في الواقع ، أنا لا أتابع بنشاط مثل هذه التقنيات. قرأت قليلاً عن IPFS ، لكنني لم استخدمها بنفسي. لقد عملنا قليلاً مع Dat ، والتي ، مثل IPFS ، هي تقنية تخزين لا مركزية. الفرق هو أن عملة التشفير في Filecoin مرتبطة بـ IPFS ، ويتم استخدامها لدفع تكاليف تخزين البيانات ، وليس هناك أي blockchain مرتبط بـ Dat. يسمح لك Dat فقط بتكرار البيانات إلى أجهزة متعددة على أساس P2P ، وبالنسبة للمشروع الذي كنا نعمل عليه ، تعد Dat رائعة. لقد كتبنا برنامجًا يتيح للمستخدمين التعاون في مستند أو بيانات أو قاعدة بيانات ، ويتم إرسال كل تغيير في هذه البيانات إلى كل شخص لديه نسخة من البيانات. في مثل هذا النظام ، يمكن استخدام Dat وفقًا لمبدأ P2P ، بحيث يضمن التشغيل على مستوى الشبكة ، أي NAT Traversal ويمر بجدران الحماية ، وهي مهمة صعبة إلى حد ما. علاوة على ذلك ، كتبنا مستوى من CRDT ، وبمساعدة العديد من الأشخاص الذين يمكنهم تحرير مستند أو مجموعة بيانات والتي مكنت من مشاركة التعديلات بشكل سريع ومريح. أعتقد أنه يمكن كتابة نظام مشابه فوق IPFS ، مع تجاهل Filecoin واستخدام النسخ المتماثل P2P فقط.

فاديم : لكن مثل هذا النظام لن يصبح أقل استجابة ، لأن WebRTC يربط العقد مباشرة مع بعضها البعض ، و IPFS هو أكثر من جدول تجزئة موزع.

مارتن : الشيء ، WebRTC هو مستوى مكدس مختلف قليلاً. الغرض منه هو بشكل أساسي إجراء مكالمات الفيديو - مع وجود احتمال كبير يتم استخدامه في البرنامج الذي نتواصل من خلاله الآن. بالإضافة إلى ذلك ، يوفر WebRTC قناة يمكنك من خلالها إرسال بيانات ثنائية عشوائية. لكن إنشاء نظام نسخ متماثل أعلى منه قد يكون أمرًا صعبًا. ولكن في Dat و IPFS ، لا تحتاج إلى القيام بأي شيء من أجل هذا.

لقد ذكرت الاستجابة ، وهذا عامل مهم حقًا يجب مراعاته. لنفترض أننا نريد أن نجعل مستندات Google التالية لا مركزية. في مُحرر مستندات Google ، تعد وحدة التغيير بمثابة ضغطة مفتاح واحدة ، ويمكن إرسال كل شخصية جديدة في الوقت الفعلي إلى أشخاص آخرين يعملون مع نفس المستند. من ناحية ، يضمن هذا تعاونًا سريعًا ، من ناحية أخرى ، فهذا يعني أنه عند كتابة مستند كبير ، فأنت بحاجة إلى إرسال مئات الآلاف من التغييرات ذات الحرف الواحد ، والعديد من التقنيات الحالية تؤدي مهمة سيئة لضغط هذا النوع من البيانات. حتى لو افترضنا أنه من الضروري في كل ضغطة مفتاح إرسال مائة بايت فقط ، فمن الضروري عند إرسال مستند يحتوي على 100000 حرف إرسال 10 ميغابايت من البيانات ، على الرغم من أن هذا المستند لا يستغرق عادة أكثر من عدة عشرات من الكيلوبايت. حتى يتم اختراع طريقة ضغط بارعة ، تتطلب مزامنة البيانات هذه تكلفة إضافية هائلة من الموارد. ليس لدى العديد من أنظمة P2P طريقة فعالة لإنشاء لقطات للحالة تسمح لها باستخدام نظام مثل محرّر مستندات Google. هذه هي المشكلة التي أعمل عليها حاليًا ، وأحاول إنشاء خوارزمية لمزامنة المستندات بشكل أكثر فعالية لعدة مستخدمين. يجب أن تكون هذه خوارزمية لا تخزن كل ضغطة مفتاح ، لأن ذلك يتطلب موارد كثيرة ، ويجب أن يوفر استخدامًا أكثر كفاءة للشبكة.

CRDT جديدة ، تحقق رسمي في Isabelle

فاديم : هل يمكن أن تخبرنا المزيد عن هذا؟ هل تمكنت من تحقيق أكثر من 100x ضغط البيانات؟ هل تتحدث عن تقنيات ضغط جديدة أو CRDTs خاصة؟

مارتن : نعم. حتى الآن ، لدينا فقط نموذج أولي ؛ لم يتم تنفيذه بالكامل. يجب إجراء تجارب إضافية لمعرفة مدى فعاليتها في الممارسة العملية. ولكن بعض أساليبنا واعدة. في النموذج الأولي الخاص بي ، تمكنت من تقليل حجم تحرير واحد من 100 إلى 1.7 بايت. ولكن ، أكرر ، هذه ليست سوى نسخة تجريبية حتى الآن ، قد يتغير هذا المؤشر قليلاً. بطريقة أو بأخرى ، هناك فرص كبيرة للتحسين في هذا المجال.

فاديم : إذن سيكون تقريرك في مؤتمر هيدرا حول هذا الموضوع؟

مارتن : نعم. سيكون لدي مقدمة قصيرة حول CRDT وبرامج التعاون وبعض المشكلات التي تنشأ في هذا السياق. ثم سأتحدث عن الأبحاث التي نقوم بها في هذا المجال - فهي تتعامل مع العديد من المشكلات المختلفة. على جانب التطبيق ، لدينا تطبيق لهذه الخوارزميات في جافا سكريبت ، وبناءً عليه نقوم بإنشاء برامج فعالة لفهم سلوك الخوارزميات بشكل أفضل. في الوقت نفسه ، نعمل أيضًا على أساليب رسمية لإثبات صحة هذه الخوارزميات ، لأن بعضها غير واضح إلى حد ما ، ونريد أن نضمن وصولها دائمًا إلى حالة متسقة. لا توفر العديد من الخوارزميات التي تم تطويرها مسبقًا الاتساق في بعض حالات الشريط الحدودي. لتجنب ذلك ، تحولنا إلى طرق رسمية لإثبات صحة.

فاديم : هل تستخدم بروفات نظرية مثل Coq أو Isabelle لهذا النظام؟

مارتن : نعم ، إيزابيل .

ملاحظة المحررين: سوف يقرأ مارتن حديثًا عن إيزابيل في The Strange Loop.

فاديم : هل تخطط لنشر هذا الدليل؟

مارتن : نعم ، المجموعة الأولى من الأدلة التي نشرناها قبل عام ونصف ، مع إطار التحقق من CRDT. اختبرنا ثلاث CRDTs باستخدام هذا الإطار ، وأهمها RGA (صفيف قابل للنمو متكرر ) ، CRDT للنص المشترك في التحرير. هذه الخوارزمية ليست معقدة للغاية ، ولكنها غير واضحة إلى حد ما ، في رأي أنه ليس من الواضح على الفور ما إذا كانت صحيحة ، وبالتالي كان من الضروري وجود دليل رسمي. كما عملنا على إثبات صحة العديد من CRDTs الحالية ، وآخر شيء فعلناه في هذا المجال هو إنشاء CRDTs الخاصة بنا لنماذج البيانات الجديدة.

فاديم : كم هو حجم الدليل الرسمي أكثر من حجم رمز الخوارزمية نفسها؟ هناك في بعض الأحيان صعوبات مع هذا.

مارتن : حقا ما يكفي من الصعوبات ، علينا أن نعمل الكثير مع الأدلة. : 60 , , 800 . , 12 . , . , . , . . , .

: , ? ?

: , . , . : TCP, Git . , , . , . . , .

Event sourcing, , XA-

: , . , event sourcing. , - . event sourcing ? - , .

: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .

event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.

, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .

: . , , , , .

: , , JSON (, PostgreSQL ) . , . . , .

: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .

: , , , — ?

: . , , , , , 404, .

: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .

: , Multiversion Concurrency Control .

: , . XA-, , , . , , . , , . XA . , , . .

: , - .

: , . , , , . , . - , . , . - , : , , , . . , .

: , . , . - , , , - .

: . . , , . , .

: , . event sourcing. , , , . , . , , , . , , , , , . ?

: , . , , . , , , , . . , . , , .

: , , , .

: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .

: . .

: .

: , , . , — , . .

Hydra 2019,

: , Hydra? , , , .

: , , , , « » « ». . . , , - ; , , , , .

: , , , ? . , , ?

: , . , . , . - . , - , - . , . : , . — , — . , , , .

: . ? , - , , ?

: . . , . , , , . - — . , , . : . , , Slack , . , , . , , , .

: .

: , .

: , !

أذكركم بأن هذه مقابلة مسجلة مسبقًا. عندما تكتب تعليقات ، تذكر أن مارتن لن يقرأها. يمكننا فقط نقل شيء أكثر إثارة للاهتمام. إذا كنت ترغب حقًا في التحدث مع المؤلف ، فسيقدم عرضًا تقديميًا "مزامنة البيانات عبر أجهزة المستخدم للتعاون الموزع" في مؤتمر هيدرا 2019 ، الذي سيعقد يومي 11 و 12 يوليو 2019 في سان بطرسبرغ. يمكن شراء التذاكر على الموقع الرسمي .