مرحبا يا هبر!
وُلدت هذه الملاحظة الصغيرة أثناء مناقشة مقال
"Monoliths الموزعة ..." ، وبما أن الموضوع يحتاج إلى مزيد من التفكير ، فقد قررت نشره على مدونتي. يصف مؤلف المقالة بالفعل قاعدة بيانات موزعة ، مما يثبت أن سجل الأحداث هو بنية التخزين الصحيحة الوحيدة فيه. الوسائط هي كالتالي:
- نظرًا لأن الحدث دائمًا ما يكون في المكان / الزمان ، فيمكنه تخزين جميع البيانات في حد ذاته (في بعض الأحيان في شكل روابط للأحداث السابقة) ، مما يجعل الحدث قابلاً للتسلسل ، ويزيد من المكان ، ويقلل الاتصال ، إلخ.
- بمجرد حدوث الحدث ، لم يعد يتغير (يتم توثيق أي تحسينات بواسطة أحداث أخرى) ، مما يقلل من حركة النسخ المتماثل.
- يمكن أن يكون تنسيق تخزين الأحداث موحدًا إلى حد ما ، وغير مقيد من مجال موضوع معين.
- يمكن تقسيم / دمج سجلات الأحداث بشكل غير مؤلم نسبيًا ، ويمكنك تخزين أنواع مختلفة من الأحداث على عقد مختلفة ، وهذا في جوهره نتحدث عن قاعدة بيانات موزعة.
- يتم ترتيب الأحداث حسب الوقت ، وهذا التسلسل يعكس أيضًا العلاقة السببية (لا يمكن الرجوع إلى الحدث الحالي لاحقًا).
- عند تسجيل حدث ، ليس من الضروري تحديث البيانات الأخرى معاملات (في الواقع ، تكون مطلوبة ، ولكن في عدد محدود من الحالات ، على سبيل المثال ، يجب أن يكون رصيد المشترك في نظام الفوترة ذا صلة على الفور ، من الضروري تحديث عدادات الارتباط ، إلخ).
- يمكن إنشاء التقارير مباشرةً من سجل الأحداث ، دون الحاجة إلى تحويل البيانات إلى نموذج عادي.
فيما يتعلق بالنقطة الأخيرة ، تُظهر اختبارات الأداء العديدة (بما في ذلك على مدونتي) أنه على الأجهزة الحديثة ، فإن معالجة مليار حدث (حقائق) باستخدام خوارزمية أحادية المرور مع ذاكرة قصيرة الأجل تستغرق دقائق ، وهو أمر مقبول تمامًا للإبلاغ. ونظرًا لأن معالجة الأحداث من مختلف الأنواع غير المرتبطة بالوصلات سهلة التوازي ، يمكن تقليل وقت إعداد التقارير إلى عشرات الثواني ، مع عدم وجود مقدار كبير من تطبيع البيانات / الفهرسة / تجميع الإحصائيات / تصحيح الأخطاء والاستعلامات - كما هو الحال في RDBMSs العادية. لذلك ، بناء التقارير بناءً على هذه البيانات لا يخيفني. ومع ذلك ، النظر في المشكلة على نطاق أوسع.
يمكن تمثيل تطبيق الأعمال النموذجي كسلسلة لتحويل البيانات:
"الإدخال => النموذج => الإخراج". أي مخطط تخزين هو حل وسط بين ثلاثة أطراف:
- نقوم بتخزين البيانات في تنسيق الإخراج. هذه هي الطريقة التي تعمل بها مجموعة متنوعة من واجهات المتاجر و OLAPs ، حيث يكون وقت الاستجابة مهمًا. سلبيات معروفة - الطلب المفرط على الذاكرة وانخفاض معدل التحديث (عادةً دفعة).
- نقوم بتخزين البيانات في تنسيق نموذج المجال ، وبالتالي تبسيط خوارزميات الحساب. هناك الكثير من العيوب - يلزم إجراء تحويل مزدوج للبيانات (من الإدخال إلى النموذج ، ومن النموذج إلى الإنتاج) ، وزيادة تكاليف المعاملات ، ومن الصعب توفير التخزين الموزع ، وتغيير المخطط باهظ الثمن ، إلخ. ومع ذلك ، هذا هو الخيار الأكثر شعبية.
- نقوم بتخزين البيانات في تنسيق الإدخال (في الواقع ، ما يقدمه كاتب المقال هو سجل الأحداث). في هذه الحالة ، تكون تكاليف المعاملات في حدها الأدنى ، ويتم تقسيم البيانات ودمجها بسهولة ، وهو نظام تخزين بسيط وواضح ومستقر. الربح! صحيح ، عليك أن تتعلم البرمجة مرة أخرى.
بالنسبة إلى مجال اهتمامي (أنظمة معلومات الشركة) ، يعد الحدث مستندًا أساسيًا ، ويمكن اعتبار الكتاب المرجعي حدثًا سابقًا. لقد سبق أن وصفت بنية جدول ERP الغربي النموذجي في مقال
"NoERP أو نظرة جديدة ..." ، حيث اقترحت إلغاء التطبيع المفرط للبيانات (باستثناء سجلات الأرصدة الفورية) ، وإعادة كتابة معظم العمليات الحسابية / التقارير في دورات أحادية المرور ، حيث تتم معالجة الحسابات الأولية بشكل مباشر وثائق. لن أكرر الحجج ، فكل شيء مذكور في المقالة ، لكن المخطط الذي اقترحته عمليًا تزامن مع أطروحة مؤلف المقال الأول ، أي أن سجل الأحداث هو البيانات. إنه لطيف عندما يفكر شخص آخر في هذا الاتجاه.
من الواضح أن هذا النهج يبدو خطوة إلى الوراء بالمقارنة مع نظم إدارة قواعد البيانات الذكية الحديثة ، ولكن في العالم الشاهق عليك أحيانًا أن تتخلى عن الأدوات الشائعة / المجردة / العالمية - لصالح البرمجة الحتمية والفعالة التي لا تتطلب ترخيصًا مكلفًا للعقد / حبات / المستخدمين.
أود أن أقول بشكل منفصل عن طريقة تنظيم العلاقات داخل سجل الأحداث - يجب أن يكون ذو اتجاهين ، أي أنه يجب على كل حدث تخزين عداد مرجعي لنفسه. يعد هذا ضروريًا لتنفيذ خوارزميات المرور الفردي - ننتقل من الأحداث القديمة إلى الأحداث الجديدة ، وفي نفس الوقت نقوم بتخزين كل حدث مؤقتًا برقم غير صفري من الارتباطات الواردة في الذاكرة ، وحذفها من ذاكرة التخزين المؤقت فقط بعد معالجة جميع تلك الإحالات. يقلل وجود العداد المرجعي من أداء المعاملات بطريقة غير سارة - على سبيل المثال ، إذا تم استخدام دليل الطرف المقابل في كل وثيقة ، فيجب تحديث العداد المرجعي في الطرف المقابل في كل مرة يتم فيها إضافة مستند ، وأحيانًا على عقدة أخرى. ومع ذلك ، يمكن تحسين هذا المكان عالميًا ، مع تجنب المعاملات الموزعة في جميع الحالات الأخرى.
في الواقع ، على مستوى الفكرة ، كل هذا في الوقت الحالي ، ما زلت آمل في مشروع محدد (على سبيل المثال ، على أساس إيصالات نقدية أو فواتير) ، وإذا قدمت هذه الفرصة نفسها ، فسوف أبلغ عن النتائج.