HighLoad++، Andrey Gushchin (Zabbix): عملکرد بالا و پارتیشن بندی بومی

ما به نحوه کار Zabbix با پایگاه داده TimescaleDB به عنوان backend نگاه خواهیم کرد. ما به شما نشان خواهیم داد که چگونه از ابتدا شروع کنید و چگونه از PostgreSQL مهاجرت کنید. ما همچنین تست های عملکرد مقایسه ای دو پیکربندی را ارائه خواهیم داد.

HighLoad++ Siberia 2019. تالار Tomsk. 24 ژوئن، 16:00. پایان نامه ها و ارائه. کنفرانس بعدی HighLoad++ در تاریخ 6 و 7 آوریل 2020 در سن پترزبورگ برگزار خواهد شد. جزئیات و بلیط по ссылке.

آندری گوشچین (از این پس - AG): - من یک مهندس پشتیبانی فنی ZABBIX (از این پس "Zabbix" نامیده می شود)، یک مربی هستم. من بیش از 6 سال است که در پشتیبانی فنی کار می کنم و تجربه مستقیم عملکرد را داشته ام. امروز در مورد عملکرد TimescaleDB در مقایسه با PostgreSQL 10 معمولی صحبت خواهم کرد. همچنین، بخشی مقدماتی در مورد نحوه عملکرد آن به طور کلی.

چالش های برتر بهره وری: از جمع آوری داده ها تا پاکسازی داده ها

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

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

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

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

چگونه مشکلات کش را حل کنیم؟

اکنون به طور خاص در مورد Zabbix صحبت خواهم کرد. در Zabbix تماس اول و دوم با استفاده از کش حل می شود.

جمع آوری و پردازش داده ها - ما از RAM برای ذخیره همه این داده ها استفاده می کنیم. این داده ها اکنون با جزئیات بیشتری مورد بحث قرار خواهند گرفت.

همچنین در سمت پایگاه داده مقداری ذخیره برای انتخاب های اصلی وجود دارد - برای نمودارها و موارد دیگر.

ذخیره سازی در کنار خود سرور Zabbix: ما ConfigurationCache، ValueCache، HistoryCache، TrendsCache را داریم. آن چیست؟

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

ذخیره در Zabbix. جمع آوری داده ها

در اینجا نمودار بسیار بزرگ است:

موارد اصلی در طرح این مجموعه ها هستند:

اینها خود فرآیندهای مونتاژ هستند، "رای دهندگان" مختلفی که مسئول انواع مختلف مجموعه ها هستند. آنها داده ها را از طریق icmp، ipmi و پروتکل های مختلف جمع آوری می کنند و همه آنها را به پیش پردازش منتقل می کنند.

پیش پردازش History Cache

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

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

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

کار همگام سازی تاریخ

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

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

پایگاه داده. ذخیره سازی

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

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

• shared_buffers;
• effect_cache_size;
• shared_pool.

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

درباره عملکرد پایگاه داده

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

همچنین یک راه حل تجسم بسیار محبوب Grafana است که کاربران ما از آن استفاده می کنند. امکان ورود مستقیم هم از طریق Zabbix API و هم از طریق پایگاه داده. همچنین رقابت خاصی برای به دست آوردن داده ها ایجاد می کند: تنظیم دقیق تر و بهتر پایگاه داده برای مطابقت با تحویل سریع نتایج و آزمایش لازم است.

پاک کردن تاریخچه Zabbix خانه دار دارد

سومین فراخوانی که در Zabbix استفاده می شود، پاک کردن تاریخچه با استفاده از Housekeeper است. Housekeeper تمام تنظیمات را دنبال می کند، یعنی عناصر داده ما نشان می دهد که چه مدت (در روز)، چه مدت برای ذخیره روندها، و پویایی تغییرات.

من در مورد TrendCache صحبت نکردم، که ما آن را در پرواز محاسبه می کنیم: داده ها می رسد، ما آنها را برای یک ساعت جمع می کنیم (عمدتاً اینها اعداد مربوط به ساعت گذشته هستند)، مقدار متوسط ​​/ حداقل است و ما آن را یک بار در ساعت ثبت می کنیم. جدول پویایی تغییرات ("روندها"). "Housekeeper" داده ها را با استفاده از انتخاب های معمولی از پایگاه داده شروع و حذف می کند، که همیشه موثر نیست.

چگونه بفهمیم که بی اثر است؟ می توانید تصویر زیر را در نمودارهای عملکرد فرآیندهای داخلی مشاهده کنید:

همگام‌کننده تاریخچه شما دائماً مشغول است (گراف قرمز). و نمودار "قرمز" که در بالا قرار دارد. این یک "Housekeeper" است که شروع می شود و منتظر می ماند تا پایگاه داده تمام ردیف هایی را که مشخص کرده است حذف کند.

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

می توانید Housekeeper را به روشی ساده غیرفعال کنید - ما یک رابط وب آشنا داریم. تنظیمات در مدیریت عمومی (تنظیمات "Houskeeper") ما خانه داری داخلی را برای تاریخچه و روند داخلی غیرفعال می کنیم. بر این اساس، Housekeeper دیگر این موارد را کنترل نمی کند:

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

پارتیشن بندی (بخش بندی)

معمولاً در هر پایگاه داده رابطه‌ای که من فهرست کرده‌ام، این به روشی متفاوت پیکربندی می‌شود. MySQL تکنولوژی خاص خود را دارد. اما در مجموع وقتی صحبت از PostgreSQL 10 و MySQL به میان می آید بسیار شبیه هستند. البته، تفاوت‌های داخلی زیادی در نحوه پیاده‌سازی آن‌ها و تأثیر همه آن‌ها بر عملکرد وجود دارد. اما به طور کلی، ایجاد یک پارتیشن جدید اغلب به مشکلات خاصی نیز منجر می شود.

بسته به تنظیمات شما (میزان داده ای که در یک روز ایجاد می کنید)، آنها معمولا حداقل را تعیین می کنند - این 1 روز / دسته است، و برای "روندها"، پویایی تغییرات - 1 ماه / دسته جدید. اگر تنظیمات بسیار بزرگی دارید، ممکن است تغییر کند.

بیایید فوراً در مورد اندازه تنظیم بگوییم: حداکثر 5 هزار مقدار جدید در ثانیه (به اصطلاح nvps) - این یک "راه اندازی" کوچک در نظر گرفته می شود. میانگین - از 5 تا 25 هزار مقدار در ثانیه. تمام آنچه در بالا ذکر شده است در حال حاضر نصب های بزرگ و بسیار بزرگی است که به پیکربندی بسیار دقیق پایگاه داده نیاز دارد.

در تاسیسات بسیار بزرگ، 1 روز ممکن است مطلوب نباشد. من شخصاً در MySQL پارتیشن هایی با حجم 40 گیگابایت در روز دیده ام (و ممکن است بیشتر باشد). این حجم بسیار زیادی از داده است که می تواند منجر به برخی مشکلات شود. باید کاهش یابد.

چرا به پارتیشن بندی نیاز دارید؟

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

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

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

Elastics برای NoSQL جستجو کنید

اخیراً در نسخه 3.4 ما یک راه حل NoSQL را پیاده سازی کردیم. قابلیت نوشتن در Elasticsearch اضافه شده است. شما می توانید انواع خاصی را بنویسید: شما انتخاب می کنید - یا اعداد بنویسید یا چند علامت. ما متن رشته ای داریم، شما می توانید گزارش ها را در Elasticsearch بنویسید... بر این اساس، رابط وب نیز به Elasticsearch دسترسی خواهد داشت. این در برخی موارد عالی عمل می کند، اما در حال حاضر می توان از آن استفاده کرد.

TimescaleDB. هایپر جدول ها

برای 4.4.2 ما به یک چیز مانند TimescaleDB توجه کردیم. آن چیست؟ این یک افزونه برای PostgreSQL است، یعنی دارای یک رابط بومی PostgreSQL است. به علاوه، این برنامه افزودنی به شما امکان می دهد با داده های سری زمانی کارآمدتر کار کنید و پارتیشن بندی خودکار داشته باشید. به نظر می رسد:

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

TimescaleDB و PostgreSQL

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

چگونه TimescaleDB را نصب کنیم؟ ساده است!

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

در Zabbix ما به سادگی Extention را فعال می کنیم. من فکر می کنم کسانی که از Extention در Postgres استفاده کردند ... شما به سادگی Extention را فعال کنید، آن را برای پایگاه داده Zabbix که استفاده می کنید ایجاد کنید.

و آخرین مرحله...

TimescaleDB. مهاجرت جداول تاریخ

شما باید یک جدول فوق العاده ایجاد کنید. یک عملکرد ویژه برای این وجود دارد - ایجاد hypertable. در آن، اولین پارامتر جدولی است که در این پایگاه داده مورد نیاز است (که برای آن باید یک hypertable ایجاد کنید).

فیلدی که توسط آن ایجاد می شود، و chunk_time_interval (این فاصله ی تیکه ها (پارتیشن هایی که باید استفاده شوند) است. 86 یک روز است.

پارامتر Migrate_data: اگر مقدار true را وارد کنید، تمام داده های فعلی را به تکه های از پیش ساخته شده منتقل می کند.

من خودم از migrate_data استفاده کرده‌ام - بسته به اینکه پایگاه داده شما چقدر بزرگ است، زمان زیادی می‌برد. من بیش از یک ترابایت داشتم - بیش از یک ساعت طول کشید تا ایجاد شود. در برخی موارد، در حین آزمایش، داده های تاریخی متن (history_text) و رشته (history_str) را حذف کردم تا آنها را منتقل نکنم - آنها واقعاً برای من جالب نبودند.

و ما آخرین به روز رسانی را در db_extention خود انجام می دهیم: timescaledb را نصب می کنیم تا پایگاه داده و به ویژه Zabbix ما بفهمند که db_extination وجود دارد. او آن را فعال می کند و از نحو و پرس و جوهای صحیح برای پایگاه داده استفاده می کند، با استفاده از «ویژگی هایی» که برای TimescaleDB ضروری هستند.

پیکربندی سرور

من از دو سرور استفاده کردم. سرور اول یک ماشین مجازی نسبتا کوچک، 20 پردازنده، 16 گیگابایت رم است. من Postgres 10.8 را روی آن پیکربندی کردم:

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

من از 50 عامل فعال استفاده کرده ام که از LoadableModule برای تولید سریع نتایج مختلف استفاده می کنند. آنها کسانی هستند که رشته ها، اعداد و غیره را تولید کردند. من پایگاه داده را با داده های زیادی پر کردم. در ابتدا، پیکربندی شامل 5 هزار عنصر داده در هر میزبان بود، و تقریباً هر عنصر داده حاوی یک ماشه - برای اینکه این یک تنظیم واقعی باشد. گاهی حتی برای استفاده به بیش از یک ماشه نیاز دارید.

من نه تنها با استفاده از 50 عامل (اضافه کردن بیشتر)، بلکه با استفاده از عناصر داده پویا و کاهش فاصله به روز رسانی به 4 ثانیه، فاصله به روز رسانی و خود بار را تنظیم کردم.

آزمون عملکرد. PostgreSQL: 36 هزار NVP

اولین راه اندازی، اولین راه اندازی که داشتم روی PostreSQL 10 خالص روی این سخت افزار بود (35 هزار مقدار در ثانیه). به طور کلی، همانطور که روی صفحه می بینید، قرار دادن داده ها کسری از ثانیه طول می کشد - همه چیز خوب و سریع است، درایوهای SSD (200 گیگابایت). تنها چیزی که وجود دارد این است که 20 گیگابایت خیلی سریع پر می شود.

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

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

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

آزمون عملکرد. PostgreSQL: 50 هزار NVP

در مرحله بعد، بار را روی همان سخت افزار به 50 هزار مقدار در ثانیه افزایش دادم. هنگام بارگذاری توسط Housekeeper، 10 هزار مقدار در 2-3 ثانیه با محاسبه ثبت شد. آنچه در واقع در تصویر زیر نشان داده شده است:

"خانه دار" در حال حاضر شروع به تداخل در کار کرده است، اما به طور کلی، بار روی تله گذاران تاریخچه هنوز در سطح 60٪ است (نمودار سوم، بالا سمت راست). HistoryCache از قبل شروع به پر شدن فعال در حین اجرای Housekeeper می کند (پایین سمت چپ). حدود نیم گیگ بود، 20 درصد پر بود.

آزمون عملکرد. PostgreSQL: 80 هزار NVP

سپس آن را به 80 هزار مقدار در ثانیه افزایش دادم:

تقریباً 400 هزار عنصر داده، 280 هزار محرک بود. درج، همانطور که می بینید، از نظر بار سینکرهای تاریخ (30 نفر از آنها وجود داشت) قبلاً بسیار زیاد بود. سپس پارامترهای مختلفی را افزایش دادم: تاریخچه سینکرها، حافظه نهان... در این سخت افزار، بار روی سینکورهای تاریخ شروع به افزایش به حداکثر کرد، تقریباً "در قفسه" - بر این اساس، HistoryCache وارد بار بسیار بالایی شد:

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

من سرور دیگری گرفتم که قبلاً 48 پردازنده و 128 گیگابایت رم داشت:

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

آزمون عملکرد. TimescaleDB: 80 هزار NVP

وظیفه اصلی من استفاده از TimescaleDB بود. هر نمودار یک شیب را نشان می دهد:

این خرابی ها دقیقاً انتقال داده ها هستند. پس از آن، در سرور Zabbix، پروفایل بارگذاری سینکورهای تاریخ، همانطور که می بینید، تغییرات زیادی کرد. این به شما امکان می دهد تقریباً 3 برابر سریعتر داده ها را وارد کنید و از HistoryCache کمتری استفاده کنید - بر این اساس، داده ها را به موقع تحویل خواهید داد. باز هم ، 80 هزار مقدار در ثانیه یک نرخ نسبتاً بالا است (البته برای Yandex نیست). به طور کلی این یک راه اندازی نسبتا بزرگ است، با یک سرور.

تست عملکرد PostgreSQL: 120 هزار NVP

در مرحله بعد، مقدار تعداد عناصر داده را به نیم میلیون افزایش دادم و مقدار محاسبه شده 125 هزار در ثانیه را دریافت کردم:

و من این نمودارها را گرفتم:

در اصل، این یک راه اندازی کار است، می تواند برای مدت طولانی کار کند. اما از آنجایی که من فقط یک دیسک 1,5 ترابایتی داشتم، در عرض چند روز از آن استفاده کردم. مهمترین چیز این است که در همان زمان پارتیشن های جدیدی در TimescaleDB ایجاد شد و این برای عملکرد کاملاً مورد توجه قرار نگرفت که در مورد MySQL نمی توان گفت.

به طور معمول، پارتیشن ها در شب ایجاد می شوند، زیرا این کار معمولاً درج و کار با جداول را مسدود می کند و می تواند منجر به تخریب سرویس شود. در این مورد اینطور نیست! وظیفه اصلی آزمایش قابلیت های TimescaleDB بود. نتیجه رقم زیر بود: 120 هزار مقدار در ثانیه.

نمونه هایی نیز در جامعه وجود دارد:

شخص همچنین TimescaleDB را روشن کرد و بار استفاده از io.weight روی پردازنده کاهش یافت. و استفاده از عناصر فرآیند داخلی نیز به دلیل گنجاندن TimescaleDB کاهش یافته است. علاوه بر این، این ها دیسک های پنکیک معمولی هستند، یعنی یک ماشین مجازی معمولی روی دیسک های معمولی (نه SSD)!

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

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

سوالات مخاطبان

سوال مخاطبان (از این پس - الف): - اگر پیکربندی TimescaleDB بسیار آسان است و چنین عملکردی را تقویت می کند، شاید باید از این به عنوان بهترین تمرین برای پیکربندی Zabbix با Postgres استفاده کرد؟ و آیا این راه حل اشکالات و معایبی دارد یا بالاخره اگر تصمیم گرفتم Zabbix را برای خودم بسازم، می توانم به راحتی Postgres را بگیرم، فوراً Timescale را در آنجا نصب کنم، از آن استفاده کنم و به هیچ مشکلی فکر نکنم؟

AG: - بله، من می گویم که این یک توصیه خوب است: بلافاصله از Postgres با پسوند TimescaleDB استفاده کنید. همانطور که قبلاً گفتم، با وجود اینکه این "ویژگی" آزمایشی است، بسیاری از بررسی های خوب هستند. اما در واقع آزمایشات نشان می دهد که این یک راه حل عالی است (با TimescaleDB) و من فکر می کنم که تکامل خواهد یافت! ما در حال نظارت بر نحوه توسعه این افزونه هستیم و در صورت لزوم تغییراتی را اعمال خواهیم کرد.

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

پاسخ: - در آخرین نمودارهای جامعه، نموداری با "خانه دار" وجود داشت:

به کارش ادامه داد. Housekeeper با TimescaleDB چه می کند؟

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

پاسخ: - من یک سوال مشابه دارم - در مورد عملکرد عملیات حذف در Timescale.
پاسخ (پاسخ از طرف مخاطب): – وقتی داده‌ها را از جدول حذف می‌کنید، اگر این کار را از طریق حذف انجام می‌دهید، باید از جدول عبور کنید - حذف کنید، تمیز کنید، همه چیز را برای خلاء آینده علامت‌گذاری کنید. در Timescale، از آنجایی که شما تکه هایی دارید، می توانید رها کنید. به طور کلی، شما به سادگی به فایلی که در داده های بزرگ است می گویید: "حذف!"

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

پاسخ: - ما قبلاً به موضوع غیر SQL پرداخته ایم. تا آنجا که من متوجه شدم، Zabbix واقعاً نیازی به تغییر داده ها ندارد و همه اینها چیزی شبیه یک گزارش است. آیا می توان از پایگاه های داده تخصصی استفاده کرد که نتوانند داده های خود را تغییر دهند، اما در عین حال بسیار سریعتر ذخیره، انباشته و توزیع شوند - مثلا کلیک هاوس، چیزی شبیه به کافکا؟.. کافکا هم یک لاگ است! آیا امکان ادغام آنها وجود دارد؟

AG: - تخلیه قابل انجام است. ما از نسخه 3.4 "ویژگی" خاصی داریم: شما می توانید تمام فایل های تاریخی، رویدادها، هر چیز دیگری را در فایل ها بنویسید. و سپس آن را با استفاده از کنترلر به هر پایگاه داده دیگری ارسال کنید. در واقع، بسیاری از افراد دوباره کار می کنند و مستقیماً در پایگاه داده می نویسند. در حال پرواز، سینکرهای تاریخ همه اینها را در فایل‌ها می‌نویسند، این فایل‌ها را می‌چرخانند و غیره، و شما می‌توانید آن را به Clickhouse انتقال دهید. من نمی توانم در مورد برنامه ها بگویم، اما شاید پشتیبانی بیشتر از راه حل های NoSQL (مانند Clickhouse) ادامه یابد.

پاسخ: - به طور کلی، معلوم می شود که می توانید به طور کامل از شر پست گرس خلاص شوید؟

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

پاسخ: – آیا می توانید تخمین بزنید که اگر مثلاً به کلیک هاوس تغییر دهید، همه چیز چقدر سریعتر کار می کند؟

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

پاسخ: - پس ما در مورد مبارزه برابر صحبت می کنیم، و نه در مورد مزیت بزرگ این پایگاه داده های سریع؟

AG: - فکر می کنم وقتی ادغام می شویم، آزمایش های دقیق تری وجود خواهد داشت.

پاسخ: - RRD خوب قدیمی کجا رفت؟ چه چیزی باعث شد به پایگاه داده های SQL بروید؟ در ابتدا، تمام معیارها در RRD جمع آوری شد.

AG: - Zabbix دارای RRD بود، شاید در یک نسخه بسیار قدیمی. همیشه پایگاه داده های SQL وجود داشته است - یک رویکرد کلاسیک. رویکرد کلاسیک MySQL، PostgreSQL است (آنها برای مدت طولانی وجود داشته اند). ما تقریباً هرگز از یک رابط مشترک برای پایگاه داده های SQL و RRD استفاده نکردیم.

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر 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