Instagram لديه واحدة من أكبر قواعد بيانات Apache Cassandra في العالم. بدأ المشروع باستخدام كاساندرا في عام 2012 لاستبدال Redis ودعم تنفيذ ميزات التطبيق مثل نظام التعرف على الاحتيال ، Tape و Direct. في البداية ، عملت مجموعات كاساندرا في AWS ، لكن المهندسين لاحقًا قاموا بترحيلهم إلى البنية التحتية لـ Facebook مع جميع أنظمة Instagram الأخرى. عملت كاساندرا بشكل جيد للغاية من حيث الموثوقية والتسامح مع الخطأ. وفي الوقت نفسه ، يمكن تحسين مقاييس وقت الاستجابة بوضوح عند قراءة البيانات.
في العام الماضي ، بدأ فريق دعم Instagram في Cassandra العمل في مشروع يهدف إلى تقليل وقت الاستجابة بشكل كبير في قراءة البيانات في Cassandra ، والتي أطلق عليها المهندسون Rocksandra. في هذه المقالة ، يخبر المؤلف ما الذي دفع الفريق إلى تنفيذ هذا المشروع ، والصعوبات التي يجب التغلب عليها ، ومقاييس الأداء التي يستخدمها المهندسون في البيئات السحابية الداخلية والخارجية.
أسباب الانتقال
يستخدم Instagram بنشاط وعلى نطاق واسع Apache Cassandra كخدمة تخزين ذات قيمة رئيسية. يتم إجراء معظم طلبات Instagram عبر الإنترنت ، وبالتالي ، لتوفير تجربة مستخدم موثوقة وممتعة لمئات الملايين من مستخدمي Instagram ، تتطلب اتفاقيات مستوى الخدمة جدًا أداء النظام.
يلتزم Instagram بتصنيف خمسة إلى تسعة موثوقية. وهذا يعني أن عدد حالات الفشل في أي وقت لا يمكن أن يتجاوز 0.001٪. من أجل تحسين الأداء ، يراقب المهندسون بنشاط الإنتاجية ووقت الاستجابة لمجموعات كاساندرا المختلفة ، والتأكد من أن 99 ٪ من جميع الطلبات تتناسب مع مؤشر معين (تأخير P99).
فيما يلي رسم بياني يوضح التأخير من جانب العميل لواحدة من مجموعات كاساندرا القتالية. يشير اللون الأزرق إلى متوسط سرعة القراءة (5 مللي ثانية) ، بينما يشير اللون البرتقالي إلى سرعة القراءة لـ 99٪ ، بدءًا من 25-60 مللي ثانية. تغييراته تعتمد بشكل كبير على حركة العملاء.
ووجدت الدراسة أن الاندفاعات الحادة في التأخير ترجع إلى حد كبير إلى عمل جامع القمامة JVM. قدم المهندسون مقياسًا يسمى "النسبة المئوية للتوقف في CM" لقياس النسبة المئوية للوقت الذي تم قضاؤه في "إيقاف العالم" بواسطة خادم كاساندرا ، وكان مصحوبًا برفض طلبات العملاء. في ما يلي الرسم البياني أعلاه يوضح مقدار الوقت (في المائة) الذي توقف عند توقف SM باستخدام مثال أحد خوادم كاساندرا القتالية. تراوح المؤشر من 1.25٪ في أوقات أصغر حركة مرور إلى 2.5٪ في أوقات الذروة.
يوضح الرسم البياني أن مثيل خادم كاساندرا هذا يمكن أن يقضي 2.5 ٪ من وقته في جمع القمامة بدلاً من خدمة طلبات العملاء. من الواضح أن العمليات الوقائية للجامع كان لها تأثير كبير على تأخير P99 ، وبالتالي أصبح من الواضح أنه إذا تمكنا من تقليل معدل توقف CM ، فيمكن للمهندسين تقليل معدل التأخير P99 بشكل كبير.
الحل
أباتشي كاساندرا هي قاعدة بيانات موزعة على أساس جافا مع محرك تخزين البيانات الخاص بها على أساس أشجار LSM. وجد المهندسون أن مكونات المحرك مثل جدول الذاكرة ، وأداة الضغط ، ومسارات القراءة / الكتابة ، وأنشأ البعض الآخر العديد من الكائنات في ذاكرة Java الديناميكية ، مما أدى إلى اضطرار JVM إلى إجراء العديد من العمليات العامة الإضافية. لتقليل تأثير آليات التخزين على عمل جامع القمامة ، نظر فريق الدعم في أساليب مختلفة وقرر في نهاية المطاف تطوير محرك C ++ واستبدال المحرك الموجود به.
لم يرغب المهندسون في عمل كل شيء من الصفر ، وبالتالي قرروا اتخاذ RocksDB كأساس.
RocksDB عبارة عن قاعدة بيانات مضمنة عالية الأداء ومفتوحة المصدر لتخزين القيمة الأساسية. إنه مكتوب بلغة C ++ ، ولديه API الخاص بها روابط لغوية رسمية لـ C ++ و C و Java. تم تحسين RocksDB للحصول على أداء عالي ، خاصة على محركات الأقراص السريعة مثل أقراص الحالة الصلبة. يتم استخدامه على نطاق واسع في الصناعة كمحرك تخزين لـ MySQL و mongoDB وقواعد البيانات الشائعة الأخرى.
الصعوبات
في عملية تنفيذ محرك التخزين الجديد على RocksDB ، واجه المهندسون ثلاث مهام صعبة وحلوها.
كانت الصعوبة الأولى هي أن كاساندرا لا تزال تفتقر إلى بنية تسمح بربط معالجات البيانات التابعة لجهات خارجية. هذا يعني أن عمل المحرك الحالي مرتبط بشكل وثيق مع مكونات قاعدة البيانات الأخرى. للعثور على توازن بين إعادة الهيكلة على نطاق واسع والتكرار السريع ، حدد المهندسون واجهة برمجة التطبيقات للمحرك الجديد ، بما في ذلك واجهات القراءة والكتابة والبث الأكثر شيوعًا. وهكذا ، تمكن فريق الدعم من تنفيذ آليات معالجة البيانات الجديدة لواجهة برمجة التطبيقات وإدراجها في مسارات تنفيذ التعليمات البرمجية المناسبة داخل كاساندرا.
كانت الصعوبة الثانية هي أن كاساندرا دعمت أنواع البيانات المنظمة ومخططات الجداول ، في حين أن RocksDB قدم فقط واجهات ذات قيمة رئيسية. قام المهندسون بتحديد خوارزميات التشفير وفك التشفير بعناية لدعم نموذج بيانات كاساندرا داخل هياكل بيانات RocksDB وضمان استمرارية دلالات الاستعلامات المماثلة بين قاعدتي البيانات.
كانت الصعوبة الثالثة مرتبطة بمكون مهم لأي مكون قاعدة بيانات موزعة مثل العمل مع تدفقات البيانات. عند إضافة عقدة أو إزالتها من مجموعة كاساندرا ، تحتاج إلى توزيع البيانات بشكل صحيح بين العقد المختلفة لموازنة الحمل داخل الكتلة. وقد استندت عمليات التنفيذ الحالية لهذه الآليات إلى الحصول على بيانات تفصيلية من محرك قاعدة البيانات الحالي. لذلك ، كان على المهندسين فصلهم عن بعضهم البعض ، وإنشاء طبقة تجريدية وتنفيذ خيار جديد لمعالجة التدفقات باستخدام RocksDB API. للحصول على عرض نطاق ترددي مرتفع ، يقوم فريق الدعم الآن بتوزيع البيانات أولاً على ملفات sst المؤقتة ، ثم يستخدم RocksDB API الخاص "لابتلاع" الملفات ، مما يسمح بتنزيلها في وقت واحد إلى مثيل RocksDB.
مؤشرات الأداء
بعد ما يقرب من عام من التطوير والاختبار ، أكمل المهندسون الإصدار الأول من التنفيذ وتم طرحه بنجاح على العديد من مجموعات Instagram Instagram Cassandra. في إحدى المجموعات القتالية ، انخفض تأخير P99 من 60 مللي ثانية إلى 20 مللي ثانية. كما أظهرت الملاحظات أن نقاط توقف SM في هذه المجموعة انخفضت من 2.5٪ إلى 0.3٪ ، أي 10 مرات تقريبًا!
أراد المهندسون أيضًا التحقق مما إذا كان Rocksandra يمكن أن يؤدي أداءً جيدًا في بيئة سحابية عامة. قام فريق الدعم بإعداد مجموعة كاساندرا في AWS باستخدام ثلاث حالات i3.8 xlarge EC2 ، كل منها بمعالج 32 نواة ، و 244 غيغابايت من ذاكرة الوصول العشوائي ، وغارة صفرية لأربعة محركات أقراص فلاش NVMe.
بالنسبة للاختبارات المقارنة ، استخدمنا
NDBench ومخطط الجدول الافتراضي للإطار.
TABLE emp ( emp_uname text PRIMARY KEY, emp_dept text, emp_first text, emp_last text )
قام المهندسون مسبقًا بتحميل 250 مليون صف من 6 كيلوبايت لكل منها (يتم تخزين حوالي 500 جيجابايت من البيانات على كل خادم). بعد ذلك ، قم بإعداد 128 قارئًا وكتابًا في NDBench.
قام فريق الدعم باختبار العديد من الأحمال وقياس المتوسط / P99 / P999 وقت القراءة والكتابة. تُظهر الرسوم البيانية أدناه أن Rocksandra أظهرت أوقات استجابة للقراءة والكتابة أقل بكثير وأكثر ثباتًا.
قام المهندسون أيضًا بفحص الحمل في وضع القراءة بدون كتابة ووجدوا أنه مع نفس تأخير القراءة P99 (2 مللي ثانية) ، فإن Rocksandra قادرة على توفير أكثر من 10 أضعاف سرعة قراءة المعلومات (300 K / s لـ Rocksandra مقابل 30 K / s لـ C * 3.0).
الخطط المستقبلية
افتتح فريق دعم Instagram رمز
Rocksandra وإطار عمل تقييم الأداء . يمكنك تنزيلها من Github وتجربتها في بيئتك الخاصة. تأكد من إخبارنا بما حدث!
كخطوة تالية ، يعمل الفريق بنشاط على إضافة دعم أوسع لوظائف C * ، مثل الفهارس الثانوية والإصلاحات والمزيد. بالإضافة إلى ذلك ، يقوم المهندسون بتطوير
بنية محرك قاعدة البيانات في C * من أجل نقل هذه التطورات إلى مجتمع Apache Cassandra.
