السبب الحقيقي الذي يجعل Fogo متميزًا
أولّي اهتمامًا بـ Fogo لسبب لا علاقة له بلقطات شاشة TPS أو مقارنات لوحات الصدارة. ما يثير اهتمامي هو كيف أن طبقة 1 المعتمدة على SVM تجبر المطورين على النضوج بهدوء. عندما تبني على هذا النموذج التنفيذي، فأنت لا تحصل فقط على السرعة. أنت تدخل في بيئة يتم فيها مكافأة تصميم الحالة الجيد وكشف الهندسة المعمارية السيئة على الفور.
تصبح السرعة حقيقية عندما تكون التطبيقات مهمة
تتكون Fogo حول فكرة بسيطة. إذا كانت وقت التشغيل سريعًا حقًا وقادرة على معالجة المعاملات المستقلة في نفس الوقت، فإن التطبيق يصبح هو عنق الزجاجة. هنا تبدأ الأمور في أن تصبح حقيقية. لا يسأل SVM عما إذا كانت ادعاءاتك التسويقية تبدو جيدة. إنه يسأل عما إذا كانت معاملاتك مستقلة فعليًا عندما يصل المستخدمون الحقيقيون.
لماذا لا يكون التنفيذ المتوازي بسيطًا
يبدو التنفيذ المتوازي سهلًا نظريًا. تعمل المعاملات معًا. تزداد السعة. تشعر أن كل شيء سلس. في الواقع، لا ينجح إلا عندما لا تتصارع المعاملات على نفس الحالة. على سلسلة SVM، الحالة واضحة. يجب أن تُعلن كل معاملة ما تقرؤه وما تكتبه. إذا تداخلت هذه الإعلانات، لا يستطيع وقت التشغيل تنفيذها بأمان على التوازي. عليه أن يُسلسلها.
تصميمك أنت يمكنه أن يحد من السرعة
هذا يعني أن السلسلة لا يمكنها إخفاء الخيارات التصميمية السيئة. إذا رتبت تطبيقك بحيث يكتب كل إجراء إلى نفس الحساب المشترك، فقد أنشأت اختناقًا مروريًا داخل نظام صُمم لعدة حارات.
الأداء يعيش في طبقة التطبيق
هذه هي النقطة التي يفوتها الناس. يتحدثون عن الأداء كما لو كان موجودًا بالكامل في طبقة السلسلة. على Fogo، يصبح الأداء مسؤولية على مستوى التطبيق. يمكن لتطبيقين الجلوس على نفس السلسلة. يبقى أحدهما سلسًا تحت الحمل. الآخر يشعر أنه عالق. الفرق ليس وقت التشغيل. بل طريقة تقسيم الحالة.
العادات المتسلسلة يمكن أن تقتل التوازي
غالبًا ما يحمل المطورون القادمون من الأنظمة المتسلسلة عادات تبدو آمنة. وأكثر ما هو شائع: الحفاظ على كائن حالة مركزي واحد يقوم كل إجراء بتحديثه. يبدو ذلك نظيفًا. يبدو منظمًا. يمنحك مصدر حقيقة واحد. على سلسلة SVM، تصبح نفس هذه الأنماط آلية كبح صامتة. الآن كل مستخدم يتنافس على الكتابة إلى المكان نفسه. وقت التشغيل جاهز للتوازي، لكن التطبيق يجبر كل شيء في مسار واحد.
تخطيط الحالة كسياسة للتوازي
في Fogo، يصبح تخطيط الحالة سياسة للتوازي. كل حساب قابل للكتابة يتصرف كأنه قفل. إذا اعتمد عدد كبير جدًا من التدفقات على نفس القفل، فإنك تُفشل التوازي حتى عندما لا تكون الشبكة مزدحمة. لا يأتي التباطؤ من السلسلة. بل يأتي من بنيتك المعمارية أنت.
اعتبر الحالة القابلة للكتابة كقرارات
النموذج الذهني الأفضل هو هذا: كل جزء من الحالة القابلة للكتابة يحدد من يمكنه التحرك في نفس الوقت. ليس الهدف إلغاء الحالة المشتركة بالكامل. بعض البيانات المشتركة ضرورية. الهدف هو الانضباط. افصل ما يجب مشاركته عمّا تمت مشاركته فقط من أجل الراحة. الراحة غالبًا هي المكان الذي يموت فيه التنفيذ المتوازي.
أنماط تحافظ على التطبيقات سريعة
الأنماط التي تجعل التطبيقات سريعة على Fogo ليست مبهرجة. إنها صارمة.
افصل حالة المستخدمين بشدة
عزل الحالة الخاصة بكل سوق بدلًا من تمرير كل شيء عبر كائن عالمي واحد
تجنّب الكتابة إلى حسابات مشتركة فقط لتحديث المقاييس أو بيانات الرؤية
غالبًا يمكن حساب القيم المشتقة من الأحداث بدلًا من تعديلها داخل كل معاملة.
تصاميم متوازية ناجحة
انظر إلى التصميمات التي تتعامل مع الضغط جيدًا.
إجراءات المستخدم غالبًا محلية
يحدّث المستخدم حالته الخاصة وجزءًا ضيقًا من الحالة المشتركة التي يلزمها فعلًا
تُبنى المكوّنات المشتركة بحيث لا يتصادم المستخدمون غير المرتبطين ببعضهم
إن فصل الحالة لكل مستخدم ليس مجرد ترتيب أنيق. إنه استراتيجية لزيادة الإنتاجية. إن فصل الحالة لكل سوق يمنع سوقًا حارًا واحدًا من سحب كل شيء آخر إلى الأسفل.
مصائد التقارير العالمية
الفخ الخفي هو التقارير العالمية. يحب المطورون عدّادات عالمية فورية.
إجمالي الحجم
الرسوم العالمية
متتبعات النشاط
لوحات الصدارة
المقاييس نفسها جيدة. تظهر المشكلة عندما تُحدّث كل معاملة تلك الحسابات العالمية. الآن كل مسار يتضمن كتابة مشتركة. تتكاثر التعارضات. لقد بنيت نظامًا متسلسلًا داخل وقت تشغيل متوازٍ. مهما كانت سرعة Fogo، فإن تصميمك يُجبرها على التصرف بشكل متسلسل.
فصل صحة التنفيذ عن التقارير
يدفع التنفيذ المتوازي البنّائين إلى فصل الصحة عن التقارير.
تحدث تغييرات الحالة الحرجة في مكان واحد
يمكن للتقارير أن تُحدَّث بإيقاع مختلف، أو تُقسَّم (sharded)، أو تُشتق من السجلات
بمجرد أن تتوقف عن إجبار كل معاملة على تعديل حساب التقارير نفسه، يصبح التوازي الحقيقي ممكنًا.
التداول والأنظمة التفاعلية
تُبرز أنظمة التداول هذه النقطة.
التداول يركز النشاط
التركيز يولّد تنازعًا
حساب دفتر أوامر مركزي واحد يُسلسل كل العمليات
تجعل بيئات التداول عالي التردد العيوب مستحيلة الإخفاء. كل حساب قابل للكتابة ومشترك يصبح ساحة معركة. بدلًا من أن تتقدم التدفقات المستقلة بشكل متوازٍ، ينتظر الجميع خلف نفس القفل. يتدهور الأداء، ويتغير سلوك السوق لأن التنازع يهيمن على الترتيب.
تطبيقات ثقيلة بالبيانات
القراءات نادرًا ما تكون المشكلة
الكتابات هي المشكلة
تجنب تحديث الكاشات المشتركة أو طباعة القيم في حسابات عالمية لأجل الراحة
احصر عمليات الكتابة المشتركة داخل تدفقات مخصصة
تكلفة البنية المعمارية المتوازية
لا شيء من هذا مجاني. يتطلب بناء معماري مناسبًا للتوازي:
مكوّنات أكثر
اختبارات أكثر دقة
ملاحظة أفضل
أنت تبني توازيًا حقيقيًا، وليس توازيًا نظريًا. لكن الجائزة هي قابلية التوسع التي تطابق ما تم تصميمه ليقدمه وقت تشغيل SVM.
أغلى خطأ
أكثر خطأ مُضرّ هو خطأ بسيط. حساب واحد قابل للكتابة ومشترك بين الجميع تلامسه كل معاملة. على سلسلة مثل Fogo، يصبح هذا الخطأ واضحًا بسرعة. كلما كانت السلسلة أسرع، صار واضحًا أكثر أن تصميمك هو القيد.
يجعل Fogo الحديث صادقًا
ما يفعله Fogo هو جعل حديث المطورين صادقًا.
ليس كافيًا أن تقول إن السلسلة سريعة
نموذج التنفيذ يتطلب من المطورين تصميمًا من أجل الاستقلالية
قسّم الحالة بذكاء
عامل الحالة كأنها سطح للتوازي
الخلاصة: الانضباط بدلًا من التسويق
التنفيذ المتوازي ليس ميزة تسويقية. إنه انضباط. على SVM Layer 1 مثل Fogo، يُفرض هذا الانضباط عبر التصميم.