je sistem za upravljanje kolonskom bazom podataka otvorenog koda za online analitičku obradu upita (OLAP) koju je kreirao Yandex. Koriste ga Yandex, CloudFlare, VK.com, Badoo i drugi servisi širom svijeta za skladištenje zaista velikih količina podataka (umetanje hiljada redova u sekundi ili petabajta podataka pohranjenih na disku).
U normalnom, "string" DBMS-u, čiji su primjeri MySQL, Postgres, MS SQL Server, podaci se pohranjuju ovim redoslijedom:
U ovom slučaju, vrijednosti koje se odnose na jedan red se fizički pohranjuju jedna pored druge. U kolonskom DBMS-u vrijednosti iz različitih stupaca se pohranjuju odvojeno, a podaci jedne kolone se pohranjuju zajedno:
Primjeri stupastih DBMS-ova su Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Firma je špediter pošte Počeo sam da koristim Clickhouse 2018. godine za izveštavanje i bio sam veoma impresioniran njegovom jednostavnošću, skalabilnosti, SQL podrškom i brzinom. Brzina ovog DBMS-a graničila je sa magijom.
jednostavnost
Clickhouse se instalira na Ubuntu pomoću jedne naredbe. Ako poznajete SQL, možete odmah početi koristiti Clickhouse za svoje potrebe. Međutim, to ne znači da možete "prikazati kreiranu tabelu" u MySQL-u i kopirati-zalepiti SQL u Clickhouse-u.
U poređenju sa MySQL-om, postoje važne razlike u tipovima podataka u definicijama šeme tablice u ovom DBMS-u, tako da vam je još potrebno neko vrijeme da promijenite definicije sheme tablice i naučite mehanizme tablica kako biste se osjećali udobno.
Clickhouse radi odlično bez ikakvog dodatnog softvera, ali ako želite koristiti replikaciju, morat ćete instalirati ZooKeeper. Analiza performansi upita pokazuje odlične rezultate - sistemske tabele sadrže sve informacije, a svi podaci se mogu dobiti pomoću starog i dosadnog SQL-a.
Produktivnost
- Clickhouse u odnosu na Vertica i MySQL poređenja na konfiguracionom serveru: dva soketa Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 na 8 6TB SATA HDD, ext4.
- poređenje Clickhouse-a sa Amazon RedShift skladištem u oblaku.
- Izvodi iz blogova :
ClickHouse baza podataka ima vrlo jednostavan dizajn - svi čvorovi u klasteru imaju istu funkcionalnost i koriste samo ZooKeeper za koordinaciju. Napravili smo mali klaster od nekoliko čvorova i izvršili testiranje, tokom kojeg smo utvrdili da sistem ima prilično impresivne performanse, što odgovara prednostima koje se navode u analitičkim DBMS benchmarkovima. Odlučili smo da pobliže pogledamo koncept iza ClickHouse. Prva prepreka istraživanju bio je nedostatak alata i mala zajednica ClickHouse-a, pa smo ušli u dizajn ovog DBMS-a kako bismo razumjeli kako on funkcionira.
ClickHouse ne podržava primanje podataka direktno od Kafke, jer je to samo baza podataka, pa smo napisali vlastitu uslugu adaptera u Go. Čitao je Cap'n Proto kodirane poruke iz Kafke, pretvarao ih u TSV i ubacivao ih u ClickHouse u serijama preko HTTP interfejsa. Kasnije smo prepravili ovu uslugu da koristimo Go biblioteku u sprezi sa našim ClickHouse interfejsom kako bismo poboljšali performanse. Kada smo procjenjivali performanse primanja paketa, otkrili smo važnu stvar - pokazalo se da za ClickHouse ova izvedba jako ovisi o veličini paketa, odnosno broju redova ubačenih u isto vrijeme. Da bismo razumjeli zašto se to događa, proučili smo kako ClickHouse pohranjuje podatke.
Glavni mehanizam, ili bolje rečeno, porodica mašina za tablice koje ClickHouse koristi za pohranjivanje podataka je MergeTree. Ovaj mehanizam je konceptualno sličan LSM algoritmu koji se koristi u Google BigTable-u ili Apache Cassandri, ali izbjegava izgradnju međutablice memorije i zapisuje podatke direktno na disk. Ovo mu daje odličnu propusnost pisanja, jer se svaki umetnuti paket sortira samo po primarnom ključu "primarnog ključa", komprimuje se i zapisuje na disk kako bi se formirao segment.
Odsustvo tablice memorije ili bilo kakvog koncepta „svježine“ podataka također znači da se oni mogu samo dodati, sistem ne podržava mijenjanje ili brisanje. Od danas, jedini način za brisanje podataka je brisanje po kalendarskom mjesecu, jer segmenti nikada ne prelaze granicu mjeseca. ClickHouse tim aktivno radi na tome da ovu funkciju učini prilagodljivom. S druge strane, čini pisanje i spajanje segmenata bez sukoba, tako da primate skale propusnosti linearno s brojem paralelnih umetanja dok se I/O ili jezgra ne zasiti.
Međutim, ova okolnost takođe znači da sistem nije pogodan za male pakete, pa se za baferovanje koriste Kafka servisi i inserteri. Nadalje, ClickHouse u pozadini nastavlja kontinuirano spajati segmente, tako da će se mnogi mali dijelovi informacija kombinirati i snimati više puta, čime se povećava intenzitet snimanja. Međutim, previše nepovezanih dijelova će uzrokovati agresivno prigušivanje umetaka sve dok se spajanje nastavlja. Otkrili smo da je najbolji kompromis između unosa podataka u realnom vremenu i performansi unosa prihvatanje ograničenog broja umetanja u sekundi u tabelu.
Ključ za performanse čitanja tablice je indeksiranje i lokacija podataka na disku. Bez obzira koliko je brza obrada, kada motor treba da skenira terabajte podataka s diska i iskoristi samo njihov dio, to će potrajati. ClickHouse je skladište kolona, tako da svaki segment sadrži datoteku za svaku kolonu (kolona) sa sortiranim vrijednostima za svaki red. Dakle, čitave kolone koje nisu prisutne u upitu mogu se prvo preskočiti, a zatim se više ćelija može obraditi paralelno sa vektoriziranim izvršavanjem. Da biste izbjegli potpuno skeniranje, svaki segment ima malu indeksnu datoteku.
S obzirom na to da su sve kolone sortirane po "primarnom ključu", indeksna datoteka sadrži samo oznake (uhvaćene redove) svakog N-tog reda, kako bi ih mogli zadržati u memoriji čak i za vrlo velike tabele. Na primjer, možete podesiti zadane postavke na “označiti svaki 8192. red”, zatim “oskudno” indeksiranje tabele sa 1 trilion. linije koje se lako uklapaju u memoriju trebale bi samo 122 znakova.
Razvoj sistema
Razvoj i unapređenje Clickhouse-a može se pratiti i pobrinite se da se proces "odrastanja" odvija impresivnim tempom.
Popularnost
Čini se da Clickhouse-ova popularnost raste eksponencijalno, posebno u zajednici koja govori ruski. Prošlogodišnja konferencija High load 2018 (Moskva, 8-9. novembar 2018.) pokazala je da čudovišta poput vk.com i Badooa koriste Clickhouse, koji istovremeno ubacuje podatke (na primjer, logove) sa desetina hiljada servera. U videu od 40 minuta . Uskoro ćemo transkript postaviti na Habr radi lakšeg rada sa materijalom.
Aplikacije
Nakon što sam proveo neko vrijeme istražujući, mislim da postoje oblasti u kojima ClickHouse može biti koristan ili sposoban u potpunosti zamijeniti druga tradicionalnija i popularnija rješenja kao što su MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot i Druid. Slijede detalji korištenja ClickHouse-a za nadogradnju ili potpunu zamjenu gore navedenog DBMS-a.
Proširivanje MySQL-a i PostgreSQL-a
Nedavno smo djelimično zamijenili MySQL sa ClickHouse za platformu za bilten . Problem je bio u tome što je MySQL zbog loše osmišljenog dizajna evidentirao svaku poslanu e-poštu i svaku vezu u toj e-poruci sa base64 hešom, stvarajući ogromnu MySQL tabelu (email_stats). Nakon slanja samo 10 miliona mejlova pretplatnicima servisa, ova tabela je zauzela 150 GB prostora u fajlovima, a MySQL je počeo da "glupi" na jednostavne upite. Da bismo riješili problem s prostorom datoteka, uspješno smo koristili InnoDB kompresiju tablice, što ga je smanjilo za faktor 4. Međutim, još uvijek nema smisla pohranjivati više od 20-30 milijuna e-mailova u MySQL samo radi čitanja povijesti, jer svaki jednostavan upit koji iz nekog razloga mora izvršiti potpuno skeniranje dovodi do zamjene i velikog ulazno-izlaznog opterećenja, o čemu smo redovno dobijali Zabbix upozorenja.
Clickhouse koristi dva algoritma kompresije koji smanjuju količinu podataka otprilike , ali u ovom konkretnom slučaju podaci su bili posebno "komprimirani".
ELK Zamjena
Na osnovu mog sopstvenog iskustva, ELK stek (ElasticSearch, Logstash i Kibana, u ovom konkretnom slučaju ElasticSearch) zahteva mnogo više resursa za pokretanje nego što je potrebno za skladištenje dnevnika. ElasticSearch je odličan motor ako želite dobru pretragu po cijelom tekstu (što mislim da vam nije potrebno), ali pitam se zašto je postao de facto standardni mehanizam za evidentiranje. Njegove performanse unosa, u kombinaciji sa Logstash-om, stvarale su nam probleme čak i pri prilično malim radnim opterećenjima i zahtijevale su dodavanje sve više RAM-a i prostora na disku. Kao baza podataka, Clickhouse je bolji od ElasticSearch-a iz sljedećih razloga:
- podrška za SQL dijalekt;
- Najbolji stepen kompresije pohranjenih podataka;
- Podrška za pretraživanje Regex umjesto pretraživanja punog teksta;
- Poboljšano zakazivanje upita i bolje ukupne performanse.
Trenutno najveći problem koji se javlja prilikom poređenja ClickHouse-a sa ELK-om je nedostatak rješenja za upload logova, kao i nedostatak dokumentacije i tutorijala na ovu temu. Istovremeno, svaki korisnik može podesiti ELK koristeći priručnik Digital Ocean, što je vrlo važno za brzu implementaciju ovakvih tehnologija. Ovdje postoji mehanizam baze podataka, ali još uvijek ne postoji Filebeat za ClickHouse. Da tu je i sistem za rad sa logovima , postoji alat da unesete podatke iz log fajla u ClickHouse, ali za sve to treba više vremena. Međutim, ClickHouse i dalje prednjači zbog svoje jednostavnosti, tako da ga čak i početnici mogu lako instalirati i započeti potpuno funkcionalnu upotrebu za samo 10 minuta.
Preferirajući minimalistička rješenja, pokušao sam koristiti FluentBit, alatku za učitavanje dnevnika s vrlo malo memorije, uz ClickHouse dok sam pokušavao izbjeći korištenje Kafke. Međutim, potrebno je riješiti manje nekompatibilnosti, kao što su prije nego što se to može učiniti bez proxy sloja koji pretvara podatke iz FluentBit u ClickHouse.
Kao alternativu Kibani, možete koristiti ClickHouse kao backend . Koliko ja razumijem, to može uzrokovati probleme s performansama pri renderiranju velikog broja podataka, posebno sa starijim verzijama Grafane. U Qwintryju ovo još nismo isprobali, ali se s vremena na vrijeme pojavljuju žalbe na to na ClickHouse kanalu podrške u Telegramu.
Zamjena Google Big Queryja i Amazon RedShift (rješenje za velike kompanije)
Idealan slučaj upotrebe BigQueryja je učitavanje 1TB JSON podataka i pokretanje analitičkih upita na njima. Big Query je odličan proizvod čiju je skalabilnost teško precijeniti. Ovo je mnogo složeniji softver od ClickHousea koji radi na internom klasteru, ali sa stanovišta klijenta, ima dosta zajedničkog sa ClickHouseom. BigQuery može brzo "poskupiti" kada počnete da plaćate za svaki SELECT, tako da je to pravo SaaS rješenje sa svim svojim prednostima i nedostacima.
ClickHouse je najbolji izbor kada pokrećete mnogo računarski skupih upita. Što više SELECT upita pokrenete svaki dan, to je više smisla zamijeniti Big Query sa ClickHouse, jer će vam takva zamjena uštedjeti hiljade dolara kada je u pitanju mnogo terabajta podataka koji se obrađuju. Ovo se ne odnosi na pohranjene podatke, koji su prilično jeftini za obradu u Big Queryju.
U članku Aleksandra Zajceva, suosnivača Altinityja opisuje prednosti takve DBMS migracije.
TimescaleDB Zamjena
TimescaleDB je PostgreSQL ekstenzija koja optimizuje rad sa vremenskim serijama u redovnoj bazi podataka (, ).
Iako ClickHouse nije ozbiljan konkurent u niši vremenskih serija, ali u smislu stupne strukture i vektorskog izvršenja upita, mnogo je brži od TimescaleDB-a u većini slučajeva obrade analitičkih upita. Istovremeno, performanse prijema ClickHouse paketnih podataka su oko 3 puta veće, osim toga, koristi 20 puta manje prostora na disku, što je zaista važno za obradu velikih količina povijesnih podataka: .
Za razliku od ClickHouse-a, jedini način da uštedite malo prostora na disku u TimescaleDB-u je korištenje ZFS-a ili sličnih sistema datoteka.
Predstojeća ažuriranja ClickHouse-a će vjerovatno uvesti delta kompresiju, što će ga učiniti još pogodnijim za obradu i pohranjivanje podataka vremenskih serija. TimescaleDB može biti bolji izbor od golog ClickHousea u sljedećim slučajevima:
- male instalacije sa vrlo malo RAM-a (<3 GB);
- veliki broj malih INSERT-ova koje ne želite da baferujete u velike fragmente;
- bolja konzistentnost, uniformnost i zahtjevi za ACID;
- PostGIS podrška;
- spojiti sa postojećim PostgreSQL tabelama, pošto je Timescale DB u suštini PostgreSQL.
Konkurencija sa Hadoop i MapReduce sistemima
Hadoop i drugi MapReduce proizvodi mogu izvesti mnogo složenih proračuna, ali imaju tendenciju da rade sa velikim kašnjenjem. ClickHouse rješava ovaj problem tako što obrađuje terabajte podataka i daje rezultate gotovo trenutno. Dakle, ClickHouse je mnogo efikasniji za obavljanje brzih, interaktivnih analitičkih istraživanja, što bi trebalo da bude od interesa za data naučnike.
Konkurencija sa Pinotom i Druidom
Najbliži konkurenti ClickHousea su kolonasti, linearno skalabilni proizvodi otvorenog koda Pinot i Druid. Odličan posao upoređivanja ovih sistema objavljen je u članku 1. februara 2018
Ovaj članak treba ažurirati - piše da ClickHouse ne podržava operacije UPDATE i DELETE, što nije sasvim tačno u odnosu na najnovije verzije.
Nemamo mnogo iskustva sa ovim DBMS-ovima, ali mi se ne sviđa složenost osnovne infrastrukture koja je potrebna za pokretanje Druida i Pinot-a – to je čitava gomila „pokretnih delova“ okruženih Javom sa svih strana.
Druid i Pinot su projekti Apache inkubatora, koje Apache detaljno obrađuje na svojim stranicama GitHub projekta. Pinot se pojavio u inkubatoru u oktobru 2018., a Druid je rođen 8 mjeseci ranije - u februaru.
Nedostatak informacija o tome kako AFS funkcioniše postavlja mi neka, a možda i glupa pitanja. Pitam se da li su autori Pinota primijetili da je fondacija Apache sklonija Druidu i da li je takav odnos prema konkurentu izazvao osjećaj zavisti? Hoće li se razvoj Druida usporiti, a razvoj pinota ubrzati ako se sponzori koji podržavaju prvog iznenada zainteresuju za potonjeg?
Nedostaci ClickHouse-a
Nezrelost: Očigledno, ovo je još uvijek dosadna tehnologija, ali u svakom slučaju, ništa slično ovome se ne viđa u drugim kolumnarskim DBMS-ima.
Mali umetci ne rade dobro pri velikoj brzini: umetci se moraju podijeliti na velike komade jer se performanse malih umetaka smanjuju proporcionalno broju kolona u svakom redu. Ovako ClickHouse pohranjuje podatke na disk - svaka kolona znači 1 fajl ili više, tako da da biste umetnuli 1 red koji sadrži 100 kolona, morate otvoriti i napisati najmanje 100 datoteka. Zbog toga je za umetanje u međuspremnik potreban posrednik (osim ako sam klijent ne obezbjeđuje baferovanje) - obično Kafka ili neka vrsta sistema čekanja. Također možete koristiti mehanizam Buffer table za kasnije kopiranje velikih komada podataka u MergeTree tabele.
Pridruživanja tablica su ograničena RAM-om servera, ali barem su tu! Na primjer, Druid i Pinot uopće nemaju takve veze, jer ih je teško implementirati direktno u distribuirane sisteme koji ne podržavaju premještanje velikih komada podataka između čvorova.
nalazi
U narednim godinama planiramo da u velikoj mjeri koristimo ClickHouse u Qwintryju, jer ovaj DBMS pruža odličnu ravnotežu performansi, niske troškove, skalabilnost i jednostavnost. Prilično sam siguran da će se brzo proširiti kada ClickHouse zajednica smisli više načina za korištenje u malim i srednjim instalacijama.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com