ما المتطلبات التي يجب أن يلتزم بها تخزين البيانات الوصفية لخدمة السحابة؟ نعم ، ليس الأكثر اعتيادية ، ولكن للمؤسسات التي تدعم مراكز البيانات الموزعة جغرافيًا و Active-Active. من الواضح أن النظام يجب أن يتدرج جيدًا ، وأن يتحمل الأخطاء ، ويود أن يكون قادرًا على تنفيذ تناسق قابل للتخصيص للعمليات.

فقط كاساندرا مناسبة لجميع هذه المتطلبات ، ولا يوجد شيء آخر مناسب. وتجدر الإشارة إلى أن كاساندرا رائعة حقًا ، ولكن العمل معها يشبه السفينة الدوارة.


في تقرير في Highload ++ 2017 ، قرر Andrei Smirnov ( smira ) أنه ليس من المثير للاهتمام التحدث عن الخير ، لكنه تحدث بالتفصيل عن كل مشكلة واجهها: حول فقدان البيانات والفساد ، حول الزومبي وفقدان الأداء. هذه القصص تذكرنا حقًا بالسفينة الدوارة ، ولكن هناك حل لجميع المشاكل ، حيث نرحب بك في القط.

حول المتحدث: يعمل Andrey Smirnov في Virtustream ، وهي شركة تنفذ التخزين السحابي للمؤسسات. الفكرة هي أن أمازون مشروطًا بالخدمة السحابية للجميع ، و Virtustream يفعل الأشياء المحددة التي تحتاجها شركة كبيرة.

بضع كلمات حول Virtustream

نحن نعمل في فريق صغير بعيد تمامًا ، ونشارك في أحد حلول Virtustream السحابية. هذه سحابة لتخزين البيانات.


يتحدث بكل بساطة ، هذا هو API متوافق مع S3 حيث يمكنك تخزين الكائنات. بالنسبة لأولئك الذين لا يعرفون ما هو S3 ، فهي مجرد واجهة برمجة تطبيقات HTTP يمكنك من خلالها تحميل الكائنات إلى السحابة في مكان ما ، واستعادتها ، وحذفها ، والحصول على قائمة بالكائنات ، وما إلى ذلك. علاوة على ذلك - ميزات أكثر تعقيدًا تعتمد على هذه العمليات البسيطة.

لدينا بعض الميزات المميزة التي لا تمتلكها أمازون. واحد منهم هو ما يسمى بالمناطق الجغرافية. في الحالة المعتادة ، عندما تقوم بإنشاء مستودع وتقول أنك ستقوم بتخزين الكائنات في السحابة ، يجب عليك تحديد منطقة. تعد المنطقة في الأساس مركز بيانات ، ولن تغادر الكائنات الخاصة بك مركز البيانات هذا أبدًا. إذا حدث له شيء ، فلن تكون أغراضك متاحة.

نحن نقدم مناطق جغرافية توجد فيها البيانات في وقت واحد في العديد من مراكز البيانات (DC) ، على الأقل في مركزين ، كما في الصورة. يمكن للعميل الاتصال بأي مركز بيانات ، لأنه شفاف. يتم نسخ البيانات بينهما ، أي أننا نعمل في وضع Active-Active ، وبشكل مستمر. وهذا يوفر للعميل ميزات إضافية ، بما في ذلك:

1. موثوقية أكبر للتخزين والقراءة والكتابة في حالة فشل التيار المستمر أو فقدان الاتصال ؛
   
2. توفر البيانات حتى إذا فشل أحد DCs ؛
   
3. إعادة توجيه العمليات إلى العاصمة "الأقرب".
   

هذه فرصة مثيرة للاهتمام - حتى لو كانت هذه DCs متباعدة جغرافيًا ، فقد يكون بعضها أقرب إلى العميل في نقاط زمنية مختلفة. والوصول إلى البيانات إلى أقرب العاصمة ببساطة أسرع.


من أجل تقسيم البناء الذي سنتحدث عنه إلى أجزاء ، سأقدم تلك الأشياء المخزنة في السحابة كقطعتين كبيرتين:

1. أول جزء بسيط من كائن هو البيانات . لم تتغير ، تم تنزيلها مرة واحدة وهذا كل شيء. الشيء الوحيد الذي يمكن أن يحدث لهم لاحقًا هو أنه يمكننا إزالته إذا لم تعد هناك حاجة إليه.

كان مشروعنا السابق مرتبطًا بتخزين سعة تخزينية للبيانات ، لذا لم تكن لدينا مشاكل في تخزين البيانات. كانت هذه بالفعل مهمة محلولة بالنسبة لنا.

2. البيانات الوصفية . كل منطق الأعمال ، والأكثر إثارة للاهتمام ، يتعلق بالمنافسة: الوصول ، والسجلات ، وإعادة الكتابة - في منطقة البيانات الوصفية.

تأخذ البيانات الوصفية عن الكائن في حد ذاتها أكبر تعقيد للمشروع ، وتخزن البيانات الوصفية مؤشرًا إلى كتلة البيانات المخزنة للكائن.

من وجهة نظر المستخدم ، هذا كائن واحد ، ولكن يمكننا تقسيمه إلى قسمين. اليوم سأتحدث فقط عن البيانات الوصفية .

أرقام

• البيانات : 4 بايت.
• مجموعات البيانات الوصفية : 3.
• كائنات : 40 مليار.
• حجم البيانات الوصفية : 160 تيرابايت (بما في ذلك النسخ المتماثل).
• معدل التغيير (البيانات الوصفية): 3000 كائن / ثانية.

إذا نظرت إلى هذه المؤشرات بعناية ، فإن أول ما يلفت انتباهك هو متوسط ​​الحجم الصغير جدًا للكائن المخزن. لدينا الكثير من البيانات الوصفية لكل وحدة حجم من البيانات الرئيسية. بالنسبة لنا لم تكن مفاجأة أقل مما ربما بالنسبة لك الآن.

خططنا أنه سيكون لدينا على الأقل ترتيب للبيانات ، إن لم يكن 2 ، أكثر من البيانات الوصفية. أي أن كل كائن سيكون أكبر بكثير ، وستقل كمية البيانات الوصفية. نظرًا لأن البيانات أرخص في التخزين ، فإن عمليات أقل معها ، والبيانات الوصفية أكثر تكلفة بكثير من حيث الأجهزة ، ومن حيث الخدمة وتنفيذ العمليات المختلفة عليها.

علاوة على ذلك ، تتغير هذه البيانات بسرعة عالية إلى حد ما. لقد أعطيت قيمة الذروة هنا ، والقيمة غير الذروة ليست أقل بكثير ، ولكن مع ذلك ، يمكن الحصول على حمولة كبيرة إلى حد ما في نقاط زمنية محددة.

تم الحصول على هذه الأرقام بالفعل من نظام عمل ، ولكن دعونا نعود قليلاً إلى وقت تصميم التخزين السحابي.

اختيار مستودع للبيانات الوصفية

عندما واجهنا التحدي الذي نريد أن يكون لدينا مناطق جغرافية ، نشطة نشطة ، ونحتاج إلى تخزين البيانات الوصفية في مكان ما ، اعتقدنا أنه يمكن أن يكون؟

من الواضح أن المستودع (قاعدة البيانات) يجب أن يكون له الخصائص التالية:

• الدعم النشط ؛
• قابلية التوسع.

نود حقًا أن يكون منتجنا شائعًا للغاية ، ولا نعرف كيف سينمو في نفس الوقت ، لذلك يجب أن يتوسع النظام.

• توازن تحمل الخطأ وموثوقية التخزين.

يجب تخزين البيانات الوصفية بشكل آمن ، لأنه إذا فقدناها ، وكان هناك رابط للبيانات الموجودة فيها ، فسوف نفقد الكائن بأكمله.

• تناسق قابل للتخصيص للعمليات.

نظرًا لحقيقة أننا نعمل في العديد من وحدات تحكم المجال (DCs) ونسمح باحتمال عدم توفر وحدات تحكم المجال DC ، علاوة على ذلك ، تكون وحدات التحكم عن بُعد بعيدة عن بعضها البعض ، ولا يمكننا ، خلال معظم عمليات واجهة برمجة التطبيقات ، أن نطلب إجراء هذه العملية في وقت واحد اثنين من العاصمة. سيكون بطيئًا جدًا ومستحيلًا إذا كان DC الثاني غير متوفر. لذلك ، يجب أن يعمل جزء من العمليات محليًا في وحدة تحكم المجال DC واحدة.

ولكن من الواضح أن نوعًا من التقارب يجب أن يحدث في وقت ما ، وبعد حل جميع التعارضات ، يجب أن تكون البيانات مرئية في كلا مركزي البيانات. لذلك ، يجب تعديل اتساق العمليات.

من وجهة نظري ، كاساندرا مناسبة لهذه المتطلبات.

كاساندرا

سأكون سعيدًا جدًا إذا لم يكن علينا استخدام كاساندرا ، لأنها كانت بالنسبة لنا نوعًا من التجربة الجديدة. ولكن لا يوجد شيء آخر مناسب. يبدو لي أن هذا هو الوضع الأكثر حزنًا في السوق لأنظمة التخزين هذه - لا يوجد بديل .

ما هي كاساندرا؟

هذه قاعدة بيانات موزعة ذات قيمة رئيسية. من وجهة نظر الهندسة المعمارية والأفكار المضمنة فيها ، يبدو لي أن كل شيء رائع. إذا فعلت ذلك ، سأفعل نفس الشيء. عندما بدأنا لأول مرة ، فكرنا في كتابة نظام تخزين البيانات الوصفية الخاص بنا. ولكن كلما زاد إدراكنا ، كلما ازداد إدراكنا أنه سيتعين علينا القيام بشيء مشابه جدًا لكساندرا ، والجهود التي سنبذلها عليها لا تستحق ذلك. بالنسبة للتطوير بأكمله ، لم يكن لدينا سوى شهر ونصف . سيكون من الغريب إنفاقهم على كتابة قاعدة بياناتك.

إذا تم طبقات كاساندرا مثل كعكة طبقة ، سأختار 3 طبقات:

1. تخزين KV محلي على كل عقدة.
هذه مجموعة من العقد ، يمكن لكل منها تخزين بيانات القيمة الرئيسية محليًا.

2. مشاركة البيانات على العقد (التجزئة المتسقة).
يمكن لـ Cassandra توزيع البيانات بين عُقد المجموعة ، بما في ذلك النسخ المتماثل ، وهي تفعل ذلك بطريقة يمكن أن تنمو فيها الكتلة أو تقل حجمها ، وسيتم إعادة توزيع البيانات.

3. منسق لإعادة توجيه الطلبات إلى العقد الأخرى.
عندما نصل إلى البيانات الخاصة ببعض الاستعلامات من تطبيقنا ، يمكن لـ Cassandra توزيع استعلامنا في العقد حتى نحصل على البيانات التي نريدها ومع مستوى الاتساق الذي نحتاجه - نريد قراءتها فقط النصاب القانوني ، أو تريد النصاب القانوني مع اثنين من DCs ، إلخ.


بالنسبة لنا ، سنتان مع كاساندرا - إنها السفينة الدوارة أو السفينة الدوارة - كل ما تريد. بدأ كل شيء في أعماقنا ، لم يكن لدينا خبرة مع كاساندرا. كنا خائفين. بدأنا ، وكان كل شيء على ما يرام. ولكن بعد ذلك يبدأ السقوط المستمر والإقلاع: المشكلة ، كل شيء سيئ ، لا نعرف ماذا نفعل ، نحصل على أخطاء ، ثم نحل المشكلة ، إلخ.

هذه الوقايات الدوارة ، من حيث المبدأ ، لا تنتهي حتى يومنا هذا.

جيد

الفصل الأول والأخير ، حيث أقول أن كاساندرا رائع. إنه رائع حقًا ، نظام رائع ، ولكن إذا واصلت القول كم هو جيد ، أعتقد أنك لن تكون مهتمًا. لذلك ، سنولي المزيد من الاهتمام بالسيئ ، ولكن لاحقًا.

كاساندرا جيدة حقا.

• هذا أحد الأنظمة التي تتيح لنا الحصول على وقت استجابة بالمللي ثانية ، أي أقل من 10 مللي ثانية. هذا أمر جيد بالنسبة لنا ، لأن وقت الاستجابة بشكل عام مهم بالنسبة لنا. تعتبر العملية باستخدام البيانات الوصفية بالنسبة لنا جزءًا فقط من أي عملية تتعلق بتخزين كائن ما ، سواء كان يتلقى أو يسجل.
• من وجهة نظر التسجيل ، يتم تحقيق قابلية التوسع العالية . يمكنك الكتابة في كاساندرا بسرعة جنونية ، وفي بعض الحالات يكون ذلك ضروريًا ، على سبيل المثال ، عندما نقوم بنقل كميات كبيرة من البيانات بين السجلات.
• كاساندرا متسامحة مع الخطأ . لا يؤدي سقوط عقدة واحدة على الفور إلى حدوث مشاكل ، على الرغم من أنها ستبدأ عاجلاً أم آجلاً. تعلن كاساندرا أنه ليس لديها نقطة واحدة من الفشل ، ولكن في الواقع ، هناك نقاط فشل في كل مكان. في الواقع ، الشخص الذي عمل مع قاعدة البيانات يعرف أنه حتى انهيار العقدة ليس شيئًا يعاني عادةً حتى الصباح. عادة ، يجب إصلاح هذا الوضع بشكل أسرع.
• البساطة. ومع ذلك ، مقارنةً بقواعد بيانات Cassandra القياسية الأخرى ، من السهل فهم ما يجري. في كثير من الأحيان ، حدث خطأ ما ، ونحن بحاجة إلى فهم ما يحدث. لدى كاساندرا فرصًا أكبر لمعرفة ذلك ، الوصول إلى أصغر برغي ، على الأرجح ، أكثر من قاعدة بيانات أخرى.

خمس قصص سيئة

أكرر ، كاساندرا جيدة ، إنها تعمل من أجلنا ، لكني سأخبر خمس قصص عن السيئة. أعتقد أن هذا هو ما قرأته. سأعطي القصص بترتيب زمني ، على الرغم من أنها ليست مرتبطة ارتباطًا وثيقًا ببعضها البعض.


هذه القصة كانت الأكثر حزناً بالنسبة لنا. نظرًا لأننا نخزن بيانات المستخدم ، فإن أسوأ شيء ممكن هو فقدانها ، وفقدها إلى الأبد ، كما حدث في هذه الحالة. لقد وفرنا طرقًا لاستعادة البيانات إذا فقدناها في كاساندرا ، لكننا فقدناها حتى لا نتمكن حقًا من استردادها.

من أجل شرح كيفية حدوث ذلك ، سيتعين علي التحدث قليلاً عن كيفية ترتيب كل شيء داخلنا.


من منظور S3 ، هناك بعض الأشياء الأساسية:

• دلو - يمكن تخيله على أنه كتالوج ضخم يقوم المستخدم بتحميل كائن إليه (يشار إليه فيما يلي باسم الدلو).
• لكل كائن اسم (مفتاح) وبيانات وصفية مرتبطة به: الحجم ونوع المحتوى ومؤشر لبيانات الكائن. في الوقت نفسه ، لا يقتصر حجم الدلو على أي شيء. أي أنه يمكن أن يكون 10 مفاتيح ، ربما 100 مليار مفتاح - لا يوجد فرق.
• أي عمليات تنافسية ممكنة ، أي قد يكون هناك العديد من عمليات التعبئة التنافسية في نفس المفتاح ، قد يكون هناك حذف تنافسي ، إلخ.

في وضعنا ، يمكن أن تحدث عمليات نشطة نشطة ، بما في ذلك بشكل تنافسي في مختلف البلدان النامية ، وليس فقط في واحدة. لذلك ، نحن بحاجة إلى نوع من مخطط الحفظ الذي سيسمح لنا بتنفيذ هذا المنطق. في النهاية ، اخترنا سياسة بسيطة: يفوز الإصدار الأخير المسجل. في بعض الأحيان تحدث العديد من العمليات التنافسية ، ولكن ليس من الضروري أن يقوم عملاؤنا بذلك عن قصد. قد يكون مجرد طلب بدأ ، ولكن العميل لم ينتظر إجابة ، وحدث شيء آخر ، وحاول مرة أخرى ، وما إلى ذلك.

لذلك ، لدينا جدولين أساسيين:

1. جدول الأشياء . في ذلك ، يرتبط زوج - اسم الدلو واسم المفتاح - بنسخته الحالية. إذا تم حذف الكائن ، فلا يوجد شيء في هذا الإصدار. إذا كان الكائن موجودًا ، فهناك نسخته الحالية. في الواقع ، في هذا الجدول نغير فقط مجال الإصدار الحالي.
   
2. جدول إصدار الكائنات . ندرج فقط إصدارات جديدة في هذا الجدول. في كل مرة يتم تنزيل كائن جديد ، نقوم بإدراج إصدار جديد في جدول الإصدار ، ونعطيه رقمًا فريدًا ، ونحفظ جميع المعلومات المتعلقة به ، وفي النهاية نقوم بتحديث الرابط إليه في جدول الكائن.
   

يوضح الشكل مثالاً لكيفية ارتباط جداول الكائنات وإصدارات الكائنات.


هنا كائن يحتوي على نسختين - أحدهما حالي والآخر قديم ، يوجد كائن تم حذفه بالفعل ، ولا يزال إصداره موجودًا. نحن بحاجة إلى تنظيف الإصدارات غير الضرورية من وقت لآخر ، أي حذف شيء لا يشير إليه أي شخص آخر. علاوة على ذلك ، لا نحتاج إلى حذفه على الفور ، يمكننا القيام بذلك في الوضع المؤجل. هذا هو تنظيفنا الداخلي ، نحذف فقط ما لم يعد هناك حاجة إليه.

حدثت مشكلة.


كانت المشكلة هي: لدينا نشطان ، اثنان من DC. في كل DC ، يتم تخزين البيانات الوصفية في ثلاث نسخ ، أي لدينا 3 + 3 - فقط 6 نسخ متماثلة. عندما يتصل بنا العملاء ، نقوم بتنفيذ العمليات باتساق (من وجهة نظر كاساندرا يطلق عليه LOCAL_QUORUM). أي أنه من المؤكد أن السجل (أو القراءة) حدث في نسختين متماثلتين في العاصمة المحلية. هذا ضمان - وإلا ستفشل العملية.

ستحاول كاساندرا دائمًا الكتابة في جميع الخطوط الستة - 99 ٪ من الوقت سيكون كل شيء على ما يرام. في الواقع ، ستكون جميع النسخ المتماثلة الستة هي نفسها ، ولكنها مضمونة لنا 2.

كان لدينا وضع صعب ، على الرغم من أنه لم يكن حتى منطقة جغرافية. حتى بالنسبة للمناطق العادية الموجودة في وحدة تحكم المجال DC ، ما زلنا نخزن النسخة الثانية من البيانات الوصفية في وحدة تحكم المجال DC أخرى. هذه قصة طويلة ، ولن أعطي كل التفاصيل. ولكن في النهاية ، كانت لدينا عملية تنظيف أزلت الإصدارات غير الضرورية.

ثم نشأت نفس المشكلة. عملت عملية التنظيف أيضًا مع اتساق النصاب المحلي في مركز بيانات واحد ، لأنه لا يوجد معنى في تشغيله في اثنين - سيقاتلون بعضهم البعض.

كان كل شيء على ما يرام حتى اتضح أن مستخدمينا لا يزالون يكتبون في بعض الأحيان إلى مركز بيانات آخر ، لم نشك في ذلك. تم إعداد كل شيء فقط في حالة العاشق ، ولكن اتضح أنهم كانوا يستخدمونه بالفعل.


في معظم الأوقات ، كان كل شيء على ما يرام حتى يوم واحد نشأ موقف عندما تم نسخ سجل في جدول الإصدار في كل من DCs ، ولكن تبين أن السجل في جدول الكائن كان في DC واحد فقط ، لكنه لم يدخل في الثاني. وبناءً على ذلك ، فإن إجراء التنظيف ، الذي تم إطلاقه في أول (علوي) من العاصمة ، رأى أن هناك نسخة لم يكن أحد يشير إليها وحذفها. ولم أحذف الإصدار فقط ، ولكن أيضًا بالطبع البيانات - كل شيء تمامًا ، لأنه مجرد كائن غير ضروري. وهذا الإزالة غير قابل للإلغاء.

بالطبع ، هناك "ازدهار" أبعد من ذلك ، لأنه لا يزال لدينا سجل في جدول الكائنات يشير إلى إصدار لم يعد موجودًا.

لذا في المرة الأولى التي فقدنا فيها البيانات ، وفقدناها بشكل لا رجعة فيه - جيد قليلاً.

الحل

ماذا تفعل في وضعنا ، كل شيء بسيط.

نظرًا لأن لدينا بيانات مخزنة في مركزي بيانات ، فإن عملية التنظيف هي عملية تقارب وتزامن. يجب أن نقرأ البيانات من كلا DCs. ستعمل هذه العملية فقط عند توفر كلا DC. نظرًا لأنني قلت أن هذه عملية متأخرة ولا تحدث أثناء معالجة واجهة برمجة التطبيقات ، فهذا ليس مخيفًا.

الاتساق ALL هو سمة من سمات كاساندرا 2. في كاساندرا 3 ، كل شيء أفضل قليلاً - هناك مستوى من الاتساق ، والذي يسمى النصاب القانوني في كل DC. ولكن على أي حال ، هناك مشكلة في أنها بطيئة ، لأنه ، أولاً ، يجب أن نتحول إلى وحدة تحكم عن بعد. ثانيًا ، في حالة الاتساق بين جميع العقد الست ، فهذا يعني أنها تعمل بسرعة أسوأ من هذه العقد الست.

ولكن في نفس الوقت ، تحدث ما يسمى بعملية إصلاح القراءة ، عندما لا تكون جميع النسخ المتماثلة متزامنة. أي عندما فشل التسجيل في مكان ما ، تقوم هذه العملية بإصلاحها في وقت واحد. هكذا تعمل كاساندرا.

عندما حدث ذلك ، تلقينا شكوى من العميل بأن الكائن غير متوفر. لقد اكتشفنا ذلك ، وفهمنا السبب ، وأول شيء أردنا القيام به هو معرفة عدد الأشياء الأخرى التي لدينا. قمنا بتشغيل نص برمجي حاول العثور على بناء مشابه لهذا عندما كان هناك إدخال في جدول واحد ، ولكن لم يكن هناك إدخال في جدول آخر.

فجأة وجدنا أن لدينا 10٪ من هذه السجلات . ليس هناك ما هو أسوأ من ذلك ، ربما لم يكن ليحدث لو لم نكن نخمن أن الأمر ليس كذلك. كانت المشكلة مختلفة.



تسللت الزومبي إلى قاعدة بياناتنا. هذا هو الاسم شبه الرسمي لهذه المشكلة. لفهم ماهيتها ، عليك التحدث عن كيفية عمل الإزالة في كاساندرا.


على سبيل المثال ، لدينا بعض البيانات x التي يتم تسجيلها وتكرارها بشكل مثالي لجميع النسخ المتماثلة الستة. إذا أردنا حذفها ، فقد لا تتم الإزالة ، مثل أي عملية في كاساندرا ، على جميع العقد.

على سبيل المثال ، أردنا ضمان تناسق 2 من 3 في DC واحد. اسمح بإجراء عملية الحذف على خمس عقد ، ولكن تبقى في سجل واحد ، على سبيل المثال ، لأن العقدة لم تكن متاحة في تلك اللحظة.


إذا حذفنا هذا ثم حاولنا قراءة "أريد 2 من أصل 3" بنفس الاتساق ، فإن كاساندرا ، التي ترى القيمة وغيابها ، تفسر هذا على أنه وجود البيانات. أي عندما تقرأ مرة أخرى ، ستقول: "أوه ، هناك بيانات!" ، على الرغم من حذفها. لذلك ، لا يمكنك الحذف بهذه الطريقة.


يزيل كاساندرا بشكل مختلف. الحذف هو في الواقع رقم قياسي . عندما نحذف البيانات ، تكتب كاساندرا بعض العلامات الصغيرة تسمى Tombstone (علامة مميزة). يشير إلى حذف البيانات. وبالتالي ، إذا قرأنا رمز الحذف والبيانات في نفس الوقت ، تفضل كاساندرا دائمًا رمز الحذف في هذه الحالة وتقول أنه لا توجد بيانات في الواقع. هذا ما تحتاجه.

Tombstone — , , , , - , . Tombstone . Tombstone gc_grace_period . , , .

?

Repair

Cassandra , Repair (). — , . , , , , / , , - - , .. . Repair , .


, - , - . Repair , , . - , — . , .


Repair, , , , — , . 6 . — , , .


, — , - . , . , - , , , .

الحل

, :

• Repair .

, repair. , , .

• , Tombstones, , repair.

repair — , repair. , , 10-20 , , 3 . Tombstone , . , , -.


Cassandra, . .

S3 . , — 10 , 100 . API, — . , , , , , . , , , — , . .

API?


, — , , — , , . . — . , , . , , Cassandra. , — , , , .

, , , , . , . , , . , - , .

Cassandra , . , , , , , .


, Cassandra composite key . , — , - , — . , . ? , , !

, , , , — , .

. Cassandra , Cassandra . , , Cassandra, : , , SQL .. !


. Cassandra ? , , API. , , , , ( ) . , .

, . , , , . , — — . , , , .

Cassandra , . : « 100 », , , , , , 100, .

, ( ), — , , . , , , , , - . 100 , - , , . , SQL .

Cassandra , , Java, . , Large Partition , . — , , , , — . , , garbage collection .. .

, , , , .

, , - .


, , . . , Large Partition.

:

1. ( , - );
   
2. , , . , .
   

, , , key_hash 0. , , . , . , , .

, .


— , , , - - .

— , N ? , Large Partition, — . , . : . , , , , - . , . , , .


— , , - . - , , . , , . , , ..

— , ? , . ? - md5- — , - 30 — , - . . , , .


, , , , . — , . , . , - - - , - - — . , . .

, , , .

• .
• .
• Cassandra.
• Online- ( ).

لدينا بعض حالة الدلو الآن ، يتم تقسيمها بطريقة أو بأخرى إلى أقسام. ثم نفهم أن بعض الأقسام كبيرة جدًا أو صغيرة جدًا. نحن بحاجة إلى العثور على قسم جديد ، من ناحية ، سيكون مثاليًا ، أي أن حجم كل قسم سيكون أقل من بعض حدودنا ، وسيكون أكثر أو أقل تجانسًا. في هذه الحالة ، يجب أن يتطلب الانتقال من الحالة الحالية إلى حالة جديدة الحد الأدنى من الإجراءات. من الواضح أن أي انتقال يتطلب مفاتيح متحركة بين الأقسام ، ولكن كلما قلنا نقلها ، كان ذلك أفضل.

لقد فعلناها. ربما يكون الجزء الذي يتعامل مع اختيار التوزيع هو أصعب جزء في الخدمة بأكملها ، إذا تحدثنا عن العمل مع البيانات الوصفية بشكل عام. نعيد كتابتها ، ونعيد صياغتها ، وما زلنا نقوم بذلك ، لأن بعض العملاء أو أنماط معينة من إنشاء المفاتيح دائمًا ما تجد نقطة ضعف في هذا المخطط.

على سبيل المثال ، افترضنا أن الدلو سينمو أكثر أو أقل بالتساوي. أي أننا حصلنا على نوع من التوزيع ، ونأمل أن تنمو جميع الأقسام وفقًا لهذا التوزيع. لكننا وجدنا عميلًا يكتب دائمًا في النهاية ، بمعنى أن مفاتيحه دائمًا مرتبة. طوال الوقت يتفوق في القسم الأخير ، الذي ينمو بسرعة بحيث يمكن أن يكون في الدقيقة 100 ألف مفتاح. و 100 ألف هي تقريبًا القيمة التي تناسبها في قسم واحد.

ببساطة لن يكون لدينا الوقت لمعالجة مثل هذه المفاتيح الإضافية باستخدام خوارزمية لدينا ، وكان علينا تقديم توزيع أولي خاص لهذا العميل. نظرًا لأننا نعرف كيف تبدو مفاتيحه ، إذا رأينا أنه هو ، فإننا نبدأ فقط في إنشاء أقسام فارغة مسبقًا في النهاية ، حتى يتمكن من الكتابة بهدوء هناك ، وفي الوقت الحالي سيكون لدينا القليل من الراحة حتى التكرار التالي ، عندما يكون علينا مرة أخرى إعادة توزيع كل شيء.

كل هذا يحدث عبر الإنترنت بمعنى أننا لا نوقف العملية. قد تكون هناك عمليات للقراءة والكتابة ، في أي وقت يمكنك طلب قائمة مفاتيح. ستكون دائمًا متسقة ، حتى لو كنا في عملية إعادة تقسيم.

إنه مثير للاهتمام للغاية ، وتبين مع كاساندرا. هنا يمكنك اللعب مع الحيل المتعلقة بحقيقة أن كاساندرا قادرة على حل النزاعات. إذا كتبنا قيمتين مختلفتين على نفس السطر ، فإن القيمة التي لها طابع زمني أكبر تفوز.

عادةً ما يكون الطابع الزمني هو الطابع الزمني الحالي ، ولكن يمكن تمريره يدويًا. على سبيل المثال ، نريد كتابة قيمة إلى سلسلة ، والتي يجب فركها على أي حال إذا كتب العميل شيئًا بنفسه. أي أننا نقوم بنسخ بعض البيانات ، لكننا نريد أن يتمكن العميل ، إذا كتب معنا فجأة في نفس الوقت ، من استبدالها. ثم يمكننا فقط نسخ بياناتنا باستخدام طابع زمني قليلاً من الماضي. بعد ذلك ، فإن أي تسجيل حالي سيتعطل عمداً ، بغض النظر عن الترتيب الذي تم فيه التسجيل.

تتيح لك هذه الحيل القيام بذلك عبر الإنترنت.

الحل

• لا تسمح أبدًا بظهور قسم كبير .
• قم بفصل البيانات عن طريق المفتاح الأساسي حسب المهمة.

إذا تم التخطيط لشيء مشابه لقسم كبير في مخطط البيانات ، فيجب أن تحاول على الفور القيام بشيء حيال ذلك - معرفة كيفية كسره وكيفية الابتعاد عنه. وينشأ ذلك عاجلاً أم آجلاً ، لأن أي فهرس مقلوب ينشأ عاجلاً أم آجلاً في أي مهمة تقريبًا. لقد أخبرتك بالفعل عن مثل هذه القصة - لدينا مفتاح دلو في الكائن ، ونحتاج إلى الحصول على قائمة مفاتيح من الدلو - في الواقع ، هذا فهرس.

علاوة على ذلك ، يمكن أن يكون القسم كبيرًا ليس فقط من البيانات ، ولكن أيضًا من شواهد القبور (علامات الحذف). من وجهة نظر كاساندرا الداخلية (لا نراهم أبداً من الخارج) ، فإن علامات الحذف هي بيانات أيضًا ، ويمكن أن يكون القسم كبيرًا إذا تم حذف الكثير من الأشياء فيه ، لأن الحذف هو سجل. لا يجب أن تنسى هذا أيضًا.


قصة أخرى ثابتة هي أن هناك خطأ ما من البداية إلى النهاية. على سبيل المثال ، ترى أن وقت الاستجابة من كاساندرا قد ازداد ، فإنه يستجيب ببطء. كيف تفهم وتفهم ماهية المشكلة؟ لا توجد إشارة خارجية على الإطلاق بأن المشكلة موجودة.


على سبيل المثال ، سأقدم رسمًا بيانيًا - هذا هو متوسط ​​وقت استجابة المجموعة ككل. يظهر أن لدينا مشكلة - الحد الأقصى لوقت الاستجابة هو 12 ثانية - هذه هي المهلة الداخلية لـ Cassandra. هذا يعني أنها سوف تنتهي بنفسها. إذا كانت المهلة أعلى من 12 ثانية ، فهذا يعني على الأرجح أن جامع القمامة يعمل ، وأن كاساندرا ليس لديها حتى وقت للرد في الوقت المناسب. تجيب بنفسها عن طريق المهلة ، ولكن وقت الاستجابة لمعظم الطلبات ، كما قلت ، يجب أن يكون في المتوسط ​​خلال 10 مللي ثانية.

على الرسم البياني ، تجاوز المتوسط ​​بالفعل مئات المللي ثانية - حدث خطأ ما. ولكن بالنظر إلى هذه الصورة ، من المستحيل فهم السبب.



ولكن إذا قمت بتوسيع نفس الإحصائيات حول عقد كاساندرا ، يمكنك أن ترى ، من حيث المبدأ ، أن جميع العقد لا شيء تقريبًا ، ولكن وقت الاستجابة للعقدة الواحدة يختلف حسب ترتيب الحجم. على الأرجح ، هناك نوع من المشاكل معه.

الإحصائيات على العقد تغير الصورة بالكامل. هذه الإحصائيات من جانب التطبيق. ولكن هنا من الصعب جدًا في الواقع فهم المشكلة. عندما يصل تطبيق إلى كاساندرا ، فإنه يصل إلى بعض العقدة ، ويستخدمها كمنسق. أي أن التطبيق يعطي طلبًا ، ويقوم المنسق بإعادة توجيهه إلى النسخ المتماثلة مع البيانات. أولئك الذين يجيبون بالفعل ، والمنسق يشكل الجواب النهائي مرة أخرى.

ولكن لماذا يستجيب المنسق ببطء؟ ربما تكون المشكلة معه ، على هذا النحو ، أي أنه يتباطأ ويجيب ببطء؟ أو ربما يتباطأ ، لأن النسخ المتماثلة تستجيب له ببطء؟ إذا كانت النسخ المتماثلة تستجيب ببطء ، من وجهة نظر التطبيق ، فستبدو استجابة بطيئة من المنسق ، على الرغم من أنها لا علاقة لها بها.

هنا وضع سعيد - من الواضح أن عقدة واحدة فقط تستجيب ببطء ، وعلى الأرجح أن المشكلة فيها.

تعقيد التفسير

• وقت استجابة المنسق (العقدة مقابل النسخة المتماثلة نفسها).
• جدول محدد أو العقدة بأكملها؟
• وقفة GC؟ تجمع مؤشر ترابط غير كاف؟
• الكثير من SSTables غير المضغوطة؟

من الصعب دائمًا فهم الخطأ. يحتاج فقط إلى الكثير من الإحصائيات والمراقبة ، سواء من جانب التطبيق أو من كاساندرا نفسها ، لأنه إذا كان سيئًا حقًا ، فلا يوجد شيء مرئي من كاساندرا. يمكنك إلقاء نظرة على مستوى الاستعلامات الفردية ، على مستوى كل جدول محدد ، في كل عقدة محددة.

قد يكون هناك ، على سبيل المثال ، موقف حيث يحتوي جدول واحد لما يسمى في Cassandra SSTables (ملفات منفصلة) على الكثير. للقراءة ، لدى كاساندرا ، تقريبًا ، الفرز عبر جميع SSTables. إذا كان هناك عدد كبير جدًا منهم ، فإن عملية الفرز تستغرق وقتًا طويلاً ، وتبدأ القراءة في الترهل.

الحل هو الضغط ، مما يقلل من عدد هذه SSTables ، ولكن تجدر الإشارة إلى أنه يمكن أن يكون فقط على عقدة واحدة لجدول معين. نظرًا لأن كاساندرا ، للأسف ، مكتوبة بلغة جافا وتعمل على JVM ، ربما ذهب جامع القمامة إلى فترة توقف بحيث لم يعد لديه وقت للرد. عندما يتوقف جامع القمامة مؤقتًا ، لا يتباطأ طلباتك فحسب ، ولكن يبدأ التفاعل داخل مجموعة Cassandra بين العقد في التباطؤ . تبدأ عُقد بعضها البعض بالهبوط ، أي أنها سقطت ، ميتة.

يبدأ موقف أكثر متعة ، لأنه عندما ترى العقدة أن عقدة أخرى معطلة ، فإنها أولاً لا ترسل الطلبات إليها ، وثانياً ، تبدأ في محاولة حفظ البيانات التي ستحتاج إلى نسخها إلى عقدة أخرى في نفسه محليًا ، لذلك يبدأ في قتل نفسه ببطء ، إلخ.

هناك حالات يمكن فيها حل هذه المشكلة ببساطة باستخدام الإعدادات الصحيحة. على سبيل المثال ، قد يكون هناك موارد كافية ، كل شيء على ما يرام ورائع ، ولكن مجرد تجمع سلسلة ، وعددها حجم ثابت ، يحتاج إلى زيادة.

أخيرًا ، ربما نحتاج إلى الحد من القدرة التنافسية على جانب السائق. في بعض الأحيان يحدث أن يتم إرسال العديد من الطلبات التنافسية ، ومثل أي قاعدة بيانات ، لا تستطيع كاساندرا التعامل معها وتذهب إلى المركز عندما يزداد وقت الاستجابة بشكل كبير ، ونحن نحاول إعطاء المزيد والمزيد من العمل.

فهم السياق

هناك دائمًا بعض السياق للمشكلة - ما يحدث في المجموعة ، سواء كان الإصلاح يعمل الآن ، على أي عقدة ، وفي أي مساحات رئيسية ، وفي أي جدول.

على سبيل المثال ، كانت لدينا مشاكل سخيفة مع الحديد. رأينا أن جزءًا من العقد بطيء. اكتشف لاحقًا أن السبب هو أنه في BIOS كانت معالجاتها في وضع توفير الطاقة. لسبب ما ، أثناء التثبيت الأولي للحديد ، حدث هذا ، وتم استخدام ما يقرب من 50 ٪ من موارد المعالج مقارنة بالعقد الأخرى.

قد يكون فهم هذه المشكلة أمرًا صعبًا في الواقع. العَرَض هذا - يبدو أن العقدة تقوم بالضغط ، لكنها تفعل ذلك ببطء. في بعض الأحيان يتم توصيله بالحديد ، وأحيانًا لا ، ولكن هذا مجرد خلل كاساندرا آخر.

لذلك ، فإن المراقبة إلزامية وتحتاج إلى الكثير. كلما كانت الميزة في كاساندرا أكثر تعقيدًا ، كلما كانت أبعد من الكتابة والقراءة البسيطة ، كلما زادت المشاكل المتعلقة بها ، وأسرع في قتل قاعدة بيانات تحتوي على عدد كاف من الاستعلامات. لذلك ، إذا أمكن ، لا تنظر إلى بعض الرقائق "اللذيذة" وحاول استخدامها ، فمن الأفضل تجنبها قدر الإمكان. ليس من الممكن دائما - بالطبع ، عاجلا أو آجلا من الضروري.


القصة الأخيرة حول كيف أفسدت كاساندرا البيانات. في هذه الحالة ، حدث ذلك داخل كاساندرا. كان ذلك مثيرا للاهتمام.

لقد رأينا ذلك مرة واحدة أسبوعيًا في قاعدة البيانات الخاصة بنا تظهر عدة عشرات من الخطوط التالفة - فهي مسدودة حرفياً بالقمامة. علاوة على ذلك ، تتحقق كاساندرا من البيانات التي تذهب إلى مدخلاتها. على سبيل المثال ، إذا كانت سلسلة ، فيجب أن تكون في utf8. ولكن في هذه السطور كانت القمامة ، وليس utf8 ، ولم تقدم كاساندرا حتى أي علاقة بها. عندما أحاول حذف (أو القيام بشيء آخر) ، لا يمكنني حذف قيمة ليست utf8 ، لأنه ، على وجه الخصوص ، لا يمكنني إدخالها حيث ، لأنه يجب أن يكون المفتاح utf8.

تظهر خطوط مدللة ، مثل وميض ، في مرحلة ما ، ثم تختفي مرة أخرى لعدة أيام أو أسابيع.

بدأنا في البحث عن مشكلة. اعتقدنا أنه ربما كانت هناك مشكلة في عقدة معينة كنا نتعامل معها ، ونفعل شيئًا مع البيانات ، وننسخ SSTables. ربما ، على الرغم من كل ذلك ، يمكنك مشاهدة النسخ المتماثلة لهذه البيانات؟ ربما هذه النسخ المتماثلة لها عقدة مشتركة ، أصغر عامل مشترك؟ ربما تعطل بعض العقدة؟ لا ، لا شيء من هذا القبيل.

ربما شيء مع قرص؟ هل البيانات تالفة على القرص؟ لا مرة أخرى.

ربما ذكرى؟ لا! متناثرة عبر كتلة.

ربما هذا هو نوع من مشكلة النسخ المتماثل؟ عقدة واحدة أفسدت كل شيء واستنساخ قيمة سيئة؟ - كلا.

أخيرًا ، ربما هذه مشكلة تطبيق؟

علاوة على ذلك ، في مرحلة ما ، بدأت الخطوط التالفة في الظهور في مجموعتين من كاساندرا. عمل أحدهما على الإصدار 2.1 ، والثاني على الثالث. يبدو أن كاساندرا مختلفة ، لكن المشكلة هي نفسها. ربما ترسل خدمتنا بيانات سيئة؟ ولكن كان من الصعب تصديق ذلك. تتحقق كاساندرا من صحة بيانات الإدخال ؛ ولا يمكنها كتابة البيانات المهملة. ولكن فجأة؟

لا شيء يناسبها.

تم العثور على إبرة!

لقد ناضلنا طويلاً وشاقًا حتى اكتشفنا مشكلة صغيرة: لماذا لدينا نوعًا من تفريغ التصادم من JVM على العقد التي لم نهتم بها كثيرًا؟ وبطريقة ما يبدو بشكل مريب في جامع القمامة تتبع المكدس ... ولسبب ما ، بعض تتبع المكدس مسدود أيضًا بالقمامة.

في النهاية ، أدركنا - أوه ، لسبب ما ، نحن نستخدم JVM من الإصدار القديم لعام 2015 . كان هذا هو الشيء المشترك الوحيد الذي توحد فيه مجموعات كاساندرا في إصدارات مختلفة من كاساندرا.

ما زلت لا أعرف ما هي المشكلة ، لأنه لم تتم كتابة أي شيء حول هذا الأمر في ملاحظات الإصدار الرسمية من JVM. ولكن بعد التحديث ، اختفى كل شيء ، لم تعد المشكلة تنشأ. علاوة على ذلك ، لم تحدث في المجموعة منذ اليوم الأول ، ولكن من نقطة ما ، على الرغم من أنها عملت على نفس JVM لفترة طويلة.

استعادة البيانات

ما الدرس الذي تعلمناه من هذا:

● النسخ الاحتياطي لا طائل منه.
البيانات ، كما اكتشفنا ، تالفة في الثانية التي تم تسجيلها فيها. في اللحظة التي دخلت فيها البيانات إلى المنسق ، كانت تالفة بالفعل.

● من الممكن استعادة الأعمدة غير التالفة جزئيًا.
لم تتلف بعض الأعمدة ، يمكننا قراءة هذه البيانات ، واستعادتها جزئيًا.

● في النهاية ، كان علينا أن نتعافى من مصادر مختلفة.
كان لدينا بيانات احتياطية للبيانات في الكائن ، ولكن في البيانات نفسها. لإعادة الاتصال بالكائن ، استخدمنا السجلات ، إلخ.

● سجلات لا تقدر بثمن!
تمكنا من استرداد جميع البيانات التالفة ، ولكن في النهاية من الصعب جدًا الوثوق في قاعدة البيانات إذا فقدت بياناتك حتى بدون أي إجراء من جانبك.

الحل

• تحديث JVM بعد اختبار مكثف.
• رصد تحطم JVM.
• الحصول على نسخة من البيانات مستقلة عن كاساندرا.

على سبيل المثال: حاول أن يكون لديك نوع من نسخة مستقلة عن كاساندرا من البيانات التي يمكنك استردادها إذا لزم الأمر. قد يكون هذا هو الحل الأخير. دع الأمر يستغرق الكثير من الوقت والموارد ، ولكن يجب أن يكون هناك بعض الخيارات التي تسمح لك بإعادة البيانات.

البق

● جودة اختبار الإصدار رديئة
عندما تبدأ العمل مع كاساندرا ، هناك شعور مستمر (خاصة إذا كنت تتحرك ، نسبيًا ، من قواعد بيانات "جيدة" ، على سبيل المثال ، PostgreSQL) أنه إذا قمت بإصلاح خطأ في إصدار الإصدار السابق ، فستضيف بالتأكيد واحدة جديدة. والخطأ ليس هراء ، وعادة ما يكون البيانات تالفة أو سلوك غير صحيح آخر.

● المشاكل المستمرة مع الميزات المعقدة
كلما كانت الميزة أكثر تعقيدًا ، زادت المشاكل ، والأخطاء ، وما إلى ذلك.

● لا تستخدم الإصلاح التدريجي في 2.1
الإصلاح الشهير ، الذي تحدثت عنه ، والذي يعمل على إصلاح تناسق البيانات ، في الوضع القياسي ، عندما يستقصي جميع العقد ، يعمل بشكل جيد. ولكن ليس في ما يسمى بالوضع التدريجي (عندما يتخطى الإصلاح البيانات التي لم تتغير منذ الإصلاح السابق ، وهو أمر منطقي تمامًا). تم الإعلان عنه منذ فترة طويلة ، رسميًا ، كميزة موجودة ، ولكن الجميع يقول: "لا ، في الإصدار 2.1 ، لا تستخدمه أبدًا! سيفتقد بالتأكيد شيئا. في 3 نقوم بإصلاحه. "

● ولكن لا تستخدم الإصلاح المتزايد في 3.x
عندما ظهرت النسخة الثالثة ، بعد بضعة أيام قالوا: "لا ، لا يمكنك استخدامها في الإصدار الثالث. هناك قائمة من 15 خطأ ، لذلك لا تستخدم بأي حال من الأحوال إصلاحًا تدريجيًا. في الرابع سنقوم بعمل أفضل! "

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

● الحاجة إلى تتبع JIRA

إذا قمت بتوزيع جميع قواعد البيانات على طيف التنبؤ ، بالنسبة لي ، فإن كاساندرا على اليسار في المنطقة الحمراء. هذا لا يعني أنه أمر سيئ ، عليك فقط الاستعداد لحقيقة أن كاساندرا لا يمكن التنبؤ بها بأي معنى للكلمة: سواء في طريقة عملها أو في حقيقة أن شيئًا ما يمكن أن يحدث.

أتمنى أن تجد أشواطاً أخرى وأن تخطوها ، لأنه من وجهة نظري ، مهما كانت كاساندرا جيدة ، وبالتأكيد ليست مملة. فقط تذكر المطبات على الطريق!

اجتماع مفتوح لنشطاء HighLoad ++

في 31 يوليو في موسكو ، في تمام الساعة 19:00 ، سيتم عقد اجتماع للمتحدثين ولجنة البرنامج والناشطين في مؤتمر HighLoad ++ 2018 لمطوري الأنظمة ذات الأحمال العالية ، وسننظم عصفًا ذهنيًا صغيرًا حول برنامج هذا العام حتى لا تفوت أي شيء جديد وهام. الاجتماع مفتوح ، ولكن عليك التسجيل .

دعوة لتقديم أوراق

قبول الطلبات للتقارير في Highload ++ 2018. تنتظر لجنة البرنامج الملخص الخاص بك حتى نهاية الصيف.