الانتقال إلى ClickHouse: بعد 3 سنوات

قبل ثلاث سنوات ، ظهر فيكتور تارنافسكي وأليكسي ميلوفيدوف من شركة ياندكس على خشبة المسرح HighLoad ++ قال، أي ClickHouse جيد ، وكيف أنه لا يبطئ. وكان في المرحلة التالية الكسندر زايتسيف с أبلغ عن حول الانتقال إلى كليكهاوس من DBMS تحليلي آخر ومع استنتاج أن كليكهاوس، بالطبع ، جيد ، لكن ليس مريحًا جدًا. عندما تكون الشركة في عام 2016 و LifeStreet، حيث عمل Alexander في ذلك الوقت ، كان يترجم نظامًا تحليليًا متعدد البيتابايت إلى كليكهاوس، كان "طريقًا من الطوب الأصفر" رائعًا ، مليئًا بالمخاطر غير المعروفة - كليكهاوس ثم بدا وكأنه حقل ألغام.

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

شارك Alexander في الأنظمة الموزعة منذ عام 2003 ، حيث قام بتطوير مشاريع كبيرة في MySQL ، أوراكل и فيرتيكا. في النهاية HighLoad ++ 2019 الإسكندر أحد رواد الاستخدام كليكهاوس، قال ما هو نظام إدارة قواعد البيانات هذا الآن. سنتعرف على الميزات الرئيسية كليكهاوس: كيف تختلف عن الأنظمة الأخرى وفي أي الحالات يكون استخدامها أكثر فعالية. باستخدام الأمثلة ، دعنا نفكر في الممارسات الجديدة والمثبتة بالمشروع لبناء أنظمة قائمة على كليكهاوس.

بأثر رجعي: ما حدث قبل 3 سنوات

قبل ثلاث سنوات نقلنا الشركة و LifeStreet في كليكهاوس من قاعدة بيانات تحليلات مختلفة ، وبدا ترحيل تحليلات شبكة الإعلانات كما يلي:

• يونيو 2016. In مفتوحة المصدر ظهر كليكهاوس وبدأت مشروعنا.
• أغسطس. إثبات المفهوم: شبكة إعلانية كبيرة وبنية أساسية و 200-300 تيرابايت من البيانات ؛
• اكتوبر. بيانات الإنتاج الأولى ؛
• ديسمبر. الحمل الكامل للمنتج - 10-50 مليار حدث في اليوم.
• يونيو 2017. الترحيل الناجح للمستخدمين إلى كليكهاوس2,5 بيتابايت من البيانات على مجموعة مكونة من 60 خادمًا.

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

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

وبالطبع ، نحن نساعد في الانتقال إلى كليكهاوس с MySQL, فيرتيكا, Oracle, البرقوق الأخضر, الانزياح نحو الأحمر وأنظمة أخرى. لقد شاركنا في مجموعة متنوعة من عمليات الترحيل وكلها كانت ناجحة.

لماذا حتى الانتقال إلى كليكهاوس

لا تبطئ! هذا هو السبب الرئيسي. كليكهاوس - قاعدة بيانات سريعة جدًا لسيناريوهات مختلفة:

اقتباسات عشوائية من الأشخاص الذين يعملون معهم كليكهاوس.

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

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

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

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

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

الانتقال إلى ClickHouse

للتبديل إلى كليكهاوس بشيء ما ، ما عليك سوى ثلاثة أشياء:

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

مشكلة التحرك

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

• المعاملات ؛
• قيود؛
• التناسق؛
• مؤشرات.
• تحديث / حذف;
• القيم الفارغة;
• ميلي ثانية.
• نوع التحويل التلقائي ؛
• صلات متعددة
• أقسام تعسفية
• أدوات إدارة الكتلة.

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

والشيء الرئيسي هو أنه في كليكهاوس بعض الممارسات والأساليب القياسية لا تعمل أو لا تعمل بالطريقة التي اعتدنا عليها. كل ما يظهر في كليكهاوس، يتوافق مع "انقر فوق طريقة المنزل"، أي. وظائف مختلفة عن قواعد البيانات الأخرى. على سبيل المثال:

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

سيناريوهات ClickHouse

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

من وجهة نظري، كليكهاوس - نفس الغرابة. لإعادة صياغة Wigner ، يمكننا أن نقول هذا: المذهل هو الكفاءة التي لا يمكن تصورها كليكهاوس في مجموعة متنوعة من التطبيقات التحليلية!

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

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

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

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

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

السلاسل الزمنية

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

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

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

الآن هناك نمو في قواعد البيانات المتخصصة التي تقيس السلاسل الزمنية. في الموقع محركات DB يتم ترتيب قواعد البيانات المختلفة بطريقة ما ، ويمكن عرضها حسب النوع:

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

من الرواد الشركة كلودفلاري (CDNمزود). يراقبون CDN من خلال كليكهاوس (DNS-طلبات ، HTTP-طلبات) بحمل ضخم - 6 ملايين حدث في الثانية. كل شيء يمر كافكا، يذهب إلى كليكهاوس، والذي يوفر القدرة على رؤية لوحات المعلومات في الوقت الفعلي للأحداث في النظام.

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

Percona بنيت في كليكهاوس داخل PMMللحفاظ على المراقبة بشكل مختلف MySQL.

متطلبات محددة

قواعد بيانات السلاسل الزمنية لها متطلباتها الخاصة.

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

دعونا نرى كيف يتم تلبية هذه المتطلبات كليكهاوس.

القيادة

В كليكهاوس مخطط ل السلاسل الزمنية يمكن القيام به بطرق مختلفة ، اعتمادًا على درجة انتظام البيانات. من الممكن بناء نظام على بيانات منتظمة عندما نعرف جميع المقاييس مسبقًا. على سبيل المثال ، فعل كلودفلاري مع المراقبة CDN هو نظام مُحسَّن جيدًا. يمكنك بناء نظام أكثر عمومية يراقب البنية التحتية بأكملها ، والخدمات المختلفة. في حالة البيانات غير النظامية ، لا نعرف مقدمًا ما الذي نراقبه - وربما تكون هذه هي الحالة الأكثر شيوعًا.

بيانات منتظمة. الأعمدة. المخطط بسيط - أعمدة مع الأنواع الضرورية:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

بيانات غير منتظمة. المصفوفات:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

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

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

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

لكنها لا تزال تعمل بالسرعة الكافية. هناك طريقة أخرى لتخزين البيانات غير النظامية وهي عن طريق الصفوف.

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

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

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

دعنا نقارن ثلاث طرق:

Детали

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

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

في إحدى الشركات التي تستخدم هذا الأسلوب (على سبيل المثال ، اوبر) ، يتم تقطيع المصفوفات إلى أجزاء من 128 عنصرًا. لا يتم تخزين بيانات عدة آلاف من المقاييس بحجم 200 تيرابايت من البيانات / اليوم في مصفوفة واحدة ، ولكن في 10 أو 30 مصفوفة بمنطق تخزين خاص.

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

مخطط هجين

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

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

الترميز والضغط

إلى السلاسل الزمنية من المهم مدى جودة حزم البيانات ، لأن مجموعة المعلومات يمكن أن تكون كبيرة جدًا. في كليكهاوس هناك مجموعة من الأدوات لتحقيق تأثير الضغط 1:10 ، 1:20 ، وأحيانًا أكثر. هذا يعني أن 1 تيرابايت من البيانات غير المضغوطة على القرص تستهلك 50-100 جيجابايت. الحجم الصغير جيد ، يمكن قراءة البيانات ومعالجتها بشكل أسرع.

لتحقيق مستوى عالٍ من الضغط ، كليكهاوس يدعم برامج الترميز التالية:

مثال على الجدول:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

يوضح هذا مقدار المساحة التي تشغلها نفس البيانات ، ولكن باستخدام برامج ترميز وضغط مختلفة:

• في ملف GZIP على القرص ؛
• في ClickHouse بدون برامج الترميز ، ولكن بضغط ZSTD ؛
• في ClickHouse مع برامج الترميز والضغط LZ4 و ZSTD.

يمكن ملاحظة أن الجداول التي تحتوي على برامج الترميز تشغل مساحة أقل بكثير.

حجم المسائل

لا تقل أهمية اختار نوع البيانات الصحيح:

لقد استخدمت في جميع الأمثلة المذكورة أعلاه فلوت 64. ولكن إذا اخترنا فلوت 32ثم سيكون ذلك أفضل. تم توضيح ذلك جيدًا من قبل الرجال من Perkona في المقالة الموجودة على الرابط أعلاه. من المهم استخدام النوع الأكثر إحكاما الذي يناسب المهمة: حتى أقل للحجم على القرص منه لسرعة الاستعلام. كليكهاوس حساسة جدا لذلك.

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

التجميع و وجهات النظر المجسدة

تسمح لك طرق العرض التجميعية والواقعية بتكوين مجاميع لمناسبات مختلفة:

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

TTL - "نسيت" البيانات القديمة

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

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

متعدد المستويات - تقسيم البيانات عبر الأقراص

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

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

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

خصائص فريدة كليكهاوس

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

• المصفوفات. في كليكهاوس دعم جيد جدًا للمصفوفات ، بالإضافة إلى القدرة على إجراء عمليات حسابية معقدة عليها.
• تجميع هياكل البيانات. هذه إحدى "الميزات الرائعة" كليكهاوس. على الرغم من حقيقة أن الرجال من Yandex يقولون إننا لا نريد تجميع البيانات ، يتم تجميع كل شيء فيها كليكهاوسلأنه سريع ومريح.
• الآراء المجسدة. جنبًا إلى جنب مع هياكل البيانات المجمعة ، تسمح لك العروض المجسدة بجعل ملف في الوقت الحقيقي تجميع.
• كليك هاوس SQL. هذا امتداد اللغة SQL مع بعض الميزات الإضافية والحصرية التي لا تتوفر إلا في كليكهاوس. في السابق ، كان ، كما كان ، امتدادًا من ناحية ، وعيبًا من ناحية أخرى. الآن تقريبا كل أوجه القصور مقارنة ب SQL 92 أزلناه ، والآن أصبح مجرد امتداد.
• لامدا-التعبيرات. هل ما زالوا في بعض قواعد البيانات؟
• ML-يدعم. هذا في قواعد بيانات مختلفة ، بعضها أفضل ، وبعضها أسوأ.
• المصدر المفتوح. يمكننا التوسع كليكهاوس معاً. في هذه اللحظة كليكهاوس حوالي 500 مساهم ، وهذا العدد في تزايد مستمر.

استفسارات صعبة

В كليكهاوس هناك العديد من الطرق المختلفة لفعل الشيء نفسه. على سبيل المثال ، هناك ثلاث طرق مختلفة لإرجاع آخر قيمة من جدول لـ وحدة المعالجة المركزية‏: (هناك أيضًا رابع ، لكنه أكثر غرابة).

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

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

الطريقة الثانية تفعل الشيء نفسه ولكنها تستخدم دالة تجميعية أرجماكس:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

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

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

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

وظائف تحليلية

في المعيار SQL-2003 يمكنك أن تكتب مثل هذا:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В كليكهاوس هذا غير ممكن - لا يدعم المعيار SQL-2003 وربما لن تفعل ذلك أبدًا. بدلا من ذلك ، في كليكهاوس من المعتاد أن تكتب مثل هذا:

لقد وعدت لامدا - ها هم!

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

مميزات خاصة

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

بشكل عام ، لدى ClickHouse وظائف خاصة للعديد من الأغراض:

• runDifference، runningAccumulate، الجار؛
• sumMap (مفتاح ، قيمة) ؛
• timeSeriesGroupSum (uid ، الطابع الزمني ، القيمة) ؛
• timeSeriesGroupRateSum (uid ، الطابع الزمني ، القيمة) ؛
• skewPop ، skewSamp ، kurtPop ، kurtSamp ؛
• مع ملء / مع العلاقات ؛
• الانحدار الخطي البسيط ، الانحدار العشوائي الخطي.

هذه ليست قائمة كاملة بالميزات ، هناك فقط 500-600 منهم. تلميح: جميع الوظائف في كليكهاوس موجود في جدول النظام (ليست كلها موثقة ، ولكن جميعها مثيرة للاهتمام):

select * from system.functions order by name

كليكهاوس يخزن الكثير من المعلومات حول نفسه ، بما في ذلك جداول السجل, query_log، سجل التتبع ، سجل العمليات مع كتل البيانات (Part_log) ، وسجل المقاييس ، وسجل النظام ، والتي عادةً ما تكتبها على القرص. سجل المقاييس هو السلاسل الزمنية в كليكهاوس حقيقة كليكهاوس: قاعدة البيانات نفسها يمكن أن تلعب دورًا السلاسل الزمنية قواعد البيانات ، وبالتالي "تلتهم" نفسها.

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

كتلة كبيرة أو صغيرة كثيرة كليكهاوس

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

В كليكهاوس يمكنك القيام بذلك بشكل مختلف. يمكن لكل تطبيق أن يصنع خاصته كليكهاوس:

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

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

النتيجة؟

وهكذا، كليكهاوس - هذا:

• Быстро. الجميع يعرف هذا.
• فقط. قابلة للنقاش قليلاً ، لكنني أعتقد أنه من الصعب التعلم ، ومن السهل القتال. إذا فهمت كيف كليكهاوس يعمل ، كل شيء بسيط للغاية.
• عالميا. إنها مناسبة لسيناريوهات مختلفة: DWH ، السلاسل الزمنية ، تخزين السجل. لكنها ليست كذلك OLTP قاعدة البيانات ، لذلك لا تحاول القيام بإدخالات قصيرة وقراءات هناك.
• ومن المثير للاهتمام. ربما الشخص الذي يعمل معه كليكهاوس، مررت بالعديد من الدقائق الممتعة بالمعنى الجيد والسيئ. على سبيل المثال ، تم إصدار إصدار جديد ، توقف كل شيء عن العمل. أو عندما واجهت صعوبة في مهمة لمدة يومين ، ولكن بعد سؤال في دردشة Telegram ، تم حل المهمة في دقيقتين. أو ، كما في المؤتمر في تقرير Lesha Milovidov ، لقطة شاشة من كليكهاوس كسر البث HighLoad ++. هذه الأنواع من الأشياء تحدث طوال الوقت وتجعل حياتنا معها كليكهاوس مشرقة ومثيرة للاهتمام!

يمكن الاطلاع على العرض التقديمي هنا.

الاجتماع الذي طال انتظاره لمطوري أنظمة التحميل العالي في HighLoad ++ ستقام يومي 9 و 10 نوفمبر في سكولكوفو. أخيرًا ، سيكون مؤتمرًا غير متصل بالإنترنت (وإن كان مع جميع الاحتياطات) ، حيث لا يمكن حزم طاقة HighLoad ++ عبر الإنترنت.

بالنسبة إلى المؤتمر ، نجد ونعرض لك حالات حول أقصى إمكانيات التكنولوجيا: HighLoad ++ كان وسيظل المكان الوحيد الذي يمكنك أن تتعلم فيه خلال يومين كيفية عمل Facebook و Yandex و VKontakte و Google و Amazon.

بعد أن عقدنا اجتماعاتنا دون انقطاع منذ عام 2007 ، سنلتقي هذا العام للمرة الرابعة عشرة. خلال هذا الوقت ، نما المؤتمر 14 مرات ، وفي العام الماضي ، جمع الحدث الرئيسي للصناعة 10 مشاركًا ، و 3339 متحدثًا من التقارير واللقاءات ، و 165 مسارًا تم تشغيلها في نفس الوقت.
في العام الماضي ، كان هناك 20 حافلة لك ، و 5280 لتراً من الشاي والقهوة ، و 1650 لتراً من مشروبات الفاكهة ، و 10200 زجاجة مياه. و 2640 كجم أخرى من الطعام و 16 طبق و 000 كوب. بالمناسبة ، بالأموال التي تم جمعها من الورق المعاد تدويره ، قمنا بزراعة 25 شتلة بلوط 🙂

يمكن شراء التذاكر هنا، تلقي أخبار المؤتمر - هنا، وتحدث في جميع الشبكات الاجتماعية: تیلیجرام, فيسبوك, فكونتاكتي и تويتر.

المصدر: www.habr.com