‏OpenReplay چطور با ClickHouse روزی ۶ ترابایت داده رو مدیریت می‌کنه

تو این مطلب از وبلاگ ClickHouse، تیم OpenReplay تعریف می‌کنه چطور دیتابیس تحلیلی‌شون رو عوض کردن. OpenReplay یه پلتفرم session replay (یعنی ضبط و بازپخش کارهایی که کاربر تو اپ انجام داده) و product analytics هست. متن‌بازه و کاملاً روی سرورهای خود مشتری نصب می‌شه. مهدی عثمان، مدیرعامل‌شون، می‌گه انگار کنار کاربر نشستی و بی‌صدا نگاه می‌کنی چیکار می‌کنه.

سال ۲۰۱۹ همه‌چی روی Postgres بود. متادیتا مشکلی نداشت، ولی رویدادهای رفتاری مثل کلیک و بازدید صفحه اذیت می‌کردن. هدف تیم این بود که جست‌وجوی session زیر یه ثانیه جواب بده. با Postgres حتی بعد از index و partition و sharding، کوئری‌ها حدود سه ثانیه و گاهی تا ۱۰ ثانیه طول می‌کشیدن. بعد از مهاجرت به ClickHouse میانگین به حدود یه ثانیه رسید. جدول رویدادهایی که تو Postgres حدود ۱ ترابایت بود، تو ClickHouse با فشرده‌سازی شد ۱ تا ۲ گیگابایت.

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

حالا همه‌ی رویدادها تو یه جدول می‌رن و زنجیره‌ای از materialized viewها (یعنی کوئری‌هایی که با هر insert خودکار اجرا می‌شن و نتیجه رو یه جای دیگه می‌ریزن) داده رو تبدیل و جابه‌جا می‌کنن. قبلاً این کار با trigger تو Postgres یا workerهای Go انجام می‌شد و هر تغییر دو روز وقت می‌برد. الان حدود نصف روز. تیم برای فیچرهای جدید اول با materialized view آزمایش می‌کنه و وقتی ساختار داده جا افتاد، می‌برتش تو کد Go که insert سریع‌تر بشه.

پشتیبانی native از JSON تو ClickHouse هم اجازه داد مشتری‌ها رویدادهای دلخواه خودشون رو بفرستن، مثل «پرداخت انجام شد» با کلی property، و بعد راحت روش funnel و heat map بسازن. کل schema عملاً دو جدوله: یکی sessions برای متادیتا و یکی events که یه جدول بزرگ و flat که همه‌ی رویدادها توش ریخته می‌شن.

بعضی مشتری‌ها روزی یکی دو میلیون رویداد دارن و بعضی میلیاردها، تا ۶ ترابایت در روز. ولی هر نصب فقط روی یه نمونه‌ی ClickHouse اجرا می‌شه و تیم به‌جای sharding، با اضافه کردن RAM و CPU مقیاس عمودی می‌ده تا هزینه‌ی عملیاتی برای مشتری پایین بمونه. هدف بعدی اینه که همه‌ی صفحه‌ها زیر دو ثانیه جواب بدن. query cache هم فعال شده و تیم داره یه فیچر agent می‌سازه که خودکار sessionها رو بررسی کنه و trace‌هاش رو هم تو ClickHouse بریزه.

نکات کلیدی:

• جست‌وجوی session از حدود ۳ تا ۱۰ ثانیه تو Postgres به حدود ۱ ثانیه تو ClickHouse رسید.
• جدول رویدادهای حدوداً ۱ ترابایتی تو ClickHouse شد ۱ تا ۲ گیگابایت.
• TTL جای پاک‌سازی‌های دستی آخر هفته با vacuum رو گرفت.
• materialized viewها زمان تغییر pipeline رو از دو روز به حدود نصف روز رسوندن.
• بزرگ‌ترین مشتری‌ها تا ۶ ترابایت در روز رو روی یه نمونه‌ی ClickHouse با مقیاس عمودی نگه می‌دارن.