Pindhah menyang ClickHouse: 3 taun sabanjure

Telung taun kepungkur Viktor Tarnavsky lan Alexey Milovidov saka Yandex ing panggung HighLoad++ ngandika, carane apik ClickHouse, lan carane ora alon mudhun. Lan ing tahap sabanjure ana Ал с laporan babagan pindhah menyang clickhouse saka DBMS analitis liyane lan karo kesimpulan sing clickhouse, mesthi, apik, nanging ora trep banget. Nalika ing 2016 perusahaan LifeStreet, ngendi Alexander banjur makarya, iki Ngonversi sistem analitis multi-petabyte kanggo clickhouse, iki minangka "dalan bata kuning" sing kebak bebaya sing ora dingerteni - clickhouse nalika iku katon kaya ladang ranjau.

Telung taun sabanjure clickhouse dadi luwih apik - sak iki Alexander ngedegake perusahaan Altinity, kang ora mung mbantu wong pindhah menyang clickhouse Welasan proyèk, nanging uga nambah produk dhewe bebarengan karo kolega saka Yandex. Saiki clickhouse isih ora stroll carefree, nanging ora maneh minefield.

Alexander wis nggarap sistem mbagekke wiwit 2003, ngembangaken proyek gedhe ing MySQL, Oracle и Vertica. Ing pungkasan HighLoad++ 2019 Alexander, salah siji saka pionir saka nggunakake clickhouse, marang apa DBMS iki saiki. Kita bakal sinau babagan fitur utama clickhouse: carane iku beda saka sistem liyane lan ing kasus apa iku luwih efektif kanggo nggunakake. Nggunakake conto, kita bakal katon ing laku anyar lan project-dites kanggo sistem bangunan adhedhasar clickhouse.

Retrospektif: kedadeyan 3 taun kepungkur

Telung taun kepungkur kita nransfer perusahaan LifeStreet ing clickhouse saka database analitis liyane, lan migrasi analytics jaringan iklan katon kaya iki:

• Juni 2016. Ing Mbukak sumber muncul clickhouse lan proyek kita diwiwiti;
• Agustus. Bukti Konsep: jaringan iklan gedhe, infrastruktur lan 200-300 terabyte data;
• Oktober. data produksi pisanan;
• Desember. Beban produk lengkap yaiku 10-50 milyar acara saben dina.
• Juni 2017. Migrasi sukses pangguna kanggo clickhouse, 2,5 petabyte data ing kluster 60 server.

Sajrone proses migrasi, ana pangerten sing tuwuh clickhouse minangka sistem sing apik sing nyenengake, nanging iki minangka proyek internal Yandex. Mulane, ana nuansa: Yandex bakal pisanan ngatasi pelanggan internal dhewe lan mung banjur karo masyarakat lan kabutuhan pangguna eksternal, lan ClickHouse banjur ora tekan tingkat perusahaan ing akeh wilayah fungsional. Pramila kita ngedegake Altinity ing Maret 2017 kanggo nggawe clickhouse malah luwih cepet lan luwih trep ora mung kanggo Yandex, nanging uga kanggo pangguna liyane. Lan saiki kita:

• We olahraga lan mbantu mbangun solusi adhedhasar clickhouse supaya pelanggan ora nemu alangan, lan supaya solusi pungkasanipun bisa digunakake;
• Kita nyedhiyakake dhukungan 24/7 clickhouse- panginstalan;
• Kita ngembangake proyek ekosistem dhewe;
• Kita aktif komitmen kanggo awake dhewe clickhouse, nanggapi panjalukan saka pangguna sing pengin ndeleng fitur tartamtu.

Lan mesthi, kita bantuan karo pindhah menyang clickhouse с MySQL, Vertica, Oracle, Greenplum, Redshift lan sistem liyane. Kita wis melu macem-macem gerakan, lan kabeh wis sukses.

Kok pindhah menyang clickhouse

Ora alon-alon! Iki minangka alesan utama. clickhouse - database cepet banget kanggo macem-macem skenario:

Kuotasi acak saka wong sing wis kerja karo wong suwe clickhouse.

Skalabilitas. Ing sawetara database liyane sampeyan bisa entuk kinerja apik ing siji Piece saka hardware, nanging clickhouse sampeyan bisa skala ora mung vertikal, nanging uga horisontal, mung kanthi nambah server. Kabeh ora bisa lancar kaya sing dikarepake, nanging bisa. Sampeyan bisa nggedhekake sistem nalika bisnis sampeyan tuwuh. Penting yen kita ora diwatesi karo solusi saiki lan mesthi ana potensial kanggo pangembangan.

Portabilitas. Ora ana lampiran siji bab. Contone, karo Amazon RedShift Susah pindah nang endi wae. A clickhouse sampeyan bisa nginstal ing laptop, server, masang menyang maya, pindhah menyang Kubernetes - ora ana watesan ing operasi infrastruktur. Iki trep kanggo kabeh wong, lan iki minangka kauntungan gedhe sing ora bisa dibanggakake dening akeh database liyane sing padha.

Keluwesan. clickhouse ora mandheg ing siji bab, contone, Yandex.Metrica, nanging berkembang lan digunakake ing proyèk lan industri liyane lan liyane. Bisa ditambahi kanthi nambah kemampuan anyar kanggo ngatasi masalah anyar. Contone, dipercaya yen nyimpen log ing basis data minangka prilaku sing ala, mula dheweke teka Elasticsearch. Nanging thanks kanggo keluwesan clickhouse, sampeyan uga bisa nyimpen log ing, lan asring iki malah luwih apik tinimbang ing Elasticsearch - ing clickhouse iki mbutuhake 10 kaping kurang wesi.

Gratis Open Source. Sampeyan ora kudu mbayar apa-apa. Ora perlu rembugan ijin kanggo nginstal sistem ing laptop utawa server. Ora ana biaya sing didhelikake. Ing wektu sing padha, ora ana teknologi database Open Source liyane sing bisa bersaing kanthi cepet clickhouse. MySQL, MariaDB, Greenplum - kabeh padha luwih alon.

Komunitas, drive lan fun... Duwe clickhouse komunitas banget: meetups, chats lan Alexey Milovidov, sing daya kita kabeh karo energi lan optimisme.

Pindhah menyang ClickHouse

Lungo nang clickhouse sakperangan alesan, sampeyan mung butuh telung perkara:

• Ngerti watesan clickhouse lan apa ora cocok kanggo.
• Njupuk kauntungan teknologi lan kekuatan paling gedhe.
• Eksperimen. Malah ngerti cara kerjane clickhouse, iku ora tansah bisa kanggo prédhiksi nalika iku bakal luwih cepet, nalika iku bakal alon, nalika iku bakal luwih apik, lan nalika iku bakal luwih elek. Dadi coba.

Masalah obah

Mung ana siji "nanging": yen sampeyan pindhah menyang clickhouse saka liyane, banjur biasane soko dadi salah. Kita wis biasa karo sawetara praktik lan perkara sing bisa digunakake ing basis data favorit. Contone, sapa wae sing kerja SQL-database nganggep set fungsi ing ngisor iki wajib:

• transaksi;
• alangan;
• konsistensi;
• indeks;
• UPDATE / Mbusak;
• NULLs;
• milidetik;
• jinis cast otomatis;
• pirang-pirang gabung;
• partisi sewenang-wenang;
• piranti manajemen cluster.

Rekrutmen wajib, nanging telung taun kepungkur ing clickhouse Ora ana fungsi iki kasedhiya! Saiki kurang saka setengah saka apa sing durung dileksanakake tetep: transaksi, alangan, Konsistensi, milliseconds lan jinis casting.

Lan sing utama yaiku ing clickhouse sawetara laku standar lan pendekatan ora bisa utawa bisa beda saka kita digunakake kanggo. Kabeh sing katon ing clickhouse, cocog karo "Cara ClickHouse", i.e. fungsi beda saka database liyane. Tuladhane:

• Indeks ora dipilih, nanging dilewati.
• UPDATE / Mbusak ora sinkron, nanging ora sinkron.
• Ana pirang-pirang gabungan, nanging ora ana perancang pitakon. Kepiye cara dileksanakake umume ora jelas banget kanggo wong saka jagad database.

ClickHouse Scripts

Ing taun 1960, sawijining matématikawan Amérika asal Hungaria Wigner EP nulis artikel"Efektivitas matematika sing ora wajar ing ilmu alam” (“Keefektifan Matematika sing Ora Bisa Dimengerteni ing Ilmu Pengetahuan Alam”) manawa jagad ing saubengé kita ana alesan sing diterangake kanthi apik dening hukum matematika. Matematika minangka ilmu abstrak, lan hukum fisik sing ditulis ing wangun matematika ora pati penting, lan Wigner EP ditekan sing iki aneh banget.

Saka sudut pandangku, clickhouse - strangeness padha. Kanggo rephrase Wigner, kita bisa ngomong iki: efficiency inconceivable punika nggumunake clickhouse ing macem-macem aplikasi analitis!

Contone, ayo njupuk Gudang Data Real-Time, ing ngendi data dimuat meh terus-terusan. Kita pengin nampa panjalukan saka wektu tundha kaping pindho. Mangga - gunakake clickhouse, amarga iki skenario sing dirancang kanggo. clickhouse Iki persis cara digunakake ora mung ing web, nanging uga ing marketing lan analytics finansial, AdTech, ugi Deteksi penipuann. ING Real-time Data Warehouse rencana kabentuk Komplek kaya "star" utawa "snowflake" digunakake, akeh tabel karo NGGABUNGA (kadhangkala kaping pirang-pirang), lan data biasane disimpen lan diganti ing sawetara sistem.

Ayo njupuk skenario liyane - Time Series: ngawasi piranti, jaringan, statistik panggunaan, Internet of Things. Kene kita nemokke acara cukup prasaja dhawuh ing wektu. clickhouse iki ora Originally dikembangaké kanggo iki, nanging wis nuduhake dhewe kanggo bisa uga, pramila perusahaan gedhe nggunakake clickhouse minangka gudang kanggo informasi ngawasi. Kanggo njelajah apa iku cocok clickhouse kanggo time-seri, kita digawe pathokan adhedhasar pendekatan lan asil InfluxDB и TimescaleDB - khusus wektu-seri basis data. Jebule, sing clickhouse, sanajan tanpa optimalisasi kanggo tugas kasebut, menang ing lapangan manca:

В wektu-seri Biasane tabel sempit digunakake - sawetara kolom cilik. Akeh data bisa teka saka ngawasi-yuta rekaman per detik-lan biasane teka ing bledosan cilik (nyata-wektu streaming). Mulane, skrip sisipan sing beda-beda dibutuhake, lan pitakon kasebut duwe spesifik dhewe.

Log Manajemen. Nglumpukake log menyang database biasane ala, nanging clickhouse iki bisa rampung karo sawetara komentar minangka diterangake ing ndhuwur. Akeh perusahaan nggunakake clickhouse persis kanggo maksud iki. Ing kasus iki, kita nggunakake meja sudhut warata ngendi kita nyimpen kabeh log (contone, ing wangun JSON), utawa dipotong dadi potongan. Data biasane dimuat ing batch gedhe (file), lan kita nelusuri sawetara lapangan.

Kanggo saben fungsi kasebut, basis data khusus biasane digunakake. clickhouse siji bisa nindakake kabeh lan uga supaya outperforms wong. Ayo saiki ndeleng luwih cedhak wektu-seri skenario, lan carane "masak" bener clickhouse kanggo skenario iki.

Time-Series

Saiki iki minangka skenario utama clickhouse dianggep solusi standar. Time-seri yaiku sakumpulan acara sing diurutake ing wektu, sing nuduhake owah-owahan ing sawetara proses liwat wektu. Contone, iki bisa dadi detak jantung saben dina utawa jumlah proses ing sistem. Kabeh sing menehi wektu ticks karo sawetara dimensi wektu-seri:

Umume jinis acara kasebut asale saka pemantauan. Iki bisa uga ora mung ngawasi web, nanging uga piranti nyata: mobil, sistem industri, IoT, pabrik utawa taksi tanpa awak, ing bagasi sing wis dipasang Yandex clickhouse-server.

Contone, ana perusahaan sing ngumpulake data saka kapal. Saben sawetara detik, sensor ing kapal kontainer ngirim atusan ukuran beda. Insinyur nyinaoni, mbangun model lan nyoba ngerti carane efisien kapal kasebut digunakake, amarga kapal kontainer ora kudu nganggur sanajan sedetik. Sembarang downtime iku mundhut dhuwit, dadi penting kanggo prédhiksi rute supaya stoppages minimal.

Saiki ana wutah database khusus sing ngukur wektu-seri. Ing situs DB-Mesin Basis data sing beda-beda ana peringkat, lan sampeyan bisa ndeleng miturut jinis:

Tipe sing paling cepet tuwuh yaiku seri wektus. Database grafik uga akeh, nanging seri wektus wis akeh luwih cepet liwat sawetara taun kepungkur. Perwakilan khas kulawarga database iki yaiku InfluxDB, Prometheus, KDB, TimescaleDB (dibangun ing PostgreSQL), solusi saka Amazon. clickhouse bisa digunakake kene uga, lan digunakake. Ayo kula menehi sawetara conto umum.

Salah sawijining pionir yaiku perusahaan cloudflare (CDN- panyedhiya). Dheweke ngawasi dheweke CDN liwat clickhouse (DNS-njaluk, HTTP-queries) kanthi beban gedhe - 6 yuta acara per detik. Kabeh dadi liwat Kafka, tindak menyang clickhouse, sing menehi kesempatan kanggo ndeleng dashboard acara ing sistem ing wektu nyata.

Comcast - salah sawijining pimpinan telekomunikasi ing AS: Internet, televisi digital, telephony. Dheweke nggawe sistem kontrol sing padha CDN ing Open Source saka project Kontrol Lalu Lintas Apache kanggo nggarap data gedhe sampeyan. clickhouse digunakake minangka backend kanggo analytics.

percona dibangun ing clickhouse nang Panjenengan PMMkanggo nyimpen ngawasi saka macem-macem MySQL.

Syarat Khusus

Basis data seri wektu duwe syarat khusus dhewe.

• Selipan cepet saka akeh agen. Kita kudu nglebokake data saka akeh aliran kanthi cepet. clickhouse Iki ditindakake kanthi apik amarga kabeh sisipan kasebut ora diblokir. Sembarang insert iku file anyar ing disk, lan sisipan cilik bisa buffered ing salah siji cara utawa liyane. ING clickhouse Luwih becik nglebokake data ing batch gedhe tinimbang siji baris sekaligus.
• Skema fleksibel. ing wektu-seri kita biasane ora ngerti struktur data rampung. Sampeyan bisa mbangun sistem ngawasi kanggo aplikasi tartamtu, nanging banjur angel digunakake kanggo aplikasi liyane. Iki mbutuhake skema sing luwih fleksibel. clickhouse, ngidini sampeyan nindakake iki, sanajan iku basa diketik banget.
• Panyimpenan sing efisien lan lali data. Biasane ing wektu-seri jumlah data sing akeh banget, mula kudu disimpen kanthi efisien. Contone, ing InfluxDB komprèsi apik iku fitur utama. Nanging saliyane nyimpen, sampeyan uga kudu bisa "lali" data lawas lan nindakake sawetara jinis downsampling - pancacahan otomatis aggregates.
• Pitakon cepet babagan data sing dikumpulake. Kadhangkala menarik kanggo ndeleng 5 menit pungkasan kanthi akurasi milidetik, nanging ing menit data saben wulan utawa granularitas detik bisa uga ora dibutuhake - statistik umum cukup. Dhukungan saka jenis iki perlu, yen panjalukan kanggo 3 sasi bakal njupuk wektu dawa banget kanggo ngrampungake malah ing clickhouse.
• Njaluk kaya"titik pungkasan, minangka saka». Iki khas kanggo wektu-seri pitakon: katon ing pangukuran pungkasan utawa negara sistem ing wayahe ing wektu t. Iki dudu pitakon sing nyenengake kanggo database, nanging sampeyan uga kudu bisa nindakake.
• "Gluing" seri wektu. Time-seri yaiku seri wektu. Yen ana rong seri wektu, asring kudu disambungake lan digandhengake. Iku ora trep kanggo nindakake iki ing kabeh database, utamané karo unaligned seri wektu: kene sawetara titik wektu, ana liyane. Sampeyan bisa nimbang rata-rata, nanging dumadakan isih bakal ana bolongan, supaya ora cetha.

Ayo ndeleng kepiye syarat kasebut ditindakake clickhouse.

Skema

В clickhouse skema kanggo wektu-seri bisa ditindakake kanthi cara sing beda-beda, gumantung saka tingkat keteraturan data. Sampeyan bisa mbangun sistem ing data biasa nalika kita ngerti kabeh metrik ing advance. Contone, aku nindakake iki cloudflare karo ngawasi CDN punika sistem uga optimized. Sampeyan bisa mbangun sistem sing luwih umum sing ngawasi kabeh infrastruktur lan macem-macem layanan. Ing kasus data sing ora duwe aturan baku, kita ora ngerti sadurunge apa sing dipantau - lan iki bisa uga kasus sing paling umum.

Data biasa. Kolom. Skema kasebut prasaja - kolom kanthi jinis sing dibutuhake:

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);

Iki minangka tabel biasa sing ngawasi sawetara jinis kegiatan loading sistem (user, sistem, Meneng, becik). Prasaja lan trep, nanging ora fleksibel. Yen kita pengin skema sing luwih fleksibel, mula kita bisa nggunakake array.

Data ora teratur. Arrays:

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 Susuh ana rong susunan: metrics.name и metrik.nilai. Ing kene sampeyan bisa nyimpen data pemantauan sing sewenang-wenang minangka macem-macem jeneng lan macem-macem pangukuran kanggo saben acara. Kanggo optimasi luwih, tinimbang siji struktur kasebut, sampeyan bisa nggawe sawetara. Contone, siji kanggo ngawang-nilai, liyane - kanggo int- tegese amarga int Aku pengin nyimpen luwih efisien.

Nanging struktur kasebut luwih angel diakses. Sampeyan kudu nggunakake konstruksi khusus, nggunakake fungsi khusus kanggo narik nilai indeks lan banjur array:

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

Nanging isih dianggo cukup cepet. Cara liya kanggo nyimpen data sing ora teratur yaiku kanthi baris.

Data ora teratur. strings. Ing cara tradisional iki, tanpa susunan, jeneng lan nilai disimpen bebarengan. Yen 5 pangukuran teka saka siji piranti bebarengan, 000 baris digawe ing basis data:

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', ...)

clickhouse copes karo iki - wis ekstensi khusus clickhouse SQL. Contone, maxYen - fungsi khusus sing ngetung maksimum dening metrik nalika sawetara kondisi wis ketemu. Sampeyan bisa nulis sawetara ekspresi kasebut ing siji panjalukan lan langsung ngetung nilai kanggo sawetara metrik.

Ayo mbandhingake telung pendekatan:

Детали

Ing kene aku wis nambahake "Ukuran Data Disk" kanggo sawetara set data test. Ing kasus kolom, kita duwe ukuran data paling cilik: kompresi maksimum, kacepetan pitakon maksimum, nanging mbayar kanthi kudu ngrekam kabeh bebarengan.

Ing kasus array, kabeh luwih elek. Data kasebut isih dikompres kanthi apik lan pola sing ora teratur bisa disimpen. Nanging clickhouse - database columnar, lan nalika kita miwiti nyimpen kabeh ing Uploaded, dadi siji baris, lan kita mbayar keluwesan karo efficiency. Kanggo operasi apa wae, sampeyan kudu maca kabeh array menyang memori, banjur temokake unsur sing dipengini - lan yen larik mundhak, kacepetan bakal mudhun.

Ing salah sawijining perusahaan sing nggunakake pendekatan iki (contone, Uber), array dipotong dadi potongan 128 unsur. Data saka sawetara ewu metrik kanthi volume 200 TB data / dina disimpen ora ing siji larik, nanging ing 10 utawa 30 larik kanthi logika panyimpenan khusus.

Pendekatan sing paling gampang yaiku nganggo senar. Nanging data kasebut kurang dikompres, ukuran meja gedhe, lan sanajan pitakon adhedhasar sawetara metrik, ClickHouse ora bisa digunakake kanthi optimal.

Skema hibrida

Ayo nganggep yen kita wis milih sirkuit array. Nanging yen kita ngerti manawa umume dashboard mung nuduhake metrik pangguna lan sistem, kita uga bisa nggawe metrik kasebut dadi kolom saka larik ing tingkat tabel kanthi cara iki:

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);

Nalika nglebokake clickhouse bakal ngetung kanthi otomatis. Kanthi cara iki, sampeyan bisa nggabungake bisnis kanthi kesenengan: skema kasebut fleksibel lan umum, nanging kita narik kolom sing paling kerep digunakake. Elinga yen iki ora mbutuhake ngganti insert lan ETLkang terus nglebokake susunan menyang meja. Kita mung nindakake Ganti tabel, nambahake sawetara pamicara lan entuk skema hibrida lan luwih cepet sing bisa langsung digunakake.

Codecs lan komprèsi

Kanggo wektu-seri Penting banget yen sampeyan ngemas data amarga jumlah informasi bisa akeh banget. ING clickhouse Ana sawetara alat kanggo entuk efek kompresi 1:10, 1:20, lan kadhangkala luwih akeh. Iki tegese 1 TB data unpacked ing disk njupuk munggah 50-100 GB. Ukuran sing luwih cilik apik, data bisa diwaca lan diproses luwih cepet.

Kanggo entuk tingkat kompresi sing dhuwur, clickhouse ndhukung codec ing ngisor iki:

Tuladha 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);

Kene kita nemtokake codec DoubleDelta ing siji kasus, ing kaloro - Gorilla, lan kita mesthi bakal nambah liyane LZ4 komprèsi. Akibaté, ukuran data ing disk suda banget:

Iki nuduhake pira papan sing digunakake kanggo data sing padha, nanging nggunakake codec lan kompresi sing beda:

• ing file GZIP ing disk;
• ing ClickHouse tanpa codec, nanging kanthi kompresi ZSTD;
• ing ClickHouse kanthi codec lan kompresi LZ4 lan ZSTD.

Bisa dideleng manawa tabel kanthi codec njupuk papan sing luwih sithik.

Urip ukuran

Ora kurang penting milih jinis data sing bener:

Ing kabeh conto ing ndhuwur aku digunakake Ngambang64. Nanging yen kita milih Ngambang32, banjur sing bakal luwih apik. Iki uga dituduhake dening wong lanang saka Perkona ing artikel sing disambung ing ndhuwur. Penting kanggo nggunakake jinis paling kompak sing cocok kanggo tugas: malah kurang kanggo ukuran disk saka kanggo kacepetan pitakonan. clickhouse sensitif banget iki.

Yen sampeyan bisa nggunakake ing32 tinimbang ing64, banjur nyana mundhak meh pindho ing kinerja. Data njupuk munggah memori kurang, lan kabeh "aritmetika" dianggo luwih cepet. clickhouse njero iku sistem banget strictly diketik; iku ndadekake maksimum nggunakake kabeh kemungkinan sing sistem modern nyedhiyani.

Agregasi lan Ndeleng Materialized

Tampilan agregasi lan materialisasi ngidini sampeyan nggawe agregat kanggo macem-macem kesempatan:

Contone, sampeyan bisa uga duwe data sumber non-dikumpulake, lan sampeyan bisa masang macem-macem tampilan materialized kanggo wong-wong mau kanthi penjumlahan otomatis liwat mesin khusus. SummingMergeTree (SMT). SMT punika struktur data aggregating khusus sing ngetung aggregates otomatis. Data mentah dilebokake ing basis data, dikumpulake kanthi otomatis, lan dashboard bisa langsung digunakake.

TTL - "lali" data lawas

Carane "lali" data sing ora perlu maneh? clickhouse ngerti carane nindakake iki. Nalika nggawe tabel, sampeyan bisa nemtokake TTL ekspresi: contone, kita nyimpen data menit sedina, data saben dina kanggo 30 dina, lan ora tau ndemek data mingguan utawa saben wulan:

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 undakan - dibagi data antarane disk

Njupuk idea iki luwih, data bisa disimpen ing clickhouse ing macem-macem panggonan. Upaminipun kita pengin nyimpen data panas kanggo minggu pungkasan ing lokal banget cepet SSD, lan kita sijine data sajarah liyane ing panggonan liyane. ING clickhouse iki saiki bisa:

Sampeyan bisa ngatur kabijakan panyimpenan (privasi panyimpenan) Dadi clickhouse bakal kanthi otomatis nransfer data nalika tekan kondisi tartamtu kanggo panyimpenan liyane.

Nanging ora mung kuwi. Ing tingkat tabel tartamtu, sampeyan bisa nemtokake aturan kanggo persis nalika data dadi menyang panyimpenan kadhemen. Contone, data disimpen ing disk sing cepet banget suwene 7 dina, lan kabeh sing luwih lawas ditransfer menyang sing alon. Iki apik amarga ngidini sampeyan njaga sistem kanthi kinerja maksimal, nalika ngontrol biaya lan ora mbuwang dhuwit kanggo data kadhemen:

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

Fitur unik clickhouse

Ing meh kabeh clickhouse Ana "sorotan", nanging diimbangi dening eksklusivitas - sing ora ana ing database liyane. Contone, ana sawetara fitur unik clickhouse:

• Susunan. ing clickhouse support apik banget kanggo susunan, uga kemampuan kanggo nindakake petungan Komplek ing wong.
• Nglumpukake Struktur Data. Iki minangka salah sawijining "fitur pembunuh" clickhouse. Senadyan kasunyatan manawa wong lanang saka Yandex ujar manawa kita ora pengin nglumpukake data, kabeh dikumpulake ing clickhouse, amarga cepet lan trep.
• Views Materialized. Bebarengan karo struktur data aggregating, tampilan materialized ngijini sampeyan kanggo nggawe trep nyata-wektu nglumpukake.
• KlikHouse SQL. Iki minangka ekstensi basa SQL karo sawetara fitur tambahan lan eksklusif sing mung kasedhiya ing clickhouse. Sadurunge, iku kaya expansion ing tangan siji, lan kerugian ing sisih liyane. Saiki meh kabeh cacat dibandhingake karo SQL 92 kita dibusak, saiki mung extension.
• lambda– ekspresi. Apa dheweke isih ana ing database apa wae?
• ML-nyokong. Iki kasedhiya ing macem-macem database, sawetara luwih apik, sawetara luwih elek.
• mbukak sumber. Kita bisa nggedhekake clickhouse bebarengan. Saiki ing clickhouse bab 500 kontributor, lan nomer iki saya akeh.

Pitakonan angel

В clickhouse ana macem-macem cara kanggo nindakake perkara sing padha. Contone, sampeyan bisa bali Nilai pungkasan saka Tabel ing telung cara kanggo CPU (ana uga sing kaping papat, nanging luwih endah).

Kang pisanan nuduhake carane trep kanggo nindakake ing clickhouse pitakon nalika sampeyan pengin mriksa tuple ana ing subquery. Iki soko sing aku pribadi tenan ora kejawab ing database liyane. Yen aku pengin mbandhingake soko karo subquery, banjur ing database liyane mung skalar bisa dibandhingake karo, nanging kanggo sawetara kolom aku kudu nulis. NGGABUNGA. ing clickhouse sampeyan bisa nggunakake tuple:

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

Cara kapindho nindakake perkara sing padha nanging nggunakake fungsi agregat argMax:

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

В clickhouse ana sawetara rolas fungsi agregat, lan yen sampeyan nggunakake combinator, banjur miturut hukum kombinatorik sampeyan bakal entuk babagan sewu. ArgMax - salah siji saka fungsi sing ngetung Nilai maksimum: request ngasilake Nilai usage_user, ing ngendi nilai maksimum wis tekan digawe_ing:

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

ASOF gabung - "gluing" larik karo kaping beda. Iki minangka fitur unik kanggo database sing mung kasedhiya ing kdb+. Yen ana rong seri wektu kanthi wektu sing beda, ASOF gabung ngijini sampeyan kanggo mindhah lan nggabung ing siji panjalukan. Kanggo saben nilai ing siji seri wektu, nilai paling cedhak ing liyane ditemokake, lan padha bali ing baris sing padha:

Fungsi Analitik

Ing standar SQL-2003 sampeyan bisa nulis kaya iki:

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;

В clickhouse Sampeyan ora bisa nindakake - ora ndhukung standar SQL-2003 lan mbokmenawa ora bakal nindakake. Nanging, ing clickhouse Biasane nulis kaya mangkene:

Aku janji lambdas - kene padha!

Iki minangka analog saka pitakon analitis ing standar SQL-2003: dheweke ngetung prabédan antarane loro stempel wektu, durasi, nomer ordinal - kabeh sing biasane kita nimbang fungsi analitis. ING clickhouse Kita ngetung liwat array: pisanan kita ambruk data menyang Uploaded, sawise kita nindakake kabeh kita pengin ing Uploaded, lan banjur kita nggedhekake maneh. Iku ora trep banget, mbutuhake katresnan saka program fungsi ing minimal, nanging banget fleksibel.

Fitur Khusus

Kajaba iku, ing clickhouse akeh fungsi khusus. Contone, kepiye carane nemtokake pirang-pirang sesi sing ditindakake bebarengan? Tugas ngawasi khas yaiku nemtokake beban maksimal kanthi siji panyuwunan. ING clickhouse Ana fungsi khusus kanggo tujuan iki:

Umumé, ClickHouse nduweni fungsi khusus kanggo macem-macem tujuan:

• runningDifference, runningAccumulate, pepadhamu;
• sumMap(kunci, nilai);
• timeSeriesGroupSum(uid, timestamp, nilai);
• timeSeriesGroupRateSum(uid, timestamp, nilai);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH ISI / WITH TIES;
• SimpleLinearRegression, StochasticLinearRegression.

Iki dudu dhaptar lengkap fungsi, ana 500-600 total. Petunjuk: kabeh fungsi ing clickhouse ana ing tabel sistem (ora kabeh didokumentasikake, nanging kabeh menarik):

select * from system.functions order by name

clickhouse iku nyimpen akèh informasi bab dhewe, kalebu tabel log, query_log, trace log, log operasi kanthi blok data (bagean_log), log metrik, lan log sistem, sing biasane ditulis ing disk. Log metrik punika wektu-seri в clickhouse nyatane clickhouse: Database dhewe bisa muter peran wektu-seri database, mangkono "devouring" dhewe.

Iki uga unik - amarga kita nindakake pakaryan sing apik wektu-seri, kenapa kita ora bisa nyimpen kabeh sing dibutuhake ing awake dhewe? Kita ora perlu Prometheus, kita nyimpen kabeh kanggo awake dhewe. Nyambung Grafana lan kita ngawasi dhéwé. Nanging, yen clickhouse tiba, kita ora bakal weruh apa, supaya padha biasane ora nindakaken.

Kluster gedhe utawa akeh cilik clickhouse

Apa sing luwih apik - siji kluster gedhe utawa akeh ClickHouses cilik? Pendekatan tradisional kanggo DWH iku kluster gedhe kang sirkuit diparengake kanggo saben aplikasi. Kita teka menyang administrator database - menehi kita diagram, lan padha menehi siji:

В clickhouse sampeyan bisa nindakake iku beda. Sampeyan bisa nggawe saben aplikasi dhewe clickhouse:

Kita ora butuh sing gedhe banget DWH lan admin sing ora bisa ditindakake. Kita bisa menehi saben aplikasi dhewe clickhouse, lan pangembang bisa nindakake dhewe, wiwit clickhouse gampang banget kanggo nginstal lan ora mbutuhake administrasi rumit:

Nanging yen kita duwe akeh clickhouse, lan sampeyan kudu kerep nginstal, banjur sampeyan pengin ngotomatisasi proses iki. Kanggo iki kita bisa, contone, nggunakake Kubernetes и clickhouse-operator. ING Kubernetes ClickHouse sampeyan bisa sijine iku "on-klik": Aku bisa klik tombol, mbukak manifest lan database siap. Aku bisa langsung nggawe diagram, miwiti ngunggah metrik ing kana, lan ing 5 menit aku wis siap dashboard Grafana. Iku prasaja banget!

Apa ing pungkasan?

Supaya clickhouse - Iki:

• Cepet. Kabeh wong ngerti iki.
• Cukup. A sethitik kontrovèrsial, nanging aku pracaya iku angel ing latihan, gampang ing pertempuran. Yen sampeyan ngerti carane clickhouse kerjane, banjur kabeh iku banget prasaja.
• Universitas. Cocog kanggo macem-macem skenario: DWH, Time Series, Log Storage. Nanging ora OLTP database, supaya ora nyoba kanggo nindakake sisipan singkat lan maca ana.
• Menarik. Mbokmenawa sing nggarap clickhouse, ngalami akeh wektu menarik ing pangertèn apik lan ala. Contone, rilis anyar metu, kabeh mandheg. Utawa nalika sampeyan berjuang karo tugas sajrone rong dina, nanging sawise takon ing obrolan Telegram, tugas kasebut dirampungake sajrone rong menit. Utawa kaya ing konferensi ing laporan Lesha Milovidov, gambar saka clickhouse ngrusak siaran HighLoad++. Kahanan kaya mengkono tansah kelakon lan ndadekake urip kita angel. clickhouse padhang lan menarik!

Sampeyan bisa nonton presentation kene.

Rapat sing ditunggu-tunggu para pangembang sistem beban dhuwur ing HighLoad++ bakal ditindakake ing 9 lan 10 November ing Skolkovo. Pungkasan, iki bakal dadi konferensi offline (sanajan kanthi kabeh pancegahan), amarga energi HighLoad ++ ora bisa dikemas online.

Kanggo konferensi kasebut, kita nemokake lan nuduhake sampeyan kasus babagan kemampuan maksimal teknologi: HighLoad ++ ana, lan bakal dadi siji-sijine papan ing ngendi sampeyan bisa sinau ing rong dina carane Facebook, Yandex, VKontakte, Google lan Amazon bisa digunakake.

Sampun ngawontenaken patemon tanpa gangguan wiwit taun 2007, ing taun punika kita badhe patemon kaping 14. Sajrone wektu kasebut, konferensi kasebut wis tuwuh kaping 10; taun kepungkur, acara industri utama nglumpukake 3339 peserta, 165 pamicara, laporan lan rapat, lan 16 trek mlaku bebarengan.
Taun kepungkur ana 20 bus, 5280 liter teh lan kopi, 1650 liter ombenan woh lan 10200 botol banyu. Lan panganan liyane 2640 kilogram, piring 16 lan cangkir 000. Ngomong-ngomong, kanthi dhuwit sing ditampa saka kertas daur ulang, kita nandur 25 bibit ek :)

Sampeyan bisa tuku tiket kene, njaluk warta babagan konferensi - kene, lan ngobrol ing kabeh jaringan sosial: Telegram, Facebook, Vkontakte и Twitter.

Source: www.habr.com