minangka sistem manajemen basis data kolom sumber terbuka kanggo pangolahan pitakon analitik online (OLAP), digawe dening Yandex. Iki digunakake dening Yandex, CloudFlare, VK.com, Badoo lan layanan liyane ing saindenging jagad kanggo nyimpen data sing akeh banget (nglebokake ewu baris per detik utawa petabyte data sing disimpen ing disk).
Ing DBMS biasa, "string", contone yaiku MySQL, Postgres, MS SQL Server, data disimpen ing urutan ing ngisor iki:
Ing kasus iki, nilai sing ana gandhengane karo siji baris disimpen sacara fisik ing cedhak. Ing DBMS kolom, nilai saka kolom sing beda-beda disimpen kanthi kapisah, lan data saka siji kolom disimpen bebarengan:
Conto DBMS kolom yaiku Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Perusahaan pangirim surat wiwit nggunakake Clickhouse ing 2018 kanggo nglaporake lan kesengsem banget karo kesederhanaan, skalabilitas, dhukungan lan kacepetan SQL. Kacepetan DBMS iki wewatesan karo sihir.
ease
Clickhouse diinstal ing Ubuntu kanthi siji prentah. Yen sampeyan ngerti SQL, sampeyan bisa langsung miwiti nggunakake Clickhouse kanggo kabutuhan. Nanging, iki ora ateges sampeyan bisa nindakake "show nggawe tabel" ing MySQL lan nyalin-tempel SQL ing Clickhouse.
Dibandhingake karo MySQL, ana beda jinis data sing penting ing definisi skema tabel, mula sampeyan isih butuh sawetara wektu kanggo ngganti definisi skema tabel lan sinau mesin meja supaya kepenak.
Clickhouse bisa digunakake tanpa piranti lunak tambahan, nanging yen sampeyan pengin nggunakake replikasi, sampeyan kudu nginstal ZooKeeper. Analisis kinerja Query nuduhake asil banget - tabel sistem ngemot kabeh informasi, lan kabeh data bisa dijupuk nggunakake SQL lawas lan mboseni.
Produktivitas
- mbandhingaké Clickhouse karo Vertica lan MySQL ing konfigurasi server: loro sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 ing 8 6TB SATA HDD, ext4.
- comparison of Clickhouse karo panyimpenan maya Amazon RedShift.
- Blog kutipan :
Database ClickHouse nduweni desain sing prasaja banget - kabeh simpul ing kluster nduweni fungsi sing padha lan mung nggunakake ZooKeeper kanggo koordinasi. Kita mbangun kluster cilik saka sawetara kelenjar lan nganakake tes, sajrone kita nemokake manawa sistem kasebut nduweni kinerja sing cukup nyengsemaken, sing cocog karo kaluwihan kasebut ing benchmark DBMS analitis. Kita mutusake kanggo nliti konsep ing mburi ClickHouse. Rintangan pisanan kanggo riset yaiku kekurangan alat lan komunitas ClickHouse cilik, mula kita nyelidiki desain DBMS iki kanggo ngerti cara kerjane.
ClickHouse ora ndhukung nampa data langsung saka Kafka amarga mung database, mula kita nulis layanan adaptor dhewe ing Go. Iki maca pesen sing dienkode Cap'n Proto saka Kafka, diowahi dadi TSV lan dilebokake menyang ClickHouse kanthi batch liwat antarmuka HTTP. We mengko rewrote layanan iki kanggo nggunakake perpustakaan Go magepokan karo antarmuka ClickHouse dhewe kanggo nambah kinerja. Nalika ngevaluasi kinerja nampa paket, kita nemokake sing penting - ternyata kanggo ClickHouse kinerja iki gumantung banget karo ukuran paket, yaiku, jumlah baris sing dipasang bebarengan. Kanggo mangerteni kenapa iki kedadeyan, kita ndeleng carane ClickHouse nyimpen data.
Mesin utama, utawa kulawarga mesin meja, digunakake dening ClickHouse kanggo nyimpen data yaiku MergeTree. Mesin iki sacara konsep padha karo algoritma LSM sing digunakake ing Google BigTable utawa Apache Cassandra, nanging ngindhari nggawe tabel memori penengah lan nulis data langsung menyang disk. Iki menehi throughput nulis sing apik banget, amarga saben paket sing dilebokake mung diurutake miturut kunci utama, dikompres, lan ditulis menyang disk kanggo mbentuk bagean.
Ora ana tabel memori utawa konsep "kesegaran" data uga tegese mung bisa ditambah; sistem ora ndhukung ngganti utawa mbusak. Saiki, siji-sijine cara kanggo mbusak data yaiku mbusak data kasebut miturut sasi tanggalan, amarga segmen ora tau ngliwati wates sasi. Tim ClickHouse aktif nggarap fitur iki supaya bisa disesuaikan. Ing sisih liya, nggawe bagean nulis lan gabung bebas kontroversi, mula nampa skala throughput kanthi linear kanthi jumlah sisipan bebarengan nganti I / O utawa jenuh inti dumadi.
Nanging, iki uga tegese sistem kasebut ora cocog kanggo paket cilik, mula layanan lan sisipan Kafka digunakake kanggo buffering. Sabanjure, ClickHouse ing latar mburi terus nindakake panggabungan segmen, supaya akeh informasi cilik bakal digabungake lan direkam luwih akeh, saéngga nambah intensitas rekaman. Nanging, akeh banget bagean sing ora nyambung bakal nyebabake throttling agresif saka sisipan anggere gabungan terus. Kita wis nemokake manawa kompromi paling apik ing antarane ingestion wektu nyata lan kinerja ingestion yaiku nglebokake sawetara sisipan per detik menyang meja.
Tombol kanggo kinerja maca tabel yaiku indeksasi lan lokasi data ing disk. Ora ketompo carane cepet Processing punika, nalika mesin kudu mindai terabyte data saka disk lan mung nggunakake bagean saka iku, iku bakal njupuk wektu. ClickHouse minangka toko kolom, saengga saben bagean ngemot file kanggo saben kolom (kolom) kanthi nilai sing diurutake kanggo saben baris. Kanthi cara iki, kabeh kolom sing ilang saka pitakonan bisa dilewati dhisik, banjur sawetara sel bisa diproses kanthi podo karo eksekusi vektor. Kanggo ngindhari scan lengkap, saben bagean duwe file indeks cilik.
Amarga kabeh kolom diurutake kanthi "kunci utama", file indeks mung ngemot label (larik sing dijupuk) saben baris N supaya bisa disimpen ing memori sanajan tabel sing gedhe banget. Contone, sampeyan bisa nyetel setelan gawan kanggo "tandhani saben baris 8192nd", banjur indeksasi "meager" saka tabel kanthi 1 triliun. garis sing pas karo memori bakal njupuk mung 122 karakter.
Pangembangan sistem
Pangembangan lan perbaikan Clickhouse bisa dilacak ing lan priksa manawa proses "tuwuh" dumadi kanthi cepet.
Popularitas
Popularitas Clickhouse katon akeh banget, utamane ing komunitas sing nganggo basa Rusia. Konferensi High load 2018 pungkasan taun (Moscow, 8-9 November 2018) nuduhake manawa monsters kayata vk.com lan Badoo nggunakake Clickhouse, sing nglebokake data (contone, log) saka puluhan ewu server bebarengan. Ing video 40 menit . Ora suwe, kita bakal ngirim transkrip ing Habr supaya gampang nggarap materi kasebut.
Aplikasi
Sawise mbuwang sawetara wektu kanggo riset, aku mikir ana wilayah ing ngendi ClickHouse bisa migunani utawa bisa ngganti solusi liyane, luwih tradisional lan populer kayata MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot lan Druid. Ing ngisor iki njlèntrèhaké rincian nggunakake ClickHouse kanggo modernize utawa rampung ngganti DBMS ndhuwur.
Ngluwihi kapabilitas MySQL lan PostgreSQL
Mung bubar kita sebagian ngganti MySQL karo ClickHouse kanggo platform newsletter kita . Masalahe yaiku MySQL, amarga desain sing ora apik, nyathet saben email sing dikirim lan saben link ing email kasebut kanthi hash base64, nggawe tabel MySQL sing gedhe (email_stats). Sawise ngirim mung 10 yuta email menyang pelanggan layanan, tabel iki manggoni 150 GB ruang file, lan MySQL wiwit "bodho" ing pitakonan prasaja. Kanggo ndandani masalah ruang file, kita kasil nggunakake kompresi tabel InnoDB sing nyuda kanthi faktor 4. Nanging, isih ora ana gunane kanggo nyimpen luwih saka 20-30 yuta email ing MySQL mung kanggo maca riwayat, amarga pitakon prasaja sing sakperangan alesan kudu nindakake scan lengkap asil swap lan akeh aku. / O mbukak, miturut bab kang kita ajeg nampa bebaya saka Zabbix.
Clickhouse nggunakake rong algoritma kompresi sing nyuda volume data kira-kira , nanging ing kasus tartamtu iki data utamané "compressible".
Ngganti ELK
Adhedhasar pengalamanku dhewe, tumpukan ELK (ElasticSearch, Logstash lan Kibana, ing kasus iki ElasticSearch) mbutuhake sumber daya luwih akeh tinimbang sing dibutuhake kanggo nyimpen log. ElasticSearch minangka mesin sing apik yen sampeyan butuh telusuran log teks lengkap sing apik (sing dakkira sampeyan pancene butuh), nanging aku mikir kenapa wis dadi mesin logging standar de facto. Kinerja ingest sing digabungake karo Logstash menehi masalah sanajan ing beban sing cukup entheng lan mbutuhake kita nambah RAM lan papan disk liyane. Minangka basis data, Clickhouse luwih apik tinimbang ElasticSearch amarga alasan ing ngisor iki:
- Dhukungan dialek SQL;
- Tingkat kompresi paling apik saka data sing disimpen;
- Dhukungan kanggo telusuran ekspresi reguler Regex tinimbang telusuran teks lengkap;
- Penjadwalan pitakon sing luwih apik lan kinerja sakabèhé sing luwih dhuwur.
Saiki, masalah paling gedhe sing muncul nalika mbandhingake ClickHouse karo ELK yaiku kekurangan solusi kanggo ngunggah log, uga kekurangan dokumentasi lan tutorial babagan topik kasebut. Kajaba iku, saben pangguna bisa ngatur ELK nggunakake manual Digital Ocean, sing penting banget kanggo implementasine teknologi kasebut kanthi cepet. Ana mesin database, nanging durung ana Filebeat kanggo ClickHouse. Ya wis ana lan sistem kanggo nggarap log , ana alat kanggo ngetik data file log menyang ClickHouse, nanging kabeh iki mbutuhake wektu luwih akeh. Nanging, ClickHouse isih dadi pimpinan amarga kesederhanaan, saengga para pamula bisa kanthi gampang nginstal lan miwiti nggunakake kanthi fungsional sajrone 10 menit.
Luwih milih solusi minimalis, aku nyoba nggunakake FluentBit, alat kanggo ngirim log kanthi memori sing sithik banget, bebarengan karo ClickHouse, nalika nyoba supaya ora nggunakake Kafka. Nanging, incompatibilities cilik kudu ditangani, kayata sadurunge iki bisa ditindakake tanpa lapisan proxy sing ngowahi data saka FluentBit menyang ClickHouse.
Minangka alternatif, Kibana bisa digunakake minangka backend ClickHouse . Saka apa aku ngerti, iki bisa nimbulaké masalah kinerja nalika Rendering nomer ageng titik data, utamané karo versi lawas saka Grafana. Kita durung nyoba iki ing Qwintry, nanging keluhan babagan iki katon saka wektu kanggo saluran dhukungan ClickHouse ing Telegram.
Ganti Google Big Query lan Amazon RedShift (solusi kanggo perusahaan gedhe)
Kasus panggunaan sing cocog kanggo BigQuery yaiku ngemot 1 TB data JSON lan mbukak pitakon analitis. Big Query minangka produk sing apik banget sing skalabilitas ora bisa diremehake. Iki minangka piranti lunak sing luwih rumit tinimbang ClickHouse, sing mlaku ing kluster internal, nanging saka sudut pandang klien, akeh sing padha karo ClickHouse. BigQuery bisa larang kanthi cepet yen sampeyan miwiti mbayar saben SELECT, dadi solusi SaaS sing bener karo kabeh pro lan kontra.
ClickHouse minangka pilihan sing paling apik nalika sampeyan mbukak akeh pitakon sing larang kanthi komputasi. Luwih akeh pitakon PILIH sing sampeyan lakoni saben dina, luwih becik ngganti Big Query karo ClickHouse, amarga panggantos kasebut bisa ngirit ewonan dolar nalika nerangake akeh terabyte data sing diproses. Iki ora ditrapake kanggo data sing disimpen, sing cukup murah kanggo diproses ing Big Query.
Ing artikel dening Altinity co-founder Alexander Zaitsev ngomong babagan keuntungan saka migrasi DBMS kasebut.
Panggantos TimescaleDB
TimescaleDB minangka ekstensi PostgreSQL sing ngoptimalake nggarap seri wektu seri ing basis data biasa (, ).
Senajan ClickHouse ora pesaing serius ing niche saka seri wektu, nanging struktur kolom lan eksekusi query vektor, iku luwih cepet tinimbang TimescaleDB ing paling kasus pangolahan pitakonan analitis. Ing wektu sing padha, kinerja nampa data batch saka ClickHouse kira-kira 3 kaping luwih dhuwur, lan uga nggunakake 20 kaping kurang spasi disk, kang pancene penting kanggo ngolah volume gedhe saka data sajarah: .
Ora kaya ClickHouse, siji-sijine cara kanggo ngirit ruang disk ing TimescaleDB yaiku nggunakake ZFS utawa sistem file sing padha.
Nganyari mbesuk kanggo ClickHouse kemungkinan bakal ngenalake kompresi delta, sing bakal nggawe luwih cocog kanggo ngolah lan nyimpen data seri wektu. TimescaleDB bisa dadi pilihan sing luwih apik tinimbang ClickHouse ing kasus ing ngisor iki:
- panginstalan cilik karo RAM sethitik banget (<3 GB);
- nomer akeh INSERT cilik sing sampeyan ora pengin buffer menyang pecahan gedhe;
- konsistensi sing luwih apik, seragam lan syarat ACID;
- Dhukungan PostGIS;
- gabung karo tabel PostgreSQL sing ana, amarga Timescale DB sejatine PostgreSQL.
Kompetisi karo sistem Hadoop lan MapReduce
Hadoop lan produk MapReduce liyane bisa nindakake akeh kalkulasi sing rumit, nanging cenderung mlaku kanthi latensi gedhe. ClickHouse ndandani masalah iki kanthi ngolah terabyte data lan ngasilake asil meh langsung. Mangkono, ClickHouse luwih efektif kanggo nindakake riset analitis interaktif kanthi cepet, sing kudu dadi kapentingan kanggo para ilmuwan data.
Kompetisi karo Pinot lan Druid
Saingan paling cedhak ClickHouse yaiku produk open source kolumnar, skala linear, Pinot lan Druid. Karya sing apik banget kanggo mbandhingake sistem kasebut diterbitake ing artikel kasebut 1 Februari 2018
Artikel iki perlu nganyari - ujar manawa ClickHouse ora ndhukung operasi UPDATE lan DELETE, sing ora bener kanggo versi paling anyar.
Kita ora duwe pengalaman akeh karo database kasebut, nanging aku ora seneng karo kerumitan infrastruktur sing dibutuhake kanggo nglakokake Druid lan Pinot - iku kabeh bagean obah sing diubengi dening Jawa ing kabeh sisih.
Druid lan Pinot minangka proyek inkubator Apache, sing kemajuane dibahas kanthi rinci dening Apache ing kaca proyek GitHub. Pinot muncul ing inkubator ing Oktober 2018, lan Druid lair 8 wulan sadurunge - ing wulan Februari.
Kurang informasi babagan cara kerja AFS nyebabake sawetara, lan mbok menawa bodho, pitakonan kanggo aku. Aku kepengin weruh yen penulis Pinot ngerteni manawa Yayasan Apache luwih seneng karo Druid, lan apa sikap iki marang pesaing kasebut nyebabake rasa iri? Apa pangembangan Druid bakal saya suwe lan pangembangan Pinot bakal luwih cepet yen para pendukung mantan tiba-tiba dadi tertarik karo sing terakhir?
Kekurangan ClickHouse
Immaturity: Temenan, iki isih dudu teknologi sing mboseni, nanging ing kasus apa wae, ora ana sing katon ing DBMS kolumnar liyane.
Sisipan cilik ora nindakake kanthi apik ing kacepetan dhuwur: sisipan kudu dipérang dadi potongan sing luwih gedhe amarga kinerja sisipan cilik mudhun kanthi proporsi karo jumlah kolom ing saben baris. Iki carane ClickHouse nyimpen data ing disk - saben kolom makili 1 file utawa luwih, supaya kanggo masang 1 baris ngemot 100 kolom, sampeyan kudu mbukak lan nulis paling 100 file. Iki kok sisipan buffering mbutuhake middleman (kajaba klien dhewe menehi buffering) - biasane Kafka utawa sawetara jenis sistem manajemen antrian. Sampeyan uga bisa nggunakake mesin Tabel Buffer kanggo mengko nyalin potongan gedhe saka data menyang tabel MergeTree.
Tabel nggabung diwatesi dening RAM server, nanging paling padha ana! Contone, Druid lan Pinot ora duwe sambungan kuwi ing kabeh, amarga padha angel kanggo ngleksanakake langsung ing sistem mbagekke sing ora ndhukung obah gedhe chunks data antarane kelenjar.
temonan
Kita rencana nggunakake ClickHouse ing Qwintry ing taun-taun sing bakal teka, amarga DBMS iki nyedhiyakake keseimbangan kinerja, overhead sing murah, skalabilitas lan kesederhanaan. Aku yakin manawa bakal nyebar kanthi cepet yen komunitas ClickHouse entuk luwih akeh cara kanggo nggunakake instalasi cilik nganti ukuran agêng.
Sawetara iklan 🙂
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com