estas malfermfonta kolona datumbaza administradsistemo por interreta analiza pritraktado de demandoj (OLAP) kreita de Yandex. Ĝi estas uzata de Yandex, CloudFlare, VK.com, Badoo kaj aliaj servoj tra la mondo por stoki vere grandajn kvantojn da datumoj (enmeto de miloj da vicoj sekundo aŭ petabajtoj da datumoj stokitaj sur disko).
En normala, "ŝnuro" DBMS, ekzemploj de kiuj estas MySQL, Postgres, MS SQL Server, datumoj estas stokitaj en ĉi tiu ordo:
En ĉi tiu kazo, la valoroj rilataj al unu vico estas fizike konservitaj unu apud la alia. En kolumna DBMS, valoroj de malsamaj kolumnoj estas stokitaj aparte, kaj la datumoj de unu kolumno estas stokitaj kune:
Ekzemploj de kolonaj DBMSoj estas Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
La kompanio estas poŝtsendisto Mi komencis uzi Clickhouse en 2018 por raportado kaj estis tre impresita pri ĝia simpleco, skaleblo, SQL-subteno kaj rapideco. La rapideco de ĉi tiu DBMS limis al magio.
faciligi
Clickhouse instalas sur Ubuntu per ununura komando. Se vi konas SQL, vi povas tuj komenci uzi Clickhouse por viaj bezonoj. Tamen, ĉi tio ne signifas, ke vi povas "montri krei tabelon" en MySQL kaj kopii-alglui SQL en Clickhouse.
Kompare kun MySQL, estas gravaj datumtipdiferencoj en la tabelskemdifinoj en ĉi tiu DBMS, do vi ankoraŭ bezonas iom da tempo por ŝanĝi la tabelskemdifinojn kaj lerni la tabelajn motorojn por komfortiĝi.
Clickhouse funkcias bonege sen aldona programaro, sed se vi volas uzi reproduktadon, vi devos instali ZooKeeper. Demanda agado-analizo montras bonegajn rezultojn - la sistemaj tabeloj enhavas ĉiujn informojn, kaj ĉiuj datumoj povas esti akiritaj per malnova kaj enuiga SQL.
Produkteco
- Clickhouse kontraŭ Vertica kaj MySQL-koparoj sur agorda servilo: du ingoj Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 sur 8 6TB SATA HDD, ekst4.
- komparo de Clickhouse kun Amazon RedShift nuba stokado.
- Blogaj eltiraĵoj :
La ClickHouse-datumbazo havas tre simplan dezajnon - ĉiuj nodoj en la areto havas la saman funkciecon kaj uzas nur ZooKeeper por kunordigo. Ni konstruis malgrandan areton de pluraj nodoj kaj faris testadon, dum kiu ni trovis, ke la sistemo havas sufiĉe imponan agadon, kio respondas al la pretenditaj avantaĝoj en analizaj DBMS-referenco. Ni decidis pli detale rigardi la koncepton malantaŭ ClickHouse. La unua obstaklo al esplorado estis la manko de iloj kaj la malgranda komunumo de ClickHouse, do ni enprofundiĝis en la dezajnon de ĉi tiu DBMS por kompreni kiel ĝi funkcias.
ClickHouse ne subtenas ricevi datumojn rekte de Kafka, ĉar ĝi estas nur datumbazo, do ni skribis nian propran adaptilon en Go. Ĝi legis Cap'n Proto ĉifritajn mesaĝojn de Kafka, konvertis ilin al TSV, kaj enigis ilin en ClickHouse en aroj per la HTTP-interfaco. Ni poste reverkis ĉi tiun servon por uzi la Go-bibliotekon kune kun nia propra ClickHouse-interfaco por plibonigi rendimenton. Analizante la agadon de ricevado de pakaĵoj, ni malkovris gravan aferon - montriĝis, ke por ClickHouse ĉi tiu agado forte dependas de la grandeco de la pako, tio estas, la nombro da vicoj enmetitaj samtempe. Por kompreni kial tio okazas, ni studis kiel ClickHouse konservas datumojn.
La ĉefa motoro, aŭ pli ĝuste, familio de tabelmotoroj uzataj de ClickHouse por stoki datumojn, estas MergeTree. Ĉi tiu motoro estas koncipe simila al la LSM-algoritmo uzata en Google BigTable aŭ Apache Cassandra, sed evitas konstrui mezan memortabelon kaj skribas datumojn rekte al disko. Tio donas al ĝi bonegan skriban trairon, ĉar ĉiu enigita pakaĵeto estas nur ordigita per la "ĉefa ŝlosilo" ĉefŝlosilo, kunpremita, kaj skribita al disko por formi segmenton.
La foresto de memortabelo aŭ ajna koncepto de "freŝeco" de datumoj ankaŭ signifas, ke ili nur povas esti aldonitaj, la sistemo ne subtenas ŝanĝi aŭ forigi. Ekde hodiaŭ, la nura maniero forigi datumojn estas forigi ĝin laŭ kalendara monato, ĉar segmentoj neniam transiras monatan limon. La ClickHouse-teamo aktive laboras por fari ĉi tiun funkcion agordebla. Aliflanke, ĝi faras skribi kaj kunfandi segmentojn liberaj de disputo, do ricevu traigajn skalojn linie kun la nombro da paralelaj enigaĵoj ĝis I/O aŭ kernoj saturiĝas.
Tamen, ĉi tiu cirkonstanco ankaŭ signifas, ke la sistemo ne taŭgas por malgrandaj pakaĵoj, do Kafka-servoj kaj enigiloj estas uzataj por bufrado. Plue, ClickHouse en la fono daŭre kunfandas segmentojn, tiel ke multaj malgrandaj informoj estos kombinitaj kaj registritaj pli da fojoj, tiel pliigante la intensecon de registrado. Tamen, tro da senrilataj partoj kaŭzos agreseman strekadon de enigaĵoj tiel longe kiel la kunfandado daŭras. Ni trovis, ke la plej bona kompromiso inter realtempa konsumado de datumoj kaj konsuma rendimento estas akcepti limigitan nombron da enmetoj sekundo en la tabelon.
La ŝlosilo al tabellegado estas la indeksado kaj loko de la datumoj sur disko. Kiom ajn rapida estas la prilaborado, kiam la motoro bezonas skani terabajtojn da datumoj de disko kaj uzi nur frakcion de ĝi, ĝi daŭros tempon. ClickHouse estas kolumna vendejo, do ĉiu segmento enhavas dosieron por ĉiu kolumno (kolumno) kun ordigitaj valoroj por ĉiu vico. Tiel, tutaj kolumnoj ne ĉeestantaj en la demando unue povas esti preterlasitaj, kaj tiam pluraj ĉeloj povas esti procesitaj paralele kun vektorigita ekzekuto. Por eviti plenan skanadon, ĉiu segmento havas malgrandan indeksan dosieron.
Konsiderante ke ĉiuj kolumnoj estas ordigitaj per la "ĉefa ŝlosilo", la indeksa dosiero enhavas nur la etikedojn (kaptitaj vicoj) de ĉiu N-a vico, por povi konservi ilin en memoro eĉ por tre grandaj tabeloj. Ekzemple, vi povas agordi la defaŭltajn agordojn por "marki ĉiun 8192-an vicon", tiam "magra" indeksado de tabelo kun 1 duiliono. linioj kiuj konvenas facile en memoron nur prenus 122 signojn.
Sistemevoluo
La evoluo kaj plibonigo de Clickhouse povas esti spuritaj kaj certigu, ke la procezo de "kreskado" okazas je impona rapideco.
Populareco
Ŝajnas, ke la populareco de Clickhouse kreskas eksponente, precipe en la ruslingva komunumo. La pasintjara High load 2018-konferenco (Moskvo, novembro 8-9, 2018) montris, ke monstroj kiel vk.com kaj Badoo uzas Clickhouse, kiu enmetas datumojn (ekzemple protokolojn) de dekoj da miloj da serviloj samtempe. En video de 40 minutoj . Baldaŭ ni afiŝos la transskribon sur Habr por la komforto labori kun la materialo.
Aplikoj
Post iom da tempo esplorante, mi pensas, ke ekzistas areoj kie ClickHouse povas esti utila aŭ kapabla tute anstataŭigi aliajn pli tradiciajn kaj popularajn solvojn kiel MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot kaj Druido. La jenaj estas la detaloj pri uzado de ClickHouse por ĝisdatigi aŭ tute anstataŭigi ĉi-supran DBMS.
Etendante MySQL kaj PostgreSQL
Plej lastatempe, ni parte anstataŭigis MySQL per ClickHouse por la informilo-platformo . La problemo estis, ke MySQL pro malbone konceptita dezajno ensalutis ĉiun retpoŝton senditan kaj ĉiun ligon en tiu retpoŝto kun base64 hash, kreante grandegan MySQL-tabelon (email_stats). Post sendi nur 10 milionojn da retpoŝtoj al la abonantoj de la servo, ĉi tiu tablo okupis 150 GB da dosierspaco, kaj MySQL komencis "stulta" pri simplaj demandoj. Por ripari la problemon de dosierspaco, ni sukcese uzis InnoDB-tabelkunpremadon, kiu reduktis ĝin je faktoro de 4. Tamen, ankoraŭ ne havas sencon stoki pli ol 20-30 milionojn da retpoŝtoj en MySQL nur por legi historion, ĉar ajna simpla demando, kiu ial devas fari plenan skanadon, rezultigas interŝanĝon kaj pezan I/O. supre, pri kiu ni regule ricevis Zabbix-avertojn.
Clickhouse uzas du kunpremajn algoritmojn, kiuj reduktas la kvanton de datumoj je proksimume , sed en ĉi tiu aparta kazo, la datumoj estis precipe "kunpremeblaj".
ELK Anstataŭaĵo
Surbaze de mia propra sperto, la ELK-stako (ElasticSearch, Logstash kaj Kibana, en ĉi tiu aparta kazo ElasticSearch) postulas multe pli da rimedoj por funkcii ol necesas por stoki protokolojn. ElasticSearch estas bonega motoro se vi volas bonan plentekstan protokolserĉon (kion mi ne pensas, ke vi vere bezonas), sed mi scivolas, kial ĝi fariĝis la fakta norma protokolo-motoro. Ĝia konsuma rendimento, kombinita kun Logstash, donis al ni problemojn eĉ ĉe sufiĉe malpezaj laborŝarĝoj kaj postulis la aldonon de pli kaj pli da RAM kaj diskspaco. Kiel datumbazo, Clickhouse estas pli bona ol ElasticSearch pro la sekvaj kialoj:
- SQL-dialekta subteno;
- La plej bona grado de kunpremo de stokitaj datumoj;
- Subteno por Regex-serĉo anstataŭ plenteksta serĉo;
- Plibonigita enketplanado kaj pli bona ĝenerala rendimento.
Nuntempe, la plej granda problemo, kiu aperas kiam oni komparas ClickHouse kun ELK, estas la manko de solvoj por alŝuti protokolojn, same kiel la manko de dokumentado kaj lerniloj pri ĉi tiu temo. Samtempe, ĉiu uzanto povas agordi ELK uzante la manlibron de Cifereca Oceano, kiu estas tre grava por la rapida efektivigo de tiaj teknologioj. Estas datumbaza motoro ĉi tie, sed ankoraŭ ne ekzistas Filebeat por ClickHouse. Jes ekzistas kaj sistemo por labori kun ŝtipoj , ekzistas ilo enigi protokoldosierajn datumojn en ClickHouse, sed ĉio ĉi prenas pli da tempo. Tamen, ClickHouse ankoraŭ kondukas la vojon pro sia simpleco, do eĉ komencantoj povas facile instali ĝin kaj komenci plene funkcian uzon en nur 10 minutoj.
Preferante minimumismajn solvojn, mi provis uzi FluentBit, tre malalta memorregistra alŝutilo, kun ClickHouse provante eviti uzi Kafka. Tamen, negravaj nekongruoj devas esti traktitaj, kiel ekzemple antaŭ ol ĝi povas esti farita sen la prokura tavolo, kiu konvertas datumojn de FluentBit al ClickHouse.
Kiel alternativo al Kibana, vi povas uzi ClickHouse kiel backend . Laŭ mia kompreno, ĉi tio povas kaŭzi rendimentajn problemojn dum prezentado de grandega nombro da datumpunktoj, precipe kun pli malnovaj versioj de Grafana. En Qwintry, ni ankoraŭ ne provis tion, sed plendoj pri tio aperas de tempo al tempo en la subtena kanalo de ClickHouse en Telegram.
Anstataŭigo de Google Big Query kaj Amazon RedShift (solvo por grandaj kompanioj)
La ideala uzkazo por BigQuery estas ŝargi 1TB da JSON-datumoj kaj ruli analizajn demandojn sur ĝi. Big Query estas bonega produkto, kies skaleblo estas malfacile supertaksi. Ĉi tio estas multe pli kompleksa programaro ol ClickHouse funkcianta sur interna areto, sed el la vidpunkto de la kliento, ĝi havas multon komunan kun ClickHouse. BigQuery povas rapide "altigi" post kiam vi komencas pagi por ĉiu SELECT, do ĝi estas vera SaaS-solvo kun ĉiuj ĝiaj avantaĝoj kaj malavantaĝoj.
ClickHouse estas la plej bona elekto kiam vi faras multajn komputile multekostajn demandojn. Ju pli da SELECT-demandoj vi rulas ĉiutage, des pli da celo estas anstataŭigi Big Query per ClickHouse, ĉar tia anstataŭaĵo ŝparos al vi milojn da dolaroj kiam temas pri multaj terabajtoj da datumoj prilaborataj. Ĉi tio ne validas por konservitaj datumoj, kiuj estas sufiĉe malmultekostaj por prilabori en Big Query.
En artikolo de Alexander Zaitsev, kunfondinto de Altinity priskribas la avantaĝojn de tia DBMS-migrado.
TimecaleDB Anstataŭigo
TimescaleDB estas PostgreSQL-etendo kiu optimumigas labori kun temposerio en regula datumbazo (, ).
Kvankam ClickHouse ne estas serioza konkuranto en la niĉo de temposerio, sed laŭ kolumna strukturo kaj vektora demanda ekzekuto, ĝi estas multe pli rapida ol TimescaleDB en la plej multaj kazoj de prilaborado de analizaj demandoj. Samtempe, la agado ricevi ClickHouse-pakaĵdatumojn estas ĉirkaŭ 3 fojojn pli alta, krome ĝi uzas 20 fojojn malpli da diskospaco, kio estas vere grava por prilaborado de grandaj volumoj de historiaj datumoj: .
Male al ClickHouse, la nura maniero ŝpari iom da diskospaco en TimescaleDB estas uzi ZFS aŭ similajn dosiersistemojn.
Venontaj ĝisdatigoj al ClickHouse verŝajne enkondukos deltan kunpremadon, kio faros ĝin eĉ pli taŭga por prilaborado kaj stokado de tempaj serioj. TimescaleDB povas esti pli bona elekto ol nuda ClickHouse en la sekvaj kazoj:
- malgrandaj instalaĵoj kun tre malmulte da RAM (<3 GB);
- granda nombro da malgrandaj INSERT, kiujn vi ne volas bufri en grandajn fragmentojn;
- pli bonaj postuloj de konsistenco, unuformeco kaj ACIDO;
- PostGIS-subteno;
- kunfandi kun ekzistantaj PostgreSQL-tabloj, ĉar Timescale DB estas esence PostgreSQL.
Konkurado kun Hadoop kaj MapReduce-sistemoj
Hadoop kaj aliaj MapReduce-produktoj povas fari multajn kompleksajn kalkulojn, sed ili emas funkcii kun grandega latenteco. ClickHouse riparas ĉi tiun problemon prilaborante terabajtojn da datumoj kaj produktante rezultojn preskaŭ tuj. Tiel, ClickHouse estas multe pli efika por fari rapidan, interagan analizan esploradon, kiu devus interesi datumajn sciencistojn.
Konkurado kun Pinot kaj Druido
La plej proksimaj konkurantoj de ClickHouse estas la kolonaj, linie skaleblaj malfermfontaj produktoj Pinot kaj Druid. Bonega laboro komparanta ĉi tiujn sistemojn estas publikigita en la artikolo 1-a de februaro 2018
Ĉi tiu artikolo devas esti ĝisdatigita - ĝi diras, ke ClickHouse ne subtenas operaciojn UPDATE kaj DELETE, kio ne estas tute vera rilate al la plej novaj versioj.
Ni ne havas multe da sperto pri ĉi tiuj DBMS-oj, sed mi ne ŝatas la kompleksecon de la subesta infrastrukturo, kiu estas bezonata por funkcii Druid kaj Pinot - ĝi estas tuta aro da "movaj partoj" ĉirkaŭitaj de Java de ĉiuj flankoj.
Druid kaj Pinot estas Apache-inkubatorprojektoj, kiuj estas detale kovritaj de Apache sur siaj GitHub-projektaj paĝoj. Pinot aperis en la inkubatoro en oktobro 2018, kaj Druido naskiĝis 8 monatojn pli frue - en februaro.
La manko de informoj pri kiel funkcias AFS starigas kelkajn, kaj eble stultajn, demandojn por mi. Mi scivolas, ĉu la aŭtoroj de Pinot rimarkis, ke la Apache-Fondaĵo estas pli disponita al Druido, kaj ĉu tia sinteno al konkuranto kaŭzis senton de envio? Ĉu la evoluo de Druido malrapidiĝos kaj la evoluo de Pinot akcelos, se la sponsoroj subtenantaj la unuan subite interesiĝos pri la dua?
Malavantaĝoj de ClickHouse
Nematureco: Evidente, ĉi tio ankoraŭ estas enuiga teknologio, sed ĉiukaze nenio tia vidiĝas en aliaj kolonaj DBMS.
Malgrandaj enigaĵoj ne funkcias bone ĉe alta rapideco: enigaĵoj devas esti dividitaj en grandajn pecojn ĉar la agado de malgrandaj enigaĵoj degradas proporcie al la nombro da kolumnoj en ĉiu vico. Jen kiel ClickHouse konservas datumojn sur disko - ĉiu kolumno signifas 1 dosieron aŭ pli, do por enmeti 1 vicon enhavantan 100 kolumnojn, vi devas malfermi kaj skribi almenaŭ 100 dosierojn. Tial enmeta bufrado postulas peranton (krom se la kliento mem disponigas bufradon) - kutime Kafka aŭ ia vicosistemo. Vi ankaŭ povas uzi la Buffer-tabelmotoron por poste kopii grandajn partojn da datumoj en MergeTree-tablojn.
Tablokuniĝoj estas limigitaj de servila RAM, sed almenaŭ ili estas tie! Ekzemple, Druid kaj Pinot tute ne havas tiajn ligojn, ĉar ili estas malfacile efektivigeblaj rekte en distribuitaj sistemoj, kiuj ne subtenas movi grandajn partojn de datumoj inter nodoj.
trovoj
En la venontaj jaroj, ni planas vaste uzi ClickHouse en Qwintry, ĉar ĉi tiu DBMS provizas bonegan ekvilibron de rendimento, malalta superkompeco, skaleblo kaj simpleco. Mi estas sufiĉe certa, ke ĝi rapide disvastiĝos post kiam la ClickHouse-komunumo venos kun pli da manieroj uzi ĝin en malgrandaj kaj mezaj instalaĵoj.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com