je sustav za upravljanje stupčastim bazama podataka otvorenog koda za online analitičku obradu upita (OLAP), kreiran od strane Yandexa. Koriste ga Yandex, CloudFlare, VK.com, Badoo i drugi servisi diljem svijeta za pohranjivanje stvarno velikih količina podataka (umetanje tisuća redaka u sekundi ili petabajta podataka pohranjenih na disku).
U običnom, “string” DBMS-u, čiji su primjeri MySQL, Postgres, MS SQL Server, podaci se pohranjuju sljedećim redoslijedom:
U ovom slučaju, vrijednosti koje se odnose na jedan red fizički su pohranjene u blizini. U stupnim DBMS-ovima, vrijednosti iz različitih stupaca pohranjuju se odvojeno, a podaci iz jednog stupca pohranjuju se zajedno:
Primjeri stupčastih 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+.
Tvrtka za otpremu pošte počeo je koristiti Clickhouse 2018. za izvješćivanje i bio je vrlo impresioniran njegovom jednostavnošću, skalabilnošću, podrškom za SQL i brzinom. Brzina ovog DBMS-a graničila je s magijom.
Ublažiti
Clickhouse se instalira na Ubuntu jednom jedinom naredbom. Ako poznajete SQL, odmah možete početi koristiti Clickhouse za svoje potrebe. Međutim, to ne znači da možete učiniti "prikaži kreirati tablicu" u MySQL-u i kopirati-zalijepiti SQL u Clickhouse.
U usporedbi s MySQL-om, postoje važne razlike u tipovima podataka u definicijama sheme tablice, tako da će vam ipak trebati neko vrijeme da promijenite definicije sheme tablice i naučite mehanizme tablice kako biste se osjećali ugodno.
Clickhouse radi odlično bez dodatnog softvera, ali ako želite koristiti replikaciju, morat ćete instalirati ZooKeeper. Analiza performansi upita pokazuje odlične rezultate - sistemske tablice sadrže sve informacije, a svi se podaci mogu dohvatiti pomoću starog i dosadnog SQL-a.
Performanse
- usporedbe Clickhousea s Verticom i MySQL na konfiguraciji poslužitelja: dva socketa Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 na 8 6TB SATA HDD, ext4.
- usporedba Clickhousea s pohranom u oblaku Amazon RedShift.
- Izvadci s bloga :
Baza podataka ClickHouse ima vrlo jednostavan dizajn - svi čvorovi u klasteru imaju istu funkcionalnost i koriste samo ZooKeeper za koordinaciju. Izgradili smo mali klaster od nekoliko čvorova i proveli testiranje, tijekom kojeg smo ustanovili da sustav ima prilično impresivne performanse, što odgovara navedenim prednostima u analitičkim DBMS benchmarkovima. Odlučili smo pobliže pogledati koncept iza ClickHousea. Prva prepreka istraživanju bio je nedostatak alata i mala ClickHouse zajednica, pa smo se udubili u dizajn ovog DBMS-a kako bismo razumjeli kako funkcionira.
ClickHouse ne podržava primanje podataka izravno od Kafke budući da je to samo baza podataka, pa smo napisali vlastitu uslugu adaptera u Go. Čitao je Cap'n Proto kodirane poruke od Kafke, pretvarao ih u TSV i ubacivao u ClickHouse u serijama putem HTTP sučelja. Kasnije smo ponovno napisali ovu uslugu kako bismo koristili biblioteku Go u kombinaciji s vlastitim sučeljem tvrtke ClickHouse za poboljšanje performansi. Prilikom ocjenjivanja performansi primanja paketa otkrili smo važnu stvar - pokazalo se da za ClickHouse ta izvedba jako ovisi o veličini paketa, odnosno broju istovremeno umetnutih redaka. Da bismo razumjeli zašto se to događa, pogledali smo kako ClickHouse pohranjuje podatke.
Glavni motor, odnosno obitelj tabličnih motora, koje koristi ClickHouse za pohranu podataka je MergeTree. Ovaj mehanizam je konceptualno sličan LSM algoritmu koji se koristi u Google BigTable ili Apache Cassandra, ali izbjegava konstrukciju srednje memorijske tablice i zapisuje podatke izravno na disk. To mu daje izvrsnu propusnost pisanja, budući da je svaki umetnuti paket razvrstan samo po primarnom ključu, komprimiran i zapisan na disk u obliku segmenta.
Nepostojanje memorijske tablice ili bilo kakvog koncepta "svježine" podataka također znači da se oni mogu samo dodavati; sustav ne podržava promjenu ili brisanje. Trenutačno je jedini način brisanja podataka brisanje po kalendarskom mjesecu jer segmenti nikada ne prelaze mjesečnu granicu. ClickHouse tim aktivno radi na tome da ovu značajku učini prilagodljivom. S druge strane, segmente za pisanje i spajanje čini slobodnim, tako da se propusnost primanja linearno mjeri s brojem istodobnih umetanja dok ne dođe do zasićenja I/O ili jezgre.
Međutim, to također znači da sustav nije prikladan za male pakete, pa se Kafka servisi i umetci koriste za međuspremnik. Zatim, ClickHouse u pozadini nastavlja konstantno spajanje segmenata, tako da će se mnogo malih informacija kombinirati i snimati više puta, čime se povećava intenzitet snimanja. Međutim, previše nepovezanih dijelova uzrokovat će agresivno usporavanje umetaka sve dok se spajanje nastavlja. Utvrdili smo da je najbolji kompromis između unosa u stvarnom vremenu i performansi unosa unos ograničenog broja umetanja u sekundi u tablicu.
Ključ izvedbe čitanja tablice je indeksiranje i lokacija podataka na disku. Bez obzira na to koliko je brza obrada, kada motor treba skenirati terabajte podataka s diska i koristiti samo njihov dio, trebat će vremena. ClickHouse je pohrana u stupcima, tako da svaki segment sadrži datoteku za svaki stupac (stupac) s sortiranim vrijednostima za svaki redak. Na taj se način najprije mogu preskočiti cijeli stupci koji nedostaju u upitu, a zatim se više ćelija može obraditi paralelno s vektoriziranim izvršavanjem. Kako bi se izbjeglo potpuno skeniranje, svaki segment ima malu indeksnu datoteku.
S obzirom na to da su svi stupci sortirani prema "primarnom ključu", indeksna datoteka sadrži samo oznake (uhvaćene retke) svakog N-tog retka kako bi ih se moglo zadržati u memoriji čak i za vrlo velike tablice. Na primjer, možete postaviti zadane postavke na "označavanje svakog 8192. reda", zatim "oskudno" indeksiranje tablice s 1 trilijun. linije koje lako stanu u memoriju zauzet će samo 122 070 znakova.
Razvoj sustava
Razvoj i poboljšanje Clickhousea može se pratiti na i pobrinite se da se proces "odrastanja" odvija impresivnom brzinom.
Popularnost
Čini se da popularnost Clickhousea eksponencijalno raste, posebno u zajednici koja govori ruski. Prošlogodišnja konferencija High load 2018 (Moskva, 8.-9. studenog 2018.) pokazala je da takva čudovišta kao što su vk.com i Badoo koriste Clickhouse, s kojim ubacuju podatke (na primjer, logove) s desetaka tisuća poslužitelja istovremeno. U videu od 40 minuta . Uskoro ćemo transkript objaviti na Habru radi lakšeg rada s materijalom.
aplikacije
Nakon što sam proveo neko vrijeme istražujući, mislim da postoje područja u kojima bi ClickHouse mogao biti koristan ili bi mogao 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. Sljedeće opisuje detalje korištenja ClickHousea za modernizaciju ili potpunu zamjenu gore navedenog DBMS-a.
Proširenje mogućnosti MySQL-a i PostgreSQL-a
Nedavno smo djelomično zamijenili MySQL s ClickHouseom za našu newsletter platformu . Problem je bio u tome što je MySQL, zbog lošeg dizajna, bilježio svaki poslani e-mail i svaku vezu u tom e-mailu s base64 hashom, stvarajući ogromnu MySQL tablicu (email_stats). Nakon slanja samo 10 milijuna e-mailova pretplatnicima usluga, ova tablica je zauzela 150 GB prostora u datotekama, a MySQL je počeo biti "glup" na jednostavnim upitima. Kako bismo riješili problem s prostorom datoteke, uspješno smo upotrijebili InnoDB kompresiju tablice koja ga je smanjila za faktor 4. Međutim, još uvijek nema smisla pohranjivati više od 20-30 milijuna e-poruka u MySQL samo radi čitanja povijesti, budući da svaki jednostavan upit koji iz nekog razloga treba izvršiti potpuno skeniranje rezultira swapom i puno I /O load, o čemu smo redovito dobivali upozorenja od Zabbixa.
Clickhouse koristi dva algoritma kompresije koji smanjuju količinu podataka za približno , ali u ovom konkretnom slučaju podaci su bili posebno "komprimirani".
Zamjena ELK
Na temelju mog vlastitog iskustva, ELK stog (ElasticSearch, Logstash i Kibana, u ovom konkretnom slučaju ElasticSearch) zahtijeva puno više resursa za rad nego što je potrebno za pohranu zapisa. ElasticSearch je izvrstan mehanizam ako trebate dobro pretraživanje dnevnika cijelog teksta (što mislim da vam zapravo nije potrebno), ali pitam se zašto je postao de facto standardni motor za bilježenje. Njegova izvedba unosa u kombinaciji s Logstashom stvarala nam je probleme čak i pod relativno malim opterećenjima i zahtijevala od nas da dodajemo 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 stupanj kompresije pohranjenih podataka;
- Podrška za pretraživanje regularnih izraza Regex umjesto pretraživanja cijelog teksta;
- Poboljšano zakazivanje upita i veća ukupna izvedba.
Trenutno najveći problem koji se javlja pri usporedbi ClickHousea s ELK-om je nedostatak rješenja za upload logova, kao i nedostatak dokumentacije i tutorijala na tu temu. Štoviše, svaki korisnik može konfigurirati ELK pomoću priručnika Digital Ocean, što je vrlo važno za brzu implementaciju takvih tehnologija. Postoji mehanizam baze podataka, ali još ne postoji Filebeat za ClickHouse. Da, tu je te sustav za rad s zapisnicima , postoji alat za unos podataka iz log datoteke u ClickHouse, ali sve to oduzima više vremena. No, ClickHouse je i dalje vodeći po svojoj jednostavnosti, pa ga i početnici mogu lako instalirati i početi koristiti u potpunosti funkcionalno u samo 10 minuta.
Preferirajući minimalistička rješenja, pokušao sam koristiti FluentBit, alat za otpremu zapisa s vrlo malo memorije, zajedno s ClickHouseom, pokušavajući izbjeći korištenje Kafke. Međutim, potrebno je riješiti manje nekompatibilnosti, kao što je prije nego što se to može učiniti bez proxy sloja koji pretvara podatke iz FluentBita u ClickHouse.
Kao alternativa, Kibana se može koristiti kao ClickHouse backend . Koliko ja razumijem, to može uzrokovati probleme s performansama pri prikazivanju ogromnog broja podatkovnih točaka, posebno sa starijim verzijama Grafane. Ovo još nismo isprobali u Qwintryju, ali pritužbe o ovome pojavljuju se s vremena na vrijeme na ClickHouse kanalu podrške na Telegramu.
Zamjena za Google Big Query i Amazon RedShift (rješenje za velike tvrtke)
Idealan slučaj upotrebe za BigQuery je učitavanje 1 TB JSON podataka i pokretanje analitičkih upita na njima. Big Query izvrstan je proizvod čija se skalabilnost ne može precijeniti. Ovo je puno složeniji softver od ClickHousea, koji radi na internom klasteru, ali sa stajališta klijenta ima mnogo toga zajedničkog s ClickHouseom. BigQuery može brzo postati skup kada počnete plaćati po SELECT-u, tako da je to pravo SaaS rješenje sa svim svojim prednostima i manama.
ClickHouse je najbolji izbor kada pokrećete mnogo računalno skupih upita. Što više SELECT upita pokrećete svaki dan, to više ima smisla zamijeniti Big Query s ClickHouseom, jer vam takva zamjena može uštedjeti tisuće dolara kada se radi o 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 suosnivača Altinityja Alexandera Zaitseva govori o prednostima takve migracije DBMS-a.
TimescaleDB zamjena
TimescaleDB je PostgreSQL ekstenzija koja optimizira rad s vremenskim serijama vremenskih serija u redovnoj bazi podataka (, ).
Iako ClickHouse nije ozbiljan konkurent u niši vremenskih serija, već stupčaste strukture i vektorskog izvršavanja upita, puno je brži od TimescaleDB-a u većini slučajeva analitičke obrade upita. U isto vrijeme, performanse primanja batch podataka od ClickHouse-a su otprilike 3 puta veće, a također koristi 20 puta manje prostora na disku, što je jako važno za obradu velikih količina povijesnih podataka: .
Za razliku od ClickHousea, jedini način da uštedite prostor na disku u TimescaleDB-u je korištenje ZFS-a ili sličnih datotečnih sustava.
Nadolazeća ažuriranja ClickHousea vjerojatno će uvesti delta kompresiju, što će ga učiniti još prikladnijim za obradu i pohranu podataka vremenskih serija. TimescaleDB može biti bolji izbor od golog ClickHousea u sljedećim slučajevima:
- male instalacije s vrlo malo RAM-a (<3 GB);
- veliki broj malih INSERT-a koje ne želite spremati u međuspremnik u velike fragmente;
- bolja konzistentnost, ujednačenost i zahtjevi za KISELINOM;
- PostGIS podrška;
- spajanje s postojećim PostgreSQL tablicama, budući da je Timescale DB u biti PostgreSQL.
Konkurencija sa sustavima Hadoop i MapReduce
Hadoop i drugi MapReduce proizvodi mogu izvesti mnogo složenih izračuna, ali obično rade s velikim kašnjenjima. ClickHouse rješava ovaj problem obradom terabajta podataka i izradom rezultata gotovo trenutno. Stoga je ClickHouse puno učinkovitiji u izvođenju brzih, interaktivnih analitičkih istraživanja, što bi trebalo zanimati znanstvenike koji se bave podacima.
Konkurencija pinotu i druidu
ClickHouseovi najbliži konkurenti su stupčasti, linearno skalabilni proizvodi otvorenog koda Pinot i Druid. U članku je objavljen odličan rad koji uspoređuje ove sustave od 1. veljače 2018. godine
Ovaj članak treba ažurirati - piše da ClickHouse ne podržava operacije UPDATE i DELETE, što nije sasvim točno za najnovije verzije.
Nemamo puno iskustva s tim bazama podataka, ali ne sviđa mi se baš složenost infrastrukture koja je potrebna za pokretanje Druida i Pinota - to je cijela hrpa pokretnih dijelova okruženih Javom sa svih strana.
Druid i Pinot su projekti Apache inkubatora, čiji je napredak detaljno pokriven od strane Apachea na njegovim stranicama GitHub projekta. Pinot se pojavio u inkubatoru u listopadu 2018., a Druid je rođen 8 mjeseci ranije - u veljači.
Nedostatak informacija o tome kako AFS funkcionira postavlja mi neka, možda i glupa, pitanja. Zanima me jesu li autori Pinota primijetili da je Zaklada Apache naklonjenija Druidu i je li takav odnos prema konkurentu izazvao osjećaj zavisti? Hoće li se razvoj Druida usporiti, a Pinota ubrzati ako se podupiratelji prvog odjednom zainteresiraju za drugog?
Nedostaci ClickHousea
Nezrelost: Očito, ovo još uvijek nije dosadna tehnologija, ali u svakom slučaju, ništa slično nije uočeno u drugim stupnim DBMS-ovima.
Mali umetci nemaju dobru izvedbu pri velikoj brzini: umetci se moraju podijeliti u veće dijelove jer izvedba malih umetaka opada proporcionalno broju stupaca u svakom retku. Ovo je način na koji ClickHouse pohranjuje podatke na disk - svaki stupac predstavlja 1 datoteku ili više, pa da biste umetnuli 1 redak sa 100 stupaca, morate otvoriti i napisati najmanje 100 datoteka. Zbog toga umeci za međuspremnik zahtijevaju posrednika (osim ako sam klijent ne osigurava međuspremnik) - obično Kafka ili neka vrsta sustava za upravljanje redom čekanja. Također možete koristiti mehanizam međuspremnika za kasnije kopiranje velikih dijelova podataka u tablice MergeTree.
Spajanja tablica ograničena su RAM-om poslužitelja, ali barem su tu! Na primjer, Druid i Pinot uopće nemaju takve veze, jer ih je teško implementirati izravno u distribuiranim sustavima koji ne podržavaju premještanje velikih dijelova podataka između čvorova.
Zaključci
Planiramo naširoko koristiti ClickHouse u Qwintryju u nadolazećim godinama, budući da ovaj DBMS pruža izvrsnu ravnotežu performansi, niskih troškova, skalabilnosti i jednostavnosti. Prilično sam siguran da će se brzo početi širiti kada ClickHouse zajednica smisli više načina za njegovu upotrebu u malim do srednjim instalacijama.
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com