Mēs apskatīsim, kā Zabbix darbojas ar TimescaleDB datubāzi kā aizmugursistēmu. Mēs parādīsim, kā sākt no nulles un kā migrēt no PostgreSQL. Mēs nodrošināsim arī abu konfigurāciju salīdzinošus veiktspējas testus.
HighLoad++ Siberia 2019. Зал «Томск». 24 июня, 16:00. Тезисы и . Nākamā HighLoad++ konference notiks 6. gada 7. un 2020. aprīlī Sanktpēterburgā. Sīkāka informācija un biļetes .
Andrejs Guščins (turpmāk – AG): – Я – инженер технической поддержки ZABBIX (далее – «Заббикс»), тренер. Работаю более 6 лет в технической поддержке и напрямую сталкивался с производительностью. Сегодня я буду рассказывать о производительности, которую может дать TimescaleDB, при сравнении с обычным PostgreSQL 10. Также некоторая вводная часть – о том, как вообще работает.
Главные вызовы производительности: от сбора до очистки данных
Начнём с того, что есть определённые вызовы производительности, с которыми встречается каждая система мониторинга. Первый вызов производительности – это быстрый сбор и обработка данных.
Labai uzraudzības sistēmai ātri, savlaicīgi jāsaņem visi dati, jāapstrādā tie atbilstoši trigera izteiksmēm, tas ir, jāapstrādā pēc dažiem kritērijiem (dažādās sistēmās tas atšķiras) un jāsaglabā datu bāzē, lai šos datus izmantotu nākotnē.
Otrs veiktspējas izaicinājums ir vēstures glabāšana. Bieži uzglabājiet datu bāzē un ātri un ērti piekļūstiet šiem rādītājiem, kas tika apkopoti noteiktā laika periodā. Pats galvenais, lai šos datus būtu ērti iegūt, izmantot pārskatos, grafikos, trigeros, dažās sliekšņa vērtībās, brīdinājumiem utt.
Trešais veiktspējas izaicinājums ir vēstures notīrīšana, tas ir, kad jums nav jāglabā nekādi detalizēti dati, kas apkopoti 5 gadu (pat mēnešu vai divu mēnešu) laikā. Tika dzēsti daži tīkla mezgli vai daži resursdatori. Metrikas vairs nav vajadzīgas, jo tās jau ir novecojušas un vairs netiek apkopotas. Tas viss ir jāiztīra, lai jūsu datu bāze neizaugtu pārāk liela. Kopumā vēstures dzēšana visbiežāk ir nopietns krātuves pārbaudījums - tas bieži vien ļoti spēcīgi ietekmē veiktspēju.
Kā atrisināt kešatmiņas problēmas?
Tagad es runāšu īpaši par Zabbix. Programmā Zabbix pirmais un otrais zvans tiek atrisināts, izmantojot kešatmiņu.
Datu vākšana un apstrāde – mēs izmantojam RAM, lai saglabātu visus šos datus. Tagad šie dati tiks apspriesti sīkāk.
Arī datu bāzes pusē ir kāda kešatmiņa galvenajām atlasēm - grafikiem un citām lietām.
Kešatmiņa pašā Zabbix servera pusē: mums ir ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Kas tas ir?
ConfigurationCache – это основной кэш, в котором мы храним метрики, хосты, элементы данных, триггеры; всё, что нужно для обработки препроцессинга, сбора данных, с каких хостов собирать, с какой частотой. Всё это хранится в ConfigurationCache, чтобы не ходить в базу данных, не создавать лишних запросов. После старта сервера мы обновляем этот кэш (создаём) и обновляем периодически (в зависимости от настроек конфигурации).
Кэширование в Zabbix. Сбор данных
Šeit diagramma ir diezgan liela:
Основные в схеме – вот эти сборщики:
Tie ir paši montāžas procesi, dažādi “polleri”, kas atbild par dažāda veida montāžām. Viņi apkopo datus, izmantojot icmp, ipmi un dažādus protokolus, un nodod to visu pirmapstrādei.
Pirmsapstrādes vēstures kešatmiņa
Turklāt, ja mums ir aprēķināti datu elementi (tie, kas pārzina Zabbix), tas ir, aprēķinātie, apkopotie datu elementi, mēs tos ņemam tieši no ValueCache. Kā tas ir aizpildīts, es pastāstīšu vēlāk. Visi šie savācēji izmanto ConfigurationCache, lai saņemtu savus darbus un pēc tam nodotu tos pirmapstrādei.
Iepriekšēja apstrāde izmanto arī ConfigurationCache, lai iegūtu pirmapstrādes darbības un apstrādātu šos datus dažādos veidos. Sākot no versijas 4.2, mēs to esam pārvietojuši uz starpniekserveri. Tas ir ļoti ērti, jo pati priekšapstrāde ir diezgan sarežģīta darbība. Un, ja jums ir ļoti liels Zabbix ar lielu datu elementu skaitu un augstu vākšanas biežumu, tas ievērojami vienkāršo darbu.
Attiecīgi pēc tam, kad esam kaut kādā veidā apstrādājuši šos datus, izmantojot iepriekšēju apstrādi, mēs tos saglabājam HistoryCache, lai tos apstrādātu tālāk. Tas noslēdz datu vākšanu. Mēs pārejam pie galvenā procesa.
Vēstures sinhronizētāja darbs
Galvenais process Zabbix (jo tā ir monolīta arhitektūra) ir vēstures sinhronizācija. Šis ir galvenais process, kas īpaši attiecas uz katra datu elementa, tas ir, katras vērtības, atomu apstrādi:
- vērtība nāk (tā tiek ņemta no HistoryCache);
- pārbauda Configuration syncer: vai ir kādi trigeri aprēķinam - aprēķina tos;
если есть – создаёт события, создаёт эскалацию для того, чтобы создать оповещение, если это необходимо по конфигурации; - reģistrē trigerus turpmākai apstrādei, apkopošanai; ja apkopojat pēdējo stundu un tā tālāk, ValueCache atceras šo vērtību, lai nepārietu uz vēstures tabulu; Tādējādi ValueCache tiek aizpildīta ar nepieciešamajiem datiem, kas nepieciešami trigeru, aprēķināto elementu u.tml. aprēķināšanai;
- далее History syncer записывает все данные в базу данных;
- база данных записывает их на диск – на этом процесс обработки заканчивается.
Базы данных. Кэширование
Datu bāzes pusē, kad vēlaties skatīt grafikus vai dažus pārskatus par notikumiem, ir dažādas kešatmiņas. Bet šajā ziņojumā es par tiem nerunāšu.
MySQL ir Innodb_buffer_pool un dažādas kešatmiņas, kuras var arī konfigurēt.
Bet šie ir galvenie:
- shared_buffers;
- efektīvas_kešatmiņas_izmērs;
- Shared_pool.
Visām datu bāzēm es teicu, ka ir noteiktas kešatmiņas, kas ļauj saglabāt RAM datus, kas bieži nepieciešami vaicājumiem. Viņiem ir savas tehnoloģijas šim nolūkam.
Par datu bāzes veiktspēju
Соответственно, есть конкурентная среда, то есть «Заббикс»-сервер собирает данные и записывает их. При перезапуске он тоже читает из истории для наполнения ValueCache и так далее. Тут же у вас могут быть скрипты и отчёты, которые используют «Заббикс»-API, который на базе веб-интерфейса построен. «Заббикс»-API входит в БД и получает необходимые данные для получения графиков, отчётов либо какого-то списка событий, последних проблем.
Также очень популярное решение для визуализации – это Grafana, которое используют наши пользователи. Умеет напрямую входить как через «Заббикс»-API, так и через БД. Оно тоже создаёт определённую конкуренцию для получения данных: нужна более тонкая, хорошая настройка БД, чтобы соответствовать быстрой выдаче результатов и тестирования.
Vēstures dzēšana. Zabbix ir mājkalpotāja
Trešais zvans, kas tiek izmantots Zabbix, ir vēstures notīrīšana, izmantojot Housekeeper. Housekeeper seko visiem iestatījumiem, tas ir, mūsu datu elementi norāda, cik ilgi uzglabāt (dienās), cik ilgi saglabāt tendences un izmaiņu dinamiku.
Es nerunāju par TrendCache, ko mēs aprēķinām lidojuma laikā: dati tiek saņemti, mēs tos apkopojam par vienu stundu (pārsvarā tie ir skaitļi par pēdējo stundu), summa ir vidēja/minimālā un mēs to ierakstām reizi stundā izmaiņu dinamikas tabula (“Trends”) . “Mājkalpotājs” sāk un dzēš datus no datu bāzes, izmantojot parastās atlases, kas ne vienmēr ir efektīvas.
Kā saprast, ka tas ir neefektīvs? Iekšējo procesu veiktspējas grafikos varat redzēt šādu attēlu:
У вас History syncer постоянно занят (красный график). И «рыжий» график, который поверху идёт. Это «Хаускипер», который запускается и ждёт от БД, когда она удалит все строки, которые он задал.
Возьмём какой-нибудь Item ID: нужно удалить последние 5 тысяч; конечно, по индексам. Но обычно датасет достаточно большой – база данных всё равно это считывает с диска и поднимает в кэш, а это очень дорогая операция для БД. В зависимости от её размеров, это может приводить к определённым проблемам производительности.
Jūs varat atspējot Housekeeper vienkāršā veidā — mums ir pazīstama tīmekļa saskarne. Iestatījumi sadaļā Administrēšana vispārīgi (iestatījumi “Mājkalpotājs”) mēs atspējojam iekšējo uzkopšanu, lai redzētu iekšējo vēsturi un tendences. Attiecīgi Housekeeper vairs nekontrolē šo:
Ko jūs varat darīt tālāk? Jūs to izslēdzāt, jūsu grafiki ir izlīdzinājušies... Kādas vēl problēmas varētu rasties šajā gadījumā? Kas var palīdzēt?
Sadalīšana (sadalīšana)
Обычно это настраивается на каждой реляционной базе данных, которые я перечислил, различным способом. На MySQL своя технология. Но в целом они очень похожи, если говорить о PostgreSQL 10 и MySQL. Конечно, там очень много внутренних различий, как это всё реализовано и как это всё влияет на производительность. Но в целом создание новой партиции часто тоже приводит к определённым проблемам.
Atkarībā no jūsu iestatījuma (cik daudz datu jūs izveidojat vienā dienā), viņi parasti nosaka minimumu - tā ir 1 diena / partija, un "tendencēm" izmaiņu dinamikai - 1 mēnesis / jauna partija. Tas var mainīties, ja jums ir ļoti liels iestatījums.
Teiksim uzreiz par iestatījuma lielumu: līdz 5 tūkstošiem jaunu vērtību sekundē (tā sauktais nvps) - tas tiks uzskatīts par nelielu “iestatījumu”. Vidēji - no 5 līdz 25 tūkstošiem vērtību sekundē. Viss, kas minēts iepriekš, jau ir lielas un ļoti lielas instalācijas, kurām nepieciešama ļoti rūpīga datu bāzes konfigurēšana.
Ļoti lielām iekārtām 1 diena var nebūt optimāla. Es personīgi esmu redzējis MySQL nodalījumus ar 40 gigabaitiem dienā (un var būt vairāk). Tas ir ļoti liels datu apjoms, kas var radīt dažas problēmas. Tas ir jāsamazina.
Kāpēc jums ir nepieciešama sadalīšana?
Es domāju, ka visi zina, ko nodrošina sadalīšana, ir tabulas sadalīšana. Bieži vien tie ir atsevišķi faili diskā un span pieprasījumi. Tas izvēlas vienu nodalījumu optimālāk, ja tas ir daļa no parastās sadalīšanas.
Jo īpaši attiecībā uz Zabbix tas tiek izmantots pēc diapazona, pēc diapazona, tas ir, mēs izmantojam laikspiedolu (parasts skaitlis, laiks kopš laikmeta sākuma). Jūs norādāt dienas sākumu/dienas beigas, un šis ir nodalījums. Attiecīgi, ja prasāt divas dienas vecus datus, no datu bāzes viss tiek izgūts ātrāk, jo vajag tikai vienu failu ielādēt kešatmiņā un atdot (nevis lielu tabulu).
Daudzas datu bāzes arī paātrina ievietošanu (ievietošanu vienā bērnu tabulā). Pagaidām es runāju abstrakti, bet arī tas ir iespējams. Sadalīšana bieži palīdz.
Elasticsearch для NoSQL
Недавно, в 3.4, мы внедрили решение для NoSQL. Добавили возможность писать в Elasticsearch. Вы можете писать отдельные какие-то типы: выбираете – либо числа пишите, либо какие-то знаки; у нас есть стринг-текст, логи можете писать в Elasticsearch… Соответственно, веб-интерфейс уже тоже будет обращаться к Elasticsearch. Это отлично в каких-то случаях работает, но в данный момент это можно использовать.
TimescaleDB. Hipertables
Attiecībā uz 4.4.2 mēs pievērsām uzmanību vienai lietai, piemēram, TimescaleDB. Kas tas ir? Šis ir PostgreSQL paplašinājums, tas ir, tam ir vietējais PostgreSQL interfeiss. Turklāt šis paplašinājums ļauj daudz efektīvāk strādāt ar laikrindu datiem un nodrošināt automātisku sadalīšanu. Kā tas izskatās:
Tas ir hipertable - tāds jēdziens ir Timescale. Šī ir jūsu izveidotā hipertabula, kurā ir ietverti gabali. Gabali ir starpsienas, tās ir bērnu tabulas, ja nemaldos. Tas ir patiešām efektīvs.
TimescaleDB и PostgreSQL
Kā apliecina TimescaleDB ražotāji, viņi izmanto pareizāku algoritmu vaicājumu, jo īpaši ieliktņu, apstrādei, kas ļauj tiem nodrošināt aptuveni nemainīgu veiktspēju, palielinoties datu kopas ievietojuma izmēram. Tas ir, pēc 200 miljoniem Postgres rindu parastais sāk ļoti nokrist un zaudēt veiktspēju burtiski līdz nullei, savukārt Timescale ļauj ievietot ieliktņus pēc iespējas efektīvāk ar jebkādu datu apjomu.
Kā instalēt TimescaleDB? Tas ir vienkārši!
Tas ir dokumentācijā, tas ir aprakstīts - jūs varat to instalēt no jebkuras pakotnes... Tas ir atkarīgs no oficiālajām Postgres pakotnēm. Var sastādīt manuāli. Sagadījās tā, ka nācās apkopot datubāzei.
На «Заббикс» мы просто активируем Extention. Я думаю, что те, кто пользовался в «Постгресе» Extention… Вы просто активируете Extention, создаёте его для БД «Заббикс», которую используете.
Un pēdējais solis...
TimescaleDB. Vēstures tabulu migrācija
Вам нужно создать hypertable. Для этого есть специальная функция – Create hypertable. В ней первым параметром указываете таблицу, которая в этой БД нужна (для которой нужно создать гипертаблицу).
Поле, по которому нужно создать, и chunk_time_interval (это интервал чанков (партиций, которые нужно использовать). 86 400 – это один день.
Parametrs Migrate_data: ja ievietojat vērtību True, visi pašreizējie dati tiks migrēti uz iepriekš izveidotiem gabaliem.
Pats esmu izmantojis migrate_data — tas aizņem diezgan daudz laika, atkarībā no tā, cik liela ir jūsu datubāze. Man bija vairāk nekā terabaits — tā izveide aizņēma vairāk nekā stundu. Dažos gadījumos testēšanas laikā es izdzēsu vēsturiskos datus tekstam (history_text) un virknei (history_str), lai tos nepārnestu - tie man nebija īsti interesanti.
Un mēs veicam pēdējo atjauninājumu savā db_extention: instalējam timescaledb, lai datubāze un jo īpaši mūsu Zabbix saprastu, ka pastāv db_extention. Viņš to aktivizē un izmanto pareizo sintaksi un datubāzes vaicājumus, izmantojot tās "funkcijas", kas ir nepieciešamas TimescaleDB.
Servera konfigurācija
Es izmantoju divus serverus. Pirmais serveris ir diezgan maza virtuālā mašīna, 20 procesori, 16 gigabaiti RAM. Es tajā konfigurēju Postgres 10.8:
Operētājsistēma bija Debian, failu sistēma bija xfs. Es veicu minimālus iestatījumus, lai izmantotu šo konkrēto datu bāzi, atskaitot to, ko izmantos pati Zabbix. Tajā pašā mašīnā bija Zabbix serveris, PostgreSQL un ielādes aģenti.
Esmu izmantojis 50 aktīvos līdzekļus, kas izmanto LoadableModule, lai ātri radītu dažādus rezultātus. Viņi ir tie, kas ģenerēja virknes, skaitļus un tā tālāk. Es aizpildīju datubāzi ar daudziem datiem. Sākotnēji konfigurācija ietvēra 5 tūkstošus datu elementu uz vienu saimniekdatoru, un aptuveni katrs datu elements ietvēra trigeri - lai tas būtu reāls iestatījums. Dažreiz jums pat ir nepieciešams vairāk nekā viens sprūda izmantošana.
Atjaunināšanas intervālu un pašu slodzi regulēju ne tikai izmantojot 50 aģentus (pievienojot vairāk), bet arī izmantojot dinamiskos datu elementus un samazinot atjaunināšanas intervālu līdz 4 sekundēm.
Veiktspējas pārbaude. PostgreSQL: 36 tūkstoši NVP
Первый запуск, первый setup у меня был на чистом PostreSQL 10 на этом железе (35 тысяч значений в секунду). В целом, как видно на экране, вставка данных занимает фракции секунды – всё хорошо и быстро, SSD-диски (200 гигабайт). Единственное, что 20 ГБ достаточно быстро заполняются.
Nākotnē šādu grafiku būs diezgan daudz. Šis ir standarta Zabbix servera veiktspējas informācijas panelis.
Pirmais grafiks ir vērtību skaits sekundē (zils, augšā pa kreisi), šajā gadījumā 35 tūkstoši vērtību. Šī (augšējā centrā) ir būvēšanas procesu ielāde, un šī (augšējā labajā pusē) ir iekšējo procesu ielāde: vēstures sinhronizatori un mājkalpotāja, kas šeit (apakšā centrā) darbojas jau labu laiku.
Šajā diagrammā (apakšējā centrā) ir parādīts ValueCache lietojums — cik ValueCache trāpījumi ir aktivizēti (vairāki tūkstoši vērtību sekundē). Vēl viens svarīgs grafiks ir ceturtais (apakšā pa kreisi), kas parāda HistoryCache, par kuru es runāju, izmantošanu, kas ir buferis pirms ievietošanas datu bāzē.
Veiktspējas pārbaude. PostgreSQL: 50 tūkstoši NVP
Pēc tam es palielināju slodzi līdz 50 tūkstošiem vērtību sekundē tajā pašā aparatūrā. Ielādējot Housekeeper, ar aprēķinu 10-2 sekundēs tika reģistrēti 3 tūkstoši vērtību. Kas patiesībā ir parādīts šajā ekrānuzņēmumā:
“Mājkalpotājs” jau sāk traucēt darbu, bet kopumā vēstures gremdētāju slazdotāju slodze joprojām ir 60% līmenī (trešais grafiks, augšā pa labi). HistoryCache jau sāk aktīvi aizpildīt, kamēr Housekeeper darbojas (apakšā pa kreisi). Tas bija apmēram puse gigabaita, 20% pilna.
Veiktspējas pārbaude. PostgreSQL: 80 tūkstoši NVP
Tad es to palielināju līdz 80 tūkstošiem vērtību sekundē:
Это было примерно 400 тысяч элементов данных, 280 тысяч триггеров. Вставка, как видите, по загрузке хистори-синкеров (их было 30 штук) была уже достаточно высокая. Дальше я увеличивал различные параметры: хистори-синкеры, кэш… На данном железе загрузка хистори-синкеров начала увеличиваться до максимума, практически «в полку» – соответственно, HistoryCache пошёл в очень высокую загрузку:
Visu šo laiku sekoju līdzi visiem sistēmas parametriem (kā tiek izmantots procesors, RAM) un atklāju, ka diska noslodze ir maksimāla - sasniedzu maksimālo šī diska ietilpību uz šīs aparatūras, uz šīs virtuālās mašīnas. "Postgres" sāka diezgan aktīvi izgāzt datus tādā intensitātē, un diskam vairs nebija laika rakstīt, lasīt...
Es paņēmu citu serveri, kuram jau bija 48 procesori un 128 gigabaiti RAM:
Также я его «затюнил» – поставил History syncer (60 штук) и добился приемлемого быстродействия. Фактически мы не «в полке», но это уже, наверное, предел производительности, где уже необходимо что-то с этим предпринимать.
Тест производительности. TimescaleDB: 80 тысяч NVPs
Mans galvenais uzdevums bija izmantot TimescaleDB. Katrs grafiks parāda kritumu:
Šīs kļūmes ir tieši datu migrācija. Pēc tam Zabbix serverī vēstures gremdētāju ielādes profils, kā redzat, ļoti mainījās. Tas ļauj ievietot datus gandrīz 3 reizes ātrāk un izmantot mazāk HistoryCache - attiecīgi dati tiks piegādāti laikā. Atkal, 80 tūkstoši vērtību sekundē ir diezgan augsts rādītājs (protams, ne Yandex). Kopumā šī ir diezgan liela iestatīšana ar vienu serveri.
PostgreSQL veiktspējas tests: 120 tūkstoši NVP
Tālāk es palielināju datu elementu skaitu līdz pusmiljonam un saņēmu aprēķināto vērtību 125 tūkstoši sekundē:
Un es saņēmu šādus grafikus:
Principā tas ir darba iestatījums, tas var darboties diezgan ilgu laiku. Bet, tā kā man bija tikai 1,5 terabaitu disks, es to izlietoju pāris dienu laikā. Vissvarīgākais ir tas, ka tajā pašā laikā TimescaleDB tika izveidoti jauni nodalījumi, un tas bija pilnīgi nepamanīts veiktspējai, ko nevar teikt par MySQL.
Parasti nodalījumi tiek izveidoti naktī, jo tas parasti bloķē ievietošanu un darbu ar tabulām un var izraisīt pakalpojuma degradāciju. Šajā gadījumā tas tā nav! Galvenais uzdevums bija pārbaudīt TimescaleDB iespējas. Rezultāts bija šāds skaitlis: 120 tūkstoši vērtību sekundē.
Sabiedrībā ir arī piemēri:
Persona arī ieslēdza TimescaleDB, un procesora slodze, izmantojot io.weight, samazinājās; un arī iekšējo procesa elementu izmantošana ir samazinājusies, pateicoties TimescaleDB iekļaušanai. Turklāt tie ir parastie pankūku diski, tas ir, parasta virtuālā mašīna parastajos diskos (nevis SSD)!
Dažiem maziem iestatījumiem, kurus ierobežo diska veiktspēja, TimescaleDB, manuprāt, ir ļoti labs risinājums. Tas ļaus jums turpināt darbu pirms migrēšanas uz ātrāku datu bāzes aparatūru.
Aicinu visus uz mūsu pasākumiem: Konferenci Maskavā, Samitu Rīgā. Izmantojiet mūsu kanālus - Telegram, forumu, IRC. Ja ir kādi jautājumi, nāc pie mūsu rakstāmgalda, varam visu sarunāt.
Klausītāju jautājumi
Вопрос из аудитории (далее – А): – Если TimescaleDB так просто в настройке, и он даёт такой прирост производительности, то, возможно, это стоит использовать как лучшую практику настройки «Заббикса» с «Постгресом»? И есть ли какие-то подводные камни и минусы этого решения, или всё-таки, если я решил себе делать «Заббикс», я могу спокойно брать «Постгрес», ставить туда «Таймскейл» сразу, пользоваться и не думать ни о каких проблемах?
AG: – Да, я сказал бы, что это хорошая рекомендация: использовать «Постгрес» сразу с расширением TimescaleDB. Как я уже говорил, множество хороших отзывов, несмотря на то, что эта «фича» экспериментальна. Но на самом деле тесты показывают, что это отличное решение (с TimescaleDB), и я думаю, что оно будет развиваться! Мы следим за тем, как это расширение развивается и будем править то, что нужно.
Pat izstrādes laikā mēs paļāvāmies uz vienu no viņu labi zināmajām "funkcijām": bija iespējams strādāt ar gabaliņiem nedaudz savādāk. Bet tad viņi to izgrieza nākamajā laidienā, un mums bija jāpārtrauc paļauties uz šo kodu. Es ieteiktu izmantot šo risinājumu daudzos iestatījumos. Ja izmantojat MySQL... Vidējiem iestatījumiem jebkurš risinājums darbojas labi.
A: – Pēdējās kopienas diagrammās bija grafiks ar “Mājsaimniece”:
Он продолжил работать. Что «Хаускипер» делает в случае с TimescaleDB?
AG: – Tagad nevaru droši pateikt – apskatīšu kodu un pastāstīšu sīkāk. Tas izmanto TimescaleDB vaicājumus nevis lai dzēstu gabalus, bet gan lai kaut kā tos apkopotu. Es vēl neesmu gatavs atbildēt uz šo tehnisko jautājumu. Vairāk uzzināsim stendā šodien vai rīt.
A: – Man ir līdzīgs jautājums – par dzēšanas darbības veikšanu Timescale.
A (atbilde no auditorijas): – Dzēšot datus no tabulas, ja to darāt ar dzēšanas palīdzību, tad jāiziet tabula – jāizdzēš, jāiztīra, jāatzīmē viss turpmākajam vakuumam. Laika skalā, jo jums ir gabali, varat nomest. Aptuveni runājot, jūs vienkārši sakāt failam, kas atrodas lielos datos: “Dzēst!”
Laika skala vienkārši saprot, ka šāds gabals vairs nepastāv. Un, tā kā tas ir integrēts vaicājumu plānotājā, tas izmanto āķus, lai uztvertu jūsu nosacījumus atlasītajās vai citās darbībās, un uzreiz saprot, ka šī daļa vairs nepastāv — "Es tur vairs neiešu!" (dati nav pieejami). Tas ir viss! Tas nozīmē, ka tabulas skenēšana tiek aizstāta ar bināro failu dzēšanu, tāpēc tā ir ātra.
A: – Уже затрагивали тему не SQL. Насколько я понимаю, «Заббиксу» не очень нужно модифицировать данные, а всё это – что-то вроде лога. Можно ли использовать специализированные БД, которые не могут менять свои данные, но при этом гораздо быстрее сохраняют, накапливают, отдают – Clickhouse, допустим, что-нибудь кафка-образное?.. Kafka – это же тоже лог! Можно ли их как-то интегрировать?
AG: - Izkraušanu var veikt. Kopš versijas 3.4 mums ir noteikta “funkcija”: failos var ierakstīt visus vēsturiskos failus, notikumus, visu pārējo; un pēc tam nosūtiet to uz jebkuru citu datu bāzi, izmantojot kādu apstrādātāju. Patiesībā daudzi cilvēki pārstrādā un raksta tieši datu bāzē. Lidojuma laikā vēstures meklētāji to visu ieraksta failos, pagriež šos failus un tā tālāk, un jūs varat tos pārsūtīt uz Clickhouse. Es nevaru teikt par plāniem, bet, iespējams, turpināsies turpmāks atbalsts NoSQL risinājumiem (piemēram, Clickhouse).
A: – Vispār izrādās, ka no postgres var pilnībā atbrīvoties?
AG: – Protams, vissarežģītākā daļa Zabbix ir vēsturiskās tabulas, kas rada visvairāk problēmu, un notikumi. Tādā gadījumā, ja notikumus neglabāsi ilgu laiku un vēsturi ar tendencēm glabāsi kādā citā ātrā krātuvē, tad kopumā, manuprāt, problēmu nebūs.
A: – Vai varat aplēst, cik daudz ātrāk viss darbosies, piemēram, pārejot uz Clickhouse?
AG: – Я не тестировал. Думаю, что как минимум тех же цифр можно будет достичь достаточно просто, учитывая, что «Кликхаус» имеет свой интерфейс, но не могу сказать однозначно. Лучше протестировать. Всё зависит от конфигурации: сколько у вас хостов и так далее. Вставка – это одно, но нужно ещё забирать эти данные – Grafana или ещё чем-то.
A: – Tātad runa ir par līdzvērtīgu cīņu, nevis par šo ātro datu bāzu lielo priekšrocību?
AG: – Думаю, когда интегрируем, будут более точные тесты.
A: – Kur pazuda vecā labā RRD? Kas lika jums pāriet uz SQL datu bāzēm? Sākotnēji visi rādītāji tika apkopoti RRD.
AG: – Zabbix bija RRD, iespējams, ļoti senā versijā. Vienmēr ir bijušas SQL datu bāzes – klasiska pieeja. Klasiskā pieeja ir MySQL, PostgreSQL (tās pastāv ļoti ilgu laiku). Mēs gandrīz nekad neizmantojām kopīgu saskarni SQL un RRD datu bāzēm.
Dažas reklāmas 🙂
Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, , unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).
Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai šeit Nīderlandē! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB — no 99 USD! Lasīt par
Avots: www.habr.com