يستطيع Elasticsearch تخزين البيانات بصورة دائمة. ولتحديد ما إذا كان ينبغي أن يكون قاعدة البيانات الأساسية، اسأل ما قواعد العمل التي يجب أن تبقى صحيحة عندما تفشل الكتابات أو تحدث بالتزامن.
في نظام الطلبات، البحث عن المنتجات وتأكيد الشراء مهمتان مختلفتان. أهمية نتائج البحث هي الأولوية للأولى، بينما صحة تغييرات الدفع والمخزون هي الأولوية للثانية.
لنفترض أن الشراء يتطلب تسجيل طلب وخفض المخزون. يجب أن يحدد العمل ما ينبغي حدوثه إذا نجح أحدهما فقط.
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
ترسل واجهة bulk في Elasticsearch عدة عمليات على مستندات معًا، لكن قد يفشل عنصر بينما ينجح آخر. لا تجعل هذه العمليات معاملة تنجح كلها أو تفشل كلها. يجب أن يفحص التطبيق النتائج الفردية. واجهة Bulk.
إذا كان المطلوب تغييرًا ذريًا عبر سجلات، فعادةً توفر قاعدة بيانات معاملية أساسًا أكثر مباشرة. تنفيذ هذا التنسيق بنفسك يضيف حالات فشل وأعمال استعادة.
يتحقق التحكم المتفائل بالتزامن من أن المستند لم يتغير منذ الإصدار الذي قرأته. ويمكنه رفض تحديث قديم، لمنع عميل من الكتابة فوق عمل عميل آخر دون تنبيه. التحكم بالتزامن.
تنطبق هذه الحماية على المستند الجاري تحديثه. وهي لا تنسق تلقائيًا مستند المخزون مع مستند الطلب، ولا توفر مفاتيح أجنبية علائقية، ولا تفرض أي قاعدة تفرد مطلوبة على حقول العمل.
اكتب القواعد التي يحتاجها التطبيق قبل اختيار التخزين. بذلك يصبح القرار محددًا بدل الاعتماد على وصف «محرك بحث» أو «قاعدة بيانات».
نجاح الكتابة وظهور نتيجتها في البحث حدثان منفصلان:
[Write accepted] -> [Refresh] -> [Search can see the change]
يجعل refresh التغييرات الحديثة مرئية للبحث. لذلك يختلف جلب المستند الفوري بمعرّفه عن استعلام البحث. يمكن لخيار refresh=wait_for الانتظار حتى الظهور في البحث، لكنه لا ينشئ معاملة متعددة المستندات. سلوك Refresh.
قد يكون تأخر قصير في الظهور مقبولًا لصفحة بحث المنتجات. أما قرار الدفع النهائي أو الصلاحيات، فحدد مستوى الاتساق المطلوب صراحة واقرأ من مصدر يوفره. كما أن refresh والتخزين الدائم مسألتان مختلفتان.
| المتطلب | الاتجاه المقترح للتقييم | السبب |
|---|---|---|
| يجب تغيير الطلبات والسجلات المرتبطة ذريًا | قاعدة أساسية معاملية | مكان قواعد الصحة المطلوبة قريب من السجلات المعتمدة. |
| يحتاج المستخدمون بحثًا نصيًا مرنًا | Elasticsearch كنسخة للبحث | يمكن تشكيل بيانات البحث وإعادة بنائها بصورة مستقلة. |
| مستندات مستقلة ومتطلبات اتساق متوافقة | قد يناسب Elasticsearch كمخزن أساسي | يجب أن تكون لإضافة قاعدة ثانية فائدة مثبتة. |
تصميم شائع لنظام الطلبات هو:
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
يلتقط CDC التغييرات المثبتة، بينما يسجل outbox حدثًا مع تحديث العمل ضمن المعاملة نفسها. تنقل عملية منفصلة هذه التغييرات إلى الفهرس. وهذا يتجنب الاعتماد على نجاح كتابتين منفصلتين من التطبيق معًا دائمًا.
ما زال مسار الفهرسة يحتاج معرّفات ثابتة ومعالجة الإصدارات والحذف وإعادة المحاولة ومراقبة التأخر. اختبر إعادة بناء الفهرس من المصدر، وإلا قد تتحول نسخة البحث إلى مصدر حقيقة ثانٍ غير متسق.
أيًا كان الدور المختار، خطط للنسخ الاحتياطي واختبر الاستعادة. تساعد النسخ المتماثلة على الإتاحة لكنها ليست بديلًا للنسخ الاحتياطية. حدد فقد البيانات وزمن الاستعادة المقبولين للتكوين الفعلي.
في مثال الطلبات، سأحتفظ بالسجلات المعاملية في قاعدة تدعم قواعدها، وأضيف Elasticsearch إذا بررت متطلبات البحث ذلك. أما المستندات المستقلة الموجهة للبحث، فسأقيّم ما إذا كان Elasticsearch وحده يلبي احتياجات التخزين والاتساق والاستعادة.
تذكر: اختر وفق الضمانات التي يحتاجها العمل، ثم تحقق من سلوك الفشل والاستعادة. سرعة البحث جزء واحد فقط من القرار.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع