منذ وقت طويل ، في مجرة الطاقة الشمسية البعيدة ، وحتى قبل أن تصبح جزءًا من عالم Rostelecom ، فإن منتج webProxy الصغير لم يكن بحاجة إلى تصفية حركة مرور الشبكة فحسب ، ولكن أيضًا لبناء إحصاءات عليها بتخزينها اللاحق. في ذلك الوقت ، لم تكن قواعد بيانات الأعمدة شائعة كما هي الآن. النظير المناسب الوحيد هو قاعدة بيانات HP Vertica المدفوعة. كيف قاموا في المجرة الشمسية بحل هذه المشكلة وما توصلوا إليها أخيرًا ، سنخبرهم تحت هذا الخفض
أولاً ، قررنا إنشاء قاعدة البيانات الخاصة بنا. نتيجةً لذلك ، تمت كتابته بلغة OCaml مع تخزين ثنائي للأعمدة (تم ضغط تمثيلات النص عبر lz4) ولغة الاستعلام الخاصة به والمرنة جدًا على تعبيرات S-التعبيرات. تم التقسيم في اليوم الواحد.
طلب مثال:
لم يكن الخيار الأكثر ملاءمة وسرعة ، ولكن قابل للتوسيع وقابلة للتخصيص.
مر الوقت ، وكذلك فعلت الحاجة لتسريع بناء الإحصاءات وتقارير المرور. لذلك ، بدأنا في النظر في خيارات أخرى:
- بوستجرس النقي ؛
- Postgres + cstore_fdw؛
- Slickhouse.
- مطاطا.
مقارنة Postgres مقابل مرونة
في المرحلة الأولى ، قارنا المرنة و Postgres + cstore. تم اعتبار بوستجرز عن كثب ، لأنه كان مستخدمًا بالفعل في النظام ، وكانت الخبرة متاحة للعمل معه.
مطاطا كان يستخدم أيضا بنشاط في الشركة. على الرغم من "جاذبية" البحث عن النص الكامل وسرعته ، فقد تم التخلي عن تطبيق Flex بسبب الحجم الكبير الذي تحتله البيانات الموجودة على القرص. من حيث السرعة ، فازت Flex بالطلبات البسيطة حوالي 3 مرات ، على سبيل المثال ، في استعلام "أفضل 20 موقعًا في الأسبوع". وعلى المواقع الأكثر تعقيدًا - ما يصل إلى 9 مرات: "أفضل 20 موقعًا للحركة في الشهر".
ومع ذلك ، كان أفضل من قاعدته الخاصة ، التي استغرقت دقائق للقيام بذلك مقابل 5-6 ثوان في مرنة و15-55 ثانية في بوستجرس.
Postgres مقارنة Clickhouse
مصدر البيانات
مع https://github.com/wizardjedi/clickhouse-test أخذنا حاويات مع Postgres و Clickhouse. تم تصميم هذه الحاويات لإنشاء الجداول.
عرض الجدول ل Postgres:
تمت إزالة المفتاح الأساسي ، نظرًا لأن الجدول الخارجي في Postgres لا يسمح بذلك.
بالنسبة إلى Clickhouse ، يكون إنشاء مثل هذا الجدول كما يلي:
للتعرف على عملية تثبيت cstore for Postgres ، انتقل إلى https://github.com/citusdata/cstore_fdw .
أيضًا ، عند تثبيت cstore ، ستحتاج إلى تثبيت الحزمة postgresql-server-dev-XY
عند مقارنة الأداء ، تم استخدام أحجام البيانات التالية (بالميغابايت):
مصدر البيانات هو مجرد استعلام مزود يسرد كل التلاميذ ، أي البيانات الخام.
أثناء تنفيذ الاستعلامات ، خاصة الثقيلة منها ، بالإضافة إلى البيانات ، تم قياس أحجام قاعدة البيانات.
وقد تبين أن Clickhouse لم يزد بالتأكيد.
معلمات نظام الحوسبة
الشركة المصنعة: إنتل
الخط: كور i5
الموديل: 8250U
تردد الساعة: 1.60 جيجا هرتز لكل الأساسية
النوى: 4
ذاكرة الوصول العشوائي: 16 جيجابايت
SSD: 256 جيجابايت
تحميل البيانات في قاعدة البيانات
لمثل هذا الحجم من البيانات في Clickhouse ، يتم تحميلها بسرعة كبيرة: 1 ساعة و 40 دقيقة (هذا هو 600 مليون مرة).
في البداية ، خططنا لتنزيل كل شيء في ملف واحد ، ولكن تم عرض الخطأ "bad_alloc". على ما يبدو ، بسبب عدم قدرة Clickhouse على تخصيص الذاكرة. لم يتم العثور على حل. لذلك ، تم تقسيم 600 مليون مرة إلى 30 ملفًا لكل منها 20 مليونًا ، وفي هذه الحالة ، تم تنزيل كل ملف أكثر من 3 دقائق بقليل.
مع Postgres ، كانت الأمور أكثر تعقيدًا ، ولكن فقط في البداية. إن تنزيل ملفات sql الأولية التي تحتوي على INSERT INTO <table_name> (سمات) أمر VALUES tuples يستغرق وقتًا طويلاً. لذلك ، تم تحويل كل شيء إلى تنسيق CSV وتم تنفيذ الأمر COPY <table_name> FROM WITH CSV.
تجدر الإشارة إلى أننا قمنا أولاً بتحميل البيانات في جدول Postgres منتظم ، حيث قمنا بنسخها إلى جدول أجنبي ، يتم التحكم فيه بواسطة cstore. نتيجة لذلك ، استغرق تحميل Postgres من ملف CSV أيضًا أقل من ساعتين بقليل.
مقارنة الأداء
يتم عرض مقارنة أداء Postgres و Clickhouse في الجدول أدناه. ولكن دون بناء الفهارس وتغيير معلمات قاعدة البيانات. في مرحلة ما ، نفدت الذاكرة على القرص تقريبًا ، وبالتالي أصبح من الضروري حذف جدول عادي غير مضغوط من Postgres. الآن ، تتوفر الجداول فقط في Clickhouse و Postgres cstore.
على ما يبدو ، يركز cstore على السمة الأولى المحددة عند إنشائها. بمعنى آخر ، يقوم بفرز كل البيانات به. يمكن ملاحظة ذلك بسهولة ، نظرًا لأن الاستعلامات المتعلقة بـ EventDate كانت أسرع في التنفيذ في cstore منها في Postgres.
عند تنفيذ الاستعلامات ، استغرق Postgres أحيانًا ما يصل إلى 27 جيجابايت على محرك أقراص خارجي للملفات المؤقتة.
Clickhouse يستغرق الكثير من ذاكرة الوصول العشوائي.
في ملف التكوين /etc/clickhouse/users.xml ، تم تحديد <max_memory_usage> 12000000000 </max_memory_usage> و <max_bytes_before_external_sort> 1000000000 </max_btes_before_external_sort>.
بالنسبة لبعض الاستعلامات ، لم تكن ذاكرة الوصول العشوائي كافية ، ولهذا السبب اضطررنا إلى زيادتها. بعد ذلك ، استمرت معالجة الطلبات ، ولكن بناءً على الطلب الأخير ، كان لا يزال متوقفًا. كان هناك العديد من المعلمات المتاحة للحد من استهلاك الذاكرة https://clickhouse.yandex/docs/ru/query_language/queries/ .
حدث أن أضفنا المزيد من البيانات إلى Clickhouse: 695_640_000 وحدة بدلاً من 600_000_000 ، لكن هذا لم يمنعه من الفوز.
في cstore_fdw ، يمكنك تكوين العديد من المعلمات https://github.com/citusdata/cstore_fdw/issues/174 ، https://github.com/citusdata/cstore_fdw ، والتي تؤثر على الأداء.
التقسيم
أما بالنسبة للتقسيم ، فهو أيضًا في Clickhouse https://github.com/yandex/ClickHouse/blob/master/docs/ru/table_engines/custom_partitioning_key.md ، https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key / ، وفي بوستجرس (10 و 11 إصدارات). يمكن العثور على مثال للتقسيم في clickhouse على https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00502_custom_partitioning_local.sql و https://github.com/yandex/ClickHouse/issues/1513 .
من الممكن استخدام التقسيم في Postgres بشرط أن يعمل cstore فقط مع الجداول الخارجية ، حيث إنك تحتاج إلى إنشاء خادم له ولا يمكنك تحديد خادم للجداول العادية. لا يمكن تقسيم الجدول الخارجي إلى أقسام ؛ بل يمكن أن يعمل بحد ذاته كقسم. لذلك ، لا يوجد سوى طريقة واحدة ممكنة لاستخدام التقسيم: إنشاء جدول أصل منتظم ، يمكنك إرفاق الجداول الخارجية به في شكل أقسام ، والتي تعمل بالفعل على cstore_fdw.
في Clickhouse ، التقسيم يعمل خارج الصندوق.
استنتاج
نتيجةً لذلك ، قررنا استخدام Clickhouse ، لأنه ذكي: إنه دائمًا أسرع 10 مرات على الأقل من النظير. على خوادم الذاكرة ، عادة ما يكون هناك أكثر من 32 جيجا بايت و 64 و 128 ، لذلك ستعمل الاستعلامات على الجداول التي تبلغ حوالي 50 جيجا بايت بشكل جيد. إذا كان الجدول كبيرًا جدًا ، فهذا يعني أن التقسيم أو ضبط معلمات خادم clickhouse.