استفاده از Clickhouse به عنوان جایگزینی برای ELK، Big Query و TimescaleDB

خانه کلیک یک سیستم مدیریت پایگاه داده ستونی منبع باز برای پردازش پرس و جو تحلیلی آنلاین (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+.

شرکت حمل و نقل پستی Qwintry استفاده از Clickhouse را در سال 2018 برای گزارش‌دهی آغاز کرد و از سادگی، مقیاس‌پذیری، پشتیبانی از SQL و سرعت آن بسیار تحت تأثیر قرار گرفت. سرعت این DBMS در حد جادو است.

سهولت

کلیک هاوس با یک فرمان روی اوبونتو نصب می شود. اگر SQL می دانید، می توانید بلافاصله برای نیازهای خود استفاده از Clickhouse را شروع کنید. با این حال، این بدان معنا نیست که شما می توانید "نمایش جدول ایجاد" را در MySQL انجام دهید و SQL را در Clickhouse کپی کنید.

در مقایسه با MySQL، تفاوت‌های مهمی در نوع داده‌ها در تعاریف طرح‌واره جدول وجود دارد، بنابراین برای تغییر دادن تعاریف طرح‌واره جدول و یادگیری موتورهای جدول برای راحت‌تر شدن، همچنان به زمان نیاز دارید.

Clickhouse بدون هیچ نرم افزار اضافی عالی کار می کند، اما اگر می خواهید از Replication استفاده کنید، باید ZooKeeper را نصب کنید. تجزیه و تحلیل عملکرد پرس و جو نتایج عالی را نشان می دهد - جداول سیستم حاوی تمام اطلاعات است و تمام داده ها را می توان با استفاده از SQL قدیمی و خسته کننده بازیابی کرد.

کارایی

• معیار مقایسه Clickhouse با Vertica و MySQL در پیکربندی سرور: دو سوکت Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz. رم 128 گیگابایتی؛ md RAID-5 در 8 6 ترابایت SATA HDD، ext4.
• معیار مقایسه کلیک هاوس با ذخیره سازی ابری Amazon RedShift.
• گزیده های وبلاگ Cloudflare در عملکرد Clickhouse:

پایگاه داده ClickHouse طراحی بسیار ساده ای دارد - همه گره ها در خوشه عملکرد یکسانی دارند و فقط از ZooKeeper برای هماهنگی استفاده می کنند. ما یک خوشه کوچک از چندین گره ساختیم و آزمایشاتی را انجام دادیم، که طی آن متوجه شدیم که سیستم عملکرد بسیار چشمگیری دارد که با مزایای بیان شده در معیارهای DBMS تحلیلی مطابقت دارد. ما تصمیم گرفتیم به مفهوم پشت کلیک هاوس نگاه دقیق تری داشته باشیم. اولین مانع برای تحقیق، کمبود ابزار و جامعه کوچک ClickHouse بود، بنابراین ما به طراحی این DBMS پرداختیم تا نحوه عملکرد آن را درک کنیم.

ClickHouse از دریافت مستقیم داده ها از کافکا پشتیبانی نمی کند زیرا فقط یک پایگاه داده است، بنابراین ما سرویس آداپتور خود را در Go نوشتیم. پیام‌های کدگذاری شده Cap'n Proto از کافکا را می‌خواند، آنها را به TSV تبدیل می‌کند و به صورت دسته‌ای از طریق رابط HTTP در ClickHouse قرار می‌دهد. ما بعداً این سرویس را بازنویسی کردیم تا از کتابخانه Go در ارتباط با رابط کاربری ClickHouse برای بهبود عملکرد استفاده کنیم. هنگام ارزیابی عملکرد بسته های دریافتی، یک چیز مهم را کشف کردیم - معلوم شد که برای ClickHouse این عملکرد به شدت به اندازه بسته، یعنی تعداد ردیف های درج شده به طور همزمان بستگی دارد. برای درک اینکه چرا این اتفاق می افتد، ما به نحوه ذخیره سازی داده ها توسط ClickHouse نگاه کردیم.

موتور اصلی یا بهتر بگوییم خانواده موتورهای جدولی که توسط ClickHouse برای ذخیره داده ها استفاده می شود MergeTree است. این موتور از نظر مفهومی شبیه به الگوریتم LSM مورد استفاده در Google BigTable یا Apache Cassandra است، اما از ساخت جدول حافظه میانی اجتناب می‌کند و داده‌ها را مستقیماً روی دیسک می‌نویسد. این به آن توان نوشتن عالی می دهد، زیرا هر بسته درج شده فقط بر اساس کلید اصلی مرتب می شود، فشرده می شود و برای تشکیل یک قطعه روی دیسک نوشته می شود.

عدم وجود جدول حافظه یا هر مفهومی از "تازه بودن" داده ها نیز به این معنی است که آنها فقط می توانند اضافه شوند؛ سیستم از تغییر یا حذف پشتیبانی نمی کند. در حال حاضر، تنها راه حذف داده‌ها، حذف آن‌ها بر اساس ماه تقویم است، زیرا بخش‌ها هرگز از مرز یک ماه عبور نمی‌کنند. تیم ClickHouse به طور فعال در تلاش است تا این ویژگی را قابل تنظیم کند. از سوی دیگر، نوشتن و ادغام بخش‌ها را بدون بحث می‌کند، بنابراین مقیاس‌های توان عملیاتی را به صورت خطی با تعداد درج‌های همزمان دریافت کنید تا زمانی که I/O یا اشباع هسته رخ دهد.
با این حال، این همچنین به این معنی است که سیستم برای بسته های کوچک مناسب نیست، بنابراین از سرویس ها و درج کننده های کافکا برای بافر استفاده می شود. در مرحله بعد، ClickHouse در پس‌زمینه به انجام مداوم ادغام بخش‌ها ادامه می‌دهد، به طوری که بسیاری از اطلاعات کوچک بارها با هم ترکیب و ضبط می‌شوند و در نتیجه شدت ضبط افزایش می‌یابد. با این حال، تا زمانی که ادغام ادامه داشته باشد، تعداد زیادی از قطعات غیر متصل باعث فشار شدید درج ها می شود. ما دریافته‌ایم که بهترین سازش بین مصرف بی‌درنگ و عملکرد بلع، وارد کردن تعداد محدودی از درج‌ها در هر ثانیه در جدول است.

کلید عملکرد خواندن جدول، نمایه سازی و مکان داده ها روی دیسک است. مهم نیست که پردازش چقدر سریع باشد، زمانی که موتور نیاز به اسکن ترابایت داده از دیسک دارد و فقط از بخشی از آن استفاده می کند، زمان می برد. ClickHouse یک فروشگاه ستونی است، بنابراین هر بخش حاوی یک فایل برای هر ستون (ستون) با مقادیر مرتب شده برای هر ردیف است. به این ترتیب، می‌توان ابتدا کل ستون‌های مفقود شده در پرس و جو را نادیده گرفت و سپس چندین سلول را می‌توان به موازات اجرای بردار پردازش کرد. برای جلوگیری از اسکن کامل، هر بخش دارای یک فایل فهرست کوچک است.

با توجه به اینکه همه ستون‌ها بر اساس «کلید اصلی» مرتب شده‌اند، فایل فهرست فقط حاوی برچسب‌ها (ردیف‌های گرفته‌شده) هر ردیف N است تا بتواند آن‌ها را حتی برای جداول بسیار بزرگ در حافظه نگه دارد. به عنوان مثال، می‌توانید تنظیمات پیش‌فرض را روی «مارک کردن هر ردیف ۸۱۹۲» و سپس فهرست‌بندی «ناچیز» جدول با ۱ تریلیون تنظیم کنید. خطوطی که به راحتی در حافظه قرار می گیرند تنها 8192 کاراکتر می گیرند.

توسعه سیستم

توسعه و بهبود Clickhouse را می توان در ردیابی کرد repo Github و مطمئن شوید که روند "بزرگ شدن" با سرعت چشمگیر اتفاق می افتد.

محبوبیت

به نظر می رسد که محبوبیت کلیک هاوس به طور تصاعدی در حال افزایش است، به خصوص در جامعه روسی زبان. کنفرانس High load 2018 سال گذشته (مسکو، 8-9 نوامبر 2018) نشان داد که هیولاهایی مانند vk.com و Badoo از Clickhouse استفاده می‌کنند که با آن داده‌ها (مثلاً گزارش‌ها) را از ده‌ها هزار سرور به طور همزمان درج می‌کنند. در یک ویدیو 40 دقیقه ای یوری ناصردینوف از تیم VKontakte در مورد نحوه انجام این کار صحبت می کند. به زودی برای سهولت کار با مطالب، رونوشت را در Habr قرار خواهیم داد.

برنامه های کاربردی

پس از گذراندن مدتی برای تحقیق، فکر می‌کنم حوزه‌هایی وجود دارد که ClickHouse می‌تواند مفید باشد یا می‌تواند به طور کامل جایگزین راه‌حل‌های سنتی و محبوب دیگر مانند MySQL، PostgreSQL، ELK، Google Big Query، Amazon RedShift، TimescaleDB، Hadoop، MapReduce، Pinot و دروید. در زیر جزئیات استفاده از ClickHouse برای نوسازی یا جایگزینی کامل DBMS فوق توضیح داده شده است.

گسترش قابلیت های MySQL و PostgreSQL

اخیراً ما تا حدی MySQL را با ClickHouse برای پلتفرم خبرنامه خود جایگزین کردیم خبرنامه Mautic. مشکل این بود که MySQL، به دلیل طراحی ضعیف، تمام ایمیل های ارسال شده و هر لینک در آن ایمیل را با هش base64 ثبت می کرد و یک جدول MySQL بزرگ (email_stats) ایجاد می کرد. پس از ارسال تنها 10 میلیون ایمیل برای مشترکین سرویس، این جدول 150 گیگابایت فضای فایل را اشغال کرد و MySQL در جستجوهای ساده شروع به "احمقانه" کرد. برای رفع مشکل فضای فایل، ما با موفقیت از فشرده سازی جدول InnoDB استفاده کردیم که آن را به میزان 4 کاهش داد. با این حال، ذخیره بیش از 20 تا 30 میلیون ایمیل در MySQL فقط به خاطر خواندن تاریخچه منطقی نیست، زیرا هر پرس و جو ساده ای که به دلایلی نیاز به انجام یک اسکن کامل داشته باشد، منجر به تعویض و تعداد زیادی از ایمیل ها می شود. /O load که طبق آن به طور مرتب از Zabbix اخطار دریافت می کردیم.

کلیک هاوس از دو الگوریتم فشرده سازی استفاده می کند که حجم داده ها را تقریباً کاهش می دهد 3-4 بار، اما در این مورد خاص داده ها به ویژه "تراکم پذیر" بودند.

جایگزینی ELK

بر اساس تجربه شخصی من، پشته ELK (ElasticSearch، Logstash و Kibana، در این مورد خاص ElasticSearch) برای اجرا به منابع بسیار بیشتری نسبت به ذخیره گزارش‌ها نیاز دارد. ElasticSearch یک موتور عالی است اگر به جستجوی گزارش کامل متنی خوب نیاز دارید (که فکر نمی‌کنم واقعاً به آن نیاز داشته باشید)، اما من نمی‌دانم که چرا به موتور ثبت گزارش استاندارد تبدیل شده است. عملکرد جذب آن در ترکیب با Logstash حتی در بارهای نسبتاً سبک نیز مشکلاتی را برای ما به همراه داشت و ما را ملزم به افزودن رم و فضای دیسک بیشتر و بیشتر می کرد. به عنوان یک پایگاه داده، Clickhouse به دلایل زیر بهتر از ElasticSearch است:

• پشتیبانی از گویش SQL.
• بهترین درجه فشرده سازی داده های ذخیره شده؛
• پشتیبانی از جستجوهای عبارت منظم Regex به جای جستجوی متن کامل.
• بهبود زمان‌بندی پرس و جو و عملکرد کلی بالاتر.

در حال حاضر، بزرگترین مشکلی که هنگام مقایسه ClickHouse با ELK ایجاد می شود، نبود راه حل برای آپلود لاگ ها و همچنین نبود مستندات و آموزش های مربوط به موضوع است. علاوه بر این، هر کاربر می تواند ELK را با استفاده از کتابچه راهنمای اقیانوس دیجیتال پیکربندی کند، که برای اجرای سریع چنین فناوری هایی بسیار مهم است. یک موتور پایگاه داده وجود دارد، اما هنوز Filebeat برای ClickHouse وجود ندارد. بله، آنجاست روان و سیستمی برای کار با لاگ ها خانه چوبی، یک ابزار وجود دارد دم کلیکی برای وارد کردن داده های فایل لاگ به ClickHouse، اما همه اینها زمان بیشتری می برد. با این حال، ClickHouse به دلیل سادگی همچنان پیشرو است، بنابراین حتی مبتدیان نیز می توانند به راحتی آن را نصب کرده و تنها در 10 دقیقه شروع به استفاده کامل از آن کنند.

با ترجیح راه حل های مینیمالیستی، سعی کردم از FluentBit، ابزاری برای ارسال گزارش ها با حافظه بسیار کم، به همراه ClickHouse استفاده کنم، در حالی که سعی کردم از کافکا اجتناب کنم. با این حال، ناسازگاری های جزئی باید برطرف شود، مانند مشکلات فرمت تاریخقبل از اینکه این کار بدون لایه پروکسی انجام شود که داده ها را از FluentBit به ClickHouse تبدیل می کند.

به عنوان یک جایگزین، Kibana می تواند به عنوان یک Backend ClickHouse استفاده شود گرافانا. با توجه به آنچه که من می‌دانم، این می‌تواند هنگام رندر کردن تعداد زیادی از نقاط داده، به خصوص در نسخه‌های قدیمی‌تر Grafana، مشکلات عملکردی ایجاد کند. ما هنوز این را در Qwintry امتحان نکرده‌ایم، اما شکایت‌هایی در این مورد هر از گاهی در کانال پشتیبانی ClickHouse در تلگرام ظاهر می‌شود.

جایگزینی 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 است که کار با سری های زمانی را در یک پایگاه داده معمولی بهینه می کند (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

اگرچه ClickHouse یک رقیب جدی در طاقچه سری های زمانی نیست، اما ساختار ستونی و اجرای پرس و جو بردار، در اکثر موارد پردازش پرس و جو تحلیلی بسیار سریعتر از TimescaleDB است. در عین حال، عملکرد دریافت داده های دسته ای از ClickHouse تقریباً 3 برابر بیشتر است و همچنین از فضای دیسک 20 برابر کمتر استفاده می کند که برای پردازش حجم زیادی از داده های تاریخی بسیار مهم است: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

برخلاف ClickHouse، تنها راه برای صرفه جویی در فضای دیسک در TimescaleDB استفاده از ZFS یا فایل سیستم های مشابه است.

به‌روزرسانی‌های آتی ClickHouse احتمالاً فشرده‌سازی دلتا را معرفی می‌کند که آن را برای پردازش و ذخیره داده‌های سری زمانی مناسب‌تر می‌کند. TimescaleDB ممکن است در موارد زیر انتخاب بهتری نسبت به ClickHouse خالی باشد:

• نصب های کوچک با رم بسیار کم (<3 گیگابایت)؛
• تعداد زیادی INSERT کوچک که نمی خواهید آنها را به قطعات بزرگ بافر کنید.
• سازگاری بهتر، یکنواختی و الزامات ACID؛
• پشتیبانی PostGIS؛
• پیوستن به جداول PostgreSQL موجود، زیرا Timescale DB اساساً PostgreSQL است.

رقابت با سیستم های Hadoop و MapReduce

Hadoop و سایر محصولات MapReduce می توانند محاسبات پیچیده زیادی را انجام دهند، اما تمایل دارند با تاخیرهای زیادی اجرا شوند. ClickHouse این مشکل را با پردازش ترابایت داده و تولید نتایج تقریباً فوری برطرف می کند. بنابراین، ClickHouse در انجام تحقیقات تحلیلی سریع و تعاملی بسیار مؤثرتر است، که باید مورد علاقه دانشمندان داده باشد.

رقابت با پینو و دروید

نزدیکترین رقبای ClickHouse محصولات متن باز ستونی و خطی مقیاس پذیر Pinot و Druid هستند. یک کار عالی برای مقایسه این سیستم ها در مقاله منتشر شده است رومانا لونتوا 1 فوریه 2018

این مقاله نیاز به به روز رسانی دارد - می گوید که ClickHouse از عملیات UPDATE و DELETE پشتیبانی نمی کند، که برای آخرین نسخه ها کاملاً صادق نیست.

ما تجربه زیادی با این پایگاه‌های داده نداریم، اما من واقعاً از پیچیدگی زیرساخت‌های مورد نیاز برای اجرای Druid و Pinot خوشم نمی‌آید - این یک دسته کامل از قطعات متحرک است که از هر طرف توسط جاوا احاطه شده‌اند.

Druid و Pinot پروژه‌های انکوباتور آپاچی هستند که پیشرفت آن‌ها به طور مفصل توسط آپاچی در صفحات پروژه GitHub خود پوشش داده شده است. پینو در اکتبر 2018 در انکوباتور ظاهر شد و دروید 8 ماه زودتر - در فوریه - به دنیا آمد.

فقدان اطلاعات در مورد نحوه عملکرد AFS سوالاتی و شاید احمقانه را برای من ایجاد می کند. نمی دانم آیا نویسندگان پینو متوجه شده اند که بنیاد آپاچی نسبت به دروید مطلوب تر است و آیا این نگرش نسبت به رقیب باعث حس حسادت می شود؟ اگر حامیان اولی ناگهان به دومی علاقه مند شوند، توسعه دروید کند می شود و توسعه پینو سرعت می گیرد؟

معایب ClickHouse

نابالغی: بدیهی است که این هنوز یک فناوری خسته کننده نیست، اما در هر صورت، چنین چیزی در سایر DBMS های ستونی مشاهده نمی شود.

درج های کوچک در سرعت بالا عملکرد خوبی ندارند: درج ها باید به تکه های بزرگتر تقسیم شوند زیرا عملکرد درج های کوچک متناسب با تعداد ستون ها در هر ردیف کاهش می یابد. به این ترتیب ClickHouse داده ها را روی دیسک ذخیره می کند - هر ستون نشان دهنده 1 فایل یا بیشتر است، بنابراین برای درج 1 ردیف حاوی 100 ستون، باید حداقل 100 فایل را باز کرده و بنویسید. به همین دلیل است که درج‌های بافر به یک واسطه نیاز دارند (مگر اینکه خود مشتری بافر را ارائه کند) - معمولاً کافکا یا نوعی سیستم مدیریت صف. همچنین می‌توانید از موتور جدول بافر برای کپی کردن تکه‌های بزرگ داده در جداول MergeTree استفاده کنید.

اتصال به جدول توسط RAM سرور محدود می شود، اما حداقل آنها وجود دارند! به عنوان مثال، Druid و Pinot اصلاً چنین اتصالاتی ندارند، زیرا اجرای مستقیم آنها در سیستم های توزیع شده که از جابجایی قطعات بزرگ داده بین گره ها پشتیبانی نمی کنند، دشوار است.

یافته ها

ما قصد داریم در سال های آینده به طور گسترده از ClickHouse در Qwintry استفاده کنیم، زیرا این DBMS تعادل عالی عملکرد، سربار کم، مقیاس پذیری و سادگی را ارائه می دهد. من تقریباً مطمئن هستم که وقتی جامعه ClickHouse راه‌های بیشتری برای استفاده از آن در نصب‌های کوچک تا متوسط ​​پیدا کند، به سرعت شروع به گسترش خواهد کرد.

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV از 199 دلار در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com