De afgelopen jaren zijn tijdreeksdatabases veranderd van iets bizars (zeer gespecialiseerd, gebruikt in open monitoringsystemen (en gekoppeld aan specifieke oplossingen) of in Big Data-projecten) in een ‘consumentenproduct’. Op het grondgebied van de Russische Federatie moet hiervoor speciale dank worden betuigd aan Yandex en ClickHouse. Als je tot nu toe een grote hoeveelheid tijdreeksgegevens moest opslaan, moest je óf in het reine komen met de noodzaak om een monsterlijke Hadoop-stack te bouwen en deze te onderhouden, óf te communiceren met protocollen die voor elk systeem afzonderlijk waren.
Het lijkt misschien dat in 2019 een artikel waarover TSDB de moeite waard is, uit slechts één zin zal bestaan: “gebruik gewoon ClickHouse.” Maar... er zijn nuances.
ClickHouse is inderdaad actief in ontwikkeling, het gebruikersbestand groeit en de ondersteuning is zeer actief, maar zijn we gijzelaars geworden van het publieke succes van ClickHouse, dat andere, misschien effectievere/betrouwbare oplossingen heeft overschaduwd?
Begin vorig jaar zijn we begonnen met het herwerken van ons eigen monitoringsysteem, waarbij de vraag rees een geschikte database te kiezen voor het opslaan van gegevens. Ik wil het hier hebben over de geschiedenis van deze keuze.
Formulering van het probleem
Allereerst een noodzakelijk voorwoord. Waarom hebben we überhaupt een eigen monitoringsysteem nodig en hoe is dat ontworpen?
We begonnen in 2008 met het leveren van ondersteunende diensten en in 2010 werd het duidelijk dat het moeilijk werd om gegevens over de processen die plaatsvinden in de klantinfrastructuur samen te voegen met de oplossingen die toen bestonden (we hebben het over, God vergeef me, Cacti, Zabbix en het opkomende grafiet).
Onze voornaamste eisen waren:
- ondersteuning (op dat moment - tientallen, en in de toekomst - honderden) klanten binnen één systeem en tegelijkertijd de aanwezigheid van een gecentraliseerd waarschuwingsbeheersysteem;
- flexibiliteit bij het beheer van het waarschuwingssysteem (escalatie van waarschuwingen tussen dienstdoende functionarissen, planning, kennisbank);
- het vermogen om grafieken diepgaand te detailleren (Zabbix maakte destijds grafieken in de vorm van afbeeldingen);
- langdurige opslag van een grote hoeveelheid gegevens (een jaar of langer) en de mogelijkheid om deze snel terug te halen.
In dit artikel zijn we geïnteresseerd in het laatste punt.
Over opslag gesproken, de vereisten waren als volgt:
- het systeem moet snel werken;
- het is wenselijk dat het systeem over een SQL-interface beschikt;
- het systeem moet stabiel zijn en een actieve gebruikersbasis en ondersteuning hebben (zodra we geconfronteerd werden met de noodzaak om systemen te ondersteunen zoals MemcacheDB, dat niet langer werd ontwikkeld, of de gedistribueerde opslag van MooseFS, waarvan de bugtracker in het Chinees werd bewaard: we herhalen dit verhaal want ons project wilde niet);
- naleving van het CAP-theorema: Consistentie (vereist) - de gegevens moeten up-to-date zijn, we willen niet dat het waarschuwingsbeheersysteem geen nieuwe gegevens ontvangt en waarschuwingen uitspuugt over het niet aankomen van gegevens voor alle projecten; Partitietolerantie (vereist) - we willen geen Split Brain-systeem krijgen; Beschikbaarheid (niet kritisch, als er een actieve replica is) - bij een ongeval kunnen we met behulp van code zelf overschakelen naar het back-upsysteem.
Vreemd genoeg bleek MySQL destijds voor ons de ideale oplossing. Onze datastructuur was uiterst eenvoudig: server-ID, teller-ID, tijdstempel en waarde; snelle bemonstering van actuele gegevens werd verzekerd door een grote bufferpool, en bemonstering van historische gegevens werd verzekerd door SSD.
We hebben dus een steekproef van nieuwe gegevens van twee weken verkregen, met details tot op 200 ms van een seconde voordat de gegevens volledig waren weergegeven, en hebben een behoorlijk lange tijd in dit systeem geleefd.
Ondertussen verstreek de tijd en groeide de hoeveelheid data. In 2016 bereikten de datavolumes tientallen terabytes, wat een aanzienlijke kostenpost was in de context van gehuurde SSD-opslag.
Tegen die tijd waren kolomvormige databases actief wijdverspreid geworden, waar we actief over begonnen na te denken: in kolomvormige databases worden gegevens, zoals u begrijpt, in kolommen opgeslagen, en als u naar onze gegevens kijkt, is het gemakkelijk om een grote hoeveelheid te zien. aantal duplicaten dat kan worden gecomprimeerd als u een kolomdatabase gebruikt.
Het sleutelsysteem van het bedrijf bleef echter stabiel werken en ik wilde niet experimenteren met het overstappen naar iets anders.
In 2017, op de Percona Live-conferentie in San Jose, maakten Clickhouse-ontwikkelaars zichzelf waarschijnlijk voor het eerst bekend. Op het eerste gezicht was het systeem klaar voor productie (nou ja, Yandex.Metrica is een zwaar productiesysteem), de ondersteuning was snel en eenvoudig, en, belangrijker nog, de bediening was eenvoudig. Sinds 2018 zijn we het transitieproces gestart. Maar tegen die tijd waren er veel ‘volwassen’ en beproefde TSDB-systemen, en we besloten veel tijd te besteden aan het vergelijken van alternatieven om er zeker van te zijn dat er geen alternatieve oplossingen voor Clickhouse waren, volgens onze vereisten.
Naast de reeds gespecificeerde opslagvereisten zijn er nieuwe verschenen:
- het nieuwe systeem moet minimaal dezelfde prestaties leveren als MySQL op dezelfde hoeveelheid hardware;
- de opslag van het nieuwe systeem zou aanzienlijk minder ruimte in beslag moeten nemen;
- Het DBMS moet nog steeds eenvoudig te beheren zijn;
- Ik wilde de applicatie minimaal wijzigen bij het wijzigen van het DBMS.
Welke systemen zijn we gaan overwegen?
Apache Hive/Apache Impala
Een oude, beproefde Hadoop-stack. In wezen is het een SQL-interface die is gebouwd bovenop het opslaan van gegevens in native formaten op HDFS.
Pros.
- Dankzij de stabiele werking is het heel eenvoudig om gegevens te schalen.
- Er zijn kolomoplossingen voor dataopslag (minder ruimte).
- Zeer snelle uitvoering van parallelle taken wanneer middelen beschikbaar zijn.
Cons.
- Het is Hadoop en het is moeilijk te gebruiken. Als we er niet klaar voor zijn om een kant-en-klare oplossing in de cloud te nemen (en we zijn er qua kosten nog niet klaar voor), zal de hele stapel door de handen van beheerders moeten worden samengesteld en ondersteund, en dat willen we echt niet dit.
- Gegevens worden samengevoegd .
Maar:
Snelheid wordt bereikt door het aantal computerservers te schalen. Simpel gezegd: als we een groot bedrijf zijn dat zich bezighoudt met analyses, en het van cruciaal belang is voor het bedrijf om informatie zo snel mogelijk te verzamelen (zelfs als dit ten koste gaat van het gebruik van een grote hoeveelheid computerbronnen), kan dit onze keuze zijn. Maar we waren er niet klaar voor om de hardwarevloot uit te breiden om de taken te versnellen.
Druïde/Pinot
Er is specifiek veel meer over TSDB, maar nogmaals, de Hadoop-stack.
Er is .
In een paar woorden: Druid/Pinot zien er beter uit dan Clickhouse in gevallen waarin:
- Je hebt een heterogene aard van gegevens (in ons geval registreren we alleen tijdreeksen van serverstatistieken, en in feite is dit één tabel. Maar er kunnen ook andere gevallen zijn: tijdreeksen van apparatuur, economische tijdreeksen, enz. - elk met een eigen structuur, die moeten worden samengevoegd en verwerkt).
- Bovendien zijn er veel van deze gegevens.
- Tabellen en gegevens met tijdreeksen verschijnen en verdwijnen (dat wil zeggen dat een bepaalde reeks gegevens is aangekomen, geanalyseerd en verwijderd).
- Er bestaat geen duidelijk criterium op basis waarvan gegevens kunnen worden gepartitioneerd.
In tegenovergestelde gevallen presteert ClickHouse beter, en dit is ons geval.
Klik op Huis
- SQL-achtig
- Eenvoudig te beheren.
- Mensen zeggen dat het werkt.
Wordt op de shortlist gezet om te testen.
InstroomDB
Een buitenlands alternatief voor ClickHouse. Van de minnen: Hoge beschikbaarheid is alleen aanwezig in de commerciële versie, maar moet worden vergeleken.
Wordt op de shortlist gezet om te testen.
Cassandra
Aan de ene kant weten we dat het wordt gebruikt om metrische tijdreeksen op te slaan door monitoringsystemen als bijvoorbeeld of OkMeter. Er zijn echter bijzonderheden.
Cassandra is geen zuilvormige database in de traditionele zin van het woord. Het lijkt meer op een rijweergave, maar elke regel kan een ander aantal kolommen hebben, waardoor het eenvoudig wordt om een kolomweergave te organiseren. In die zin is het duidelijk dat het met een limiet van 2 miljard kolommen mogelijk is om bepaalde gegevens in kolommen (en dezelfde tijdreeksen) op te slaan. In MySQL is er bijvoorbeeld een limiet van 4096 kolommen en het is gemakkelijk om een fout tegen te komen met code 1117 als je hetzelfde probeert te doen.
De Cassandra-engine is gericht op het opslaan van grote hoeveelheden gegevens in een gedistribueerd systeem zonder master, en de bovengenoemde Cassandra CAP-stelling gaat meer over AP, dat wil zeggen over de beschikbaarheid van gegevens en de weerstand tegen partitionering. Deze tool kan dus geweldig zijn als u alleen naar deze database hoeft te schrijven en er zelden uit leest. En hier is het logisch om Cassandra als “koude” opslag te gebruiken. Dat wil zeggen, als een betrouwbare plek voor de lange termijn om grote hoeveelheden historische gegevens op te slaan die zelden nodig zijn, maar indien nodig kunnen worden opgehaald. Toch gaan we het voor de volledigheid ook testen. Maar zoals ik al eerder zei, er is geen wens om de code voor de geselecteerde databaseoplossing actief te herschrijven, dus zullen we deze enigszins beperkt testen - zonder de databasestructuur aan te passen aan de specifieke kenmerken van Cassandra.
Prometheus
Uit nieuwsgierigheid hebben we besloten de prestaties van Prometheus-opslag te testen - gewoon om te begrijpen of we sneller of langzamer zijn dan de huidige oplossingen en in welke mate.
Testmethodologie en resultaten
We hebben dus 5 databases getest in de volgende 6 configuraties: ClickHouse (1 knooppunt), ClickHouse (gedistribueerde tabel voor 3 knooppunten), InfluxDB, Mysql 8, Cassandra (3 knooppunten) en Prometheus. Het testplan is als volgt:
- upload historische gegevens voor een week (840 miljoen waarden per dag; 208 duizend statistieken);
- we genereren een opnamebelasting (er zijn zes laadmodi overwogen, zie hieronder);
- Parallel aan de opname maken we periodiek selecties, waarbij we de verzoeken emuleren van een gebruiker die met grafieken werkt. Om de zaken niet te ingewikkeld te maken, hebben we een week lang gegevens geselecteerd voor tien statistieken (dat is precies hoeveel er in de CPU-grafiek staan).
We laden door het gedrag van onze monitoringagent te emuleren, die elke 15 seconden waarden naar elke statistiek verzendt. Tegelijkertijd zijn we geïnteresseerd in het variëren van:
- het totale aantal metrieken waarin gegevens worden geschreven;
- interval voor het verzenden van waarden naar één metriek;
- seriegrootte.
Over de batchgrootte. Omdat het niet wordt aanbevolen om bijna al onze experimentele databases met enkele inserts te laden, hebben we een relay nodig die binnenkomende metrieken verzamelt, deze in groepen groepeert en ze als batch-insert naar de database schrijft.
Om beter te begrijpen hoe we de ontvangen gegevens vervolgens moeten interpreteren, moeten we ons ook voorstellen dat we niet alleen een aantal statistieken verzenden, maar dat de statistieken zijn georganiseerd in servers - 125 statistieken per server. Hier is de server eenvoudigweg een virtuele entiteit - om maar te begrijpen dat bijvoorbeeld 10000 statistieken overeenkomen met ongeveer 80 servers.
En hier, dit alles in aanmerking genomen, zijn onze 6 laadmodi voor het schrijven van databases:
Er zijn hier twee punten. Ten eerste bleken deze batchgroottes voor Cassandra te groot, daar gebruikten we waarden van 50 of 100. En ten tweede, aangezien Prometheus strikt in pull-modus werkt, d.w.z. het gaat zelf gegevens verzamelen uit metrische bronnen (en zelfs pushgateway verandert, ondanks de naam, de situatie niet fundamenteel), de bijbehorende belastingen werden geïmplementeerd met behulp van een combinatie van statische configuraties.
De testresultaten zijn als volgt:
Wat is het vermelden waard?: fantastisch snelle samples van Prometheus, vreselijk trage samples van Cassandra, onaanvaardbaar langzame samples van InfluxDB; Qua opnamesnelheid heeft ClickHouse iedereen gewonnen, en Prometheus doet niet mee aan de wedstrijd, omdat het zelf inserts maakt en wij niets meten.
Dientengevolge: ClickHouse en InfluxDB lieten zich de beste zien, maar een cluster van Influx kan alleen gebouwd worden op basis van de Enterprise-versie, die geld kost, terwijl ClickHouse niets kost en in Rusland gemaakt wordt. Het is logisch dat in de VS de keuze waarschijnlijk in het voordeel van inInfluxDB valt, en in ons land in het voordeel van ClickHouse.
Bron: www.habr.com