على مدى السنوات القليلة الماضية، تحولت قواعد بيانات السلاسل الزمنية من شيء غريب (متخصص للغاية يستخدم إما في أنظمة المراقبة المفتوحة (والمرتبطة بحلول محددة) أو في مشاريع البيانات الضخمة) إلى "منتج استهلاكي". على أراضي الاتحاد الروسي، من الضروري تقديم شكر خاص إلى Yandex وClickHouse على هذا. حتى هذه اللحظة، إذا كنت بحاجة إلى تخزين كمية كبيرة من بيانات السلاسل الزمنية، كان عليك إما أن تتصالح مع الحاجة إلى بناء مكدس Hadoop ضخم وصيانته، أو التواصل مع البروتوكولات الفردية لكل نظام.
قد يبدو أنه في عام 2019، ستتألف المقالة التي تستحق استخدام TSDB من جملة واحدة فقط: "فقط استخدم ClickHouse". ولكن... هناك فروق دقيقة.
في الواقع، تتطور ClickHouse بنشاط، وقاعدة المستخدمين آخذة في النمو، والدعم نشط للغاية، ولكن هل أصبحنا رهائن للنجاح العام لـ ClickHouse، الذي طغى على الحلول الأخرى، التي ربما تكون أكثر فعالية/موثوقة؟
في بداية العام الماضي، بدأنا في إعادة صياغة نظام المراقبة الخاص بنا، حيث نشأ سؤال حول اختيار قاعدة بيانات مناسبة لتخزين البيانات. أريد أن أتحدث عن تاريخ هذا الاختيار هنا.
صياغة المشكلة
بادئ ذي بدء، مقدمة ضرورية. لماذا نحتاج إلى نظام المراقبة الخاص بنا أصلاً وكيف تم تصميمه؟
بدأنا تقديم خدمات الدعم في عام 2008، وبحلول عام 2010 أصبح من الواضح أنه أصبح من الصعب تجميع البيانات حول العمليات التي تحدث في البنية التحتية للعميل مع الحلول التي كانت موجودة في ذلك الوقت (نحن نتحدث عن سامحني الله، كاكتي، زابيكس والجرافيت الناشئة).
متطلباتنا الرئيسية كانت:
- دعم (في ذلك الوقت - العشرات، وفي المستقبل - المئات) من العملاء ضمن نظام واحد وفي نفس الوقت وجود نظام إدارة تنبيه مركزي؛
- المرونة في إدارة نظام التنبيه (تصعيد التنبيهات بين الموظفين المناوبين، والجدولة، وقاعدة المعرفة)؛
- القدرة على تفصيل الرسوم البيانية بعمق (قدمت Zabbix في ذلك الوقت رسومًا بيانية على شكل صور) ؛
- تخزين كمية كبيرة من البيانات على المدى الطويل (سنة أو أكثر) والقدرة على استرجاعها بسرعة.
في هذه المقالة نحن مهتمون بالنقطة الأخيرة.
بالحديث عن التخزين، كانت المتطلبات كما يلي:
- يجب أن يعمل النظام بسرعة؛
- ومن المستحسن أن يكون لدى النظام واجهة SQL؛
- يجب أن يكون النظام مستقرًا وله قاعدة مستخدمين نشطة ودعم (بمجرد أن واجهنا الحاجة إلى دعم أنظمة مثل MemcacheDB، التي لم تعد قيد التطوير، أو وحدة تخزين MooseFS الموزعة، والتي تم الاحتفاظ بمتعقب الأخطاء الخاص بها باللغة الصينية: نكرر هذه القصة لمشروعنا الذي لم يرد)؛
- الامتثال لنظرية CAP: الاتساق (مطلوب) - يجب أن تكون البيانات محدثة، ولا نريد ألا يتلقى نظام إدارة التنبيه بيانات جديدة ويطلق تنبيهات حول عدم وصول البيانات لجميع المشاريع؛ تسامح القسم (مطلوب) - لا نريد الحصول على نظام Split Brain؛ التوفر (ليس حرجًا، إذا كانت هناك نسخة متماثلة نشطة) - يمكننا التبديل إلى نظام النسخ الاحتياطي بأنفسنا في حالة وقوع حادث، باستخدام الكود.
ومن الغريب أنه في ذلك الوقت تبين أن MySQL هو الحل المثالي بالنسبة لنا. كانت بنية البيانات لدينا بسيطة للغاية: معرف الخادم، ومعرف العداد، والطابع الزمني، والقيمة؛ تم ضمان أخذ عينات سريعة من البيانات الساخنة من خلال مجموعة كبيرة من المخزن المؤقت، وتم ضمان أخذ عينات من البيانات التاريخية بواسطة SSD.
وهكذا، حصلنا على عينة من البيانات الجديدة لمدة أسبوعين، مع تفاصيل تصل إلى 200 مللي ثانية قبل تقديم البيانات بالكامل، وعشنا في هذا النظام لفترة طويلة جدًا.
وفي الوقت نفسه، مر الوقت وازدادت كمية البيانات. بحلول عام 2016، وصلت أحجام البيانات إلى عشرات التيرابايت، وهو ما كان بمثابة نفقات كبيرة في سياق تخزين SSD المستأجر.
بحلول هذا الوقت، أصبحت قواعد البيانات العمودية منتشرة على نطاق واسع، وبدأنا في التفكير بنشاط: في قواعد البيانات العمودية، يتم تخزين البيانات، كما تفهم، في أعمدة، وإذا نظرت إلى بياناتنا، فمن السهل رؤية عدد كبير من البيانات عدد التكرارات التي يمكن، إذا كنت تستخدم قاعدة بيانات عمودية، ضغطها باستخدام الضغط.
ومع ذلك، استمر النظام الرئيسي للشركة في العمل بثبات، ولم أرغب في تجربة التبديل إلى شيء آخر.
في عام 2017، في مؤتمر Percona Live في سان خوسيه، ربما أعلن مطورو Clickhouse عن أنفسهم لأول مرة. للوهلة الأولى، كان النظام جاهزًا للإنتاج (حسنًا، Yandex.Metrica هو نظام إنتاج قاسٍ)، وكان الدعم سريعًا وبسيطًا، والأهم من ذلك، كان التشغيل بسيطًا. منذ عام 2018، بدأنا عملية الانتقال. ولكن بحلول ذلك الوقت، كان هناك الكثير من أنظمة TSDB "للبالغين" والتي تم اختبارها عبر الزمن، وقررنا تخصيص وقت كبير ومقارنة البدائل للتأكد من عدم وجود حلول بديلة لـ Clickhouse، وفقًا لمتطلباتنا.
بالإضافة إلى متطلبات التخزين المحددة بالفعل، ظهرت متطلبات جديدة:
- يجب أن يوفر النظام الجديد على الأقل نفس أداء MySQL على نفس الكمية من الأجهزة؛
- يجب أن يشغل تخزين النظام الجديد مساحة أقل بكثير؛
- يجب أن يظل نظام إدارة قواعد البيانات (DBMS) سهل الإدارة؛
- كنت أرغب في تغيير التطبيق إلى الحد الأدنى عند تغيير نظام إدارة قواعد البيانات.
ما هي الأنظمة التي بدأنا في النظر فيها؟
أباتشي خلية/أباتشي إمبالا
مكدس Hadoop قديم تم اختباره في المعركة. في الأساس، إنها واجهة SQL مبنية على تخزين البيانات بتنسيقات أصلية على HDFS.
الايجابيات.
- مع التشغيل المستقر، من السهل جدًا قياس البيانات.
- توجد حلول أعمدة لتخزين البيانات (مساحة أقل).
- تنفيذ سريع جدًا للمهام المتوازية عند توفر الموارد.
سلبيات.
- إنه Hadoop، ومن الصعب استخدامه. إذا لم نكن مستعدين لاتخاذ حل جاهز في السحابة (ولسنا مستعدين من حيث التكلفة)، فيجب تجميع المكدس بالكامل ودعمه على أيدي المسؤولين، ونحن لا نريد ذلك حقًا هذا.
- يتم تجميع البيانات .
ولكن:
يتم تحقيق السرعة من خلال زيادة عدد خوادم الحوسبة. ببساطة، إذا كنا شركة كبيرة تعمل في مجال التحليلات، ومن الأهمية بمكان بالنسبة للشركة تجميع المعلومات في أسرع وقت ممكن (حتى على حساب استخدام كمية كبيرة من موارد الحوسبة)، فقد يكون هذا هو خيارنا. لكننا لم نكن مستعدين لمضاعفة أسطول الأجهزة لتسريع المهام.
الكاهن / بينوت
هناك الكثير حول TSDB على وجه التحديد، ولكن مرة أخرى، مكدس Hadoop.
هنالك .
بكلمات قليلة: يبدو Druid/Pinot أفضل من Clickhouse في الحالات التي:
- لديك طبيعة غير متجانسة للبيانات (في حالتنا، نسجل فقط سلاسل زمنية لمقاييس الخادم، وهذا في الواقع جدول واحد. ولكن قد تكون هناك حالات أخرى: السلاسل الزمنية للمعدات، والسلاسل الزمنية الاقتصادية، وما إلى ذلك - لكل منها هيكلها الخاص، والتي تحتاج إلى تجميعها ومعالجتها).
- علاوة على ذلك، هناك الكثير من هذه البيانات.
- تظهر وتختفي الجداول والبيانات ذات السلاسل الزمنية (أي وصول مجموعة من البيانات وتم تحليلها وحذفها).
- لا يوجد معيار واضح يمكن من خلاله تقسيم البيانات.
وفي الحالات المعاكسة، يكون أداء ClickHouse أفضل، وهذه هي حالتنا.
كليكهاوس
- مثل SQL
- من السهل إدارتها.
- يقول الناس أنه يعمل.
يتم إدراجه في القائمة المختصرة للاختبار.
التدفق
بديل أجنبي لـ ClickHouse. من السلبيات: التوافر العالي موجود فقط في النسخة التجارية، ولكن يجب مقارنته.
يتم إدراجه في القائمة المختصرة للاختبار.
كاساندرا
من ناحية، نحن نعلم أنه يتم استخدامه لتخزين السلاسل الزمنية المترية بواسطة أنظمة المراقبة مثل، على سبيل المثال، أو أوكميتر. ومع ذلك، هناك تفاصيل.
كاساندرا ليست قاعدة بيانات عمودية بالمعنى التقليدي. يبدو الأمر أشبه بعرض صف، ولكن يمكن أن يحتوي كل سطر على عدد مختلف من الأعمدة، مما يجعل من السهل تنظيم عرض عمودي. وبهذا المعنى، فمن الواضح أنه بحد أقصى 2 مليار عمود، من الممكن تخزين بعض البيانات في أعمدة (وبنفس السلسلة الزمنية). على سبيل المثال، يوجد في MySQL حد يبلغ 4096 عمودًا ومن السهل العثور على خطأ بالرمز 1117 إذا حاولت القيام بنفس الشيء.
يركز محرك Cassandra على تخزين كميات كبيرة من البيانات في نظام موزع بدون سيد، وتتعلق نظرية Cassandra CAP المذكورة أعلاه أكثر بـ AP، أي حول توفر البيانات ومقاومة التقسيم. وبالتالي، يمكن أن تكون هذه الأداة رائعة إذا كنت تحتاج فقط إلى الكتابة في قاعدة البيانات هذه ونادرًا ما تقرأ منها. وهنا من المنطقي استخدام كاساندرا كمخزن "بارد". وهذا يعني أنه مكان موثوق وطويل الأمد لتخزين كميات كبيرة من البيانات التاريخية التي نادرًا ما تكون هناك حاجة إليها، ولكن يمكن استرجاعها إذا لزم الأمر. ومع ذلك، من أجل اكتمالها، سنختبرها أيضًا. ولكن، كما قلت سابقًا، ليست هناك رغبة في إعادة كتابة التعليمات البرمجية لحل قاعدة البيانات المحدد بشكل فعال، لذلك سنختبره بشكل محدود إلى حد ما - دون تكييف بنية قاعدة البيانات مع تفاصيل Cassandra.
محب العمل
حسنًا، من باب الفضول، قررنا اختبار أداء وحدة تخزين Prometheus - فقط لفهم ما إذا كنا أسرع أم أبطأ من الحلول الحالية وبأي حجم.
منهجية الاختبار والنتائج
لذلك، قمنا باختبار 5 قواعد بيانات في التكوينات الستة التالية: ClickHouse (عقدة واحدة)، ClickHouse (جدول موزع لـ 6 عقد)، InfluxDB، Mysql 1، Cassandra (3 عقد) وPrometheus. خطة الاختبار هي كما يلي:
- تحميل البيانات التاريخية لمدة أسبوع (840 مليون قيمة يوميًا؛ 208 ألف مقياس)؛
- نقوم بإنشاء حمل تسجيل (تم أخذ 6 أوضاع تحميل بعين الاعتبار، انظر أدناه)؛
- بالتوازي مع التسجيل، نقوم بشكل دوري بإجراء التحديدات، ومحاكاة طلبات المستخدم الذي يعمل مع الرسوم البيانية. لكي لا نعقد الأمور أكثر من اللازم، اخترنا بيانات لـ 10 مقاييس (وهذا هو بالضبط عدد المقاييس الموجودة على الرسم البياني لوحدة المعالجة المركزية) لمدة أسبوع.
نقوم بالتحميل من خلال محاكاة سلوك وكيل المراقبة لدينا، والذي يرسل القيم إلى كل مقياس مرة واحدة كل 15 ثانية. وفي الوقت نفسه، نحن مهتمون بالتنوع:
- العدد الإجمالي للمقاييس التي يتم كتابة البيانات فيها؛
- الفاصل الزمني لإرسال القيم إلى مقياس واحد؛
- حجم الدفعة.
حول حجم الدفعة. نظرًا لأنه لا يُنصح بتحميل جميع قواعد بياناتنا التجريبية تقريبًا بإدراجات فردية، فسنحتاج إلى مرحل يجمع المقاييس الواردة ويجمعها في مجموعات ويكتبها في قاعدة البيانات كإدراج دفعي.
أيضًا، لفهم كيفية تفسير البيانات المستلمة بشكل أفضل، لنتخيل أننا لا نرسل مجموعة من المقاييس فحسب، بل يتم تنظيم المقاييس في خوادم - 125 مقياسًا لكل خادم. الخادم هنا هو ببساطة كيان افتراضي - فقط لفهم أنه، على سبيل المثال، 10000 مقياس يتوافق مع حوالي 80 خادمًا.
وهنا، مع أخذ كل هذا في الاعتبار، توجد أوضاع تحميل كتابة قاعدة البيانات الستة لدينا:
هناك نقطتان هنا. أولاً، بالنسبة لكاساندرا، تبين أن أحجام الدُفعات هذه كبيرة جدًا، حيث استخدمنا قيم 50 أو 100. وثانيًا، نظرًا لأن بروميثيوس يعمل بشكل صارم في وضع السحب، أي. إنه يذهب بنفسه ويجمع البيانات من مصادر المقاييس (وحتى بوابة الدفع، على الرغم من الاسم، لا تغير الوضع بشكل أساسي)، تم تنفيذ الأحمال المقابلة باستخدام مجموعة من التكوينات الثابتة.
نتائج الاختبار هي كما يلي:
ما هو الجدير بالذكر: عينات سريعة بشكل خيالي من بروميثيوس، وعينات بطيئة للغاية من كاساندرا، وعينات بطيئة بشكل غير مقبول من InfluxDB؛ ومن حيث سرعة التسجيل، فازت ClickHouse بالجميع، وبروميثيوس لا يشارك في المسابقة، لأنه يقوم بإدخال نفسه ولا نقيس أي شيء.
ونتيجة لذلك،: أظهر ClickHouse و InfluxDB أنهما الأفضل، ولكن لا يمكن إنشاء مجموعة من Influx إلا على أساس إصدار Enterprise، الذي يكلف المال، في حين أن ClickHouse لا يكلف شيئًا ويتم تصنيعه في روسيا. من المنطقي أن يكون الاختيار في الولايات المتحدة الأمريكية لصالح inInfluxDB، وفي بلدنا لصالح ClickHouse.
المصدر: www.habr.com