ClickHouse برای کدام سناریوها کاربرد دارد؟

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

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

ما عملکرد TPC-H 100G ClickHouse را با عملکرد Oracle در همان محیط سخت افزاری مقایسه می کنیم. در زیر فقط نتایج آزمون را فهرست می کند (واحد زمان: ثانیه). گزارش کامل آزمون را در اینجا بیابید.

تست عملکرد پایگاه داده TPC-H نسبتا ابتدایی است و – به طور کلی، پیچیده نیست. اما همه تست‌ها پیمایش تک جدولی ساده نیستند، JOIN و سوالات فرعی نیز وجود دارد. در این موارد، عملکرد ClickHouse بسیار ضعیف است. چند کار محاسباتی وجود دارد که اصلاً نمی توان آنها را به پایان رساند. دستورات SQL از چند کار حتی برای اجرا بسیار پیچیده در نظر گرفته می شوند. ClickHouse حتی به خوبی اوراکل در مدیریت آنها نیست. اوراکل یک پایگاه داده تحلیلی تخصصی نیست و بسیار کندتر است، اما می تواند تمام وظایف را انجام دهد.

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

بنابراین، کاربرانی که می خواهند از ClickHouse برای حل مشکلات عملکرد استفاده کنند، ابتدا باید پیچیدگی وظایف محاسباتی خود را با مقایسه آنها با TPC-H بررسی کنند.

اکنون ما همچنان از داده‌های TPC-H برای تولید جدولی با ستون‌های زیاد و انجام تحلیل چند بعدی که ClickHouse در آن بهترین است استفاده می‌کنیم. نتایج در زیر فهرست شده است (واحد زمان: ثانیه). گزارش کامل آزمون را در اینجا بیابید.

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

به نظر می رسد که ClickHouse تنها زمانی سریع است که پیمایش های ساده تک جدولی را که شامل هیچ ارتباطی نمی شود، انجام دهد. اما ClickHouse “سرعت سریعی” که می تواند به آن دست یابد، سناریوهای برنامه بسیار محدود را اعمال می کند. آیا معرفی یک پایگاه داده به طور خاص برای انجام چنین کار ساده ای ارزش دارد؟

برخلاف ClickHouse که شهرت اغراق آمیزی دارد، esProc SPL ذکر شده در گزارش تست بالا قهرمان واقعی عملکرد است.

esProc SPL نیز منبع باز است. این برنامه در جاوا توسعه یافته است، اما در بسیاری از سناریوهای بهینه سازی عملکرد می تواند عملکرد بسیار بهتری از ClickHouse توسعه یافته C++ داشته باشد.

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

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

بیایید عملکرد esProc را در گزارش تست بالا با عملکردهای ClickHouse مقایسه کنیم:

esProc SPL به طور قابل توجهی از ClickHouse پیشی می گیرد زیرا همه وظایف را بسیار سریع اجرا می کند. دارای مزایای جامع و قابل توجهی نسبت به ClickHouse است.

هنگامی که حجم داده ها افزایش می یابد، ClickHouse در واقع بهتر و سریعتر از esProc SPL در مدیریت پیمایش یک جدول گسترده است که در آن خوب است. با این حال، از آنجایی که جداول گسترده در اکثر موارد برای جلوگیری از عملیات اتصال با سرعت پایین (با افزایش حجم داده و انجام آماده سازی داده های پیچیده تر) استفاده می شود، زمانی که استراتژی منحصر به فرد بهینه سازی اتصال esProc SPL سرعت بالاتری نسبت به جداول گسترده ClickHouse را امکان پذیر می کند، غیرضروری می شوند. میزهای عریض دیگر هیچ امتیازی ندارند و با از دست دادن مزایای عملکردی بی فایده می شوند.

اگرچه ClickHouse در مدیریت خلاصه سازی ساده و غیر مرتبط روی جداول منفرد سریعتر است، اما مرتبه ای سریعتر از esProc نیست (در نهایت CPU و هارد دیسک فقط این سرعت را دارند). در این مورد، حتی اگر بتوان از ویژگی‌های وظیفه برای انجام بهینه‌سازی استفاده کرد، باز هم انجام آن بر اساس ClickHouse دشوار خواهد بود. بسیاری از منطق های بهینه سازی در SQL قابل دستیابی نیستند و برنامه نویسی C++ در سطح بالاتر برای تکمیل هدف مورد نیاز است. این پیچیده و دشوار است. با این حال، SPL توانایی برنامه نویسی بسیار قوی تری دارد و می تواند از ویژگی های وظیفه برای نوشتن کد بهینه سازی به خوبی استفاده کند.

برای مثال، تحلیل‌های چند بعدی معاصر تقریباً همیشه شامل خلاصه‌سازی چند شاخصه می‌شوند. می‌توانیم الگوریتم پیمایش چند منظوره را در SPL بنویسیم تا مقادیر مجموع چندگانه را در طول یک پیمایش محاسبه کنیم. حتی اگر SPL در انجام محاسبات تک شاخص کمی کندتر از ClickHouse باشد، می تواند به طور قابل توجهی از آن در هنگام کار با خلاصه چند شاخص پیشی بگیرد:

(گزارش کامل آزمون را از اینجا بیابید)

برای محاسبات پیچیده تر، مانند تجزیه و تحلیل قیف، آنها برای آزمایش با استفاده از ClickHouse بسیار پیچیده هستند. اما esProc SPL می تواند آنها را آزمایش کند. اطلاعات مرتبط را در اینجا بیابید.

به طور خلاصه، esProc SPL دارای مزایای عملکرد کامل و جامع است، اما مزایای عملکرد ClickHouse فقط در محدوده بسیار محدودی از برنامه‌ها اعمال می‌شود.

در اینجا یک مورد استفاده در دنیای واقعی وجود دارد. یک مشکل برخورد فضا-زمان شامل حدود 25 میلیارد ردیف داده است. به نظر می رسد که دستور SQL پیچیده نیست:

WITH DT AS ( SELECT DISTINCT id, ROUND(tm/900)+1 as tn, loc FROM T WHERE tm<3*86400)
SELECT * FROM (
    SELECT B.id id, COUNT( DISINCT B.tn ) cnt
    FROM DT AS A JOIN DT AS B ON A.loc=B.loc AND A.tn=B.tn
    WHERE A.id=a AND B.id<>a
    GROUP BY id )
ORDER BY cnt DESC
LIMIT 20

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

(برخلاف کد تولید شده توسط سایر زبان های برنامه نویسی، کد SPL در یک شبکه نوشته می شود. اطلاعات مرتبط را از اینجا بیابید).

محاسبات SQL DISTINCT شامل مقادیر HASH و مقایسه آنها می شود. زمانی که حجم داده ها زیاد باشد محاسبات فشرده می شود. خود پیوستن و COUNT (DISTINCT) بیشتر نیز به طور جدی عملکرد را کاهش می دهد. SPL می‌تواند بیشترین استفاده را از گروه‌بندی مرتب شده و مکان مبتنی بر عدد ترتیبی ببرد که SQL مجبور نیست به طور مؤثری از پیچیدگی بالا و عملیات DISTINCT اجتناب کند. اگرچه SPL از نظر کارایی ذخیره سازی مزیتی نسبت به ClickHouse ندارد و جاوا کمی کندتر از C++ است، اما همچنان کارایی را با مرتبه های بزرگی افزایش می دهد.