Біз Zabbix сервері ретінде TimescaleDB дерекқорымен қалай жұмыс істейтінін қарастырамыз. Біз сізге нөлден қалай бастау керектігін және PostgreSQL-тен қалай көшіру керектігін көрсетеміз. Біз сондай-ақ екі конфигурацияның салыстырмалы өнімділік сынақтарын береміз.
HighLoad++ Сибирь 2019. Томск залы. 24 маусым, 16:00. Тезистер және . Келесі HighLoad++ конференциясы 6 жылдың 7 және 2020 сәуірінде Санкт-Петербургте өтеді. Мәліметтер мен билеттер .
Андрей Гущин (бұдан әрі – AG): – Мен ZABBIX техникалық қолдау жөніндегі инженермін (бұдан әрі – «Zabbix»), жаттықтырушымын. Мен техникалық қолдау саласында 6 жылдан астам жұмыс істеп келемін және өнімділік бойынша тікелей тәжірибем бар. Бүгін мен тұрақты PostgreSQL 10-мен салыстырғанда TimescaleDB қамтамасыз ете алатын өнімділік туралы айтатын боламын. Сондай-ақ, оның жалпы қалай жұмыс істейтіні туралы кіріспе бөлім.
Өнімділіктің басты мәселелері: деректерді жинаудан деректерді тазалауға дейін
Бастау үшін, әрбір мониторинг жүйесі кездесетін белгілі бір өнімділік қиындықтары бар. Өнімділіктің бірінші мәселесі - деректерді жылдам жинау және өңдеу.
Жақсы мониторинг жүйесі барлық деректерді тез, уақтылы қабылдап, оны триггер өрнектеріне сәйкес өңдеуі керек, яғни оны кейбір критерийлер бойынша өңдеуі керек (бұл әртүрлі жүйелерде әртүрлі) және бұл деректерді пайдалану үшін деректер базасында сақтау керек. келешек.
Екінші өнімділік мәселесі - тарихты сақтау. Дерекқорда жиі сақтаңыз және белгілі бір уақыт аралығында жиналған осы көрсеткіштерге жылдам және ыңғайлы қол жеткізіңіз. Ең бастысы, бұл деректерді алуға ыңғайлы, оны есептерде, графиктерде, триггерлерде, кейбір шекті мәндерде, ескертулер үшін және т.б.
Үшінші өнімділік мәселесі - тарихты тазалау, яғни 5 жыл бойы (тіпті айлар немесе екі ай) жиналған кез келген егжей-тегжейлі көрсеткіштерді сақтаудың қажеті жоқ нүктеге жеткенде. Кейбір желі түйіндері жойылды немесе кейбір хосттар үшін көрсеткіштер бұдан былай қажет емес, себебі олар әлдеқашан ескірген және енді жиналмайды. Дерекқорыңыз тым үлкен болмас үшін мұның барлығын тазалау керек. Жалпы алғанда, тарихты тазалау көбінесе сақтау үшін маңызды сынақ болып табылады - ол көбінесе өнімділікке өте күшті әсер етеді.
Кэштеу мәселелерін қалай шешуге болады?
Мен қазір Zabbix туралы арнайы сөйлесетін боламын. Zabbix-те бірінші және екінші қоңыраулар кэштеу көмегімен шешіледі.
Деректерді жинау және өңдеу - біз осы деректерді сақтау үшін жедел жадты пайдаланамыз. Бұл деректер енді толығырақ талқыланады.
Сондай-ақ дерекқор жағында негізгі таңдаулар үшін кейбір кэштеу бар - графиктер және басқалар.
Zabbix серверінің жағында кэштеу: бізде ConfigurationCache, ValueCache, HistoryCache, TrendsCache бар. Бұл не?
ConfigurationCache – біз метриканы, хосттарды, деректер элементтерін, триггерлерді сақтайтын негізгі кэш; алдын ала өңдеуді өңдеу, деректерді жинау, қай хосттардан, қандай жиілікте жинау керек. Мұның бәрі дерекқорға кіріп, қажетсіз сұрауларды жасамау үшін ConfigurationCache ішінде сақталады. Сервер іске қосылғаннан кейін біз бұл кэшті жаңартамыз (оны жасаймыз) және оны мерзімді түрде жаңартып отырамыз (конфигурация параметрлеріне байланысты).
Zabbix-те кэштеу. Деректер жинау
Мұнда диаграмма өте үлкен:
Схемадағы негізгілері мына коллекторлар:
Бұл құрастыру процестерінің өздері, әр түрлі құрастыру түрлеріне жауап беретін әртүрлі «сауалушылар». Олар icmp, ipmi және әртүрлі протоколдар арқылы деректерді жинайды және олардың барлығын алдын ала өңдеуге жібереді.
Preprocessing HistoryCache
Сондай-ақ, егер бізде есептелген деректер элементтері (Zabbix-пен таныс адамдар біледі), яғни есептелген, біріктірілген деректер элементтері болса, біз оларды тікелей ValueCache ішінен аламыз. Оның қалай толтырылғанын кейінірек айтамын. Барлық осы коллекторлар өз жұмыстарын алу үшін ConfigurationCache пайдаланады, содан кейін оларды алдын ала өңдеуге береді.
Алдын ала өңдеу сонымен қатар алдын ала өңдеу қадамдарын алу және бұл деректерді әртүрлі жолдармен өңдеу үшін ConfigurationCache пайдаланады. 4.2 нұсқасынан бастап біз оны проксиге көшірдік. Бұл өте ыңғайлы, өйткені алдын ала өңдеудің өзі өте қиын операция. Егер сізде деректер элементтерінің көп саны және жинау жиілігі өте үлкен Zabbix болса, онда бұл жұмысты айтарлықтай жеңілдетеді.
Тиісінше, біз бұл деректерді алдын ала өңдеу арқылы қандай да бір жолмен өңдегеннен кейін, оны әрі қарай өңдеу үшін оны HistoryCache ішінде сақтаймыз. Бұл деректерді жинауды аяқтайды. Біз негізгі процеске көшеміз.
Тарих синсерінің жұмысы
Zabbix-тегі негізгі процесс (бұл монолитті архитектура болғандықтан) тарих синхрері болып табылады. Бұл әрбір деректер элементінің, яғни әрбір мәннің атомдық өңдеуімен арнайы айналысатын негізгі процесс:
- мән келеді (ол оны HistoryCache ішінен алады);
- Конфигурация синсерінде тексереді: есептеу үшін триггерлер бар ма - оларды есептейді;
егер бар болса - конфигурацияға сәйкес қажет болған жағдайда ескерту жасау үшін оқиғаларды жасайды, эскалацияны жасайды; - кейіннен өңдеу, жинақтау үшін триггерлерді жазбалар; соңғы сағатта және т.б. жинақтасаңыз, тарих кестесіне өтпеу үшін бұл мән ValueCache арқылы есте сақталады; Осылайша, ValueCache триггерлерді, есептелген элементтерді және т.б. есептеуге қажетті қажетті деректермен толтырылады;
- содан кейін History syncer барлық деректерді дерекқорға жазады;
- дерекқор оларды дискіге жазады - өңдеу процесі осы жерде аяқталады.
Дерекқор. Кэштеу
Дерекқор жағында графиктерді немесе оқиғалар туралы кейбір есептерді көргіңіз келсе, әртүрлі кэштер бар. Бірақ бұл баяндамада мен олар туралы айтпаймын.
MySQL үшін Innodb_buffer_pool және конфигурациялауға болатын әртүрлі кэштер бар.
Бірақ бұлар негізгілері:
- ортақ_буферлер;
- тиімді_кэш_өлшемі;
- ортақ_бассейн.
Барлық дерекқорлар үшін мен жедел жадта сұраулар үшін жиі қажет деректерді сақтауға мүмкіндік беретін белгілі бір кэштер бар екенін айттым. Бұл үшін олардың өз технологиялары бар.
Деректер базасының өнімділігі туралы
Сәйкесінше, бәсекелестік орта бар, яғни Zabbix сервері деректерді жинап, жазып алады. Қайта іске қосылғанда, ол ValueCache толтыру үшін тарихтан да оқиды және т.б. Мұнда веб-интерфейсте құрылған Zabbix API пайдаланатын сценарийлер мен есептер болады. Zabbix API дерекқорға кіреді және графиктерді, есептерді немесе оқиғалардың қандай да бір тізімін, соңғы проблемаларды алу үшін қажетті деректерді алады.
Сондай-ақ өте танымал визуализация шешімі - біздің пайдаланушыларымыз пайдаланатын Grafana. Zabbix API арқылы да, дерекқор арқылы да тікелей кіре алады. Ол сондай-ақ деректерді алу үшін белгілі бір бәсекелестік тудырады: нәтижелерді және тестілеуді жылдам жеткізуге сәйкес келу үшін мәліметтер базасын жақсырақ, жақсырақ баптау қажет.
Тарихты тазалау. Заббикстің үй қызметкері бар
Zabbix-те қолданылатын үшінші қоңырау - Housekeeper көмегімен тарихты тазарту. Үй қызметкері барлық параметрлерді бақылайды, яғни біздің деректер элементтері қанша уақыт сақтау керектігін (күнмен), трендтерді қанша уақыт сақтау керектігін және өзгерістер динамикасын көрсетеді.
Мен TrendCache туралы айтқан жоқпын, оны біз жылдам есептейміз: деректер келеді, біз оны бір сағатқа біріктіреміз (негізінен бұл соңғы сағаттағы сандар), сома орташа/минималды және біз оны сағатына бір рет жазамыз. өзгерістер динамикасының кестесі («Трендтер»). «Үй қызметкері» тұрақты таңдаулар арқылы дерекқордан деректерді бастайды және жояды, бұл әрқашан тиімді бола бермейді.
Оның тиімсіз екенін қалай түсінуге болады? Ішкі процестердің өнімділік графиктерінде келесі суретті көруге болады:
Тарих синсері үнемі бос емес (қызыл график). Ал жоғарғы жағында орналасқан «қызыл» график. Бұл дерекқордың өзі көрсеткен барлық жолдарды жоюын бастайтын және күтетін «Үй қызметкері».
Кейбір элемент идентификаторын алайық: соңғы 5 мыңды жою керек; әрине, индекстер бойынша. Бірақ, әдетте, деректер жинағы айтарлықтай үлкен - деректер базасы әлі де оны дискіден оқып, кэшке қояды және бұл дерекқор үшін өте қымбат операция. Оның өлшеміне байланысты бұл белгілі бір өнімділік мәселелеріне әкелуі мүмкін.
Үй қызметкерін қарапайым жолмен өшіруге болады - бізде таныс веб-интерфейс бар. Жалпы әкімшіліктегі параметрлер («Үй қызметкері» параметрлері) біз ішкі тарих пен трендтер үшін ішкі шаруашылықты өшіреміз. Тиісінше, үй қызметкері бұдан былай мұны бақылай алмайды:
Бұдан әрі не істей аласыз? Сіз оны өшірдіңіз, графиктеріңіз тегістелді... Бұл жағдайда тағы қандай мәселелер туындауы мүмкін? Не көмектесе алады?
Бөлу (бөлу)
Әдетте бұл мен тізімдеген әрбір реляциялық дерекқорда басқа жолмен конфигурацияланады. MySQL-де өз технологиясы бар. Бірақ олар PostgreSQL 10 және MySQL-ке келгенде өте ұқсас. Әрине, мұның барлығы қалай жүзеге асырылатыны және оның барлығы өнімділікке қалай әсер ететіні туралы көптеген ішкі айырмашылықтар бар. Бірақ тұтастай алғанда, жаңа бөлімді жасау көбінесе белгілі бір мәселелерге әкеледі.
Орнатуыңызға байланысты (бір күнде қанша деректер жасайсыз) олар әдетте ең азды белгілейді - бұл 1 күн / топтама, ал «тенденциялар» үшін өзгерістер динамикасы - 1 ай / жаңа топтама. Егер сізде өте үлкен орнату болса, бұл өзгеруі мүмкін.
Орнату өлшемі туралы бірден айтайық: секундына 5 мың жаңа мәнге дейін (nvps деп аталады) - бұл шағын «қондырма» болып саналады. Орташа – секундына 5-тен 25 мың мәнге дейін. Жоғарыда айтылғандардың бәрі дерекқорды өте мұқият конфигурациялауды қажет ететін үлкен және өте үлкен қондырғылар.
Өте үлкен қондырғыларда 1 күн оңтайлы болмауы мүмкін. Мен күніне 40 гигабайт MySQL бөлімдерін көрдім (және одан да көп болуы мүмкін). Бұл деректердің өте үлкен көлемі, бұл кейбір мәселелерге әкелуі мүмкін. Оны азайту керек.
Бөлу не үшін қажет?
Бөлімдеудің қамтамасыз ететіні, менің ойымша, бәрі біледі, бұл кестені бөлу. Көбінесе бұл дискідегі және ауқымды сұраулардағы бөлек файлдар. Ол қалыпты бөлімнің бөлігі болса, бір бөлімді оңтайлы таңдайды.
Заббикс үшін, атап айтқанда, диапазон бойынша, диапазон бойынша пайдаланылады, яғни біз уақыт белгісін (тұрақты сан, дәуірдің басынан бергі уақыт) қолданамыз. Сіз күннің басын/күннің соңын көрсетесіз және бұл бөлім. Тиісінше, егер сіз екі күндік деректерді сұрасаңыз, бәрі дерекқордан жылдамырақ шығарылады, себебі кэшке тек бір файлды жүктеп, оны қайтару керек (үлкен кесте емес).
Көптеген дерекқорлар кірістіруді жылдамдатады (бір еншілес кестеге кірістіру). Мен қазір абстрактілі түрде айтып отырмын, бірақ бұл да мүмкін. Бөлу жиі көмектеседі.
NoSQL үшін Elasticsearch
Жақында 3.4 нұсқасында біз NoSQL шешімін енгіздік. Elasticsearch-те жазу мүмкіндігі қосылды. Белгілі бір түрлерін жазуға болады: сіз таңдайсыз - не сандарды, не кейбір белгілерді жазу; бізде жолдық мәтін бар, журналдарды Elasticsearch жүйесіне жазуға болады... Сәйкесінше, веб-интерфейс Elasticsearch-ке де қол жеткізеді. Бұл кейбір жағдайларда жақсы жұмыс істейді, бірақ қазіргі уақытта оны пайдалануға болады.
Уақыт шкаласыDB. Гипертаблицалар
4.4.2 үшін біз TimescaleDB сияқты бір нәрсеге назар аудардық. Бұл не? Бұл PostgreSQL кеңейтімі, яғни оның PostgreSQL интерфейсі бар. Сонымен қатар, бұл кеңейтім уақыт сериялары деректерімен әлдеқайда тиімді жұмыс істеуге және автоматты түрде бөлуге мүмкіндік береді. Бұл қалай көрінеді:
Бұл гипертаблица - Timescale бағдарламасында мұндай тұжырымдама бар. Бұл сіз жасайтын гиперкесте және оның бөліктері бар. Бөлшектер - бұл бөлімдер, егер қателеспесем, бұл еншілес кестелер. Бұл шынымен тиімді.
TimescaleDB және PostgreSQL
TimescaleDB өндірушілері сендіргендей, олар сұрауларды, атап айтқанда кірістірулерді өңдеу үшін неғұрлым дұрыс алгоритмді пайдаланады, бұл деректер жиынының кірістіру өлшемі ұлғаюымен шамамен тұрақты өнімділікке мүмкіндік береді. Яғни, Postgres-тің 200 миллион жолынан кейін кәдімгісі қатты құлдилай бастайды және өнімділігін нөлге дейін жоғалтады, ал Timescale кез келген деректер көлемімен кірістірулерді барынша тиімді енгізуге мүмкіндік береді.
TimescaleDB қалай орнатуға болады? Бәрі оңай!
Бұл құжаттамада, ол сипатталған - оны кез келген пакеттерден орнатуға болады... Бұл ресми Postgres пакеттеріне байланысты. Қолмен құрастыруға болады. Дерекқорға компиляция жасауға тура келді.
Zabbix-те біз жай ғана кеңейтімді белсендіреміз. Менің ойымша, Postgres-те кеңейтімді пайдаланғандар... Сіз жай ғана кеңейтуді белсендіріп, оны пайдаланып жатқан Zabbix дерекқоры үшін жасайсыз.
Ал соңғы қадам...
Уақыт шкаласыDB. Тарих кестелерінің көшуі
Сізге гиперкесте жасау керек. Бұл үшін арнайы функция бар – Гиперкесте жасау. Онда бірінші параметр осы деректер қорына қажет кесте болып табылады (ол үшін гиперкесте жасау керек).
Жасалатын өріс және chunk_time_interval (бұл бөліктер аралығы (пайдаланылуы қажет бөлімдер). 86 - бір күн.
Migrate_data параметрі: "true" мәніне кірістірсеңіз, бұл барлық ағымдағы деректерді алдын ала жасалған бөліктерге тасымалдайды.
Мен migrate_data қолданбасын өзім пайдаландым - бұл дерекқордың қаншалықты үлкен екеніне байланысты жеткілікті уақытты алады. Менде терабайттан астам уақыт болды - оны жасауға бір сағаттан астам уақыт кетті. Кейбір жағдайларда тестілеу кезінде мен мәтін (history_text) және жол (history_str) үшін тарихи деректерді оларды тасымалдамау үшін жойдым - олар маған қызық болмады.
Және біз соңғы жаңартуды db_extension ішінде жасаймыз: дерекқор және, атап айтқанда, біздің Zabbix db_extension бар екенін түсінетіндей етіп timescaledb орнатамыз. Ол оны белсендіреді және TimescaleDB үшін қажетті «мүмкіндіктерді» пайдалана отырып, дерекқорға дұрыс синтаксис пен сұрауларды пайдаланады.
Сервер конфигурациясы
Мен екі серверді қолдандым. Бірінші сервер - бұл өте кішкентай виртуалды машина, 20 процессор, 16 гигабайт жедел жады. Мен оған Postgres 10.8 конфигурацияладым:
Операциялық жүйе Debian, файлдық жүйе xfs болды. Мен осы нақты дерекқорды пайдалану үшін ең аз параметрлерді жасадым, минус Zabbix өзі пайдаланатын. Сол машинада Zabbix сервері, PostgreSQL және жүктеу агенттері болды.
Мен әртүрлі нәтижелерді жылдам жасау үшін LoadableModule пайдаланатын 50 белсенді агентті қолдандым. Олар жолдарды, сандарды және т.б. жасағандар. Мен дерекқорды көптеген деректермен толтырдым. Бастапқыда конфигурацияда бір хост үшін 5 мың деректер элементтері болды және шамамен әрбір деректер элементінде триггер болды - бұл нақты орнату болуы үшін. Кейде пайдалану үшін бірнеше триггер қажет болады.
Мен жаңарту аралығын және жүктеудің өзін тек 50 агентті пайдаланып (көбірек қосу) ғана емес, сонымен қатар динамикалық деректер элементтерін пайдалану және жаңарту аралығын 4 секундқа дейін азайту арқылы реттедім.
Өнімділік сынағы. PostgreSQL: 36 мың NVP
Бірінші іске қосу, менде болған бірінші орнату осы жабдықта таза PostreSQL 10 болды (секундына 35 мың мән). Жалпы, экранда көріп отырғаныңыздай, деректерді енгізу секундтың бөліктерін алады - бәрі жақсы және жылдам, SSD дискілері (200 гигабайт). Жалғыз нәрсе - 20 ГБ өте тез толтырылады.
Болашақта мұндай графиктер өте көп болады. Бұл стандартты Zabbix серверінің өнімділік бақылау тақтасы.
Бірінші график секундына мәндер саны (көк, жоғарғы сол), бұл жағдайда 35 мың мән. Бұл (жоғарғы орталық) құрастыру процестерінің жүктелуі, ал бұл (жоғарғы оң жақта) ішкі процестердің жүктелуі: тарих синсерлері және мұнда (төменгі орталық) біраз уақыттан бері жұмыс істеп тұрған үй қызметкері.
Бұл график (төменгі орталық) ValueCache пайдалануын көрсетеді - триггерлер үшін қанша ValueCache соққысы (секундына бірнеше мың мән). Тағы бір маңызды график - төртінші (төменгі сол жақта), ол мен айтқан HistoryCache пайдалануды көрсетеді, ол дерекқорға кірістірер алдында буфер болып табылады.
Өнімділік сынағы. PostgreSQL: 50 мың NVP
Содан кейін мен сол жабдықтағы жүктемені секундына 50 мың мәнге дейін арттырдым. Үй қызметкері жүктеген кезде 10-2 секундта есептеумен 3 мың мән жазылды. Іс жүзінде не келесі скриншотта көрсетілген:
«Үй қызметкері» қазірдің өзінде жұмысқа кедергі жасай бастады, бірақ тұтастай алғанда, тарихқа түсіретін тұзақшыларға жүктеме әлі де 60% деңгейінде (үшінші график, жоғарғы оң жақта). HistoryCache Housekeeper жұмыс істеп тұрған кезде белсенді түрде толтыра бастайды (төменгі сол жақта). Ол шамамен жарты гигабайт болды, 20% толы.
Өнімділік сынағы. PostgreSQL: 80 мың NVP
Содан кейін мен оны секундына 80 мың мәнге дейін арттырдым:
Бұл шамамен 400 мың деректер элементтері, 280 мың триггерлер болды. Кірістіру, көріп отырғаныңыздай, тарихқа түсірушілердің жүктемесі бойынша (олардың 30-ы болды) әлдеқашан жоғары болды. Содан кейін мен әртүрлі параметрлерді ұлғайттым: тарихты түсіргіштер, кэш... Бұл жабдықта тарихқа түсіргіштерге жүктеме максимумға дейін өсе бастады, дерлік «сөреде» - тиісінше, HistoryCache өте жоғары жүктемеге түсті:
Осы уақыт ішінде мен барлық жүйе параметрлерін бақылап отырдым (процессордың қалай пайдаланылатынын, RAM) және дискіні пайдаланудың максималды екенін білдім - мен осы жабдықта, осы виртуалды машинада бұл дискінің максималды сыйымдылығына қол жеткіздім. «Postgres» осындай қарқындылықта деректерді белсенді түрде шығара бастады, ал дискінің жазуға, оқуға уақыты болмады...
Мен 48 процессоры мен 128 гигабайт жедел жады бар басқа серверді алдым:
Мен оны «баптадым» - History syncer (60 дана) орнатып, қолайлы өнімділікке қол жеткіздім. Шындығында, біз «сөреде» емеспіз, бірақ бұл өнімділіктің шегі болса керек, онда бұл туралы бірдеңе істеу керек.
Өнімділік сынағы. Уақыт шкаласыДБ: 80 мың NVP
Менің негізгі міндетім TimescaleDB пайдалану болды. Әрбір график төмендеуді көрсетеді:
Бұл сәтсіздіктер дәл деректерді тасымалдау болып табылады. Осыдан кейін, Zabbix серверінде, сіз көріп отырғандай, тарихты түсірушілердің жүктеу профилі көп өзгерді. Ол деректерді дерлік 3 есе жылдам енгізуге және HistoryCache-ті азырақ пайдалануға мүмкіндік береді - сәйкесінше, деректер уақытында жеткізіледі. Тағы да, секундына 80 мың мән - бұл өте жоғары көрсеткіш (әрине, Яндекс үшін емес). Тұтастай алғанда, бұл бір сервері бар өте үлкен орнату.
PostgreSQL өнімділік сынағы: 120 мың NVP
Содан кейін мен деректер элементтері санының мәнін жарты миллионға дейін арттырдым және секундына 125 мың есептелген мәнді алдым:
Мен мына графиктерді алдым:
Негізінде, бұл жұмыс істейтін қондырғы, ол ұзақ уақыт жұмыс істей алады. Бірақ менде бар болғаны 1,5 терабайт диск болғандықтан, мен оны бірнеше күнде қолдандым. Ең бастысы, TimescaleDB-де бір уақытта жаңа бөлімдер жасалды және бұл MySQL туралы айту мүмкін емес өнімділік үшін мүлдем байқалмады.
Әдетте, бөлімдер түнде жасалады, себебі бұл әдетте кірістіру мен кестелермен жұмыс істеуді блоктайды және қызметтің нашарлауына әкелуі мүмкін. Бұл жағдайда олай емес! Негізгі міндет TimescaleDB мүмкіндіктерін тексеру болды. Нәтиже келесі көрсеткіш болды: секундына 120 мың мән.
Сондай-ақ қоғамда мысалдар бар:
Сондай-ақ адам TimescaleDB бағдарламасын қосты және процессорға io.weight пайдалану жүктемесі төмендеді; және TimescaleDB қосуына байланысты ішкі процесс элементтерін пайдалану да азайды. Сонымен қатар, бұл қарапайым құймақ дискілері, яғни қарапайым дискілердегі қарапайым виртуалды машина (SSD емес)!
Дискінің өнімділігімен шектелген кейбір шағын орнатулар үшін TimescaleDB, менің ойымша, өте жақсы шешім. Бұл дерекқор үшін жылдамырақ жабдыққа көшу алдында жұмысты жалғастыруға мүмкіндік береді.
Баршаңызды біздің іс-шараларға шақырамын: Мәскеудегі конференция, Ригадағы саммит. Біздің арналарды пайдаланыңыз - Telegram, форум, IRC. Сұрақтарыңыз болса біздің үстелге келіңіз, біз барлығын айта аламыз.
Аудитория сұрақтары
Аудиториядан сұрақ (бұдан әрі - A): - Егер TimescaleDB конфигурациялау оңай болса және ол өнімділікті жоғарылатса, онда бұл Postgres көмегімен Zabbix конфигурациялаудың ең жақсы тәжірибесі ретінде пайдаланылуы мүмкін бе? Бұл шешімнің қандай да бір қателері мен кемшіліктері бар ма, әлде егер мен өзім үшін Zabbix жасауды шешсем, мен Postgres-ті оңай алып, Timescale-ті бірден орната аламын, оны пайдалана аламын және ешқандай мәселе туралы ойламаймын?
AG: – Иә, бұл жақсы ұсыныс деп айтар едім: Postgres қолданбасын TimescaleDB кеңейтімімен дереу пайдаланыңыз. Жоғарыда айтқанымдай, бұл «мүмкіндік» эксперименттік болғанына қарамастан, көптеген жақсы пікірлер бар. Бірақ іс жүзінде сынақтар бұл тамаша шешім екенін көрсетеді (TimescaleDB көмегімен) және менің ойымша, ол дамиды! Біз бұл кеңейтімнің қалай дамып жатқанын бақылап жатырмыз және қажет болған жағдайда өзгертулер енгіземіз.
Әзірлеу кезінде біз олардың белгілі «мүмкіндіктерінің» біріне сүйендік: кесектермен басқаша жұмыс істеуге болады. Бірақ содан кейін олар оны келесі шығарылымда кесіп тастады, және біз бұл кодқа сенуді тоқтатуға тура келді. Мен бұл шешімді көптеген орнатуларда пайдалануды ұсынамын. MySQL пайдалансаңыз... Орташа орнатулар үшін кез келген шешім жақсы жұмыс істейді.
A: – Қоғамдастықтың соңғы графиктерінде «Үй қызметкері» бар график болды:
Ол жұмысын жалғастырды. Housekeeper TimescaleDB көмегімен не істейді?
AG: – Енді мен нақты айта алмаймын – кодты қарап, толығырақ айтып беремін. Ол TimescaleDB сұрауларын бөліктерді жою үшін емес, оларды қандай да бір түрде біріктіру үшін пайдаланады. Мен бұл техникалық сұраққа әлі жауап беруге дайын емеспін. Толығырақ бүгін немесе ертең стендте білеміз.
A: – Менде ұқсас сұрақ бар – уақыт шкаласында жою операциясының орындалуы туралы.
A (аудиториядан жауап): – Кестеден деректерді жойған кезде, оны жою арқылы жасасаңыз, онда кесте арқылы өту керек - жою, тазалау, болашақ вакуум үшін барлығын белгілеу. Уақыт шкаласында бөліктер бар болғандықтан, тастай аласыз. Дөрекі айтқанда, сіз үлкен деректердегі файлға жай айтасыз: «Жою!»
Уақыт шкаласы мұндай бөліктің енді жоқ екенін түсінеді. Ол сұрауды жоспарлаушыға біріктірілгендіктен, таңдау немесе басқа операцияларда сіздің шарттарыңызды ұстау үшін ілмектерді пайдаланады және бұл бөлік енді жоқ екенін бірден түсінеді - «Мен енді ол жерге бармаймын!» (деректер қолжетімді емес). Осымен болды! Яғни, кестені сканерлеу екілік файлды жоюмен ауыстырылады, сондықтан ол жылдам.
A: – Біз SQL емес тақырыбын қозғадық. Менің түсінуімше, Zabbix деректерді өзгертудің қажеті жоқ және мұның бәрі журнал сияқты. Деректерін өзгерте алмайтын, бірақ сонымен бірге әлдеқайда жылдамырақ сақтайтын, жинақталатын және тарататын арнайы деректер қорын пайдалануға болады ма - Clickhouse, мысалы, Кафка сияқты нәрсе?.. Кафка да журнал! Оларды қандай да бір жолмен біріктіру мүмкін бе?
AG: - Жүк түсіруге болады. 3.4 нұсқасынан бастап бізде белгілі бір «мүмкіндік» бар: сіз барлық тарихи файлдарды, оқиғаларды, қалғанның бәрін файлдарға жаза аласыз; содан кейін оны қандай да бір өңдеуші арқылы кез келген басқа дерекқорға жіберіңіз. Шындығында, көптеген адамдар деректер базасына қайта жұмыс жасайды және жазады. Ұзақ уақыт бойы тарихшылар мұның бәрін файлдарға жазады, осы файлдарды айналдырады және т.б. және сіз мұны Clickhouse-ға тасымалдай аласыз. Мен жоспарлар туралы айта алмаймын, бірақ NoSQL шешімдерін (мысалы, Clickhouse) одан әрі қолдау жалғасады.
A: – Жалпы, постгрестен толық құтылуға болады екен?
AG: – Әрине, Zabbix-тің ең қиын бөлігі - ең көп проблемалар мен оқиғаларды тудыратын тарихи кестелер. Бұл жағдайда, егер сіз оқиғаларды ұзақ уақыт сақтамасаңыз және тарихты басқа жылдам сақтауда трендтермен сақтасаңыз, онда жалпы алғанда, менің ойымша, ешқандай проблемалар болмайды.
A: – Мысалы, Clickhouse жүйесіне ауыссаңыз, бәрі қаншалықты жылдам жұмыс істейтінін есептей аласыз ба?
AG: – Мен оны сынаған жоқпын. Менің ойымша, Clickhouse-дың өз интерфейсі бар екенін ескере отырып, кем дегенде бірдей сандарға оңай қол жеткізуге болады, бірақ мен нақты айта алмаймын. Тестілеу жақсы. Мұның бәрі конфигурацияға байланысты: сізде қанша хост бар және т.б. Кірістіру - бұл бір нәрсе, бірақ сіз бұл деректерді де алуыңыз керек - Grafana немесе басқа нәрсе.
A: – Демек, біз бұл жылдам базалардың үлкен артықшылығы туралы емес, тең күрес туралы айтып отырмыз?
AG: – Менің ойымша, біз интеграцияланған кезде дәлірек сынақтар болады.
A: – Жақсы ескі РРД қайда кетті? SQL дерекқорларына ауысуыңызға не себеп болды? Бастапқыда барлық көрсеткіштер RRD бойынша жиналды.
AG: – Zabbix-те RRD болды, мүмкін өте көне нұсқада. Әрқашан SQL дерекқорлары болды - классикалық тәсіл. Классикалық тәсіл MySQL, PostgreSQL (олар өте ұзақ уақыт бойы бар). Біз SQL және RRD дерекқорлары үшін ортақ интерфейсті ешқашан қолданбағанбыз.
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com