mangrupikeun sistem manajemén database kolom open-source pikeun pamrosésan query analitik online (OLAP) anu diciptakeun ku Yandex. Hal ieu dipaké ku Yandex, CloudFlare, VK.com, Badoo sarta jasa lianna di sakuliah dunya pikeun nyimpen jumlah bener badag data (sisipan rébuan baris per detik atawa petabytes data disimpen dina disk).
Dina normal, "string" DBMS, contona MySQL, Postgres, MS SQL Server, data disimpen dina urutan ieu:
Dina hal ieu, nilai-nilai anu aya hubunganana sareng hiji baris disimpen sacara fisik sisi-sisi. Dina kolom DBMS, nilai tina kolom anu béda disimpen sacara misah, sareng data tina hiji kolom disimpen babarengan:
Conto kolom DBMS nyaéta Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Pausahaan téh forwarder mail Kuring mimiti nganggo Clickhouse di 2018 pikeun ngalaporkeun sareng kagum pisan ku kesederhanaan, skalabilitas, dukungan SQL, sareng kacepetan. Laju DBMS ieu wates jeung magic.
katentreman
Clickhouse dipasang dina Ubuntu kalayan hiji paréntah. Upami anjeun terang SQL, anjeun tiasa langsung nganggo Clickhouse pikeun kabutuhan anjeun. Nanging, ieu sanés hartosna anjeun tiasa "nunjukkeun nyiptakeun méja" dina MySQL sareng nyalin-témpél SQL di Clickhouse.
Dibandingkeun sareng MySQL, aya bédana jinis data anu penting dina definisi skéma tabel dina DBMS ieu, ku kituna anjeun masih peryogi sababaraha waktos pikeun ngarobih definisi skéma tabel sareng diajar mesin méja supados langkung nyaman.
Clickhouse tiasa dianggo saé tanpa parangkat lunak tambahan, tapi upami anjeun hoyong nganggo réplikasi anjeun kedah pasang ZooKeeper. Analisis kinerja query nembongkeun hasil alus teuing - tabel sistem ngandung sakabéh informasi, sarta sakabeh data bisa didapet maké SQL heubeul jeung boring.
kakuwatan keur ngasilkeun
- Clickhouse versus Vertica jeung MySQL ngabandingkeun dina server konfigurasi: dua sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 dina 8 6TB SATA HDD, ext4.
- ngabandingkeun tina Clickhouse kalawan gudang awan Amazon RedShift.
- Blog cutatan :
Database ClickHouse gaduh desain anu saderhana pisan - sadaya titik dina kluster gaduh fungsi anu sami sareng ngan ukur nganggo ZooKeeper pikeun koordinasi. Kami ngawangun klaster leutik tina sababaraha titik sareng ngalaksanakeun tés, dimana kami mendakan yén sistemna ngagaduhan prestasi anu lumayan, anu cocog sareng kaunggulan anu diklaim dina tolok ukur DBMS analitik. Urang mutuskeun nyandak katingal ngadeukeutan dina konsép balik ClickHouse. Halangan munggaran pikeun panalungtikan nyaéta kurangna alat sareng komunitas leutik ClickHouse, ku kituna urang ngagali kana desain DBMS ieu pikeun ngartos kumaha jalanna.
ClickHouse henteu ngadukung nampi data langsung ti Kafka, sabab éta ngan ukur database, janten kami nyerat jasa adaptor kami sorangan di Go. Éta maca pesen anu disandikeun Cap'n Proto ti Kafka, dirobih janten TSV, sareng diselapkeun kana ClickHouse dina bets ngalangkungan antarmuka HTTP. Urang engké rewrote jasa ieu ngagunakeun perpustakaan Go ditéang jeung panganteur ClickHouse urang sorangan pikeun ngaronjatkeun kinerja. Nalika ngevaluasi kinerja nampi pakét, urang mendakan hiji hal anu penting - tétéla yén pikeun ClickHouse kinerja ieu gumantung pisan kana ukuran pakét, nyaéta, jumlah barisan anu diselapkeun dina waktos anu sami. Pikeun ngartos naha ieu kajadian, urang diajar kumaha ClickHouse nyimpen data.
Mesin utama, atawa rada, kulawarga mesin tabel dipaké ku ClickHouse pikeun nyimpen data, nyaeta MergeTree. mesin Ieu conceptually sarupa algoritma LSM dipaké dina Google BigTable atanapi Apache Cassandra, tapi avoids ngawangun hiji méja memori panengah jeung nulis data langsung ka disk. Ieu masihan throughput nyerat anu saé, sabab unggal pakét anu diselapkeun ngan ukur diurutkeun ku konci primér "konci primér", dikomprés, sareng ditulis kana disk pikeun ngabentuk bagéan.
Henteuna tabel memori atanapi konsép "freshness" data ogé ngandung harti yén maranéhna ngan bisa ditambahkeun, sistem teu ngarojong ngarobah atawa mupus. Nepi ka ayeuna, hiji-hijina jalan pikeun mupus data nyaéta mupusna ku bulan kalénder, sabab bagéan henteu pernah meuntas wates sabulan. Tim ClickHouse aktip ngusahakeun ngajantenkeun fitur ieu tiasa disaluyukeun. Di sisi séjén, éta ngajadikeun tulisan jeung merging bagéan contention-gratis, jadi narima skala throughput linier kalawan jumlah inserts paralel nepi ka I/O atawa cores jenuh.
Nanging, kaayaan ieu ogé hartosna yén sistem éta henteu cocog pikeun pakét leutik, janten jasa Kafka sareng sisipan dianggo pikeun panyangga. Salajengna, ClickHouse di tukang terus terus ngahijikeun bagéan, ku kituna loba potongan leutik inpormasi bakal digabungkeun jeung dirékam leuwih kali, sahingga ngaronjatkeun inténsitas rekaman. Sanajan kitu, loba teuing bagian nu teu patali bakal ngabalukarkeun throttling agrésif of inserts salami ngahiji terus. Kami geus manggihan yén kompromi pangalusna antara ingestion data real-time jeung kinerja ingestion nyaéta nampa jumlah kawates inserts per detik kana tabél.
Konci pikeun kinerja bacaan tabel nyaéta indexing sareng lokasi data dina disk. Perkara teu sabaraha gancang ngolah éta, nalika mesin kudu nyeken terabytes data tina disk jeung ngan ngagunakeun fraksi eta, éta bakal butuh waktu. ClickHouse mangrupikeun toko kolom, janten unggal ruas ngandung file pikeun tiap kolom (kolom) kalayan nilai anu diurutkeun pikeun unggal baris. Ku kituna, sakabéh kolom teu hadir dina pamundut mimiti bisa skipped, lajeng sababaraha sél bisa diolah dina paralel jeung palaksanaan vectorized. Pikeun ngahindarkeun scan lengkep, unggal bagean gaduh file indéks leutik.
Nunjukkeun yen sakabeh kolom diurutkeun ku "konci primér", file indéks ngan ngandung labél (baris direbut) unggal baris Nth, guna bisa tetep dina mémori malah keur tabel kacida gedéna. Salaku conto, anjeun tiasa nyetél setélan standar pikeun "nyirian unggal baris ka-8192", teras indéks "meager" tina méja kalayan 1 triliun. garis nu fits gampang kana memori ngan bakal nyandak 122 karakter.
Pangwangunan sistem
Ngembangkeun sareng ningkatkeun Clickhouse tiasa dilacak sarta pastikeun yén prosés "tumuwuh nepi" lumangsung dina hiji Pace impressive.
popularitas
Sigana popularitas Clickhouse naék sacara éksponénsial, khususna dina komunitas anu nyarios Rusia. Konperénsi High load 2018 taun ka tukang (Moscow, 8-9 Nopember 2018) nunjukkeun yén monster sapertos vk.com sareng Badoo nganggo Clickhouse, anu nyelapkeun data (contona, log) tina puluhan rébu server sakaligus. Dina video 40 menit . Moal lami deui urang bakal masangkeun transkrip dina Habr pikeun genah gawé bareng bahan.
aplikasi
Saatos nyéépkeun waktos naliti, kuring nyangka aya daérah dimana ClickHouse tiasa mangpaat atanapi tiasa ngagentos lengkep solusi anu langkung tradisional sareng populér sapertos MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot sareng Druid. Ieu mangrupikeun detil ngeunaan ngagunakeun ClickHouse pikeun ningkatkeun atanapi ngagentos lengkep DBMS di luhur.
Ngalegaan MySQL sareng PostgreSQL
Nu panganyarna, urang sawaréh ngaganti MySQL jeung ClickHouse pikeun platform newsletter . Masalahna nya éta MySQL alatan desain gering-katimu asup unggal email dikirim jeung unggal link di email nu ku base64 hash, nyieun tabel MySQL badag (email_stats). Saatos ngirim ukur 10 juta surelek ka palanggan jasa, tabel ieu nempatan 150 GB spasi file, sarta MySQL mimiti "bodoh" dina queries basajan. Pikeun ngalereskeun masalah rohangan file, kami suksés ngagunakeun komprési tabel InnoDB, anu ngirangan ku faktor 4. Sanajan kitu, éta masih teu make akal pikiran pikeun nyimpen leuwih ti 20-30 juta surelek dina MySQL ngan pikeun kapentingan maca sajarah, sakumaha query basajan nu pikeun sababaraha alesan kudu ngalakukeun scan pinuh hasil swap jeung beurat I / O. overhead, ngeunaan nu urang rutin narima warnings Zabbix.
Clickhouse ngagunakeun dua algoritma komprési nu ngurangan jumlah data ku ngeunaan , Tapi dina hal husus ieu, data ieu utamana "compressible".
Ngaganti ELK
Dumasar pangalaman kuring sorangan, tumpukan ELK (ElasticSearch, Logstash sareng Kibana, dina hal ieu ElasticSearch) ngabutuhkeun langkung seueur sumber pikeun ngajalankeun tibatan anu diperyogikeun pikeun nyimpen log. ElasticSearch mangrupikeun mesin anu saé upami anjeun hoyong milarian log téks lengkep anu saé (sareng kuring henteu nyangka anjeun peryogi pisan), tapi kuring heran naha éta parantos janten mesin logging standar de facto. Kinerja ingestion na, digabungkeun sareng Logstash, masihan kami masalah sanajan dina beban kerja anu cukup hampang sareng peryogi tambihan langkung seueur RAM sareng rohangan disk. Salaku pangkalan data, Clickhouse langkung saé tibatan ElasticSearch kusabab alesan ieu:
- Pangrojong dialék SQL;
- Tingkat komprési pangsaéna tina data anu disimpen;
- Rojongan pikeun milarian Regex tinimbang milarian téks lengkep;
- Ngaronjatkeun scheduling query jeung kinerja sakabéh hadé.
Ayeuna, masalah pangbadagna anu timbul nalika ngabandingkeun ClickHouse sareng ELK nyaéta kurangna solusi pikeun unggah log, ogé kurangna dokuméntasi sareng tutorial ngeunaan topik ieu. Dina waktos anu sami, unggal pangguna tiasa nyetél ELK nganggo manual Samudra Digital, anu penting pisan pikeun palaksanaan gancang téknologi sapertos kitu. Aya mesin database di dieu, tapi teu acan aya Filebeat pikeun ClickHouse. Sumuhun, aya jeung sistem pikeun gawé bareng log , aya alatna pikeun ngasupkeun data file log kana ClickHouse, tapi kabeh ieu butuh leuwih waktos. Sanajan kitu, ClickHouse masih ngabalukarkeun jalan alatan kesederhanaan na, jadi malah beginners bisa kalayan gampang install deui tur mimitian pamakéan pinuh fungsi dina ngan 10 menit.
Preferring solusi minimalis, abdi diusahakeun make FluentBit, a memori pisan low alat unggah log, kalawan ClickHouse, bari nyobian ulah ngagunakeun Kafka. Sanajan kitu, incompatibilities minor perlu kajawab, kayaning sateuacan éta tiasa dilakukeun tanpa lapisan proxy anu ngarobih data tina FluentBit ka ClickHouse.
Salaku alternatif pikeun Kibana, anjeun tiasa nganggo ClickHouse salaku backend . Sajauh anu kuring ngartos, ieu tiasa nyababkeun masalah kinerja nalika masihan sajumlah titik data, khususna sareng versi Grafana anu langkung lami. Dina Qwintry, kami henteu acan nyobian ieu, tapi keluhan ngeunaan ieu muncul ti waktos ka waktos dina saluran dukungan ClickHouse di Telegram.
Ngagantian Google Big Query sareng Amazon RedShift (solusi pikeun perusahaan ageung)
Kasus panggunaan idéal pikeun BigQuery nyaéta ngamuat 1TB data JSON sareng ngajalankeun patarosan analitik dina éta. Big Query mangrupikeun produk anu hébat anu skalabilitasna hésé diéstimasikeun. Ieu mangrupikeun parangkat lunak anu langkung rumit tibatan ClickHouse anu dijalankeun dina kluster internal, tapi tina sudut pandang klien, éta ngagaduhan seueur anu umum sareng ClickHouse. BigQuery tiasa gancang "naékkeun harga" saatos anjeun mimiti mayar unggal PILIH, janten éta mangrupikeun solusi SaaS nyata kalayan sagala pro sareng kontra.
ClickHouse mangrupikeun pilihan anu pangsaéna nalika anjeun ngajalankeun seueur patarosan komputasi anu mahal. Langkung seueur patarosan PILIH anu anjeun jalankeun unggal dinten, langkung seueur titik pikeun ngagentos Big Query sareng ClickHouse, sabab panggantian sapertos kitu bakal nyalametkeun anjeun rébuan dolar nalika datang ka seueur terabytes data anu diolah. Ieu henteu lumaku pikeun data nu disimpen, nu rada mirah pikeun ngolah dina Big Query.
Dina artikel ku Alexander Zaitsev, ko-pangadeg Altinity ngajelaskeun mangpaat migrasi DBMS sapertos kitu.
Ngagantian TimescaleDB
TimescaleDB mangrupikeun ekstensi PostgreSQL anu ngaoptimalkeun damel sareng timeseries dina database biasa (, ).
Sanajan ClickHouse sanes pesaing serius dina ceruk runtuyan waktu, tapi tina segi struktur columnar jeung palaksanaan query vektor, éta leuwih gancang ti TimescaleDB di hal nu ilahar ngolah queries analitik. Dina waktos anu sami, kinerja nampi data pakét ClickHouse sakitar 3 kali langkung luhur, salian ti éta, ngagunakeun rohangan disk 20 kali kirang, anu penting pisan pikeun ngolah data sajarah anu ageung: .
Beda sareng ClickHouse, hiji-hijina jalan pikeun ngahémat sababaraha rohangan disk dina TimescaleDB nyaéta ngagunakeun ZFS atanapi sistem file anu sami.
Pembaruan anu bakal datang ka ClickHouse sigana bakal ngenalkeun komprési délta, anu bakal ngajantenkeun langkung cocog pikeun ngolah sareng nyimpen data séri waktos. TimescaleDB tiasa janten pilihan anu langkung saé tibatan ClickHouse bulistir dina kasus ieu:
- pamasangan leutik kalawan saeutik pisan RAM (<3 GB);
- sajumlah ageung INSERT leutik anu anjeun henteu hoyong panyangga kana fragmen ageung;
- konsistensi hadé, uniformity jeung syarat asam;
- rojongan PostGIS;
- ngagabung jeung tabel PostgreSQL aya, saprak Timescale DB dasarna PostgreSQL.
Kompetisi sareng sistem Hadoop sareng MapReduce
Hadoop jeung produk MapReduce lianna bisa ngalakukeun loba itungan kompléks, tapi aranjeunna condong ngajalankeun dina latency badag ClickHouse ngalereskeun masalah ieu ku ngolah terabytes data sarta ngahasilkeun hasil ampir instan. Ku kituna, ClickHouse jauh leuwih efisien keur ngajalankeun gancang, panalungtikan analitik interaktif, nu kedah dipikaresep ku élmuwan data.
Kompetisi sareng Pinot sareng Druid
pesaing pangdeukeutna ClickHouse urang anu columnar, linier scalable produk open source Pinot na Druid. Proyék anu saé pikeun ngabandingkeun sistem ieu diterbitkeun dina tulisan 1 Pébruari 2018
Artikel ieu perlu diropéa - eta nyebutkeun yen ClickHouse teu ngarojong operasi UPDATE na DELETE, nu teu sagemblengna bener dina hubungan jeung versi panganyarna.
Kami henteu gaduh seueur pangalaman sareng DBMS ieu, tapi kuring henteu resep pajeulitna infrastruktur dasar anu diperyogikeun pikeun ngajalankeun Druid sareng Pinot - éta sakumpulan "bagian anu gerak" dikurilingan ku Java tina sagala sisi.
Druid sareng Pinot mangrupikeun proyék inkubator Apache, anu katutupan sacara rinci ku Apache dina halaman proyék GitHub na. Pinot muncul dina inkubator dina Oktober 2018, sareng Druid lahir 8 bulan sateuacanna - dina bulan Pebruari.
Kurangna informasi ngeunaan kumaha AFS jalan raises sababaraha, jeung sugan bodo, patarosan pikeun kuring. Kuring heran naha pangarang Pinot perhatikeun yén Yayasan Apache langkung condong ka Druid, sareng naha sikep sapertos kitu ka pesaing nyababkeun rasa dengki? Bakal ngembangkeun Druid ngalambatkeun turun sarta ngembangkeun Pinot ngagancangkeun lamun sponsor ngarojong urut dumadakan jadi kabetot dina dimungkinkeun?
Kakurangan ClickHouse
Immaturity: Jelas, ieu téh masih téhnologi boring, tapi dina sagala hal, nanaon kawas ieu katempo dina DBMS columnar séjén.
Inserts leutik teu nedunan alus dina speed tinggi: inserts kudu dibeulah jadi sakumpulan badag sabab kinerja inserts leutik degrades saimbang jeung jumlah kolom dina unggal baris. Ieu kumaha ClickHouse nyimpen data dina disk - unggal kolom hartina 1 file atawa leuwih, jadi mun nyelapkeun 1 baris ngandung 100 kolom, Anjeun kudu muka jeung nulis sahenteuna 100 file. Ieu naha sisipan buffering merlukeun perantara (iwal klien sorangan nyadiakeun buffering) - biasana Kafka atawa sababaraha jenis sistem antrian. Anjeun oge bisa make mesin tabel panyangga pikeun engké nyalin sakumpulan badag data kana tabel MergeTree.
Méja gabung diwatesan ku RAM server, tapi sahenteuna aranjeunna aya! Salaku conto, Druid sareng Pinot henteu gaduh sambungan sapertos kitu, sabab hese dilaksanakeun langsung dina sistem anu disebarkeun anu henteu ngadukung mindahkeun sakumpulan data anu ageung antara titik.
papanggihan
Dina taun-taun anu bakal datang, urang ngarencanakeun ngagunakeun ClickHouse sacara éksténsif di Qwintry, sabab DBMS ieu nyayogikeun kasaimbangan kinerja anu saé, overhead rendah, skalabilitas, sareng kesederhanaan. Abdi geulis yakin eta bakal nyebarkeun gancang sakali komunitas ClickHouse datang nepi ka leuwih cara ngagunakeun eta dina pamasangan leutik sarta sedeng.
Sababaraha iklan 🙂
Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, , analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).
Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan
sumber: www.habr.com