Mir kucken wéi Zabbix mat der TimescaleDB Datebank als Backend funktionnéiert. Mir weisen Iech wéi Dir vun Null unzefänken a wéi Dir vu PostgreSQL migréiert. Mir wäerten och vergläichend Leeschtungstester vun den zwou Konfiguratiounen ubidden.
HighLoad++ Sibirien 2019. Tomsk Hall. 24. Juni, 16:00. Theses an . Déi nächst HighLoad++ Konferenz gëtt de 6. a 7. Abrëll 2020 zu St. Detailer an Ticketen .
Andrey Gushchin (nachfolgend - AG): - Ech sinn en ZABBIX Technesch Ënnerstëtzung Ingenieur (nodréiglech als "Zabbix" bezeechent), en Trainer. Ech hunn an der technescher Ënnerstëtzung fir méi wéi 6 Joer geschafft an hunn direkt Erfahrung mat Leeschtung. Haut wäert ech iwwer d'Performance schwätzen, déi TimescaleDB kann ubidden am Verglach mat normale PostgreSQL 10. Och e puer Aféierungsdeel iwwer wéi et am Allgemengen funktionnéiert.
Top Produktivitéit Erausfuerderungen: vun Datensammlung bis Datereinigung
Fir unzefänken, ginn et gewësse Performance Erausfuerderunge fir all Iwwerwaachungssystem. Déi éischt Produktivitéit Erausfuerderung ass d'Sammelen an d'Veraarbechtung vun Daten séier.
E gudde Iwwerwaachungssystem soll séier, rechtzäiteg all Donnéeën kréien, se no Ausléiserausdréck veraarbechten, dat heescht, se no e puer Critèren veraarbechten (dëst ass anescht a verschiddene Systemer) an an enger Datebank späicheren fir dës Donnéeën an der Zukunft.
Déi zweet Leeschtung Erausfuerderung ass Geschicht Stockage. Späichert an enger Datebank dacks an hu séier a praktesch Zougang zu dëse Metriken déi iwwer eng Zäit gesammelt goufen. Déi wichtegst Saach ass datt dës Donnéeën bequem sinn ze kréien, benotzt se a Berichter, Grafiken, Ausléiser, an e puer Schwellwäerter, fir Alarmer, asw.
Déi drëtt Performance Erausfuerderung ass d'Geschicht Clearing, dat ass, wann Dir op de Punkt kënnt wou Dir keng detailléiert Metriken braucht, déi iwwer 5 Joer gesammelt goufen (och Méint oder zwee Méint). E puer Netzknäppchen goufen geläscht, oder e puer Hosten, d'Metriken sinn net méi gebraucht well se scho verännert sinn an net méi gesammelt sinn. All dëst muss gebotzt ginn fir datt Är Datebank net ze grouss gëtt. Allgemeng ass d'Cleargeschicht meeschtens e seriöse Test fir d'Lagerung - et huet dacks e ganz staarken Impakt op d'Leeschtung.
Wéi Cache Problemer ze léisen?
Ech wäert elo speziell iwwer Zabbix schwätzen. An Zabbix ginn déi éischt an zweet Uruff mat Caching geléist.
Datesammlung a Veraarbechtung - Mir benotzen RAM fir all dës Donnéeën ze späicheren. Dës Donnéeë wäert elo méi am Detail diskutéiert ginn.
Och op der Datebank Säit gëtt et e puer Cache fir Haaptauswielen - fir Grafiken an aner Saachen.
Caching op der Säit vum Zabbix Server selwer: mir hunn ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Wat ass et?
ConfigurationCache ass den Haaptcache an deem mir Metriken, Hosten, Datenartikelen, Trigger späicheren; alles wat Dir braucht fir d'Virveraarbechtung ze verarbeiten, d'Donnéeën ze sammelen, vu wéi enge Hosten ze sammelen, mat wéi enger Frequenz. All dëst gëtt am ConfigurationCache gespäichert fir net an d'Datebank ze goen an onnéideg Ufroen ze kreéieren. Nodeems de Server ufänkt, aktualiséieren mir dëse Cache (erstellen) an aktualiséieren se periodesch (je no Konfiguratiounsastellungen).
Caching an Zabbix. Datensammlung
Hei ass d'Diagramm zimlech grouss:
D'Haaptrei am Schema sinn dës Sammler:
Dëst sinn d'Versammlungsprozesser selwer, verschidde "Poller", déi fir verschidden Aarte vu Versammlungen verantwortlech sinn. Si sammelen Daten iwwer icmp, ipmi, a verschidde Protokoller an iwwerdroen alles op d'Virveraarbechtung.
PreProcessing HistoryCache
Och, wa mir Daten Elementer berechent hunn (déi, déi mat Zabbix kennt wëssen), dat ass, berechent, Aggregatioun Daten Elementer, mir huelen se direkt aus ValueCache. Ech soen Iech méi spéit wéi et gefëllt ass. All dës Sammler benotzen ConfigurationCache fir hir Aarbecht ze kréien an se dann op d'Virveraarbechtung weiderginn.
Preprocessing benotzt och ConfigurationCache fir Preprocessing Schrëtt ze kréien a veraarbecht dës Donnéeën op verschidde Manéieren. Vun der Versioun 4.2 un hu mir et op e Proxy geplënnert. Dëst ass ganz bequem, well d'Virveraarbechtung selwer eng zimlech schwéier Operatioun ass. A wann Dir e ganz grousse Zabbix hutt, mat enger grousser Unzuel vun Datenelementer an enger héijer Sammelfrequenz, da vereinfacht dëst d'Aarbecht immens.
Deementspriechend, nodeems mir dës Donnéeën op iergendeng Manéier mat der Virveraarbechtung veraarbecht hunn, späichere mir se am HistoryCache fir se weider ze veraarbecht. Dëst schléisst d'Datesammlung of. Mir ginn op den Haaptprozess.
Geschicht Synchroner Aarbecht
Den Haaptprozess am Zabbix (well et eng monolithesch Architektur ass) ass d'Geschicht Synchroniséierung. Dëst ass den Haaptprozess dee speziell mat der atomarer Veraarbechtung vun all Dateelement beschäftegt, dat heescht all Wäert:
- de Wäert kënnt (et hëlt et aus HistoryCache);
- Kontrollen am Configuratioun Synchroniséierung: ob et Ausléiser fir d'Berechnung gëtt - berechent se;
wann et ass - erstellt Eventer, erstellt Eskalatioun fir eng Alarm ze kreéieren, wann néideg no der Konfiguratioun; - records Trigger fir spéider Veraarbechtung, Aggregatioun; wann Dir iwwer déi lescht Stonn a sou weider aggregéiert, gëtt dëse Wäert vum ValueCache erënnert fir net an d'Geschichtstabell ze goen; Also ass de ValueCache mat den néidegen Donnéeën gefëllt, déi néideg sinn fir Ausléiser ze berechnen, berechent Elementer, etc.;
- da schreift History Syncer all Daten an d'Datebank;
- d'Datebank schreift se op Disk - dat ass wou de Veraarbechtungsprozess ophält.
Datebank. Caching
Op der Datebank Säit, wann Dir Grafike wëllt gesinn oder e puer Berichter iwwer Eventer, ginn et verschidde Cache. Mä an dësem Rapport wäert ech net iwwer hinnen schwätzen.
Fir MySQL gëtt et Innodb_buffer_pool, an eng Rëtsch vu verschiddene Cache déi och konfiguréiert kënne ginn.
Awer dëst sinn d'Haaptgrënn:
- shared_buffers;
- efficace_cache_size;
- shared_pool.
Fir all Datenbanken, sot ech, datt et bestëmmte Cache sinn, datt Dir am RAM d'Donnéeën ze Buttek erlaabt, datt fir Ufroen oft néideg ass. Si hunn hir eege Technologien fir dëst.
Iwwert Datebank Leeschtung
Deementspriechend gëtt et e kompetitivt Ëmfeld, dat heescht, den Zabbix Server sammelt Daten a registréiert se. Wann et nei gestart gëtt, liest et och aus der Geschicht fir de ValueCache auszefëllen an sou weider. Hei kënnt Dir Scripten a Berichter hunn, déi d'Zabbix API benotzen, déi op engem Webinterface gebaut ass. Zabbix API gitt an d'Datebank a kritt déi néideg Donnéeën fir Grafiken, Berichter oder eng Aart Lëscht vun Eventer ze kréien, rezent Probleemer.
Och eng ganz populär Visualiséierungsléisung ass Grafana, déi eis Benotzer benotzen. Kënnen direkt aloggen souwuel duerch d'Zabbix API an duerch d'Datebank. Et schaaft och eng gewëssen Konkurrenz fir Daten ze kréien: eng méi fein, besser Ofstëmmung vun der Datebank ass néideg fir d'rapid Liwwerung vu Resultater an Tester ze respektéieren.
Läscht Geschicht. Zabbix huet Haushälterin
Den drëtten Uruff deen am Zabbix benotzt gëtt ass d'Geschicht vun der Haushalter läschen. Haushälter follegt all Astellungen, dat heescht, eis Dateelementer weisen wéi laang ze späicheren (an Deeg), wéi laang Trends späicheren an d'Dynamik vun Ännerungen.
Ech hunn net iwwer TrendCache geschwat, dee mir op der Flucht berechent hunn: Daten kommen, mir aggregéiere se fir eng Stonn (meeschtens sinn dat Zuelen fir déi lescht Stonn), de Betrag ass duerchschnëttlech/minimum a mir notéieren et eemol d'Stonn an der Dësch vun der Dynamik vun Ännerungen ("Trends"). "Housekeeper" fänkt un a läscht Daten aus der Datebank mat regelméissege Selektiounen, wat net ëmmer effektiv ass.
Wéi ze verstoen datt et net effikass ass? Dir kënnt déi folgend Bild op de Leeschtungsgrafiken vun interne Prozesser gesinn:
Äre Geschicht Synchroniséierung ass dauernd beschäftegt (roude Grafik). An déi "rout" Grafik déi uewen geet. Dëst ass e "Housekeeper" deen ufänkt a waart op d'Datebank fir all d'Reihen ze läschen déi se spezifizéiert huet.
Loosst eis e puer Element ID huelen: Dir musst déi lescht 5 dausend läschen; natierlech, duerch Indizes. Awer normalerweis ass d'Datebank zimlech grouss - d'Datebank liest se nach ëmmer vun der Disk a setzt se an de Cache, an dëst ass eng ganz deier Operatioun fir d'Datebank. Ofhängeg vu senger Gréisst, kann dëst zu bestëmmte Leeschtungsproblemer féieren.
Dir kënnt Housekeeper op eng einfach Manéier auszeschalten - mir hunn e vertraute Webinterface. Astellungen an der Administratioun allgemeng (Astellunge fir "Housekeeper") mir deaktivéieren intern Haushälterin fir intern Geschicht an Trends. Deementspriechend kontrolléiert Haushalter dëst net méi:
Wat kënnt Dir als nächst maachen? Dir hutt et ausgeschalt, Är Grafike sinn ausgeglach ... Wéi eng weider Problemer kënnen an dësem Fall entstoen? Wat kann hëllefen?
Deelen (Sektioun)
Typesch ass dëst op eng aner Manéier op all relational Datebank konfiguréiert, déi ech opgezielt hunn. MySQL huet seng eege Technologie. Awer insgesamt si se ganz ähnlech wann et ëm PostgreSQL 10 a MySQL kënnt. Natierlech ginn et vill intern Differenzen a wéi et alles ëmgesat gëtt a wéi et alles d'Performance beaflosst. Awer allgemeng féiert d'Schafung vun enger neier Partition dacks och zu bestëmmte Problemer.
Ofhängeg vun Ärem Setup (wéi vill Daten Dir an engem Dag erstellt), setzen se normalerweis de Minimum - dëst ass 1 Dag / Batch, a fir "Trends", Dynamik vun Ännerungen - 1 Mount / nei Batch. Dëst kann änneren wann Dir e ganz grousse Setup hutt.
Loosst eis direkt iwwer d'Gréisst vum Setup soen: bis zu 5 dausend nei Wäerter pro Sekonn (sougenannte nvps) - dëst gëtt als kleng "Setup" ugesinn. Duerchschnëtt - vu 5 bis 25 dausend Wäerter pro Sekonn. Alles wat uewen ass scho grouss a ganz grouss Installatiounen déi ganz virsiichteg Konfiguratioun vun der Datebank erfuerderen.
Op ganz groussen Installatiounen kann 1 Dag net optimal sinn. Ech perséinlech hunn Partitionen op MySQL vu 40 Gigabytes pro Dag gesinn (an et ka méi sinn). Dëst ass eng ganz grouss Quantitéit un Daten, déi zu e puer Probleemer féieren kann. Et muss reduzéiert ginn.
Firwat braucht Dir Partitionéierung?
Wat d'Partitionéierung ubitt, mengen ech, jidderee weess, ass Dëschpartitionéierung. Dacks sinn dës separat Dateien op Disk a Spann Ufroen. Et wielt eng Partition méi optimal wann et Deel vun der normaler Partition ass.
Besonnesch fir Zabbix gëtt et duerch Range benotzt, no Range, dat heescht, mir benotzen en Zäitstempel (eng regulär Zuel, Zäit zanter dem Ufank vun der Epoch). Dir spezifizéiert den Ufank vum Dag / Enn vum Dag, an dëst ass d'Partition. Deementspriechend, wann Dir no Daten freet, déi zwee Deeg al sinn, gëtt alles méi séier aus der Datebank zréckgezunn, well Dir braucht nëmmen eng Datei an de Cache ze lueden an zréckzebréngen (anstatt e groussen Dësch).
Vill Datenbanken beschleunegen och Insert (Insertion an eng Kannertabell). Ech schwätzen elo abstrakt, mee dat ass och méiglech. Partitoning hëlleft dacks.
Elasticsearch fir NoSQL
Viru kuerzem, am 3.4, hu mir eng NoSQL Léisung implementéiert. D'Fäegkeet bäigefüügt fir an Elasticsearch ze schreiwen. Dir kënnt verschidden Zorte schreiwen: Dir wielt - entweder schreiwen Zuelen oder e puer Schëlder; mir hunn String Text, Dir kënnt Logbicher op Elasticsearch schreiwen ... Deementspriechend wäert d'Webinterface och op Elasticsearch kommen. Dëst funktionnéiert gutt an e puer Fäll, awer am Moment kann et benotzt ginn.
Zäitskala DB. Hypertabellen
Fir 4.4.2 hu mir op eng Saach wéi TimescaleDB opmierksam gemaach. Wat ass et? Dëst ass eng Extensioun fir PostgreSQL, dat heescht, et huet eng gebierteg PostgreSQL Interface. Plus, dës Extensioun erlaabt Iech vill méi effizient mat Zäitseriedaten ze schaffen an automatesch Partitionéierung ze hunn. Wéi et ausgesäit:
Dëst ass hypertabel - et gëtt sou e Konzept an der Timescale. Dëst ass en Hypertabell deen Dir erstellt, an et enthält Stécker. Chunks sinn Partitionen, dëst sinn Kannerdëscher, wann ech mech net verwiesselen. Et ass wierklech effektiv.
TimescaleDB an PostgreSQL
Wéi d'TimescaleDB Hiersteller versécheren, benotze se e méi korrekten Algorithmus fir Ufroen ze veraarbecht, besonnesch Inserts, wat et hinnen erlaabt ongeféier konstant Leeschtung mat enger ëmmer méi grousser Gréisst vun der Dataset Insert ze hunn. Dat ass, no 200 Millioune Reihen vu Postgres, fänkt de gewéinleche ganz vill ze sagen a verléiert d'Performance wuertwiertlech op Null, während Timescale erlaabt Iech Inserts esou effizient wéi méiglech mat all Quantitéit un Daten ze setzen.
Wéi installéiere ech TimescaleDB? Et ass einfach!
Et ass an der Dokumentatioun, et ass beschriwwen - Dir kënnt et aus Packagen fir all installéieren ... Et hänkt vun den offiziellen Postgres Packagen of. Kann manuell kompiléiert ginn. Et ass geschitt, datt ech fir d'Datebank kompiléiere muss.
Op Zabbix aktivéiere mir einfach Extensioun. Ech denken, datt déi, déi Extensioun an Postgres benotzt hunn ... Dir aktivéiert einfach Extensioun, erstellt se fir d'Zabbix Datebank déi Dir benotzt.
An de leschte Schrëtt ...
Zäitskala DB. Migratioun vun Geschicht Dëscher
Dir musst en Hypertabell erstellen. Et gëtt eng speziell Funktioun fir dëst - Hypertable erstellen. An et ass den éischte Parameter den Dësch, deen an dëser Datebank gebraucht gëtt (fir deen Dir en Hypertable erstellen musst).
D'Feld fir ze kreéieren, an chunk_time_interval (dëst ass den Intervall vu Stécker (Partitionen déi benotzt musse ginn). 86 ass een Dag.
Migrate_data Parameter: Wann Dir op richteg asetzt, da migréiert dëst all aktuell Donnéeën op virgeschaaft Stécker.
Ech hunn migrate_data selwer benotzt - et hëlt eng fair Zäit, jee no wéi grouss Är Datebank ass. Ech hat iwwer en Terabyte - et huet iwwer eng Stonn gedauert fir ze kreéieren. An e puer Fäll, wärend dem Test, hunn ech historesch Daten fir Text (history_text) a String (history_str) geläscht fir se net ze transferéieren - si ware fir mech net wierklech interessant.
A mir maachen de leschten Update an eiser db_extention: mir installéieren timescaledb sou datt d'Datebank a besonnesch eisen Zabbix versteet datt et db_extention gëtt. Hien aktivéiert et a benotzt déi richteg Syntax an Ufroen un d'Datebank, mat deene "Features" déi néideg sinn fir TimescaleDB.
Server Konfiguratioun
Ech hunn zwee Serveren benotzt. Den éischte Server ass eng zimlech kleng virtuell Maschinn, 20 Prozessoren, 16 Gigabytes RAM. Ech hunn Postgres 10.8 drop konfiguréiert:
De Betribssystem war Debian, de Dateiesystem war xfs. Ech hunn minimal Astellunge gemaach fir dës speziell Datebank ze benotzen, minus wat Zabbix selwer benotzt. Op der selwechter Maschinn gouf et e Zabbix Server, PostgreSQL a Lastagenten.
Ech hunn 50 aktiv Agenten benotzt déi LoadableModule benotze fir séier verschidde Resultater ze generéieren. Si sinn déi, déi d'Strings, d'Zuelen, asw. Ech hunn d'Datebank mat vill Daten gefëllt. Am Ufank huet d'Konfiguratioun 5 Tausend Datenelementer pro Host enthalen, an ongeféier all Dateelement enthält en Ausléiser - fir datt dëst e richtege Setup ass. Heiansdo brauch Dir souguer méi wéi een Ausléiser fir ze benotzen.
Ech hunn d'Aktualiséierungsintervall an d'Laascht selwer geregelt andeems ech net nëmmen 50 Agenten benotzen (méi addéieren), awer och dynamesch Datenelementer benotzen an den Updateintervall op 4 Sekonnen reduzéieren.
Leeschtung Test. PostgreSQL: 36 dausend NVPs
Den éischte Start, den éischte Setup deen ech hat war op pure PostreSQL 10 op dëser Hardware (35 Tausend Wäerter pro Sekonn). Am Allgemengen, wéi Dir um Écran gesitt, dauert d'Insertéierung vun Daten Fraktiounen vun enger Sekonn - alles ass gutt a séier, SSD fiert (200 Gigabytes). Déi eenzeg Saach ass datt 20 GB ganz séier fëllt.
Et wäerten an Zukunft zimlech vill esou Grafike ginn. Dëst ass e Standard Zabbix Server Performance Dashboard.
Déi éischt Grafik ass d'Zuel vun de Wäerter pro Sekonn (blo, uewe lénks), 35 dausend Wäerter an dësem Fall. Dëst (uewen Zentrum) ass d'Luede vun Bau Prozesser, an dëst (uewen riets) ass d'Luede vun intern Prozesser: Geschicht Syncer an Haushälterin, déi hei (ënnen Zentrum) fir eng laang Zäit leeft.
Dës Grafik (ënnen Zentrum) weist ValueCache Notzung - wéivill ValueCache Hits fir Ausléiser (e puer dausend Wäerter pro Sekonn). Eng aner wichteg Grafik ass déi véiert (ënnescht lénks), déi d'Benotzung vum HistoryCache weist, iwwer deen ech geschwat hunn, wat e Puffer ass ier Dir an d'Datebank setzt.
Leeschtung Test. PostgreSQL: 50 dausend NVPs
Als nächst hunn ech d'Laascht op 50 Tausend Wäerter pro Sekonn op der selwechter Hardware erhéicht. Wann Dir vum Hausmeeschter gelueden ass, goufen 10 Tausend Wäerter an 2-3 Sekonnen mat der Berechnung opgeholl. Wat, tatsächlech, gëtt am folgende Screenshot gewisen:
"Housekeeper" fänkt schonn un Aarbecht ze Amëschung, mä am Allgemengen, ass d'Laascht op Geschicht-Sinker Trapper nach um Niveau vun 60% (drëtt Grafik, uewen riets). HistoryCache fänkt schonn aktiv un ze fëllen wärend Housekeeper leeft (ënnescht lénks). Et war ongeféier en halleft Gigabyte, 20% voll.
Leeschtung Test. PostgreSQL: 80 dausend NVPs
Dunn hunn ech et op 80 Tausend Wäerter pro Sekonn erhéicht:
Et waren ongeféier 400 Tausend Datenelementer, 280 Tausend Ausléiser. Den Insert, wéi Dir gesitt, wat d'Belaaschtung vun de Geschichtssinker ugeet (et waren der 30) war schonn zimlech héich. Dunn hunn ech verschidde Parameteren erhéicht: Geschicht Sinks, Cache ... Op dëser Hardware huet d'Laascht op Geschicht Sinks ugefaang maximal ze erhéijen, bal "um Regal" - deementspriechend ass HistoryCache an eng ganz héich Laascht gaangen:
All dës Kéier hunn ech all Systemparameter iwwerwaacht (wéi de Prozessor benotzt gëtt, RAM) an entdeckt datt d'Disknutzung maximal war - ech hunn déi maximal Kapazitéit vun dëser Disk op dëser Hardware, op dëser virtueller Maschinn erreecht. "Postgres" huet ugefaang Donnéeën zimlech aktiv mat esou Intensitéit ze dumpen, an d'Disk hat keng Zäit méi ze schreiwen, ze liesen ...
Ech hunn en anere Server geholl, dee scho 48 Prozessoren an 128 Gigabytes RAM hat:
Ech hunn et och "gestëmmt" - installéiert History Syncer (60 Stéck) an erreecht akzeptabel Leeschtung. Tatsächlech si mir net "op dem Regal", awer dëst ass wahrscheinlech d'Limite vun der Produktivitéit, wou et scho néideg ass eppes doriwwer ze maachen.
Leeschtung Test. ZäitskalaDB: 80 dausend NVPs
Meng Haaptaufgab war TimescaleDB ze benotzen. All Grafik weist en Dip:
Dës Feeler si genee Datemigratioun. Duerno, am Zabbix-Server, huet de Luedeprofil vun de Geschichtsinker, wéi Dir gesitt, vill geännert. Et erlaabt Iech Daten bal 3 Mol méi séier anzeginn a manner HistoryCache ze benotzen - deementspriechend kritt Dir Daten zu Zäit geliwwert. Erëm, 80 dausend Wäerter pro Sekonn ass eng zimlech héich Taux (natierlech net fir Yandex). Insgesamt ass dëst e relativ grousse Setup, mat engem Server.
PostgreSQL Leeschtung Test: 120 dausend NVPs
Als nächst hunn ech de Wäert vun der Unzuel vun Datenelementer op eng hallef Millioun erhéicht a krut e berechent Wäert vun 125 Tausend pro Sekonn:
An ech hunn dës Grafiken:
Am Prinzip ass dëst e funktionnéierende Setup, et kann zimmlech laang funktionnéieren. Awer well ech nëmmen en 1,5 Terabyte Disk hat, hunn ech se an e puer Deeg benotzt. Déi wichtegst Saach ass datt gläichzäiteg nei Partitionen op TimescaleDB erstallt goufen, an dëst war komplett onnotéiert fir d'Performance, wat net iwwer MySQL gesot ka ginn.
Typesch ginn Partitionen an der Nuecht erstallt, well dëst allgemeng d'Insertion blockéiert an d'Aarbecht mat Dëscher blockéiert a kann zu enger Degradatioun vum Service féieren. An dësem Fall ass dat net de Fall! D'Haaptaufgab war d'Fäegkeete vun TimescaleDB ze testen. D'Resultat war déi folgend Figur: 120 dausend Wäerter pro Sekonn.
Et ginn och Beispiller an der Gemeinschaft:
D'Persoun huet och TimescaleDB an d'Laascht op benotzt io.Gewiicht erof op de Prozessor; an d'Benotzung vun internen Prozesselementer ass och erofgaang wéinst der Inklusioun vun TimescaleDB. Ausserdeem sinn dës gewéinlech Pancakesdisks, dat heescht eng gewéinlech virtuell Maschinn op gewéinleche Disken (net SSDs)!
Fir e puer kleng Setups déi limitéiert sinn duerch Disk Performance, TimescaleDB, menger Meenung no, ass eng ganz gutt Léisung. Et erlaabt Iech weider ze schaffen ier Dir op méi séier Hardware fir d'Datebank migréiert.
Ech invitéieren Iech all op eis Evenementer: Konferenz zu Moskau, Sommet zu Riga. Benotzt eis Kanäl - Telegram, Forum, IRC. Wann Dir Froen hutt, kommt op eise Büro, mir kënnen iwwer alles schwätzen.
Publikum Froen
Fro vum Publikum (nodréiglech - A): - Wann TimescaleDB sou einfach ass ze konfiguréieren, an et gëtt esou e Performance Boost, da sollt dëst vläicht als bescht Praxis benotzt ginn fir Zabbix mat Postgres ze konfiguréieren? A ginn et Falen an Nodeeler vun dëser Léisung, oder schliisslech, wann ech beschloss Zabbix fir mech selwer ze maachen, kann ech einfach Postgres huelen, Timescale do direkt installéieren, se benotzen an net iwwer Probleemer denken?
AG: - Jo, ech géif soen datt dëst eng gutt Empfehlung ass: benotzt Postgres direkt mat der TimescaleDB Extensioun. Wéi scho gesot, vill gutt Kritiken, trotz der Tatsaach, datt dës "Feature" experimentell ass. Awer tatsächlech Tester weisen datt dëst eng super Léisung ass (mat TimescaleDB) an ech mengen et wäert sech entwéckelen! Mir iwwerwaachen wéi dës Verlängerung sech entwéckelt a wäerte wéi néideg Ännerungen maachen.
Och während der Entwécklung hu mir op ee vun hire bekannte "Features" vertraut: et war méiglech mat Stécker e bëssen anescht ze schaffen. Awer dunn hunn se et an der nächster Verëffentlechung ofgeschnidden, a mir hu misse stoppen op dëse Code ze vertrauen. Ech géif recommandéieren dës Léisung op ville Setups ze benotzen. Wann Dir MySQL benotzt ... Fir duerchschnëttlech Setups funktionnéiert all Léisung gutt.
A: – Op deene leschte Grafike vun der Gemeng gouf et eng Grafik mam „Housekeeper“:
Hien huet weider geschafft. Wat mécht Hausmeeschter mat TimescaleDB?
AG: - Elo kann ech net sécher soen - ech kucken de Code a soen Iech méi detailléiert. Et benotzt TimescaleDB Ufroen net fir Stécker ze läschen, awer fir se iergendwéi aggregéiert ze ginn. Ech sinn nach net prett dës technesch Fro ze beäntweren. Méi gewuer gi mir haut oder muer um Stand.
A: - Ech hunn eng ähnlech Fro - iwwer d'Leeschtung vun der Läschen Operatioun am Timescale.
A (Äntwert vum Publikum): - Wann Dir Daten aus engem Dësch läscht, wann Dir et iwwer Läschen maacht, da musst Dir duerch den Dësch goen - läschen, botzen, markéieren alles fir zukünfteg Vakuum. An Timescale, well Dir Stécker hutt, kënnt Dir erofsetzen. Grof geschwat, sot Dir einfach der Datei déi a Big Data ass: "Läschen!"
Timescale versteet einfach datt esou e Stéck net méi gëtt. A well et an de Query Planner integréiert ass, benotzt et Haken fir Är Konditiounen a wielt oder aner Operatiounen ze fangen a versteet direkt datt dëse Stéck net méi existéiert - "Ech ginn net méi dohinner!" (Daten net verfügbar). Dat ass alles! Dat ass, en Dësch Scan gëtt duerch eng binär Datei Läsch ersat, sou datt et séier ass.
A: - Mir hu schonn d'Thema vun Net-SQL beréiert. Sou wäit wéi ech verstinn, brauch Zabbix net wierklech d'Donnéeën z'änneren, an dat alles ass eppes wéi e Log. Ass et méiglech spezialiséiert Datenbanken ze benotzen, déi hir Donnéeën net änneren, awer gläichzäiteg vill méi séier späicheren, accumuléieren a verdeelen - Clickhouse, zum Beispill, eppes Kafka-ähnlechen?.. Kafka ass och e Log! Ass et méiglech se iergendwéi z'integréieren?
AG: - Ausluede kann gemaach ginn. Mir hunn eng gewësse "Feature" zënter Versioun 3.4: Dir kënnt all historesch Dateien, Eventer, alles anescht op Dateien schreiwen; a schéckt et dann op all aner Datebank mat engem Handler. Tatsächlech reworken vill Leit a schreiwen direkt an d'Datebank. Iwwerdeems schreiwen Geschicht Sinks all dëst an Fichieren, rotéieren dës Fichieren, an sou op, an Dir kënnt dëst zu Clickhouse Transfert. Ech kann net iwwer Pläng soen, awer vläicht weider Ënnerstëtzung fir NoSQL Léisungen (wéi Clickhouse) wäert weidergoen.
A: - Am Allgemengen, stellt sech eraus, datt Dir komplett vun postgres lass kréien kann?
AG: - Natierlech ass de schwieregsten Deel am Zabbix déi historesch Dëscher, déi déi meeschte Probleemer an Eventer kreéieren. An dësem Fall, wann Dir keng Eventer fir eng laang Zäit späichert an d'Geschicht mat Trends an e puer anere schnelle Späichere späichert, dann am Allgemengen, mengen ech, gëtt et keng Probleemer.
A: - Kënnt Dir schätzen wéi vill méi séier alles funktionnéiert wann Dir zum Beispill op Clickhouse wiesselt?
AG: - Ech hunn et net getest. Ech denken datt op d'mannst déiselwecht Zuelen ganz einfach erreecht kënne ginn, well Clickhouse seng eegen Interface huet, awer ech kann net sécher soen. Et ass besser ze testen. Et hänkt alles vun der Konfiguratioun of: wéivill Hosten Dir hutt, a sou weider. Asetzen ass eng Saach, awer Dir musst och dës Donnéeën recuperéieren - Grafana oder soss eppes.
A: - Mir schwätzen also vun engem gläichberechtegten Kampf, an net iwwer de grousse Virdeel vun dëse schnelle Datenbanken?
AG: - Ech mengen, wa mir integréieren, ginn et méi genee Tester.
A: – Wou ass de gudden alen RRD gaangen? Wat huet Iech gemaach fir op SQL Datenbanken ze wiesselen? Am Ufank goufen all Metriken op RRD gesammelt.
AG: - Zabbix hat RRD, vläicht an enger ganz antiker Versioun. Et goufen ëmmer SQL Datenbanken - eng klassesch Approche. Déi klassesch Approche ass MySQL, PostgreSQL (si hu scho ganz laang existéiert). Mir hunn bal ni eng gemeinsam Interface fir SQL an RRD Datenbanken benotzt.
Puer Annoncen 🙂
Merci datt Dir bei eis bleift. Hutt Dir eis Artikelen gär? Wëllt Dir méi interessant Inhalt gesinn? Ënnerstëtzt eis andeems Dir eng Bestellung maacht oder Frënn empfeelt, , en eenzegaartegen Analog vun Entry-Level Serveren, dee vun eis fir Iech erfonnt gouf: (verfügbar mat RAID1 an RAID10, bis zu 24 Kären a bis zu 40GB DDR4).
Dell R730xd 2 Mol méi bëlleg an Equinix Tier IV Daten Zentrum zu Amsterdam? Nëmmen hei an Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vun $99! Liest iwwer
Source: will.com