ClickHouse مدیریت‌شده، برای تحلیل سریع داده

هر جا داده بیشتر اضافه می‌شود تا ویرایش، و پرسش‌ها از جنس «چند تا، چقدر، در کدام بازه» هستند، ClickHouse جای خودش را پیدا می‌کند. چند نمونهٔ رایج:

تقریباً همهٔ جدول‌های تولیدی در ClickHouse از موتور MergeTree یا یکی از گونه‌های آن استفاده می‌کنند. هر INSERT یک part جدید روی دیسک می‌سازد و ClickHouse در پس‌زمینه part‌ها را با هم ادغام می‌کند. مهم‌ترین تصمیم طراحی، کلید ORDER BY است: داده روی دیسک بر اساس همین کلید مرتب می‌شود و ایندکس پراکندهٔ ClickHouse فقط با آن کار می‌کند.

قاعدهٔ عملی این است که ستون‌هایی را که بیشتر در WHERE فیلتر می‌کنید و تعداد مقادیر یکتای کمتری دارند، اول بیاورید و زمان را بعد از آن‌ها. مثلاً برای جدول رویدادها، ترتیب (نوع رویداد، شناسهٔ سایت، زمان) معمولاً از (زمان، شناسهٔ کاربر) بهتر عمل می‌کند. PARTITION BY را هم معمولاً بر اساس ماه تعریف کنید؛ پارتیشن خیلی ریز تعداد part‌ها را بی‌دلیل زیاد می‌کند.

برای گزارش‌های پرتکرار، materialized view نتیجهٔ تجمیع را هنگام INSERT محاسبه و در جدول جداگانه‌ای ذخیره می‌کند؛ داشبورد به‌جای پیمایش همهٔ رویدادها، چند هزار ردیف خلاصه را می‌خواند. TTL روی جدول هم داده‌های قدیمی‌تر از بازهٔ دلخواه را خودکار حذف می‌کند تا دیسک پر نشود.

این‌ها تنظیماتی است که هنگام نصب اعمال می‌شود؛ بقیهٔ پیکربندی همان مقادیر پیش‌فرض بستهٔ رسمی ClickHouse است.

هزینه ساعتی است و از کیف پول کسر می‌شود: قیمت سرور پشتیبان به‌اضافهٔ کارمزد مدیریت. اعداد جدول از همان منبع قیمت‌گذاری سامانهٔ صورت‌حساب خوانده می‌شوند و تعرفهٔ تعریف‌شده برای زمان راه‌اندازی هستند؛ تا روز باز شدن سفارش ممکن است تغییر کنند و مبلغ نهایی پیش از ساخت در پنل نمایش داده می‌شود.

برخلاف Elasticsearch و Cassandra‏، ClickHouse روی اندازهٔ mini هم اجرا می‌شود. اولین ساعت هنگام ساخت کسر می‌شود و با حذف نمونه محاسبه متوقف می‌شود؛ تعهد ماهانه ندارد. معادل ماهانه بر مبنای ۷۳۰ ساعت است. برای مقایسه با سایر سرویس‌ها به قیمت‌گذاری و ماشین‌حساب هزینه سر بزنید.

رایج‌ترین اشتباه این است که ClickHouse را جایگزین دیتابیس اصلی اپلیکیشن کنیم. ClickHouse برای UPDATE و DELETE مکرر تک‌ردیفی، تراکنش چندجدولی و کلید یکتا ساخته نشده است. معماری درست معمولاً این است: PostgreSQL یا MySQL سفارش‌ها و کاربران را نگه می‌دارد و رویدادها یا کپی دوره‌ای داده برای تحلیل به ClickHouse فرستاده می‌شود.

این جدول تفاوت دو نوع دیتابیس را در کارهای روزمره نشان می‌دهد:

وقتی سفارش ClickHouse باز شود، همهٔ مراحل از پنل و ابزارهای معمول خودتان انجام می‌شود:

ClickHouse برای INSERT‌های بزرگ و کم‌تعداد ساخته شده است. هر INSERT یک part جدید می‌سازد؛ اگر هر رویداد را جداگانه درج کنید، در چند دقیقه هزاران part کوچک ساخته می‌شود و ادغام پس‌زمینه از آن عقب می‌ماند. توصیهٔ رایج این است که در هر INSERT دست‌کم چند هزار ردیف بفرستید و تعداد INSERT‌ها را به چند بار در ثانیه محدود کنید.

اگر اپلیکیشن رویدادها را تک‌تک تولید می‌کند، دو راه ساده دارید. یکی تنظیم async_insert در سطح کاربر یا query است تا خود ClickHouse درج‌های کوچک را در حافظه جمع کند و یکجا بنویسد. دیگری استفاده از یک صف بین اپلیکیشن و ClickHouse است؛ صف پیام مدیریت‌شده می‌تواند رویدادها را نگه دارد تا یک worker آن‌ها را دسته‌ای وارد کند.

برای بارگذاری اولیه، فرمت‌هایی مثل CSV‏، JSONEachRow و Parquet مستقیماً پشتیبانی می‌شوند و می‌توانید فایل را با یک دستور curl به رابط HTTP بفرستید.

کاربر پیش‌فرض ClickHouse بدون رمز نصب می‌شود، اما در نسخهٔ مدیریت‌شده پیش از اولین اجرا یک رمز تصادفی ۲۴ کاراکتری برایش تعیین می‌شود و فقط هش SHA-256 آن در پیکربندی سرور ذخیره می‌شود. خود رمز رمزنگاری‌شده در پنل نگه‌داری می‌شود و از طریق فایل اطلاعات اتصال در حساب شما قابل دریافت است.

برای هر مصرف‌کننده کاربر جدا بسازید: داشبورد BI فقط به دسترسی خواندنی روی یک دیتابیس نیاز دارد و سرویس ورود داده فقط به INSERT روی جدول‌های مشخص. ClickHouse مدیریت کاربر و نقش را با SQL انجام می‌دهد و با CREATE USER و GRANT این کار در چند خط تمام می‌شود.

پورت‌های ۸۱۲۳ و ۹۰۰۰ برای اتصال از بیرون باز هستند و در پیکربندی فعلی TLS ندارند. رمزها را فقط در سمت سرور نگه دارید و برای بررسی دسترس‌پذیری پورت از شبکهٔ خودتان از ابزار بررسی پورت استفاده کنید.

برای پایگاه‌های دادهٔ تحلیلی، از جمله ClickHouse، بکاپ خودکار ارائه نمی‌شود و برنامهٔ نسخهٔ پشتیبان بر عهدهٔ شماست. خبر خوب این است که دادهٔ تحلیلی معمولاً از منبع دیگری مثل دیتابیس اصلی یا لاگ‌ها قابل بازسازی است؛ پیش از هر چیز مشخص کنید کدام جدول‌ها واقعاً منحصربه‌فردند.

ClickHouse تابع s3 دارد که خروجی یک query را مستقیماً در فضای ذخیره‌سازی سازگار با S3 می‌نویسد. با این روش می‌توانید جدول‌های مهم را به‌صورت دوره‌ای در قالب Parquet یا Native در فضای ذخیره‌سازی ابری نگه دارید و در صورت نیاز با همان تابع دوباره بخوانید. برای جدول‌های کوچک‌تر، clickhouse-client با یک SELECT و فرمت خروجی دلخواه کافی است.

ساختار جدول‌ها را هم با SHOW CREATE TABLE ذخیره کنید؛ بدون آن، بازگرداندن داده به همان شکل قبلی دشوار است.

اگر ClickHouse را جای دیگری اجرا می‌کنید، ابتدا ساختار جدول‌ها را با SHOW CREATE TABLE بازسازی کنید. سپس دو راه دارید: تابع remote که از نمونهٔ جدید مستقیماً به مبدأ وصل می‌شود و داده را با INSERT INTO ... SELECT منتقل می‌کند، یا خروجی فایل در فرمت Native یا Parquet و بارگذاری آن در مقصد.

برای انتقال از PostgreSQL یا MySQL‏، ClickHouse توابع جدولی postgresql و mysql دارد که می‌توانند یک جدول را مستقیم از دیتابیس مبدأ بخوانند؛ کافی است دیتابیس مبدأ از نمونهٔ ClickHouse قابل دسترسی باشد. برای حجم‌های بزرگ، انتقال را بر اساس بازه‌های زمانی تکه‌تکه انجام دهید تا یک query طولانی همه‌چیز را متوقف نکند.

نمونهٔ ClickHouse تک‌نودی است؛ جدول‌های Replicated‏، sharding و خوشه در این سرویس ارائه نمی‌شوند. اگر سرور میزبان برای نگه‌داری یا خرابی از دسترس خارج شود، دیتابیس هم تا بازگشت آن در دسترس نیست. تغییر اندازهٔ نمونهٔ موجود هم در فاز نخست پیش‌بینی نشده است.

به سیستم‌عامل و فایل‌های پیکربندی دسترسی ندارید، بکاپ خودکار ارائه نمی‌شود و TLS روی پورت‌ها فعال نیست. روی اندازه‌های کوچک، query‌های بسیار سنگین ممکن است به سقف حافظه برسند؛ در این حالت query را محدودتر کنید یا اندازهٔ بزرگ‌تری بسازید. اگر به کنترل کامل یا چند نود نیاز دارید، ClickHouse را روی سرور ابری خودتان نصب کنید.