أليكسي ليزونوف ، رئيس مركز اختصاص قنوات الخدمة عن بعد التابعة لمديرية تكنولوجيا المعلومات التابعة للـ ICD
كبديل لمكدس ELK (ElasticSearch ، Logstash ، Kibana) ، نحن نجري بحثًا حول استخدام قاعدة بيانات ClickHouse كمستودع بيانات للسجلات.
في هذه المقالة ، نود أن نتحدث عن تجربتنا باستخدام قاعدة بيانات ClickHouse وعن النتائج الأولية من العملية التجريبية. تجدر الإشارة إلى أن النتائج كانت مثيرة للإعجاب على الفور.

بعد ذلك ، سنصف بمزيد من التفصيل كيفية تكوين نظامنا والمكونات التي يتكون منها. لكن الآن أود أن أتحدث قليلاً عن قاعدة البيانات هذه ككل ، ولماذا يجب عليك الانتباه إليها. قاعدة بيانات ClickHouse هي قاعدة بيانات عمود تحليلي عالي الأداء من Yandex. يتم استخدامه في خدمات ياندكس ، في البداية هو مستودع البيانات الرئيسي ل Yandex.Metrica. نظام مفتوح المصدر مجاني. من وجهة نظر المطور ، كنت مهتمًا دائمًا بكيفية تنفيذها ، نظرًا لوجود بيانات كبيرة خيالية. وواجهة المستخدم المترية نفسها مرنة وسريعة للغاية. عند التعارف الأول مع قاعدة البيانات هذه ، الانطباع: "حسنًا ، أخيرًا! صنع "للناس"! بدءا من عملية التثبيت وتنتهي مع إرسال الطلبات. "
تحتوي قاعدة البيانات هذه على عتبة دخول منخفضة جدًا. حتى مطور ماهر في المتوسط يمكنه تثبيت قاعدة البيانات هذه في بضع دقائق والبدء في استخدامها. كل شيء يعمل بشكل واضح. حتى الأشخاص الجدد على Linux يمكنهم الوصول بسرعة إلى التثبيت والقيام بعمليات بسيطة. في وقت سابق ، عندما كانت كلمة Big Data و Hadoop و Google BigTable و HDFS ، كان لدى المطور المعتاد فكرة أنهم يتحدثون عن بعض تيرابايت ، بايت ، أن بعض البشر الخارقين شاركوا في إعدادات وتطوير هذه الأنظمة ، ثم مع ظهور قاعدة بيانات ClickHouse التي حصلنا عليها أداة بسيطة ومفهومة يمكنك من خلالها حل مجموعة المهام السابقة التي يتعذر الوصول إليها. واحد فقط سيارة متوسطة إلى حد ما وخمس دقائق لتثبيت. هذا هو ، لدينا قاعدة بيانات مثل ، على سبيل المثال ، MySql ، ولكن فقط لتخزين مليارات السجلات! نوع من المشرف SQL. يبدو الأمر كما لو أن الناس تلقوا أسلحة للأجانب.
حول نظام جمع السجلات الخاص بنا
لجمع المعلومات ، يتم استخدام ملفات سجل IIS لتطبيقات الويب ذات التنسيق القياسي (نحن نشارك أيضًا في تحليل سجلات التطبيق ، ولكن الهدف الرئيسي في مرحلة التشغيل التجريبي معنا هو جمع سجلات IIS).
لأسباب مختلفة ، فشلنا في التخلي عن مكدس ELK تمامًا ، وما زلنا نستخدم مكونات LogStash و Filebeat ، والتي أثبتت نفسها بشكل جيد وتعمل بشكل موثوق وموثوق.
يتم عرض مخطط التسجيل العام في الشكل أدناه:

تتمثل ميزة كتابة البيانات في قاعدة بيانات ClickHouse في الإدراج النادر (مرة واحدة في الثانية) للسجلات على دفعات كبيرة. هذا ، على ما يبدو ، هو الجزء الأكثر "إشكالية" الذي تواجهه عند تجربة العمل مع قاعدة بيانات ClickHouse لأول مرة: المخطط معقد بعض الشيء.
ساعد المكون الإضافي LogStash كثيرًا هنا ، والذي يدرج البيانات مباشرةً في ClickHouse. يتم نشر هذا المكون على نفس الخادم مثل قاعدة البيانات نفسها. وبصفة عامة ، لا يُنصح بالقيام بذلك ، ولكن من وجهة نظر عملية ، حتى لا تنتج خوادم منفصلة أثناء نشرها على نفس الخادم. لم نلاحظ أي حالات فشل أو تعارض في الموارد مع قاعدة البيانات. بالإضافة إلى ذلك ، تجدر الإشارة إلى أن المكوّن الإضافي لديه آلية إعادة اختبار في حالة وجود أخطاء. وفي حالة وجود أخطاء ، يكتب البرنامج المساعد على القرص حزمة من البيانات التي لا يمكن إدراجها (تنسيق الملف مناسب: بعد التحرير ، يمكنك بسهولة إدخال الحزمة المصححة باستخدام clickhouse-client).
يتم عرض القائمة الكاملة للبرامج المستخدمة في المخطط في الجدول:
يتم عرض تكوين الخادم مع قاعدة بيانات ClickHouse في الجدول التالي:
كما ترون ، هذه محطة عمل عادية.
هيكل الجدول لتخزين السجلات كما يلي:
log_web.sqlCREATE TABLE log_web ( logdate Date, logdatetime DateTime CODEC(Delta, LZ4HC), fld_log_file_name LowCardinality( String ), fld_server_name LowCardinality( String ), fld_app_name LowCardinality( String ), fld_app_module LowCardinality( String ), fld_website_name LowCardinality( String ), serverIP LowCardinality( String ), method LowCardinality( String ), uriStem String, uriQuery String, port UInt32, username LowCardinality( String ), clientIP String, clientRealIP String, userAgent String, referer String, response String, subresponse String, win32response String, timetaken UInt64 , uriQuery__utm_medium String , uriQuery__utm_source String , uriQuery__utm_campaign String , uriQuery__utm_term String , uriQuery__utm_content String , uriQuery__yclid String , uriQuery__region String ) Engine = MergeTree() PARTITION BY toYYYYMM(logdate) ORDER BY (fld_app_name, fld_app_module, logdatetime) SETTINGS index_granularity = 8192;
نستخدم القيم الافتراضية للتقسيم (بالأشهر) وتحبب الفهرس. تتوافق جميع الحقول عملياً مع إدخالات سجل IIS لتسجيل طلبات http. بشكل منفصل ، حقول منفصلة لتخزين علامات utm (يتم تحليلها في مرحلة الإدراج في الجدول من حقل سلسلة الاستعلام).
أيضا في الجدول يتم إضافة العديد من مجالات النظام لتخزين المعلومات حول الأنظمة والمكونات والخوادم. انظر الجدول أدناه للحصول على وصف لهذه الحقول. في جدول واحد ، نقوم بتخزين سجلات لعدة أنظمة.
يتيح لك ذلك إنشاء رسومات فعالة في Grafana. على سبيل المثال ، عرض الطلبات من الواجهة الأمامية لنظام معين. هذا مشابه لعداد الموقع في Yandex.Metrica.
فيما يلي بعض الإحصاءات حول استخدام قاعدة البيانات لمدة شهرين.
عدد السجلات حسب النظام والمكون SELECT fld_app_name, fld_app_module, count(fld_app_name) AS rows_count FROM log_web GROUP BY fld_app_name, fld_app_module WITH TOTALS ORDER BY fld_app_name ASC, rows_count DESC ┌─fld_app_name─────┬─fld_app_module─┬─rows_count─┐ │ site1.domain.ru │ web │ 131441 │ │ site2.domain.ru │ web │ 1751081 │ │ site3.domain.ru │ web │ 106887543 │ │ site3.domain.ru │ svc │ 44908603 │ │ site3.domain.ru │ intgr │ 9813911 │ │ site4.domain.ru │ web │ 772095 │ │ site5.domain.ru │ web │ 17037221 │ │ site5.domain.ru │ intgr │ 838559 │ │ site5.domain.ru │ bo │ 7404 │ │ site6.domain.ru │ web │ 595877 │ │ site7.domain.ru │ web │ 27778858 │ └──────────────────┴────────────────┴────────────┘ Totals: ┌─fld_app_name─┬─fld_app_module─┬─rows_count─┐ │ │ │ 210522593 │ └──────────────┴────────────────┴────────────┘ 11 rows in set. Elapsed: 4.874 sec. Processed 210.52 million rows, 421.67 MB (43.19 million rows/s., 86.51 MB/s.)
كمية البيانات الموجودة على القرص SELECT formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, formatReadableSize(sum(data_compressed_bytes)) AS compressed, sum(rows) AS total_rows FROM system.parts WHERE table = 'log_web' ┌─uncompressed─┬─compressed─┬─total_rows─┐ │ 54.50 GiB │ 4.86 GiB │ 211427094 │ └──────────────┴────────────┴────────────┘ 1 rows in set. Elapsed: 0.035 sec.
درجة ضغط البيانات في الأعمدة SELECT name, formatReadableSize(data_uncompressed_bytes) AS uncompressed, formatReadableSize(data_compressed_bytes) AS compressed, data_uncompressed_bytes / data_compressed_bytes AS compress_ratio FROM system.columns WHERE table = 'log_web' ┌─name───────────────────┬─uncompressed─┬─compressed─┬─────compress_ratio─┐ │ logdate │ 401.53 MiB │ 1.80 MiB │ 223.16665968777315 │ │ logdatetime │ 803.06 MiB │ 35.91 MiB │ 22.363966401202305 │ │ fld_log_file_name │ 220.66 MiB │ 2.60 MiB │ 84.99905736932571 │ │ fld_server_name │ 201.54 MiB │ 50.63 MiB │ 3.980924816977078 │ │ fld_app_name │ 201.17 MiB │ 969.17 KiB │ 212.55518183686877 │ │ fld_app_module │ 201.17 MiB │ 968.60 KiB │ 212.67805817411906 │ │ fld_website_name │ 201.54 MiB │ 1.24 MiB │ 162.7204926761546 │ │ serverIP │ 201.54 MiB │ 50.25 MiB │ 4.010824061219731 │ │ method │ 201.53 MiB │ 43.64 MiB │ 4.617721053304486 │ │ uriStem │ 5.13 GiB │ 832.51 MiB │ 6.311522291936919 │ │ uriQuery │ 2.58 GiB │ 501.06 MiB │ 5.269731450124478 │ │ port │ 803.06 MiB │ 3.98 MiB │ 201.91673864241824 │ │ username │ 318.08 MiB │ 26.93 MiB │ 11.812513794583598 │ │ clientIP │ 2.35 GiB │ 82.59 MiB │ 29.132328640073343 │ │ clientRealIP │ 2.49 GiB │ 465.05 MiB │ 5.478382297052563 │ │ userAgent │ 18.34 GiB │ 764.08 MiB │ 24.57905114484208 │ │ referer │ 14.71 GiB │ 1.37 GiB │ 10.736792723669906 │ │ response │ 803.06 MiB │ 83.81 MiB │ 9.582334090987247 │ │ subresponse │ 399.87 MiB │ 1.83 MiB │ 218.4831068635027 │ │ win32response │ 407.86 MiB │ 7.41 MiB │ 55.050315514606815 │ │ timetaken │ 1.57 GiB │ 402.06 MiB │ 3.9947395692010637 │ │ uriQuery__utm_medium │ 208.17 MiB │ 12.29 MiB │ 16.936148912472955 │ │ uriQuery__utm_source │ 215.18 MiB │ 13.00 MiB │ 16.548367623199912 │ │ uriQuery__utm_campaign │ 381.46 MiB │ 37.94 MiB │ 10.055156353418509 │ │ uriQuery__utm_term │ 231.82 MiB │ 10.78 MiB │ 21.502540454070672 │ │ uriQuery__utm_content │ 441.34 MiB │ 87.60 MiB │ 5.038260760449327 │ │ uriQuery__yclid │ 216.88 MiB │ 16.58 MiB │ 13.07721335008116 │ │ uriQuery__region │ 204.35 MiB │ 9.49 MiB │ 21.52661903446796 │ └────────────────────────┴──────────────┴────────────┴────────────────────┘ 28 rows in set. Elapsed: 0.005 sec.
وصف المكونات المستخدمة
FileBeat. نقل ملف السجل
يراقب هذا المكون التغييرات في ملفات السجل على القرص وينقل المعلومات إلى LogStash. يتم تثبيته على كافة الخوادم حيث تتم كتابة ملفات السجل (عادةً IIS). إنه يعمل في وضع الذيل (أي ، ينقل السجلات المضافة فقط إلى ملف). لكن بشكل منفصل ، يمكنك تكوين نقل الملف بأكمله. هذا مفيد عندما تحتاج إلى تنزيل البيانات من الأشهر السابقة. فقط ضع ملف السجل في مجلد وسوف يقرأه بالكامل.
عندما تتوقف الخدمة ، تتوقف البيانات عن النقل إلى وحدة التخزين.
مثال التكوين على النحو التالي:
filebeat.yml filebeat.inputs: - type: log enabled: true paths: - C:/inetpub/logs/LogFiles/W3SVC1
LogStash. سجل جامع
هذا المكون مخصص لتلقي إدخالات السجل من FileBeat (أو من خلال قائمة انتظار RabbitMQ) ، تحليل وإدراج حزم في قاعدة بيانات ClickHouse.
للإدراج في ClickHouse ، يتم استخدام المكون الإضافي Logstash-output-clickhouse. يحتوي المكون الإضافي Logstash على آلية لاسترداد الطلبات ، ولكن مع إيقاف التشغيل بشكل منتظم ، من الأفضل إيقاف الخدمة نفسها. عندما تتوقف ، تتراكم الرسائل في قائمة انتظار RabbitMQ ، لذلك إذا توقفت لفترة طويلة ، فمن الأفضل إيقاف Filebeats على الخوادم. في نظام لا يستخدم فيه RabbitMQ (على الشبكة المحلية ، يرسل Filebeat سجلات مباشرة إلى Logstash) ، يعمل Filebeats مقبولًا وآمنًا تمامًا ، لذلك فإن عدم إمكانية الوصول إلى الإخراج يذهب دون عواقب.
مثال التكوين على النحو التالي:
log_web__filebeat_clickhouse.conf input { beats { port => 5044 type => 'iis' ssl => true ssl_certificate_authorities => ["/etc/logstash/certs/ca.cer", "/etc/logstash/certs/ca-issuing.cer"] ssl_certificate => "/etc/logstash/certs/server.cer" ssl_key => "/etc/logstash/certs/server-pkcs8.key" ssl_verify_mode => "peer" add_field => { "fld_server_name" => "%{[fields][fld_server_name]}" "fld_app_name" => "%{[fields][fld_app_name]}" "fld_app_module" => "%{[fields][fld_app_module]}" "fld_website_name" => "%{[fields][fld_website_name]}" "fld_log_file_name" => "%{source}" "fld_logformat" => "%{[fields][fld_logformat]}" } } rabbitmq { host => "queue.domain.com" port => 5671 user => "q-reader" password => "password" queue => "web_log" heartbeat => 30 durable => true ssl => true
ClickHouse. سجل التخزين
يتم حفظ سجلات جميع الأنظمة في جدول واحد (انظر بداية المقال). الغرض منه هو تخزين معلومات حول الطلبات: جميع المعلمات متشابهة للتنسيقات المختلفة ، على سبيل المثال ، سجلات IIS وسجلات apache و nginx. بالنسبة لسجلات التطبيق التي ، على سبيل المثال ، يتم تسجيل الأخطاء والرسائل المعلوماتية والتحذيرات ، سيتم تزويد جدول منفصل بالهيكل المقابل (الآن في مرحلة التصميم).
عند تصميم جدول ، من المهم جدًا تحديد المفتاح الأساسي (حسب البيانات التي سيتم فرزها أثناء التخزين). تعتمد درجة ضغط البيانات وسرعة الاستعلام على هذا. في مثالنا ، المفتاح هو
ORDER BY (fld_app_name ، fld_app_module ، logdatetime)
وهذا هو ، باسم النظام ، اسم مكون النظام وتاريخ الحدث. كان التاريخ الأصلي للحدث في المقام الأول. بعد نقلها إلى آخر مكان ، بدأت الاستعلامات تعمل بمعدل أسرع مرتين تقريبًا. سيتطلب تغيير المفتاح الأساسي إعادة إنشاء الجدول وإعادة تحميل البيانات من أجل ClickHouse لإعادة فرز البيانات الموجودة على القرص. هذه عملية صعبة ، لذا فمن المستحسن التفكير في وقت مبكر بما يجب تضمينه في مفتاح الفرز.
تجدر الإشارة أيضًا إلى أنه في الإصدارات الحديثة ، ظهر نوع بيانات LowCardinality. عند استخدامه ، يتم تقليل حجم البيانات المضغوطة بشكل حاد لتلك الحقول التي تحتوي على عدد قليل من العناصر الأساسية (عدد قليل من الخيارات).
الآن يتم استخدام الإصدار 19.6 ، ونحن نخطط لمحاولة تحديث الإصدار إلى الأحدث. تضمنت ميزات رائعة مثل Adaptive Granularity ومؤشرات Skipping وبرنامج ترميز DoubleDelta ، على سبيل المثال.
بشكل افتراضي ، أثناء التثبيت ، يتم ضبط مستوى سجل التكوين على التتبع. يتم تدوير السجلات وأرشفتها ، ولكن يتم توسيعها إلى غيغا بايت. إذا لم تكن هناك حاجة ، فيمكنك ضبط مستوى التحذير ، ثم ينخفض حجم السجل بشكل حاد. يتم تعيين إعدادات التسجيل في ملف config.xml:
<level>warning</level>
بعض الأوامر المفيدة Debian, Linux Altinity. : https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse sudo yum search clickhouse-server sudo yum install clickhouse-server.noarch 1. sudo systemctl status clickhouse-server 2. sudo systemctl stop clickhouse-server 3. sudo systemctl start clickhouse-server ( ";") clickhouse-client
LogStash. FileBeat سجل جهاز التوجيه إلى قائمة الانتظار RabbitMQ
يستخدم هذا المكون لتوجيه السجلات القادمة من FileBeat إلى قائمة انتظار RabbitMQ. هناك نقطتان:
- لسوء الحظ ، لا يحتوي FileBeat على مكون إضافي للكتابة مباشرة إلى RabbitMQ. ومثل هذه الوظيفة ، إذا حكمنا من قبل العش على جيثب بهم ، ليست مخططة للتنفيذ. يوجد مكون إضافي لـ Kafka ، لكن لسبب ما لا يمكننا استخدامه في المنزل.
- هناك متطلبات لجمع السجلات في DMZ. بناءً عليها ، يجب أولاً إضافة السجلات إلى قائمة الانتظار ثم يقرأ LogStash من الخارج الإدخالات من قائمة الانتظار.
لذلك ، على وجه التحديد بالنسبة لحالة موقع الخادم في المنطقة المجردة من السلاح ، يتعين عليك استخدام مثل هذا المخطط المعقد قليلاً. مثال التكوين على النحو التالي:
iis_w3c_logs__filebeat_rabbitmq.conf input { beats { port => 5044 type => 'iis' ssl => true ssl_certificate_authorities => ["/etc/pki/tls/certs/app/ca.pem", "/etc/pki/tls/certs/app/ca-issuing.pem"] ssl_certificate => "/etc/pki/tls/certs/app/queue.domain.com.cer" ssl_key => "/etc/pki/tls/certs/app/queue.domain.com-pkcs8.key" ssl_verify_mode => "peer" } } output {
RabbitMQ. قائمة انتظار الرسائل
يستخدم هذا المكون لتخزين إدخالات السجل في DMZ. يتم التسجيل من خلال مجموعة من Filebeat → LogStash. تتم القراءة من خارج DMZ عبر LogStash. عند التشغيل من خلال RabboitMQ ، تتم معالجة حوالي 4 آلاف رسالة في الثانية.
يتم تكوين توجيه الرسائل وفقًا لاسم النظام ، أي بناءً على بيانات تكوين FileBeat. جميع الرسائل تقع في طابور واحد. إذا تم إيقاف خدمة قائمة الانتظار لأي سبب من الأسباب ، فلن يؤدي ذلك إلى فقد الرسائل: سيتلقى FileBeats أخطاء في الاتصال ويوقف الإرسال المؤقت. وسيتلقى LogStash ، الذي يقرأ من قائمة الانتظار ، أيضًا أخطاء في الشبكة وينتظر استئناف الاتصال. بطبيعة الحال ، لن تتم كتابة البيانات في هذه الحالة في قاعدة البيانات.
تُستخدم الإرشادات التالية لإنشاء قوائم الانتظار وتكوينها:
sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare exchange
Grafana. لوحات
يستخدم هذا المكون لتصور بيانات المراقبة. في هذه الحالة ، يجب عليك تثبيت مصدر بيانات ClickHouse لـ Grafana 4.6+ plugin. كان علينا تعديله قليلاً لزيادة كفاءة معالجة عوامل تصفية SQL على لوحة القيادة.
على سبيل المثال ، نستخدم المتغيرات ، وإذا لم يتم تعيينها في حقل التصفية ، فإننا نرغب في عدم إنشاء شرط في نموذج WHERE (uriStem = `` AND AND uriStem! = ''). في هذه الحالة ، سوف تقرأ ClickHouse عمود uriStem. بشكل عام ، جربنا خيارات مختلفة وقمنا في نهاية المطاف بإصلاح المكون الإضافي (قيمة $ valueIfEmpty) بحيث في حالة وجود قيمة فارغة ، فإنه سيعود 1 ، دون ذكر العمود نفسه.
والآن يمكنك استخدام هذا الاستعلام للمخطط
$columns(response, count(*) c) from $table where $adhoc and $valueIfEmpty($fld_app_name, 1, fld_app_name = '$fld_app_name') and $valueIfEmpty($fld_app_module, 1, fld_app_module = '$fld_app_module') and $valueIfEmpty($fld_server_name, 1, fld_server_name = '$fld_server_name') and $valueIfEmpty($uriStem, 1, uriStem like '%$uriStem%') and $valueIfEmpty($clientRealIP, 1, clientRealIP = '$clientRealIP')
الذي تم تحويله إلى SQL من هذا القبيل (لاحظ أنه تم تحويل حقول uriStem الفارغة إلى 1 فقط)
SELECT t, groupArray((response, c)) AS groupArr FROM ( SELECT (intDiv(toUInt32(logdatetime), 60) * 60) * 1000 AS t, response, count(*) AS c FROM default.log_web WHERE (logdate >= toDate(1565061982)) AND (logdatetime >= toDateTime(1565061982)) AND 1 AND (fld_app_name = 'site1.domain.ru') AND (fld_app_module = 'web') AND 1 AND 1 AND 1 GROUP BY t, response ORDER BY t ASC, response ASC ) GROUP BY t ORDER BY t ASC
استنتاج
أصبح ظهور قاعدة بيانات ClickHouse حدثًا مهمًا في السوق. كان من الصعب أن نتخيل أنه في لحظة ، كنا مسلحين بأداة قوية وعملية للتعامل مع البيانات الضخمة. بطبيعة الحال ، مع زيادة الاحتياجات (على سبيل المثال ، المشاركة والنسخ المتماثل لخوادم متعددة) ، سيصبح المخطط أكثر تعقيدًا. ولكن عند الانطباعات الأولى ، فإن العمل مع قاعدة البيانات هذه أمر لطيف للغاية. يتبين أن المنتج مصنوع "للناس".
مقارنة بـ ElasticSearch ، يتم تقليل تكلفة تخزين السجلات ومعالجتها ، وفقًا للتقديرات الأولية ، من خمس إلى عشر مرات. بمعنى آخر ، إذا كنا بحاجة إلى تكوين مجموعة من العديد من الأجهزة ، بالنسبة إلى الكمية الحالية من البيانات ، فعند استخدام ClickHouse ، نحتاج إلى جهاز واحد منخفض الطاقة. نعم ، بالطبع ، لدى تطبيق البحث المرن أيضًا آليات لضغط البيانات على القرص والميزات الأخرى التي يمكن أن تقلل إلى حد كبير من استهلاك الموارد ، ولكن بالمقارنة مع ClickHouse ، فإن هذا سيكون مكلفًا.
بدون أي تحسينات خاصة من جانبها ، على الإعدادات الافتراضية ، يعمل تحميل البيانات واسترداد البيانات من قاعدة البيانات بسرعة مذهلة. لدينا حتى الآن القليل من البيانات (حوالي 200 مليون سجل) ، ولكن الخادم نفسه ضعيف. في المستقبل ، يمكننا استخدام هذه الأداة لأغراض أخرى لا تتعلق بتخزين السجلات. على سبيل المثال ، بالنسبة للتحليلات الشاملة ، في مجال الأمن ، والتعلم الآلي.
في النهاية ، قليلا عن إيجابيات وسلبيات.
سلبيات
- تحميل السجلات في حزم كبيرة. هذه ، من ناحية ، ميزة ، ولكن لا يزال يتعين عليك استخدام مكونات إضافية لتخزين السجلات مؤقتًا. هذه المهمة ليست دائما بسيطة ، ولكن لا تزال قابلة للحل. وأود أن تبسيط المخطط.
- غالبًا ما تنقسم بعض الوظائف الغريبة أو الميزات الجديدة إلى إصدارات جديدة. هذا يثير المخاوف ، مما يقلل من الرغبة في الترقية إلى إصدار جديد. على سبيل المثال ، يعد محرك طاولة Kafka ميزة مفيدة للغاية تتيح لك قراءة الأحداث مباشرة من Kafka ، دون تنفيذ المستهلكين. لكن بالنظر إلى عدد المشكلات على جيثب ، فإننا لا نزال حذرين من استخدام هذا المحرك في الإنتاج. ومع ذلك ، إذا لم تقم بحركات حادة في الجانب وتستخدم الوظيفة الأساسية ، فستعمل بشكل ثابت.
الأشياء الجيدة
- لا تبطئ.
- عتبة دخول منخفضة.
- المصدر المفتوح
- إنه مجاني.
- ميزان جيد (التقسيم / النسخ خارج الصندوق)
- يتم تضمينه في سجل البرنامج الروسي الذي أوصت به وزارة الاتصالات.
- وجود دعم رسمي من ياندكس.