چگونه پایگاه های داده سری های زمانی متعدد را آزمایش کردیم

طی چند سال گذشته، پایگاه‌های داده سری زمانی از یک چیز عجیب و غریب (بسیار تخصصی که در سیستم‌های نظارت باز (و مرتبط با راه‌حل‌های خاص) یا در پروژه‌های کلان داده استفاده می‌شود) به یک «محصول مصرف‌کننده» تبدیل شده‌اند. در قلمرو فدراسیون روسیه، برای این کار باید از Yandex و ClickHouse تشکر ویژه کرد. تا این مرحله، اگر نیاز به ذخیره حجم زیادی از داده‌های سری زمانی داشتید، یا باید با نیاز به ساخت یک پشته هیولایی Hadoop و نگهداری آن کنار می‌آمدید، یا با پروتکل‌های جداگانه برای هر سیستم ارتباط برقرار می‌کردید.

ممکن است به نظر برسد که در سال 2019 مقاله ای که در مورد آن TSDB ارزش استفاده را دارد فقط از یک جمله تشکیل شده باشد: "فقط از ClickHouse استفاده کنید." اما ... تفاوت های ظریف وجود دارد.

در واقع، ClickHouse به طور فعال در حال توسعه است، پایگاه کاربران در حال رشد است، و پشتیبانی بسیار فعال است، اما آیا ما گروگان موفقیت عمومی ClickHouse شده‌ایم، که راه‌حل‌های دیگر، شاید مؤثرتر/قابل اعتمادتر را تحت الشعاع قرار داده است؟

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

بیانیه مشکل

اول از همه یک مقدمه ضروری. اصلاً چرا به سیستم نظارتی خودمان نیاز داریم و چگونه طراحی شده است؟

ما از سال 2008 شروع به ارائه خدمات پشتیبانی کردیم و تا سال 2010 مشخص شد که جمع آوری داده های مربوط به فرآیندهای رخ داده در زیرساخت مشتری با راه حل هایی که در آن زمان وجود داشت دشوار شد (ما در مورد، خدا ببخشید، Cacti، Zabbix صحبت می کنیم. و گرافیت در حال ظهور).

الزامات اصلی ما این بود:

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

در این مقاله به آخرین نکته علاقه مندیم.

در مورد ذخیره سازی، الزامات به شرح زیر بود:

• سیستم باید به سرعت کار کند.
• مطلوب است که سیستم دارای یک رابط SQL باشد.
• سیستم باید پایدار باشد و پایگاه کاربر فعال و پشتیبانی داشته باشد (زمانی که با نیاز به پشتیبانی از سیستم‌هایی مانند MemcacheDB که دیگر توسعه نیافته بود یا ذخیره‌سازی توزیع‌شده MooseFS که ردیاب اشکال آن به زبان چینی نگهداری می‌شد، مواجه شدیم: ما این داستان را برای پروژه خود تکرار نمی کنیم)
• مطابقت با قضیه CAP: ثبات (الزامی) - داده ها باید به روز باشند، ما نمی خواهیم سیستم مدیریت هشدار داده های جدید را دریافت نکند و هشدارهایی را در مورد عدم رسیدن داده ها برای همه پروژه ها منتشر کند. تحمل پارتیشن (الزامی) - ما نمی خواهیم یک سیستم Split Brain دریافت کنیم. در دسترس بودن (بسیار مهم نیست، در صورت وجود یک ماکت فعال) - ما می توانیم خودمان در صورت بروز حادثه، با استفاده از کد، به سیستم پشتیبان سوئیچ کنیم.

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

بنابراین، ما به نمونه‌ای از داده‌های دو هفته‌ای تازه، با جزئیات تا 200 میلی ثانیه قبل از ارائه کامل داده‌ها، دست یافتیم و برای مدت طولانی در این سیستم زندگی کردیم.

در همین حال زمان گذشت و حجم داده ها افزایش یافت. تا سال 2016، حجم داده ها به ده ها ترابایت رسید که هزینه قابل توجهی در زمینه ذخیره سازی اجاره ای SSD بود.

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

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

در سال 2017، در کنفرانس Percona Live در سن خوزه، توسعه دهندگان Clickhouse احتمالاً برای اولین بار خود را معرفی کردند. در نگاه اول، سیستم آماده تولید بود (خوب، Yandex.Metrica یک سیستم تولید خشن است)، پشتیبانی سریع و ساده بود، و مهمتر از همه، عملیات ساده بود. از سال 2018، ما روند انتقال را آغاز کرده ایم. اما در آن زمان، سیستم‌های TSDB «بزرگسالان» و آزمایش‌شده زیادی وجود داشت، و ما تصمیم گرفتیم زمان قابل‌توجهی را اختصاص دهیم و جایگزین‌ها را با هم مقایسه کنیم تا مطمئن شویم که طبق نیاز ما، هیچ راه‌حل جایگزینی برای Clickhouse وجود ندارد.

علاوه بر الزامات ذخیره سازی از قبل مشخص شده، موارد جدیدی نیز ظاهر شده اند:

• سیستم جدید باید حداقل عملکرد مشابه MySQL را روی همان مقدار سخت افزار ارائه دهد.
• ذخیره سازی سیستم جدید باید فضای کمتری را اشغال کند.
• مدیریت DBMS همچنان باید آسان باشد.
• من می خواستم هنگام تغییر DBMS برنامه را حداقل تغییر دهم.

چه سیستم هایی را در نظر گرفتیم؟

Apache Hive/Apache Impala
پشته Hadoop قدیمی و آزمایش شده در نبرد. در اصل، این یک رابط SQL است که بر روی ذخیره داده ها در قالب های بومی در HDFS ساخته شده است.

طرفداران

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

مضرات

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

با این حال:

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

دروید/پینو

بیشتر در مورد TSDB وجود دارد، اما باز هم پشته Hadoop.

وجود دارد مقاله عالی در مورد مقایسه مزایا و معایب Druid و Pinot در مقابل ClickHouse .

در چند کلمه: Druid/Pinot در مواردی بهتر از Clickhouse به نظر می رسند:

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

در موارد مخالف، ClickHouse بهتر عمل می کند و این مورد ماست.

کلیک هاوس

• شبیه SQL
• کارکرد آسان.
• مردم می گویند کار می کند.

برای تست در لیست نهایی قرار می گیرد.

InfluxDB

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

برای تست در لیست نهایی قرار می گیرد.

کاساندرا

از یک طرف، ما می دانیم که برای ذخیره سری های زمانی متریک توسط سیستم های نظارتی مانند، برای مثال، استفاده می شود. SignalFX یا OkMeter. با این حال، ویژگی های خاصی وجود دارد.

کاساندرا یک پایگاه داده ستونی به معنای سنتی نیست. بیشتر شبیه نمای ردیفی به نظر می رسد، اما هر خط می تواند تعداد ستون های متفاوتی داشته باشد، که سازماندهی نمای ستونی را آسان می کند. از این نظر مشخص است که با محدودیت 2 میلیارد ستون، امکان ذخیره برخی داده ها در ستون ها (و همان سری های زمانی) وجود دارد. به عنوان مثال، در MySQL محدودیت 4096 ستون وجود دارد و اگر بخواهید همین کار را انجام دهید، به راحتی می توانید با خطای کد 1117 برخورد کنید.

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

تیتان فرزند پاپتوس

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

روش و نتایج تست

بنابراین، ما 5 پایگاه داده را در 6 پیکربندی زیر آزمایش کردیم: ClickHouse (1 گره)، ClickHouse (جدول توزیع شده برای 3 گره)، InfluxDB، Mysql 8، Cassandra (3 گره) و Prometheus. طرح آزمون به شرح زیر است:

1. بارگذاری داده های تاریخی برای یک هفته (840 میلیون مقدار در روز؛ 208 هزار متریک)؛
2. ما یک بار ضبط تولید می کنیم (6 حالت بار در نظر گرفته شده است، به زیر مراجعه کنید).
3. به موازات ضبط، ما به صورت دوره‌ای انتخاب‌هایی را انجام می‌دهیم و درخواست‌های کاربری را که با نمودارها کار می‌کند شبیه‌سازی می‌کنیم. برای اینکه مسائل را خیلی پیچیده نکنیم، داده‌ها را برای 10 معیار (این دقیقاً همان تعداد موجود در نمودار CPU است) برای یک هفته انتخاب کردیم.

ما با شبیه‌سازی رفتار عامل نظارت خود بارگذاری می‌کنیم، که هر 15 ثانیه یک بار مقادیر را به هر متریک ارسال می‌کند. در عین حال، ما علاقه مند به تغییر هستیم:

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

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

همچنین، برای درک بهتر نحوه تفسیر داده‌های دریافتی، بیایید تصور کنیم که ما فقط یک دسته از معیارها را ارسال نمی‌کنیم، بلکه معیارها در سرورها سازماندهی می‌شوند - 125 معیار برای هر سرور. در اینجا سرور صرفاً یک موجودیت مجازی است - فقط برای اینکه بفهمیم، برای مثال، 10000 معیار مربوط به حدود 80 سرور است.

و در اینجا، با در نظر گرفتن همه اینها، 6 حالت بارگذاری نوشتن پایگاه داده ما وجود دارد:

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

نتایج آزمون به شرح زیر است:

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

به عنوان یک نتیجه،: ClickHouse و InfluxDB خود را بهترین نشان دادند، اما خوشه ای از Influx فقط بر اساس نسخه Enterprise ساخته می شود که هزینه دارد، در حالی که ClickHouse هیچ هزینه ای ندارد و ساخت روسیه است. منطقی است که در ایالات متحده آمریکا احتمالاً به نفع inInfluxDB است و در کشور ما به نفع ClickHouse است.

منبع: www.habr.com