Databases

شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.

لما نيجي نتكلم عن الأنظمة اللي بتركز على عمليات القراءة أكتر من الكتابة، يعني الـ Systems اللي بيكون فيها نسبة قراءة للبيانات أكبر بكتير من نسبة الكتابة، ففيه شوية استراتيجيات ممكن نستخدمها عشان نحسن من الأداء.

الطريقة الشائعة واللي أغلبنا اتعرضلها عشان يقدر يولد Unique IDs عشان نستعملها في الـ Database ونميز الـ Rows كانت الـ UUID أو اللي بنسميه برضو GUID في منتجات Microsoft.

إيقاف عمليات الـwrites على الـLeader Replica،  يؤدي بنا بعد وقت ما إلى مرحلة يصبح النظام فيها consistent؛ يعني ذلك أن استمرار عملية الـwrite لا تضمن لنا معرفة، بعد كم من الوقت سنصل إلى حالة الـconsistency، وهل سنصل لها أم لا

مع مرور الوقت وزيادة حجم البيانات لا يمكن لجهاز واحد أن يتحمل كل هذه البيانات، فلا بد من زيادة عدد الأجهزة وتخزين البيانات عليها، وهنا يمكننا توزيع الـ Read Requests على أكثر من جهاز فبدلًا من قراءة البيانات من جهاز واحد فقط

الـ Pessimistic Locking في قواعد البيانات بيمنع الـ Conflicts الناتجة من الـ Concurrent Updates واللي بتحصل بشكل Frequent أو متكرر. فلما بنيجي نعمل عملية تحديث لـ Row أو Record معين، فالـPessimistic Locking بتحط قفل

ال ACID ببساطة عبارة عن اختصار ل 4 قواعد لازم تحققهم قاعدة البيانات و العمليات اللي بتتم عليها بغض النظر عن أي Software or Hardware Failure أو حتى Power Failure. و ال 4 قواعد دي هي الضمان إن ال Database دي والبيانات اللي فيها صحيحة وموثوق فيها و دا عامل أساسي في مجال البرمجيات ككل "صحة البيانات".

ورقة وقلم وتعالوا نتكلم عن واحدة من أهم المفاهيم في عالم صناعة البرمجيات واللي مبسطة علينا حياتنا اليومية كمبرمجين  ألا وهي الـ ORMs - Object Relational Mappers

تخيل تروح فرع لبنك او أي فرع لشركة تليفون عشان تستفسر عن حاجة معينة وتلاقي مفيش غير شباك واحد , هيكون ايه رد فعلك لو مع كل حد هيجي يسال عن حاجة معينة, الفرع هيروح يدور على حد يوظفه يقعد في الشباك يساعدك وبعدين يمشي الموظف ده ؟