HighLoad++، Yuri Nasretdinov (VKontakte): چگونه VK داده ها را از ده ها هزار سرور به ClickHouse وارد می کند

HighLoad++ مسکو 2018، سالن کنگره. 9 نوامبر ساعت 15:00

چکیده و ارائه: http://www.highload.ru/moscow/2018/abstracts/4066

یوری ناصردینوف (VKontakte): این گزارش در مورد تجربه اجرای ClickHouse در شرکت ما صحبت می کند - چرا به آن نیاز داریم، چه مقدار داده ذخیره می کنیم، چگونه آن را می نویسیم و غیره.

مواد اضافی: استفاده از Clickhouse به عنوان جایگزینی برای ELK، Big Query و TimescaleDB

یوری ناصرالدینوف: - سلام به همه! همانطور که قبلاً معرفی شده ام، یوری ناصردینوف هستم. من در VKontakte کار می کنم. من در مورد نحوه وارد کردن داده ها به ClickHouse از ناوگان سرور خود (ده ها هزار) صحبت خواهم کرد.

سیاههها چیست و چرا آنها را جمع آوری می کند؟

آنچه به شما خواهیم گفت: چه کاری انجام دادیم، چرا به ترتیب به "ClickHouse" نیاز داشتیم، چرا آن را انتخاب کردیم، چه نوع عملکردی را تقریباً می توانید بدون پیکربندی چیز خاصی دریافت کنید. من در مورد جداول بافر، مشکلاتی که با آنها داشتیم و راه‌حل‌هایی که از منبع باز ایجاد کرده‌ایم - KittenHouse و Lighthouse بیشتر به شما خواهم گفت.

اصلاً چرا باید کاری انجام دهیم (در VKontakte همه چیز همیشه خوب است، درست است؟). ما می خواستیم گزارش های اشکال زدایی را جمع آوری کنیم (و صدها ترابایت داده در آنجا وجود داشت)، شاید به نحوی محاسبه آمار راحت تر باشد. و ما یک ناوگان ده ها هزار سرور داریم که همه اینها باید از طریق آنها انجام شود.

چرا تصمیم گرفتیم؟ ما احتمالاً راه حل هایی برای ذخیره سیاهه ها داشتیم. در اینجا - چنین "Backend VK" عمومی وجود دارد. من به شدت توصیه می کنم در آن مشترک شوید.

لاگ چیست؟ این موتوری است که آرایه های خالی را برمی گرداند. موتورها در VK همان چیزی است که دیگران آن را میکروسرویس می نامند. و این هم یک برچسب خندان (لایک های بسیار زیاد). چطور؟ خوب، بیشتر گوش کن!

از چه چیزی می توان برای ذخیره سیاهه های مربوط استفاده کرد؟ غیرممکن است که از حدوپ یاد نکنیم. سپس، به عنوان مثال، Rsyslog (ذخیره این لاگ ها در فایل ها). ال اس دی چه کسی می داند ال اس دی چیست؟ نه، این ال اس دی نیست. به ترتیب فایل ها را نیز ذخیره کنید. خوب، ClickHouse یک گزینه عجیب است.

کلیک هاوس و رقبا: الزامات و فرصت ها

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

و ما چنین نیاز جالبی داریم: ما گاهی اوقات خروجی برخی از دستورات را می نویسیم (به عنوان مثال، لاگ ها)، به راحتی می تواند بیش از 4 کیلوبایت باشد. و اگر این مورد از طریق UDP کار کند، پس نیازی به خرج کردن ندارد... هیچ "سربار" برای اتصال نخواهد داشت و برای تعداد زیادی سرور این یک امتیاز مثبت خواهد بود.

بیایید ببینیم منبع باز چه چیزی به ما ارائه می دهد. اولا، ما موتور Logs را داریم - این موتور ما است. اصولاً او می تواند همه کارها را انجام دهد، حتی می تواند خطوط طولانی بنویسد. خوب، داده‌ها را به‌طور شفاف فشرده نمی‌کند - اگر بخواهیم می‌توانیم ستون‌های بزرگ را خودمان فشرده کنیم... البته ما نمی‌خواهیم (در صورت امکان). تنها مشکل این است که او فقط می‌تواند چیزی را که در حافظه‌اش جای می‌گیرد، ببخشد. برای خواندن بقیه، باید بایلاگ این موتور را دریافت کنید و بر این اساس، زمان زیادی طول می کشد.

چه گزینه های دیگر وجود دارد؟ مثلا «هدوپ». سهولت کار ... چه کسی فکر می کند که راه اندازی Hadup آسان است؟ البته هیچ مشکلی برای ضبط وجود ندارد. هنگام مطالعه گاهی اوقات سؤالاتی پیش می آید. در اصل، من می گویم احتمالا نه، به خصوص برای سیاهههای مربوط. ذخیره سازی طولانی مدت - البته، بله، فشرده سازی داده ها - بله، رشته های طولانی - واضح است که می توانید ضبط کنید. اما ضبط از تعداد زیادی سرور... هنوز باید خودت کاری انجام دهی!

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

سپس توسعه "badushka" LSD وجود دارد. اساساً همان "Rsyslog" است: از رشته های طولانی پشتیبانی می کند، اما نمی تواند از طریق UDP کار کند و در واقع، به همین دلیل، متاسفانه، چیزهای زیادی باید در آنجا بازنویسی شوند. LSD باید دوباره طراحی شود تا بتواند از ده ها هزار سرور ضبط کند.

و اینجا! یک گزینه خنده دار ElasticSearch است. چگونه بگوییم؟ او با خواندن خوب عمل می کند، یعنی سریع می خواند، اما در نوشتن خیلی خوب نیست. اولاً اگر داده ها را فشرده کند، بسیار ضعیف است. به احتمال زیاد، یک جستجوی کامل به ساختارهای داده بزرگتر از حجم اصلی نیاز دارد. کار با آن دشوار است و اغلب مشکلاتی با آن ایجاد می شود. و دوباره ضبط در الاستیک - ما باید همه کارها را خودمان انجام دهیم.

در اینجا ClickHouse یک گزینه ایده آل است، البته. تنها نکته این است که ضبط از ده ها هزار سرور مشکل دارد. اما حداقل یک مشکل وجود دارد، ما می توانیم سعی کنیم آن را به نحوی حل کنیم. و بقیه گزارش در مورد این مشکل است. چه نوع عملکردی می توانید از ClickHouse انتظار داشته باشید؟

چگونه قرار است آن را وارد کنیم؟ MergeTree

کدام یک از شما درباره «ClickHouse» چیزی نشنیده یا نمی داند؟ من باید به شما بگویم، نه؟ خیلی سریع. درج در آنجا - 1-2 گیگابیت در ثانیه، انفجارهای تا 10 گیگابیت در ثانیه در واقع می تواند این پیکربندی را تحمل کند - دو Xeon 6 هسته ای (یعنی حتی قوی ترین آنها) 256 گیگابایت رم، 20 ترابایت وجود دارد. در RAID (هیچ کس پیکربندی نشده، تنظیمات پیش فرض). الکسی میلوویدوف، توسعه دهنده ClickHouse، احتمالاً آنجا نشسته و گریه می کند، زیرا ما چیزی را پیکربندی نکرده ایم (همه چیز برای ما اینطور کار کرد). بر این اساس، اگر داده ها به خوبی فشرده شوند، می توان سرعت اسکن، مثلاً حدود 6 میلیارد خط در ثانیه را به دست آورد. اگر % را در یک رشته متن دوست دارید - 100 میلیون خط در ثانیه، یعنی بسیار سریع به نظر می رسد.

چگونه قرار است آن را وارد کنیم؟ خوب، می دانید که VK از PHP استفاده می کند. ما از هر PHP Worker از طریق HTTP به "ClickHouse" در جدول MergeTree برای هر رکورد وارد می کنیم. چه کسی مشکلی در این طرح می بیند؟ به دلایلی، همه دست خود را بالا نبردند. اجازه بدهید به شما بگویم.

اولاً ، سرورهای زیادی وجود دارد - بر این اساس ، اتصالات زیادی (بد) وجود خواهد داشت. سپس بهتر است اطلاعات را بیش از یک بار در ثانیه در MergeTree وارد کنید. و چه کسی می داند چرا؟ خوب خوب. در این مورد کمی بیشتر به شما خواهم گفت. سوال جالب دیگر این است که ما تجزیه و تحلیل انجام نمی دهیم، نیازی به غنی سازی داده ها نداریم، ما به سرورهای میانی نیاز نداریم، می خواهیم مستقیماً در "ClickHouse" درج کنیم (ترجیحا - هر چه مستقیم تر، بهتر).

بر این اساس، درج در MergeTree چگونه انجام می شود؟ چرا بهتر است بیشتر از یک بار در ثانیه یا کمتر در آن وارد شود؟ واقعیت این است که "ClickHouse" یک پایگاه داده ستونی است و داده ها را به ترتیب صعودی کلید اصلی مرتب می کند و هنگامی که یک درج انجام می دهید، تعدادی فایل حداقل برابر با تعداد ستون هایی که داده ها در آنها مرتب شده اند ایجاد می شود. به ترتیب صعودی کلید اصلی (یک دایرکتوری جداگانه ایجاد می شود، مجموعه ای از فایل ها روی دیسک برای هر درج). سپس درج بعدی می آید و در پس زمینه آنها به "پارتیشن های" بزرگتر ترکیب می شوند. از آنجایی که داده ها مرتب شده اند، امکان "ادغام" دو فایل مرتب شده بدون مصرف حافظه زیاد وجود دارد.

اما، همانطور که ممکن است حدس بزنید، اگر برای هر درج 10 فایل بنویسید، ClickHouse (یا سرور شما) به سرعت به پایان می رسد، بنابراین توصیه می شود در دسته های بزرگ قرار دهید. بر این اساس، ما هرگز اولین طرح را وارد مرحله تولید نکردیم. ما بلافاصله یکی را راه اندازی کردیم که در اینجا شماره 2 دارد:

در اینجا تصور کنید که حدود هزار سرور وجود دارد که ما روی آنها راه اندازی کرده ایم، فقط PHP وجود دارد. و در هر سرور عامل محلی ما وجود دارد که ما آن را "Kittenhouse" نامیدیم، که یک اتصال را با "ClickHouse" حفظ می کند و هر چند ثانیه یک بار داده ها را وارد می کند. داده‌ها را نه در MergeTree، بلکه در یک جدول بافر قرار می‌دهد، که دقیقاً برای جلوگیری از درج مستقیم آن در MergeTree عمل می‌کند.

کار با جداول بافر

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

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

Kittenhouse چیست و چگونه کار می کند؟

KittenHouse چیست؟ این یک پروکسی است. حدس بزنید چه زبانی؟ من بیشترین موضوعات تبلیغاتی را در گزارش خود جمع آوری کردم - "Clickhouse"، برو، شاید چیز دیگری به خاطر بیاورم. بله، این در Go نوشته شده است، زیرا من واقعاً نمی دانم چگونه به زبان C بنویسم، نمی خواهم.

بر این اساس، با هر سرور ارتباط برقرار می کند و می تواند در حافظه بنویسد. به عنوان مثال، اگر ما گزارش های خطا را در Clickhouse بنویسیم، سپس اگر Clickhouse زمان برای درج داده ها نداشته باشد (در نهایت، اگر بیش از حد نوشته شده باشد)، حافظه را متورم نمی کنیم - ما به سادگی بقیه را بیرون می اندازیم. زیرا اگر چندین گیگابیت در ثانیه خطا بنویسیم، احتمالاً می توانیم برخی از آنها را حذف کنیم. Kittenhouse می تواند این کار را انجام دهد. بعلاوه، می تواند تحویل قابل اعتمادی را انجام دهد، یعنی نوشتن روی دیسک در ماشین محلی و هر بار (در آنجا، هر دو ثانیه یک بار) سعی می کند داده ها را از این فایل تحویل دهد. و در ابتدا از قالب معمولی Values ​​استفاده کردیم - نه برخی از فرمت های باینری، یک قالب متنی (مانند SQL معمولی).

اما بعد این اتفاق افتاد. ما از تحویل قابل اعتماد استفاده کردیم، لاگ نوشتیم، سپس تصمیم گرفتیم (این یک خوشه آزمایشی مشروط بود) ... برای چندین ساعت از آن خارج شد و دوباره بالا آمد و یک درج از هزار سرور شروع شد - معلوم شد که کلیک هاوس هنوز یک "Thread on Connection" - بر این اساس، در هزار اتصال، یک درج فعال منجر به میانگین بار در سرور حدود یک و نیم هزار می شود. با کمال تعجب، سرور درخواست‌ها را پذیرفت، اما داده‌ها پس از مدتی همچنان درج شدند. اما سرویس دهی آن برای سرور بسیار سخت بود...

nginx را اضافه کنید

چنین راه حلی برای مدل Thread per Connection nginx است. ما nginx را در جلوی کلیک‌هاوس نصب کردیم، در همان زمان تعادل را برای دو کپی تنظیم کردیم (سرعت درج ما 2 برابر افزایش یافت، اگرچه این واقعیت ندارد که اینطور باشد) و تعداد اتصالات را به کلیک‌هاوس محدود کردیم. بالادست و بر این اساس، بیش از 50 اتصال، به نظر می رسد درج هیچ فایده ای ندارد.

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

سپس این مشکل جالب را کشف کردیم: اگر از یک روش غیر استاندارد برای درج در حالت SQL استفاده کنید، یک تجزیه کننده SQL مبتنی بر AST کامل را مجبور می کند که بسیار کند است. بر این اساس، ما تنظیماتی را اضافه کرده‌ایم تا اطمینان حاصل کنیم که هرگز این اتفاق نمی‌افتد. ما تعادل بار، بررسی های بهداشتی را انجام دادیم، به طوری که اگر کسی بمیرد، هنوز داده ها را باقی می گذاریم. ما اکنون جدول های بسیار زیادی داریم که باید خوشه های Clickhouse مختلف داشته باشیم. و همچنین شروع به فکر کردن در مورد کاربردهای دیگر کردیم - برای مثال، می‌خواستیم گزارش‌هایی را از ماژول‌های nginx بنویسیم، اما آنها نمی‌دانند چگونه با استفاده از RPC ما ارتباط برقرار کنند. خوب، من می خواهم به آنها یاد بدهم که چگونه حداقل به نحوی ارسال کنند - برای مثال، رویدادها را در لوکال هاست از طریق UDP دریافت کنند و سپس آنها را به Clickhouse ارسال کنند.

یک قدم تا راه حل فاصله دارد

طرح نهایی به این صورت شروع شد (نسخه چهارم این طرح): در هر سرور روبروی Clickhouse nginx (روی همان سرور) وجود دارد و به سادگی درخواست های لوکال هاست را با محدودیت تعداد اتصالات 50 پروکسی می کند. قطعات. و این طرح قبلاً کاملاً کار می کرد، همه چیز با آن بسیار خوب بود.

حدود یک ماه اینطور زندگی کردیم. همه خوشحال بودند، جداول اضافه کردند، اضافه کردند، اضافه کردند... در کل معلوم شد که نحوه اضافه کردن جداول بافر چندان بهینه نیست (اینطور بگوییم). ما 16 قطعه را در هر جدول و یک فاصله چند ثانیه ای انجام دادیم. ما 20 جدول داشتیم و هر جدول 8 درج در ثانیه دریافت می کرد - و در این مرحله "Clickhouse" شروع شد... رکوردها شروع به کند شدن کردند. نه تنها عبور نکردند... به طور پیش فرض، nginx چیز جالبی داشت که اگر اتصالات در بالادست به پایان می رسید، به سادگی "502" را به همه درخواست های جدید برمی گرداند.

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

جایگزینی nginx با یک پروکسی معکوس

من تصمیم گرفتم که خودمان باید این را مدیریت کنیم، لازم نیست آن را به nginx بسپاریم - nginx نمی داند چه جداولی در Clickhouse وجود دارد و من nginx را با یک پروکسی معکوس جایگزین کردم که خودم هم نوشتم.

داره چیکار میکنه؟ این بر اساس کتابخانه fasthttp "goshnoy" کار می کند، یعنی سریع، تقریبا به همان سرعت nginx. با عرض پوزش، ایگور، اگر شما در اینجا حضور دارید (توجه داشته باشید: ایگور سیسوف یک برنامه نویس روسی است که وب سرور nginx را ایجاد کرده است). می‌تواند بفهمد که اینها چه نوع جستارهایی هستند - INSERT یا SELECT - بر این اساس، استخرهای اتصال مختلفی را برای انواع مختلف پرس‌و‌جوها نگه می‌دارد.

بر این اساس، حتی اگر زمان لازم برای تکمیل درخواست‌های درج را نداشته باشیم، «انتخاب‌ها» عبور می‌کنند و بالعکس. و داده ها را در جداول بافر گروه بندی می کند - با یک بافر کوچک: در صورت وجود هر گونه خطا، خطاهای نحوی و غیره - به طوری که آنها تأثیر زیادی روی بقیه داده ها نداشته باشند، زیرا وقتی به سادگی در جداول بافر درج می کنیم، "باچی" کوچکی داشت و تمام اشتباهات نحوی فقط روی این قطعه کوچک تأثیر می گذاشت. و در اینجا آنها قبلاً روی یک بافر بزرگ تأثیر می گذارند. کوچک 1 مگابایت است، یعنی نه چندان کوچک.

قرار دادن یک هماهنگ سازی و در اصل جایگزین کردن nginx، اساساً همان کاری را انجام می دهد که nginx قبلا انجام می داد - برای این کار نیازی به تغییر "Kittenhouse" محلی ندارید. و از آنجایی که از fasthttp استفاده می کند، بسیار سریع است - شما می توانید بیش از 100 هزار درخواست در ثانیه برای درج های منفرد از طریق یک پروکسی معکوس انجام دهید. از نظر تئوری، می‌توانید هر بار یک خط را در پراکسی معکوس خانه بچه‌گربه وارد کنید، اما البته ما این کار را انجام نمی‌دهیم.

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

قاتل یک راه حل موقت است، بچه گربه دائمی است

این یک مشکل جالب است... آیا شما از fasthttp استفاده کرده اید؟ چه کسی از fasthttp با درخواست های POST استفاده کرد؟ احتمالاً این کار واقعاً نباید انجام می شد، زیرا به طور پیش فرض بدنه درخواست را بافر می کند و اندازه بافر ما روی 16 مگابایت تنظیم شده بود. درج در نقطه ای متوقف شد و تکه های 16 مگابایتی از همه ده ها هزار سرور شروع به دریافت کردند و همه آنها قبل از ارسال به Clickhouse در حافظه بافر شدند. بر این اساس، حافظه تمام شد، قاتل Out-Of-Memory آمد و پراکسی معکوس را کشت (یا «Clickhouse»، که از نظر تئوری می‌توانست بیشتر از پراکسی معکوس « بخورد»). چرخه دوباره تکرار شد. مشکل چندان خوشایندی نیست. اگرچه ما فقط پس از چندین ماه کار به این موضوع برخورد کردیم.

من چه کار کرده ام؟ باز هم، من واقعاً دوست ندارم بفهمم دقیقاً چه اتفاقی افتاده است. من فکر می کنم کاملاً واضح است که شما نباید در حافظه بافر شوید. من نتونستم fasthttp رو پچ کنم، هرچند سعی کردم. اما من راهی پیدا کردم که آن را طوری درست کنم که نیازی به پچ کردن چیزی نباشد و به روش خودم در HTTP رسیدم - اسمش را گذاشتم بچه گربه. خوب، منطقی است - "VK"، "Kitten"... چه چیز دیگری؟..

اگر درخواستی با روش Kitten به سرور برسد، سرور باید به صورت منطقی به "میو" پاسخ دهد. اگر او به این پاسخ دهد، در نظر گرفته می شود که او این پروتکل را درک می کند، و سپس من اتصال را قطع می کنم (fasthttp چنین روشی دارد) و اتصال به حالت "خام" می رود. چرا به آن نیاز دارم؟ من می خواهم نحوه خواندن از اتصالات TCP را کنترل کنم. TCP یک خاصیت فوق العاده دارد: اگر کسی از طرف دیگر مطالعه نمی کند، نوشتن شروع به انتظار می کند و حافظه به ویژه در این مورد صرف نمی شود.

و بنابراین من از حدود 50 مشتری در یک زمان مطالعه کردم (از پنجاه به دلیل اینکه پنجاه باید قطعاً کافی باشد، حتی اگر نرخ از DC دیگری باشد) ... مصرف با این رویکرد حداقل 20 بار کاهش یافته است، اما من صادقانه بگویم ، نمی توانم دقیقاً زمان را اندازه گیری کنم، زیرا قبلاً بی معنی است (قبلاً به سطح خطا رسیده است). پروتکل باینری است، یعنی حاوی نام جدول و داده است. هیچ هدر http وجود ندارد، بنابراین من از سوکت وب استفاده نکردم (نیازی به برقراری ارتباط با مرورگرها ندارم - پروتکلی ساختم که مطابق با نیازهای ما باشد). و همه چیز با او خوب شد.

جدول بافر غمگین است

اخیرا با یکی دیگر از ویژگی های جالب جداول بافر مواجه شدیم. و این مشکل در حال حاضر بسیار دردناک تر از دیگران است. بیایید این وضعیت را تصور کنیم: شما در حال حاضر به طور فعال از Clickhouse استفاده می کنید، ده ها سرور Clickhouse دارید، و برخی از درخواست ها را دارید که خواندن آنها زمان بسیار زیادی می برد (مثلاً بیش از 60 ثانیه). و شما بیایید و در این لحظه Alter را انجام دهید... در ضمن، "انتخاب هایی" که قبل از "Alter" شروع شده اند در این جدول گنجانده نمی شوند، "Alter" شروع نمی شود - احتمالاً برخی از ویژگی های نحوه عملکرد "Clickhouse" در این مکان. شاید بتوان این را برطرف کرد؟ یا این ممکن نیست؟

به طور کلی، واضح است که در واقعیت این مشکل چندان بزرگی نیست، اما با جداول بافر دردناک تر می شود. زیرا، اگر فرض کنیم، زمان «تغییر» شما به پایان می‌رسد (و ممکن است در میزبان دیگری به پایان برسد - برای مثال نه در میزبان شما، بلکه در یک ماکت)، پس... شما جدول بافر، «Alter» خود را حذف کرده‌اید ( یا یک میزبان دیگر) به پایان رسیده است. سپس یک خطای "تغییر" رخ داده است) - هنوز باید اطمینان حاصل کنید که داده ها همچنان نوشته می شوند: جداول بافر را به عقب می سازید (طبق طرح مشابه جدول والد)، سپس "تغییر" می رود، به پایان می رسد، و بافر جدول شروع به تفاوت در طرحواره با والد می کند. بسته به اینکه "تغییر" چه بود، ممکن است درج دیگر به این جدول بافر نرود - این بسیار غم انگیز است.

چنین علامتی نیز وجود دارد (شاید کسی متوجه آن شده باشد) - در نسخه های جدید Clickhouse به آن query_thread_log می گویند. به طور پیش فرض، در برخی از نسخه ها یکی وجود داشت. در اینجا ما 840 میلیون رکورد در چند ماه (100 گیگابایت) جمع آوری کرده ایم. این به این دلیل است که "درج" در آنجا نوشته شده است (شاید اکنون، اتفاقاً آنها نوشته نشده باشند). همانطور که به شما گفتم، "درج" ما کوچک است - ما "درج" زیادی در جداول بافر داشتیم. واضح است که این غیرفعال است - من فقط آنچه را که در سرور خود دیدم به شما می گویم. چرا؟ این یکی دیگر از استدلال های مخالف استفاده از جداول بافر است! اسپاتی بسیار غمگین است.

چه کسی می دانست که نام این پسر اسپاتی است؟ کارمندان VK دستان خود را بالا بردند. خوب.

درباره برنامه های "KitttenHouse"

برنامه ها معمولا به اشتراک گذاشته نمی شوند، درست است؟ ناگهان آنها را برآورده نخواهید کرد و در چشم دیگران خیلی خوب به نظر نخواهید رسید. اما من ریسک می کنم! ما می خواهیم کارهای زیر را انجام دهیم: به نظر من جداول بافر هنوز یک عصا هستند و ما باید خودمان بافر را درج کنیم. اما هنوز نمی‌خواهیم آن را روی دیسک بافر کنیم، بنابراین درج را در حافظه بافر می‌کنیم.

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

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

مهمترین چیز این است که در این طرح ما با اطمینان می دانیم که آیا درج انجام شده است یا خیر. این وضعیت را تصور کنید: شما یک جدول بافر دارید، چیزی در آن نوشتید، و سپس، فرض کنید، جدول به حالت فقط خواندنی رفت و سعی کرد بافر را پاک کند. داده ها کجا خواهند رفت؟ آنها در بافر باقی خواهند ماند. اما ما نمی توانیم از این مطمئن باشیم - اگر خطای دیگری وجود داشته باشد که به دلیل آن داده ها در بافر باقی نمی مانند ... (خطاب به Alexey Milovidov، Yandex، توسعه دهنده ClickHouse) یا باقی می ماند؟ همیشه؟ الکسی ما را متقاعد می کند که همه چیز خوب خواهد بود. ما دلیلی نداریم که او را باور نکنیم. اما با این حال: اگر از جداول بافر استفاده نکنیم، هیچ مشکلی با آنها وجود نخواهد داشت. ایجاد دو برابر جدول نیز ناخوشایند است، اگرچه در اصل مشکل بزرگی وجود ندارد. این طرح است.

بیایید در مورد خواندن صحبت کنیم

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

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

و به نظر بسیار شبیه به Sequel Pro است، اما فقط در بوت استرپ توییتر و نسخه دوم ساخته شده است. شما می پرسید: "یوری، چرا در نسخه دوم؟" چه سالی؟ 2018؟ به طور کلی، من این کار را خیلی وقت پیش برای "Muscle" (MySQL) انجام دادم و فقط چند خط در پرس و جوهای آنجا را تغییر دادم و برای "Clickhouse" شروع به کار کرد، که با تشکر ویژه! از آنجا که تجزیه کننده بسیار شبیه به "عضله" است، و پرس و جوها بسیار شبیه هستند - بسیار راحت، به خصوص در ابتدا.

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

یک ویرایشگر نیز وجود دارد. من صادقانه سعی کردم کل ویرایشگر را از Tabix بدزدم، اما نتوانستم. اما به نوعی کار می کند. در اصل، این همه است.

"Clickhouse" برای لانه ها مناسب است

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

TCP؟ به طور کلی، در VK مرسوم است که از UDP استفاده کنید. و وقتی از TCP استفاده کردم... البته هیچکس به من نگفت: «یوری، این چه حرفی است که میزنی! شما نمی توانید، شما به UDP نیاز دارید." معلوم شد که TCP چندان ترسناک نیست. تنها نکته این است که اگر ده ها هزار ترکیب فعال دارید که می نویسید، باید آن را کمی با دقت بیشتری تهیه کنید. اما ممکن است و بسیار آسان است.

من قول دادم که "Kittenhouse" و "Lighthouse" را در HighLoad Siberia پست کنم، اگر همه در "پشت‌اند VK" عمومی ما مشترک شوند... و می‌دانید، همه مشترک نشده‌اند... البته، من از شما درخواست نمی‌کنم که مشترک ما شوید. عمومی. هنوز تعداد شما خیلی زیاد است، حتی ممکن است کسی توهین شود، اما با این وجود، لطفا مشترک شوید (و اینجا باید چشمانم را شبیه چشمان گربه کنم). یعنی اتفاقا به آن لینک دهید. بسیار از شما متشکرم! Github مال ماست اینجا. با کلیک هاوس موهای شما نرم و ابریشمی خواهد شد.

سرب: - دوستان حالا برای سوال. بلافاصله پس از ارائه گواهی قدردانی و گزارش شما در مورد VHS.

یوری ناصردینوف (از این پس YN نامیده می شود): - اگر گزارش من در VHS به تازگی تمام شده باشد، چگونه می توانید آن را ضبط کنید؟

سرب: - شما همچنین نمی توانید به طور کامل تعیین کنید که "Clickhouse" چگونه کار می کند یا خیر! دوستان 5 دقیقه برای سوال!

پرسش

سوال از حضار (که از این پس Q نامیده می شود): - عصر بخیر. بابت گزارش خیلی ممنون دو تا سوال دارم من با یک چیز بیهوده شروع می کنم: آیا تعداد حروف t در نام "Kittenhouse" در نمودارها (3، 4، 7...) بر رضایت گربه ها تأثیر می گذارد؟

YN: - مقدار چه چیزی؟

ز: - حرف t. سه t وجود دارد، جایی حدود سه t.

YN: - درستش نکردم؟ خوب، البته که دارد! اینها محصولات متفاوتی هستند - من در تمام این مدت فقط شما را فریب می دادم. باشه، شوخی کردم - مهم نیست. آه، همین جا! نه همینه من اشتباه تایپی کردم

ز: - متشکرم. سوال دوم جدی است. تا آنجا که من متوجه شدم، در Clickhouse، جداول بافر منحصراً در حافظه زندگی می کنند، به دیسک بافر نمی شوند و بر این اساس، پایدار نیستند.

YN: - آره.

ز: - و در عین حال، مشتری شما به دیسک بافر می شود، که به نوعی تضمین کننده تحویل همین لاگ ها است. اما این به هیچ وجه در Clickhouse تضمین نشده است. توضیح دهید که ضمانت به چه دلیل انجام می شود؟.. در اینجا این مکانیسم با جزئیات بیشتر است

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

ز: – یعنی “Kittenhouse” پنجره را طولانی‌تر نگه می‌دارد و در صورت افتادن، می‌تواند آن را بشناسد و بپیچد؟

YN: - اما این در تئوری است. در عمل ما این کار را انجام نمی دهیم و تحویل قابل اطمینان از صفر تا بی نهایت بار است. اما به طور متوسط ​​یک. ما راضی هستیم که اگر Clickhouse به دلایلی از کار بیفتد یا سرورها "راه اندازی مجدد" شوند، کمی ضرر می کنیم. در همه موارد دیگر هیچ اتفاقی نمی افتد.

ز: - سلام. از همان ابتدا به نظرم رسید که شما واقعاً از همان ابتدای گزارش از UDP استفاده خواهید کرد. شما http دارید، همه اینها... و بیشتر مشکلاتی که توضیح دادید، همانطور که من متوجه شدم، ناشی از این راه حل خاص است ...

YN: – از TCP چه استفاده می کنیم؟

ز: - در اصل بله.

YN: - نه

ز: - با fasthttp بود که مشکل داشتید، با اتصال مشکل داشتید. اگر به تازگی از UDP استفاده کرده بودید، در زمان خود صرفه جویی می کردید. خوب، پیام های طولانی یا چیز دیگری مشکل دارد ...

YN: - با چی؟

ز: – با پیام های طولانی، چون ممکن است در MTU جا نیفتد، چیز دیگری... خب، ممکن است مشکلات خودشان باشد. سوال این است: چرا UDP نه؟

YN: - من معتقدم که نویسندگانی که TCP/IP را توسعه داده اند بسیار باهوش تر از من هستند و بهتر از من می دانند که چگونه بسته ها را سریالی کنند (به طوری که آنها بروند)، در عین حال پنجره ارسال را تنظیم کنند، شبکه را بیش از حد بارگذاری نکنند، در مورد آنچه که قرار است بازخورد بدهند. خوانده نمی شود، از طرف دیگر حساب نمی شود ... همه این مشکلات به نظر من در UDP وجود دارد، فقط من باید حتی بیشتر از آنچه قبلا نوشتم کد بنویسم تا خودم همان چیزی را پیاده سازی کنم و به احتمال زیاد ضعیف من حتی خیلی دوست ندارم به زبان C بنویسم، چه رسد به آنجا...

ز: - فقط راحت! ارسال شد و منتظر چیزی نباشید - کاملا ناهمزمان است. یک اعلان برگشت مبنی بر اینکه همه چیز خوب است - به این معنی است که رسیده است. اگر نیامد، یعنی بد است.

YN: – من به هر دو نیاز دارم – باید بتوانم هر دو را با ضمانت تحویل و بدون ضمانت تحویل ارسال کنم. اینها دو سناریو متفاوت هستند. من باید برخی از سیاهههای مربوط را از دست ندهم یا آنها را در حد منطق از دست ندهم.

ز: - من وقت را تلف نمی کنم. این باید بیشتر مورد بحث قرار گیرد. متشکرم.

سرب: - چه کسی سؤال دارد - دست به آسمان!

ز: - سلام من ساشا هستم. جایی در اواسط گزارش، این احساس ظاهر شد که علاوه بر TCP، می توان از یک راه حل آماده استفاده کرد - نوعی کافکا.

YN: – خب... من به شما گفتم که نمی‌خواهم از سرورهای میانی استفاده کنم، زیرا... در کافکا، معلوم می‌شود که ما ده هزار هاست داریم. در واقع، ما بیش از ده ها هزار میزبان داریم. انجام دادن با کافکا بدون هیچ پروکسی نیز می تواند دردناک باشد. علاوه بر این، مهمتر از همه، هنوز "تأخیر" می دهد، میزبان های اضافی را می دهد که شما باید داشته باشید. اما من نمی خواهم آنها را داشته باشم - من می خواهم ...

ز: اما در نهایت به هر حال اینطور شد.»

YN: - نه، میزبانی وجود ندارد! این همه در هاست های Clickhouse کار می کند.

ز: - خوب، و "Kittenhouse"، که برعکس است - او کجا زندگی می کند؟

YN: – در هاست Clickhouse چیزی روی دیسک نمی نویسد.

ز: - فرض کنیم.

سرب: - شما راضی؟ آیا می توانیم به شما حقوق بدهیم؟

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

YN: – و همچنین چرا نمی‌خواستم از کافکا استفاده کنم، زیرا در چت تلگرام کلیک‌هاوس شکایات بسیار زیادی وجود داشت که مثلاً پیام‌های کافکا گم شده بود. نه از خود کافکا، بلکه در ادغام کافکا و کلیکهاوس. یا چیزی به آنجا وصل نشده است. به طور کلی، در آن زمان لازم است برای کافکا یک مشتری بنویسیم. فکر نمی‌کنم راه‌حل ساده‌تر یا مطمئن‌تری وجود داشته باشد.

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

YN: - لطفاً پیشنهاد دهید از چه صف هایی می توان استفاده کرد؟

ز: - هر کدام، حتی بدون تضمین درست بودن آنها. نوعی Redis، RMQ...

YN: - من احساس می کنم که Redis به احتمال زیاد نمی تواند چنین حجمی از درج را حتی روی یک میزبان (به معنای چندین سرور) که Clickhouse را بیرون می آورد، بکشد. من نمی توانم این را با هیچ مدرکی تأیید کنم (من آن را محک نزده ام)، اما به نظر من Redis بهترین راه حل در اینجا نیست. در اصل، این سیستم را می توان به عنوان یک صف پیام بداهه در نظر گرفت، اما فقط برای "Clickhouse" طراحی شده است.

سرب: - یوری، خیلی ممنون. پیشنهاد می کنم سوال و جواب ها را همین جا تمام کنم و بگویم کتاب را به کدام یک از کسانی که سوال کرده اند می دهیم.

YN: - دوست دارم به اولین نفری که سوال پرسیده کتاب بدهم.

سرب: - فوق العاده! عالی! شگفت آور! خیلی ممنون!

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV از 199 دلار در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com