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