— je kolumnasti sustav upravljanja bazama podataka za online obradu analitičkih upita (OLAP) s otvorenim kodom, razvijen od strane Yandexa. Koriste ga Yandex, CloudFlare, VK.com, Badoo i drugi servisi širom svijeta za pohranu zaista velikih količina podataka (ubacivanje tisuća redaka u sekundi ili petabajti podataka pohranjenih na disku).
U uobičajenom, "rednom" DBMS-u, primjeri kojih su MySQL, Postgres, MS SQL Server, podaci se čuvaju u sljedećem redoslijedu:
U tom slučaju, vrijednosti koje pripadaju jednom redu fizički se pohranjuju blizu jedna druge. U kolumnastim DBMS-ima, vrijednosti iz različitih kolona pohranjuju se odvojeno, a podaci iz jedne kolone – zajedno:
Primjeri kolumnastih DBMS-a uključuju 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 – mailforwarder postala je korisnik Clickhousea 2018. godine za izradu izvještaja i bila je vrlo impresionirana njegovom jednostavnošću, skalabilnošću, podrškom za SQL i brzinom. Brzina rada ovog DBMS-a bila je nalik čaroliji.
Jednostavnost
Clickhouse se instalira na Ubuntu jedinstvenom komandom. Ako znate SQL, možete odmah početi koristiti Clickhouse za svoje potrebe. Međutim, to ne znači da možete izvršiti „show create table“ u MySQL i jednostavno kopirati i zalijepiti SQL u Clickhouse.
U usporedbi s MySQL-om, u ovom DBMS-u postoje važna razlikovna svojstva tipova podataka u definicijama shema tablica, stoga će vam ipak trebati neko vrijeme da prilagodite definicije shema tablica i proučite motore tablica.
Clickhouse odlično funkcionira bez ikakvog dodatnog softvera, ali ako želite koristiti replikaciju, trebat ćete instalirati ZooKeeper. Analiza performansi upita pokazuje odlične rezultate – sistemske tablice sadrže sve informacije, a svi podaci mogu se dobiti pomoću starog i dosadnog SQL-a.
Performanse
- usporedbe Clickhousea s Verticom i MySQL-om na konfiguracijskom serveru: dva Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 na 8 6TB SATA HDD, ext4.
- usporedbe Clickhousea s Amazon RedShiftom kao oblakom za pohranu podataka.
- Izdvojci iz bloga :
ClickHouse ima vrlo jednostavan dizajn baze podataka — svi čvorovi u klasteru imaju istu funkcionalnost i koriste samo ZooKeeper za koordinaciju. Izgradili smo mali klaster od nekoliko čvorova i obavili testiranje, pri čemu smo otkrili da sustav ima prilično impresivne performanse koje su u skladu s navedenim prednostima u benchmarkovima analitičkih sustava za upravljanje bazama podataka. Odlučili smo detaljnije istražiti koncept koji leži u osnovi ClickHousea. Prva prepreka za istraživanja bila je nedostatak alata i malobrojna zajednica ClickHouse, pa smo se produbili u dizajn ovog sustava za upravljanje bazama podataka kako bismo razumjeli kako on funkcionira.
ClickHouse ne podržava prijem podataka izravno iz Kafke, jer je to samo baza podataka, pa smo napisali vlastitu uslugu adaptera na jeziku Go. Ona je čitala kodirana poruke Cap’n Proto iz Kafke, pretvarala ih u TSV i umetala u ClickHouse u paketima putem HTTP sučelja. Kasnije smo ovu uslugu prepravili kako bismo korištenjem Go biblioteke zajedno s vlastitim sučeljem ClickHouse poboljšali performanse. Prilikom procjene performansi primanja paketa otkrili smo važnu stvar – ispostavilo se da ClickHouseove performanse uvelike ovise o veličini paketa, tj. broju istodobno umetnutih redaka. Kako bismo razumjeli zašto se to događa, proučili smo kako ClickHouse pohranjuje podatke.
Glavni motor, bolje rečeno, obitelj motora za tablice, koji ClickHouse koristi za pohranu podataka, je MergeTree. Ovaj motor je konceptualno sličan LSM algoritmu koji se koristi u Google BigTable ili Apache Cassandri, međutim izbjegava izradu privremene tablice u memoriji i zapisuje podatke izravno na disk. To mu daje izvrsnu propusnost zapisivanja, jer se svaki umetnuti paket sortira samo prema "primarnom ključu" primary key, komprimira i zapisuje na disk kako bi se formirao segment.
Odsutnost memorijske tablice ili bilo kakvog pojma o "svježini" podataka također znači da se samo mogu dodavati, a sustav ne podržava izmjene ili brisanje. Danas je jedini način za brisanje podataka uklanjanje po kalendarskim mjesecima, budući da segmenti nikada ne prelaze granicu mjeseca. Tim ClickHouse-a aktivno radi na tome da ovu funkciju učini prilagodljivom. S druge strane, to omogućava nekompliciranu upisivanje i spajanje segmenata, pa se propusnost prihvaćanja linearno skalira s brojem paralelnih umetanja, sve dok ne dođe do zasićenja I/O-a ili jezgri.
Međutim, ova okolnost također znači da sustav nije prikladan za male pakete, pa se za međuspremanje koriste Kafka servisi i umetnici. Nadalje, ClickHouse u pozadini neprekidno obavlja spajanje segmenata, tako da će mnogi mali dijelovi informacija biti objedinjeni i zapisani više puta, povećavajući intenzitet pisanja. U isto vrijeme, previše nepovezanih dijelova uzrokovat će agresivno throttling umetanja sve dok spajanje traje. Otkrili smo da je najbolji kompromis između prihvata podataka u stvarnom vremenu i performansi prihvata ograničen broj umetanja po sekundi u tablicu.
Ključ performansi čitanja tablica je indeksiranje i raspored podataka na disku. Bez obzira na to koliko brzo je obrada, kada motor mora skenirati terabajte podataka s diska i koristiti samo dio njih, to će trajati. ClickHouse je kolonsko spremište, pa svaki segment sadrži datoteku za svaku kolonu sa sortiranim vrijednostima za svaki redak. Tako mogu biti preskočeni cijeli stupci koji nisu u upitu, a zatim se mogu nekoliko ćelija obraditi paralelno s vektoriziranom obradom. Da bi se izbjeglo potpuno skeniranje, svaki segment ima mali indeksni datoteku.
S obzirom na to da su svi stupci sortirani prema "primarnom ključu", indeksna datoteka sadrži samo oznake (zabilježene retke) svakog N-tog retka, kako bi ih bilo moguće čuvati u memoriji čak i za vrlo velike tablice. Na primjer, može se postaviti zadano podešavanje "označavanje svakog 8192. retka", tada će "skromno" indeksiranje tablice s 1 trilijunom retka, koja lako staje u memoriju, zahtijevati samo 122 070 znakova.
Razvoj sustava
Razvoj i usavršavanje Clickhousea može se pratiti na i uvjeriti se da proces "odraslog" sustava napreduje impresivnim tempom.
Popularnost
Čini se da popularnost Clickhousea raste eksponencijalno, osobito u ruskom govoru. Konferencija High Load 2018 (Moskva, 8-9. studenog 2018.) pokazala je da takvi divovi kao što su vk.com i Badoo koriste Clickhouse za unos podataka (npr. logove) s desetaka tisuća poslužitelja istovremeno. U 40-minutnom videu . Uskoro ćemo objaviti transkript na Habr-u za lakši rad s materijalom.
Područja primjene
Nakon što sam proveo malo vremena istražujući, mislim da postoje područja u kojima ClickHouse može biti koristan ili u potpunosti zamijeniti druga, tradicionalnija i popularnija rješenja, kao što su MySQL, PostgreSQL, ELK, Google BigQuery, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot i Druid. U nastavku su detalji o korištenju ClickHousea za modernizaciju ili potpunu zamjenu gore navedenih DBMS-ova.
Proširenje mogućnosti MySQL-a i PostgreSQL-a
Nedavno smo djelomično zamijenili MySQL s ClickHouseom za platformu newslettera . Problem je bio u tome što je MySQL zbog lošeg dizajna bilježio svaku poslanu e-poštu i svaku vezu u toj e-pošti sa base64 hashom, stvarajući ogromnu MySQL tablicu (email_stats). Nakon slanja samo 10 milijuna poruka pretplatnicima servisa, ova tablica je zauzela 150 GB prostora na disku, a MySQL je počeo 'usporavati' na jednostavnim upitima. Kako bismo riješili problem s prostorom na disku, uspješno smo koristili kompresiju InnoDB tablica, koja je smanjila njezinu veličinu za 4 puta. Međutim, i dalje nema smisla čuvati više od 20-30 milijuna e-pošta u MySQL-u samo radi pregledavanja povijesti, jer svaki jednostavni upit koji iz nekog razloga mora izvršiti potpuno skeniranje dovodi do swapanja i velikog opterećenja na I/O, o čemu smo redovito primali upozorenja iz Zabbixa.
Clickhouse koristi dva algoritma kompresije koja smanjuju volumen podataka otprilike za , ali u ovom konkretnom slučaju podaci su bili posebno 'kompresibilni'.
Zamjena ELK
Na temelju vlastitog iskustva, ELK stack (ElasticSearch, Logstash i Kibana, u ovom konkretnom slučaju ElasticSearch) zahtijeva mnogo više resursa za pokretanje nego što je potrebno za pohranu logova. ElasticSearch je izvrstan motor ako vam treba dobar pretraživač logova (a mislim da vam to zapravo nije potrebno), ali me zanima zašto je de facto postao standardni motor za vođenje evidencije. Njegova brzina prihvaćanja u kombinaciji s Logstashom stvarala nam je probleme čak i pri prilično malim opterećenjima i zahtijevala dodatak sve većih količina RAM-a i prostora na disku. Kao DB, Clickhouse je bolji od ElasticSearch-a iz sljedećih razloga:
- Podrška za SQL dijalekat;
- Bolji stepen kompresije pohranjenih podataka;
- Podrška za pretraživanje regularnih izraza Regex umjesto pretraživanja punog teksta;
- Poboljšano planiranje upita i veća ukupna učinkovitost.
Trenutno je najveći problem u usporedbi ClickHouse-a s ELK-om nedostatak rješenja za otpremu logova, kao i manjak dokumentacije i vodiča o ovoj temi. Ipak, svaki korisnik može postaviti ELK uz pomoć vodiča Digital Ocean, što je izuzetno važno za brzu implementaciju sličnih tehnologija. Ovdje postoji DB motor, ali još uvijek nema Filebeat-a za ClickHouse. Da, tamo je prisutan. i sustav za rad s logovima , postoji alat za unos log datoteka u ClickHouse, no sve to zahtijeva više vremena. Međutim, ClickHouse i dalje prednjači zbog svoje jednostavnosti, tako da čak i početnici lako instaliraju i započinju potpuno funkcionalnu upotrebu doslovno u roku od 10 minuta.
Preferirajući minimalistička rješenja, pokušao sam koristiti FluentBit, alat za isporuku logova s vrlo malim opterećenjem memorije, zajedno s ClickHouse, nastojeći izbjeći korištenje Kafke. No, potrebno je riješiti male nespojivosti kao što su , prije nego što to bude moguće bez proxy sloja koji pretvara podatke iz FluentBit-a u ClickHouse.
Kao alternativu Kibani, moguće je koristiti ClickHouse kao backend . Koliko sam razumio, mogu nastati problemi s performansama prilikom renderiranja ogromnog broja stavki podataka, posebno s starijim verzijama Grafane. U Qwintry to još nismo probali, ali pritužbe na to povremeno se javljaju na kanalu potpore ClickHouse na Telegramu.
Zamjena za Google Big Query i Amazon RedShift (rješenje za velike tvrtke)
Idealna upotreba BigQuery-a je učitati 1 TB JSON podataka i izvršiti analitičke upite nad njima. Big Query je odličan proizvod čija se skalabilnost teško može precijeniti. Ovo je mnogo složeniji softver od ClickHouse-a koji radi na internom klasteru, ali s gledišta klijenta ima mnogo zajedničkog s ClickHouse-om. BigQuery može brzo 'poskupjeti' čim počnete plaćati za svaki SELECT, pa je to stvarno SaaS rješenje sa svim svojim prednostima i nedostacima.
ClickHouse je najbolji izbor kada izvršavate mnogo skupi zahtjeva s obzirom na izračun. Što više SELECT zahtjeva izvršavate svakodnevno – to više smisla ima zamjena Big Query-a s ClickHouse-om, jer takva zamjena može uštedjeti tisuće dolara kada su u pitanju mnogi terabajti obrađenih podataka. To se ne odnosi na pohranjene podatke, čija obrada u Big Query-u košta prilično malo.
U članku suosnivača tvrtke Altinity Aleksandra Zajceva govori o prednostima takve migracije DBMS-a.
Zamjena za TimescaleDB
TimescaleDB je proširenje PostgreSQL-a koje optimizira rad s vremenskim serijama timeseries u klasičnoj bazi podataka., ).
Iako ClickHouse nije ozbiljan konkurent u niši vremenskih serija, zbog svoje stupčaste strukture i vektorskog izvođenja upita u većini slučajeva analitička obrada upita je puno brža od TimescaleDB-a. Osim toga, performanse prihvata paketnih podataka ClickHouse-a su otprilike tri puta veće, a koristi i 20 puta manje diskovnog prostora, što je zaista važno za obradu velikih količina istorijskih podataka..
Za razliku od ClickHouse-a, jedini način da se u TimescaleDB-u uštedi nešto diskovnog prostora je korišćenje ZFS-a ili sličnih datotečnih sistema.
Nadogradnje ClickHouse-a verovatno će uvesti delta-kompresiju, što će ga učiniti još pogodnijim za obradu i skladištenje podataka vremenskih serija. TimescaleDB može postati bolji izbor od 'gole' verzije ClickHouse-a u sledećim slučajevima:
- mali instalacije s vrlo malo RAM-a (<3 GB);
- velike količine sitnih INSERT-ova koje ne želite da bufersite u velike fragmente;
- bolja konzistencija, jedinstvenost i ACID zahtjevi;
- podrška za PostGIS;
- spajanje sa postojećim PostgreSQL tabelama jer je TimescaleDB suštinski PostgreSQL.
Konkurencija sa Hadoop i MapReduce sistemima
Hadoop i drugi MapReduce proizvodi mogu obaviti mnoge složene izračune, ali obično rade s ogromnim kašnjenjem. ClickHouse ovaj problem rešava obrađujući terabajte podataka i gotovo trenutno dajući rezultate. Tako je ClickHouse mnogo efikasniji za izvođenje brzih, interaktivnih analitičkih istraživanja, što bi trebalo da zainteresuje stručnjake za obradu podataka.
Konkurencija s Pinot i Druid
Najbliži konkurenti ClickHouse-a su stupčasti linearno skalabilni open source proizvodi Pinot i Druid. Odličan pregled uporedbe ovih sistema objavljen je u članku od 1. februara 2018. godine.
Ovaj članak zahteva ažuriranje – u njemu se navodi da ClickHouse ne podržava UPDATE i DELETE operacije, što nije sasvim tačno u vezi sa najnovijim verzijama.
Nemamo dovoljno iskustva s ovim sustavima upravljanja bazama podataka, ali mi se nimalo ne sviđa složenost infrastrukture potrebne za pokretanje Druid i Pinot – to je cijela hrpa 'pokretnih dijelova', okružena Javom sa svih strana.
Druid i Pinot su projekti u inkubatoru Apachea čiji se razvoj detaljno prati na stranicama njihovih GitHub projekata. Pinot je ušao u inkubator u listopadu 2018., dok je Druid nastao 8 mjeseci ranije – u veljači.
Nedostatak informacija o tome kako AFS radi izaziva neka, možda i glupa pitanja. Zanimljivo je, jesu li autori Pinota primijetili da je Apache Foundation sklonija Druid-u i je li to stvorilo zavist prema konkurentu? Hoće li se razvoj Druid-a usporiti, a razvoj Pinota ubrzati, ako sponzori koji podržavaju prvi odjednom pokažu interes za drugi?
Nedostaci ClickHousea
Nezrelost: očito je da je ovo još uvijek zanimljiva tehnologija, ali u svakom slučaju, ništa slično nije primećeno kod drugih sustava upravljanja kolonama.
Male umetnosti loše funkcioniraju pri velikoj brzini: umetanja moraju biti podijeljena na veće dijelove, jer se performanse malih umetanja smanjuju proporcionalno broju kolona u svakoj liniji. Na taj način ClickHouse pohranjuje podatke na disku – svaka kolona predstavlja 1 ili više datoteka, pa je za umetanje 1 reda koji sadrži 100 kolona potrebno otvoriti i zapisati najmanje 100 datoteka. Zato je za spremanje umetanja potreban posrednik (osim ako sam klijent ne osigurava spremanje) – obično je to Kafka ili neki sustav za upravljanje redovima. Također se može koristiti Buffer table engine kako bi se kasnije kopirali veliki dijelovi podataka u MergeTree tablice.
Spojevi tablica ograničeni su operativnom memorijom servera, ali barem postoje! Na primjer, Druid i Pinot uopće nemaju takve spojeve jer ih je teško implementirati u distribuiranim sustavima koji ne podržavaju premještanje velikih količina podataka između čvorova.
Zaključci
U narednim godinama planiramo široku upotrebu ClickHouse-a u Qwintry, jer ova SDB pruža odličnu ravnotežu između performansi, niskih troškova, skalabilnosti i jednostavnosti. Gotovo sam siguran da će se brzo širiti čim zajednica ClickHouse pronađe više načina za korištenje na malim i srednjim instalacijama.
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
