قواعد البيانات NoSQL عندمام ظهرت لم تكن تحقق خصائص ACID التي ذكرتها في سلسلة سابقة و بدلاً من ذلك كانت تكتفي بتحقيق خصائص ثلاث جمعت في كلمة BASE و هي Basic Availability, Soft-state, Eventual consistency
لكن قبلها سنتعرف على نظرية CAP
(سلسلة )
لكن قبلها سنتعرف على نظرية CAP
(سلسلة )
في عالم قواعد البيانات الموزعة هناك نظرية تسمى CAP تنص انه لا يمكن الحصول على الثلاث مزايا مع بعضها بل أنت قادر على الحصول على ميزتين اثنتين كاملتين فقط من اصل ثلاثة و تتقبل عدم اكتمال الثالثة اعتماداً على ما يحتاجه عملك.
المزايا الثلاث هي ال Consistency أي ان كل السيرفرات لديها نسخ متطابقة من البيانات في نفس الوقت و الAvailability تعني انها دائماً متوفرة عند الاستعلام عنها بغض النظر عن تطابقها في جميع السيرفرات و الPartition Tolerance تعني ان نظامك دائماً يعمل حتى لو فقدت بعض السيرفرات.
تخيل نفسك مديراً لاحد شركات الطيران و لديك موقع لحجز تذاكر عبر الويب و قاعدة بياناته موزعة . مثلاً لو دخل شخصين في مكانين مختلفين من العالم على موقع الشركة في نفس الوقت و طلبوا حجز مقعد معين . ما الذي يمكن أن يحدث مع العميلين و ما الطريقة المناسبة برأيك لحل الإشكال.
عندما يكون لديك قواعد بيانات SQL أي ACID فيمكن مباشرة للموقع أن يعلم بأن المقعد لم يعد متاحاً لأنك قمت بعمل Lock للبيانات عندما استدعاها الأول و لكن إن كان لديك قواعد بيانات موزعة فقد تتأخر قاعدة البيانات التي دخل عليها الشخص الاول في إخطار قواعد البيانات الأخرى بالتغيير.
لذا نقول إن اخترت ان تسمح للاثنين باختيار اخر مقعد في نفس الوقت و تكمل العملية بسلاسة ثم ترسل اعتذار للعميل الذي لم يتمكن من الحصول على المقعد و تطيب خاطره . فانت اخترت AP و ضحيت بالConsistency .
و إن اخترت ان تمنع ذلك بأن تتأكد ان لا أحد الان يقوم بفحص المقاعد و تريد الإنتظار حتى تتأكد فأنت هنا اخترت الCP و ضحيت بالAvailability حيث سيكون موقعك في حالة جمود وانتظار لوقت طويل بالاضافة الى كثرة رسائل الخطأ. هذا في الأخير قرار يعود للبزنس و كيف يقيم الأصلح له.
نعود للBASE و لاحظ انه اختيار في مقابل ACID ( حمضي و قلوي ) . الBasically Available تعني ان بياناتك دائماً موجودة لأنها موزعة على اكثر من جهاز خادم فإذا فقدت احدها مازال لديك نسخة اخرى حية. الSoft state يعني ان بياناتك ليست دائماً ثابته بسبب الEventual consistency
و الEventual consistency تعني ان تحديث البيانات لا يتم بالضرورة في نفس الوقت بل عندما تتصل الخوادم بنفسها.
في عالم الNoSQL هناك قواعد بيانات يهمها ان تكون CP اكثر مثل MongoDB و Redis و اخرى يهمها ان تكون AP اكثر من CP مثل CouchDB و Cassandra
إلى هنا نكون انهينا هذه السلسلة.
في عالم الNoSQL هناك قواعد بيانات يهمها ان تكون CP اكثر مثل MongoDB و Redis و اخرى يهمها ان تكون AP اكثر من CP مثل CouchDB و Cassandra
إلى هنا نكون انهينا هذه السلسلة.
جاري تحميل الاقتراحات...