المقدمة
شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.
ودي واحدة من أكبر محركات قواعد البيانات عند Uber واللي بتستخدمها كتير من الـ Microservices في كل القطاعات التجارية أو اللي بنسميها Business Verticals عندهم.
والكلام ده من ساعة ما بدأت في 2020، عدد المستخدمين وحالات الاستخدام بتاعت Docstore في ازدياد، وكمان حجم الطلبات والبيانات في زيادة.
Motivation
شركة Uber كانت بتستعمل الـ Schemaless Types من قواعد البيانات , واللي خلتها بعد كده تقابل شوية تحديات كبيرة والي خلتها تتجه لاستعمال Cassandra كـ Database وتبقى كـ General Purpose Database لمعظم الـ Business Verticals.
ولكن مع حجم الـ Scale بتاع Uber كان الـ Operations على Cassandra كبيرة جدًا ومش فعالة بالنسبة ليهم من ناحية الكفاءة بتاعتها والـ Scale بتاع Uber ، بالاضافة كمان لان Cassandra بتدعم الـ Eventual Consistency وده Consistency Level بالنسبة لـ Uber مكنش أفضل حاجة من ناحية المتطلبات بتاعتهم خصوصا ان هم بيطمحوا لتحقيق الـ Strict Serializability Consistency Level.
ومن ثم ظهر الحاجة لتصميم Docstore واللي مبني على MySQL.
Docstore
قاعدة البيانات دي بتتميز بعدة مميزات من ضمنها انها بتوفر الـ Strict Serializability Consistency Model على مستوى الـ Partition وده كان من ضمن المتطلبات اللي Uber عاوزة تحققها وبالتالي نقدر نستنج هنا ان Uber بتضحي بالـ Availability في سبيل الـ Consistency من ناحية نظرية الـ CAP Theorem.
كمان نقدر نـ Scale Horizontally واللي اتاح الفرصة لـ Uber انها بالشكل ده قاعدة البيانات تكون بتدعم وبتخدم عدد كبير من الـ Heavy Workloads اللي عندهم.
ومش بس كده ده كمان بتوفر مميزات كتير بتحسن من انتاجية المطورين زي الـ Transactions / Materialized Views / CDC بالإضافة للمرونة في عمل الـ Modeling للبيانات وكذلك وفرة من الـ Query Support اللي الـ Clients ممكن يكونوا محتاجينها.
Docstore Architecture
هنلاقي أن Docstore متقسمة بشكل رئيسي لثلاث أجزاء أو طبقات Layers:
1- الـ Stateless Query Engine Layer
2- الـ Stateful Storage Engine Layer
3- الـ Control Plane
وللتذكير Stateless من اسمها يعني مش مسئولة عن الاحتفاظ بأي State نهائيًا أو معلومات ، بينما الـ Stateful فهي بتحتفظ بالـ State أو بعض المعلومات عشان تستفيد منها في أداء شغلها.
- الـ Stateless Query Engine مسئول بشكل أساسي عن الـ Query Planning والـ Routing والـ Sharding والـ Schema Management وكمان الـ Node Health Monitoring والـ Request Parsing والـ Validation والـ AuthN/AuthZ.
والـ AuthN اللي هي اختصار لـ Authentication والـ AuthZ اختصار للـ Authorization.
- بينما الـ Stateful Storage Engine مسئول بشكل أساسي عن تحقيق الـ Consensus من خلال Raft وده طبعًا بيتم استعماله بشكل أساسي في النظم الموزعة لضمان تحقيق الـ Replication بكفاءة واتساق البيانات أو ما يعرف بالـ Consistency.
والـ Storage Engine كذلك مسئول عن الـ Replication والـ Transactions والـ Concurrency Control والـ Load Management.
- والـ Control Plane هم مسئول بشكل أساسي على انه يـ Assign الـ Shards للـ Docstore Partitions ويعدل ويغير من الـ Shard بناء على الـ Failure اللي ممكن تحصل في أي وقت. فهو زي المخ لعملية تحديد الـ Shards على الـ Partitions.
وزي ماحنا شايفين في الصورة احنا عندنا أكتر من Partition كل جزء بيكون عبارة عن بعض الـ MySQL Nodes مدعومة بـ NVMe SSDs واللي قادرة على انها تتحمل الأحمال الثقيلة في القراءة والكتابة Heavy Read and Write Workloads.
البيانات متقسمة على أكتر من جزء وكل جزء بيكون فيه Leader واحد , و 2 Follower وطبعا من خلال استعمال Raft لتحقيق الـ Consensus.
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
Eqraatech - اقرأ-تِك
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Consistency Model
الـ Docstore زي ما قولنا بيوفر الـ Strict Serializability Consistency Model على الـ Partition Level.
وده بيضمن لنا خاصية لطيفة جدًا الا وهي ان الـ Users يقدروا يتخيلوا ان الـ Transactions بتحصل بشكل Sequentially وبالتالي بنتجنب مشاكل الـ Concurrency والـ Conflicts اللي ممكن تحصل.
بالإضافة لإن كمان الـ Transactions بتكون مرتبة وده معناه ان لو عندي Tx A و Tx B و A حصل قبل B فـ Tx A هيحصله Start و Commit قبل B. وده بيضمن ان الـ Read Operations دايما هترجع النتيجة الآخيرة من آخر عملية كتابة حصلت.
وعشان كده زي ماقولنا Docstore من منظور الـ CAP هي بتفضل الـ Consistency عن الـ Availability.
Transactions
ذكرنا في الـ Architecture أن Docstore مبنية على الـ MySQL Database Engine. وبالتالي الـ Replication اللي بيتم من خلال الـ Replicated State Machine هو عبارة عن MySQL Transaction.
وبالتالي كل العمليات اللي بتتنفذ في محيط وحيز الـ MySQL Transactions بتضمن الـ ACID Semantics واللي كنا اتكلمنا عنها قبل كده في ورقة منفصلة.
Alaa Elkzaz
ACID Properties in DBMS
والـ Transactions دي بيحصلها Replication في كل الـ Nodes باستعمال الـ Raft Consensus Protocol.
وبرضو بيعتمدوا على MySQL في ادارة الـ Concurrency Control , ومهم جدًا اننا نفهم ان MySQL بيعتمد اصلا على الـ Row Locks عشان الـ Concurrency Control خصوصا في عمليات الكتابة زي الـ Inserts / Updates / Deletes ولكن الـ Concurrent Updates على نفس الـ Rows بيحصلهم Serialization من خلال MySQL.
وبالتالي كل الـ Lockings بيتم العناية بيها من خلال MySQL نفسها.
Raft Based Replicated State Machine
الـ Raft Based Replicated State Machine بيسمح بأن MySQL تعمل Exposing للـ MySQL Transactions للـ Clients بشكل يكون Highly Available.
فكل الـ Replicas بتنسق مع بعضها عشان تـ Apply الـ Transactions واللي بينتج عن ده ان يكون فيه Automatic Failover بين الـ Replica. وكمان نكون محافظين على الـ ACID Properties اللي بيتميز بيها الـ Transaction حتى مع حدوث Failover.
في الختام
شوفنا مع بعض الـ Motivation والسبب في اتجاه Uber لبناء Docstore , وشوفنا مع بعض بدايتهم مع الـ Schemaless واتجاهمم بعد كده لـ Cassandra وازاي مع الوقت بدأوا يفكروا في انهم يقللوا من العبء اللي عليهم ويبدأوا يسهلوا الدنيا للمطورين في الشركة في مختلف الـ Business Verticals ان هم يستعملوا General Purpose Database وتكون Distributed ومحققة اهدافهم.
وشوفنا مع بعض الـ Architecture بتاعته وانه مبني على MySQL Database Engine وكمان خدنا بصة على الـ Transactions والـ Consistency Model.
