در ماه آوریل، مهندسان Avito برای گردهمایی های آنلاین با الکسی میلوویدوف، توسعه دهنده اصلی ClickHouse، و Kirill Shvakov، توسعه دهنده Golang از Integros گرد هم آمدند. در مورد اینکه چگونه از سیستم مدیریت پایگاه داده استفاده می کنیم و با چه مشکلاتی روبرو هستیم بحث کردیم.
بر اساس جلسه، ما مقاله ای را با پاسخ کارشناسان به سوالات ما و مخاطبان در مورد پشتیبان گیری، اشتراک گذاری مجدد داده ها، دیکشنری های خارجی، درایور Golang و به روز رسانی نسخه ClickHouse گردآوری کرده ایم. این می تواند برای توسعه دهندگانی مفید باشد که قبلاً به طور فعال با Yandex DBMS کار می کنند و به حال و آینده آن علاقه مند هستند. پاسخ های الکسی میلوویدوف به طور پیش فرض، مگر اینکه خلاف آن ذکر شده باشد.
مراقب باشید، متن زیادی در زیر برش وجود دارد. امیدواریم مطالب حاوی سوالات به شما در مسیریابی کمک کند.
مقدار
اگر نمی خواهید متن را بخوانید، می توانید ضبط مجالس را تماشا کنید . مهر زمانی در اولین نظر زیر ویدیو آمده است.
ClickHouse دائماً به روز می شود، اما داده های ما اینطور نیست. با آن چه کار باید کرد؟
ClickHouse به طور مداوم به روز می شود و داده های ما که توسط optimize final پردازش شده اند به روز نمی شوند و در نسخه پشتیبان هستند.
فرض کنید ما نوعی مشکل داشتیم و داده ها از بین رفتند. ما تصمیم به بازیابی گرفتیم و معلوم شد که پارتیشن‌های قدیمی که در سرورهای پشتیبان ذخیره می‌شوند با نسخه‌ای از ClickHouse که در حال حاضر استفاده می‌شود بسیار متفاوت هستند. در چنین شرایطی چه باید کرد و آیا ممکن است؟
وضعیتی که در آن داده ها را از یک نسخه پشتیبان در قالب قدیمی بازیابی کرده اید، اما در نسخه جدید آنها متصل نیستند، غیرممکن است. ما مطمئن می شویم که فرمت داده ها در ClickHouse همیشه با هم سازگار باشد. در صورتی که رفتار برخی از عملکردهایی که به ندرت استفاده می شوند تغییر کرده باشد، این بسیار مهمتر از سازگاری به عقب در عملکرد است. داده هایی که روی دیسک ذخیره می شوند، نسخه جدید ClickHouse باید همیشه قادر به خواندن باشد. این قانون است.
بهترین روش های فعلی برای پشتیبان گیری از داده ها از ClickHouse چیست؟
با در نظر گرفتن اینکه عملیات نهایی بهینه سازی، بانک اطلاعاتی عظیم ترابایتی و داده هایی که مثلاً سه روز گذشته به روز می شوند و بعد هیچ رویه ای برایشان نمی افتد، چگونه پشتیبان گیری کنیم؟
ما می توانیم راه حل خود را جمع آوری کنیم و روی سر بنویسیم: این نسخه های پشتیبان را به گونه ای جمع کنید. شاید شما نیازی به عصا کردن ندارید و دوچرخه خیلی وقت پیش اختراع شده است؟
بیایید با بهترین شیوه ها شروع کنیم. همکاران من همیشه در پاسخ به سؤالات مربوط به پشتیبان گیری توصیه می کنند که سرویس Yandex.Cloud را به آنها یادآوری کنند ، جایی که این کار قبلاً حل شده است. پس در صورت امکان از آن استفاده کنید.
هیچ راه حل کاملی وجود ندارد که صد در صد در ClickHouse تعبیه شده است برای پشتیبان گیری. چند جای خالی وجود دارد که می توانید از آنها استفاده کنید. برای به دست آوردن یک راه حل کامل، یا باید کمی دستی سرهم کنید یا لفاف هایی را به شکل اسکریپت بسازید.
من با ساده ترین راه حل ها شروع می کنم و با پیچیده ترین راه حل ها، بسته به مقدار داده ها و اندازه خوشه، پایان می دهم. هر چه خوشه بزرگتر باشد، راه حل دشوارتر می شود.
اگر جدول داده ها فقط چند گیگابایت را اشغال کند، پشتیبان گیری را می توان به صورت زیر انجام داد:
- تعریف جداول، یعنی ابرداده - را ذخیره کنید نمایش ایجاد جدول.
- با استفاده از کلاینت ClickHouse - یک Dump درست کنید را انتخاب کنید * از جدول برای تشکیل پرونده به طور پیش فرض، فایلی با فرمت TabSeparated دریافت خواهید کرد. اگر می خواهید کارآمدتر باشید، می توانید از فرمت Native استفاده کنید.
اگر حجم داده ها بیشتر باشد، پشتیبان گیری زمان و فضای زیادی را می گیرد. این یک پشتیبان گیری منطقی نامیده می شود، به فرمت داده های ClickHouse وابسته نیست. اگر چنین است، پس از آن می توانید یک نسخه پشتیبان تهیه کنید و آن را برای بازیابی در MySQL آپلود کنید.
برای موارد پیشرفته تر، ClickHouse دارای قابلیت داخلی برای ایجاد یک عکس فوری از پارتیشن ها در سیستم فایل محلی است. این ویژگی به صورت درخواستی در دسترس است. تغییر جدول فریز پارتیشن. یا به سادگی تغییر انجماد جدول یک عکس فوری از کل جدول است.
اسنپ شات برای یک جدول روی یک خرده سازگار ایجاد می شود، یعنی ایجاد یک عکس فوری ثابت از کل خوشه به این روش غیرممکن است. اما برای اکثر وظایف، چنین نیازی وجود ندارد و کافی است روی هر قطعه یک درخواست اجرا کنید و یک عکس فوری ثابت دریافت کنید. به شکل هاردلینک ایجاد می شود و بنابراین فضای اضافی را اشغال نمی کند. سپس این عکس فوری را در سرور پشتیبان یا در فضای ذخیره‌سازی که برای پشتیبان‌گیری استفاده می‌کنید کپی می‌کنید.
بازیابی چنین پشتیبان گیری بسیار آسان است. ابتدا جداول را طبق تعاریف جدول موجود ایجاد می کنید. در مرحله بعد، snapshot های پارتیشن ذخیره شده را برای این جداول در Directory-Detached کپی کنید و پرس و جو را اجرا کنید. پارتیشن را وصل کنید. این راه حل برای جدی ترین حجم داده ها کاملاً مناسب است.
گاهی اوقات شما به چیزی حتی خنک تر نیاز دارید - در مواردی که ده ها یا حتی صدها ترابایت در هر سرور و صدها سرور دارید. در اینجا راه حلی وجود دارد که من از همکاران Yandex.Metrica از آن جاسوسی کردم. من آن را به همه توصیه نمی کنم - آن را بخوانید و خودتان تصمیم بگیرید که آیا مناسب است یا خیر.
ابتدا باید چندین سرور با قفسه های دیسک بزرگ ایجاد کنید. در مرحله بعد، چندین سرور ClickHouse را روی این سرورها بالا ببرید و آنها را طوری پیکربندی کنید که به عنوان یک کپی دیگر برای همان خرده ها کار کنند. و سپس از سیستم فایل روی این سرورها یا ابزاری استفاده کنید که به شما امکان ایجاد عکس های فوری را می دهد. در اینجا دو گزینه وجود دارد. گزینه اول LVM snapshots، گزینه دوم ZFS در لینوکس است.
پس از آن، هر روز که نیاز به ایجاد یک عکس فوری دارید، دروغ می‌گوید و فضایی را اشغال می‌کند. به طور طبیعی، اگر داده ها تغییر کنند، با گذشت زمان مقدار فضا افزایش می یابد. شما می توانید این عکس فوری را در هر زمان دریافت کنید و داده ها را بازیابی کنید، چنین تصمیم عجیبی است. به علاوه، شما هنوز باید این کپی‌ها را در پیکربندی محدود کنید تا سعی نکنند رهبر شوند.
آیا امکان سازماندهی یک انبار کنترل شده از ماکت ها در شفت وجود خواهد داشت؟
امسال شما در حال برنامه ریزی برای ساخت شفت در ClickHouse هستید. آیا امکان سازماندهی مجموعه ای کنترل شده از ماکت ها در آنها وجود خواهد داشت؟ ما می خواهیم از آن برای محافظت از خود در برابر سناریوهای منفی با تغییرات و تغییرات دیگر استفاده کنیم.
آیا می توان یک نوع roll back برای تغییرات انجام داد؟ مثلاً در یک شفت موجود، بگیرید و بگویید تا این لحظه تغییرات را اعمال کنید و از این لحظه به بعد اعمال تغییرات را متوقف کنید؟
اگر دستوری به خوشه ما آمد و آن را خراب کرد، پس ما یک replica شرطی با یک ساعت تاخیر داریم که می توانیم بگوییم فعلا از آن استفاده کنیم، اما تغییرات را در ده دقیقه آخر اعمال نمی کنیم؟
برای شروع، در مورد عقب ماندگی کنترل شده ماکت ها. چنین درخواستی از سوی کاربران وجود داشت و ما با این درخواست در Github مشکلی ایجاد کردیم: "اگر کسی به این نیاز دارد، یک لایک بگذار، یک قلب بگذار." هیچ کس شرط بندی نکرد و موضوع بسته شد. با این حال، از قبل می توانید با راه اندازی ClickHouse از این فرصت برخوردار شوید. درست است، فقط از نسخه 20.3 شروع می شود.
ClickHouse دائماً داده ها را در پس زمینه ادغام می کند - ادغام. هنگامی که یک ادغام انجام می شود، مجموعه ای از تکه های داده با یک تکه بزرگتر جایگزین می شود. در همان زمان، بخش‌هایی از داده‌ها که قبلاً بودند، برای مدتی روی دیسک باقی می‌مانند.
اول، تا زمانی که جستارهای منتخبی وجود داشته باشند که از آنها استفاده می کنند، ذخیره می شوند تا از عملکرد غیرمسدود اطمینان حاصل شود. درخواست های منتخب بی سر و صدا از تکه های قدیمی خوانده می شوند.
ثانیا، یک آستانه زمانی نیز وجود دارد - قطعات قدیمی داده به مدت هشت دقیقه روی دیسک قرار می گیرند. این هشت دقیقه را می توان سفارشی کرد و حتی به یک روز تبدیل کرد. این هزینه فضای دیسک را به همراه خواهد داشت: بسته به جریان داده، معلوم می شود که در روز گذشته داده ها نه تنها دو برابر می شوند، بلکه می توانند پنج برابر شوند. اما در صورت بروز مشکل جدی می توانید سرور ClickHouse را متوقف کرده و با همه چیز مقابله کنید.
حال سوال این است که چگونه این کار در برابر تغییرات محافظت می کند. ارزش این را دارد که در اینجا عمیق‌تر نگاه کنید، زیرا در نسخه‌های قدیمی‌تر ClickHouse، alter به گونه‌ای عمل می‌کرد که به سادگی مستقیماً قطعات را تغییر می‌داد. یک قطعه داده با برخی فایل ها وجود دارد، و ما برای مثال انجام می دهیم تغییر ستون دراپ. سپس این ستون به صورت فیزیکی از تمام تکه ها حذف می شود.
اما از نسخه 20.3، مکانیسم تغییر به طور کامل تغییر کرده است و اکنون تکه های داده همیشه تغییرناپذیر هستند. آنها به هیچ وجه تغییر نمی کنند - تغییرات در حال حاضر به همان شیوه ادغام کار می کنند. به جای تغییر یک قطعه در جای خود، یک قطعه جدید ایجاد می کنیم. در قسمت جدید، فایل هایی که تغییر نکرده اند تبدیل به هاردلینک می شوند و اگر ستونی را حذف کنیم، به سادگی در قطعه جدید گم می شود. قطعه قدیمی پس از هشت دقیقه به طور پیش فرض حذف می شود و در اینجا می توانید تنظیمات ذکر شده در بالا را تغییر دهید.
همین امر در مورد تغییراتی مانند جهش نیز صدق می کند. وقتی انجام می دهید تغییر حذف یا تغییر به روز رسانی، قطعه را تغییر نمی دهد، بلکه قطعه جدیدی ایجاد می کند. و سپس قبلی را حذف می کند.
اگر ساختار جدول تغییر کرده باشد چه؟
چگونه می توان یک نسخه پشتیبان تهیه کرد که با طرح قدیمی ساخته شده است؟ و سوال دوم در مورد پرونده عکس های فوری و ابزارهای سیستم فایل است. آیا Btrfs به جای ZFS در لینوکس LVM در اینجا مناسب است؟
اگر انجام دهید پارتیشن را وصل کنید پارتیشن هایی با ساختار متفاوت، سپس ClickHouse به شما می گوید که این امکان پذیر نیست. راه حل این است. اولین مورد این است که یک جدول موقت از نوع MergeTree با ساختار قدیمی ایجاد کنید، داده ها را با استفاده از attach در آنجا ضمیمه کنید و یک پرس و جو تغییر دهید. سپس می‌توانید این داده‌ها را کپی یا انتقال دهید و دوباره پیوست کنید، یا از پرس و جو استفاده کنید تغییر پارتیشن حرکت جدول.
حال سوال دوم این است که آیا می توان از Btrfs استفاده کرد؟ برای شروع، اگر LVM دارید، عکس های فوری LVM کافی است، و سیستم فایل می تواند ext4 باشد، مهم نیست. با Btrts، همه چیز به تجربه شما در مورد آن بستگی دارد. این یک فایل سیستم بالغ است، اما هنوز شک و تردیدهایی وجود دارد که چگونه همه چیز در یک سناریوی خاص در عمل انجام می شود. من استفاده از این را توصیه نمی کنم مگر اینکه Btrfs در حال تولید داشته باشید.
بهترین شیوه های فعلی برای اشتراک گذاری مجدد داده ها چیست؟
مسئله تغییر رنگ پیچیده و چندوجهی است. در اینجا می توانید به چندین گزینه به طور همزمان پاسخ دهید. می توانید از یک طرف وارد شوید و این را بگویید - در ClickHouse گزینه ای برای تغییر رنگ داخلی وجود ندارد. اما می ترسم این پاسخ برای کسی مناسب نباشد. بنابراین، می‌توانید از طرف دیگر بروید و بگویید که ClickHouse راه‌های زیادی برای ریشارکردن داده‌ها دارد.
اگر فضای خوشه تمام شود یا نتواند بار را تحمل کند، سرورهای جدیدی اضافه می‌کنید. اما این سرورها به طور پیش فرض خالی هستند، هیچ داده ای روی آنها وجود ندارد، هیچ بارگیری وجود ندارد. باید داده ها را جابجا کنید تا به طور مساوی روی خوشه جدید و بزرگتر پخش شوند.
اولین راه برای انجام این کار این است که بخشی از پارتیشن ها را با استفاده از پرس و جو در سرورهای جدید کپی کنید پارتیشن واکشی جدول را تغییر دهید. به عنوان مثال، شما پارتیشن‌ها را بر اساس ماه داشتید و ماه اول 2017 را می‌گیرید و آن را در یک سرور جدید کپی می‌کنید، سپس ماه سوم را در سرور جدید دیگری کپی می‌کنید. و این کار را تا زمانی انجام می دهید که کم و بیش یکنواخت شود.
مهاجرت را می توان فقط برای آن دسته از پارتیشن هایی انجام داد که در طول ضبط تغییر نمی کنند. برای پارتیشن های تازه، نوشتن باید غیرفعال شود، زیرا انتقال آنها اتمی نیست. در غیر این صورت، در نهایت با داده های تکراری یا شکاف مواجه خواهید شد. با این حال، این روش عملی است و کاملا موثر عمل می کند. پارتیشن های فشرده آماده از طریق شبکه منتقل می شوند، یعنی داده ها فشرده یا رمزگذاری مجدد نمی شوند.
این روش یک ایراد دارد و بستگی به طرح شاردینگ دارد، اینکه آیا شما به این طرح تقسیم بندی تعهد داده اید، چه کلید اشتراکی دارید. در مثال شما برای مورد با متریک، کلید اشتراک گذاری یک هش از مسیر است. هنگامی که یک جدول توزیع شده را انتخاب می کنید، یکباره به تمام قطعات خوشه می رود و داده ها را از آنجا می گیرد.
این بدان معنی است که در واقع برای شما مهم نیست که کدام داده به کدام خرده ختم می شود. نکته اصلی این است که داده ها در یک مسیر به یک قطعه ختم می شوند، اما کدام یک مهم نیست. در این مورد، انتقال پارتیشن‌های آماده عالی است، زیرا با کوئری‌های انتخابی، داده‌های کامل را نیز دریافت خواهید کرد - هم قبل از ریشارد کردن و هم بعد از آن، این طرح واقعاً مهم نیست.
اما مواردی وجود دارد که پیچیده تر هستند. اگر در سطح منطق برنامه به یک طرح تقسیم بندی خاص تکیه کنید، که این کلاینت روی فلان خرده قرار دارد و درخواست را می توان بلافاصله به آنجا ارسال کرد و نه به جدول توزیع شده. یا از نسخه نسبتاً جدید ClickHouse استفاده می کنید و تنظیمات را فعال کرده اید بهینه سازی پرش از خرده های استفاده نشده. در این حالت، در حین انتخاب کوئری، عبارت در قسمت Where تجزیه می شود و محاسبه می شود که با توجه به طرح تقسیم به کدام خرده ها بروید. این به شرطی کار می کند که داده ها دقیقاً مطابق با این طرح تقسیم بندی تجزیه شوند. اگر آنها را به صورت دستی جابجا کرده باشید، ممکن است مطابقت تغییر کند.
پس این راه شماره یک است. و منتظر پاسخ شما هستم که آیا روش مناسب است یا ادامه دهید.
ولادیمیر کولوبایف، مدیر ارشد سیستم در Avito: الکسی، روشی که شما نام بردید در مواقعی که باید بار را پخش کنید، از جمله خواندن، خیلی مناسب نیست. ما می توانیم پارتیشنی را بگیریم که ماهانه است و می توانیم ماه قبل را به گره دیگری ببریم، اما وقتی درخواستی برای این داده وارد می شود، فقط آن را بارگذاری می کنیم. اما من می خواهم کل خوشه را بارگذاری کنم، زیرا، در غیر این صورت، برای مدتی، کل بار خواندن توسط دو قطعه پردازش می شود.
الکسی میلوویدوف: پاسخ در اینجا عجیب است - بله، بد است، اما می تواند کار کند. دقیقا توضیح میدم چطوری ارزش دارد به سناریوی بارگیری که با داده های شما ارائه می شود نگاه کنید. اگر این نظارت بر داده ها باشد، تقریباً مطمئن است که اکثریت قریب به اتفاق درخواست ها برای داده های تازه هستند.
شما سرورهای جدید نصب کرده اید، پارتیشن های قدیمی را انتقال داده اید، اما نحوه نوشتن داده های تازه را نیز تغییر داده اید. و داده های تازه در سراسر خوشه پخش خواهد شد. بنابراین، پس از پنج دقیقه، درخواست‌های پنج دقیقه آخر به طور یکنواخت خوشه را بارگیری می‌کنند، پس از یک روز، درخواست‌های یک روز به طور یکنواخت خوشه را بارگیری می‌کنند. و درخواست های ماه قبل متأسفانه فقط به بخشی از سرورهای کلاستر می رود.
اما اغلب برای فوریه 2019 درخواستی نخواهید داشت. به احتمال زیاد، اگر درخواست ها به سال 2019 بروند، آنها برای کل سال 2019 خواهند بود - برای یک بازه زمانی بزرگ، و نه برای محدوده کوچک. و چنین درخواست هایی همچنین می توانند به طور یکنواخت خوشه را بارگیری کنند. اما به طور کلی، اظهار نظر شما کاملاً صحیح است که این یک راه حل موقت است که داده ها را به طور کامل پخش نمی کند.
برای پاسخ به سوال چند نکته دیگر دارم. یکی از آنها در مورد این است که چگونه می توان در ابتدا طرح شاردینگ را به گونه ای ساخت که درد کمتری از ریشارد کردن وجود داشته باشد. این همیشه ممکن نیست.
به عنوان مثال، شما داده های نظارتی دارید. داده های پایش به سه دلیل در حال رشد است. اولین مورد انباشت داده های تاریخی است. دوم رشد ترافیک است. و سوم افزایش تعداد مواردی است که تحت نظارت هستند. میکروسرویس ها و معیارهای جدیدی وجود دارند که باید ذخیره شوند.
این امکان وجود دارد که از این میان، بیشترین افزایش به دلیل سومین دلیل باشد - این افزایش استفاده از نظارت است. و در این مورد، ارزش نگاه کردن به ماهیت بار را دارد که درخواست های اصلی برای انتخاب چیست. پرسوجوهای انتخابی اصلی احتمالاً زیر مجموعه‌ای از معیارها را دنبال می‌کنند.
به عنوان مثال، استفاده از CPU در برخی از سرورها توسط برخی از سرویس ها. به نظر می رسد که زیر مجموعه ای از کلیدها وجود دارد که توسط آنها این داده ها را دریافت می کنید. و خود درخواست برای این داده به احتمال زیاد بسیار ساده است و در ده ها میلی ثانیه اجرا می شود. برای خدمات نظارت، برای داشبورد استفاده می شود. امیدوارم این را درست متوجه شده باشم.
ولادیمیر کولوبایف: واقعیت این است که ما اغلب به داده های تاریخی متوسل می شویم، زیرا موقعیت فعلی را با موقعیت تاریخی در زمان واقعی مقایسه می کنیم. و دسترسی سریع به حجم زیادی از داده ها برای ما مهم است و ClickHouse با این کار بسیار عالی عمل می کند.
کاملاً درست می گویید، اکثر درخواست های خواندنی که ما در روز گذشته تجربه می کنیم، مانند هر سیستم نظارتی. اما در عین حال، بار روی داده های تاریخی نیز بسیار زیاد است. این بیشتر از یک سیستم هشدار است که هر XNUMX ثانیه یکبار دور می‌زند و به ClickHouse می‌گوید: «داده‌های شش هفته گذشته را به من بدهید. و حالا یک میانگین متحرک از آنها برای من بسازید، و بیایید ارزش فعلی را با ارزش تاریخی مقایسه کنیم.
می‌خواهم بگویم که برای چنین درخواست‌های بسیار تازه‌ای، ما یک جدول کوچک دیگر داریم که فقط دو روز داده را در آن ذخیره می‌کنیم و درخواست‌های اصلی در آن پرواز می‌کنند. ما فقط پرس و جوهای تاریخی بزرگ را به یک جدول بزرگ خرد شده ارسال می کنیم.
الکسی میلوویدوف: متأسفانه، به نظر می رسد که برای سناریوی شما کاربرد ضعیفی دارد، اما من دو طرح تقسیم بندی بد و پیچیده را شرح می دهم که نیازی به استفاده ندارند، اما در سرویس دوستان من استفاده می شوند.
یک خوشه اصلی با رویدادهای Yandex.Metrics وجود دارد. رویدادها بازدید از صفحه، کلیک‌ها و انتقال‌ها هستند. بیشتر درخواست ها به یک وب سایت خاص می رود. شما سرویس Yandex.Metrica را باز می کنید، یک وب سایت دارید - avito.ru، به گزارش بروید و درخواستی برای وب سایت شما ارسال می شود.
اما درخواست های دیگری وجود دارد - تحلیلی و جهانی که توسط تحلیلگران داخلی ارائه می شود. در هر صورت، متذکر می شوم که تحلیلگران داخلی فقط برای خدمات Yandex درخواست می کنند. اما با این وجود، حتی خدمات Yandex سهم قابل توجهی از تمام داده ها را اشغال می کند. این درخواست‌ها نه برای شمارنده‌های خاص، بلکه برای فیلتر کردن گسترده‌تر است.
چگونه داده ها را به گونه ای سازماندهی کنیم که همه چیز برای یک شمارنده و همچنین پرس و جوهای جهانی به طور موثر کار کند؟ مشکل دیگر در این واقعیت نهفته است که تعداد درخواست ها در ClickHouse برای خوشه Metrics چندین هزار در ثانیه است. در عین حال، یک سرور ClickHouse به درخواست های غیر ضروری، به عنوان مثال، چندین هزار در ثانیه رسیدگی نمی کند.
اندازه خوشه ششصد و چند سرور است. اگر به سادگی یک جدول توزیع شده را روی این خوشه بکشید و چندین هزار درخواست را به آنجا ارسال کنید، حتی بدتر از ارسال آنها به یک سرور خواهد شد. از طرفی این گزینه که داده ها به صورت یکنواخت پخش می شوند و ما می رویم و از همه سرورها درخواست می کنیم بلافاصله حذف می شود.
یک گزینه کاملاً مخالف وجود دارد. تصور کنید که داده ها را بر اساس سایت خرد می کنیم و درخواست یک سایت به یک خرده می رود. اکنون خوشه قادر خواهد بود ده هزار درخواست را در ثانیه بیرون بکشد، اما در یک قطعه یک درخواست خیلی کند عمل می کند. دیگر از نظر پهنای باند مقیاس نخواهد شد. به خصوص اگر یک سایت avito.ru باشد. اگر بگویم Avito یکی از پربازدیدترین سایت های Runet است، رازی را فاش نمی کنم. و پردازش آن روی یک تکه دیوانه کننده خواهد بود.
بنابراین، طرح اشتراک گذاری به روشی پیچیده تر ترتیب داده شده است. کل خوشه به تعدادی خوشه تقسیم می شود که آنها را لایه می نامیم. در داخل هر خوشه از ده تا چند ده خرده وجود دارد. در مجموع سی و نه خوشه از این دست وجود دارد.
این همه مقیاس چگونه است؟ تعداد خوشه‌ها تغییر نمی‌کند - همانطور که سی و نه سال پیش بود، ثابت می‌ماند. اما در هر یک از آنها، با جمع شدن داده ها به تدریج تعداد خرده ها را افزایش می دهیم. و طرح اشتراک گذاری به طور کلی این است - تقسیم به این خوشه ها توسط وب سایت ها انجام می شود، و برای اینکه بفهمیم کدام سایت در کدام خوشه قرار دارد، به طور کلی از یک متابیس جداگانه در MySQL استفاده می شود. یک سایت - در یک خوشه. و در داخل آن شاردینگ با توجه به شناسه بازدیدکنندگان صورت می گیرد.
هنگام ضبط، آنها را بر باقی مانده شناسه بازدیدکننده تقسیم می کنیم. اما هنگامی که یک قطعه جدید اضافه می شود، طرح تقسیم بندی تغییر می کند، ما به تقسیم کردن ادامه می دهیم، اما با باقی مانده تقسیم بر عدد دیگری. این بدان معنی است که یک بازدید کننده در حال حاضر در چندین سرور قرار دارد و شما نمی توانید روی آن شرط بندی کنید. این کار صرفاً برای اطمینان از فشرده سازی بهتر داده ها انجام می شود. و هنگام پرس و جو به جدول Distributed می رویم که به خوشه نگاه می کند و به ده ها سرور دسترسی دارد. این چنین طرح احمقانه ای است.
اما اگر نگویم که این طرح را رها کرده ایم، داستان من ناقص خواهد بود. در طرح جدید، همه چیز را تغییر دادیم و تمام داده ها را با استفاده از clickhouse-copier کپی کردیم.
در طرح جدید، همه سایت ها به دو دسته بزرگ و کوچک تقسیم می شوند. من نمی دانم آستانه چگونه در آنجا انتخاب شده است ، اما در نتیجه معلوم شد که سایت های بزرگ در یک خوشه ضبط می شوند ، جایی که 120 قطعه با سه کپی در هر کدام وجود دارد - یعنی 360 سرور. و طرح شاردینگ به این صورت است که هر درخواستی به یکباره به همه خرده ها می رود. اگر اکنون هر صفحه گزارشی را برای avito.ru در Yandex.Metrica باز کنید، درخواست به 120 سرور می رود. تعداد کمی از سایت های بزرگ در Runet وجود دارد. و درخواست ها نه هزار در ثانیه بلکه کمتر از صد است. همه اینها بی سر و صدا توسط جدول توزیع شده جویده می شود که هر یک از آنها 120 سرور را پردازش می کند.
و خوشه دوم برای سایت های کوچک است. در اینجا یک طرح اشتراک گذاری بر اساس شناسه سایت وجود دارد و هر درخواست دقیقاً به یک قطعه می رود.
ClickHouse یک ابزار clickhouse-copier دارد. می توانید در مورد او بگویید؟
فوراً باید بگویم که این راه حل دست و پا گیرتر و تا حدودی کمتر کارآمد است. مزیت این است که داده ها را به طور کامل طبق طرحی که شما مشخص کرده اید، آغشته می کند. اما عیب ابزار این است که اصلاً مجدداً ریشارد نمی شود. داده ها را از یک طرحواره خوشه ای به طرحواره خوشه ای دیگر کپی می کند.
این بدان معناست که برای کارکرد آن باید دو کلاستر داشته باشید. آنها می توانند در همان سرورها قرار گیرند، اما، با این وجود، داده ها به صورت تدریجی جابه جا نمی شوند، بلکه کپی می شوند.
مثلا چهار تا سرور بود الان هشت تا شده. شما یک جدول Distributed جدید روی همه سرورها، جداول محلی جدید ایجاد می‌کنید، و clickhouse-copier را راه‌اندازی می‌کنید، و طرح کاری را که باید از آنجا بخواند، در آن مشخص می‌کنید، طرح اشتراک‌گذاری جدید را می‌پذیرید، و داده‌ها را به آنجا منتقل می‌کنید. و شما یک و نیم برابر بیشتر از فضای فعلی سرورهای قدیمی نیاز خواهید داشت، زیرا داده های قدیمی باید روی آنها باقی بماند و نیمی از همان داده های قدیمی روی آنها قرار می گیرد. اگر از قبل فکر می‌کردید که داده‌ها نیاز به اصلاح مجدد دارند و فضا وجود دارد، این روش مناسب است.
دستگاه کپی کلیک در داخل چگونه کار می کند؟ تمام کارها را به مجموعه ای از وظایف برای پردازش یک پارتیشن از یک جدول در یک خرده تقسیم می کند. همه این وظایف می توانند به صورت موازی اجرا شوند، و clickhouse-copier می تواند چندین نمونه را روی ماشین های مختلف اجرا کند، اما کاری که برای یک پارتیشن انجام می دهد چیزی بیش از یک انتخاب درج نیست. داده ها خوانده می شوند، از حالت فشرده خارج می شوند، دوباره پارتیشن بندی می شوند، سپس دوباره فشرده می شوند، در جایی نوشته می شوند، دوباره مرتب می شوند. این تصمیم دشوارتر است.
شما یک چیز آزمایشی به نام resharding داشتید. با او چه؟
در سال 2017، شما یک چیز آزمایشی به نام resharding داشتید. حتی یک گزینه در ClickHouse وجود دارد. میفهمم بلند نشد می توانید بگویید چرا این اتفاق افتاد؟ به نظر می رسد بسیار مرتبط است.
کل مشکل این است که اگر شما نیاز دارید که داده ها را مجدداً در جای خود به اشتراک بگذارید، برای انجام این کار به صورت اتمی به یک هماهنگ سازی بسیار پیچیده نیاز است. وقتی شروع به بررسی نحوه عملکرد این همگام سازی کردیم، مشخص شد که مشکلات اساسی وجود دارد. و این مشکلات اساسی نه تنها تئوری هستند، بلکه بلافاصله شروع به نشان دادن خود در عمل در قالب چیزی کردند که می توان آن را بسیار ساده توضیح داد - هیچ چیز کار نمی کند.
آیا می توان قبل از انتقال به دیسک های کند، همه بخش های داده را با هم ادغام کرد؟
یک سوال در مورد TTL با گزینه انتقال به دیسک کند در زمینه ادغام. آیا راهی به جز cron وجود دارد که بتوان قبل از انتقال به دیسک های کند، همه قسمت ها را در یک قسمت ادغام کرد؟
پاسخ به این سوال که آیا امکان چسباندن خودکار تمام قطعات قبل از انتقال آنها وجود دارد، خیر است. به نظر من این کار ضروری نیست. شما نمی توانید تمام قسمت ها را در یک ادغام کنید، بلکه فقط به این واقعیت تکیه کنید که به طور خودکار به دیسک های کند منتقل می شوند.
برای قوانین نقل و انتقالات دو معیار داریم. اولی این است که پر می شود. اگر سطح ذخیره سازی فعلی کمتر از درصد مشخصی از فضای خالی داشته باشد، یک تکه را انتخاب کرده و به فضای ذخیره سازی کندتر منتقل می کنیم. یا بهتر است بگوییم، نه آهسته تر، بلکه موارد زیر - نحوه تنظیم آن.
معیار دوم اندازه است. او در مورد انتقال قطعات بزرگ صحبت می کند. شما می توانید آستانه را بر اساس فضای آزاد روی یک دیسک سریع تنظیم کنید و داده ها به طور خودکار منتقل می شوند.
اگر هیچ راهی برای بررسی سازگاری از قبل وجود نداشته باشد، چگونه می توان به نسخه های جدید ClickHouse مهاجرت کرد؟
این موضوع به طور مرتب مورد بحث قرار می گیرد با در نظر گرفتن نسخه های مختلف، و در عین حال. ارتقا از نسخه 19.11 به 19.16 و مثلاً از 19.16 به 20.3 چقدر امن است. بهترین راه برای انتقال به نسخه های جدید بدون اینکه بتوانید از قبل سازگاری را در sandbox بررسی کنید چیست؟
در اینجا چند قانون طلایی وجود دارد. اولین - . بزرگ است، اما نکات جداگانه ای در مورد تغییرات ناسازگار با عقب وجود دارد. با این موارد به عنوان یک پرچم قرمز رفتار نکنید. اینها معمولاً ناسازگاری های جزئی هستند که به برخی از عملکردهای لبه مربوط می شوند که احتمالاً از آنها استفاده نمی کنید.
ثانیاً، اگر راهی برای بررسی سازگاری در sandbox وجود ندارد و می‌خواهید فوراً در مرحله تولید ارتقا دهید، توصیه می‌شود که نیازی به انجام این کار نداشته باشید. ابتدا یک sandbox بسازید و تست کنید. اگر محیط آزمایشی وجود نداشته باشد، به احتمال زیاد شرکت بسیار بزرگی ندارید، به این معنی که می توانید برخی از داده ها را در لپ تاپ خود کپی کنید و مطمئن شوید که همه چیز به درستی روی آن کار می کند. حتی می توانید چند کپی را به صورت محلی روی دستگاه خود بیاورید. یا می توانید یک نسخه جدید را در جایی در نزدیکی بالا بیاورید و برخی از داده ها را در آنجا آپلود کنید - یعنی یک محیط آزمایشی بداهه بسازید.
قانون دیگر این است که به دلیل بروز اشکالات در تولید و رفع سریع بعدی، ظرف یک هفته پس از انتشار نسخه به روز رسانی نکنید. بیایید شماره گذاری نسخه ClickHouse را بفهمیم تا گیج نشویم.
نسخه 20.3.4 هست. عدد 20 نشان دهنده سال ساخت - 2020 است. از نظر آنچه در داخل است، این مهم نیست، بنابراین ما به آن توجه نخواهیم کرد. بیشتر - 20.3. عدد دوم - در این مورد 3 - هر بار که نسخه ای را با برخی عملکردهای جدید منتشر می کنیم افزایش می دهیم. اگر بخواهیم قابلیتی به ClickHouse اضافه کنیم، باید این عدد را افزایش دهیم. یعنی در نسخه 20.4 ClickHouse حتی بهتر عمل خواهد کرد. رقم سوم 20.3.4 است. در اینجا 4 تعداد پچ های منتشر شده است که در آنها ویژگی های جدیدی اضافه نکردیم، اما برخی از باگ ها را برطرف کردیم. و 4 یعنی ما آن را چهار بار انجام دادیم.
فکر نکنید چیز وحشتناکی است. معمولا کاربر می تواند آخرین نسخه را نصب کند و سالیانه بدون هیچ مشکلی با آپ تایم کار می کند. اما تصور کنید که در یک تابع برای پردازش بیت مپ که توسط رفقای چینی ما اضافه شده است، هنگام ارسال آرگومان های نادرست، سرور از کار می افتد. ما باید این را درست کنیم. ما یک نسخه پچ جدید منتشر خواهیم کرد و ClickHouse پایدارتر خواهد شد.
اگر ClickHouse دارید که در حال تولید است و نسخه جدیدی از ClickHouse با ویژگی های اضافی منتشر شده است - به عنوان مثال، 20.4.1 اولین نسخه است، برای تولید آن در روز اول عجله نکنید. اصلا چرا به او نیاز است؟ اگر هنوز از ClickHouse استفاده نمی کنید، می توانید آن را نصب کنید و به احتمال زیاد همه چیز خوب خواهد بود. اما اگر ClickHouse در حال حاضر به طور پایدار کار می‌کند، منتظر وصله‌ها و به‌روزرسانی‌ها باشید - چه مشکلاتی را برطرف می‌کنیم.
کریل شواکوف: من می خواهم کمی در مورد محیط های آزمایشی اضافه کنم. همه از محیط های تست بسیار می ترسند و به دلایلی معتقدند که اگر یک خوشه ClickHouse بسیار بزرگ دارید، پس محیط تست نباید کوچکتر یا حداقل ده برابر کوچکتر باشد. اصلا شبیه به آن نیست.
با مثالم می توانم بگویم. من یک پروژه دارم و ClickHouse وجود دارد. محیط آزمایشی ما برای او یک ماشین مجازی کوچک در Hetzner به قیمت بیست یورو است که در آن مطلقاً همه چیز مستقر شده است. برای انجام این کار، ما در Ansible اتوماسیون کامل داریم، و بنابراین، در اصل، هیچ تفاوتی وجود ندارد که کجا رول کنیم - روی سرورهای آهنی یا فقط در ماشین های مجازی مستقر شویم.
چه کاری می توان کرد؟ خوب است که در اسناد ClickHouse مثالی در مورد نحوه استقرار یک خوشه کوچک به تنهایی ایجاد کنید - در Docker، در LXC، شاید یک کتاب بازی Ansible ایجاد کنید، زیرا افراد مختلف استقرارهای متفاوتی دارند. این کار خیلی چیزها را راحت تر می کند. وقتی یک خوشه را در پنج دقیقه می گیرید و مستقر می کنید، تلاش برای کشف چیزی بسیار ساده تر است. به این ترتیب بسیار راحت‌تر است، زیرا عرضه نسخه‌ای که آزمایش نکرده‌اید راهی به جایی نیست. گاهی اوقات کار می کند و گاهی اوقات نه. و بنابراین امید به موفقیت بد است.
ماکسیم کوتیاکوف، مهندس ارشد آویتو: من کمی در مورد محیط های آزمایشی از یک سری مشکلات برای شرکت های بزرگ اضافه می کنم. ما یک خوشه پذیرش کامل ClickHouse، طبق طرح‌های داده و تنظیمات، یک کپی دقیق از آنچه در حال تولید است، داریم. این خوشه در ظروف نسبتاً پوسیده با حداقل منابع مستقر شده است. ما درصد معینی از داده های تولید را در آنجا می نویسیم، زیرا فرصتی برای تکرار جریان در کافکا وجود دارد. همه چیز در آنجا هماهنگ و مقیاس شده است - هم از نظر ظرفیت و هم از نظر جریان، و از نظر تئوری، اگر سایر چیزها برابر باشند، باید از نظر معیارها مانند یک تولید رفتار کند. هر چیزی که بالقوه انفجاری است ابتدا روی این پایه می‌پیچد و برای چند روز در آنجا تزریق می‌شود تا آماده شود. اما البته این راه حل گران، سنگین و با هزینه های پشتیبانی غیر صفر است.
الکسی میلوویدوف: من به شما می گویم که محیط تست دوستان ما از Yandex.Metrica چگونه است. یک خوشه 600 یا بیشتر سرور داشت، دیگری 360 سرور داشت و یک خوشه سوم و چندین خوشه وجود دارد. محیط آزمایشی برای یکی از آنها فقط دو قطعه با دو کپی در هر کدام است. چرا دو خرده؟ برای تنها نبودن. و کپی ها نیز باشند. فقط مقداری حداقلی که می توانید بپردازید.
این محیط آزمایشی به شما امکان می دهد سلامت درخواست ها را بررسی کنید و اینکه آیا چیزی به طور عمده خراب است یا خیر. اما اغلب مشکلات از ماهیت کاملاً متفاوتی به وجود می آیند، زمانی که همه چیز کار می کند، اما تغییرات کوچکی با بار وجود دارد.
من برای شما یک مثال می زنم. تصمیم گرفتیم نسخه جدیدی از ClickHouse را نصب کنیم. این در یک محیط آزمایشی گذاشته شده است، آزمایش های خودکار در خود Yandex.Metrica انجام می شود که داده ها را در نسخه قدیمی و جدید مقایسه می کند و کل خط لوله را اجرا می کند. و البته، تست های سبز CI ما. در غیر این صورت ما حتی این نسخه را پیشنهاد نمی کردیم.
همه چیز خوب است. ما شروع به تولید می کنیم. من پیامی دریافت می کنم که بار روی نمودارها چندین برابر شده است. ما در حال عقب نشینی نسخه هستیم. من به نمودار نگاه می کنم و می بینم: بارگذاری واقعاً چندین بار در طول عرضه افزایش یافته است، و پس از عرضه مجدد کاهش می یابد. سپس شروع به بازگردانی نسخه کردیم. و بار به همین ترتیب زیاد شد و به همان ترتیب عقب افتاد. بنابراین نتیجه این است - بار در ارتباط با محاسبه افزایش یافته است، هیچ چیز تعجب آور نیست.
سپس متقاعد کردن همکاران برای نصب نسخه جدید دشوار بود. من می گویم: "اشکالی ندارد، ول کن. انگشتان خود را روی هم بگذارید، همه چیز درست می شود. اکنون بار روی نمودارها افزایش یافته است، اما همه چیز خوب است. صبر کن." به طور کلی، ما این کار را انجام دادیم و تمام - نسخه در سایت تولید قرار داده شده است. اما تقریباً با هر محاسبه، مشکلات مشابهی پیش می آید.
Kill Query قرار است پرس و جوها را از بین ببرد، اما اینطور نیست. چرا؟
کاربری به سراغ من آمد، نوعی تحلیلگر، و درخواست خاصی را ایجاد کرد که خوشه ClickHouse من را قرار داد. بسته به این که درخواست وارد کدام یک از گره ها یا یک خوشه کامل شود. من می بینم که تمام منابع CPU در این سرور در قفسه است، همه چیز قرمز است. در همان زمان، ClickHouse خود به درخواست ها پاسخ می دهد. و من می نویسم: "لطفاً لیست فرآیند را به من نشان دهید، درخواستی که باعث ایجاد این جنون شده است."
من این درخواست را پیدا می کنم و می نویسم kill to it. و من می بینم که هیچ اتفاقی نمی افتد. سرور من در قفسه است، ClickHouse سپس دستوراتی را به من می دهد، نشان می دهد که سرور زنده است، و همه چیز خوب است. اما من در تمام درخواست‌های کاربر تخریب دارم، تخریب با ورود در ClickHouse شروع می‌شود و کوئری kill من کار نمی‌کند. چرا؟ من فکر کردم kill query قرار بود پرس و جوها را بکشد، اما اینطور نیست.
اکنون پاسخ نسبتاً عجیبی وجود خواهد داشت. نکته اینجاست که kill query کوئری ها را نمی کشد.
Kill query یک چک باکس کوچک به نام "I want this query to be kill" قرار می دهد. و خود درخواست هنگام پردازش هر بلوک به این پرچم نگاه می کند. اگر تنظیم شود، درخواست از کار می افتد. معلوم می شود که هیچ کس درخواست را نمی کشد، او خودش باید همه چیز را بررسی کند و متوقف شود. و این باید در همه مواردی که درخواست در حالت پردازش بلوک است کار کند. بلوک بعدی داده را پردازش می کند، پرچم را بررسی می کند و متوقف می شود.
این در مواردی که درخواست در برخی از عملیات مسدود شده است کار نمی کند. درست است، به احتمال زیاد این مورد شما نیست، زیرا، به گفته شما، از یک سری منابع سرور استفاده می کند. این امکان وجود دارد که در مورد مرتب سازی خارجی و در برخی جزئیات دیگر این کار جواب ندهد. اما به طور کلی، این نباید باشد، این یک اشکال است. و تنها چیزی که می توانم توصیه کنم این است که ClickHouse را به روز کنید.
چگونه زمان پاسخ را تحت بار خواندن محاسبه کنیم؟
جدولی وجود دارد که مجموعه های اقلام را ذخیره می کند - شمارنده های مختلف. تعداد خطوط حدود صد میلیون است. اگر 1K RPS روی آیتم های 1K بریزید، آیا می توان روی زمان پاسخگویی قابل پیش بینی حساب کرد؟
با قضاوت بر اساس زمینه، ما در مورد بار خواندن صحبت می کنیم، زیرا هیچ مشکلی برای نوشتن وجود ندارد - حداقل هزار، حداقل صد هزار و گاهی اوقات چندین میلیون خط می تواند درج شود.
درخواست های خواندن بسیار متفاوت است. در انتخاب 1، ClickHouse می‌تواند حدود ده‌ها هزار درخواست در ثانیه انجام دهد، بنابراین حتی درخواست‌های یک کلید از قبل به منابعی نیاز دارند. و چنین پرسوجوهای نقطه‌ای دشوارتر از برخی پایگاه‌های داده کلید-مقدار خواهند بود، زیرا برای هر خواندن لازم است بلوک داده‌ها بر اساس فهرست خوانده شود. ایندکس ما به هر رکورد نمی‌پردازد، بلکه به هر محدوده می‌پردازد. یعنی شما باید کل محدوده را بخوانید - اینها به طور پیش فرض 8192 خط هستند. و باید بلوک داده های فشرده را از 64 کیلوبایت به 1 مگابایت از حالت فشرده خارج کنید. به طور معمول، چنین پرس و جوهای نقطه ای از چند میلی ثانیه طول می کشد. اما این ساده ترین گزینه است.
بیایید حسابی ساده را امتحان کنیم. اگر چند میلی ثانیه را در هزار ضرب کنید، چند ثانیه به دست می آید. انگار نگه داشتن هزار درخواست در ثانیه غیرممکن است، اما در واقع ممکن است، زیرا ما چندین هسته پردازنده داریم. بنابراین، در اصل، 1000 RPS ClickHouse گاهی اوقات می تواند نگه داشته شود، اما در درخواست های کوتاه، یعنی درخواست های نقطه ای.
اگر نیاز دارید که خوشه ClickHouse را بر اساس تعداد درخواست‌های ساده مقیاس کنید، پس من ساده‌ترین کار را توصیه می‌کنم - افزایش تعداد کپی‌ها و ارسال درخواست‌ها به یک ماکت تصادفی. اگر یک ماکت در هر ثانیه پانصد درخواست داشته باشد که کاملاً واقع بینانه است، در این صورت سه ماکت یک و نیم هزار درخواست را در خود جای خواهند داد.
البته گاهی اوقات می توانید ClickHouse را برای حداکثر تعداد خوانش نقاط پیکربندی کنید. چه چیزی برای این مورد نیاز است؟ اولین مورد کاهش دانه بندی شاخص است. در عین حال نباید آن را به یک کاهش داد، بلکه بر این اساس که تعداد رکوردهای ایندکس چندین میلیون یا ده ها میلیون در هر سرور خواهد بود. اگر جدول دارای صد میلیون ردیف باشد، می توان 64 را به عنوان دانه بندی تنظیم کرد.
می توانید اندازه بلوک فشرده را کاهش دهید. تنظیماتی برای این کار وجود دارد. اندازه بلوک فشرده در دقیقه, حداکثر اندازه بلوک فشرده. می‌توانید آنها را کاهش دهید، داده‌ها را دوباره بارگیری کنید، و سپس جستجوهای نقطه‌ای سریع‌تر خواهند بود. اما با این حال، ClickHouse یک پایگاه داده کلید-مقدار نیست. تعداد زیادی از درخواست های کوچک یک ضد الگوی بار است.
کریل شواکوف: در صورتی که حسابداران معمولی وجود داشته باشند مشاوره خواهم داد. زمانی که نوعی شمارنده در ClickHouse ذخیره می شود، این یک وضعیت نسبتاً استاندارد است. من یک کاربر دارم، او اهل فلان کشور، یک رشته سوم دیگر است، و باید چیزی را به تدریج افزایش دهم. MySQL را بگیرید، یک کلید منحصر به فرد بسازید - در MySQL یک کلید تکراری است و در PostgreSQL یک تضاد است - و یک علامت مثبت اضافه کنید. این خیلی بهتر عمل خواهد کرد.
وقتی داده های کمی دارید، استفاده از ClickHouse فایده ای ندارد. پایگاه‌های اطلاعاتی منظمی وجود دارد، و آنها به خوبی این کار را انجام می‌دهند.
چه چیزی را در ClickHouse تنظیم کنیم تا داده های بیشتری در حافظه نهان وجود داشته باشد؟
بیایید وضعیت را تصور کنیم - سرورها 256 گیگابایت رم دارند، در روتین روزانه ClickHouse حدود 60-80 گیگابایت طول می کشد، در اوج - تا 130. چه چیزی را می توان فعال و بهینه کرد تا داده های بیشتری در حافظه پنهان باشد و بر این اساس. ، سفرهای کمتری به دیسک وجود دارد؟
به عنوان یک قاعده، کش صفحه سیستم عامل این کار را به خوبی انجام می دهد. اگر فقط قسمت بالایی را باز کنید، به صورت کش یا آزاد نگاه کنید - همچنین می‌گوید چقدر ذخیره شده است - سپس می‌بینید که تمام حافظه آزاد برای کش استفاده می‌شود. و هنگام خواندن این داده ها از روی دیسک خوانده نمی شود، بلکه از RAM خوانده می شود. در عین حال، می توانم بگویم که کش به طور موثر استفاده می شود، زیرا این داده های فشرده است که کش می شود.
با این حال، اگر می‌خواهید سرعت برخی از پرسوجوهای ساده را حتی بیشتر کنید، می‌توانید یک کش را در داده‌های فشرده‌شده در داخل ClickHouse فعال کنید. نامیده می شود کش غیر فشرده. در فایل پیکربندی config.xml، اندازه کش فشرده نشده را به مقداری که نیاز دارید تنظیم کنید - من بیش از نیمی از RAM رایگان را توصیه نمی کنم، زیرا مابقی زیر کش صفحه می رود.
علاوه بر این، دو تنظیمات سطح درخواست وجود دارد. تنظیم اول - از کش غیر فشرده استفاده کنید - شامل استفاده از آن است. توصیه می شود آن را برای همه درخواست ها فعال کنید، به جز موارد سنگین، که می توانند تمام داده ها را بخوانند و این کش را پاکسازی کنند. و تنظیم دوم چیزی شبیه حداکثر تعداد خطوط برای استفاده از کش است. به طور خودکار درخواست های بزرگ را محدود می کند تا از حافظه پنهان گذشته باشد.
چگونه می توانم storage_configuration را برای ذخیره سازی در RAM پیکربندی کنم؟
در مستندات جدید ClickHouse، بخش مربوط به آن را خواندم . در توضیحات مثالی با یک SSD سریع وجود دارد.
من تعجب می کنم که چگونه می توانید همان را با حافظه داغ حجمی پیکربندی کنید. و یک سوال دیگر Select چگونه با این سازمان داده کار می کند، آیا کل مجموعه را می خواند یا فقط آن چیزی که روی دیسک است، و آیا این داده ها در حافظه فشرده می شوند؟ و چگونه بخش prewhere روی چنین سازمان داده ای کار می کند؟
این تنظیم روی ذخیره سازی داده ها تأثیر می گذارد و فرمت آنها به هیچ وجه تغییر نمی کند.
بیایید نگاه دقیق تری بیندازیم.
می توانید ذخیره سازی داده ها را در RAM تنظیم کنید. هر چیزی که برای یک دیسک پیکربندی شده است مسیر آن است. شما یک پارتیشن tmpfs ایجاد می کنید که در مسیری در سیستم فایل نصب شده است. این مسیر را به عنوان مسیر ذخیره سازی داده ها برای داغترین پارتیشن مشخص کنید، قطعات داده شروع به رسیدن می کنند و در آنجا نوشته می شوند، همه چیز خوب است.
اما من انجام این کار را به دلیل قابلیت اطمینان کم توصیه نمی کنم، اگرچه اگر حداقل سه نسخه مشابه در مراکز داده مختلف دارید، می توانید. در این صورت، داده ها بازیابی خواهند شد. تصور کنید که سرور به طور ناگهانی خاموش شده و دوباره روشن می شود. بخش دوباره نصب شد، اما یک جای خالی وجود دارد. در هنگام راه‌اندازی، سرور ClickHouse می‌بیند که این قطعات گم شده‌اند، اگرچه، طبق ابرداده ZooKeeper، باید وجود داشته باشند. او نگاه می کند که آنها روی کدام ماکت هستند، آنها را درخواست می کند و آنها را دانلود می کند. بنابراین، داده ها بازیابی خواهند شد.
از این نظر، ذخیره داده ها در RAM تفاوتی اساسی با ذخیره آن روی دیسک ندارد، زیرا زمانی که داده ها روی دیسک نوشته می شوند، ابتدا در حافظه پنهان صفحه قرار می گیرند و بعداً به صورت فیزیکی نوشته می شوند. بستگی به نحوه نصب فایل سیستم دارد. اما در هر صورت، من می گویم که ClickHouse در درج همگام سازی نمی شود.
در این حالت، داده های RAM دقیقاً با همان فرمت روی دیسک ذخیره می شوند. پرس و جو انتخاب تکه هایی را که قرار است خوانده شوند به همین ترتیب انتخاب می کند، محدوده داده های مورد نیاز را در تکه ها انتخاب می کند و آنها را می خواند. و prewhere دقیقاً یکسان عمل می کند، صرف نظر از اینکه داده ها در RAM یا روی دیسک بودند.
کاردینالیتی کم تا چه تعداد از مقادیر منحصر به فرد موثر است؟
کاردینالیته کم مشکل است. دیکشنری های داده را جمع آوری می کند، اما آنها محلی هستند. اولاً دیکشنری ها برای هر قطعه متفاوت هستند و ثانیاً حتی در یک قطعه نیز می توانند برای هر محدوده متفاوت باشند. وقتی تعداد مقادیر منحصر به فرد به یک آستانه می رسد - یک میلیون، فکر می کنم - فرهنگ لغت به سادگی کنار گذاشته می شود و یک فرهنگ لغت جدید ایجاد می شود.
پاسخ به طور کلی این است: برای هر محدوده محلی - مثلاً برای هر روز - جایی تا یک میلیون مقدار منحصر به فرد، Low Cardinality موثر است. پس از آن، فقط یک بازگشت وجود خواهد داشت، که در آن از بسیاری از دیکشنری های مختلف استفاده می شود، نه فقط یک. تقریباً مانند یک ستون معمولی از نوع رشته کار می کند، شاید کمی کارآمدتر باشد، اما هیچ افت عملکرد جدی وجود نخواهد داشت.
بهترین روش برای جستجوی متن کامل در جدولی با پنج میلیارد ردیف چیست؟
پاسخ های متفاوتی وجود دارد. اولین مورد این است که بگوییم ClickHouse یک موتور جستجوی متن کامل نیست. سیستم های خاصی برای این کار وجود دارد، به عنوان مثال، и . با این حال، من افراد بیشتری را می بینم که می گویند از Elasticsearch به ClickHouse نقل مکان می کنند.
چرا این اتفاق می افتد؟ آنها این را با این واقعیت توضیح می دهند که Elasticsearch از عهده بارگذاری بر روی برخی از حجم ها، با شروع شاخص های ساختمان، دست نمی کشد. ایندکس ها بیش از حد دست و پا گیر می شوند و اگر به سادگی داده ها را به ClickHouse منتقل کنید، معلوم می شود که از نظر حجم چندین برابر کارآمدتر ذخیره می شوند. در عین حال، پرس و جوهای جستجو اغلب به گونه ای نبودند که با در نظر گرفتن ریخت شناسی، نیاز به یافتن عبارتی در کل حجم داده ها باشد، بلکه موارد کاملاً متفاوت است. به عنوان مثال، برای یافتن چند ساعت گذشته در گزارش‌ها برای تعدادی از بایت‌ها.
در این حالت شما یک نمایه در ClickHouse ایجاد می کنید که اولین فیلد در آن تاریخ با زمان خواهد بود. و بزرگترین قطع داده دقیقاً برای محدوده تاریخ خواهد بود. در محدوده تاریخ انتخاب شده، به عنوان یک قاعده، از قبل می توان جستجوی تمام متن را حتی با استفاده از روش brute-force با استفاده از like انجام داد. عبارت like در ClickHouse کارآمدترین عبارت like است که می توانید پیدا کنید. اگه بهتری پیدا کردی بهم بگو
اما هنوز، مانند یک اسکن کامل است. و اسکن کامل می تواند نه تنها در CPU، بلکه روی دیسک نیز کند باشد. اگر به طور ناگهانی یک ترابایت داده در روز دارید و به دنبال کلمه ای در یک روز هستید، باید یک ترابایت را اسکن کنید. و احتمالا روی هارد های معمولی هست و در نتیجه طوری لود میشن که از طریق SSH وارد این سرور نمیشید.
در این مورد، من آماده ارائه یک ترفند کوچک دیگر هستم. این از دسته تجربی است - ممکن است کار کند یا نه. ClickHouse دارای نمایه های متن کامل به شکل فیلترهای تریگرام بلوم است. همکاران ما در Arenadata قبلاً این شاخص‌ها را امتحان کرده‌اند، و اغلب دقیقاً همانطور که در نظر گرفته شده است کار می‌کنند.
برای استفاده صحیح از آنها، باید درک خوبی از نحوه عملکرد آنها داشته باشید: فیلتر شکوفه تریگرام چیست و چگونه اندازه آن را انتخاب کنید. می توانم بگویم که آنها برای پرس و جو در مورد برخی از عبارات نادر، زیر رشته هایی که به ندرت در داده ها یافت می شوند، کمک خواهند کرد. در این حالت، زیرمجموعه ها توسط شاخص ها انتخاب می شوند و داده های کمتری خوانده می شود.
ClickHouse اخیراً ویژگی های پیشرفته تری را برای جستجوی تمام متن اضافه کرده است. این، اولاً، جستجوی دسته‌ای از زیررشته‌ها به‌طور همزمان در یک گذر است، از جمله گزینه‌های حساس به حروف بزرگ، حساس به حروف کوچک، پشتیبانی شده با UTF-8 یا فقط ASCII. کارآمدترین مورد نیاز خود را انتخاب کنید.
همچنین جستجو برای چندین عبارت منظم در یک پاس وجود داشت. لازم نیست X را مانند یک زیر رشته یا X را مانند زیررشته دیگری بنویسید. فوراً بنویسید و همه چیز به بهترین نحو ممکن انجام می شود.
ثالثاً، اکنون یک جستجوی تقریبی برای regexps و یک جستجوی تقریبی برای زیر رشته ها وجود دارد. اگر فردی کلمه ای را با اشتباه تایپی نوشته باشد، برای حداکثر مطابقت جستجو می شود.
بهترین راه برای سازماندهی دسترسی به ClickHouse برای تعداد زیادی از کاربران چیست؟
به ما بگویید چگونه می توان دسترسی تعداد زیادی از مصرف کنندگان و تحلیلگران را سازماندهی کرد. چگونه یک صف تشکیل دهیم، حداکثر پرس و جوهای همزمان را اولویت بندی کنیم و با چه ابزارهایی؟
اگر خوشه به اندازه کافی بزرگ باشد، راه حل خوبی برای افزایش دو سرور دیگر خواهد بود که نقطه ورود تحلیلگران خواهد بود. یعنی به تحلیلگران اجازه ندهید که وارد کلاسترهای خاص شوند، بلکه به سادگی دو سرور خالی، بدون داده ایجاد کنید و از قبل حقوق دسترسی را روی آنها تنظیم کنید. در همان زمان، تنظیمات کاربر در طول درخواست های توزیع شده به سرورهای راه دور منتقل می شود. یعنی روی این دو سرور همه چیز را پیکربندی می کنید و تنظیمات روی کل کلاستر اثر می گذارد.
اصولا این سرورها بدون دیتا هستند اما میزان رم روی آنها برای اجرای درخواست ها بسیار مهم است. اگر تجمیع خارجی یا مرتب‌سازی خارجی فعال باشد، می‌توان از دیسک برای داده‌های موقت نیز استفاده کرد.
مهم است که به تنظیماتی که با تمام محدودیت های ممکن مرتبط هستند نگاه کنید. اگر اکنون به عنوان یک تحلیلگر به خوشه Yandex.Metrics بروم و یک پرس و جو تنظیم کنم تعداد بازدیدها را انتخاب کنید، سپس فوراً استثنایی به من داده می شود که نمی توانم درخواست را انجام دهم. حداکثر تعداد ردیف هایی که من مجاز به اسکن کردن آنها هستم صد میلیارد است و در کل در یک جدول پنجاه تریلیون ردیف وجود دارد. این اولین محدودیت است.
فرض کنید محدودیت تعداد ردیف ها را حذف کرده و دوباره کوئری را اجرا می کنم. سپس استثنای زیر را می بینم - تنظیم فعال است شاخص نیرو بر اساس تاریخ. اگر محدوده تاریخ را مشخص نکرده باشم، نمی توانم پرس و جو را اجرا کنم. برای وارد کردن دستی آن لازم نیست به تحلیلگران تکیه کنید. یک مورد معمولی - یک محدوده تاریخ نوشته شده است که در آن تاریخ رویداد بین یک هفته است. و سپس آنها فقط یک براکت را در آنجا مشخص نکردند، و به جای و معلوم شد که یا - یا URL مطابقت دارد. اگر محدودیتی وجود نداشته باشد، ستون URL را می‌خزد و تعداد زیادی از منابع را هدر می‌دهد.
علاوه بر این، ClickHouse دارای دو تنظیمات اولویت است. متأسفانه آنها بسیار ابتدایی هستند. یکی به سادگی نامیده می شود اولویت. اگر اولویت ≠ 0 و درخواست‌هایی با مقداری اولویت اجرا شوند، اما درخواستی با مقدار اولویت کمتر، که به معنای اولویت بالاتر است، اجرا می‌شود، در این صورت درخواستی با مقدار اولویت بیشتر از، که به معنای اولویت کمتر است، اجرا می‌شود. به سادگی به حالت تعلیق درآمده است و در این مدت اصلا کار نمی کند.
این یک تنظیم بسیار خشن است و برای موقعیت هایی که بار ثابتی روی خوشه وجود دارد مناسب نیست. اما اگر درخواست‌های کوتاه و تکانه‌ای دارید که مهم هستند و خوشه عمدتاً بی‌حرکت است، این تنظیم انجام می‌شود.
تنظیم اولویت بعدی نامیده می شود اولویت رشته سیستم عامل. این به سادگی تمام رشته های اجرای درخواست را در معرض مقدار خوب برای زمانبندی لینوکس قرار می دهد. این طوری کار می کند، اما همچنان کار می کند. اگر حداقل مقدار خوب را تنظیم کنید - این بزرگترین مقدار و در نتیجه کمترین اولویت است - و -19 را برای درخواست های با اولویت بالا تنظیم کنید، CPU درخواست های با اولویت پایین را تقریباً چهار برابر کمتر از درخواست های با اولویت بالا مصرف می کند.
همچنین باید حداکثر زمان اجرای پرس و جو را تنظیم کنید - مثلاً پنج دقیقه. حداقل سرعت اجرای درخواست جالب ترین چیز است. این تنظیم برای مدت طولانی وجود داشته است، و نه تنها باید ادعا کرد که ClickHouse کند نمی شود، بلکه باید آن را مجبور کرد.
تصور کنید که در حال راه اندازی هستید: اگر یک پرس و جو کمتر از یک میلیون ردیف در ثانیه را پردازش کند، نمی توانید این کار را انجام دهید. این به نام خوب ما، پایگاه داده خوب ما بی احترامی می کند. فقط تحریمش کنیم در واقع دو تنظیمات وجود دارد. یکی نامیده می شود حداقل سرعت اجرا - در خطوط در ثانیه، و دوم قبل از بررسی حداقل سرعت اجرای - پانزده ثانیه به طور پیش فرض، تایم اوت نامیده می شود. یعنی پانزده ثانیه امکان پذیر است، و سپس، اگر به آرامی، فقط یک استثنا پرتاب کنید - درخواست را لغو کنید.
شما همچنین باید سهمیه بندی کنید. ClickHouse دارای یک ویژگی سهمیه داخلی است که مصرف منابع را محاسبه می کند. اما، متأسفانه، نه منابع آهنی مانند CPU، دیسک، بلکه منابع منطقی - تعداد درخواست های پردازش شده، خطوط و بایت های خوانده شده. و شما می توانید به عنوان مثال حداکثر صد درخواست در مدت پنج دقیقه و هزار درخواست در ساعت تنظیم کنید.
چرا مهم است؟ زیرا برخی از درخواست های تجزیه و تحلیل به صورت دستی مستقیماً از مشتری ClickHouse انجام می شود. و همه چیز خوب خواهد بود. اما اگر در شرکت خود تحلیلگران پیشرفته ای داشته باشید، آنها یک اسکریپت می نویسند و ممکن است خطایی در اسکریپت وجود داشته باشد. و این خطا باعث می شود که درخواست در یک حلقه بی نهایت اجرا شود. این چیزی است که باید محافظت شود.
آیا می توان نتیجه یک درخواست را به ده مشتری داد؟
ما چندین کاربر داریم که دوست دارند همزمان با درخواست های بسیار زیاد وارد شوند. درخواست بزرگ است، در اصل به سرعت اجرا می شود، اما به دلیل وجود این درخواست ها به طور همزمان، بسیار دردناک می شود. آیا می توان همان درخواستی را که ده بار متوالی رسید، یک بار اجرا کرد و نتیجه را به ده مشتری داد؟
مشکل این است که ما نتایج کش یا حافظه پنهان داده میانی نداریم. یک صفحه کش سیستم عامل وجود دارد که به شما امکان می دهد دیگر داده ها را از روی دیسک نخوانید، اما متأسفانه، داده ها همچنان فشرده، deserialized و پردازش مجدد می شوند.
من می‌خواهم به نحوی از این امر جلوگیری کنم، یا با ذخیره‌سازی داده‌های میانی، یا با ردیف کردن پرسوجوهای مشابه در نوعی صف و افزودن حافظه پنهان نتایج. اکنون یک درخواست کشش در توسعه داریم که یک کش درخواست اضافه می کند، اما فقط برای درخواست های فرعی در بخش های in و join - یعنی راه حل پایین تر است.
با این حال ما هم چنین شرایطی داریم. یک مثال متعارف خاص، درخواست هایی با صفحه بندی است. یه گزارش هست چند صفحه داره و لیمیت 10 درخواست هست بعد همون ولی 10,10 لیمیت. سپس یک صفحه دیگر. و سوال این است که چرا ما هر بار همه آن را حساب می کنیم؟ اما اکنون هیچ راه حلی وجود ندارد و هیچ راهی برای اجتناب از آن وجود ندارد.
یک راه حل جایگزین وجود دارد که به عنوان یک صندلی کناری در کنار ClickHouse قرار می گیرد - .
کریل شواکوف: ClickHouse Proxy دارای یک محدود کننده نرخ داخلی و یک کش نتایج داخلی است. تنظیمات زیادی در آنجا انجام شده است، زیرا یک کار مشابه حل شده است. پروکسی به شما اجازه می دهد تا درخواست ها را با قرار دادن آنها در صف محدود کنید و پیکربندی کنید که کش درخواست چقدر زنده بماند. اگر درخواست ها واقعاً یکسان بود، پروکسی بارها آنها را می دهد و فقط یک بار به ClickHouse می رود.
Nginx همچنین یک کش در نسخه رایگان دارد و این نیز کار خواهد کرد. Nginx حتی تنظیماتی دارد که اگر درخواست‌ها همزمان وارد شوند، سایرین را تا زمانی که یکی تکمیل شود متوقف می‌کند. اما در ClickHouse Proxy است که تنظیمات بسیار بهتر انجام می شود. به طور خاص برای ClickHouse، به طور خاص برای این درخواست ها ساخته شده است، بنابراین مناسب تر است. خوب، تنظیم آن آسان است.
در مورد عملیات ناهمزمان و نماهای تحقق یافته چطور؟
چنین مشکلی وجود دارد که عملیات با موتور جایگزین ناهمزمان است - داده ها ابتدا نوشته می شوند، سپس فرو می ریزند. اگر یک تبلت متریال شده با مقداری مصالح در زیر لوح زندگی کند، موارد تکراری روی آن نوشته می‌شود. و اگر منطق پیچیده ای وجود نداشته باشد، داده ها تکرار می شوند. در مورد آن چه می توان کرد؟
یک راه حل واضح وجود دارد - اجرای یک ماشه در یک کلاس matview خاص در طول یک عملیات فروپاشی ناهمزمان. آیا برنامه ای برای اجرای چنین عملکردی "گلوله های نقره ای" وجود دارد؟
ارزش درک نحوه عملکرد deduplication را دارد. چیزی که می خواهم بگویم به سوال مربوط نمی شود، اما ارزش آن را دارد که برای هر موردی به خاطر بسپارم.
هنگام درج در یک جدول تکراری، کل بلوک های درج شده حذف می شود. اگر همان بلوک حاوی همان تعداد ردیف را به همان ترتیب دوباره وارد کنید، داده‌ها کپی می‌شوند. در پاسخ به درج "Ok" دریافت خواهید کرد، اما یک دسته از داده ها در واقع نوشته می شوند و تکراری نمی شوند.
این برای اطمینان لازم است. اگر در حین درج "Ok" دریافت کردید، داده های شما درج شده است. اگر خطایی از ClickHouse دریافت کردید، آنها درج نمی شوند و باید درج را تکرار کنید. اما اگر در حین درج اتصال قطع شود، شما نمی دانید که آیا داده درج شده است یا خیر. تنها گزینه این است که درج را دوباره تکرار کنید. اگر داده ها واقعاً درج شده باشند و شما آن را مجدداً درج کرده باشید، حذف مجدد بلوک وجود دارد. برای جلوگیری از تکرار لازم است.
و همچنین مهم است که چگونه برای دیدگاه های مادی کار می کند. اگر داده‌ها هنگام درج در جدول اصلی کپی شده باشند، آنها به نمای تحقق‌یافته نیز نمی‌روند.
حالا در مورد سوال وضعیت شما پیچیده تر است زیرا شما در حال نوشتن تکراری از خطوط جداگانه هستید. یعنی کل پک تکراری نیست، بلکه خطوط خاصی هستند و در پس زمینه فرو می ریزند. در واقع، داده‌ها در جدول اصلی جمع می‌شوند و داده‌های جمع نشده به نمای مادی‌شده می‌روند و در حین ادغام هیچ اتفاقی برای نمایش‌های تحقق‌یافته نمی‌افتد. زیرا نمای مادی شده چیزی بیش از یک ماشه در درج نیست. هیچ چیز دیگری در طول عملیات دیگر برای آن اتفاق نمی افتد.
و من نمی توانم اینجا خوشحال باشم. تنها باید به دنبال راه حلی خاص برای این مورد بود. به عنوان مثال، آیا می توان آن را در یک نمای مادی جایگزین کرد، و روش deduplication، شاید، به همین صورت عمل کند. اما متاسفانه نه همیشه. اگر تجمیع شود، کار نمی کند.
کریل شواکوف: زمانی استخوان سازی هم داشتیم. مشکلی وجود دارد که نمایش‌های تبلیغاتی وجود دارد، و برخی داده‌ها وجود دارد که می‌توانیم در زمان واقعی نشان دهیم - اینها فقط نمایش‌ها هستند. آنها به ندرت تکراری می شوند، اما اگر این کار را انجام دهند، به هر حال آنها را از بین می بریم. و چیزهایی وجود داشت که نمی توان آنها را تکرار کرد - کلیک ها و کل این داستان. اما من همچنین می خواستم آنها را تقریباً بلافاصله نشان دهم.
دیدگاه های تحقق یافته چگونه ساخته شدند؟ نماهایی وجود داشت که مستقیماً نوشته شده است - یک رکورد در داده های خام وجود دارد و در نماها نوشته شده است. اونجا یه وقتایی داده ها خیلی درست نیست، کپی شده و غیره. و قسمت دوم جدول وجود دارد که دقیقاً مشابه نماهای مادی شده به نظر می رسند، یعنی دقیقاً از نظر ساختار یکسان هستند. هر چند وقت یکبار، داده ها را دوباره محاسبه می کنیم، داده ها را بدون تکرار می شماریم، روی آن جداول می نویسیم.
ما از طریق API رفتیم - این به صورت دستی در ClickHouse کار نخواهد کرد. و API به نظر می رسد: زمانی که من تاریخ آخرین افزودن به جدول را دارم، که در آن تضمین شده است که داده های صحیح قبلاً محاسبه شده است، و درخواستی را به یک جدول و به جدول دیگر ارسال می کند. از یک درخواست تا مقدار مشخصی زمان را انتخاب می کند و از دیگری چیزی را که هنوز محاسبه نشده است دریافت می کند. و کار می کند، اما نه با استفاده از یک ClickHouse.
اگر نوعی API دارید - برای تحلیلگران، برای کاربران -، در اصل، این یک گزینه است. شما همیشه حساب می کنید، همیشه حساب می کنید. این کار را می توان یک بار در روز یا در زمان دیگری انجام داد. شما محدوده ای را انتخاب می کنید که به آن نیاز ندارید و حیاتی نیست.
ClickHouse لاگ های زیادی دارد. چگونه می توانم همه چیزهایی که در یک لحظه برای سرور اتفاق می افتد را ببینم؟
ClickHouse تعداد بسیار زیادی لاگ مختلف دارد و این تعداد در حال افزایش است. در نسخه های جدید، برخی از آنها حتی به صورت پیش فرض فعال هستند، در نسخه های قدیمی تر باید هنگام به روز رسانی فعال شوند. با این حال، تعداد آنها بیشتر و بیشتر می شود. من می خواهم در نهایت ببینم که اکنون با سرور من چه اتفاقی می افتد، شاید در داشبورد خلاصه.
آیا در تیم ClickHouse یا در تیم دوستان خود دارید که از برخی عملکردهای داشبوردهای آماده پشتیبانی می کنند که این گزارش ها را به عنوان یک محصول نهایی نمایش می دهد؟ در نهایت، فقط نگاه کردن به گزارش‌ها در ClickHouse عالی است. اما اگر از قبل به صورت داشبورد تهیه شده بود خیلی باحال بود. من در این مورد بالا خواهم رفت.
داشبوردهایی وجود دارد، اگرچه استاندارد نیستند. ما حدود 60 تیم در شرکت خود داریم که از ClickHouse استفاده می کنند و عجیب ترین چیز این است که بسیاری از آنها داشبوردی دارند که خودشان ساخته اند و کمی متفاوت است. برخی از تیم ها از نصب داخلی Yandex.Cloud استفاده می کنند. برخی از گزارش های آماده وجود دارد، اگرچه همه موارد ضروری نیستند. دیگران مال خودشان را دارند.
همکاران من از متریکا داشبورد خود را در گرافانا دارند و من داشبورد خود را برای کلاستر خود دارم. من به مواردی مانند ضربه کش برای یک سریف کش نگاه می کنم. و حتی دشوارتر این است که ما از ابزارهای مختلف استفاده می کنیم. من داشبورد خود را روی یک ابزار بسیار قدیمی به نام Graphite-web ایجاد کردم. او کاملاً زشت است. و من هنوز هم از آن استفاده می کنم، اگرچه Grafana احتمالا راحت تر و زیباتر خواهد بود.
نکته اساسی در داشبوردها یکسان است. اینها معیارهای سیستم برای خوشه هستند: CPU، حافظه، دیسک، شبکه. موارد دیگر عبارتند از: تعداد درخواست‌های همزمان، تعداد ادغام‌های همزمان، تعداد درخواست‌ها در ثانیه، حداکثر تعداد تکه‌ها برای پارتیشن‌های جدول MergeTree، تاخیر تکرار، اندازه صف تکرار، تعداد ردیف‌های درج شده در ثانیه، تعداد بلوک های درج شده در ثانیه این تمام چیزی است که نه از لاگ ها، بلکه از معیارها به دست می آید.
ولادیمیر کولوبایف: الکسی، من می خواهم کمی اصلاح کنم. گرافانا وجود دارد. Grafana یک منبع داده دارد که ClickHouse است. یعنی می توانم از Grafana مستقیماً به ClickHouse درخواست بدهم. ClickHouse یک جدول با لاگ دارد، برای همه یکسان است. در نتیجه، من می خواهم به این جدول ورود به سیستم در گرافانا دسترسی داشته باشم و درخواست هایی را که سرورم اعمال می کند، ببینم. داشتن چنین داشبوردی عالی خواهد بود.
من خودم دوچرخه کردم اما من یک سوال دارم - اگر همه اینها استاندارد است و Grafana توسط همه استفاده می شود، چرا Yandex چنین داشبورد رسمی ندارد؟
کریل شواکوف: در واقع منبع داده ای که ClickHouse اکنون از Altinity پشتیبانی می کند. و من فقط می‌خواهم یک بردار از جایی که باید حفاری کنم و چه کسی را فشار دهم ارائه دهم. می‌توانید از آنها بپرسید، زیرا Yandex هنوز ClickHouse را می‌سازد و نه داستان اطراف آن. Altinity شرکت اصلی است که در حال حاضر ClickHouse را تبلیغ می کند. آنها او را رها نخواهند کرد، بلکه از او حمایت خواهند کرد. زیرا اصولا برای آپلود داشبورد در سایت گرافانا فقط باید ثبت نام کرده و آپلود کنید - مشکل خاصی وجود ندارد.
الکسی میلوویدوف: در طول سال گذشته، ClickHouse بسیاری از ویژگی های پروفایل پرس و جو را اضافه کرده است. معیارهایی برای هر درخواست استفاده از منبع وجود دارد. و اخیراً یک نمایه‌گر پرس و جو حتی سطح پایین‌تری اضافه شده است تا ببیند پرس و جو در هر میلی‌ثانیه کجا می‌گذرد. اما برای استفاده از این قابلیت، باید کلاینت کنسول را باز کنم و عبارتی را تایپ کنم که مدام فراموش می کنم. من آن را در جایی ذخیره کردم و همیشه فراموش می کنم که دقیقا کجاست.
ای کاش ابزاری وجود داشت که فقط می گفت - در اینجا سؤالات سنگین شما، گروه بندی شده بر اساس کلاس پرس و جو هستند. من روی یکی کلیک کردم و به من می گفتند که سنگین است. اکنون چنین راه حلی وجود ندارد. و واقعاً عجیب است که وقتی مردم از من می پرسند: "به من بگو، آیا داشبورد آماده ای برای Grafana وجود دارد؟" از Kostyan. نمی دانم چیست، خودم از آن استفاده نکرده ام.»
چگونه بر merdzhi تأثیر بگذاریم تا سرور در OOM نیفتد؟
من یک جدول دارم، فقط یک پارتیشن در جدول وجود دارد، آن ReplaceingMergeTree است. من چهار سال است که در حال نوشتن اطلاعات برای آن هستم. مجبور شدم یک تغییر در آن ایجاد کنم و برخی از داده ها را حذف کنم.
من این کار را انجام دادم و در طول پردازش این درخواست، تمام حافظه های موجود در تمام سرورهای کلاستر خورده شد و همه سرورهای کلاستر با هم به OOM رفتند. سپس همه با هم بلند شدند، شروع به ادغام همان عملیات، این بلوک داده، کردند و دوباره در OOM افتادند. بعد دوباره بلند شدند و دوباره افتادند. و این چیز متوقف نشد.
سپس معلوم شد که این در واقع یک اشکال است که بچه ها آن را برطرف کردند. این خیلی باحاله، خیلی ممنون اما باقیمانده باقی ماند. و اکنون، وقتی به لزوم انجام یک ادغام خاص در جدول فکر می کنم، یک سوال دارم - چرا نمی توانم این ادغام ها را انجام دهم و به نوعی بر آنها تأثیر بگذارم؟ به عنوان مثال، آنها را با مقدار RAM مورد نیاز، یا در اصل، با تعداد آنها محدود کنید، که این جدول خاص را پردازش می کند.
من یک جدول به نام "متریک" دارم، لطفاً آن را برای من در دو جریان پردازش کنید. نیازی به تولید ده یا پنج ادغام به صورت موازی نیست، این کار را در دو انجام دهید. من فکر می کنم که در دو به اندازه کافی حافظه دارم، اما ممکن است برای پردازش ده کافی نباشد. چرا ترس باقی می ماند؟ از آنجا که جدول در حال رشد است و روزی من با وضعیتی روبرو خواهم شد که در اصل دیگر به دلیل یک باگ نیست، بلکه به دلیل این واقعیت است که داده ها به اندازه ای تغییر می کنند که من به سادگی حافظه کافی در آن ندارم. سرور. و سپس سرور در حین ادغام به OOM می افتد. علاوه بر این، من می توانم جهش را لغو کنم، اما ادغام از بین رفته است.
می دانید، هنگام ادغام، سرور به OOM نمی افتد، زیرا هنگام ادغام، مقدار RAM فقط برای یک محدوده داده کوچک استفاده می شود. بنابراین همه چیز بدون توجه به مقدار داده ها خوب خواهد بود.
ولادیمیر کولوبایف: خوب. در اینجا لحظه به گونه ای است که پس از رفع اشکال، من یک نسخه جدید را برای خودم دانلود کردم و روی یک جدول دیگر، کوچکتر که تعداد زیادی پارتیشن وجود دارد، عملیات مشابهی را انجام دادم. و در حین ادغام حدود 100 گیگابایت رم روی سرور رایت شد. من 150 مشغول بودم، 100 تا خوردم و یک پنجره 50 گیگابایتی باقی مانده بود، بنابراین در OOM نیفتم.
اگر واقعاً 100 گیگابایت رم مصرف کند، در حال حاضر چه چیزی من را از سقوط به OOM محافظت می کند؟ در شرایطی که ناگهان رم در merdzh تمام شود چه باید کرد؟
الکسی میلوویدوف: چنین مشکلی وجود دارد که مصرف رم محدود به merdzhi نیست. و مشکل دوم این است که اگر یک ادغام اختصاص داده شده است، باید اجرا شود، زیرا در گزارش تکرار نوشته شده است. Replication log اقداماتی است که برای آوردن ماکت به یک حالت سازگار لازم است. اگر دستکاری‌های دستی انجام ندهید که این گزارش تکرار به عقب برگردد، ادغام باید به روشی انجام شود.
البته، داشتن محدودیت در RAM، که "فقط در مورد" در برابر OOM محافظت می کند، اضافی نخواهد بود. این به اجرای ادغام کمکی نمی کند، دوباره شروع می شود، به آستانه ای می رسد، یک استثنا ایجاد می کند، و سپس دوباره شروع می شود - هیچ چیز خوبی از آن حاصل نمی شود. اما اصولاً معرفی این محدودیت مفید خواهد بود.
توسعه درایور Golang برای ClickHouse چگونه انجام خواهد شد؟
راننده Golang نوشته Kirill Shvakov اکنون به طور رسمی توسط تیم ClickHouse پشتیبانی می شود. او ، او اکنون بزرگ و واقعی است.
یک یادداشت کوچک یک مخزن شگفت انگیز و دوست داشتنی از اشکال عادی نظم بی نهایت وجود دارد - این Vertica است. آنها همچنین درایور رسمی پایتون خود را دارند که توسط توسعه دهندگان Vertica نگهداری می شود. و چندین بار اتفاق افتاد که نسخه های ذخیره سازی و نسخه های درایور کاملاً ناگهانی از هم جدا شدند و درایور در یک نقطه از کار افتاد. و نکته دوم. به نظر من، پشتیبانی از این درایور رسمی توسط سیستم "نیپل" حفظ می شود - شما یک موضوع را برای آنها می نویسید و برای همیشه معلق می ماند.
دو تا سوال دارم اکنون درایور Golang Kirill یک راه تقریباً پیش فرض برای برقراری ارتباط از Golang با ClickHouse است. مگر اینکه کسی هنوز از طریق رابط http ارتباط برقرار کند، زیرا آن را بسیار دوست دارد. این درایور چگونه توسعه خواهد یافت؟ آیا با برخی تغییرات شکسته در خود مخزن همگام خواهد شد؟ و روال بررسی موضوع چگونه است؟
کریل شواکوف: اولین مورد این است که چگونه همه چیز به صورت بوروکراتیک تنظیم شده است. این نکته مورد بحث قرار نگرفته است، بنابراین من چیزی برای پاسخگویی ندارم.
برای پاسخ به سوال در مورد موضوع، به کمی تاریخچه راننده نیاز داریم. من برای شرکتی کار می کردم که داده های زیادی داشت. این یک اسپینر تبلیغاتی با تعداد زیادی رویداد بود که باید در جایی ذخیره می شد. و در نقطه ای کلیک هاوس ظاهر شد. ما داده ها را در آن ریختیم و در ابتدا همه چیز خوب بود، اما سپس ClickHouse سقوط کرد. در آن زمان تصمیم گرفتیم که نیازی به آن نداریم.
یک سال بعد، ما به ایده استفاده از ClickHouse بازگشتیم و باید به نحوی داده ها را در آنجا بنویسیم. ورودی این بود - آهن بسیار ضعیف است، منابع کمی وجود دارد. اما ما همیشه به این روش کار کرده‌ایم و بنابراین به پروتکل بومی نگاه کرده‌ایم.
از آنجایی که ما روی Go کار می کردیم، مشخص بود که به یک راننده Go نیاز داریم. من این کار را تقریبا تمام وقت انجام دادم - این وظیفه کاری من بود. تا یک جایی آن را مطرح کردیم و اصولاً هیچکس انتظار نداشت که غیر از ما از آن استفاده کند. سپس CloudFlare دقیقاً با همین مشکل همراه شد و برای مدتی ما بسیار روان با آنها کار کردیم، زیرا آنها وظایف مشابهی داشتند. و ما این کار را هم در خود ClickHouse و هم در درایور انجام دادیم.
در مقطعی به سادگی از انجام آن دست کشیدم، زیرا فعالیت من از نظر کلیک هاوس و با کار کمی تغییر کرده است. بنابراین مسائل بسته نیست. به طور دوره ای، افرادی که خودشان به چیزی نیاز دارند، به مخزن متعهد می شوند. سپس به درخواست کشش نگاه می کنم و حتی گاهی اوقات خودم چیزی را ویرایش می کنم، اما به ندرت این اتفاق می افتد.
من می خواهم به سمت راننده برگردم. چند سال پیش که کل این کار شروع شد، ClickHouse نیز متفاوت و با امکانات متفاوت بود. اکنون درک درستی از نحوه بازسازی درایور وجود دارد تا خوب باشد. اگر این اتفاق بیفتد، نسخه 2 به هر حال به دلیل عصاهای انباشته شده ناسازگار خواهد بود.
من نمی دانم چگونه این را ترتیب دهم. من خودم وقت زیادی ندارم اگر چند نفر راننده را تمام کنند، می توانم به آنها کمک کنم و به آنها بگویم که چه کار کنند. اما این مشارکت فعال Yandex در توسعه پروژه است که هنوز به هیچ وجه مورد بحث قرار نگرفته است.
الکسی میلوویدوف: در واقع هنوز هیچ بروکراسی اداری در مورد این رانندگان وجود ندارد. تنها چیزی که وجود دارد این است که آنها به یک سازمان رسمی منتقل می شوند، یعنی این درایور به عنوان راه حل رسمی پیش فرض برای Go شناخته می شود. چند درایور دیگه هم هست ولی جدا میاد.
ما هیچ توسعه ای برای این درایورها در داخل نداریم. سوال این است که آیا می‌توانیم فردی را استخدام کنیم، نه به طور خاص برای این راننده، بلکه برای توسعه همه رانندگان جامعه، یا می‌توانیم فردی خارج از آن را پیدا کنیم.
فرهنگ لغت خارجی پس از راه اندازی مجدد با فعال بودن lazy_load بالا نمی رود. چه باید کرد؟
ما تنظیمات lazy_load را فعال کرده ایم و پس از راه اندازی مجدد سرور، خود دیکشنری بالا نمی رود. فقط پس از دسترسی کاربر به این فرهنگ لغت مطرح می شود. و در اولین تماس خطا می دهد. آیا می توان به نحوی دیکشنری ها را با استفاده از ClickHouse بطور خودکار بارگذاری کرد یا همیشه باید آمادگی آنها را خودتان کنترل کنید تا کاربران خطا دریافت نکنند؟
شاید ما یک نسخه قدیمی از ClickHouse داشته باشیم، بنابراین فرهنگ لغت به طور خودکار بارگیری نشده است. ممکنه؟
اول، لغت نامه ها را می توان با استفاده از پرس و جو بارگذاری کرد بارگذاری مجدد دیکشنری های سیستم. ثانیاً در مورد خطا - اگر فرهنگ لغت قبلاً بارگیری شده باشد ، پرس و جوها روی داده هایی که بارگذاری شده اند کار می کنند. اگر فرهنگ لغت هنوز بارگذاری نشده باشد، درست در زمان درخواست بارگیری می شود.
برای دیکشنری های سنگین، این خیلی راحت نیست. به عنوان مثال، شما باید یک میلیون ردیف از MySQL واکشی کنید. شخصی یک انتخاب ساده انجام می دهد، اما این انتخاب برای همان میلیون ردیف منتظر می ماند. در اینجا دو راه حل وجود دارد. اولین مورد این است که lazy_load را خاموش کنید. دوم این است که وقتی سرور بالا می رود، قبل از روشن کردن بار روی آن، انجام دهید دیکشنری بارگذاری مجدد سیستم یا فقط درخواستی را اجرا کنید که از دیکشنری استفاده می کند. سپس فرهنگ لغت بارگذاری می شود. شما باید در دسترس بودن دیکشنری ها را با تنظیم lazy_load فعال کنید، زیرا ClickHouse آنها را به طور خودکار بالا نمی برد.
پاسخ سوال آخر این است که یا نسخه قدیمی است یا باید اشکال زدایی شود.
در مورد این واقعیت که دیکشنری‌های بارگذاری مجدد سیستم هیچ یک از تعداد زیادی دیکشنری را بارگیری نمی‌کنند، اگر حداقل یکی از آنها با خطا از کار بیفتد، چطور؟
سوال دیگری در مورد دیکشنری های بارگذاری مجدد سیستم وجود دارد. ما دو دیکشنری داریم - یکی بارگذاری نشده است، دومی بارگذاری شده است. دیکشنری های بارگذاری مجدد سیستم در این مورد هیچ دیکشنری را بارگذاری نمی کند و باید با استفاده از فرهنگ لغت بارگذاری مجدد سیستم، یک دیکشنری خاص را به نام آن بارگذاری کنید. آیا این مربوط به نسخه ClickHouse نیز هست؟
من می خواهم لطفا. این رفتار تغییر کرده است. بنابراین، اگر ClickHouse را به روز کنید، آن نیز تغییر خواهد کرد. اگر از رفتار فعلی راضی نیستید بارگذاری مجدد دیکشنری های سیستم، به روز رسانی کنید، و امیدواریم که برای بهتر شدن تغییر کند.
آیا راهی وجود دارد که بتوان جزئیات را در پیکربندی ClickHouse پیکربندی کرد، اما آنها را روی خطاها روشن نکرد؟
سوال بعدی در مورد خطاهای مربوط به فرهنگ لغت یعنی جزئیات است. ما جزئیات اتصال را در پیکربندی ClickHouse در دیکشنری ثبت کرده ایم و در صورت بروز خطا، این جزئیات و رمز عبور را در پاسخ دریافت می کنیم.
ما این خطا را با افزودن جزئیات به پیکربندی درایور ODBC حل کردیم. آیا راهی برای پیکربندی جزئیات در پیکربندی ClickHouse وجود دارد، اما نمی‌توان این جزئیات را بر روی خطاها نشان داد؟
در اینجا، راه حل واقعاً این است - تعیین این اعتبارنامه ها در odbc.ini، و در خود ClickHouse، فقط نام منبع داده ODBC را مشخص کنید. این اتفاق برای سایر منابع فرهنگ لغت نمی افتد - نه برای دیکشنری با MySQL و نه برای بقیه، شما نباید رمز عبور را در پیام خطا مشاهده کنید. برای ODBC نیز نگاه خواهم کرد - اگر چنین چیزی وجود دارد، فقط باید آن را حذف کنید.
پاداش: پس زمینه زوما از گردهمایی ها
با کلیک بر روی تصویر برای پیگیرترین خوانندگان، پس زمینه های جایزه از گردهمایی ها باز می شود. خاموش کردن آتش همراه با طلسم های فن آوری Avito، گفتگو با همکاران از اتاق مدیر سیستم یا یک باشگاه کامپیوتر قدیمی، و برگزاری یک روز روزانه در زیر پل در پس زمینه گرافیتی.
منبع: www.habr.com