دفتر الحسابات9 دقائق قراءة

التسوية الحتمية: لماذا تفشل قواعد البيانات العامة على نطاق واسع

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

التسوية الحتمية: لماذا يهم زمن الاستجابة دون الميلي ثانية في التمويل

التحويل قيد التنفيذ هو رأس مال مقفل. رصيد المرسل مخصوم. رصيد المستلم لم يُضف بعد. تلك الفجوة، الفارق بين الالتزام والتوفر، هي أموال لا يمكن لأي طرف استخدامها.

عند الحجم المنخفض، التكلفة غير مرئية. عند 1,000 تحويل في الثانية بمتوسط وقت تسوية 200 ميلي ثانية، حوالي 200 تحويل قيد التنفيذ في أي لحظة. بمتوسط قيمة 500 يورو، هذا 100,000 يورو مقفلة بشكل دائم في العبور. زد زمن التسوية إلى ثانيتين ويرتفع رأس المال المقفل إلى 1,000,000 يورو. تكلفة البنية التحتية للخوادم هي خطأ تقريب مقارنة بتكلفة رأس مال زمن الاستجابة.

تحتفظ البنوك باحتياطيات رأسمالية لهذا السبب بالضبط. الاحتياطي يغطي نافذة عدم اليقين: الفترة بين "التزمنا بالإرسال" و"أكدنا الوصول." قلّص النافذة، قلّص الاحتياطي. العلاقة مباشرة.

لماذا تصطدم قواعد البيانات العامة بجدار

البنية الافتراضية لدفتر حسابات مالي: PostgreSQL (أو MySQL، أو أي قاعدة بيانات علائقية)، جدول transactions، ومنطق على مستوى التطبيق لتحديث الأرصدة. لأول 10,000 حساب و100 معاملة في الثانية، يعمل هذا دون حوادث.

يظهر السقف عندما تصبح الحسابات "ساخنة." حساب تحصيل رسوم تمسه كل معاملة. حساب تسوية يجمع جميع المدفوعات الصادرة. حساب إيرادات المنصة الذي يستقبل كل تقسيم عمولة. هذه الحسابات يصل إليها نسبة غير متناسبة من التحويلات، وكل وصول يتنافس على نفس قفل الصف.

يُسلسل PostgreSQL الكتابات لنفس الصف. تحت عزل SERIALIZABLE (المستوى الوحيد الذي يمنع جميع الشذوذات في أحمال العمل المالية)، يضيف اكتشاف التعارض عبئًا إضافيًا. عندما تمس معاملتان متزامنتان نفس الحساب، واحدة تفوز وواحدة تعيد المحاولة. تحت الحمل، تتتالى إعادات المحاولة. تتدهور الإنتاجية بشكل غير خطي.

يحدد قانون أمدال السقف. إذا كان 5% من حمل عملك مُسلسلًا، لأن 5% من التحويلات تمس حسابًا ساخنًا، فإن أقصى تسريع نظري من التوازي هو 20 ضعفًا. أضف المزيد من الأنوية، المزيد من الاتصالات، المزيد من النسخ: السقف لا يتحرك. إنه خاصية لحمل العمل، وليس للعتاد.

الحلول البديلة مألوفة:

التجزئة، تقسيم مساحة الحسابات عبر قواعد بيانات. لكن التحويلات عبر الأجزاء (المرسل على الجزء A، المستلم على الجزء B) تتطلب معاملات موزعة. الالتزام ثنائي المرحلة بطيء ومعقد. استبدلت تنافس الأقفال بعبء التنسيق.
الاتساق النهائي، تخفيف مستوى العزل، قبول أن الأرصدة قد تكون غير دقيقة مؤقتًا، المطابقة لاحقًا. في التمويل، "غير دقيق مؤقتًا" يعني "العميل يرى رصيدًا خاطئًا." غير مقبول لأي نظام يعرض الأرصدة في الوقت الفعلي.
القفل على مستوى التطبيق، استخدام Redis أو أقفال استشارية لتسلسل الوصول خارج قاعدة البيانات. الآن لديك نظامان للحفاظ على اتساقهما، وضعا فشل للتعامل معهما، ومدير أقفال يصبح نقطة تنافس خاصة به.

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

ما يفعله المحرك المصمم خصيصًا بشكل مختلف

محرك تسوية مصمم لأحمال العمل المالية يتخذ ثلاثة خيارات معمارية لا تستطيع قاعدة البيانات العامة اتخاذها:

سجلات بحجم ثابت. كل حساب بالضبط 128 بايت. كل تحويل بالضبط 128 بايت. محاذاة لخط التخزين المؤقت. لا حقول متغيرة الطول، لا جداول TOAST، لا صفحات فائضة. يمكن للمعالج التنبؤ بأنماط الوصول للذاكرة، ويمكن لمحرك التخزين حساب موقع أي سجل بالحساب. لا حاجة لبحث في الفهرس.

المعالجة الدفعية. بدلًا من الحصول على قفل وتحريره لكل تحويل، يجمع المحرك التحويلات في دفعات، حتى 8,190 عملية لكل دفعة، ويعالجها في تمريرة واحدة. تنافس الأقفال غير ذي صلة لأنه لا توجد أقفال. الدفعة هي وحدة العمل. جميع التحويلات في الدفعة تُطبق ذريًا.

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

صفر تخصيص، صفر جمع قمامة. كل الذاكرة تُخصص ثابتًا عند بدء التشغيل. لا يعمل جامع قمامة أثناء التشغيل. لا دورات malloc/free. لا تجزئة بمرور الوقت. زمن الاستجابة حتمي: وقت معالجة الدفعة هو دالة لحجم الدفعة، وليس لحالة الكومة.

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

الخاصية	قاعدة بيانات عامة	محرك مصمم خصيصًا
الوصول للسجل	بحث في الفهرس (تجاوز B-tree)	حسابي (حساب الإزاحة)
نموذج التزامن	أقفال مستوى الصف، اكتشاف التعارض	معالجة دفعية، لا أقفال
الإنتاجية تحت التنافس	تتدهور بشكل غير خطي	تتحسن مع دفعات أكمل
إدارة الذاكرة	تخصيص ديناميكي + جمع قمامة أو تحرير يدوي	تخصيص ثابت، صفر جمع قمامة
زمن الذيل (p99)	غير متوقع (جمع قمامة، انتظار أقفال، vacuum)	حتمي
فرض الثوابت	كود التطبيق أو المشغلات	مستوى المحرك (البروتوكول يرفض التحويلات غير الصالحة)

ما تمكّنه التسوية الحتمية

التسوية دون الميلي ثانية ليست مقياسًا تجميليًا. تمكّن أربع قدرات تشغيلية:

رؤية الرصيد في الوقت الفعلي. التحويلات الداخلية تُسوَّى فوريًا. لا حالة "معلق" للحركات داخل المنصة. الرصيد الذي يراه العميل هو الرصيد الذي يملكه. هذا يلغي فئة كاملة من تذاكر الدعم ("لماذا رصيدي خاطئ؟") ويزيل الحاجة للتمييز بين "الرصيد المتاح" و"رصيد دفتر الحسابات" للتدفقات الداخلية.

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

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

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

مشكلة ادعاءات الأداء

معظم بائعي البنوك الأساسية ينشرون أرقام إنتاجية. "50,000 معاملة في الثانية." "100,000 حساب في الثانية." هذه الأرقام نادرًا ما تكون ذات معنى بدون سياق.

أسئلة مهمة:

أي نوع من المعاملات؟ استعلام رصيد ليس تسوية. القراءة ليست كتابة. "معاملة في الثانية" دون تحديد العملية بلا معنى.
أي توزيع حسابات؟ 1,000 معاملة في الثانية ضد مليون حساب موزع بالتساوي أمر تافه. 1,000 معاملة في الثانية ضد 100 حساب بتوزيع Zipfian (حسابات ساخنة) هو حمل عمل مختلف تمامًا.
أي نموذج اتساق؟ "50,000 معاملة في الثانية" تحت READ COMMITTED رقم مختلف عنه تحت SERIALIZABLE. أحمال العمل المالية تتطلب أقوى عزل. اذكر الرقم عند ذلك المستوى.
أي مئوي؟ زمن p50 يخبرك بالحالة النموذجية. p99 يخبرك بأسوأ حالة 1 من 100. p100 يخبرك بأسوأ حالة فعلية. للتسوية المالية، p99 و p100 هما ما يهم. نظام سريع 99% من الوقت ويتوقف لثانيتين في الطلب المائة ليس حتميًا.

تنشر Thought Machine (بائع بنوك أساسية) تقارير أداء معتمدة برحلات اختبار محددة، وأحجام بيانات محملة مسبقًا، وبنية تحتية موثقة، وتحقق مستقل. هذا هو المعيار الذي يجب أن تتبناه الصناعة: ادعاءات مؤهلة بمنهجية قابلة للتكرار.

النهج الصادق: انشر منهجية اختبارك بجانب أرقامك. صف حمل العمل. سمِّ مستوى العزل. أظهر توزيع المئويات. دع المهندسين يقيّمون الادعاء مقابل ملف حمل عملهم. أرقام الأداء غير المؤهلة هي تسويق. بيانات الأداء المؤهلة هي هندسة.

المصادر:

Amdahl, Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967.
Jim Gray, "A Measure of Transaction Processing Power" (1985), معيار TPC debit/credit
Thought Machine, "Vault Core Performance", منهجية معيار معتمدة بتحقق مستقل
"Gray Failure: The Achilles' Heel of Cloud-Scale Systems" (Microsoft Research, 2017), تدهور العتاد الصامت