ialah sistem pengurusan pangkalan data kolumnar sumber terbuka untuk pemprosesan pertanyaan analitikal dalam talian (OLAP) yang dicipta oleh Yandex. Ia digunakan oleh Yandex, CloudFlare, VK.com, Badoo dan perkhidmatan lain di seluruh dunia untuk menyimpan jumlah data yang sangat besar (pemasukan beribu-ribu baris sesaat atau petabait data yang disimpan pada cakera).
Dalam biasa, "rentetan" DBMS, contohnya adalah MySQL, Postgres, MS SQL Server, data disimpan dalam susunan ini:
Dalam kes ini, nilai yang berkaitan dengan satu baris disimpan secara fizikal bersebelahan. Dalam DBMS kolumnar, nilai dari lajur yang berbeza disimpan secara berasingan, dan data satu lajur disimpan bersama:
Contoh DBMS kolumnar ialah Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Syarikat itu adalah penghantar mel Saya mula menggunakan Clickhouse pada tahun 2018 untuk melaporkan dan sangat kagum dengan kesederhanaan, kebolehskalaan, sokongan SQL dan kelajuannya. Kepantasan DBMS ini bersempadan dengan sihir.
Kesederhanaan
Clickhouse memasang pada Ubuntu dengan satu arahan. Jika anda tahu SQL, anda boleh mula menggunakan Clickhouse dengan segera untuk keperluan anda. Walau bagaimanapun, ini tidak bermakna anda boleh "menunjukkan jadual cipta" dalam MySQL dan salin-tampal SQL dalam Clickhouse.
Berbanding dengan MySQL, terdapat perbezaan jenis data yang penting dalam definisi skema jadual dalam DBMS ini, jadi anda masih memerlukan sedikit masa untuk menukar definisi skema jadual dan mempelajari enjin jadual untuk menjadi selesa.
Clickhouse berfungsi hebat tanpa sebarang perisian tambahan, tetapi jika anda ingin menggunakan replikasi anda perlu memasang ZooKeeper. Analisis prestasi pertanyaan menunjukkan hasil yang sangat baik - jadual sistem mengandungi semua maklumat, dan semua data boleh diperoleh menggunakan SQL lama dan membosankan.
Produktiviti
- Clickhouse berbanding Vertica dan perbandingan MySQL pada pelayan konfigurasi: dua soket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 pada 8 6TB SATA HDD, samb4.
- perbandingan Clickhouse dengan storan awan Amazon RedShift.
- Petikan blog :
Pangkalan data ClickHouse mempunyai reka bentuk yang sangat mudah - semua nod dalam kelompok mempunyai fungsi yang sama dan hanya menggunakan ZooKeeper untuk penyelarasan. Kami membina gugusan kecil beberapa nod dan melakukan ujian, di mana kami mendapati bahawa sistem ini mempunyai prestasi yang agak mengagumkan, yang sepadan dengan kelebihan yang didakwa dalam penanda aras DBMS analitikal. Kami memutuskan untuk melihat dengan lebih dekat konsep di sebalik ClickHouse. Halangan pertama untuk penyelidikan ialah kekurangan alatan dan komuniti kecil ClickHouse, jadi kami menyelidiki reka bentuk DBMS ini untuk memahami cara ia berfungsi.
ClickHouse tidak menyokong penerimaan data terus daripada Kafka, kerana ia hanyalah pangkalan data, jadi kami menulis perkhidmatan penyesuai kami sendiri dalam Go. Ia membaca mesej Cap'n Proto yang dikodkan daripada Kafka, menukarkannya kepada TSV, dan memasukkannya ke dalam ClickHouse secara berkelompok melalui antara muka HTTP. Kami kemudiannya menulis semula perkhidmatan ini untuk menggunakan perpustakaan Go bersama-sama dengan antara muka ClickHouse kami sendiri untuk meningkatkan prestasi. Apabila menilai prestasi menerima paket, kami mendapati satu perkara penting - ternyata untuk ClickHouse prestasi ini sangat bergantung pada saiz paket, iaitu bilangan baris yang dimasukkan pada masa yang sama. Untuk memahami sebab ini berlaku, kami mengkaji cara ClickHouse menyimpan data.
Enjin utama, atau lebih tepatnya, keluarga enjin meja yang digunakan oleh ClickHouse untuk menyimpan data, ialah MergeTree. Enjin ini secara konsepnya serupa dengan algoritma LSM yang digunakan dalam Google BigTable atau Apache Cassandra, tetapi mengelak daripada membina jadual memori perantaraan dan menulis data terus ke cakera. Ini memberikan kemampuan menulis yang sangat baik, kerana setiap paket yang dimasukkan hanya diisih mengikut kekunci utama "kunci utama", dimampatkan dan ditulis ke cakera untuk membentuk segmen.
Ketiadaan jadual memori atau sebarang konsep "kesegaran" data juga bermakna ia hanya boleh ditambah, sistem tidak menyokong penukaran atau pemadaman. Mulai hari ini, satu-satunya cara untuk memadamkan data ialah memadamkannya mengikut bulan kalendar, kerana segmen tidak pernah melintasi sempadan bulan. Pasukan ClickHouse sedang giat berusaha untuk menjadikan ciri ini boleh disesuaikan. Sebaliknya, ia menjadikan penulisan dan penggabungan segmen bebas perbalahan, jadi terima skala pemprosesan secara linear dengan bilangan sisipan selari sehingga I/O atau teras tepu.
Walau bagaimanapun, keadaan ini juga bermakna sistem ini tidak sesuai untuk paket kecil, jadi perkhidmatan Kafka dan penyisipan digunakan untuk penimbal. Selanjutnya, ClickHouse di latar belakang terus menggabungkan segmen secara berterusan, supaya banyak maklumat kecil akan digabungkan dan direkodkan lebih banyak kali, sekali gus meningkatkan intensiti rakaman. Walau bagaimanapun, terlalu banyak bahagian yang tidak berkaitan akan menyebabkan pendikitan sisipan yang agresif selagi penggabungan berterusan. Kami telah mendapati bahawa kompromi terbaik antara pengingesan data masa nyata dan prestasi pengingesan ialah menerima bilangan sisipan sesaat yang terhad ke dalam jadual.
Kunci kepada prestasi bacaan jadual ialah pengindeksan dan lokasi data pada cakera. Tidak kira betapa pantas pemprosesannya, apabila enjin perlu mengimbas terabait data dari cakera dan hanya menggunakan sebahagian kecil daripadanya, ia akan mengambil masa. ClickHouse ialah kedai lajur, jadi setiap segmen mengandungi fail untuk setiap lajur (lajur) dengan nilai diisih untuk setiap baris. Oleh itu, keseluruhan lajur yang tidak terdapat dalam pertanyaan boleh dilangkau dahulu, dan kemudian berbilang sel boleh diproses selari dengan pelaksanaan vektor. Untuk mengelakkan imbasan penuh, setiap segmen mempunyai fail indeks kecil.
Memandangkan semua lajur diisih mengikut "kunci utama", fail indeks hanya mengandungi label (baris yang ditangkap) bagi setiap baris ke-N, supaya dapat menyimpannya dalam ingatan walaupun untuk jadual yang sangat besar. Sebagai contoh, anda boleh menetapkan tetapan lalai untuk "menandai setiap baris ke-8192", kemudian mengindeks "sedikit" jadual dengan 1 trilion. baris yang sesuai dengan mudah ke dalam ingatan hanya akan mengambil 122 aksara.
Pembangunan sistem
Pembangunan dan penambahbaikan Clickhouse boleh dikesan pada dan pastikan bahawa proses "membesar" berlaku pada kadar yang mengagumkan.
Populariti
Nampaknya populariti Clickhouse berkembang dengan pesat, terutamanya dalam komuniti berbahasa Rusia. Persidangan High load 2018 tahun lepas (Moscow, 8-9 November 2018) menunjukkan bahawa raksasa seperti vk.com dan Badoo menggunakan Clickhouse, yang memasukkan data (contohnya, log) daripada puluhan ribu pelayan secara serentak. Dalam video 40 minit . Tidak lama lagi kami akan menyiarkan transkrip di Habr untuk kemudahan bekerja dengan bahan tersebut.
Permohonan
Selepas meluangkan sedikit masa untuk meneliti, saya fikir terdapat kawasan di mana ClickHouse boleh berguna atau dapat menggantikan sepenuhnya penyelesaian lain yang lebih tradisional dan popular seperti MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot dan Druid. Berikut ialah butiran menggunakan ClickHouse untuk menaik taraf atau menggantikan sepenuhnya DBMS di atas.
Memperluas MySQL dan PostgreSQL
Terbaru, kami telah menggantikan sebahagian MySQL dengan ClickHouse untuk platform surat berita . Masalahnya adalah bahawa MySQL kerana reka bentuk yang salah melog setiap e-mel yang dihantar dan setiap pautan dalam e-mel itu dengan hash base64, mencipta jadual MySQL yang besar (email_stats). Selepas menghantar hanya 10 juta e-mel kepada pelanggan perkhidmatan, jadual ini menduduki 150 GB ruang fail, dan MySQL mula "bodoh" pada pertanyaan mudah. Untuk menyelesaikan isu ruang fail, kami berjaya menggunakan pemampatan jadual InnoDB, yang mengurangkannya dengan faktor 4. Walau bagaimanapun, masih tidak masuk akal untuk menyimpan lebih daripada 20-30 juta e-mel dalam MySQL hanya untuk membaca sejarah, kerana sebarang pertanyaan mudah yang atas sebab tertentu perlu melakukan imbasan penuh menghasilkan pertukaran dan I/O berat overhed, yang kami kerap menerima amaran Zabbix.
Clickhouse menggunakan dua algoritma pemampatan yang mengurangkan jumlah data sebanyak kira-kira , tetapi dalam kes khusus ini, data adalah "boleh mampat".
Penggantian ELK
Berdasarkan pengalaman saya sendiri, timbunan ELK (ElasticSearch, Logstash dan Kibana, dalam kes ini ElasticSearch) memerlukan lebih banyak sumber untuk dijalankan daripada yang diperlukan untuk menyimpan log. ElasticSearch ialah enjin yang hebat jika anda mahukan carian log teks penuh yang baik (dan saya rasa anda tidak benar-benar memerlukannya), tetapi saya tertanya-tanya mengapa ia telah menjadi enjin pengelogan standard de facto. Prestasi pengingesannya, digabungkan dengan Logstash, memberi kami masalah walaupun pada beban kerja yang agak ringan dan memerlukan penambahan lebih banyak RAM dan ruang cakera. Sebagai pangkalan data, Clickhouse lebih baik daripada ElasticSearch atas sebab berikut:
- Sokongan dialek SQL;
- Tahap pemampatan terbaik bagi data yang disimpan;
- Sokongan untuk carian Regex dan bukannya carian teks penuh;
- Penjadualan pertanyaan yang lebih baik dan prestasi keseluruhan yang lebih baik.
Pada masa ini, masalah terbesar yang timbul apabila membandingkan ClickHouse dengan ELK ialah kekurangan penyelesaian untuk memuat naik log, serta kekurangan dokumentasi dan tutorial mengenai topik ini. Pada masa yang sama, setiap pengguna boleh menyediakan ELK menggunakan manual Lautan Digital, yang sangat penting untuk pelaksanaan pantas teknologi tersebut. Terdapat enjin pangkalan data di sini, tetapi belum ada Filebeat untuk ClickHouse. Ya, memang ada dan sistem untuk bekerja dengan log , ada alat untuk memasukkan data fail log ke ClickHouse, tetapi semua ini memerlukan lebih banyak masa. Walau bagaimanapun, ClickHouse masih mendahului kerana kesederhanaannya, jadi walaupun pemula boleh memasangnya dengan mudah dan memulakan penggunaan berfungsi sepenuhnya dalam masa 10 minit sahaja.
Lebih suka penyelesaian minimalis, saya cuba menggunakan FluentBit, alat muat naik log memori yang sangat rendah, dengan ClickHouse, sambil cuba mengelak daripada menggunakan Kafka. Walau bagaimanapun, ketidakserasian kecil perlu ditangani, seperti sebelum ia boleh dilakukan tanpa lapisan proksi yang menukar data daripada FluentBit kepada ClickHouse.
Sebagai alternatif kepada Kibana, anda boleh menggunakan ClickHouse sebagai backend . Setakat yang saya faham, ini boleh menyebabkan masalah prestasi apabila memaparkan sejumlah besar titik data, terutamanya dengan versi Grafana yang lebih lama. Dalam Qwintry, kami belum mencuba ini lagi, tetapi aduan mengenai perkara ini muncul dari semasa ke semasa di saluran sokongan ClickHouse dalam Telegram.
Penggantian Google Big Query dan Amazon RedShift (penyelesaian untuk syarikat besar)
Kes penggunaan yang ideal untuk BigQuery ialah memuatkan 1TB data JSON dan menjalankan pertanyaan analitik padanya. Big Query ialah produk hebat yang skalabilitinya sukar untuk dinilai terlalu tinggi. Ini adalah perisian yang jauh lebih kompleks daripada ClickHouse yang dijalankan pada kluster dalaman, tetapi dari sudut pandangan pelanggan, ia mempunyai banyak persamaan dengan ClickHouse. BigQuery boleh "menaikkan harga" dengan cepat sebaik sahaja anda mula membayar untuk setiap SELECT, jadi ini merupakan penyelesaian SaaS sebenar dengan semua kebaikan dan keburukannya.
ClickHouse ialah pilihan terbaik apabila anda menjalankan banyak pertanyaan yang mahal dari segi pengiraan. Lebih banyak pertanyaan PILIH yang anda jalankan setiap hari, lebih banyak perkara yang diperoleh untuk menggantikan Pertanyaan Besar dengan ClickHouse, kerana penggantian sedemikian akan menjimatkan beribu-ribu ringgit apabila melibatkan banyak terabait data yang sedang diproses. Ini tidak terpakai pada data yang disimpan, yang agak murah untuk diproses dalam Big Query.
Dalam artikel oleh Alexander Zaitsev, pengasas bersama Altinity menerangkan faedah migrasi DBMS sedemikian.
Penggantian TimescaleDB
TimescaleDB ialah sambungan PostgreSQL yang mengoptimumkan kerja dengan siri masa dalam pangkalan data biasa (, ).
Walaupun ClickHouse bukanlah pesaing yang serius dalam niche siri masa, tetapi dari segi struktur kolumnar dan pelaksanaan pertanyaan vektor, ia adalah lebih pantas daripada TimescaleDB dalam kebanyakan kes memproses pertanyaan analisis. Pada masa yang sama, prestasi menerima data paket ClickHouse adalah kira-kira 3 kali lebih tinggi, di samping itu, ia menggunakan ruang cakera 20 kali lebih sedikit, yang sangat penting untuk memproses jumlah data sejarah yang besar: .
Tidak seperti ClickHouse, satu-satunya cara untuk menjimatkan ruang cakera dalam TimescaleDB ialah menggunakan ZFS atau sistem fail yang serupa.
Kemas kini akan datang untuk ClickHouse mungkin akan memperkenalkan pemampatan delta, yang akan menjadikannya lebih sesuai untuk memproses dan menyimpan data siri masa. TimescaleDB mungkin merupakan pilihan yang lebih baik daripada ClickHouse kosong dalam kes berikut:
- pemasangan kecil dengan RAM yang sangat sedikit (<3 GB);
- sebilangan besar INSERT kecil yang anda tidak mahu timbal menjadi serpihan besar;
- ketekalan, keseragaman dan keperluan ASID yang lebih baik;
- Sokongan PostGIS;
- bergabung dengan jadual PostgreSQL sedia ada, kerana Timescale DB pada asasnya ialah PostgreSQL.
Persaingan dengan sistem Hadoop dan MapReduce
Hadoop dan produk MapReduce yang lain boleh melakukan banyak pengiraan yang rumit, tetapi mereka cenderung berjalan pada kependaman yang besar. ClickHouse membetulkan masalah ini dengan memproses terabait data dan menghasilkan keputusan hampir serta-merta. Oleh itu, ClickHouse jauh lebih cekap untuk melaksanakan penyelidikan analitik yang pantas dan interaktif, yang sepatutnya menarik minat saintis data.
Persaingan dengan Pinot dan Druid
Pesaing terdekat ClickHouse ialah kolumnar, produk sumber terbuka berskala linear Pinot dan Druid. Kerja yang sangat baik membandingkan sistem ini diterbitkan dalam artikel 1 Februari 2018
Artikel ini perlu dikemas kini - ia mengatakan bahawa ClickHouse tidak menyokong operasi KEMASKINI dan PADAM, yang tidak sepenuhnya benar berkaitan dengan versi terkini.
Kami tidak mempunyai banyak pengalaman dengan DBMS ini, tetapi saya tidak menyukai kerumitan infrastruktur asas yang diperlukan untuk menjalankan Druid dan Pinot - ia adalah sekumpulan "bahagian bergerak" yang dikelilingi oleh Java dari semua pihak.
Druid dan Pinot ialah projek inkubator Apache, yang diliputi secara terperinci oleh Apache pada halaman projek GitHub mereka. Pinot muncul dalam inkubator pada Oktober 2018, dan Druid dilahirkan 8 bulan lebih awal - pada bulan Februari.
Kekurangan maklumat tentang cara AFS berfungsi menimbulkan beberapa, dan mungkin bodoh, soalan untuk saya. Saya tertanya-tanya adakah pengarang Pinot menyedari bahawa Yayasan Apache lebih cenderung kepada Druid, dan adakah sikap sedemikian terhadap pesaing menyebabkan perasaan iri hati? Adakah perkembangan Druid akan menjadi perlahan dan perkembangan Pinot akan dipercepatkan jika penaja yang menyokong Druid tiba-tiba berminat dengan yang kedua?
Kelemahan ClickHouse
Ketidakmatangan: Jelas sekali, ini masih merupakan teknologi yang membosankan, tetapi dalam apa jua keadaan, tiada apa yang seperti ini dilihat dalam DBMS kolumnar lain.
Sisipan kecil tidak berfungsi dengan baik pada kelajuan tinggi: sisipan mesti dibahagikan kepada ketulan besar kerana prestasi sisipan kecil merosot mengikut kadar bilangan lajur dalam setiap baris. Beginilah cara ClickHouse menyimpan data pada cakera - setiap lajur bermakna 1 fail atau lebih, jadi untuk memasukkan 1 baris yang mengandungi 100 lajur, anda perlu membuka dan menulis sekurang-kurangnya 100 fail. Inilah sebabnya mengapa penimbalan sisipan memerlukan perantara (melainkan pelanggan itu sendiri menyediakan penimbalan) - biasanya Kafka atau sejenis sistem giliran. Anda juga boleh menggunakan enjin jadual Penampan untuk menyalin sebahagian besar data ke dalam jadual MergeTree kemudian.
Sambungan jadual dihadkan oleh RAM pelayan, tetapi sekurang-kurangnya ia ada! Sebagai contoh, Druid dan Pinot tidak mempunyai sambungan sedemikian sama sekali, kerana ia sukar untuk dilaksanakan secara langsung dalam sistem teragih yang tidak menyokong pemindahan sebahagian besar data antara nod.
Penemuan
Pada tahun-tahun akan datang, kami merancang untuk menggunakan ClickHouse secara meluas dalam Qwintry, kerana DBMS ini menyediakan keseimbangan prestasi yang sangat baik, overhed rendah, kebolehskalaan dan kesederhanaan. Saya agak pasti ia akan merebak dengan cepat apabila komuniti ClickHouse menghasilkan lebih banyak cara untuk menggunakannya dalam pemasangan kecil dan sederhana.
Beberapa iklan 🙂
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com