هو نظام إدارة قاعدة بيانات عمودية مفتوح المصدر لمعالجة الاستعلام التحليلي عبر الإنترنت (OLAP) تم إنشاؤه بواسطة Yandex. يتم استخدامه بواسطة Yandex و CloudFlare و VK.com و Badoo وغيرها من الخدمات حول العالم لتخزين كميات كبيرة حقًا من البيانات (إدخال آلاف الصفوف في الثانية أو بيتابايت من البيانات المخزنة على القرص).
في نظام DBMS العادي ، "سلسلة" ، ومن الأمثلة على ذلك MySQL و Postgres و MS SQL Server ، يتم تخزين البيانات بهذا الترتيب:
في هذه الحالة ، يتم تخزين القيم المتعلقة بصف واحد ماديًا جنبًا إلى جنب. في DBMS العمودي ، يتم تخزين القيم من أعمدة مختلفة بشكل منفصل ، ويتم تخزين بيانات عمود واحد معًا:
من أمثلة أنظمة DBMS العمودية Vertica و Paraccel (Actian Matrix و Amazon Redshift) و Sybase IQ و Exasol و Infobright و InfiniDB و MonetDB (VectorWise و Actian Vector) و LucidDB و SAP HANA و Google Dremel و Google PowerDrill و Druid و kdb +.
الشركة وكيل بريد لقد بدأت في استخدام Clickhouse في عام 2018 لإعداد التقارير وقد أعجبت جدًا ببساطتها وقابليتها للتوسع ودعم SQL وسرعتها. سرعة نظام إدارة قواعد البيانات (DBMS) تحدها السحر.
سهولة
يتم تثبيت Clickhouse على Ubuntu بأمر واحد. إذا كنت تعرف SQL ، فيمكنك البدء فورًا في استخدام Clickhouse لتلبية احتياجاتك. ومع ذلك ، هذا لا يعني أنه يمكنك "إظهار جدول الإنشاء" في MySQL ونسخ SQL ولصقه في Clickhouse.
مقارنةً بـ MySQL ، توجد اختلافات مهمة في نوع البيانات في تعريفات مخطط الجدول في نظام إدارة قواعد البيانات هذا ، لذلك لا تزال بحاجة إلى بعض الوقت لتغيير تعريفات مخطط الجدول وتعلم محركات الجدول حتى تشعر بالراحة.
يعمل Clickhouse بشكل رائع دون أي برامج إضافية ، ولكن إذا كنت ترغب في استخدام النسخ المتماثل ، فستحتاج إلى تثبيت ZooKeeper. يُظهر تحليل أداء الاستعلام نتائج ممتازة - تحتوي جداول النظام على جميع المعلومات ، ويمكن الحصول على جميع البيانات باستخدام لغة SQL القديمة والمملة.
أداء
- Clickhouse مقابل Vertica و MySQL مقارنات على خادم التكوين: مآخذان Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz ؛ 128 جيجا بايت رام md RAID-5 على 8 6TB SATA HDD ، ext4.
- مقارنة Clickhouse مع التخزين السحابي Amazon RedShift.
- مقتطفات من المدونة :
تتميز قاعدة بيانات ClickHouse بتصميم بسيط للغاية - جميع العقد في المجموعة لها نفس الوظيفة وتستخدم ZooKeeper فقط للتنسيق. قمنا ببناء مجموعة صغيرة من عدة عقد وأجرينا اختبارات ، وجدنا خلالها أن النظام يتمتع بأداء مثير للإعجاب ، وهو ما يتوافق مع المزايا المزعومة في معايير DBMS التحليلية. قررنا إلقاء نظرة فاحصة على المفهوم الكامن وراء ClickHouse. كانت العقبة الأولى أمام البحث هي الافتقار إلى الأدوات ومجتمع ClickHouse الصغير ، لذلك تعمقنا في تصميم نظام إدارة قواعد البيانات هذا لفهم كيفية عمله.
لا يدعم ClickHouse تلقي البيانات مباشرة من كافكا ، حيث إنها مجرد قاعدة بيانات ، لذلك قمنا بكتابة خدمة المهايئ الخاصة بنا في Go. قرأت الرسائل المشفرة Cap'n Proto من كافكا ، وحولتها إلى TSV ، وأدخلتها في ClickHouse على دفعات عبر واجهة HTTP. قمنا لاحقًا بإعادة كتابة هذه الخدمة لاستخدام مكتبة Go جنبًا إلى جنب مع واجهة ClickHouse الخاصة بنا لتحسين الأداء. عند تقييم أداء الحزم المستقبلة ، اكتشفنا شيئًا مهمًا - اتضح أن هذا الأداء لـ ClickHouse يعتمد بشدة على حجم الحزمة ، أي عدد الصفوف التي تم إدخالها في نفس الوقت. لفهم سبب حدوث ذلك ، قمنا بدراسة كيفية تخزين ClickHouse للبيانات.
المحرك الرئيسي ، أو بالأحرى ، عائلة محركات الجدول التي يستخدمها ClickHouse لتخزين البيانات ، هو MergeTree. يشبه هذا المحرك من الناحية المفاهيمية خوارزمية LSM المستخدمة في Google BigTable أو Apache Cassandra ، لكنه يتجنب إنشاء جدول ذاكرة وسيطة ويكتب البيانات مباشرة إلى القرص. يمنحها هذا معدل نقل ممتاز للكتابة ، حيث يتم فرز كل حزمة مدرجة فقط بواسطة المفتاح الأساسي "المفتاح الأساسي" ، ويتم ضغطها ، وكتابتها على القرص لتشكيل مقطع.
إن عدم وجود جدول ذاكرة أو أي مفهوم "لحداثة" البيانات يعني أيضًا أنه لا يمكن إضافتها إلا ، ولا يدعم النظام التغيير أو الحذف. اعتبارًا من اليوم ، فإن الطريقة الوحيدة لحذف البيانات هي حذفها حسب الشهر التقويمي ، حيث لا تتجاوز المقاطع حدود الشهر مطلقًا. يعمل فريق ClickHouse بنشاط على جعل هذه الميزة قابلة للتخصيص. من ناحية أخرى ، فإنه يجعل كتابة المقاطع ودمجها خالية من الخلاف ، لذلك تلقي مقاييس الإنتاجية خطيًا مع عدد الإدخالات المتوازية حتى تشبع الإدخال / الإخراج أو النوى.
ومع ذلك ، فإن هذا الظرف يعني أيضًا أن النظام غير مناسب للحزم الصغيرة ، لذلك تُستخدم خدمات ومُدخلات كافكا للتخزين المؤقت. علاوة على ذلك ، يواصل ClickHouse في الخلفية دمج المقاطع باستمرار ، بحيث يتم دمج العديد من المعلومات الصغيرة وتسجيلها مرات أكثر ، وبالتالي زيادة كثافة التسجيل. ومع ذلك ، سيؤدي وجود عدد كبير جدًا من الأجزاء غير المرتبطة إلى اختناق شديد للإدخالات طالما استمر الدمج. لقد وجدنا أن أفضل حل وسط بين عرض البيانات في الوقت الفعلي وأداء العرض هو قبول عدد محدود من الإدخالات في الثانية في الجدول.
مفتاح أداء قراءة الجدول هو فهرسة البيانات وموقعها على القرص. بغض النظر عن مدى سرعة المعالجة ، عندما يحتاج المحرك إلى مسح تيرابايت من البيانات من القرص واستخدام جزء منه فقط ، فسوف يستغرق الأمر وقتًا. ClickHouse هو مخزن أعمدة ، لذلك يحتوي كل مقطع على ملف لكل عمود (عمود) بقيم مرتبة لكل صف. وبالتالي ، يمكن أولاً تخطي أعمدة كاملة غير موجودة في الاستعلام ، ومن ثم يمكن معالجة عدة خلايا بالتوازي مع التنفيذ المتجه. لتجنب الفحص الكامل ، يحتوي كل مقطع على ملف فهرس صغير.
بالنظر إلى أن جميع الأعمدة مرتبة حسب "المفتاح الأساسي" ، فإن ملف الفهرس يحتوي فقط على التسميات (الصفوف الملتقطة) لكل صف N ، من أجل التمكن من الاحتفاظ بها في الذاكرة حتى بالنسبة للجداول الكبيرة جدًا. على سبيل المثال ، يمكنك تعيين الإعدادات الافتراضية على "تحديد كل صف 8192" ، ثم فهرسة "هزيلة" لجدول يحتوي على 1 تريليون. السطور التي تتلاءم بسهولة مع الذاكرة لن تستغرق سوى 122،070 حرفًا.
تطوير النظام
يمكن تتبع تطوير وتحسين Clickhouse على وتأكد من أن عملية "النمو" تتم بوتيرة رائعة.
شعبية
يبدو أن شعبية Clickhouse تزداد باطراد ، خاصة في المجتمع الناطق باللغة الروسية. أظهر مؤتمر High load 2018 (موسكو ، 8-9 نوفمبر 2018) أن الوحوش مثل vk.com و Badoo تستخدم Clickhouse ، والتي تُدخل البيانات (على سبيل المثال ، السجلات) من عشرات الآلاف من الخوادم في وقت واحد. في فيديو مدته 40 دقيقة . سننشر قريبًا النص على Habr لتسهيل التعامل مع المادة.
تطبيقات
بعد قضاء بعض الوقت في البحث ، أعتقد أن هناك مجالات يمكن أن يكون ClickHouse فيها مفيدًا أو قادرًا على استبدال الحلول التقليدية والشائعة الأخرى تمامًا مثل MySQL و PostgreSQL و ELK و Google Big Query و Amazon RedShift و TimescaleDB و Hadoop و MapReduce و Pinot و الكاهن. فيما يلي تفاصيل استخدام ClickHouse لترقية DBMS أعلاه أو استبدالها بالكامل.
توسيع MySQL و PostgreSQL
في الآونة الأخيرة ، قمنا باستبدال MySQL جزئيًا بـ ClickHouse لمنصة الرسائل الإخبارية . تكمن المشكلة في أن MySQL بسبب التصميم الخاطئ قام بتسجيل كل بريد إلكتروني يتم إرساله وكل رابط في هذا البريد الإلكتروني يحتوي على تجزئة base64 ، مما يؤدي إلى إنشاء جدول MySQL ضخم (email_stats). بعد إرسال 10 ملايين رسالة بريد إلكتروني فقط إلى مشتركي الخدمة ، احتل هذا الجدول 150 جيجابايت من مساحة الملفات ، وبدأت MySQL في "الغباء" عند الاستعلامات البسيطة. لإصلاح مشكلة مساحة الملف ، استخدمنا ضغط جدول InnoDB بنجاح ، مما أدى إلى تقليله بمعامل 4. ومع ذلك ، لا يزال من غير المنطقي تخزين أكثر من 20 إلى 30 مليون بريد إلكتروني في MySQL فقط من أجل قراءة السجل ، حيث إن أي استعلام بسيط يجب أن يقوم لسبب ما بإجراء مسح كامل ينتج عنه تبديل وإدخال / إخراج ثقيل فوق النفقات العامة ، والتي تلقينا بشأنها تحذيرات من Zabbix بانتظام.
يستخدم Clickhouse اثنين من خوارزميات الضغط التي تقلل كمية البيانات بحوالي ، ولكن في هذه الحالة بالذات ، كانت البيانات "قابلة للضغط" بشكل خاص.
استبدال ELK
بناءً على تجربتي الخاصة ، تتطلب مكدس ELK (ElasticSearch و Logstash و Kibana ، في هذه الحالة بالذات ElasticSearch) موارد لتشغيل أكثر بكثير مما هو مطلوب لتخزين السجلات. يعد ElasticSearch محركًا رائعًا إذا كنت تريد بحثًا جيدًا في سجل النص الكامل (ولا أعتقد أنك بحاجة إليه حقًا) ، لكنني أتساءل لماذا أصبح محرك التسجيل القياسي الفعلي. لقد تسبب لنا أداء الاستيعاب ، جنبًا إلى جنب مع Logstash ، في حدوث مشكلات حتى في أحمال العمل الخفيفة إلى حد ما وتطلب إضافة المزيد والمزيد من ذاكرة الوصول العشوائي ومساحة القرص. كقاعدة بيانات ، يعد Clickhouse أفضل من ElasticSearch للأسباب التالية:
- دعم لغة SQL.
- أفضل درجة لضغط البيانات المخزنة ؛
- دعم البحث في Regex بدلاً من البحث عن النص الكامل ؛
- جدولة استعلام محسنة وأداء عام أفضل.
في الوقت الحالي ، أكبر مشكلة تظهر عند مقارنة ClickHouse مع ELK هي عدم وجود حلول لتحميل السجلات ، فضلاً عن نقص الوثائق والبرامج التعليمية حول هذا الموضوع. في الوقت نفسه ، يمكن لكل مستخدم إعداد ELK باستخدام دليل Digital Ocean ، وهو أمر مهم جدًا للتنفيذ السريع لهذه التقنيات. يوجد محرك قاعدة بيانات هنا ، ولكن لا يوجد Filebeat لـ ClickHouse حتى الآن. نعم هنالك ونظام للعمل مع السجلات ، هناك أداة لإدخال بيانات ملف السجل في ClickHouse ، لكن كل هذا يستغرق وقتًا أطول. ومع ذلك ، لا يزال ClickHouse يحتل الصدارة نظرًا لبساطته ، لذلك يمكن حتى للمبتدئين تثبيته بسهولة والبدء في الاستخدام الوظيفي الكامل في غضون 10 دقائق فقط.
مفضلاً الحلول البسيطة ، حاولت استخدام FluentBit ، أداة تحميل سجل ذاكرة منخفضة للغاية ، مع ClickHouse أثناء محاولة تجنب استخدام كافكا. ومع ذلك ، يجب معالجة حالات عدم التوافق الطفيفة ، مثل قبل أن يتم ذلك بدون طبقة الوكيل التي تحول البيانات من FluentBit إلى ClickHouse.
كبديل لـ Kibana ، يمكنك استخدام ClickHouse كخلفية . بقدر ما أفهم ، يمكن أن يتسبب ذلك في حدوث مشكلات في الأداء عند عرض عدد كبير من نقاط البيانات ، خاصةً مع الإصدارات القديمة من Grafana. في Qwintry ، لم نجرب هذا بعد ، ولكن تظهر شكاوى حول هذا من وقت لآخر على قناة دعم ClickHouse في Telegram.
استبدال Google Big Query و Amazon RedShift (حل للشركات الكبيرة)
حالة الاستخدام المثالية لـ BigQuery هي تحميل 1 تيرابايت من بيانات JSON وتشغيل استعلامات تحليلية عليها. يعد Big Query منتجًا رائعًا يصعب المبالغة في تقدير قابلية التوسع. هذا برنامج أكثر تعقيدًا من ClickHouse الذي يعمل على مجموعة داخلية ، ولكن من وجهة نظر العميل ، لديه الكثير من القواسم المشتركة مع ClickHouse. يمكن لـ BigQuery "زيادة السعر" سريعًا بمجرد أن تبدأ في الدفع مقابل كل SELECT ، لذا فهو حل SaaS حقيقي بكل إيجابياته وسلبياته.
ClickHouse هو الخيار الأفضل عند تشغيل الكثير من الاستعلامات باهظة الثمن من الناحية الحسابية. كلما زاد عدد استعلامات SELECT التي تقوم بتشغيلها كل يوم ، كلما زاد الهدف من استبدال Big Query بـ ClickHouse ، لأن مثل هذا الاستبدال سيوفر لك آلاف الدولارات عندما يتعلق الأمر بالعديد من تيرابايت من البيانات التي تتم معالجتها. لا ينطبق هذا على البيانات المخزنة ، وهي رخيصة جدًا لمعالجتها في Big Query.
في مقال بقلم ألكسندر زايتسيف ، المؤسس المشارك لشركة Altinity يصف فوائد ترحيل DBMS.
استبدال TimescaleDB
TimescaleDB هو امتداد PostgreSQL يعمل على تحسين العمل مع سلاسل زمنية في قاعدة بيانات عادية (, ).
على الرغم من أن ClickHouse ليس منافسًا جادًا في مكانة السلاسل الزمنية ، ولكن من حيث الهيكل العمودي وتنفيذ استعلام المتجه ، فهو أسرع بكثير من TimescaleDB في معظم حالات معالجة الاستعلامات التحليلية. في الوقت نفسه ، يكون أداء تلقي بيانات حزمة ClickHouse أعلى بحوالي 3 مرات ، بالإضافة إلى أنه يستخدم مساحة قرص أقل 20 مرة ، وهو أمر مهم حقًا لمعالجة كميات كبيرة من البيانات التاريخية: .
على عكس ClickHouse ، فإن الطريقة الوحيدة لتوفير بعض مساحة القرص في TimescaleDB هي استخدام ZFS أو أنظمة ملفات مماثلة.
من المحتمل أن تقدم التحديثات القادمة لبرنامج ClickHouse ضغط دلتا ، مما سيجعله أكثر ملاءمة لمعالجة بيانات السلاسل الزمنية وتخزينها. قد يكون TimescaleDB خيارًا أفضل من ClickHouse العاري في الحالات التالية:
- المنشآت الصغيرة ذات ذاكرة الوصول العشوائي (RAM) قليلة جدًا (<3 غيغابايت) ؛
- عدد كبير من الإدخالات الصغيرة التي لا تريد تخزينها في أجزاء كبيرة ؛
- متطلبات تناسق وتوحيد أفضل وحمض أفضل ؛
- دعم PostGIS ؛
- دمجها مع جداول PostgreSQL الحالية ، لأن قاعدة بيانات Timescale DB هي أساسًا PostgreSQL.
التنافس مع أنظمة Hadoop و MapReduce
يمكن لـ Hadoop ومنتجات MapReduce الأخرى إجراء الكثير من العمليات الحسابية المعقدة ، لكنها تميل إلى العمل في زمن انتقال كبير. يعمل ClickHouse على إصلاح هذه المشكلة عن طريق معالجة تيرابايت من البيانات وتقديم النتائج على الفور تقريبًا. وبالتالي ، يعد ClickHouse أكثر كفاءة لإجراء بحث تحليلي سريع وتفاعلي ، والذي يجب أن يكون محل اهتمام علماء البيانات.
المنافسة مع Pinot و Druid
أقرب المنافسين لـ ClickHouse هم المنتجات مفتوحة المصدر العمودية والقابلة للتطوير خطيًا Pinot و Druid. تم نشر عمل ممتاز لمقارنة هذه الأنظمة في المقالة 1 فبراير 2018
تحتاج هذه المقالة إلى التحديث - تقول أن ClickHouse لا تدعم عمليات UPDATE و DELETE ، وهذا ليس صحيحًا تمامًا فيما يتعلق بأحدث الإصدارات.
ليس لدينا الكثير من الخبرة مع أنظمة إدارة قواعد البيانات (DBMS) هذه ، لكنني لا أحب تعقيد البنية التحتية الأساسية المطلوبة لتشغيل Druid و Pinot - إنها مجموعة كاملة من "الأجزاء المتحركة" المحاطة بجافا من جميع الجوانب.
Druid و Pinot هي مشاريع حاضنة Apache ، والتي يتم تغطيتها بالتفصيل بواسطة Apache على صفحات مشروع GitHub الخاصة بهم. ظهر Pinot في الحاضنة في أكتوبر 2018 ، وولد Druid قبل 8 أشهر - في فبراير.
يثير نقص المعلومات حول كيفية عمل AFS بعض الأسئلة ، وربما الغبية ، بالنسبة لي. أتساءل عما إذا كان مؤلفو Pinot قد لاحظوا أن مؤسسة Apache أكثر ميلًا إلى Druid ، وهل مثل هذا الموقف تجاه أحد المنافسين تسبب في شعور بالحسد؟ هل سيتباطأ تطوير Druid ويتسارع تطور Pinot إذا أصبح الرعاة الذين يدعمون الأول مهتمين بالأخير فجأة؟
عيوب ClickHouse
عدم النضج: من الواضح أن هذه لا تزال تقنية مملة ، ولكن على أي حال ، لا يوجد شيء مثل هذا في نظم إدارة قواعد البيانات العمودية الأخرى.
لا تعمل الإدخالات الصغيرة بشكل جيد عند السرعة العالية: يجب تقسيم الإدخالات إلى أجزاء كبيرة لأن أداء الإدخالات الصغيرة يتدهور بما يتناسب مع عدد الأعمدة في كل صف. هذه هي الطريقة التي يخزن بها ClickHouse البيانات على القرص - كل عمود يعني ملفًا واحدًا أو أكثر ، لذلك لإدراج صف واحد يحتوي على 1 عمود ، تحتاج إلى فتح وكتابة 1 ملف على الأقل. هذا هو السبب في أن إدراج التخزين المؤقت يتطلب وسيطًا (ما لم يوفر العميل نفسه تخزينًا مؤقتًا) - عادةً كافكا أو نوع من نظام الطابور. يمكنك أيضًا استخدام محرك جدول المخزن المؤقت لنسخ أجزاء كبيرة من البيانات لاحقًا إلى جداول MergeTree.
صلات الجدول محدودة بواسطة ذاكرة الوصول العشوائي للخادم ، لكنها على الأقل موجودة! على سبيل المثال ، ليس لدى Druid و Pinot مثل هذه الاتصالات على الإطلاق ، حيث يصعب تنفيذها مباشرة في الأنظمة الموزعة التي لا تدعم نقل أجزاء كبيرة من البيانات بين العقد.
النتائج
في السنوات القادمة ، نخطط للاستفادة المكثفة من ClickHouse في Qwintry ، حيث يوفر نظام إدارة قواعد البيانات هذا توازنًا ممتازًا في الأداء ، وانخفاض النفقات العامة ، وقابلية التوسع ، والبساطة. أنا متأكد من أنه سينتشر بسرعة بمجرد أن يأتي مجتمع ClickHouse بمزيد من الطرق لاستخدامه في المنشآت الصغيرة والمتوسطة.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com