HighLoad++, Андреј Гушчин (Zabbix): високи перформанси и мајчин партиционирање

Ќе погледнеме како Zabbix работи со базата на податоци TimescaleDB како заднина. Ќе ви покажеме како да започнете од нула и како да мигрирате од PostgreSQL. Ќе обезбедиме и компаративни тестови за перформанси на двете конфигурации.

HighLoad++ Сибир 2019. Сала Томск. 24 јуни, 16:00 часот. Тези и презентација. Следната конференција HighLoad++ ќе се одржи на 6 и 7 април 2020 година во Санкт Петербург. Детали и билети по ссылке.

Андреј Гушчин (во натамошниот текст – А.Г.): – Јас сум инженер за техничка поддршка на ZABBIX (во натамошниот текст „Zabbix“), тренер. Работам во техничка поддршка повеќе од 6 години и имам директно искуство со перформанси. Денес ќе зборувам за перформансите што TimescaleDB може да ги обезбеди во споредба со обичните PostgreSQL 10. Исто така, воведен дел за тоа како функционира воопшто.

Врвни предизвици за продуктивноста: од собирање податоци до чистење на податоците

За почеток, постојат одредени предизвици за изведба со кои се соочува секој систем за следење. Првиот предизвик за продуктивноста е брзо собирање и обработка на податоци.

Еден добар систем за следење треба брзо, навремено да ги прима сите податоци, да ги обработува според изразите на активирањето, односно да ги обработува според некои критериуми (ова е различно во различни системи) и да го зачува во база на податоци за да ги користи овие податоци во иднината.

Вториот предизвик за изведба е складирањето на историјата. Чувајте често во базата на податоци и имајте брз и лесен пристап до овие метрики кои беа собрани во одреден временски период. Најважно е дека овие податоци се погодни за добивање, користете ги во извештаи, графикони, предизвикувачи, во некои вредности на прагови, за предупредувања итн.

Третиот предизвик за изведба е расчистување на историјата, односно кога ќе дојдете до точка каде што не треба да складирате никакви детални метрики што биле собрани во текот на 5 години (дури и месеци или два месеци). Некои мрежни јазли беа избришани, или некои хостови, метриката повеќе не е потребна затоа што тие се веќе застарени и повеќе не се собрани. Сето ова треба да се исчисти за вашата база на податоци да не расте премногу. Општо земено, расчистувањето на историјата е најчесто сериозен тест за складирањето - честопати во голема мера влијае на перформансите.

Како да се решат проблемите со кеширање?

Сега ќе зборувам конкретно за Zabbix. Во Zabbix, првиот и вториот повик се решаваат со кеширање.

Собирање и обработка на податоци - Ние користиме RAM за складирање на сите овие податоци. Овие податоци сега ќе се дискутираат подетално.

Исто така, на страната на базата на податоци има одредено кеширање за главните селекции - за графикони и други работи.

Кеширање на страната на самиот сервер Zabbix: имаме ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Што е тоа?

ConfigurationCache е главниот кеш во кој складираме метрика, хостови, податочни ставки, предизвикувачи; сè што ви треба за обработка на претходна обработка, собирање податоци, од кои хостови да собирате, со која фреквенција. Сето ова е зачувано во ConfigurationCache за да не оди во базата на податоци и да не се создаваат непотребни прашања. Откако ќе започне серверот, го ажурираме овој кеш (го создаваме) и периодично го ажурираме (во зависност од поставките за конфигурација).

Кеширање во Zabbix. Собирање на податоци

Овде дијаграмот е доста голем:

Главните во шемата се овие колекционери:

Тоа се самите процеси на склопување, разни „полери“ кои се одговорни за различни типови склопови. Тие собираат податоци преку icmp, ipmi и разни протоколи и сето тоа го пренесуваат на претходна обработка.

Preprocessing HistoryCache

Исто така, ако имаме пресметани податочни елементи (знаат оние што се запознаени со Zabbix), односно пресметани, агрегациони податоци, ги земаме директно од ValueCache. Подоцна ќе ви кажам како се полни. Сите овие собирачи го користат ConfigurationCache за да ги добијат своите работни места и потоа да ги пренесат на претпроцесирање.

Претпроцесирањето исто така користи ConfigurationCache за да добие чекори за претпроцесирање и ги обработува овие податоци на различни начини. Почнувајќи од верзијата 4.2, ја префрливме на прокси. Ова е многу погодно, бидејќи самата преработка е прилично тешка операција. И ако имате многу голем Zabbix, со голем број на податоци и висока фреквенција на собирање, тогаш ова во голема мера ја поедноставува работата.

Според тоа, откако ќе ги обработиме овие податоци на некој начин користејќи претпроцесирање, ги зачувуваме во HistoryCache за да ги обработиме понатаму. Ова го завршува собирањето податоци. Продолжуваме кон главниот процес.

Работа на синхронизацијата на историјата

Главниот процес во Zabbix (бидејќи е монолитна архитектура) е History syncer. Ова е главниот процес кој конкретно се занимава со атомска обработка на секој податочен елемент, односно секоја вредност:

• вредноста доаѓа (ја зема од HistoryCache);
• проверува во Configuration syncer: дали има некои предизвикувачи за пресметка - ги пресметува;
  ако има - создава настани, создава ескалација со цел да се создаде предупредување, доколку е потребно според конфигурацијата;
• евидентира предизвикувачи за последователна обработка, агрегација; ако се соберат во текот на последниот час и така натаму, оваа вредност се памети од ValueCache за да не оди на табелата за историја; Така, ValueCache се полни со потребните податоци кои се неопходни за пресметување на предизвикувачи, пресметани елементи итн.;
• потоа History syncer ги запишува сите податоци во базата на податоци;
• базата на податоци ги запишува на дискот - тука завршува процесот на обработка.

База на податоци. Кеширање

На страната на базата на податоци, кога сакате да гледате графикони или некои извештаи за настани, има различни кешови. Но, во овој извештај нема да зборувам за нив.

За MySQL постои Innodb_buffer_pool и еден куп различни кешови кои исто така може да се конфигурираат.
Но, ова се главните:

• shared_buffers;
• ефективна_големина на кешот;
• shared_pool.

За сите бази на податоци, реков дека има одредени кешови кои ви дозволуваат да ги зачувате во RAM податоците кои често се потребни за прашања. Тие имаат свои технологии за ова.

За перформансите на базата на податоци

Според тоа, постои конкурентна средина, односно серверот Zabbix собира податоци и ги снима. Кога се рестартира, исто така чита од историјата за да се пополни ValueCache и така натаму. Овде можете да имате скрипти и извештаи кои користат Zabbix API, кој е изграден на веб-интерфејс. Zabbix API влегува во базата на податоци и ги добива потребните податоци за да добие графикони, извештаи или некој вид листа на настани, неодамнешни проблеми.

Исто така многу популарно решение за визуелизација е Графана, кое го користат нашите корисници. Можност за директно најавување и преку Zabbix API и преку базата на податоци. Тоа, исто така, создава одредена конкуренција за добивање податоци: потребно е пофино, подобро прилагодување на базата на податоци за да се усогласи со брзото доставување на резултатите и тестирањето.

Чистење на историјата. Забикс има домаќинка

Третиот повик што се користи во Zabbix е чистење на историјата со помош на Housekeeper. Housekeeper ги следи сите поставки, односно, нашите податочни елементи покажуваат колку долго да се складираат (во денови), колку долго да се складираат трендовите и динамиката на промените.

Не зборував за TrendCache, кој го пресметуваме на лето: податоците пристигнуваат, ги собираме за еден час (најчесто тоа се бројки за последниот час), износот е просечна/минимум и го снимаме еднаш на час во табела на динамиката на промените („Трендови“) . „Housekeeper“ започнува и брише податоци од базата со користење на редовни избирања, што не е секогаш ефективно.

Како да се разбере дека е неефективен? Можете да ја видите следната слика на графиконите за изведба на внатрешните процеси:

Вашиот синхронизатор за историја е постојано зафатен (црвен графикон). И „црвениот“ графикон што оди на врвот. Ова е „Houskeeper“ кој започнува и чека базата на податоци да ги избрише сите редови што ги навела.

Ајде да земеме ID на ставка: треба да ги избришете последните 5 илјади; се разбира, по индекси. Но, обично сетот на податоци е доста голем - базата на податоци сè уште ја чита од дискот и ја става во кешот, и ова е многу скапа операција за базата на податоци. Во зависност од нејзината големина, ова може да доведе до одредени проблеми со изведбата.

Можете да го оневозможите Housekeeper на едноставен начин - имаме познат веб-интерфејс. Поставки во Администрација општо (поставки за „Домаќин“) го оневозможуваме внатрешното домаќинство за внатрешна историја и трендови. Според тоа, Housekeeper повеќе не го контролира ова:

Што можете да направите следно? Го исклучивте, вашите графикони се израмнија... Какви дополнителни проблеми би можеле да настанат во овој случај? Што може да помогне?

Поделба (секција)

Обично ова е конфигурирано на различен начин на секоја релациона база на податоци што ја наведов. MySQL има своја технологија. Но, генерално тие се многу слични кога станува збор за PostgreSQL 10 и MySQL. Се разбира, има многу внатрешни разлики во тоа како сето тоа се спроведува и како сето тоа влијае на перформансите. Но, генерално, создавањето на нова партиција честопати исто така доведува до одредени проблеми.

Во зависност од вашето поставување (колку податоци создавате за еден ден), тие обично го поставуваат минимумот - ова е 1 ден / серија, а за „трендови“, динамика на промени - 1 месец / нова серија. Ова може да се промени ако имате многу големо поставување.

Веднаш да кажеме за големината на поставувањето: до 5 илјади нови вредности во секунда (т.н. nvps) - ова ќе се смета за мало „поставување“. Просек - од 5 до 25 илјади вредности во секунда. Сè што е погоре е веќе големи и многу големи инсталации кои бараат многу внимателна конфигурација на базата на податоци.

На многу големи инсталации, 1 ден можеби не е оптимален. Јас лично сум видел партиции на MySQL од 40 гигабајти дневно (а може да има и повеќе). Ова е многу голема количина на податоци, што може да доведе до некои проблеми. Треба да се намали.

Зошто ви е потребна партиција?

Она што го обезбедува партиционирањето, мислам дека сите го знаат, е партиционирање на табели. Честопати ова се посебни датотеки на диск и барања за распон. Пооптимално избира една партиција ако е дел од нормална партиција.

За Zabbix, особено, се користи по опсег, по опсег, односно користиме временски печат (редовен број, време од почетокот на епохата). Го одредувате почетокот на денот/крајот на денот, а ова е партицијата. Според тоа, ако барате податоци стари два дена, сè се вади од базата на податоци побрзо, бидејќи треба само да вчитате една датотека во кешот и да ја вратите (а не голема табела).

Многу бази на податоци исто така го забрзуваат вметнувањето (вметнување во една детска табела). Засега зборувам апстрактно, но и ова е можно. Поделбата често помага.

Elasticsearch за NoSQL

Неодамна, во 3.4, имплементиравме NoSQL решение. Додадена е способност за пишување во Elasticsearch. Можете да напишете одредени типови: вие избирате - или пишувајте броеви или некои знаци; имаме текст на низа, можете да пишувате дневници на Elasticsearch... Според тоа, веб-интерфејсот исто така ќе пристапи до Elasticsearch. Ова функционира одлично во некои случаи, но во моментот може да се користи.

TimescaleDB. Хипертабели

За 4.4.2 обрнавме внимание на една работа како TimescaleDB. Што е тоа? Ова е екстензија за PostgreSQL, односно има мајчин PostgreSQL интерфејс. Плус, оваа екстензија ви овозможува да работите многу поефикасно со податоците од временските серии и да имате автоматско партиционирање. Како изгледа:

Ова е хипертабела - постои таков концепт во Timescale. Ова е хипертабела што ја креирате и содржи делови. Парчињата се партиции, тоа се детски табели, ако не се лажам. Тоа е навистина ефикасно.

TimescaleDB и PostgreSQL

Како што уверуваат производителите на TimescaleDB, тие користат поправилен алгоритам за обработка на прашања, особено инсерти, што им овозможува да имаат приближно постојани перформанси со зголемување на големината на вметнувањето на базата на податоци. Односно, по 200 милиони редови на Postgres, вообичаениот почнува многу да попушта и ги губи перформансите буквално на нула, додека Timescale ви овозможува да вметнете инсерти што е можно поефикасно со која било количина на податоци.

Како да инсталирате TimescaleDB? Едноставно е!

Тоа е во документацијата, опишано е - можете да го инсталирате од пакети за кој било... Зависи од официјалните пакети на Postgres. Може да се состави рачно. Така се случи да морам да компајлирам за базата на податоци.

На Zabbix едноставно го активираме Extention. Мислам дека тие што користеле Extention во Postgres... Едноставно го активирате Extention, го креирате за Zabbix базата на податоци што ја користите.

И последниот чекор...

TimescaleDB. Миграција на табели за историја

Треба да креирате хипертабела. Постои посебна функција за ова - Креирај хипертабела. Во него, првиот параметар е табелата што е потребна во оваа база на податоци (за која треба да креирате хипертабела).

Полето според кое се креира и chunk_time_interval (ова е интервалот на парчиња (партиции што треба да се користат). 86 е еден ден.

Параметар Migrate_data: Ако вметнете во точно, тогаш ова ќе ги мигрира сите тековни податоци на претходно креирани делови.

Јас самиот користев migrate_data - потребно е прилично време, во зависност од тоа колку е голема вашата база на податоци. Имав повеќе од терабајт - ми требаше повеќе од еден час за да се создаде. Во некои случаи, за време на тестирањето, избришав историски податоци за текст (history_text) и стринг (history_str) за да не ги префрлам - тие навистина не ми беа интересни.

И ние го правиме последното ажурирање во нашето db_extention: инсталираме timescaledb така што базата на податоци и, особено, нашиот Zabbix да разберат дека има db_extention. Тој го активира и користи правилна синтакса и прашања во базата на податоци, користејќи ги оние „функции“ кои се неопходни за TimescaleDB.

Конфигурација на серверот

Јас користев два сервери. Првиот сервер е прилично мала виртуелна машина, 20 процесори, 16 гигабајти RAM меморија. Го конфигурирав Postgres 10.8 на него:

Оперативниот систем беше Debian, датотечен систем беше xfs. Направив минимални поставки за користење на оваа конкретна база на податоци, минус она што самиот Zabbix ќе го користи. На истата машина имаше сервер Zabbix, PostgreSQL и агенти за вчитување.

Јас користев 50 активни агенти кои користат LoadableModule за брзо генерирање различни резултати. Тие се оние кои ги генерираат низите, броевите итн. Ја пополнив базата со многу податоци. Првично, конфигурацијата содржеше 5 илјади податочни елементи по домаќин, а приближно секој податочен елемент содржеше активирач - со цел ова да биде вистинско поставување. Понекогаш дури ви требаат повеќе од еден активирач за користење.

Го регулирав интервалот за ажурирање и самото оптоварување не само со користење на 50 агенти (додавање повеќе), туку и со користење на динамични податочни елементи и намалување на интервалот за ажурирање на 4 секунди.

Тест за изведба. PostgreSQL: 36 илјади NVP

Првото лансирање, првото поставување што го имав беше на чист PostreSQL 10 на овој хардвер (35 илјади вредности во секунда). Во принцип, како што можете да видите на екранот, вметнувањето податоци трае делови од секунда - сè е добро и брзо, SSD дискови (200 гигабајти). Единственото нешто е што 20 GB се полнат доста брзо.

Во иднина ќе има доста такви графикони. Ова е стандардна табла за перформанси на серверот 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 гигабајти RAM:

Исто така го „наштимав“ - инсталирав History syncer (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, според мене, е многу добро решение. Тоа ќе ви овозможи да продолжите да работите пред да мигрирате на побрз хардвер за базата на податоци.

Ве поканувам сите на нашите настани: Конференција во Москва, Самит во Рига. Користете ги нашите канали - Телеграма, форум, IRC. Ако имате какви било прашања, дојдете на нашето биро, можеме да разговараме за сè.

Прашања на публиката

Прашање од публиката (во натамошниот текст - А): - Ако TimescaleDB е толку лесно да се конфигурира, и дава таков поттик на перформансите, тогаш можеби ова треба да се користи како најдобра практика за конфигурирање на Zabbix со Postgres? И дали има некои замки и недостатоци на ова решение, или на крајот на краиштата, ако решив да направам Zabbix за себе, можам лесно да го земам Postgres, веднаш да инсталирам Timescale таму, да го користам и да не размислувам за никакви проблеми?

АГ: – Да, би рекол дека ова е добра препорака: веднаш користете го Postgres со екстензијата TimescaleDB. Како што веќе реков, многу добри критики, и покрај фактот дека оваа „функција“ е експериментална. Но, всушност тестовите покажуваат дека ова е одлично решение (со TimescaleDB) и мислам дека ќе се развива! Следиме како се развива оваа екстензија и ќе направиме промени по потреба.

Дури и за време на развојот, се потпиравме на една од нивните добро познати „карактеристики“: беше можно да се работи со парчиња малку поинаку. Но, тогаш тие го прекинаа во следното издание и моравме да престанеме да се потпираме на овој код. Јас би препорачал да го користите ова решение на многу поставки. Ако користите MySQL... За просечни поставки, секое решение функционира добро.

О: – На последните графикони од заедницата имаше графикон со „Домаќин“:

Тој продолжи да работи. Што прави Housekeeper со TimescaleDB?

АГ: – Сега не можам да кажам со сигурност – ќе го погледнам кодот и ќе ви кажам подетално. Ги користи TimescaleDB пребарувањата не за да ги брише деловите, туку некако да ги собере. Сè уште не сум подготвен да одговорам на ова техничко прашање. Ќе дознаеме повеќе на штандот денес или утре.

О: – Имам слично прашање – за извршувањето на операцијата за бришење во Timescale.
О (одговор од публиката): – Кога бришете податоци од табела, ако тоа го правите преку бришење, тогаш треба да поминете низ табелата - избришете, исчистете, означете сè за идното правосмукалка. Во Timescale, бидејќи имате парчиња, можете да испуштите. Грубо кажано, едноставно ѝ кажувате на датотеката што е во големи податоци: „Избриши!“

Timescale едноставно разбира дека таков дел повеќе не постои. И бидејќи е интегриран во планерот за прашања, тој користи куки за да ги фати вашите услови при избрани или други операции и веднаш разбира дека овој дел повеќе не постои - „Нема да одам повеќе таму!“ (податоците не се достапни). Тоа е се! Односно, скенирањето на табелата се заменува со бришење на бинарна датотека, па затоа е брзо.

О: – Веќе ја допревме темата за не-SQL. Колку што разбрав, Zabbix навистина не треба да ги менува податоците, и сето ова е нешто како дневник. Дали е можно да се користат специјализирани бази на податоци кои не можат да ги променат своите податоци, но во исто време да зачувуваат, акумулираат и дистрибуираат многу побрзо - Clickhouse, на пример, нешто слично на Кафка?.. Кафка е и дневник! Дали е можно некако да се интегрираат?

АГ: - Може да се направи истовар. Имаме одредена „функција“ од верзијата 3.4: можете да ги запишете сите историски датотеки, настани, сè друго во датотеките; а потоа испратете ја во која било друга база на податоци користејќи некој управувач. Всушност, многу луѓе преработуваат и пишуваат директно во базата на податоци. Во лет, минатите за историја го пишуваат сето ова во датотеки, ги ротираат овие датотеки и така натаму, и можете да го префрлите ова во Clickhouse. Не можам да кажам за плановите, но можеби понатамошната поддршка за решенијата NoSQL (како што е Clickhouse) ќе продолжи.

О: – Во принцип, излегува дека можете целосно да се ослободите од постгрес?

АГ: – Се разбира, најтешкиот дел во Забикс се историските табели, кои создаваат најмногу проблеми и настани. Во овој случај, ако не чувате настани долго време и не ја чувате историјата со трендови во некое друго брзо складирање, тогаш генерално, мислам, нема да има проблеми.

О: – Можете ли да процените колку побрзо сè ќе функционира ако се префрлите на Clickhouse, на пример?

АГ: – Не сум го тестирал. Мислам дека барем истите бројки може да се постигнат сосема едноставно, со оглед на тоа што Clickhouse има свој интерфејс, но не можам да кажам со сигурност. Подобро е да се тестира. Сè зависи од конфигурацијата: колку хостови имате и така натаму. Вметнувањето е една работа, но исто така треба да ги вратите овие податоци - Графана или нешто друго.

О: – Значи, зборуваме за рамноправна борба, а не за големата предност на овие брзи бази на податоци?

АГ: – Мислам дека кога ќе се интегрираме, ќе има попрецизни тестови.

О: – Каде отиде стариот добар РРД? Што ве натера да се префрлите на SQL бази на податоци? Првично, сите метрики беа собрани на RRD.

АГ: – Забикс имаше RRD, можеби во многу античка верзија. Отсекогаш постоеле SQL бази на податоци - класичен пристап. Класичниот пристап е MySQL, PostgreSQL (тие постојат многу долго време). Речиси никогаш не користевме заеднички интерфејс за SQL и RRD бази на податоци.

Некои реклами 🙂

Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, облак VPS за програмери од 4.99 долари, уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: Целата вистина за VPS (KVM) E5-2697 v3 (6 јадра) 10GB DDR4 480GB SSD 1Gbps од 19 долари или како да споделите сервер? (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB 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 телевизор од 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