🥇Pindah ke ClickHouse: 3 tahun kemudian

Tiga tahun lalu Viktor Tarnavsky dan Alexei Milovidov dari Yandex di atas panggung HighLoad ++ diceritakan, seberapa bagus ClickHouse, dan bagaimana ia tidak melambat. Dan pada tahap selanjutnya ada Alexander Zaitsev с laporan tentang pindah ke KlikRumah dari DBMS analitis lain dan dengan kesimpulan bahwa KlikRumah, tentu saja, bagus, tapi tidak terlalu nyaman. Ketika pada tahun 2016 perusahaan LifeStreet, tempat Alexander bekerja, mengubah sistem analitik multi-petabyte menjadi KlikRumah, itu adalah “jalan bata kuning” yang menakjubkan dan penuh dengan bahaya yang tidak diketahui - KlikRumah saat itu tampak seperti ladang ranjau.

Tiga tahun kemudian KlikRumah menjadi jauh lebih baik - selama ini Alexander mendirikan perusahaan Altinity, yang tidak hanya membantu orang berpindah KlikRumah lusinan proyek, tetapi juga meningkatkan produk itu sendiri bersama rekan-rekan dari Yandex. Sekarang KlikRumah masih bukan jalan santai, tapi bukan lagi ladang ranjau.

Alexander telah bekerja dengan sistem terdistribusi sejak tahun 2003, mengembangkan proyek-proyek besar MySQL, Oracle и Vertikal. Di akhir HighLoad ++ 2019 Alexander, salah satu pionir penggunaan KlikRumah, diberitahu apa itu DBMS sekarang. Kita akan belajar tentang fitur-fitur utama KlikRumah: apa perbedaannya dari sistem lain dan dalam hal apa lebih efektif menggunakannya. Dengan menggunakan contoh, kita akan melihat praktik terbaru dan yang telah teruji oleh proyek untuk membangun sistem berdasarkan KlikRumah.

Retrospektif: apa yang terjadi 3 tahun lalu

Tiga tahun lalu kami memindahkan perusahaan LifeStreet pada KlikRumah dari database analitis lain, dan migrasi analisis jaringan iklan terlihat seperti ini:

Juni 2016. Masuk Sumber Terbuka muncul KlikRumah dan proyek kami dimulai;
Agustus Bukti dari konsep: jaringan periklanan besar, infrastruktur, dan data 200-300 terabyte;
Oktober. Data produksi pertama;
Desember. Muatan produk secara penuh adalah 10-50 miliar peristiwa per hari.
Juni 2017. Migrasi pengguna yang berhasil ke KlikRumah, 2,5 petabyte data pada cluster yang terdiri dari 60 server.

Selama proses migrasi, ada pemahaman yang berkembang tentang hal itu KlikRumah adalah sistem bagus yang menyenangkan untuk digunakan, tetapi ini adalah proyek internal Yandex. Oleh karena itu, ada beberapa perbedaan: Yandex pertama-tama akan berurusan dengan pelanggan internalnya sendiri dan baru kemudian dengan komunitas dan kebutuhan pengguna eksternal, dan ClickHouse kemudian tidak mencapai tingkat perusahaan di banyak area fungsional. Itu sebabnya kami mendirikan Altinity pada bulan Maret 2017 untuk membuat KlikRumah bahkan lebih cepat dan nyaman tidak hanya untuk Yandex, tetapi juga untuk pengguna lain. Dan sekarang kita:

Kami melatih dan membantu membangun solusi berdasarkan KlikRumah agar pelanggan tidak mendapat masalah, dan agar solusinya berhasil;
Kami menyediakan dukungan 24/7 KlikRumah- instalasi;
Kami mengembangkan proyek ekosistem kami sendiri;
Kami secara aktif berkomitmen pada diri kami sendiri KlikRumah, menanggapi permintaan dari pengguna yang ingin melihat fitur tertentu.

Dan tentu saja, kami membantu untuk pindah ke KlikRumah с MySQL, Vertikal, Peramal, plum hijau, Redshift dan sistem lainnya. Kami telah terlibat dalam berbagai gerakan, dan semuanya berhasil.

Mengapa pindah ke KlikRumah

Tidak melambat! Ini adalah alasan utama. KlikRumah - database yang sangat cepat untuk berbagai skenario:

Kutipan acak dari orang-orang yang sudah lama bekerja dengan orang lain KlikRumah.

Skalabilitas. Di beberapa database lain Anda dapat mencapai kinerja yang baik pada satu perangkat keras, namun KlikRumah Anda dapat menskalakan tidak hanya secara vertikal, tetapi juga secara horizontal, cukup dengan menambahkan server. Semuanya tidak berjalan semulus yang kita inginkan, tapi berhasil. Anda dapat memperluas sistem seiring pertumbuhan bisnis Anda. Penting bagi kita untuk tidak dibatasi oleh solusi saat ini dan selalu ada potensi untuk dikembangkan.

Portabilitas. Tidak ada keterikatan pada satu hal. Misalnya dengan Pergeseran Merah Amazon Sulit untuk berpindah ke suatu tempat. A KlikRumah Anda dapat menginstalnya di laptop Anda, server, menyebarkannya ke cloud, buka Kubernetes — tidak ada pembatasan pada pengoperasian infrastruktur. Ini nyaman bagi semua orang, dan ini merupakan keuntungan besar yang tidak dapat dibanggakan oleh banyak database serupa lainnya.

Keluwesan. KlikRumah tidak berhenti pada satu hal, misalnya Yandex.Metrica, tetapi berkembang dan digunakan di semakin banyak proyek dan industri yang berbeda. Hal ini dapat diperluas dengan menambahkan kemampuan baru untuk memecahkan masalah baru. Misalnya, diyakini bahwa menyimpan log dalam database adalah perilaku yang buruk, sehingga mereka muncul Elasticsearch. Namun berkat fleksibilitas KlikRumah, Anda juga dapat menyimpan log di dalamnya, dan seringkali ini lebih baik daripada di dalamnya Elasticsearch - di KlikRumah ini membutuhkan zat besi 10 kali lebih sedikit.

Gratis Open Source. Anda tidak perlu membayar apa pun. Tidak perlu menegosiasikan izin untuk menginstal sistem di laptop atau server Anda. Tidak ada biaya tersembunyi. Pada saat yang sama, tidak ada teknologi database Open Source lain yang dapat menandingi kecepatannya KlikRumah. MySQL, MariaDB, Greenplum - semuanya jauh lebih lambat.

Komunitas, mengemudi dan kesenangan. Di KlikRumah komunitas luar biasa: pertemuan, obrolan, dan Alexei Milovidov, yang memberi energi dan optimisme kepada kita semua.

Pindah ke ClickHouse

Pergi ke KlikRumah untuk beberapa alasan, Anda hanya memerlukan tiga hal:

Pahami batasannya KlikRumah dan apa yang tidak cocok untuknya.
Mengambil keuntungan teknologi dan kekuatan terbesarnya.
Percobaan. Bahkan memahami cara kerjanya KlikRumah, tidak selalu mungkin untuk memprediksi kapan akan lebih cepat, kapan akan lebih lambat, kapan akan lebih baik, dan kapan akan lebih buruk. Jadi cobalah.

Masalah perpindahan

Hanya ada satu “tetapi”: jika Anda pindah ke KlikRumah dari sesuatu yang lain, maka biasanya ada yang tidak beres. Kami terbiasa dengan beberapa praktik dan hal-hal yang berfungsi di database favorit kami. Misalnya, siapa pun yang bekerja dengan SQL-database menganggap serangkaian fungsi berikut ini wajib:

transaksi;
kendala;
konsistensi;
indeks;
PERBARUI/HAPUS;
NULL;
milidetik;
gips tipe otomatis;
banyak gabungan;
partisi sewenang-wenang;
alat manajemen cluster.

Rekrutmen itu wajib, tapi tiga tahun lalu masuk KlikRumah Tak satu pun dari fungsi ini tersedia! Sekarang kurang dari separuh yang belum diterapkan tersisa: transaksi, batasan, Konsistensi, milidetik, dan pengecoran tipe.

Dan yang paling penting adalah itu masuk KlikRumah beberapa praktik dan pendekatan standar tidak berfungsi atau bekerja secara berbeda dari biasanya. Segala sesuatu yang muncul di KlikRumah, sesuai dengan "Cara ClickHouse", yaitu fungsinya berbeda dari database lain. Misalnya:

Indeks tidak dipilih, tetapi dilewati.
PERBARUI/HAPUS tidak sinkron, tetapi asinkron.
Ada beberapa gabungan, namun tidak ada perencana kueri. Bagaimana kinerjanya umumnya tidak begitu jelas bagi orang-orang dari dunia database.

Skrip ClickHouse

Pada tahun 1960, seorang matematikawan Amerika asal Hongaria Wigner EP menulis artikel "Efektivitas matematika yang tidak masuk akal dalam ilmu alam” (“Efektifitas Matematika yang Tidak Dapat Dipahami dalam Ilmu Pengetahuan Alam”) bahwa dunia di sekitar kita karena alasan tertentu dijelaskan dengan baik oleh hukum matematika. Matematika adalah ilmu abstrak, dan hukum fisika yang dinyatakan dalam bentuk matematika bukanlah hal yang sepele, dan Wigner EP menekankan bahwa ini sangat aneh.

Dari sudut pandang saya, KlikRumah - keanehan yang sama. Untuk mengulangi kata-kata Wigner, kita dapat mengatakan ini: efisiensi yang tak terbayangkan sungguh mencengangkan KlikRumah dalam berbagai macam aplikasi analitis!

Sebagai contoh, mari kita ambil Gudang Data Waktu Nyata, tempat data dimuat hampir terus menerus. Kami ingin menerima permintaan darinya dengan penundaan kedua. Tolong - gunakan itu KlikRumah, karena skenario inilah yang dirancang untuknya. KlikRumah ini persis bagaimana hal ini digunakan tidak hanya di web, tetapi juga dalam pemasaran dan analisis keuangan, AdTech, serta di Deteksi penipuanN. DI DALAM Gudang Data Waktu Nyata skema terstruktur yang kompleks seperti "bintang" atau "kepingan salju" digunakan, banyak tabel dengan BERGABUNG (terkadang banyak), dan data biasanya disimpan dan diubah di beberapa sistem.

Mari kita ambil skenario lain - Seri waktu: pemantauan perangkat, jaringan, statistik penggunaan, Internet of Things. Di sini kita menjumpai kejadian-kejadian sederhana yang diurutkan berdasarkan waktu. KlikRumah pada awalnya tidak dikembangkan untuk ini, namun telah terbukti berfungsi dengan baik, itulah sebabnya perusahaan besar menggunakannya KlikRumah sebagai tempat penyimpanan informasi pemantauan. Untuk mengeksplorasi apakah itu cocok KlikRumah untuk time-series, kami membuat benchmark berdasarkan pendekatan dan hasil masuknyaDB и Skala waktuDB - terspesialisasi deret waktu database. TernyataBahwa KlikRumah, bahkan tanpa optimasi untuk tugas-tugas seperti itu, menang di bidang asing:

В deret waktu Biasanya tabel sempit digunakan - beberapa kolom kecil. Banyak data yang dapat diperoleh dari pemantauan—jutaan catatan per detik—dan biasanya data tersebut datang dalam jumlah kecil (real-time mengalir). Oleh karena itu, diperlukan skrip penyisipan yang berbeda, dan kuerinya sendiri memiliki spesifikasinya sendiri.

Manajemen Log. Mengumpulkan log ke dalam database biasanya buruk, tapi KlikRumah ini dapat dilakukan dengan beberapa komentar seperti dijelaskan di atas. Banyak perusahaan yang menggunakan KlikRumah tepatnya untuk tujuan ini. Dalam hal ini, kami menggunakan tabel datar lebar tempat kami menyimpan seluruh log (misalnya, dalam formulir JSON), atau dipotong-potong. Data biasanya dimuat dalam kumpulan besar (file), dan kami mencari berdasarkan beberapa bidang.

Untuk masing-masing fungsi ini, database khusus biasanya digunakan. KlikRumah seseorang dapat melakukan semuanya dengan sangat baik sehingga kinerjanya mengungguli mereka. Sekarang mari kita lihat lebih dekat deret waktu skenario, dan cara “memasak” dengan benar KlikRumah untuk skenario ini.

Seri Waktu

Saat ini inilah skenario utama yang terjadi KlikRumah dianggap sebagai solusi standar. Deret waktu adalah serangkaian peristiwa yang diurutkan dalam waktu, mewakili perubahan dalam beberapa proses sepanjang waktu. Misalnya saja detak jantung per hari atau jumlah proses dalam sistem. Segala sesuatu yang memberi waktu berdetak dengan beberapa dimensi adalah deret waktu:

Sebagian besar kejadian seperti ini berasal dari pemantauan. Ini tidak hanya memantau web, tetapi juga perangkat nyata: mobil, sistem industri, IOT, pabrik atau taksi tak berawak, yang bagasinya sudah dimasukkan Yandex KlikRumah-server.

Misalnya ada perusahaan yang mengumpulkan data dari kapal. Setiap beberapa detik, sensor di kapal kontainer mengirimkan ratusan pengukuran berbeda. Para insinyur mempelajarinya, membuat model dan mencoba memahami seberapa efisien kapal tersebut digunakan, karena kapal kontainer tidak boleh menganggur sedetik pun. Setiap downtime berarti hilangnya uang, jadi penting untuk memprediksi rute sehingga penghentian dapat diminimalkan.

Saat ini ada pertumbuhan database khusus yang mengukur deret waktu. On line DB-Mesin Basis data yang berbeda diberi peringkat, dan Anda dapat melihatnya berdasarkan jenis:

Jenis yang paling cepat berkembang adalah rangkaian waktuS. Basis data grafik juga berkembang, namun rangkaian waktus telah tumbuh lebih cepat selama beberapa tahun terakhir. Perwakilan khas dari keluarga database ini adalah masuknyaDB, Prometheus, KDB, Skala waktuDB (dibangun di atas PostgreSQL), solusi dari Amazon. KlikRumah dapat digunakan di sini juga, dan digunakan. Izinkan saya memberi Anda beberapa contoh umum.

Salah satu pionirnya adalah perusahaan CloudFlare (CDN-pemberi). Mereka memantau mereka CDN melalui KlikRumah (DNS-permintaan, HTTP-queries) dengan beban besar - 6 juta peristiwa per detik. Semuanya berjalan lancar Kafka, pergi ke KlikRumah, yang memberikan kesempatan untuk melihat dasbor peristiwa di sistem secara real time.

Comcast - salah satu pemimpin di bidang telekomunikasi di AS: Internet, televisi digital, telepon. Mereka menciptakan sistem kendali serupa CDN di dalam Open Source proyek Kontrol Lalu Lintas Apache untuk bekerja dengan data besar Anda. KlikRumah digunakan sebagai backend untuk analitik.

percona dibangun di KlikRumah di dalam milikmu PMMuntuk menyimpan pemantauan berbagai MySQL.

Persyaratan Khusus

Basis data deret waktu memiliki persyaratan spesifiknya sendiri.

Penyisipan cepat dari banyak agen. Kami harus memasukkan data dari banyak aliran dengan sangat cepat. KlikRumah Ia melakukan ini dengan baik karena semua sisipannya tidak menghalangi. Setiap menyisipkan adalah file baru di disk, dan sisipan kecil dapat di-buffer dengan satu atau lain cara. DI DALAM KlikRumah Lebih baik memasukkan data dalam jumlah besar daripada satu baris dalam satu waktu.
Skema fleksibel. Di deret waktu kita biasanya tidak mengetahui struktur data sepenuhnya. Dimungkinkan untuk membangun sistem pemantauan untuk aplikasi tertentu, tetapi sulit menggunakannya untuk aplikasi lain. Hal ini memerlukan skema yang lebih fleksibel. KlikRumah, memungkinkan Anda melakukan ini, meskipun itu adalah basis yang diketik dengan kuat.
Penyimpanan yang efisien dan melupakan data. Biasanya di deret waktu sejumlah besar data, sehingga harus disimpan seefisien mungkin. Misalnya, di masuknyaDB kompresi yang baik adalah fitur utamanya. Namun selain menyimpan, Anda juga harus bisa “melupakan” data lama dan melakukan semacamnya pengambilan sampel bawah — penghitungan agregat secara otomatis.
Kueri cepat pada data gabungan. Terkadang menarik untuk melihat 5 menit terakhir dengan akurasi milidetik, namun pada data bulanan, granularitas menit atau detik mungkin tidak diperlukan - statistik umum sudah cukup. Dukungan semacam ini diperlukan, jika tidak, permintaan selama 3 bulan akan memakan waktu yang sangat lama untuk diselesaikan meskipun dalam KlikRumah.
Permintaan seperti "poin terakhir, pada». Ini tipikal untuk deret waktu pertanyaan: lihat pengukuran terakhir atau keadaan sistem pada saat itu t. Ini bukanlah kueri yang menyenangkan untuk database, tetapi Anda juga harus bisa menjalankannya.
Rangkaian waktu “Merekatkan”.. Deret waktu adalah deret waktu. Jika ada dua deret waktu, sering kali keduanya perlu dihubungkan dan dikorelasikan. Tidak mudah melakukan hal ini pada semua database, terutama dengan deret waktu yang tidak selaras: berikut adalah beberapa titik waktu, ada titik waktu lainnya. Boleh dibilang rata-rata, tapi tiba-tiba masih ada lubang di situ, jadi kurang jelas.

Mari kita lihat bagaimana persyaratan ini dipenuhi KlikRumah.

Skema itu

В KlikRumah skema untuk deret waktu dapat dilakukan dengan berbagai cara, tergantung pada derajat keteraturan datanya. Membangun sistem berdasarkan data reguler dapat dilakukan jika kita mengetahui semua metriknya terlebih dahulu. Misalnya, saya melakukan ini CloudFlare dengan pemantauan CDN adalah sistem yang dioptimalkan dengan baik. Anda dapat membangun sistem yang lebih umum yang memantau seluruh infrastruktur dan berbagai layanan. Dalam kasus data yang tidak teratur, kami tidak mengetahui sebelumnya apa yang kami pantau - dan ini mungkin kasus yang paling umum.

Data reguler. Kolom. Skemanya sederhana - kolom dengan tipe yang diperlukan:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Ini adalah tabel biasa yang memantau beberapa jenis aktivitas pemuatan sistem (pemakai, sistem, siaga, bagus). Sederhana dan nyaman, tetapi tidak fleksibel. Jika kita menginginkan skema yang lebih fleksibel, maka kita bisa menggunakan array.

Data tidak teratur. Array:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Struktur Bersarang adalah dua array: metrik.nama и metrik.nilai. Di sini Anda dapat menyimpan data pemantauan sewenang-wenang seperti larik nama dan larik pengukuran untuk setiap peristiwa. Untuk pengoptimalan lebih lanjut, alih-alih satu struktur seperti itu, Anda dapat membuat beberapa struktur seperti itu. Misalnya, satu untuk mengapung-nilai, yang lain - untuk int-artinya karena int Saya ingin menyimpan lebih efisien.

Namun struktur seperti itu lebih sulit diakses. Anda harus menggunakan konstruksi khusus, menggunakan fungsi khusus untuk mengeluarkan nilai indeks terlebih dahulu dan kemudian array:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Tapi itu masih bekerja cukup cepat. Cara lain untuk menyimpan data tidak beraturan adalah dengan baris.

Data tidak teratur. string. Dalam metode tradisional ini, tanpa array, nama dan nilai disimpan secara bersamaan. Jika 5 pengukuran berasal dari satu perangkat sekaligus, 000 baris akan dihasilkan dalam database:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

KlikRumah mengatasi ini - ia memiliki ekstensi khusus KlikRumah SQL. Misalnya, maxIf — fungsi khusus yang menghitung maksimum berdasarkan metrik ketika beberapa kondisi terpenuhi. Anda dapat menulis beberapa ekspresi seperti itu dalam satu permintaan dan segera menghitung nilai untuk beberapa metrik.

Mari kita bandingkan tiga pendekatan:

Detail

Di sini saya telah menambahkan "Ukuran Data Disk" untuk beberapa kumpulan data pengujian. Dalam hal kolom, kami memiliki ukuran data terkecil: kompresi maksimum, kecepatan kueri maksimum, tetapi kami membayarnya dengan harus mencatat semuanya sekaligus.

Dalam kasus array, keadaannya sedikit lebih buruk. Data masih terkompresi dengan baik dan pola tidak beraturan dapat disimpan. Tetapi KlikRumah - database berbentuk kolom, dan ketika kita mulai menyimpan semuanya dalam array, itu berubah menjadi baris pertama, dan kita membayar fleksibilitas dengan efisiensi. Untuk operasi apa pun, Anda harus membaca seluruh array ke dalam memori, kemudian menemukan elemen yang diinginkan di dalamnya - dan jika array bertambah, maka kecepatannya menurun.

Di salah satu perusahaan yang menggunakan pendekatan ini (misalnya, uber), array dipotong menjadi 128 elemen. Data dari beberapa ribu metrik dengan volume 200 TB data/hari disimpan tidak dalam satu array, tetapi dalam 10 atau 30 array dengan logika penyimpanan khusus.

Pendekatan paling sederhana adalah dengan string. Namun datanya dikompresi dengan buruk, ukuran tabelnya besar, dan bahkan ketika kueri didasarkan pada beberapa metrik, ClickHouse tidak bekerja secara optimal.

Skema hibrida

Mari kita asumsikan bahwa kita telah memilih rangkaian array. Namun jika kita tahu bahwa sebagian besar dasbor hanya menampilkan metrik pengguna dan sistem, kita juga dapat mewujudkan metrik ini ke dalam kolom dari array di tingkat tabel dengan cara ini:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Saat memasukkan KlikRumah akan secara otomatis menghitungnya. Dengan cara ini Anda dapat menggabungkan bisnis dengan kesenangan: skemanya fleksibel dan umum, tetapi kami telah mengeluarkan kolom yang paling sering digunakan. Perhatikan bahwa ini tidak memerlukan perubahan sisipan dan ETLyang terus memasukkan array ke dalam tabel. Kami baru saja melakukannya ALTER TABEL, menambahkan beberapa speaker dan kami mendapatkan skema hybrid dan lebih cepat yang dapat Anda gunakan segera.

Codec dan kompresi

Untuk deret waktu Seberapa baik Anda mengemas data itu penting karena jumlah informasinya bisa sangat besar. DI DALAM KlikRumah Ada seperangkat alat untuk mencapai efek kompresi 1:10, 1:20, dan terkadang lebih. Ini berarti 1 TB data yang belum dibongkar pada disk membutuhkan 50-100 GB. Ukuran yang lebih kecil bagus, data dapat dibaca dan diproses lebih cepat.

Untuk mencapai tingkat kompresi yang tinggi, KlikRumah mendukung codec berikut:

Contoh tabel:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Di sini kita mendefinisikan codec Delta Ganda dalam satu kasus, dalam kasus kedua - gorila, dan kami pasti akan menambahkan lebih banyak LZ4 kompresi. Akibatnya, ukuran data pada disk menjadi sangat berkurang:

Ini menunjukkan berapa banyak ruang yang digunakan oleh data yang sama, tetapi menggunakan codec dan kompresi yang berbeda:

dalam file GZIP di disk;
di ClickHouse tanpa codec, tetapi dengan kompresi ZSTD;
di ClickHouse dengan codec dan kompresi LZ4 dan ZSTD.

Terlihat bahwa tabel dengan codec memakan lebih sedikit ruang.

Ukuran penting

Tak kalah penting Выбрать tipe data yang benar:

Dalam semua contoh di atas saya menggunakan mengapung64. Namun jika kita memilih mengapung32, maka itu akan lebih baik lagi. Hal ini ditunjukkan dengan baik oleh orang-orang dari Perkona pada artikel yang ditautkan di atas. Penting untuk menggunakan tipe paling ringkas yang sesuai untuk tugas tersebut: bahkan lebih kecil untuk ukuran disk dibandingkan untuk kecepatan kueri. KlikRumah sangat sensitif terhadap hal ini.

Jika Anda bisa menggunakan int32 daripada int64, lalu mengharapkan peningkatan kinerja hampir dua kali lipat. Data memakan lebih sedikit memori, dan semua “aritmatika” bekerja lebih cepat. KlikRumah secara internal ini adalah sistem yang diketik dengan sangat ketat; ia memanfaatkan secara maksimal semua kemungkinan yang disediakan oleh sistem modern.

Agregasi dan Tampilan Terwujud

Tampilan agregasi dan materialisasi memungkinkan Anda membuat agregat untuk berbagai kesempatan:

Misalnya, Anda mungkin memiliki data awal yang tidak teragregasi, dan Anda dapat melampirkan berbagai jenis material ke data tersebut dengan penjumlahan otomatis melalui mesin khusus. PenjumlahanMergeTree (SMT). SMT adalah struktur data agregasi khusus yang menghitung agregat secara otomatis. Data mentah dimasukkan ke dalam database, dikumpulkan secara otomatis, dan dasbor dapat langsung digunakan di dalamnya.

TTL - “lupakan” data lama

Bagaimana cara “melupakan” data yang tidak diperlukan lagi? KlikRumah tahu bagaimana melakukan ini. Saat membuat tabel, Anda bisa menentukan TTL ekspresi: misalnya kita menyimpan data menit selama satu hari, data harian selama 30 hari, dan tidak pernah menyentuh data mingguan atau bulanan:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-tingkat - membagi data ke seluruh disk

Mengambil ide ini lebih jauh, data dapat disimpan KlikRumah di tempat yang berbeda. Misalkan kita ingin menyimpan data panas selama seminggu terakhir di lokal yang sangat cepat SSD, dan kami menempatkan lebih banyak data historis di tempat lain. DI DALAM KlikRumah ini sekarang mungkin:

Anda dapat mengonfigurasi kebijakan penyimpanan (kebijakan penyimpanan) Jadi KlikRumah akan secara otomatis mentransfer data setelah mencapai kondisi tertentu ke penyimpanan lain.

Tapi bukan itu saja. Pada tingkat tabel tertentu, Anda dapat menentukan aturan kapan tepatnya data masuk ke penyimpanan dingin. Misalnya, data disimpan di disk yang sangat cepat selama 7 hari, dan semua data yang lebih lama ditransfer ke disk yang lambat. Ini bagus karena memungkinkan Anda menjaga sistem pada kinerja maksimal, sekaligus mengendalikan biaya dan tidak membuang-buang uang untuk data dingin:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Peluang unik KlikRumah

Hampir dalam segala hal KlikRumah Ada "sorotan" seperti itu, tetapi diimbangi oleh eksklusivitas - sesuatu yang tidak ada di database lain. Misalnya, berikut beberapa fitur uniknya KlikRumah:

Array. Di KlikRumah dukungan yang sangat baik untuk array, serta kemampuan untuk melakukan perhitungan yang rumit pada array tersebut.
Menggabungkan Struktur Data. Ini adalah salah satu "fitur mematikan" KlikRumah. Terlepas dari kenyataan bahwa orang-orang dari Yandex mengatakan bahwa kami tidak ingin mengumpulkan data, semuanya dikumpulkan KlikRumah, karena cepat dan nyaman.
Pandangan yang Terwujud. Bersama dengan struktur data agregat, tampilan materialisasi memungkinkan Anda melakukan hal yang nyaman real-time pengumpulan.
KlikHouse SQL. Ini adalah ekstensi bahasa SQL dengan beberapa fitur tambahan dan eksklusif yang hanya tersedia di KlikRumah. Sebelumnya, hal ini seperti perluasan di satu sisi, dan kerugian di sisi lain. Sekarang hampir semua kekurangannya dibandingkan SQL 92 kami menghapusnya, sekarang hanya perpanjangan.
Lambda–ekspresi. Apakah mereka masih ada di database?
ML-mendukung. Ini tersedia di database yang berbeda, ada yang lebih baik, ada yang lebih buruk.
sumber terbuka. Kita bisa memperluas KlikRumah bersama. Sekarang di KlikRumah sekitar 500 kontributor, dan jumlah ini terus bertambah.

Pertanyaan rumit

В KlikRumah ada banyak cara berbeda untuk melakukan hal yang sama. Misalnya, Anda dapat mengembalikan nilai terakhir dari tabel dengan tiga cara berbeda CPU (ada juga yang keempat, tapi lebih eksotis).

Yang pertama menunjukkan betapa nyamannya melakukannya KlikRumah pertanyaan ketika Anda ingin memeriksanya tupel terkandung dalam subkueri. Ini adalah sesuatu yang secara pribadi sangat saya lewatkan di database lain. Jika saya ingin membandingkan sesuatu dengan subquery, maka di database lain hanya skalar yang dapat dibandingkan, tetapi untuk beberapa kolom saya perlu menulis BERGABUNG. Di KlikRumah Anda dapat menggunakan tupel:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Metode kedua melakukan hal yang sama tetapi menggunakan fungsi agregat argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В KlikRumah ada beberapa lusin fungsi agregat, dan jika Anda menggunakan kombinator, maka menurut hukum kombinatorik Anda akan mendapatkan sekitar seribu fungsi tersebut. ArgMax - salah satu fungsi yang menghitung nilai maksimum: permintaan mengembalikan nilai penggunaan_pengguna, di mana nilai maksimum tercapai dibuat di:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF BERGABUNG — “menempelkan” baris dengan waktu yang berbeda. Ini adalah fitur unik untuk database yang hanya tersedia di kdb +. Jika ada dua deret waktu dengan waktu berbeda, ASOF BERGABUNG memungkinkan Anda untuk memindahkan dan menggabungkannya dalam satu permintaan. Untuk setiap nilai dalam satu deret waktu, nilai terdekat dari deret waktu lainnya ditemukan, dan nilai tersebut dikembalikan pada baris yang sama:

Fungsi Analitik

Dalam standar SQL-2003 Anda dapat menulis seperti ini:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В KlikRumah Anda tidak dapat melakukan ini - ini tidak mendukung standar SQL-2003 dan mungkin tidak akan pernah melakukannya. Sebaliknya, di KlikRumah Merupakan kebiasaan untuk menulis seperti ini:

Saya berjanji pada lambda - ini dia!

Ini adalah analog dari kueri analitis dalam standar SQL-2003: dia menghitung selisih keduanya stempel waktu, durasi, bilangan urut - segala sesuatu yang biasanya kita anggap sebagai fungsi analitis. DI DALAM KlikRumah Kami menghitungnya melalui array: pertama kami menciutkan data ke dalam array, setelah itu kami melakukan semua yang kami inginkan pada array, dan kemudian kami mengembangkannya kembali. Ini tidak terlalu nyaman, minimal memerlukan kecintaan terhadap pemrograman fungsional, tetapi sangat fleksibel.

Fitur spesial

Selain itu, di KlikRumah banyak fungsi khusus. Misalnya, bagaimana cara menentukan berapa banyak sesi yang berlangsung secara bersamaan? Tugas pemantauan yang umum adalah menentukan beban maksimum dengan satu permintaan. DI DALAM KlikRumah Ada fungsi khusus untuk tujuan ini:

Secara umum, ClickHouse memiliki fungsi khusus untuk berbagai tujuan:

runningDifference, runningAccumulate, tetangga;
sumMap(kunci, nilai);
timeSeriesGroupSum(uid, stempel waktu, nilai);
timeSeriesGroupRateSum(uid, stempel waktu, nilai);
skewPop, skewSamp, kurtPop, kurtSamp;
DENGAN ISI / DENGAN DASI;
Regresi Linier sederhana, Regresi Linier stokastik.

Ini bukan daftar lengkap fungsinya, total ada 500-600. Petunjuk: semua fungsi di KlikRumah ada di tabel sistem (tidak semuanya didokumentasikan, tetapi semuanya menarik):

select * from system.functions order by name

KlikRumah itu menyimpan banyak informasi tentang dirinya sendiri, termasuk tabel log, query_log, log jejak, log operasi dengan blok data (bagian_log), log metrik, dan log sistem, yang biasanya ditulis ke disk. Metrik log adalah deret waktu в KlikRumah Sebenarnya KlikRumah: Basis data itu sendiri dapat berperan deret waktu database, sehingga “melahap” dirinya sendiri.

Ini juga merupakan hal yang unik - karena kami melakukan pekerjaan dengan baik deret waktu, kenapa kita tidak bisa menyimpan semua yang kita perlukan di dalam diri kita sendiri? Kami tidak membutuhkan Prometheus, kami menyimpan semuanya untuk diri kami sendiri. Terhubung grafana dan kami memantau diri kami sendiri. Namun jika KlikRumah jatuh, kita tidak akan mengetahui alasannya, jadi mereka biasanya tidak melakukan itu.

Cluster besar atau banyak cluster kecil KlikRumah

Mana yang lebih baik – satu cluster besar atau banyak ClickHouse kecil? Pendekatan tradisional untuk DWH adalah cluster besar di mana sirkuit dialokasikan untuk setiap aplikasi. Kami datang ke administrator database - beri kami diagram, dan mereka memberi kami diagram:

В KlikRumah Anda dapat melakukannya secara berbeda. Anda dapat menjadikan setiap aplikasi milik Anda sendiri KlikRumah:

Kita tidak membutuhkan monster besar itu lagi DWH dan admin yang keras kepala. Kami dapat memberikan masing-masing aplikasi miliknya sendiri KlikRumah, dan pengembang dapat melakukannya sendiri KlikRumah sangat mudah dipasang dan tidak memerlukan administrasi yang rumit:

Tapi kalau kita punya banyak KlikRumah, dan Anda harus sering menginstalnya, lalu Anda ingin mengotomatiskan proses ini. Untuk ini kita bisa, misalnya, menggunakan Kubernetes и rumah klik-operator. DI DALAM KlikHouse Kubernetes Anda dapat meletakkannya “on-click”: Saya dapat mengklik tombol, menjalankan manifes dan database siap. Saya dapat segera membuat diagram, mulai mengunggah metrik di sana, dan dalam 5 menit dasbor saya sudah siap grafana. Ini sangat mudah!

Hasilnya?

Dengan demikian, KlikRumah - ini:

Быстро. Semua orang tahu ini.
Hanya. Sedikit kontroversial, tapi menurut saya ini sulit dalam latihan, mudah dalam pertarungan. Jika Anda mengerti caranya KlikRumah berhasil, maka semuanya sangat sederhana.
Secara universal. Sangat cocok untuk skenario yang berbeda: DWH, Rangkaian Waktu, Penyimpanan Log. Tapi ternyata tidak OLTP database, jadi jangan mencoba melakukan penyisipan pendek dan membaca di sana.
Menariknya. Mungkin orang yang bekerja dengannya KlikRumah, mengalami banyak momen menarik dalam arti baik dan buruk. Misalnya, rilis baru keluar, semuanya berhenti berfungsi. Atau ketika Anda kesulitan mengerjakan suatu tugas selama dua hari, tetapi setelah mengajukan pertanyaan di obrolan Telegram, tugas tersebut terselesaikan dalam dua menit. Atau seperti di konferensi atas laporan Lesha Milovidov, tangkapan layar dari KlikRumah merusak siarannya HighLoad ++. Hal seperti ini terjadi setiap saat dan membuat hidup kita sulit. KlikRumah cerah dan menarik!

Anda dapat menonton presentasinya di sini.

Pertemuan para pengembang sistem beban tinggi yang telah lama ditunggu-tunggu di HighLoad ++ akan berlangsung pada 9 dan 10 November di Skolkovo. Terakhir, ini akan menjadi konferensi offline (walaupun dengan semua tindakan pencegahan), karena energi HighLoad++ tidak dapat dikemas secara online.

Untuk konferensi ini, kami menemukan dan menunjukkan kepada Anda kasus-kasus tentang kemampuan maksimum teknologi: HighLoad++ dulu, sekarang, dan akan menjadi satu-satunya tempat di mana Anda dapat mempelajari dalam dua hari cara kerja Facebook, Yandex, VKontakte, Google, dan Amazon.

Setelah mengadakan pertemuan tanpa henti sejak tahun 2007, tahun ini kita akan bertemu untuk yang ke-14 kalinya. Selama waktu ini, konferensi ini telah berkembang 10 kali lipat; tahun lalu, acara industri utama ini menghadirkan 3339 peserta, 165 pembicara, laporan dan pertemuan, dan 16 trek yang dijalankan secara bersamaan.
Tahun lalu ada 20 bus, 5280 liter teh dan kopi, 1650 liter minuman buah, dan 10200 botol air. Serta 2640 kilogram pangan, 16 piring, dan 000 gelas. Omong-omong, dengan uang yang diperoleh dari kertas daur ulang, kami menanam 25 bibit pohon ek :)

Anda dapat membeli tiket di sini, dapatkan berita tentang konferensi - di sini, dan berbicara di semua jejaring sosial: Telegram, Facebook, Vkontakte и Twitter.

Sumber: www.habr.com

Pindah ke ClickHouse: 3 tahun kemudian