يقولون أنه في كل شيء يستحق المحاولة مرة واحدة على الأقل. وإذا كنت معتادًا على التعامل مع قواعد بيانات إدارة قواعد البيانات العلائقية ، فإن التعرف على التطبيق العملي لـ NoSQL يستحق ذلك ، أولاً وقبل كل شيء ، على الأقل للتطوير العام. الآن ، نظرًا للتطور السريع لهذه التقنية ، هناك الكثير من الآراء المتضاربة والمناقشات الساخنة حول هذا الموضوع ، وهو ما يثير الاهتمام بشكل خاص.
إذا بحثت في جوهر كل هذه النزاعات ، يمكنك أن ترى أنها تنشأ بسبب النهج الخاطئ. أولئك الذين يستخدمون قواعد بيانات NoSQL بالضبط حيث تكون هناك حاجة إليها راضون ويحصلون على كل مزاياها من هذا الحل. ويخيب أمل المجربون الذين يعتمدون على هذه التكنولوجيا باعتبارها الدواء الشافي حيث لا تنطبق على الإطلاق ، في فقد نقاط القوة لقواعد البيانات العلائقية دون الحصول على فوائد كبيرة.
سوف أخبركم بتجربتنا في تنفيذ حل قائم على Cassandra DBMS: ما كان علينا مواجهته ، وكيف خرجنا من المواقف الصعبة ، وهل نجحنا في الاستفادة من استخدام NoSQL وأين يجب علينا استثمار جهد إضافي / أموال.
تتمثل المهمة الأولية في إنشاء نظام يقوم بتسجيل المكالمات إلى وحدة تخزين معينة.
مبدأ النظام هو على النحو التالي. الملفات ذات بنية معينة تصف بنية الاستدعاء تأتي إلى الإدخال. ثم يضمن التطبيق أن يتم حفظ هذه البنية في الأعمدة المناسبة. في المستقبل ، يتم استخدام المكالمات المحفوظة لعرض معلومات حول استهلاك حركة المرور للمشتركين (الرسوم والمكالمات وسجل الرصيد).
لماذا تم اختيار كاساندرا أمر مفهوم تمامًا - تكتب بصفتها مدفعًا رشاشًا وقابلًا للتحجيم بسهولة وتتحمل الأخطاء.
لذا ، ها هي التجربة التي أعطتنا
نعم ، العقدة المحطمة ليست مأساة. هذا هو جوهر تسامح كاساندرا. ولكن يمكن أن تكون العقدة مباشرة وفي نفس الوقت تبدأ في الترهل على الأداء . كما اتضح ، هذا يؤثر على الفور على أداء المجموعة بأكملها.
كاساندرا لا تحوط حيث حفظ أوراكل مع الثوابت . وإذا لم يفهم مؤلف التطبيق هذا مقدمًا ، فحينئذٍ ، لن تأخذ الطائرة التي يتم نقلها إلى كاساندرا أسوأ من الأصل. بمجرد أن يأتي ، سنقوم بإدخاله.
لم يعجب Kassandra المجاني "خارج الصندوق" بأمان المعلومات بشكل حاد: لا يوجد تسجيل لإجراءات المستخدم ، ولا يوجد تمييز بين الحقوق . تتعلق المعلومات المتعلقة بالمكالمات بالبيانات الشخصية ، مما يعني أنه يجب تسجيل جميع المحاولات لطلب / تغييرها بأي طريقة مع إمكانية المراجعة اللاحقة. أيضًا ، يجب أن تكون مدركًا للحاجة إلى فصل الحقوق على مستويات مختلفة للمستخدمين المختلفين. إن مهندس التشغيل البسيط والمشرف الفائق الذي يمكنه إزالة مساحة المفاتيح بأكملها بحرية هي أدوار مختلفة ومسؤوليات مختلفة وكفاءات. بدون هذا التمييز في حقوق الوصول ، سيتم فوراً التشكيك في قيمة وسلامة البيانات بشكل أسرع من مستوى التناسق.
لم نأخذ في الاعتبار أن المكالمات تتطلب تحليلات جدية ، وكذلك عينات دورية لمجموعة متنوعة من الظروف. نظرًا لأنه من المفترض أن يتم حذف السجلات المحددة وإعادة كتابتها (في إطار المهمة ، يجب أن ندعم عملية تحديث البيانات عند إدخال حلقة البيانات في البداية بشكل غير صحيح) ، Kassandra ليس صديقنا هنا. كاسندرا ، مثله مثل بنك أصبع ، مناسب لوضعه فيه ، لكنك لن تكون قادرًا على الاعتماد عليه.
واجهت مشكلة نقل البيانات إلى مناطق الاختبار (5 نقاط في الاختبار مقابل 20 في حفلة موسيقية). في هذه الحالة ، لا يمكن استخدام تفريغ.
مشكلة تحديث مخطط البيانات لتطبيق الكتابة إلى كاساندرا. سوف يؤدي التراجع إلى إنشاء عدد كبير من شواهد القبور الكبيرة ، والتي بطريقة يمكن التنبؤ بها يمكن أن تقلل من إنتاجيتنا . تم تحسين كاساندرا للتسجيل ، وقبل التسجيل ، لا يفكر كثيرًا. أي عملية مع البيانات الموجودة فيه هو أيضا رقما قياسيا. أي أنه بعد إزالة الفائض ، فإننا ببساطة نفرغ سجلات أكثر ، وسيتم تمييز جزء منها فقط بشواهد القبور.
مهلات على إدراج. كاسندرا جميلة في التسجيل ، ولكن في بعض الأحيان يمكن أن يكون الدفق القادم محيرًا جدًا لها . يحدث هذا عندما يبدأ التطبيق بدائرة عدة سجلات لا يمكن إدراجها لأي سبب. وسنحتاج إلى DBA حقيقي تمامًا ، والذي سيتبع gc.log وسجلات النظام والتصحيح للاستعلام البطيء ، ومقاييس الضغط المعلقة.
العديد من مراكز البيانات في كتلة. أين تقرأ وأين تكتب؟
ربما تنقسم إلى القراءة والكتابة؟ وإذا كان الأمر كذلك ، فهل يجب أن يكون هناك DC للكتابة أو القراءة أقرب إلى التطبيق؟ ألا نحصل على دماغ حقيقي منقسم إذا اخترنا مستوى الاتساق بشكل غير صحيح؟ هناك الكثير من الأسئلة ، والكثير من الإعدادات غير المستكشفة ، وهي ميزات أريد حقًا تحريفها.
كيف قررنا
أن العقدة لم تبدد ، تعطيل SWAP . والآن مع نقص الذاكرة ، يجب أن العقدة الاستلقاء ، وألا تنتج توقف مؤقت كبير.
لذلك ، لم نعد نأمل في المنطق في قاعدة البيانات. يتعلم مطورو التطبيقات ويبدأون في جعلهم آمنين في كودهم الخاص. الفصل الواضح التام لتخزين البيانات ومعالجتها.
اشترينا الدعم من DataStax. لقد توقفت كاساندرا المعبأة بالفعل عن التطوير (الالتزام الأخير في فبراير 2018). في الوقت نفسه ، تقدم Datastax خدمة ممتازة وعدد كبير من الحلول المعدلة والمتكيفة مع حلول IC الحالية.
أود أيضًا أن أشير إلى أن كاساندرا غير مناسب جدًا للاستعلام عن العينات. بالطبع ، تعد CQL خطوة كبيرة نحو المستخدمين (مقارنةً بـ Trift). ولكن إذا كان لديك أقسام كاملة ، اعتادوا على مثل هذه الوصلات المريحة ، والتصفية المجانية حسب أي مجال وخيارات تحسين الاستعلام ، وتعمل هذه الإدارات على إغلاق الدعاوى والحوادث ، فإن القرار بشأن كاساندرا يبدو أنه عدو وغبي. وبدأنا في معالجة مسألة كيفية قيام زملائنا بعمل عينات.
درسنا خيارين: في الخيار الأول ، نكتب المكالمات ليس فقط في C * ، ولكن أيضًا في قاعدة بيانات أرشيف Oracle. فقط ، على عكس C * ، يتم تخزين المكالمات في قاعدة البيانات هذه فقط للشهر الحالي (عمق تخزين مكالمات كافٍ لحالات إعادة التصديق). هنا رأينا المشكلة التالية على الفور: إذا قمت بالكتابة بشكل متزامن ، فإننا نفقد كل مزايا C * المرتبطة بالإدخال السريع ، إذا كان بشكل غير متزامن ، فلا يوجد ضمان بأن جميع المكالمات الضرورية تصل إلى Oracle عمومًا. كان هناك واحد زائد ، ولكنه كبير: بالنسبة للاستغلال ، يبقى نفس مطور PL / SQL المألوف ، أي أننا ننفذ عمليًا نمط "الواجهة" ، وهو خيار بديل. ننفذ آلية تفريغ المكالمات من C * ، وسحب بعض البيانات للإثراء من الجداول المقابلة في Oracle ، وضم العينات المستلمة وتعطينا النتيجة ، التي نستخدمها بعد ذلك بطريقة ما (التراجع ، إعادة التكرار ، التحليل ، الإعجاب). السلبيات: العملية متعددة الخطوات ، بالإضافة إلى ذلك ، لا توجد واجهة لموظفي التشغيل.
نتيجة لذلك ، مازلنا نستقر على الخيار الثاني. تم استخدام Apache Spark لعينات من علب مختلفة. جاء جوهر الآلية إلى كود جافا ، والذي ، باستخدام المفاتيح المحددة (المشترك ، مفاتيح قسم وقت الاتصال) ، يسحب البيانات من C * ، وكذلك البيانات اللازمة للإثراء من أي قاعدة بيانات أخرى. ثم ينضم إليهم في ذاكرته ويعرض النتيجة في الجدول الناتج. تم رسم كمامة على شبكة الإنترنت حول الشرارة واتضح أنها قابلة للخدمة تمامًا.
عند حل مشكلة في تحديث البيانات ، فحص اختبار الترويجي مرة أخرى عدة حلول. يتم نقل كل من خلال Sstloader ، وخيار تقسيم الكتلة في منطقة الاختبار إلى جزأين ، كل منهما يدخل بالتناوب في نفس الكتلة مثل العرض الترويجي ، وبالتالي يتم تشغيله منه. عند تحديث الاختبار ، تم التخطيط لتغيير أماكنهم: يتم مسح الجزء الذي نجح في الاختبار وإدخاله في حفلة موسيقية ، ويبدأ الآخر في العمل مع البيانات بشكل منفصل. ومع ذلك ، التفكير مرة أخرى ، قمنا بتقييم أكثر عقلانية البيانات التي ينبغي نقلها ، وأدركنا أن المكالمات نفسها هي كيان غير متناسق للاختبارات ، ولدت بسرعة إذا لزم الأمر ، وهي مجموعة البيانات الترويجي الذي لا يستحق نقل إلى الاختبار. هناك العديد من كائنات التخزين التي تستحق الحركة ، ولكن هذا حرفيًا عبارة عن طاولتين ، وليس ثقيلتين للغاية. لذلك ، جاء Spark مرة أخرى لمساعدتنا كحل ، وبمساعدة كتبناها وبدأنا بنشاط في استخدام نقل البيانات بين الجداول النصية لاختبار prom.
تسمح لنا سياسة النشر الحالية لدينا بالعمل دون عمولات. قبل الحفلة الراقصة ، هناك تمريرة إلزامية للاختبار ، حيث الخطأ ليس مكلفاً للغاية. في حالة الفشل ، يمكنك دائمًا إسقاط casespace ولف المخطط بالكامل من البداية.
لضمان استمرار توافر كاساندرا ، فأنت بحاجة إلى ديسيبل وليس فقط. يجب على كل شخص يعمل مع التطبيق أن يفهم أين وكيف ينظر إلى الوضع الحالي وكيفية تشخيص المشكلات في الوقت المناسب. للقيام بذلك ، نستخدم بنشاط DataStax OpsCenter (إدارة ومراقبة أعباء العمل) ، ومقاييس نظام Cassandra Driver (عدد المهلات للكتابة إلى C * ، وعدد المهلات للقراءة من C * ، والحد الأقصى الكمون ، وما إلى ذلك) ، والرصد عمل التطبيق نفسه ، والعمل مع كاساندرا.
عندما فكرنا في السؤال السابق ، أدركنا أين تكمن مخاطرنا الرئيسية. هذه هي نماذج عرض البيانات التي تقوم بإخراج البيانات من عدة طلبات تخزين مستقلة عن بعضها البعض. بهذه الطريقة يمكننا الحصول على معلومات غير متناسقة. لكن هذه المشكلة ستكون ذات صلة إذا عملنا مع مركز بيانات واحد فقط. لذا فإن الشيء الأكثر منطقية هنا ، بالطبع ، هو القيام بوظيفة الدُفعة المتمثلة في قراءة البيانات على تطبيق تابع لجهة خارجية ، مما يضمن تلقي البيانات في فترة زمنية واحدة. أما بالنسبة للفصل بين القراءة والكتابة من حيث الأداء ، فقد توقفنا هنا من خطر أنه ، مع بعض فقدان الاتصال بين البلدان النامية ، يمكننا الحصول على مجموعتين غير متناسقتين تمامًا.
نتيجة لذلك ، توقفنا في الوقت الحالي عند مستوى التناسق للسجل EACH_QUORUM ، للقراءة - LOCAL_QUORUM
انطباعات موجزة والاستنتاجات
من أجل تقييم الحل الناتج من وجهة نظر الدعم التشغيلي وآفاق مزيد من التطوير ، قررنا التفكير في أي مكان آخر يمكن تطبيق هذا التطور فيه.
إذا كان الأمر أثناء تنقلك ، فقم بتسجيل بيانات لبرامج مثل "الدفع عندما يكون مناسبًا" (تحميل معلومات C * ، والحساب باستخدام البرامج النصية Spark) ، ومطالبات المحاسبة بالتجميع حسب الاتجاهات ، وتخزين الأدوار ، وحساب حقوق وصول المستخدم باستخدام مصفوفة الأدوار.
كما ترون ، ذخيرة واسعة ومتنوعة. وإذا اخترنا معسكر المؤيدين / المعارضين لـ NoSQL ، فسننضم إلى المؤيدين ، حيث حصلنا على مزايانا ، والمكان الذي توقعناه بالضبط.
حتى خيار Cassandra الموجود خارج الصندوق يسمح بالتوسع الأفقي في الوقت الفعلي ، مما يحل دون شك مشكلة زيادة البيانات في النظام. لقد نجحنا في وضع آلية منفصلة محمّلة للغاية في مجمل الدائرة لحساب المجاميع للمكالمات ، وكذلك لفصل مخطط التطبيق ومنطقه ، والتخلص من الممارسة الشريرة المتمثلة في كتابة وظائف مخصصة وكائنات في قاعدة البيانات نفسها. لقد أتيحت لنا الفرصة للاختيار والتكوين ، من أجل الإسراع ، والتي ستحسب بها البلدان النامية ، وأي سجلات بيانات ، قمنا بتأمين أنفسنا من أجل قطرات كل من العقد الفردية والعاصمة بأكملها.
بتطبيق بنيتنا على المشاريع الجديدة ، ولدي بعض الخبرة بالفعل ، أود أن تأخذ على الفور الفروق الدقيقة المذكورة أعلاه ، ومنع بعض الأخطاء ، وتخفيف بعض الزوايا الحادة التي لا يمكن تجنبها في البداية.
على سبيل المثال ، تابع تحديثات Cassandra في الوقت المحدد ، لأن بعض المشكلات التي تلقيناها معروفة بالفعل وتم تصحيحها.
لا تضع قاعدة البيانات نفسها و Spark على العقد نفسها (أو تقسمهما بشدة على مقدار الاستخدام المقبول للموارد) ، لأن Spark يمكنها أن تأكل أكثر من OP المتوقعة ، وسنحصل بسرعة على المشكلة رقم 1 من قائمتنا.
لضخ كفاءة المراقبة والتشغيل في مرحلة اختبار المشروع. في البداية ، يجب مراعاة الحد الأقصى لجميع العملاء المحتملين لحلنا ، لأن بنية قاعدة البيانات ستعتمد في النهاية على هذا.
لف الدائرة الناتجة عدة مرات لتحسين ممكن. حدد الحقول التي يمكن تسلسلها. إن فهم الجداول الإضافية التي يمكننا القيام بها من أجل أن نأخذ في الاعتبار بشكل صحيح ومثالي ، ثم إعادة المعلومات المطلوبة عند الطلب (على سبيل المثال ، على افتراض أنه يمكننا تخزين البيانات نفسها في جداول مختلفة ، مع مراعاة الأعطال المختلفة وفقًا لمعايير مختلفة ، يمكن أن يوفر الكثير وقت المعالج لطلبات القراءة).
إنها لفكرة جيدة أن يتم تركيب TTL على الفور وتنظيف البيانات القديمة.
عند إلغاء تحميل البيانات من Cassandra ، يجب أن يعمل منطق التطبيق وفقًا لمبدأ FETCH ، بحيث لا يتم تحميل جميع الخطوط في الذاكرة في وقت واحد ، ولكن يتم تحديدها على دفعات.
قبل نقل المشروع إلى الحل الموصوف ، من المستحسن التحقق من التسامح مع أخطاء النظام عن طريق إجراء سلسلة من اختبارات التعطل ، مثل فقد البيانات في أحد مراكز البيانات واستعادة البيانات التالفة لفترة معينة وتراجع الشبكة بين مراكز البيانات. لن تسمح لك هذه الاختبارات بتقييم إيجابيات وسلبيات الهيكل المقترح فحسب ، بل ستوفر أيضًا ممارسة جيدة للإحماء للمهندسين الذين يقومون بها ، وستكون المهارة المكتسبة بعيدة عن أن تكون ضرورية إذا تم إعادة إنتاج أعطال النظام في الحفلة الراقصة.
إذا عملنا مع المعلومات الهامة (مثل بيانات الفوترة ، وحساب ديون المشترك) ، فمن الجدير أيضًا الانتباه إلى الأدوات التي ستقلل من المخاطر التي تنشأ بسبب خصائص نظام إدارة قواعد البيانات. على سبيل المثال ، استخدم الأداة المساعدة nodesync (Datastax) ، بعد أن وضعت استراتيجية مثالية لاستخدامها ، بحيث من أجل التناسق لا تشكل حمولة زائدة على كاساندرا واستخدامها فقط لجداول معينة في فترة معينة.
حسنًا ، بعد ستة أشهر من الحياة ، مع كاساندرا؟ بشكل عام ، لا توجد مشاكل لم يتم حلها. الحوادث الخطيرة وفقدان البيانات ، ونحن أيضا لم تسمح. نعم ، كان علي أن أفكر في التعويض عن بعض المشاكل التي لم تكن قد نشأت سابقًا ، لكنها في النهاية لم تطغى على حلنا المعماري. إذا كنت تريد ولا تخشى تجربة شيء جديد ، وفي الوقت نفسه لا تريد أن تشعر بخيبة أمل كبيرة ، فاستعد لحقيقة أن لا شيء يحدث مجانًا. سيتعين عليك أن تكتشف وتحفر في الوثائق وجمع أشعل النار الخاص بك عن تلك الموجودة في الحل القديم ولن تخبرك أي نظرية مقدما بالتحديد عن أشعل النار في انتظارك.