قاعدة بيانات Redis

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

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

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

وهنا الجزء الذي تتعلمه الفرق بالطريقة الصعبة، فالذاكرة تُفرَّغ لحظة إعادة تشغيل الجهاز. يستطيع Redis أن يكتب نسخة على القرص لكنه يفعل ذلك على فترات، فإعادة تشغيل في اللحظة الخطأ تضيّع آخر ثوانٍ. وهذا مقبول لصفحة محفوظة مؤقتًا وغير مقبول لطلب شراء، ولهذا لا ينبغي أن يكون مهمًا أي شيء نسخته الوحيدة داخل Redis. والمفاجأة الثانية أن Redis مسموح له افتراضيًا باستخدام كل الذاكرة المتاحة، فحين تنفد ذاكرة الجهاز يتضرر كل ما عليه لا التخزين المؤقت وحده. وفي لينكي سوفت لنظم المعلومات نضبط هذا الحد في اليوم الأول من كل مشروع، فاسأل مورّدك عن قيمة الحد وعمّا يُحذف عند بلوغه.

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