قاعدة بيانات في الذاكرة: سرعة القراءة من الذاكرة دون فقدان البيانات

كل قاعدة بيانات تُبقي بعض البيانات في الذاكرة. لكن ما يجعل القاعدة «في الذاكرة» أن الذاكرة هي مكان العمل نفسه: البيانات التي يطلبها التطبيق أكثر من غيرها موجودة في الذاكرة أصلًا، وتُجاب القراءة منها. أما القرص فمكان حفظ البيانات بأمان، لا المكان الذي تُجلب منه مع كل طلب.

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

هذه الأسئلة تحدد هل تصلح قاعدة NoSQL في الذاكرة لبيئة الإنتاج:

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

Couchbase قاعدة بيانات NoSQL موزعة تصنعها شركة أخرى. وإنتركي شريك تقني لـCouchbase وتبيع Couchbase Capella. والنقاط التالية مأخوذة من توثيق Couchbase نفسها:

• طبقة تخزين مؤقت مدمجة ومُدارة. في Couchbase Server طبقة تخزين مؤقت داخل خدمة البيانات (Data Service) تديرها المنصة تلقائيًا، فلا يحتاج التطبيق إلى مخزن منفصل يحافظ على اتفاقه مع القاعدة.
• الكتابة إلى الذاكرة ثم إلى القرص. تُؤكد الكتابة العادية حين تُحفظ في ذاكرة العقدة التي تحمل النسخة النشطة، ثم تدخل قائمة انتظار للكتابة على القرص. وتصف Couchbase الكتابة العادية بأنها غير متزامنة.
• ضمان الحفظ حين يحتاجه المسار. يمكن أن تحمل الكتابة مستوى للحفظ (Durability): majority أي في ذاكرة أغلب عقد خدمة البيانات، وmajorityAndPersistActive أي ذلك مع الكتابة على قرص العقدة النشطة، وpersistToMajority أي الكتابة على قرص أغلب العقد. فيمكن أن تختار مسارات الدفع مستوى، والتحديثات المعتادة مستوى آخر.
• الإخراج من الذاكرة لا يحذف البيانات. حين تقترب السلة من حصتها من الذاكرة تُخرج بعض البيانات من الذاكرة وتبقى على القرص. ومع إخراج القيمة فقط (Value-only) تبقى المفاتيح والبيانات الوصفية في الذاكرة، ومع الإخراج الكامل (Full) يخرج المستند كله، فتُوفَّر ذاكرة أكثر.
• العودة بعد إعادة التشغيل. تعيد العقدة تحميل البيانات من القرص إلى الذاكرة، وافتراضيًا تخدم السلة الطلبات بينما يُحمَّل الباقي.
• محركا تخزين. يناسب Couchstore البيانات التي تتسع لها الذاكرة غالبًا، وصُمم Magma لمجموعات البيانات الكبيرة التي لا تتسع لها، ويحتاج إلى نسبة أصغر بكثير من البيانات في الذاكرة.

روابط ذات صلةصفحة مخزن المفتاح والقيمةصفحة قاعدة بيانات NoSQL

في المملكة تظهر الحاجة عادةً في نظام يواجه ضغط قراءة لم يُصمَّم له:

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

روابط ذات صلةnca.gov.sasdaia.gov.sa

Couchbase Capella خدمة المورّد المُدارة على AWS أو Google Cloud أو Microsoft Azure. وحتى 2 نوفمبر 2026 تشمل مناطقها المنشورة منطقة Google Cloud في الدمام (me-central2). أما Couchbase Server بالتشغيل الذاتي فيعمل على بنية تتحكمون فيها، كمركز بياناتكم داخل المملكة. والمنطقة داخل المملكة تحسم مكان بيانات العنقود، لكنها لا تحسم وحدها مكان النسخ الاحتياطية والسجلات، فراجعوا ذلك مع مسؤول الامتثال لديكم. وتقارن صفحة Capella أو التشغيل الذاتي بين النموذجين.

روابط ذات صلةصفحة Capella أو التشغيل الذاتي

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

• مجموعة العمل، لا حجم البيانات كله، هي التي تحدد الذاكرة. والتقدير الجيد لها أنفع من أي خصم.
• النسخ المتماثلة تضاعف الذاكرة والقرص اللذين يحتاجهما العنقود.
• محرك التخزين يغيّر نسبة الذاكرة إلى البيانات التي يجب أن يحافظ عليها العنقود.
• موقع التعافي يضيف عنقودًا ثانيًا له عقده.