انتقال به کلیک هاوس: 3 سال بعد

سه سال پیش ویکتور تارنافسکی و الکسی میلوویدوف از یاندکس روی صحنه HighLoad++ گفت:، کدام ClickHouse خوب است و چگونه سرعت آن کاهش نمی یابد. و در مرحله بعدی بود الكساندر زایتسف с گزارش در مورد حرکت به کلیک هاوس از یک DBMS تحلیلی دیگر و با این نتیجه که کلیک هاوسالبته خوبه ولی خیلی راحت نیست هنگامی که در سال 2016 شرکت خیابان زندگی، جایی که الکساندر در آن زمان کار می کرد، سیستم تحلیلی چند پتابایتی را به آن ترجمه کرد کلیک هاوس، این یک "جاده آجری زرد" جذاب و پر از خطرات ناشناخته بود - کلیک هاوس بعد شبیه میدان مین شد.

سه سال بعد کلیک هاوس بسیار بهتر شد - در این مدت ، اسکندر شرکت Altinity را تأسیس کرد ، که نه تنها به انتقال به آن کمک می کند کلیک هاوس ده ها پروژه، بلکه خود محصول را همراه با همکاران Yandex بهبود می بخشد. اکنون کلیک هاوس هنوز یک پیاده روی بی دغدغه نیست، اما دیگر یک میدان مین نیست.

الکساندر از سال 2003 در سیستم های توزیع شده مشارکت داشته و پروژه های بزرگی را توسعه داده است MySQL، Oracle и عمودی. آخرسر HighLoad++ 2019 الکساندر، یکی از پیشگامان استفاده کلیک هاوس، گفت که اکنون این DBMS چیست. ما با ویژگی های اصلی آشنا خواهیم شد کلیک هاوس: چه تفاوتی با سیستم های دیگر دارد و در چه مواردی استفاده از آن موثرتر است. با استفاده از مثال‌ها، روش‌های جدید و اثبات‌شده پروژه‌ای را برای سیستم‌های ساختمانی بر اساس در نظر می‌گیریم کلیک هاوس.


گذشته نگر: اتفاقی که 3 سال پیش افتاد

سه سال پیش ما شرکت را منتقل کردیم خیابان زندگی بر کلیک هاوس از یک پایگاه داده تحلیلی متفاوت، و انتقال تجزیه و تحلیل شبکه تبلیغاتی به این صورت بود:

  • ژوئن 2016. در متن باز ظاهر کلیک هاوس و پروژه ما را شروع کردیم.
  • آگوست اثبات مفهوم: شبکه تبلیغاتی بزرگ، زیرساخت و 200-300 ترابایت داده.
  • اکتبر. اولین داده های تولید؛
  • دسامبر. بار کامل محصول - 10-50 میلیارد رویداد در روز.
  • ژوئن 2017. مهاجرت موفقیت آمیز کاربران به کلیک هاوس، 2,5 پتابایت داده در یک خوشه 60 سروری.

با پیشرفت مهاجرت، درک آن افزایش یافت کلیک هاوس سیستم خوبی است که کار با آن لذت بخش است، اما این یک پروژه داخلی Yandex است. بنابراین، تفاوت های ظریف وجود دارد: Yandex ابتدا با مشتریان داخلی خود و تنها پس از آن با جامعه و نیازهای کاربران خارجی سروکار خواهد داشت، در حالی که ClickHouse در آن زمان در بسیاری از زمینه های کاربردی به سطح سازمانی نرسید. بنابراین در مارس 2017، Altinity را برای ساخت تاسیس کردیم کلیک هاوس حتی سریعتر و راحت تر نه تنها برای Yandex، بلکه برای سایر کاربران. و حالا ما:

  • ما آموزش می دهیم و به ایجاد راه حل هایی بر اساس آن کمک می کنیم کلیک هاوس به طوری که مشتریان برآمدگی ها را پر نکنند، و به طوری که راه حل در نهایت کار کند.
  • ما پشتیبانی 24/7 را ارائه می دهیم کلیک هاوس- تاسیسات؛
  • ما پروژه های اکوسیستم خود را توسعه می دهیم.
  • ما فعالانه به خود متعهد می شویم کلیک هاوس، پاسخ به درخواست های کاربرانی که می خواهند ویژگی های خاصی را ببینند.

و البته، ما در انتقال به کلیک هاوس с خروجی, عمودی, وحی, سبز آلو, انتقال قرمز و سیستم های دیگر ما در بسیاری از جابه‌جایی‌ها شرکت داشته‌ایم و همه آنها موفق بوده‌اند.

انتقال به کلیک هاوس: 3 سال بعد

چرا حتی به کلیک هاوس

کند نمی شود! این دلیل اصلی است. کلیک هاوس - پایگاه داده بسیار سریع برای سناریوهای مختلف:

انتقال به کلیک هاوس: 3 سال بعد

نقل قول های تصادفی از افرادی که با آنها کار می کنند کلیک هاوس.

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

قابل حمل بودن. هیچ دلبستگی به یک چیز وجود ندارد. به عنوان مثال، با آمازون Redshift حرکت به جایی سخت است آ کلیک هاوس می توانید آن را روی لپ تاپ، سرور خود قرار دهید، آن را در فضای ابری مستقر کنید، به آن بروید کوبرنیتس - هیچ محدودیتی در عملکرد زیرساخت وجود ندارد. این برای همه راحت است و این مزیت بزرگی است که بسیاری از پایگاه های داده مشابه دیگر نمی توانند به آن ببالند.

انعطاف پذیری. کلیک هاوس در یک چیز، به عنوان مثال، Yandex.Metrica متوقف نمی شود، بلکه در حال توسعه و استفاده در پروژه ها و صنایع مختلف و بیشتر است. می توان آن را با افزودن ویژگی های جدید برای حل مشکلات جدید گسترش داد. به عنوان مثال، اعتقاد بر این است که ذخیره کردن گزارش ها در یک پایگاه داده رفتار بدی است، بنابراین برای این کار آنها به این نتیجه رسیدند ارزیابی جستجو. اما به لطف انعطاف پذیری کلیک هاوس، شما همچنین می توانید سیاهههای مربوط را در آن ذخیره کنید و اغلب حتی بهتر از in است ارزیابی جستجو - در کلیک هاوس 10 برابر کمتر آهن نیاز دارد.

رایگان متن باز. شما مجبور نیستید برای هیچ چیزی هزینه کنید. برای قرار دادن سیستم بر روی لپ تاپ یا سرور خود نیازی به مذاکره با مجوز ندارید. هیچ هزینه پنهانی وجود ندارد. در عین حال، هیچ فناوری منبع باز پایگاه داده دیگری نمی تواند در سرعت با آن رقابت کند کلیک هاوس. MySQL، MariaDB، Greenplum - همه آنها بسیار کندتر هستند.

جامعه، رانندگی و سرگرمیاست. به کلیک هاوس انجمن بزرگ: ملاقات ها، چت ها و الکسی میلوویدوف، که همه ما را با انرژی و خوش بینی خود متهم می کند.

انتقال به کلیک هاوس

برای تغییر به کلیک هاوس با چیزی فقط به سه چیز نیاز دارید:

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

مشکل جابجایی

فقط یک «اما» وجود دارد: اگر به آن جا نقل مکان کنید کلیک هاوس با چیز دیگری، معمولاً مشکلی پیش می‌آید. ما به برخی از شیوه ها و چیزهایی که در پایگاه داده مورد علاقه ما کار می کنند عادت کرده ایم. به عنوان مثال، هر کسی که با آن کار می کند SQL-پایگاه های داده، مجموعه ای از توابع زیر را اجباری می داند:

  • معاملات؛
  • محدودیت ها؛
  • ثبات؛
  • شاخص ها؛
  • به روز رسانی/حذف;
  • NULL ها;
  • میلی ثانیه؛
  • تبدیل نوع خودکار؛
  • اتصالات متعدد؛
  • پارتیشن های دلخواه؛
  • ابزارهای مدیریت خوشه

استخدام اجباری است، اما سه سال پیش در کلیک هاوس هیچ کدام از این ویژگی ها وجود نداشت! اکنون کمتر از نیمی از موارد محقق نشده باقی مانده است: تراکنش ها، محدودیت ها، ثبات، میلی ثانیه و ریخته گری نوع.

و نکته اصلی این است که در کلیک هاوس برخی از شیوه ها و رویکردهای استاندارد کار نمی کنند یا به روشی که ما به آن عادت کرده ایم کار نمی کنند. هر چیزی که در آن ظاهر می شود کلیک هاوس، مربوط به "راه خانه کلیک کنید"، یعنی توابع با سایر DB ها متفاوت است. مثلا:

  • ایندکس ها انتخاب نمی شوند، اما از آنها صرفنظر می شود.
  • به روز رسانی/حذف نه همزمان، بلکه ناهمزمان.
  • چندین اتصال وجود دارد، اما برنامه‌ریزی برای درخواست وجود ندارد. نحوه اجرای آنها به طور کلی برای افراد از دنیای پایگاه داده چندان روشن نیست.

سناریوهای کلیک هاوس

در سال 1960، یک ریاضیدان آمریکایی مجارستانی الاصل WignerEP مقاله ای نوشتاثربخشی نامعقول ریاضیات در علوم طبیعی"("تاثیر غیر قابل درک ریاضیات در علوم طبیعی") که جهان اطراف ما به دلایلی به خوبی توسط قوانین ریاضی توصیف شده است. ریاضیات یک علم انتزاعی است و قوانین فیزیکی که به شکل ریاضی بیان می شوند، بی اهمیت نیستند و WignerEP تاکید کرد که این بسیار عجیب است.

از دیدگاه من، کلیک هاوس - همان عجیب و غریب. برای فرمول‌بندی مجدد ویگنر، می‌توانیم این را بگوییم: کارایی شگفت‌انگیز غیرقابل تصور است کلیک هاوس در طیف گسترده ای از برنامه های کاربردی تحلیلی!

انتقال به کلیک هاوس: 3 سال بعد

مثلاً بگیریم انبار داده بلادرنگ، که داده ها تقریباً به طور مداوم در آن بارگذاری می شوند. می خواهیم با تاخیر دوم درخواست هایی از او دریافت کنیم. خواهش می کنم استفاده کنید کلیک هاوسزیرا برای این سناریو طراحی شده است. کلیک هاوس این روشی است که نه تنها در وب، بلکه در بازاریابی و تجزیه و تحلیل مالی نیز استفاده می شود، AdTech، و همچنین در کشف تقلبn که در انبار داده بلادرنگ یک طرح ساختار پیچیده مانند "ستاره" یا "دانه برف" استفاده می شود، بسیاری از جداول با بپیوندید (گاهی اوقات چندگانه)، و داده ها معمولاً در برخی سیستم ها ذخیره و تغییر می کنند.

بیایید یک سناریوی دیگر را در نظر بگیریم - سری زمانی: دستگاه های نظارتی، شبکه ها، آمار استفاده، اینترنت اشیا. در اینجا ما با رویدادهای نسبتاً ساده ای روبرو می شویم که به موقع ترتیب داده شده اند. کلیک هاوس در ابتدا برای این کار توسعه داده نشده بود، اما خود را به خوبی نشان داده است، بنابراین شرکت های بزرگ استفاده می کنند کلیک هاوس به عنوان یک مخزن برای نظارت بر اطلاعات. تا ببینیم مناسب است یا نه کلیک هاوس برای سری های زمانی، ما یک معیار را بر اساس رویکرد و نتایج ایجاد کردیم InfluxDB и TimescaleDB - تخصصی سری زمانی پایگاه های داده معلوم شدکه کلیک هاوس، حتی بدون بهینه سازی برای چنین کارهایی نیز در یک میدان خارجی برنده می شود:

انتقال به کلیک هاوس: 3 سال بعد

В سری زمانی معمولاً از یک جدول باریک استفاده می شود - چندین ستون کوچک. بسیاری از داده‌ها می‌توانند از پایش به دست بیایند - میلیون‌ها رکورد در ثانیه - و معمولاً در درج‌های کوچک (زمان واقعی جریان). بنابراین، ما به یک اسکریپت درج متفاوت نیاز داریم، و خود جستارها - با برخی مشخصات خاص خودشان.

ورود مدیریت. جمع آوری گزارش ها در پایگاه داده معمولا بد است، اما در کلیک هاوس این را می توان با برخی از نظرات همانطور که در بالا توضیح داده شد انجام داد. بسیاری از شرکت ها استفاده می کنند کلیک هاوس فقط برای این در این مورد، از یک میز پهن مسطح استفاده می شود که در آن کل سیاهههای مربوط را ذخیره می کنیم (به عنوان مثال، در فرم JSON) یا به قطعات برش دهید. داده ها معمولاً در دسته های بزرگ (فایل ها) بارگذاری می شوند و ما به دنبال برخی زمینه ها هستیم.

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

سری زمانی

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

انتقال به کلیک هاوس: 3 سال بعد

بیشتر این اتفاقات ناشی از نظارت است. این می تواند نه تنها نظارت بر وب، بلکه دستگاه های واقعی نیز باشد: اتومبیل ها، سیستم های صنعتی، IOT، صنایع یا تاکسی های بدون سرنشین که Yandex قبلاً در صندوق عقب آنها قرار داده است کلیک هاوس-سرور

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

در حال حاضر رشد پایگاه های داده تخصصی وجود دارد که اندازه گیری می کنند سری زمانی. برخط موتورهای DB پایگاه داده های مختلفی رتبه بندی می شوند و می توان آنها را بر اساس نوع مشاهده کرد:

انتقال به کلیک هاوس: 3 سال بعد

سریعترین نوع رشد سری زمانیس پایگاه داده های گراف نیز در حال رشد هستند، اما سری زمانیدر چند سال گذشته سریعتر رشد کرده اند. نمایندگان معمولی این خانواده از پایگاه داده ها هستند InfluxDB, تیتان فرزند پاپتوس, KDB, TimescaleDB (ساخته شده بر پایه ی PostgreSQL و)، راه حل هایی از آمازون. کلیک هاوس در اینجا نیز می توان استفاده کرد و از آن استفاده می شود. اجازه دهید چند مثال عمومی برای شما بیاورم.

یکی از پیشگامان این شرکت است CloudFlare را (CDNارائه دهنده). آنها نظارت می کنند CDN از طریق کلیک هاوس (DNS-درخواست ها، HTTPدرخواست ها) با بار عظیم - 6 میلیون رویداد در ثانیه. همه چیز میگذره کافکا، مربوط می شه به کلیک هاوس، که امکان دیدن داشبوردهای بلادرنگ رویدادها را در سیستم فراهم می کند.

Comcast در - یکی از رهبران مخابرات در ایالات متحده: اینترنت، تلویزیون دیجیتال، تلفن. آنها یک سیستم کنترل مشابه ایجاد کردند CDN در چارچوب متن باز پروژه کنترل ترافیک آپاچی تا با داده های عظیم خود کار کنند. کلیک هاوس به عنوان پشتیبان برای تجزیه و تحلیل استفاده می شود.

پرکونا ساخته شده است کلیک هاوس داخل شما PMMبرای حفظ نظارت متفاوت خروجی.

الزامات خاص

پایگاه های داده سری زمانی نیازمندی های خاص خود را دارند.

  • درج سریع از بسیاری از عوامل. ما باید داده های بسیاری از جریان ها را خیلی سریع وارد کنیم. کلیک هاوس این کار را به خوبی انجام می دهد، زیرا همه درج های غیر مسدود کننده را دارد. هر درج یک فایل جدید بر روی دیسک است و درج های کوچک را می توان به هر طریقی بافر کرد. که در کلیک هاوس بهتر است داده ها را در دسته های بزرگ وارد کنید، نه یک خط در یک زمان.
  • مدار انعطاف پذیراست. به سری زمانی ما معمولا ساختار داده ها را به طور کامل نمی دانیم. امکان ساخت یک سیستم مانیتورینگ برای یک برنامه خاص وجود دارد، اما پس از آن استفاده از آن برای برنامه دیگری دشوار است. این نیاز به یک طرح انعطاف پذیرتر دارد. کلیک هاوس، به شما امکان می دهد این کار را انجام دهید، حتی اگر یک پایه قوی تایپ شده باشد.
  • ذخیره سازی کارآمد و فراموشی داده ها. معمولا در سری زمانی حجم عظیمی از داده ها، بنابراین آنها باید تا حد امکان بهینه ذخیره شوند. به عنوان مثال، در InfluxDB فشرده سازی خوب ویژگی اصلی آن است. اما علاوه بر ذخیره سازی، شما همچنین باید بتوانید داده های قدیمی را "فراموش کنید" و برخی از آنها را انجام دهید نمونه برداری - شمارش خودکار مصالح.
  • پرس و جوهای سریع در مورد داده های انبوه. گاهی اوقات جالب است که به 5 دقیقه آخر با دقت میلی ثانیه نگاه کنید، اما در داده های ماهانه، ممکن است به جزئیات دقیقه یا ثانیه نیاز نباشد - آمار کلی کافی است. پشتیبانی از این نوع ضروری است، در غیر این صورت یک درخواست 3 ماهه حتی برای تکمیل آن زمان بسیار طولانی خواهد داشت کلیک هاوس.
  • درخواست هایی مانند "آخرین نقطه، از». اینها برای سری زمانی درخواست ها: به آخرین اندازه گیری یا وضعیت سیستم در یک نقطه از زمان نگاه کنید t. برای پایگاه داده، این پرس و جوها چندان خوشایند نیستند، اما باید بتوانند اجرا شوند.
  • سری زمانی "چسباندن".. سری زمانی یک سری زمانی است اگر دو سری زمانی وجود داشته باشد، آنها اغلب نیاز به اتصال و همبستگی دارند. انجام این کار در همه پایگاه‌های داده، به‌ویژه با سری‌های زمانی بدون تراز راحت نیست: در اینجا چند علامت زمانی وجود دارد، برخی دیگر وجود دارد. شما می توانید میانگین را در نظر بگیرید، اما ناگهان هنوز یک سوراخ وجود دارد، بنابراین مشخص نیست.

بیایید ببینیم که چگونه این الزامات برآورده می شوند کلیک هاوس.

طرح

В کلیک هاوس طرح برای سری زمانی بسته به میزان منظم بودن داده ها، می توان به روش های مختلفی انجام داد. ساختن یک سیستم بر روی داده های معمولی زمانی امکان پذیر است که همه معیارها را از قبل بدانیم. به عنوان مثال، انجام داد CloudFlare را با نظارت CDN یک سیستم بهینه شده است. شما می توانید یک سیستم کلی تر بسازید که کل زیرساخت، خدمات مختلف را نظارت کند. در مورد داده های نامنظم، ما از قبل نمی دانیم که چه چیزی را نظارت می کنیم - و این احتمالاً رایج ترین مورد است.

داده های معمولی ستون ها. این طرح ساده است - ستون هایی با انواع لازم:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

این یک جدول معمولی است که نوعی فعالیت بوت سیستم را نظارت می کند (کاربر, سیستم, بیکار, خوب). ساده و راحت، اما انعطاف پذیر نیست. اگر طرحی انعطاف‌پذیرتر می‌خواهیم، ​​می‌توانیم از آرایه‌ها استفاده کنیم.

داده های نامنظم آرایه ها:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

ساختار تو در تو دو آرایه هستند: metrics.name и معیارها. ارزش. در اینجا می توانید داده های نظارتی دلخواه را به عنوان آرایه ای از نام ها و مجموعه ای از اندازه گیری ها برای هر رویداد ذخیره کنید. برای بهینه سازی بیشتر، می توان چندین ساختار از این قبیل را به جای یک ساخت. مثلا یکی برای شناور-ارزش، دیگری - برای INT- معنی، زیرا INT من می خواهم کارآمدتر ذخیره کنم.

اما دسترسی به چنین ساختاری دشوارتر است. شما باید از یک ساختار خاص استفاده کنید، با استفاده از توابع ویژه ابتدا مقادیر شاخص و سپس آرایه را بیرون بکشید:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

اما هنوز هم به اندازه کافی سریع کار می کند. راه دیگر برای ذخیره سازی داده های نامنظم توسط ردیف ها است.

داده های نامنظم رشته های. در این روش سنتی، بدون آرایه ها، نام ها و مقادیر به یکباره ذخیره می شوند. اگر 5 اندازه گیری به طور همزمان از یک دستگاه انجام شود، 000 ردیف در پایگاه داده ایجاد می شود:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

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

بیایید سه رویکرد را با هم مقایسه کنیم:

انتقال به کلیک هاوس: 3 سال بعد

جزئیات

در اینجا من "اندازه داده روی دیسک" را برای برخی از مجموعه داده های آزمایشی اضافه کرده ام. در مورد ستون ها، ما کوچکترین اندازه داده را داریم: حداکثر فشرده سازی، حداکثر سرعت پرس و جو، اما ما هزینه را با نیاز به تعمیر همه چیز به یکباره می پردازیم.

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

در یکی از شرکت هایی که از این رویکرد استفاده می کند (به عنوان مثال، حال بارگذاریآرایه ها به قطعات 128 عنصری بریده می شوند. داده های چندین هزار متریک با حجم 200 ترابایت داده در روز در یک آرایه ذخیره نمی شود، بلکه در 10 یا 30 آرایه با منطق ذخیره سازی خاص ذخیره می شود.

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

طرح ترکیبی

بیایید فرض کنیم که یک طرح آرایه را انتخاب کرده ایم. اما اگر بدانیم که بیشتر داشبوردهای ما فقط معیارهای کاربر و سیستم را نشان می‌دهند، می‌توانیم این معیارها را به ستون‌هایی از یک آرایه در سطح جدول به این روش تبدیل کنیم:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

کدک ها و فشرده سازی

برای سری زمانی این مهم است که چقدر داده ها را بسته بندی می کنید، زیرا آرایه اطلاعات می تواند بسیار بزرگ باشد. که در کلیک هاوس مجموعه ای از ابزارها برای دستیابی به اثر فشرده سازی 1:10، 1:20 و گاهی اوقات بیشتر وجود دارد. این بدان معناست که 1 ترابایت داده فشرده نشده روی دیسک 50 تا 100 گیگابایت را اشغال می کند. اندازه کوچکتر خوب است، داده ها را می توان سریعتر خواند و پردازش کرد.

برای دستیابی به سطح بالایی از فشرده سازی، کلیک هاوس از کدک های زیر پشتیبانی می کند:

انتقال به کلیک هاوس: 3 سال بعد

مثال جدول:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

در اینجا کدک را تعریف می کنیم DoubleDelta در یک مورد، در مورد دوم گوریل، و حتما موارد بیشتری را اضافه کنید LZ4 فشرده سازی در نتیجه، اندازه داده ها روی دیسک تا حد زیادی کاهش می یابد:

انتقال به کلیک هاوس: 3 سال بعد

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

  • در یک فایل GZIP روی دیسک؛
  • در ClickHouse بدون کدک، اما با فشرده سازی ZSTD.
  • در ClickHouse با کدک های LZ4 و ZSTD و فشرده سازی.

می توان دید که جداول دارای کدک فضای بسیار کمتری را اشغال می کنند.

اندازه مهم است

کم اهمیت نیست را انتخاب کنید نوع داده صحیح:

انتقال به کلیک هاوس: 3 سال بعد

در تمام مثال های بالا که استفاده کردم شناور 64. اما اگر ما انتخاب کردیم شناور 32پس از آن حتی بهتر است. این را بچه های پرکونا در مقاله در لینک بالا به خوبی نشان دادند. مهم است که از فشرده ترین نوع استفاده کنید که مناسب کار است: حتی برای اندازه روی دیسک کمتر از سرعت جستجو. کلیک هاوس بسیار به آن حساس است

اگر می توانید استفاده کنید intxnumx به جای intxnumx، سپس انتظار افزایش تقریباً دو برابری در عملکرد را داشته باشید. داده ها حافظه کمتری را اشغال می کنند و تمام "حساب ها" بسیار سریعتر کار می کنند. کلیک هاوس در داخل آن یک سیستم بسیار دقیق تایپ شده است، از تمام امکاناتی که سیستم های مدرن ارائه می دهند حداکثر استفاده را می کند.

تجمیع و نمایش های تحقق یافته

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

انتقال به کلیک هاوس: 3 سال بعد

برای مثال، ممکن است داده‌های منبع غیرتجمعی داشته باشید، و می‌توانید از طریق یک موتور ویژه، نماهای مختلف مادی شده را با جمع‌بندی خودکار روی آن‌ها آویزان کنید. SummingMergeTree (SMT). SMT یک ساختار داده جمع‌آوری ویژه است که به طور خودکار انبوه‌ها را شمارش می‌کند. داده های خام در پایگاه داده وارد می شوند، به طور خودکار جمع می شوند و داشبوردها می توانند بلافاصله استفاده شوند.

TTL - داده های قدیمی را "فراموش کنید".

چگونه داده هایی را که دیگر مورد نیاز نیستند، "فراموش کنیم"؟ کلیک هاوس می داند چگونه آن را انجام دهد. هنگام ایجاد جداول، می توانید مشخص کنید TTL عبارات: به عنوان مثال، اینکه ما داده های دقیقه را برای یک روز، داده های روزانه را برای 30 روز ذخیره می کنیم و هرگز داده های هفتگی یا ماهانه را لمس نمی کنیم:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

چند لایه - پارتیشن بندی داده ها در دیسک ها

با توسعه این ایده، داده ها را می توان در آن ذخیره کرد کلیک هاوس در مکان های مختلف فرض کنید می خواهیم داده های داغ هفته گذشته را در محلی بسیار سریع ذخیره کنیم SSD، و داده های تاریخی بیشتری را به مکان دیگری اضافه می کنیم. که در کلیک هاوس اکنون ممکن است:

انتقال به کلیک هاوس: 3 سال بعد

شما می توانید سیاست حفظ را پیکربندی کنید (سیاست ذخیره سازی) بنابراین کلیک هاوس در صورت برآورده شدن شرایط خاص، داده ها را به طور خودکار به حافظه دیگری منتقل می کند.

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

ویژگی های منحصر به فرد کلیک هاوس

تقریباً همه چیز در کلیک هاوس چنین "برجسته" وجود دارد، اما آنها توسط انحصاری - چیزی که در پایگاه داده های دیگر وجود ندارد، تراز می شوند. به عنوان مثال، در اینجا برخی از ویژگی های منحصر به فرد آورده شده است کلیک هاوس:

  • آرایه هااست. به کلیک هاوس پشتیبانی بسیار خوب از آرایه ها و همچنین توانایی انجام محاسبات پیچیده بر روی آنها.
  • تجمیع ساختارهای داده. این یکی از "ویژگی های قاتل" است کلیک هاوس. با وجود این واقعیت که بچه های Yandex می گویند که ما نمی خواهیم داده ها را جمع آوری کنیم، همه چیز در کلیک هاوسزیرا سریع و راحت است.
  • نماهای مادی شده. همراه با تجمیع ساختارهای داده، نماهای مادی به شما این امکان را می دهد که راحت تر بسازید زمان واقعی تجمع.
  • ClickHouse SQL. این یک پسوند زبان است SQL با برخی از ویژگی های اضافی و انحصاری که فقط در دسترس هستند کلیک هاوس. پیش از این، از یک سو، به عنوان یک توسعه، و از سوی دیگر یک نقطه ضعف بود. در حال حاضر تقریبا تمام کاستی ها در مقایسه با SQL 92 ما آن را حذف کردیم، اکنون فقط یک پسوند است.
  • یازدهمین حرف الفبای یونانی-اصطلاحات. آیا آنها هنوز در برخی پایگاه داده هستند؟
  • ML-حمایت کردن. این در پایگاه داده های مختلف است، برخی بهتر هستند، برخی بدتر.
  • متن باز. ما می توانیم گسترش دهیم کلیک هاوس با یکدیگر. اکنون در کلیک هاوس حدود 500 مشارکت کننده، و این تعداد به طور مداوم در حال افزایش است.

پرس و جوهای پیچیده

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

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

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

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

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В کلیک هاوس چندین ده تابع مجموع وجود دارد، و اگر از ترکیب کننده ها استفاده کنید، طبق قوانین ترکیبیات، حدود هزار عدد از آنها را دریافت می کنید. ArgMax - یکی از توابعی که حداکثر مقدار را می شمارد: پرس و جو مقدار را برمی گرداند usage_user، که در آن به حداکثر مقدار رسیده است ایجاد شده در:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF بپیوندید - "چسباندن" ردیف ها با زمان های مختلف. این یک ویژگی منحصر به فرد برای پایگاه های داده است که فقط در دسترس است kdb+. اگر دو سری زمانی با زمان های مختلف وجود داشته باشد، ASOF بپیوندید به آنها اجازه می دهد تا در یک درخواست جابجا و چسبانده شوند. برای هر مقدار در یک سری زمانی، نزدیکترین مقدار در سری دیگر پیدا می شود و آنها در همان خط برگردانده می شوند:

انتقال به کلیک هاوس: 3 سال بعد

توابع تحلیلی

در استاندارد SQL-2003 می توانید اینگونه بنویسید:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В کلیک هاوس این امکان پذیر نیست - از استاندارد پشتیبانی نمی کند SQL-2003 و احتمالا هرگز نخواهد شد. در عوض، در کلیک هاوس مرسوم است که اینگونه بنویسیم:

انتقال به کلیک هاوس: 3 سال بعد

به لامبداها قول دادم - اینجا هستند!

این یک آنالوگ از پرس و جوی تحلیلی در استاندارد است SQL-2003: تفاوت بین دو را حساب می کند مهر زمانی، مدت، ترتیبی - همه چیزهایی که معمولاً توابع تحلیلی در نظر می گیریم. که در کلیک هاوس ما آنها را از طریق آرایه ها شمارش می کنیم: ابتدا داده ها را در یک آرایه جمع می کنیم، بعد از آن هر کاری که می خواهیم روی آرایه انجام می دهیم و سپس آن را باز می کنیم. این خیلی راحت نیست، حداقل به عشق برنامه نویسی کاربردی نیاز دارد، اما بسیار انعطاف پذیر است.

ویژگی های خاص

علاوه بر این، در کلیک هاوس بسیاری از ویژگی های تخصصی به عنوان مثال، چگونه می توان تعیین کرد که چند جلسه همزمان در حال اجرا هستند؟ یک کار معمولی برای نظارت، تعیین حداکثر بار در یک درخواست واحد است. که در کلیک هاوس یک عملکرد ویژه برای این منظور وجود دارد:

انتقال به کلیک هاوس: 3 سال بعد

به طور کلی، ClickHouse دارای توابع ویژه برای بسیاری از اهداف است:

  • runDifference، runAcumulate، همسایه;
  • sumMap (کلید، مقدار)؛
  • timeSeriesGroupSum (uid، timestamp، value)؛
  • timeSeriesGroupRateSum (uid، timestamp، value)؛
  • skewPop، skewSamp، kurtPop، kurtSamp;
  • با پر / با کراوات.
  • رگرسیون ساده خطی، رگرسیون خطی تصادفی.

این لیست کاملی از ویژگی ها نیست، فقط 500-600 مورد از آنها وجود دارد. نکته: همه عملکردها در کلیک هاوس در جدول سیستم قرار دارد (همه مستند نیستند، اما همه جالب هستند):

select * from system.functions order by name

کلیک هاوس اطلاعات زیادی را در مورد خود ذخیره می کند، از جمله جداول ورود به سیستم, query_log، گزارش ردیابی، گزارش عملیات با بلوک های داده (part_log، گزارش معیارها و گزارش سیستم که معمولاً روی دیسک می نویسد. گزارش متریک است سری زمانی в کلیک هاوس در حقیقت کلیک هاوس: پایگاه داده خود می تواند نقش داشته باشد سری زمانی پایگاه های داده، بنابراین خود را "بلعیده" می کند.

انتقال به کلیک هاوس: 3 سال بعد

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

خوشه بزرگ یا خیلی کوچک کلیک هاوس

چه چیزی بهتر است - یک خوشه بزرگ یا چند کلیک خانه کوچک؟ رویکرد سنتی به DWH یک خوشه بزرگ است که در آن طرح ها برای هر برنامه اختصاص داده شده است. ما به مدیر پایگاه داده رسیدیم - یک طرح به ما بدهید و به ما داده شد:

انتقال به کلیک هاوس: 3 سال بعد

В کلیک هاوس شما می توانید آن را متفاوت انجام دهید شما می توانید هر برنامه را برای خود بسازید کلیک هاوس:

انتقال به کلیک هاوس: 3 سال بعد

ما دیگر به یک هیولای بزرگ نیاز نداریم DWH و ادمین های غیر همکار می‌توانیم به هر برنامه‌ای مختص به خود بدهیم کلیک هاوس، و توسعه دهنده می تواند خودش این کار را انجام دهد، زیرا کلیک هاوس نصب بسیار آسان است و نیازی به مدیریت پیچیده ندارد:

انتقال به کلیک هاوس: 3 سال بعد

اما اگر زیاد داشته باشیم کلیک هاوس، و باید اغلب آن را تنظیم کنید، سپس می خواهید این فرآیند را خودکار کنید. برای این ما می توانیم، به عنوان مثال، استفاده کنید کوبرنیتس и خانه کلیک-اپراتور. که در Kubernetes ClickHouse شما می توانید "روی کلیک" را قرار دهید: من می توانم روی یک دکمه کلیک کنم، مانیفست را اجرا کنم و پایگاه داده آماده است. می توانید فوراً یک طرح ایجاد کنید، شروع به بارگیری معیارها در آنجا کنید و بعد از 5 دقیقه من یک داشبورد آماده دارم گرافانا. خیلی ساده است!

نتیجه؟

بنابراین، کلیک هاوس - این:

  • سریع. این را همه می دانند.
  • به سادگی. کمی بحث برانگیز است، اما به نظر من یادگیری آن سخت است، جنگیدن آسان است. اگه فهمیدی چطوری کلیک هاوس کار می کند، همه چیز بسیار ساده است.
  • به صورت جهانی. برای سناریوهای مختلف مناسب است: DWH، سری زمانی، ذخیره‌سازی گزارش. اما اینطور نیست OLTP پایگاه داده، بنابراین سعی نکنید درج و خواندن کوتاه در آنجا انجام دهید.
  • جالب توجه است. احتمالا اونی که باهاش ​​کار میکنه کلیک هاوس، دقایق جالب زیادی را به معنای خوب و بد تجربه کرد. به عنوان مثال، نسخه جدیدی منتشر شد، همه چیز از کار افتاد. یا زمانی که دو روز با یک کار دست و پنجه نرم می کردید، اما بعد از یک سوال در چت تلگرام، کار در عرض دو دقیقه حل شد. یا همانطور که در کنفرانس در گزارش لشا میلوویدوف، اسکرین شات از کلیک هاوس پخش را شکست HighLoad++. این نوع چیزها همیشه اتفاق می افتد و زندگی ما را با آن می سازد کلیک هاوس روشن و جالب!

ارائه قابل مشاهده است اینجا.

انتقال به کلیک هاوس: 3 سال بعد

نشست مورد انتظار توسعه دهندگان سیستم های پر بار در HighLoad++ در تاریخ 9 و 10 نوامبر در Skolkovo برگزار می شود. در نهایت، این یک کنفرانس آفلاین خواهد بود (البته با تمام اقدامات احتیاطی)، زیرا انرژی HighLoad++ را نمی توان به صورت آنلاین بسته بندی کرد.

برای کنفرانس، مواردی را در مورد حداکثر امکانات فناوری پیدا کرده و به شما نشان می‌دهیم: HighLoad ++ تنها مکانی بود، و خواهد بود که در طی دو روز می‌توانید نحوه کار فیس‌بوک، یاندکس، VKontakte، گوگل و آمازون را یاد بگیرید.

با برگزاری جلسات بدون وقفه از سال 2007، امسال برای چهاردهمین بار ملاقات خواهیم کرد. در طول این مدت، کنفرانس 14 برابر شده است، سال گذشته رویداد کلیدی صنعت 10 شرکت کننده، 3339 سخنران گزارش و ملاقات جمع آوری کرد و 165 آهنگ به طور همزمان در حال پخش بودند.
سال گذشته 20 اتوبوس برای شما، 5280 لیتر چای و قهوه، 1650 لیتر نوشیدنی میوه و 10200 بطری آب وجود داشت. و 2640 کیلوگرم غذا، 16 بشقاب و 000 فنجان. ضمناً با پولی که از کاغذ بازیافتی به دست آمد، 25 نهال بلوط کاشتیم 🙂

بلیط ها قابل خرید است اینجا، دریافت اخبار مربوط به کنفرانس - اینجاو در تمام شبکه های اجتماعی صحبت کنید: تلگرام, فیس بوک, VKontakte می и توییتر.

منبع: www.habr.com

اضافه کردن نظر