We zullen bekijken hoe Zabbix werkt met de TimescaleDB-database als backend. We laten u zien hoe u helemaal opnieuw kunt beginnen en hoe u vanuit PostgreSQL kunt migreren. We zullen ook vergelijkende prestatietests van de twee configuraties uitvoeren.
HighLoad++ Siberië 2019. Tomsk Hall. 24 juni, 16:00 uur. Scripties en . De volgende HighLoad++ conferentie vindt plaats op 6 en 7 april 2020 in St. Petersburg. Details en kaartjes .
Andrey Gushchin (hierna – AG): – Ik ben een technische ondersteuningsingenieur van ZABBIX (hierna “Zabbix” genoemd), een trainer. Ik werk al meer dan 6 jaar in de technische ondersteuning en heb directe ervaring met performance. Vandaag zal ik het hebben over de prestaties die TimescaleDB kan bieden in vergelijking met het reguliere PostgreSQL 10. Ook een inleidend gedeelte over hoe het in het algemeen werkt.
Belangrijkste productiviteitsuitdagingen: van gegevensverzameling tot gegevensopschoning
Om te beginnen zijn er bepaalde prestatie-uitdagingen waarmee elk monitoringsysteem wordt geconfronteerd. De eerste productiviteitsuitdaging is het snel verzamelen en verwerken van gegevens.
Een goed monitoringsysteem moet snel en tijdig alle gegevens ontvangen, deze verwerken volgens triggerexpressies, dat wil zeggen, deze verwerken volgens bepaalde criteria (dit is in verschillende systemen anders) en deze opslaan in een database om deze gegevens te gebruiken in de toekomst.
De tweede prestatie-uitdaging is de opslag van geschiedenis. Bewaar ze vaak in een database en krijg snel en gemakkelijk toegang tot deze statistieken die in de loop van de tijd zijn verzameld. Het belangrijkste is dat deze gegevens gemakkelijk te verkrijgen zijn en te gebruiken in rapporten, grafieken, triggers, in sommige drempelwaarden, voor waarschuwingen, enz.
De derde prestatie-uitdaging is het opschonen van de geschiedenis, dat wil zeggen wanneer u het punt bereikt waarop u geen gedetailleerde statistieken meer hoeft op te slaan die over een periode van vijf jaar (zelfs maanden of twee maanden) zijn verzameld. Sommige netwerkknooppunten zijn verwijderd of bij sommige hosts zijn de statistieken niet langer nodig omdat ze al verouderd zijn en niet langer worden verzameld. Dit alles moet worden opgeruimd, zodat uw database niet te groot wordt. Over het algemeen is het wissen van de geschiedenis meestal een serieuze test voor de opslag; het heeft vaak een zeer sterke invloed op de prestaties.
Hoe cacheproblemen oplossen?
Ik zal het nu specifiek hebben over Zabbix. In Zabbix worden de eerste en tweede oproep opgelost met behulp van caching.
Gegevensverzameling en -verwerking - We gebruiken RAM om al deze gegevens op te slaan. Deze gegevens zullen nu in meer detail worden besproken.
Ook aan de databasekant is er wat caching voor de belangrijkste selecties - voor grafieken en andere dingen.
Caching aan de kant van de Zabbix-server zelf: we hebben ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Wat het is?
ConfigurationCache is de hoofdcache waarin we statistieken, hosts, gegevensitems en triggers opslaan; alles wat je nodig hebt om de voorbewerking te verwerken, gegevens te verzamelen, van welke hosts je moet verzamelen, met welke frequentie. Dit alles wordt opgeslagen in ConfigurationCache om niet naar de database te gaan en onnodige zoekopdrachten te maken. Nadat de server is opgestart, updaten we deze cache (aanmaken) en werken we deze periodiek bij (afhankelijk van de configuratie-instellingen).
Caching in Zabbix. Gegevensverzameling
Hier is het diagram vrij groot:
De belangrijkste in het schema zijn deze verzamelaars:
Dit zijn de assemblageprocessen zelf, verschillende ‘pollers’ die verantwoordelijk zijn voor verschillende soorten assemblages. Ze verzamelen gegevens via icmp, ipmi en verschillende protocollen en zetten deze allemaal over naar de voorverwerking.
Geschiedeniscache vooraf verwerken
En als we gegevenselementen hebben berekend (degenen die bekend zijn met Zabbix weten het), dat wil zeggen berekende aggregatiegegevenselementen, halen we deze rechtstreeks uit ValueCache. Hoe hij gevuld wordt vertel ik later. Al deze verzamelprogramma's gebruiken ConfigurationCache om hun taken te ontvangen en deze vervolgens door te geven aan de voorverwerking.
Voorverwerking maakt ook gebruik van ConfigurationCache om voorverwerkingsstappen te verkrijgen en verwerkt deze gegevens op verschillende manieren. Vanaf versie 4.2 hebben we het naar een proxy verplaatst. Dit is erg handig, omdat het voorbewerken zelf een nogal moeilijke handeling is. En als je een hele grote Zabbix hebt, met een groot aantal data-elementen en een hoge verzamelfrequentie, dan vereenvoudigt dit het werk enorm.
Nadat we deze gegevens op de een of andere manier hebben verwerkt met behulp van voorverwerking, slaan we deze daarom op in HistoryCache om ze verder te verwerken. Hiermee is de gegevensverzameling afgerond. We gaan verder met het hoofdproces.
Het werk van de geschiedenissynchronisatie
Het belangrijkste proces in Zabbix (aangezien het een monolithische architectuur is) is History syncer. Dit is het hoofdproces dat zich specifiek bezighoudt met de atomaire verwerking van elk data-element, dat wil zeggen elke waarde:
- de waarde komt (deze wordt overgenomen van HistoryCache);
- controleert in Configuratiesynchronisatie: of er triggers zijn voor berekening - berekent deze;
als dat zo is: creëert gebeurtenissen, creëert escalatie om een waarschuwing te creëren, indien nodig volgens de configuratie; - registreert triggers voor daaropvolgende verwerking, aggregatie; als u het afgelopen uur aggregeert, enzovoort, wordt deze waarde door ValueCache onthouden, zodat deze niet naar de geschiedenistabel gaat; Zo wordt de ValueCache gevuld met de nodige gegevens die nodig zijn om triggers, berekende elementen, etc. te berekenen;
- vervolgens schrijft History syncer alle gegevens naar de database;
- de database schrijft ze naar schijf - hier eindigt het verwerkingsproces.
Database. Caching
Aan de databasekant, als u grafieken of rapporten over gebeurtenissen wilt bekijken, zijn er verschillende caches. Maar in dit rapport zal ik er niet over praten.
Voor MySQL is er Innodb_buffer_pool en een aantal verschillende caches die ook kunnen worden geconfigureerd.
Maar dit zijn de belangrijkste:
- gedeelde_buffers;
- effectieve_cache_grootte;
- gedeeld zwembad.
Voor alle databases zei ik dat er bepaalde caches zijn waarmee je de gegevens die vaak nodig zijn voor zoekopdrachten in RAM kunt opslaan. Ze hebben hiervoor hun eigen technologieën.
Over databaseprestaties
Dienovereenkomstig is er een competitieve omgeving, dat wil zeggen dat de Zabbix-server gegevens verzamelt en registreert. Wanneer het opnieuw wordt opgestart, leest het ook uit de geschiedenis om de ValueCache te vullen, enzovoort. Hier kunt u scripts en rapporten gebruiken die de Zabbix API gebruiken, die op een webinterface is gebouwd. Zabbix API komt de database binnen en ontvangt de nodige gegevens om grafieken, rapporten of een soort lijst met gebeurtenissen en recente problemen te verkrijgen.
Ook een zeer populaire visualisatieoplossing is Grafana, die onze gebruikers gebruiken. Kan direct inloggen via de Zabbix API en via de database. Het creëert ook een zekere concurrentie om het verkrijgen van gegevens: een fijnere, betere afstemming van de database is nodig om te voldoen aan de snelle levering van resultaten en testen.
Geschiedenis wissen. Zabbix heeft huishoudster
De derde oproep die in Zabbix wordt gebruikt, is het wissen van de geschiedenis met behulp van Housekeeper. Housekeeper volgt alle instellingen, dat wil zeggen dat onze gegevenselementen aangeven hoe lang we moeten bewaren (in dagen), hoe lang we trends moeten opslaan en de dynamiek van veranderingen.
Ik had het niet over TrendCache, die we on-the-fly berekenen: de gegevens komen binnen, we verzamelen deze voor een uur (meestal zijn dit cijfers van het afgelopen uur), de hoeveelheid is gemiddeld/minimum en we registreren deze een keer per uur in de tabel met de dynamiek van veranderingen (“Trends”) . “Huishoudster” start en verwijdert gegevens uit de database met behulp van regelmatige selecties, wat niet altijd effectief is.
Hoe te begrijpen dat het niet effectief is? U kunt het volgende beeld zien op de prestatiegrafieken van interne processen:
Uw geschiedenissynchronisatie is voortdurend bezig (rode grafiek). En de “rode” grafiek die bovenaan staat. Dit is een “huishoudster” die start en wacht tot de database alle opgegeven rijen heeft verwijderd.
Laten we een artikel-ID nemen: u moet de laatste 5 verwijderen; uiteraard via indexen. Maar meestal is de dataset behoorlijk groot: de database leest deze nog steeds van schijf en plaatst deze in de cache, en dit is een erg dure operatie voor de database. Afhankelijk van de grootte kan dit tot bepaalde prestatieproblemen leiden.
U kunt Housekeeper op een eenvoudige manier uitschakelen - we hebben een vertrouwde webinterface. Instellingen in Beheer algemeen (instellingen voor “Huishoudster”) schakelen we de interne huishouding uit voor interne geschiedenis en trends. Dienovereenkomstig heeft de huishoudster hier geen controle meer over:
Wat kunt u nu doen? Je hebt het uitgeschakeld, je grafieken zijn genivelleerd... Welke verdere problemen kunnen zich in dit geval voordoen? Wat kan helpen?
Partitioneren (sectie)
Meestal wordt dit op een andere manier geconfigureerd voor elke relationele database die ik heb vermeld. MySQL heeft zijn eigen technologie. Maar over het algemeen lijken ze erg op elkaar als het gaat om PostgreSQL 10 en MySQL. Natuurlijk zijn er veel interne verschillen in de manier waarop het allemaal wordt geïmplementeerd en hoe het allemaal de prestaties beïnvloedt. Maar over het algemeen leidt het creëren van een nieuwe partitie vaak ook tot bepaalde problemen.
Afhankelijk van uw instellingen (hoeveel gegevens u op één dag creëert), stellen ze meestal het minimum in - dit is 1 dag / batch, en voor "trends", dynamiek van veranderingen - 1 maand / nieuwe batch. Dit kan veranderen als u een zeer grote installatie heeft.
Laten we meteen zeggen over de grootte van de opstelling: tot 5 nieuwe waarden per seconde (zogenaamde nvps) - dit wordt als een kleine “installatie” beschouwd. Gemiddeld – van 5 tot 25 duizend waarden per seconde. Het enige dat hierboven staat, zijn al grote en zeer grote installaties die een zeer zorgvuldige configuratie van de database vereisen.
Bij zeer grote installaties is 1 dag mogelijk niet optimaal. Ik heb persoonlijk partities op MySQL gezien van 40 gigabytes per dag (en er kunnen er meer zijn). Dit is een zeer grote hoeveelheid gegevens, wat tot enkele problemen kan leiden. Het moet worden verminderd.
Waarom heb je partitionering nodig?
Wat Partitionering biedt, denk ik dat iedereen weet, is het partitioneren van tabellen. Vaak zijn dit afzonderlijke bestanden op schijf- en spanverzoeken. Het selecteert één partitie optimaaler als deze deel uitmaakt van de normale partitie.
Met name voor Zabbix wordt het gebruikt per bereik, dat wil zeggen dat we een tijdstempel gebruiken (een normaal getal, tijd sinds het begin van het tijdperk). U geeft het begin van de dag/het einde van de dag op, en dit is de partitie. Als u dus om gegevens vraagt die twee dagen oud zijn, wordt alles sneller uit de database opgehaald, omdat u slechts één bestand in de cache hoeft te laden en terug te sturen (in plaats van een grote tabel).
Veel databases versnellen ook het invoegen (invoegen in één onderliggende tabel). Ik spreek voorlopig abstract, maar dit is ook mogelijk. Partitioneren helpt vaak.
Elasticsearch voor NoSQL
Onlangs hebben we in 3.4 een NoSQL-oplossing geïmplementeerd. De mogelijkheid toegevoegd om in Elasticsearch te schrijven. U kunt bepaalde typen schrijven: u kiest - schrijf cijfers of enkele tekens; we hebben stringtekst, je kunt logs naar Elasticsearch schrijven... Dienovereenkomstig heeft de webinterface ook toegang tot Elasticsearch. Dit werkt in sommige gevallen uitstekend, maar op dit moment kan het worden gebruikt.
TijdschaalDB. Hypertabellen
Voor 4.4.2 hebben we aandacht besteed aan iets als TimescaleDB. Wat het is? Dit is een extensie voor PostgreSQL, dat wil zeggen dat het een native PostgreSQL-interface heeft. Bovendien kunt u met deze extensie veel efficiënter werken met tijdreeksgegevens en beschikken over automatische partities. Hoe het eruit ziet:
Dit is hypertabel - er is zo'n concept in Timescale. Dit is een hypertabel die u maakt en die segmenten bevat. Chunks zijn partities, dit zijn onderliggende tabellen, als ik me niet vergis. Het is echt effectief.
TimescaleDB en PostgreSQL
Zoals de TimescaleDB-fabrikanten verzekeren, gebruiken ze een correcter algoritme voor het verwerken van query's, met name inserts, wat ongeveer constante prestaties mogelijk maakt bij een toenemende omvang van de dataset-insert. Dat wil zeggen, na 200 miljoen rijen Postgres begint de gebruikelijke erg te verzakken en verliest de prestatie letterlijk tot nul, terwijl je met Timescale invoegingen zo efficiënt mogelijk kunt invoegen met elke hoeveelheid gegevens.
Hoe TimescaleDB installeren? Het is makkelijk!
Het staat in de documentatie, het wordt beschreven - je kunt het vanuit pakketten installeren voor elk... Het hangt af van de officiële Postgres-pakketten. Kan handmatig worden samengesteld. Het gebeurde zo dat ik moest compileren voor de database.
Op Zabbix activeren we eenvoudig Extensie. Ik denk dat degenen die Extention in Postgres gebruikten... Je activeert eenvoudig Extention, maakt het aan voor de Zabbix-database die je gebruikt.
En de laatste stap...
TijdschaalDB. Migratie van geschiedenistabellen
U moet een hypertabel maken. Hiervoor is een speciale functie: Hypertabel maken. Daarin is de eerste parameter de tabel die nodig is in deze database (waarvoor u een hypertabel moet maken).
Het veld waarmee moet worden gemaakt, en chunk_time_interval (dit is het interval van chunks (partities die moeten worden gebruikt). 86 is één dag.
Migrate_data-parameter: als u true invoegt, worden alle huidige gegevens naar vooraf gemaakte segmenten gemigreerd.
Ik heb move_data zelf gebruikt - het kost behoorlijk wat tijd, afhankelijk van hoe groot je database is. Ik had meer dan een terabyte, het duurde meer dan een uur om het te maken. In sommige gevallen heb ik tijdens het testen historische gegevens voor tekst (history_text) en string (history_str) verwijderd om ze niet over te dragen - ze waren niet echt interessant voor mij.
En we voeren de laatste update uit in onze db_extention: we installeren timescaledb zodat de database en in het bijzonder onze Zabbix begrijpt dat er db_extention is. Hij activeert het en gebruikt de juiste syntaxis en query's naar de database, met behulp van de "functies" die nodig zijn voor TimescaleDB.
Serverconfiguratie
Ik heb twee servers gebruikt. De eerste server is een vrij kleine virtuele machine, 20 processors, 16 gigabyte RAM. Ik heb Postgres 10.8 erop geconfigureerd:
Het besturingssysteem was Debian, het bestandssysteem was xfs. Ik heb minimale instellingen gemaakt om deze specifieke database te gebruiken, minus wat Zabbix zelf zal gebruiken. Op dezelfde machine bevonden zich een Zabbix-server, PostgreSQL en laadagenten.
Ik heb 50 actieve agenten gebruikt die LoadableModule gebruiken om snel verschillende resultaten te genereren. Zij zijn degenen die de strings, getallen, enzovoort hebben gegenereerd. Ik heb de database gevuld met veel gegevens. Aanvankelijk bevatte de configuratie vijfduizend data-elementen per host, en ongeveer elk data-element bevatte een trigger - zodat dit een echte opstelling kon zijn. Soms heb je zelfs meer dan één trigger nodig om te gebruiken.
Ik regelde het update-interval en de belasting zelf door niet alleen 50 agenten te gebruiken (meer toe te voegen), maar ook dynamische data-elementen te gebruiken en het update-interval terug te brengen tot 4 seconden.
Prestatie test. PostgreSQL: 36 duizend NVP's
De eerste lancering, de eerste setup die ik had, was op pure PostreSQL 10 op deze hardware (35 duizend waarden per seconde). Over het algemeen duurt het invoegen van gegevens, zoals u op het scherm kunt zien, een fractie van een seconde - alles is goed en snel, SSD-schijven (200 gigabyte). Het enige is dat 20 GB vrij snel vol raakt.
Er zullen in de toekomst heel veel van dergelijke grafieken zijn. Dit is een standaard Zabbix-serverprestatiedashboard.
De eerste grafiek is het aantal waarden per seconde (blauw, linksboven), in dit geval 35 duizend waarden. Dit (middenboven) is het laden van bouwprocessen, en dit (rechtsboven) is het laden van interne processen: geschiedenissynchronisatieprogramma's en huishoudster, die hier (middenonder) al geruime tijd actief zijn.
Deze grafiek (middenonder) toont het ValueCache-gebruik: hoeveel ValueCache-hits voor triggers (enkele duizenden waarden per seconde). Een andere belangrijke grafiek is de vierde (linksonder), die het gebruik van HistoryCache laat zien, waar ik het over had, wat een buffer is voordat deze in de database wordt ingevoegd.
Prestatie test. PostgreSQL: 50 duizend NVP's
Vervolgens verhoogde ik de belasting naar 50 waarden per seconde op dezelfde hardware. Bij het laden door Housekeeper werden met berekening in 10-2 seconden 3 waarden geregistreerd. Wat wordt feitelijk weergegeven in de volgende schermafbeelding:
De ‘huishoudster’ begint zich al met het werk te bemoeien, maar over het algemeen ligt de belasting van de geschiedenis-zinkvangers nog steeds op het niveau van 60% (derde grafiek, rechtsboven). HistoryCache begint al actief te vullen terwijl Housekeeper actief is (linksonder). Het was ongeveer een halve gigabyte, 20% vol.
Prestatie test. PostgreSQL: 80 duizend NVP's
Vervolgens verhoogde ik het naar 80 waarden per seconde:
Het waren ongeveer 400 duizend data-elementen, 280 duizend triggers. De inzet was, zoals je kunt zien, in termen van de lading historische zinkers (er waren er 30) al behoorlijk hoog. Vervolgens verhoogde ik verschillende parameters: geschiedenis-zinkers, cache... Op deze hardware begon de belasting van geschiedenis-zinkers tot een maximum te stijgen, bijna "op de plank" - dienovereenkomstig ging HistoryCache in een zeer hoge belasting:
Al die tijd heb ik alle systeemparameters gecontroleerd (hoe de processor wordt gebruikt, RAM) en ontdekte dat het schijfgebruik maximaal was - ik bereikte de maximale capaciteit van deze schijf op deze hardware, op deze virtuele machine. "Postgres" begon behoorlijk actief gegevens te dumpen met een dergelijke intensiteit, en de schijf had geen tijd meer om te schrijven, lezen...
Ik nam een andere server die al 48 processors en 128 gigabyte RAM had:
Ik heb het ook "afgestemd" - History-synchronisatie geïnstalleerd (60 stuks) en acceptabele prestaties behaald. In feite staan we niet “op de plank”, maar dit is waarschijnlijk de grens van de productiviteit, waar het al nodig is om er iets aan te doen.
Prestatie test. TijdschaalDB: 80 duizend NVP's
Mijn hoofdtaak was het gebruik van TimescaleDB. Elke grafiek toont een dip:
Deze fouten zijn precies datamigratie. Daarna veranderde op de Zabbix-server het laadprofiel van geschiedenis-zinkers, zoals u kunt zien, veel. Hiermee kunt u gegevens bijna 3 keer sneller invoegen en minder HistoryCache gebruiken, zodat de gegevens op tijd worden afgeleverd. Nogmaals, 80 duizend waarden per seconde is een vrij hoog percentage (uiteraard niet voor Yandex). Over het algemeen is dit een vrij grote opstelling, met één server.
PostgreSQL-prestatietest: 120 duizend NVP's
Vervolgens verhoogde ik de waarde van het aantal gegevenselementen tot een half miljoen en ontving een berekende waarde van 125 duizend per seconde:
En ik kreeg deze grafieken:
In principe is dit een werkende opstelling, deze kan behoorlijk lang werken. Maar aangezien ik maar een schijf van 1,5 terabyte had, had ik deze binnen een paar dagen opgebruikt. Het belangrijkste is dat er tegelijkertijd nieuwe partities werden gemaakt op TimescaleDB, en dit bleef volledig onopgemerkt voor de prestaties, wat niet gezegd kan worden over MySQL.
Normaal gesproken worden partities 's nachts gemaakt, omdat dit over het algemeen het invoegen en werken met tabellen blokkeert en kan leiden tot verslechtering van de service. In dit geval is dit niet het geval! De belangrijkste taak was het testen van de mogelijkheden van TimescaleDB. Het resultaat was het volgende cijfer: 120 duizend waarden per seconde.
Er zijn ook voorbeelden in de gemeenschap:
De persoon zette ook TimescaleDB aan en de belasting van het gebruik van io.weight daalde op de processor; en het gebruik van interne proceselementen is ook afgenomen door de opname van TimescaleDB. Bovendien zijn dit gewone pannenkoekschijven, dat wil zeggen een gewone virtuele machine op gewone schijven (geen SSD's)!
Voor sommige kleine instellingen die worden beperkt door schijfprestaties, is TimescaleDB naar mijn mening een zeer goede oplossing. Hiermee kunt u blijven werken voordat u migreert naar snellere hardware voor de database.
Ik nodig jullie allemaal uit voor onze evenementen: Conferentie in Moskou, Top in Riga. Gebruik onze kanalen - Telegram, forum, IRC. Heeft u vragen, kom dan naar ons bureau, wij kunnen alles bespreken.
Vragen van het publiek
Vraag van het publiek (hierna - A): - Als TimescaleDB zo eenvoudig te configureren is en het zo'n prestatieverbetering geeft, moet dit misschien worden gebruikt als best practice voor het configureren van Zabbix met Postgres? En zijn er valkuilen en nadelen van deze oplossing, of als ik besluit Zabbix voor mezelf te maken, kan ik Postgres gemakkelijk nemen, Timescale daar meteen installeren, gebruiken en niet aan problemen denken?
AG: – Ja, ik zou zeggen dat dit een goede aanbeveling is: gebruik Postgres onmiddellijk met de TimescaleDB-extensie. Zoals ik al zei, veel goede recensies, ondanks het feit dat deze “functie” experimenteel is. Maar eigenlijk tonen tests aan dat dit een geweldige oplossing is (met TimescaleDB) en ik denk dat deze zal evolueren! We houden in de gaten hoe deze uitbreiding zich ontwikkelt en zullen indien nodig wijzigingen aanbrengen.
Zelfs tijdens de ontwikkeling vertrouwden we op een van hun bekende ‘features’: het was mogelijk om op een iets andere manier met chunks te werken. Maar toen schrapten ze het in de volgende release en moesten we niet langer op deze code vertrouwen. Ik zou aanraden deze oplossing op veel opstellingen te gebruiken. Als je MySQL gebruikt... Voor gemiddelde instellingen werkt elke oplossing goed.
A: – Op de laatste grafieken van de community stond een grafiek met “Huishoudster”:
Hij bleef werken. Wat doet Housekeeper met TimescaleDB?
AG: – Nu kan ik het niet met zekerheid zeggen – ik zal naar de code kijken en je meer in detail vertellen. Het gebruikt TimescaleDB-query's niet om chunks te verwijderen, maar om ze op de een of andere manier samen te voegen. Ik ben nog niet klaar om deze technische vraag te beantwoorden. Vandaag of morgen zullen we meer te weten komen op de stand.
A: – Ik heb een soortgelijke vraag – over de prestaties van de verwijderbewerking in Timescale.
A (antwoord van het publiek): – Wanneer u gegevens uit een tabel verwijdert en u dit via verwijderen doet, moet u de tabel doorlopen: verwijderen, opschonen, alles markeren voor toekomstig vacuüm. In Timescale kun je, omdat je chunks hebt, laten vallen. Grofweg zeg je simpelweg tegen het bestand dat in big data staat: “Verwijder!”
Timescale begrijpt eenvoudigweg dat zo'n stuk niet langer bestaat. En omdat het is geïntegreerd in de queryplanner, gebruikt het hooks om uw voorwaarden in geselecteerde of andere bewerkingen op te vangen en begrijpt het onmiddellijk dat dit deel niet langer bestaat: "Ik ga daar niet meer heen!" (gegevens niet beschikbaar). Dat is alles! Dat wil zeggen dat een tabelscan wordt vervangen door het verwijderen van binaire bestanden, dus het gaat snel.
A: – We hebben het onderwerp niet-SQL al besproken. Voor zover ik het begrijp hoeft Zabbix de gegevens niet echt te wijzigen, en dit lijkt allemaal op een logboek. Is het mogelijk om gespecialiseerde databases te gebruiken die hun gegevens niet kunnen wijzigen, maar tegelijkertijd veel sneller kunnen opslaan, verzamelen en distribueren - Clickhouse bijvoorbeeld, iets Kafka-achtigs? Kafka is ook een logboek! Is het mogelijk om ze op de een of andere manier te integreren?
AG: - Lossen kan. We hebben een bepaalde “functie” sinds versie 3.4: je kunt alle historische bestanden, gebeurtenissen en al het andere naar bestanden schrijven; en stuur het vervolgens naar een andere database met behulp van een handler. Veel mensen herwerken en schrijven rechtstreeks naar de database. Geschiedenis-zinkers schrijven dit allemaal in bestanden, roteren deze bestanden, enzovoort, en u kunt dit overbrengen naar Clickhouse. Over de plannen kan ik niets zeggen, maar misschien zal verdere ondersteuning voor NoSQL-oplossingen (zoals Clickhouse) worden voortgezet.
A: – Over het algemeen blijkt dat je postgres volledig kunt verwijderen?
AG: – Het moeilijkste deel van Zabbix zijn natuurlijk de historische tabellen, die de meeste problemen veroorzaken, en gebeurtenissen. In dit geval, als je gebeurtenissen lange tijd niet opslaat en de geschiedenis met trends opslaat in een andere snelle opslag, dan denk ik dat er over het algemeen geen problemen zullen zijn.
A: – Kunt u inschatten hoeveel sneller alles werkt als u bijvoorbeeld overstapt op Clickhouse?
AG: – Ik heb het niet getest. Ik denk dat op zijn minst dezelfde cijfers heel eenvoudig kunnen worden bereikt, aangezien Clickhouse een eigen interface heeft, maar ik kan het niet met zekerheid zeggen. Het is beter om te testen. Het hangt allemaal af van de configuratie: hoeveel hosts je hebt, enzovoort. Invoegen is één ding, maar je moet deze gegevens ook ophalen - Grafana of iets anders.
A: – We hebben het dus over een gelijkwaardige strijd, en niet over het grote voordeel van deze snelle databases?
AG: – Ik denk dat als we integreren, er nauwkeurigere tests zullen zijn.
A: – Waar is de goede oude RRD gebleven? Waarom bent u overgestapt op SQL-databases? In eerste instantie werden alle statistieken verzameld op RRD.
AG: – Zabbix had RRD, misschien in een heel oude versie. Er zijn altijd SQL-databases geweest - een klassieke benadering. De klassieke aanpak is MySQL, PostgreSQL (ze bestaan al heel lang). We hebben bijna nooit een gemeenschappelijke interface voor SQL- en RRD-databases gebruikt.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com