is een open-source kolomvormig databasebeheersysteem voor online analytische queryverwerking (OLAP) gemaakt door Yandex. Het wordt gebruikt door Yandex, CloudFlare, VK.com, Badoo en andere services over de hele wereld om echt grote hoeveelheden gegevens op te slaan (invoeging van duizenden rijen per seconde of petabytes aan gegevens die op schijf zijn opgeslagen).
In een normaal, "string" DBMS, waarvan MySQL, Postgres, MS SQL Server voorbeelden zijn, worden gegevens in deze volgorde opgeslagen:
In dit geval worden de waarden die betrekking hebben op één rij fysiek naast elkaar opgeslagen. In kolom-DBMS worden waarden uit verschillende kolommen afzonderlijk opgeslagen en worden de gegevens van één kolom samen opgeslagen:
Voorbeelden van zuilvormige DBMS'en zijn Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Het bedrijf is een postbode Ik begon Clickhouse in 2018 te gebruiken voor rapportage en was erg onder de indruk van de eenvoud, schaalbaarheid, SQL-ondersteuning en snelheid. De snelheid van dit DBMS grensde aan magie.
Gemak
Clickhouse wordt op Ubuntu geïnstalleerd met een enkele opdracht. Als u SQL kent, kunt u Clickhouse meteen gaan gebruiken voor uw behoeften. Dit betekent echter niet dat u in MySQL "toon tabel maken" en in Clickhouse SQL kunt kopiëren en plakken.
Vergeleken met MySQL zijn er belangrijke verschillen in gegevenstypes in de tabelschemadefinities in dit DBMS, dus je hebt nog wat tijd nodig om de tabelschemadefinities te wijzigen en de tabelengines te leren kennen om vertrouwd te raken.
Clickhouse werkt prima zonder extra software, maar als u replicatie wilt gebruiken, moet u ZooKeeper installeren. Analyse van queryprestaties laat uitstekende resultaten zien - de systeemtabellen bevatten alle informatie en alle gegevens kunnen worden verkregen met behulp van oude en saaie SQL.
Производительность
- Clickhouse versus Vertica en MySQL vergelijkingen op configuratieserver: twee sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GB RAM; md RAID-5 op 8 6TB SATA HDD, ext4.
- vergelijking van Clickhouse met Amazon RedShift-cloudopslag.
- Blogfragmenten :
De ClickHouse-database heeft een heel eenvoudig ontwerp - alle knooppunten in het cluster hebben dezelfde functionaliteit en gebruiken alleen ZooKeeper voor coördinatie. We hebben een klein cluster van verschillende knooppunten gebouwd en tests uitgevoerd, waarbij we ontdekten dat het systeem behoorlijk indrukwekkende prestaties levert, wat overeenkomt met de geclaimde voordelen in analytische DBMS-benchmarks. We besloten het concept achter ClickHouse onder de loep te nemen. Het eerste obstakel voor onderzoek was het gebrek aan tools en de kleine community van ClickHouse, dus hebben we ons verdiept in het ontwerp van dit DBMS om te begrijpen hoe het werkt.
ClickHouse biedt geen ondersteuning voor het rechtstreeks ontvangen van gegevens van Kafka, omdat het slechts een database is, dus hebben we onze eigen adapterservice in Go geschreven. Het las Cap'n Proto-gecodeerde berichten van Kafka, converteerde ze naar TSV en plaatste ze in batches in ClickHouse via de HTTP-interface. We hebben deze service later herschreven om de Go-bibliotheek te gebruiken in combinatie met onze eigen ClickHouse-interface om de prestaties te verbeteren. Bij het evalueren van de prestaties van het ontvangen van pakketten, ontdekten we iets belangrijks: het bleek dat deze prestaties voor ClickHouse sterk afhangen van de grootte van het pakket, dat wil zeggen het aantal rijen dat tegelijkertijd wordt ingevoegd. Om te begrijpen waarom dit gebeurt, hebben we onderzocht hoe ClickHouse gegevens opslaat.
De hoofdmotor, of beter gezegd, een familie van tafelmotoren die door ClickHouse wordt gebruikt voor het opslaan van gegevens, is MergeTree. Deze engine is conceptueel vergelijkbaar met het LSM-algoritme dat wordt gebruikt in Google BigTable of Apache Cassandra, maar vermijdt het bouwen van een tussenliggende geheugentabel en schrijft gegevens rechtstreeks naar schijf. Dit zorgt voor een uitstekende schrijfdoorvoer, aangezien elk ingevoegd pakket alleen wordt gesorteerd op basis van de primaire sleutel van de "primaire sleutel", gecomprimeerd en naar schijf wordt geschreven om een segment te vormen.
De afwezigheid van een geheugentabel of enig concept van "versheid" van gegevens betekent ook dat ze alleen kunnen worden toegevoegd, het systeem ondersteunt geen wijziging of verwijdering. Vanaf vandaag is de enige manier om gegevens te verwijderen het verwijderen per kalendermaand, aangezien segmenten nooit een maandgrens overschrijden. Het ClickHouse-team werkt er actief aan om deze functie aanpasbaar te maken. Aan de andere kant maakt het het schrijven en samenvoegen van segmenten vrij van discussies, zodat de doorvoersnelheid lineair wordt geschaald met het aantal parallelle inserts totdat de I/O of kernen verzadigd zijn.
Deze omstandigheid betekent echter ook dat het systeem niet geschikt is voor kleine pakketten, dus worden Kafka-services en inserters gebruikt voor buffering. Verder blijft ClickHouse op de achtergrond continu segmenten samenvoegen, zodat veel kleine stukjes informatie worden gecombineerd en vaker worden opgenomen, waardoor de opname-intensiteit toeneemt. Te veel niet-verwante onderdelen veroorzaken echter agressieve beperking van wisselplaten zolang het samenvoegen doorgaat. We hebben ontdekt dat het beste compromis tussen real-time gegevensopname en opnameprestaties is om een beperkt aantal invoegingen per seconde in de tabel te accepteren.
De sleutel tot leesprestaties van tabellen is de indexering en locatie van de gegevens op schijf. Het maakt niet uit hoe snel de verwerking is, als de engine terabytes aan gegevens van de schijf moet scannen en er slechts een fractie van moet gebruiken, kost het tijd. ClickHouse is een column store, dus elk segment bevat voor elke kolom (kolom) een bestand met gesorteerde waarden voor elke rij. Zo kunnen hele kolommen die niet aanwezig zijn in de query eerst worden overgeslagen en vervolgens kunnen meerdere cellen parallel worden verwerkt met gevectoriseerde uitvoering. Om een volledige scan te voorkomen, heeft elk segment een klein indexbestand.
Aangezien alle kolommen zijn gesorteerd op de "primaire sleutel", bevat het indexbestand alleen de labels (vastgelegde rijen) van elke N-de rij, om ze zelfs voor zeer grote tabellen in het geheugen te kunnen houden. U kunt bijvoorbeeld de standaardinstellingen instellen op "markeer elke 8192e rij", en vervolgens "magere" indexering van een tabel met 1 biljoen. regels die gemakkelijk in het geheugen passen, zouden slechts 122 tekens in beslag nemen.
Systeemontwikkeling
De ontwikkeling en verbetering van Clickhouse kan worden getraceerd en zorg ervoor dat het proces van 'opgroeien' in een indrukwekkend tempo verloopt.
Populariteit
Het lijkt erop dat de populariteit van Clickhouse exponentieel groeit, vooral in de Russisch sprekende gemeenschap. De High load 2018-conferentie van vorig jaar (Moskou, 8-9 november 2018) toonde aan dat monsters zoals vk.com en Badoo Clickhouse gebruiken, dat gegevens (bijvoorbeeld logs) van tienduizenden servers tegelijk invoegt. In een video van 40 minuten . Binnenkort zullen we de transcriptie op Habr plaatsen voor het gemak van het werken met het materiaal.
toepassingen
Na wat tijd te hebben besteed aan onderzoek, denk ik dat er gebieden zijn waar ClickHouse nuttig kan zijn of andere, meer traditionele en populaire oplossingen zoals MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot en volledig kan vervangen. Druïde. Hieronder volgen de details van het gebruik van ClickHouse om het bovenstaande DBMS te upgraden of volledig te vervangen.
Uitbreiding van MySQL en PostgreSQL
Onlangs hebben we MySQL gedeeltelijk vervangen door ClickHouse voor het nieuwsbriefplatform . Het probleem was dat MySQL door een slecht doordacht ontwerp elke verzonden e-mail en elke link in die e-mail registreerde met een base64-hash, waardoor een enorme MySQL-tabel (email_stats) ontstond. Na slechts 10 miljoen e-mails naar de abonnees van de service te hebben gestuurd, nam deze tabel 150 GB aan bestandsruimte in beslag en begon MySQL "dom" te worden bij eenvoudige vragen. Om het probleem met de bestandsruimte op te lossen, hebben we met succes InnoDB-tabelcompressie gebruikt, waardoor het met een factor 4 is verminderd. Het heeft echter nog steeds geen zin om meer dan 20-30 miljoen e-mails in MySQL op te slaan, alleen maar om de geschiedenis te kunnen lezen, aangezien elke eenvoudige zoekopdracht die om de een of andere reden een volledige scan moet uitvoeren, resulteert in swap en zware I/O overhead, waarover we regelmatig Zabbix-waarschuwingen ontvingen.
Clickhouse gebruikt twee compressie-algoritmen die de hoeveelheid gegevens met ongeveer verminderen , maar in dit specifieke geval waren de gegevens bijzonder "comprimeerbaar".
ELK-vervanging
Op basis van mijn eigen ervaring vereist de ELK-stack (ElasticSearch, Logstash en Kibana, in dit specifieke geval ElasticSearch) veel meer bronnen om te draaien dan nodig is om logboeken op te slaan. ElasticSearch is een geweldige engine als je goed wilt zoeken in de volledige tekst van logs (en ik denk niet dat je het echt nodig hebt), maar ik vraag me af waarom het de de facto standaard log-engine is geworden. De opnameprestaties, gecombineerd met Logstash, bezorgden ons problemen, zelfs bij vrij lichte workloads en vereisten de toevoeging van steeds meer RAM en schijfruimte. Als database is Clickhouse om de volgende redenen beter dan ElasticSearch:
- Ondersteuning voor SQL-dialect;
- De beste mate van compressie van opgeslagen gegevens;
- Ondersteuning voor Regex-zoekopdrachten in plaats van zoeken in volledige tekst;
- Verbeterde queryplanning en betere algehele prestaties.
Momenteel is het grootste probleem dat zich voordoet bij het vergelijken van ClickHouse met ELK het gebrek aan oplossingen voor het uploaden van logs, evenals het ontbreken van documentatie en tutorials over dit onderwerp. Tegelijkertijd kan elke gebruiker ELK instellen met behulp van de Digital Ocean-handleiding, wat erg belangrijk is voor de snelle implementatie van dergelijke technologieën. Er is hier een database-engine, maar er is nog geen Filebeat voor ClickHouse. Ja dat is er en een systeem om met logs te werken , er is een hulpmiddel om logbestandgegevens in ClickHouse in te voeren, maar dit kost allemaal meer tijd. ClickHouse loopt echter nog steeds voorop vanwege zijn eenvoud, zodat zelfs beginners het gemakkelijk kunnen installeren en in slechts 10 minuten volledig functioneel kunnen gebruiken.
Ik gaf de voorkeur aan minimalistische oplossingen en probeerde FluentBit, een tool voor het uploaden van logboeken met zeer weinig geheugen, te gebruiken met ClickHouse, terwijl ik probeerde Kafka te vermijden. Er moeten echter kleine onverenigbaarheden worden aangepakt, zoals voordat het kan worden gedaan zonder de proxylaag die gegevens van FluentBit naar ClickHouse converteert.
Als alternatief voor Kibana kunt u ClickHouse als backend gebruiken . Voor zover ik begrijp, kan dit prestatieproblemen veroorzaken bij het weergeven van een groot aantal datapunten, vooral bij oudere versies van Grafana. In Qwintry hebben we dit nog niet geprobeerd, maar klachten hierover verschijnen van tijd tot tijd op het ClickHouse-ondersteuningskanaal in Telegram.
Vervanging van Google Big Query en Amazon RedShift (oplossing voor grote bedrijven)
De ideale use-case voor BigQuery is om 1 TB aan JSON-gegevens te laden en er analytische query's op uit te voeren. Big Query is een geweldig product waarvan de schaalbaarheid moeilijk te overschatten is. Dit is veel complexere software dan ClickHouse die op een intern cluster draait, maar vanuit het oogpunt van de klant heeft het veel gemeen met ClickHouse. BigQuery kan snel "prijzen" zodra u voor elke SELECT begint te betalen, dus het is een echte SaaS-oplossing met al zijn voor- en nadelen.
ClickHouse is de beste keuze wanneer u veel rekenkundig dure zoekopdrachten uitvoert. Hoe meer SELECT-query's u elke dag uitvoert, hoe belangrijker het is om Big Query te vervangen door ClickHouse, omdat een dergelijke vervanging u duizenden dollars bespaart als het gaat om de verwerking van vele terabytes aan gegevens. Dit geldt niet voor opgeslagen data, die vrij goedkoop te verwerken is in Big Query.
In een artikel van Alexander Zaitsev, mede-oprichter van Altinity beschrijft de voordelen van een dergelijke DBMS-migratie.
TijdschaalDB-vervanging
TimescaleDB is een PostgreSQL-extensie die het werken met tijdreeksen in een reguliere database optimaliseert (, ).
Hoewel ClickHouse geen serieuze concurrent is in de tijdreeks-niche, is het in de meeste gevallen veel sneller dan TimescaleDB wat betreft de verwerking van analytische query's in termen van kolomstructuur en uitvoering van vectorquery's. Tegelijkertijd zijn de prestaties van het ontvangen van ClickHouse-pakketgegevens ongeveer 3 keer hoger, bovendien gebruikt het 20 keer minder schijfruimte, wat erg belangrijk is voor het verwerken van grote hoeveelheden historische gegevens: .
In tegenstelling tot ClickHouse is de enige manier om wat schijfruimte in TimescaleDB te besparen het gebruik van ZFS of vergelijkbare bestandssystemen.
Aankomende updates van ClickHouse zullen waarschijnlijk deltacompressie introduceren, waardoor het nog geschikter wordt voor het verwerken en opslaan van tijdreeksgegevens. TimescaleDB kan in de volgende gevallen een betere keuze zijn dan kale ClickHouse:
- kleine installaties met heel weinig RAM (<3 GB);
- een groot aantal kleine INSERT's die u niet wilt bufferen tot grote fragmenten;
- betere consistentie, uniformiteit en ACID-vereisten;
- PostGIS-ondersteuning;
- samenvoegen met bestaande PostgreSQL-tabellen, aangezien Timescale DB in wezen PostgreSQL is.
Concurrentie met Hadoop- en MapReduce-systemen
Hadoop en andere MapReduce-producten kunnen veel complexe berekeningen uitvoeren, maar ze hebben de neiging om met een enorme latentie te werken. ClickHouse lost dit probleem op door terabytes aan gegevens te verwerken en vrijwel onmiddellijk resultaten te produceren. ClickHouse is dus veel efficiënter voor het uitvoeren van snel, interactief analytisch onderzoek, wat interessant zou moeten zijn voor datawetenschappers.
Competitie met Pinot en Druid
De naaste concurrenten van ClickHouse zijn de kolomvormige, lineair schaalbare open source-producten Pinot en Druid. Een uitstekende vergelijking van deze systemen wordt in het artikel gepubliceerd 1 februari 2018
Dit artikel moet worden bijgewerkt - er staat dat ClickHouse geen UPDATE- en DELETE-bewerkingen ondersteunt, wat niet helemaal waar is met betrekking tot de nieuwste versies.
We hebben niet veel ervaring met deze DBMS'en, maar ik hou niet van de complexiteit van de onderliggende infrastructuur die nodig is om Druid en Pinot te laten draaien - het is een hele reeks "bewegende delen" die van alle kanten door Java worden omringd.
Druid en Pinot zijn Apache-incubatorprojecten, die in detail worden behandeld door Apache op hun GitHub-projectpagina's. Pinot verscheen in oktober 2018 in de incubator en Druid werd 8 maanden eerder geboren - in februari.
Het gebrek aan informatie over hoe AFS werkt, roept een aantal, en misschien domme, vragen bij mij op. Ik vraag me af of de auteurs van Pinot hebben opgemerkt dat de Apache Foundation meer genegen is voor druïden, en veroorzaakte een dergelijke houding ten opzichte van een concurrent een gevoel van afgunst? Zal de ontwikkeling van Druid vertragen en de ontwikkeling van Pinot versnellen als de sponsors die de eerste ondersteunen plotseling geïnteresseerd raken in de laatste?
Nadelen van ClickHouse
Onvolwassenheid: het is duidelijk dat dit nog steeds een saaie technologie is, maar in ieder geval is zoiets niet te zien in andere zuilvormige DBMS.
Kleine wisselplaten presteren niet goed bij hoge snelheid: wisselplaten moeten in grote stukken worden gesplitst omdat de prestaties van kleine wisselplaten afnemen in verhouding tot het aantal kolommen in elke rij. Dit is hoe ClickHouse gegevens op schijf opslaat - elke kolom betekent 1 bestand of meer, dus om 1 rij met 100 kolommen in te voegen, moet u minstens 100 bestanden openen en schrijven. Dit is de reden waarom insert-buffering een tussenpersoon vereist (tenzij de client zelf buffering levert) - meestal Kafka of een soort wachtrijsysteem. U kunt ook de Buffer-tabelengine gebruiken om later grote hoeveelheden gegevens naar MergeTree-tabellen te kopiëren.
Tabeljoins worden beperkt door server-RAM, maar ze zijn er tenminste! Druid en Pinot hebben dergelijke verbindingen bijvoorbeeld helemaal niet, omdat ze moeilijk direct te implementeren zijn in gedistribueerde systemen die geen ondersteuning bieden voor het verplaatsen van grote hoeveelheden gegevens tussen knooppunten.
Bevindingen
In de komende jaren zijn we van plan om uitgebreid gebruik te maken van ClickHouse in Qwintry, omdat dit DBMS een uitstekende balans biedt tussen prestaties, lage overhead, schaalbaarheid en eenvoud. Ik ben er vrij zeker van dat het zich snel zal verspreiden zodra de ClickHouse-gemeenschap meer manieren bedenkt om het in kleine en middelgrote installaties te gebruiken.
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