adalah sistem manajemen basis data kolom sumber terbuka untuk pemrosesan kueri analitis online (OLAP) yang dibuat oleh Yandex. Ini digunakan oleh Yandex, CloudFlare, VK.com, Badoo, dan layanan lain di seluruh dunia untuk menyimpan data dalam jumlah yang sangat besar (penyisipan ribuan baris per detik atau petabyte data yang disimpan di disk).
Dalam DBMS “string” biasa, contohnya adalah MySQL, Postgres, MS SQL Server, data disimpan dalam urutan berikut:
Dalam hal ini, nilai-nilai yang terkait dengan satu baris disimpan secara fisik berdampingan. Dalam DBMS kolom, nilai dari kolom yang berbeda disimpan secara terpisah, dan data dari satu kolom disimpan bersama:
Contoh DBMS kolom adalah 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 ini adalah pengirim surat Saya mulai menggunakan Clickhouse pada tahun 2018 untuk pelaporan dan sangat terkesan dengan kesederhanaan, skalabilitas, dukungan SQL, dan kecepatannya. Kecepatan DBMS ini mendekati keajaiban.
Kesederhanaan
Clickhouse menginstal di Ubuntu dengan satu perintah. Jika Anda mengetahui SQL, Anda dapat segera mulai menggunakan Clickhouse untuk kebutuhan Anda. Namun, ini tidak berarti Anda dapat "menampilkan tabel pembuatan" di MySQL dan menyalin-menempelkan SQL di Clickhouse.
Dibandingkan dengan MySQL, terdapat perbedaan tipe data yang penting dalam definisi skema tabel di DBMS ini, sehingga Anda masih memerlukan waktu untuk mengubah definisi skema tabel dan mempelajari mesin tabel agar merasa nyaman.
Clickhouse berfungsi dengan baik tanpa perangkat lunak tambahan apa pun, tetapi jika Anda ingin menggunakan replikasi, Anda harus menginstal ZooKeeper. Analisis kinerja kueri menunjukkan hasil yang sangat baik - tabel sistem berisi semua informasi, dan semua data dapat diperoleh menggunakan SQL yang lama dan membosankan.
Performa
- Perbandingan Clickhouse versus Vertica dan MySQL pada server konfigurasi: dua soket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; RAM 128 GiB; md RAID-5 pada 8 HDD SATA 6TB, ext4.
- perbandingan Clickhouse dengan penyimpanan cloud Amazon RedShift.
- kutipan blog :
Basis data ClickHouse memiliki desain yang sangat sederhana - semua node di cluster memiliki fungsi yang sama dan hanya menggunakan ZooKeeper untuk koordinasi. Kami membangun cluster kecil yang terdiri dari beberapa node dan melakukan pengujian, di mana kami menemukan bahwa sistem tersebut memiliki kinerja yang cukup mengesankan, yang sesuai dengan keunggulan yang disebutkan dalam tolok ukur DBMS analitis. Kami memutuskan untuk melihat lebih dekat konsep di balik ClickHouse. Hambatan pertama untuk penelitian adalah kurangnya alat dan kecilnya komunitas ClickHouse, jadi kami mempelajari desain DBMS ini untuk memahami cara kerjanya.
ClickHouse tidak mendukung penerimaan data langsung dari Kafka karena ini hanya database, jadi kami menulis layanan adaptor kami sendiri di Go. Itu membaca pesan yang dikodekan Cap'n Proto dari Kafka, mengubahnya menjadi TSV, dan memasukkannya ke ClickHouse secara berkelompok melalui antarmuka HTTP. Kami kemudian menulis ulang layanan ini untuk menggunakan perpustakaan Go bersama dengan antarmuka ClickHouse kami sendiri untuk meningkatkan kinerja. Saat mengevaluasi kinerja penerimaan paket, kami menemukan satu hal penting - ternyata untuk ClickHouse kinerja ini sangat bergantung pada ukuran paket, yaitu jumlah baris yang disisipkan pada saat yang bersamaan. Untuk memahami mengapa hal ini terjadi, kami mempelajari bagaimana ClickHouse menyimpan data.
Mesin utama, atau lebih tepatnya, keluarga mesin tabel yang digunakan oleh ClickHouse untuk menyimpan data, adalah MergeTree. Mesin ini secara konseptual mirip dengan algoritme LSM yang digunakan di Google BigTable atau Apache Cassandra, tetapi menghindari pembuatan tabel memori perantara dan menulis data langsung ke disk. Hal ini memberikan throughput penulisan yang sangat baik, karena setiap paket yang dimasukkan hanya diurutkan berdasarkan kunci utama "kunci utama", dikompresi, dan ditulis ke disk untuk membentuk sebuah segmen.
Tidak adanya tabel memori atau konsep “kesegaran” data juga berarti hanya dapat ditambahkan, sistem tidak mendukung perubahan atau penghapusan. Saat ini, satu-satunya cara untuk menghapus data adalah dengan menghapusnya berdasarkan bulan kalender, karena segmen tidak pernah melewati batas bulan. Tim ClickHouse secara aktif berupaya membuat fitur ini dapat disesuaikan. Di sisi lain, hal ini membuat penulisan dan penggabungan segmen bebas perselisihan, sehingga menerima skala throughput secara linear dengan jumlah penyisipan paralel hingga I/O atau inti jenuh.
Namun, keadaan ini juga berarti bahwa sistem tidak cocok untuk paket kecil, sehingga layanan dan penyisipan Kafka digunakan untuk buffering. Selanjutnya, ClickHouse di latar belakang terus menggabungkan segmen, sehingga banyak informasi kecil akan digabungkan dan direkam lebih sering, sehingga meningkatkan intensitas perekaman. Namun, terlalu banyak bagian yang tidak berhubungan akan menyebabkan pembatasan agresif pada sisipan selama penggabungan terus berlanjut. Kami telah menemukan bahwa kompromi terbaik antara penyerapan data real-time dan kinerja penyerapan adalah dengan menerima sejumlah penyisipan per detik ke dalam tabel.
Kunci kinerja pembacaan tabel adalah pengindeksan dan lokasi data pada disk. Tidak peduli seberapa cepat pemrosesannya, ketika mesin perlu memindai data berukuran terabyte dari disk dan hanya menggunakan sebagian kecil saja, itu akan memakan waktu. ClickHouse merupakan penyimpanan kolom, sehingga setiap segmen berisi file untuk setiap kolom (column) dengan nilai yang diurutkan untuk setiap baris. Dengan demikian, seluruh kolom yang tidak ada dalam kueri dapat dilewati terlebih dahulu, lalu beberapa sel dapat diproses secara paralel dengan eksekusi vektor. Untuk menghindari pemindaian penuh, setiap segmen memiliki file indeks kecil.
Mengingat semua kolom diurutkan berdasarkan "kunci utama", file indeks hanya berisi label (baris yang diambil) dari setiap baris ke-N, agar dapat menyimpannya di memori bahkan untuk tabel yang sangat besar. Misalnya, Anda dapat mengatur pengaturan default untuk “menandai setiap baris ke-8192”, lalu “sedikit” mengindeks tabel dengan 1 triliun. baris yang mudah dimasukkan ke dalam memori hanya membutuhkan 122 karakter.
Pengembangan sistem
Perkembangan dan peningkatan Clickhouse dapat ditelusuri dan memastikan bahwa proses “tumbuh dewasa” terjadi dengan kecepatan yang mengesankan.
Popularitas
Popularitas Clickhouse tampaknya tumbuh secara eksponensial, terutama di komunitas berbahasa Rusia. Konferensi High load 2018 tahun lalu (Moskow, 8-9 November 2018) menunjukkan bahwa monster seperti vk.com dan Badoo menggunakan Clickhouse, yang dengannya mereka memasukkan data (misalnya, log) dari puluhan ribu server secara bersamaan. Dalam video berdurasi 40 menit . Kami akan segera memposting transkripnya di Habr untuk kenyamanan mengerjakan materi.
Aplikasi
Setelah menghabiskan beberapa waktu melakukan penelitian, saya pikir ada area di mana ClickHouse dapat berguna atau dapat sepenuhnya menggantikan solusi lain yang lebih tradisional dan populer seperti MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot dan Druid. Berikut ini penjelasan detail penggunaan ClickHouse untuk memodernisasi atau mengganti seluruh DBMS di atas.
Memperluas MySQL dan PostgreSQL
Baru-baru ini, kami mengganti sebagian MySQL dengan ClickHouse untuk platform buletin . Masalahnya adalah MySQL karena desain yang salah mencatat setiap email yang dikirim dan setiap tautan di email itu dengan hash base64, menciptakan tabel MySQL yang besar (email_stats). Setelah hanya mengirim 10 juta email ke pelanggan layanan, tabel ini menghabiskan 150 GB ruang file, dan MySQL mulai "bodoh" pada kueri sederhana. Untuk memperbaiki masalah ruang file, kami berhasil menggunakan kompresi tabel InnoDB, yang menguranginya sebanyak 4 kali lipat. Namun, masih tidak masuk akal untuk menyimpan lebih dari 20-30 juta email di MySQL hanya demi membaca riwayat, karena permintaan sederhana apa pun yang karena alasan tertentu harus melakukan pemindaian penuh akan mengakibatkan pertukaran dan I/O yang berat. overhead, yang secara rutin kami menerima peringatan Zabbix.
Clickhouse menggunakan dua algoritma kompresi yang mengurangi jumlah data sekitar , tetapi dalam kasus khusus ini, datanya sangat "dapat dikompresi".
Penggantian Rusa
Berdasarkan pengalaman saya sendiri, tumpukan ELK (ElasticSearch, Logstash dan Kibana, dalam kasus khusus ini ElasticSearch) memerlukan lebih banyak sumber daya untuk dijalankan daripada yang diperlukan untuk menyimpan log. ElasticSearch adalah mesin yang hebat jika Anda memerlukan pencarian log teks lengkap yang bagus (yang menurut saya tidak terlalu Anda butuhkan), tapi saya bertanya-tanya mengapa ini menjadi mesin logging standar de facto. Kinerja penyerapannya dikombinasikan dengan Logstash memberi kami masalah bahkan pada beban yang cukup ringan dan mengharuskan kami menambah lebih banyak RAM dan ruang disk. Sebagai database, Clickhouse lebih baik daripada ElasticSearch karena alasan berikut:
- Dukungan dialek SQL;
- Tingkat kompresi terbaik dari data yang disimpan;
- Dukungan untuk pencarian Regex alih-alih pencarian teks lengkap;
- Penjadwalan kueri yang ditingkatkan dan kinerja keseluruhan yang lebih baik.
Saat ini, masalah terbesar yang muncul ketika membandingkan ClickHouse dengan ELK adalah kurangnya solusi untuk mengunggah log, serta kurangnya dokumentasi dan tutorial mengenai topik ini. Pada saat yang sama, setiap pengguna dapat mengatur ELK menggunakan manual Digital Ocean, yang sangat penting untuk implementasi cepat teknologi tersebut. Ada mesin database di sini, tapi belum ada Filebeat untuk ClickHouse. Ya ada dan sistem untuk bekerja dengan log , ada alatnya untuk memasukkan data file log ke ClickHouse, tetapi semua ini membutuhkan lebih banyak waktu. Namun, ClickHouse masih menjadi yang terdepan karena kesederhanaannya, sehingga pemula pun dapat dengan mudah menginstalnya dan mulai menggunakannya secara fungsional hanya dalam 10 menit.
Karena lebih memilih solusi minimalis, saya mencoba menggunakan FluentBit, alat unggah log memori sangat rendah, dengan ClickHouse sambil mencoba menghindari penggunaan Kafka. Namun, ketidakcocokan kecil perlu diatasi, seperti sebelumnya dapat dilakukan tanpa lapisan proxy yang mengubah data dari FluentBit ke ClickHouse.
Sebagai alternatif, Kibana dapat digunakan sebagai backend ClickHouse . Dari pemahaman saya, hal ini dapat menyebabkan masalah kinerja saat merender titik data dalam jumlah besar, terutama dengan Grafana versi lama. Kami belum mencobanya di Qwintry, namun keluhan mengenai hal ini muncul dari waktu ke waktu di saluran dukungan ClickHouse di Telegram.
Penggantian Google Big Query dan Amazon RedShift (solusi untuk perusahaan besar)
Kasus penggunaan ideal untuk BigQuery adalah memuat 1 TB data JSON dan menjalankan kueri analitik pada data tersebut. Big Query adalah produk hebat yang skalabilitasnya sulit ditaksir terlalu tinggi. Ini adalah perangkat lunak yang jauh lebih kompleks daripada ClickHouse yang berjalan pada cluster internal, namun dari sudut pandang klien, ini memiliki banyak kesamaan dengan ClickHouse. BigQuery dapat dengan cepat "menaikkan harga" setelah Anda mulai membayar untuk setiap SELECT, jadi ini adalah solusi SaaS nyata dengan segala kelebihan dan kekurangannya.
ClickHouse adalah pilihan terbaik ketika Anda menjalankan banyak kueri yang mahal secara komputasi. Semakin banyak kueri SELECT yang Anda jalankan setiap hari, semakin penting untuk mengganti Big Query dengan ClickHouse, karena penggantian seperti itu akan menghemat ribuan dolar jika menyangkut banyak terabyte data yang sedang diproses. Hal ini tidak berlaku untuk data yang disimpan, yang cukup murah untuk diproses di Big Query.
Dalam sebuah artikel oleh salah satu pendiri Altinity Alexander Zaitsev menjelaskan manfaat migrasi DBMS tersebut.
Penggantian TimescaleDB
TimescaleDB adalah ekstensi PostgreSQL yang mengoptimalkan kerja dengan deret waktu dalam database biasa (, ).
Meskipun ClickHouse bukan pesaing serius dalam ceruk deret waktu, namun dalam hal struktur kolom dan eksekusi kueri vektor, ClickHouse jauh lebih cepat daripada TimescaleDB dalam sebagian besar kasus pemrosesan kueri analitis. Pada saat yang sama, kinerja penerimaan data paket ClickHouse sekitar 3 kali lebih tinggi, selain itu, ia menggunakan ruang disk 20 kali lebih sedikit, yang sangat penting untuk memproses data historis dalam jumlah besar: .
Tidak seperti ClickHouse, satu-satunya cara untuk menghemat ruang disk di TimescaleDB adalah dengan menggunakan ZFS atau sistem file serupa.
Pembaruan ClickHouse yang akan datang kemungkinan akan memperkenalkan kompresi delta, yang membuatnya lebih cocok untuk memproses dan menyimpan data deret waktu. TimescaleDB mungkin merupakan pilihan yang lebih baik daripada ClickHouse dalam kasus berikut:
- instalasi kecil dengan RAM sangat sedikit (<3 GB);
- sejumlah besar INSERT kecil yang tidak ingin Anda buffer menjadi fragmen besar;
- konsistensi, keseragaman dan persyaratan ACID yang lebih baik;
- dukungan pascaGIS;
- gabungkan dengan tabel PostgreSQL yang ada, karena Timescale DB pada dasarnya adalah PostgreSQL.
Persaingan dengan sistem Hadoop dan MapReduce
Hadoop dan produk MapReduce lainnya dapat melakukan banyak penghitungan rumit, namun cenderung berjalan pada latensi yang sangat besar. ClickHouse memperbaiki masalah ini dengan memproses data berukuran terabyte dan memberikan hasil hampir secara instan. Oleh karena itu, ClickHouse jauh lebih efisien untuk melakukan penelitian analitis yang cepat dan interaktif, yang seharusnya menarik bagi para ilmuwan data.
Persaingan dengan Pinot dan Druid
Pesaing terdekat ClickHouse adalah produk open source berbentuk kolom dan dapat diskalakan secara linier, Pinot dan Druid. Pekerjaan luar biasa yang membandingkan sistem ini dipublikasikan dalam artikel 1 Februari 2018
Artikel ini perlu diperbarui - dikatakan bahwa ClickHouse tidak mendukung operasi UPDATE dan DELETE, yang tidak sepenuhnya benar sehubungan dengan versi terbaru.
Kami tidak memiliki banyak pengalaman dengan DBMS ini, tapi saya tidak menyukai kompleksitas infrastruktur dasar yang diperlukan untuk menjalankan Druid dan Pinot - ini adalah sekumpulan "bagian bergerak" yang dikelilingi oleh Java dari semua sisi.
Druid dan Pinot adalah proyek inkubator Apache, yang perkembangannya dibahas secara rinci oleh Apache di halaman proyek GitHub-nya. Pinot muncul di inkubator pada Oktober 2018, dan Druid lahir 8 bulan sebelumnya - pada bulan Februari.
Kurangnya informasi tentang cara kerja AFS menimbulkan beberapa pertanyaan, dan mungkin bodoh, bagi saya. Saya ingin tahu apakah penulis Pinot memperhatikan bahwa Apache Foundation lebih condong ke arah Druid, dan apakah sikap seperti itu terhadap pesaing menimbulkan perasaan iri? Akankah perkembangan Druid melambat dan perkembangan Pinot semakin cepat jika sponsor yang mendukung Pinot tiba-tiba tertarik pada Pinot?
Kekurangan ClickHouse
Ketidakdewasaan: Jelas, ini masih merupakan teknologi yang membosankan, tetapi bagaimanapun juga, hal seperti ini tidak terlihat di DBMS kolumnar lainnya.
Sisipan kecil tidak bekerja dengan baik pada kecepatan tinggi: sisipan harus dipecah menjadi bagian yang lebih besar karena kinerja sisipan kecil menurun sebanding dengan jumlah kolom di setiap baris. Beginilah cara ClickHouse menyimpan data pada disk - setiap kolom mewakili 1 file atau lebih, jadi untuk menyisipkan 1 baris berisi 100 kolom, Anda perlu membuka dan menulis setidaknya 100 file. Inilah sebabnya mengapa penyisipan buffering memerlukan perantara (kecuali klien sendiri yang menyediakan buffering) - biasanya Kafka atau semacam sistem manajemen antrean. Anda juga dapat menggunakan mesin tabel Buffer untuk kemudian menyalin sejumlah besar data ke dalam tabel MergeTree.
Penggabungan tabel dibatasi oleh RAM server, tapi setidaknya ada! Misalnya, Druid dan Pinot tidak memiliki koneksi seperti itu sama sekali karena sulit diterapkan secara langsung dalam sistem terdistribusi yang tidak mendukung perpindahan sejumlah besar data antar node.
Temuan
Di tahun-tahun mendatang, kami berencana untuk menggunakan ClickHouse secara ekstensif di Qwintry, karena DBMS ini memberikan keseimbangan kinerja yang sangat baik, overhead rendah, skalabilitas, dan kesederhanaan. Saya cukup yakin ini akan menyebar dengan cepat setelah komunitas ClickHouse menemukan lebih banyak cara untuk menggunakannya dalam instalasi kecil dan menengah.
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x 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 - mulai $99! Membaca tentang
Sumber: www.habr.com