Dina April, insinyur Avito ngumpul pikeun rapat online sareng pamekar ClickHouse utama Alexey Milovidov sareng Kirill Shvakov, pamekar Golang ti Integros. Urang bahas kumaha urang ngagunakeun sistem manajemen database na naon kasusah urang sapatemon.
Dumasar rapat, kami geus disusun hiji artikel kalawan waleran ahli 'pikeun patarosan urang jeung panongton ngeunaan cadangan, resharding data, kamus éksternal, supir Golang sarta ngamutahirkeun versi ClickHouse. Éta tiasa mangpaat pikeun pamekar anu parantos aktip damel sareng Yandex DBMS sareng kabetot dina ayeuna sareng ka hareup. Sacara standar, jawaban anu ku Alexey Milovidov, iwal mun ditulis disebutkeun.
Ati-ati, aya seueur téks dina potongan. Kami ngarepkeun eusi sareng patarosan bakal ngabantosan anjeun napigasi.
eusi
Upami anjeun henteu hoyong maca téks, anjeun tiasa ningali rekaman rapat-rapat . Timecodes aya dina komentar kahiji handapeun video.
ClickHouse terus diropéa, tapi data urang henteu. Naon anu kudu dipigawé ngeunaan eta?
ClickHouse terus diropéa, sarta data urang, nu ieu dioptimalkeun final diolah, teu diropéa tur aya dina salinan cadangan.
Anggap urang ngagaduhan masalah sareng datana leungit. Urang mutuskeun pikeun mulangkeun, sarta tétéla yén partitions heubeul, nu disimpen dina server cadangan, pisan béda ti versi ayeuna dipaké ClickHouse. Naon anu kudu dipigawé dina kaayaan kitu, sarta éta mungkin?
Hiji kaayaan dimana anjeun malikkeun data tina cadangan dina format heubeul, tapi teu nyambung ka versi anyar, mustahil. Kami mastikeun yén format data dina ClickHouse salawasna tetep cocog ka tukang. Ieu langkung penting tibatan kasaluyuan mundur dina fungsionalitas upami paripolah sababaraha fungsi anu jarang dianggo parantos robih. Versi anyar ClickHouse kedah salawasna tiasa maca data anu disimpen dina disk. Ieu hukum.
Naon prakték pangalusna ayeuna keur nyadangkeun data ti ClickHouse?
Kumaha carana nyieun cadangan, nyokot kana akun yén kami geus ngaoptimalkeun operasi final, database badag terabytes, sarta data anu diropéa, sebutkeun, salila tilu poé panungtungan, lajeng euweuh prosedur lumangsung?
Urang tiasa ngadamel solusi sorangan sareng nyerat dina bash: kumpulkeun salinan cadangan ieu ku cara sapertos kitu. Panginten teu aya anu kedah dikruk, sareng sapédah parantos diciptakeun lami?
Hayu urang mimitian ku prakték pangsaéna. Babaturan kuring sok mamatahan, pikeun ngaréspon patarosan ngeunaan cadangan, pikeun ngingetkeun aranjeunna ngeunaan jasa Yandex.Cloud, dimana masalah ieu parantos direngsekeun. Janten anggo upami mungkin.
Teu aya solusi lengkep pikeun cadangan, saratus persén diwangun kana ClickHouse. Aya sababaraha kosong anu tiasa dianggo. Pikeun meunangkeun solusi lengkep, anjeun bakal boh kudu tinker saeutik sacara manual, atawa nyieun wrappers dina bentuk skrip.
Kuring bakal mimitian ku solusi pangbasajanna sareng ditungtungan ku solusi anu paling canggih, gumantung kana volume data sareng ukuran klaster. Langkung ageung kluster, langkung kompleks solusina.
Lamun tabel kalawan data ngawengku ukur sababaraha gigabytes, cadangan bisa dipigawé saperti kieu:
- Simpen harti tabel nyaéta metadata − némbongkeun nyieun tabel.
- Jieun dump ngagunakeun klien ClickHouse - milih * tina méja pikeun berkas. Sacara standar anjeun bakal nampi file dina format TabSeparated. Upami anjeun hoyong langkung éfisién, anjeun tiasa ngalakukeunana dina format asli.
Upami jumlah data langkung ageung, cadanganna bakal langkung seueur waktos sareng seueur rohangan. Ieu disebut cadangan logis; eta teu dihijikeun ka format data ClickHouse. Upami éta, teras salaku pilihan terakhir anjeun tiasa nyandak cadangan sareng unggah kana MySQL pikeun pamulihan.
Pikeun kasus anu langkung maju, ClickHouse gaduh kamampuan anu diwangun pikeun nyiptakeun snapshot partisi dina sistem file lokal. fitur ieu sadia sakumaha pamundut a ngarobah tabel freeze partisi. Atawa ngan saukur ngarobah tabel freeze - ieu téh snapshot tina sakabéh méja.
snapshot bakal dijieun konsistén pikeun hiji méja dina hiji beling, nyaeta, mustahil pikeun nyieun snapshot konsisten sakabéh klaster ku cara kieu. Tapi pikeun sabagéan ageung pancén henteu peryogi sapertos kitu, sareng éta cekap pikeun ngaéksekusi pamundut dina unggal beling sareng kéngingkeun snapshot anu konsisten. Éta didamel dina bentuk hardlinks sahingga henteu nyandak rohangan tambahan. Salajengna, anjeun nyalin snapshot ieu ka server cadangan atawa ka gudang nu Anjeun pake pikeun cadangan.
Malikkeun cadangan sapertos anu cukup gampang. Mimiti, jieun tabel nganggo definisi tabel anu aya. Salajengna, salin snapshots disimpen tina partisi ka Diréktori-Detached pikeun tabel ieu jeung ngajalankeun query. ngagantelkeun partisi. Solusi ieu cukup cocog pikeun volume data anu paling serius.
Kadang-kadang nu peryogi hal malah cooler - dina kasus dimana anjeun boga puluhan atawa malah ratusan terabytes dina unggal server na ratusan server. Aya solusi di dieu anu kuring angkat ti kolega kuring ti Yandex.Metrica. Abdi henteu nyarankeun ka sadayana - baca sareng mutuskeun pikeun diri naha éta cocog atanapi henteu.
Kahiji maneh kudu nyieun sababaraha server kalawan rak disk badag. Salajengna, dina server ieu, ngangkat sababaraha server ClickHouse tur ngonpigurasikeun aranjeunna ambéh maranéhanana bisa dipake salaku replica sejen pikeun shards sarua. Teras nganggo sistem file atanapi sababaraha alat dina server ieu anu ngamungkinkeun anjeun nyiptakeun snapshot. Aya dua pilihan di dieu. Pilihan kahiji nyaéta snapshots LVM, pilihan kadua nyaéta ZFS dina Linux.
Saatos éta, unggal dinten anjeun kedah nyiptakeun snapshot, éta bakal bohong sareng nyandak sababaraha rohangan. Alami, lamun data robah, jumlah spasi bakal nambahan kana waktu. snapshot Ieu bisa dicokot kaluar iraha wae jeung data dibalikeun, misalna leyuran aneh. Tambih Deui, urang ogé kedah ngawates réplika ieu dina config supados aranjeunna henteu nyobian janten pamimpin.
Dupi éta mungkin pikeun ngatur hiji lag dikawasa réplika dina shafts?
Taun ieu anjeun perencanaan nyieun shafts di ClickHouse. Dupi éta mungkin pikeun ngatur hiji lag dikawasa réplika di aranjeunna? Kami hoyong nganggo éta pikeun ngajagi diri tina skénario négatip kalayan parobihan sareng parobihan sanés.
Naha mungkin pikeun ngalakukeun sababaraha jinis roll back pikeun ngarobih? Salaku conto, dina aci anu tos aya, cokot teras ucapkeun yén dugi ka ayeuna anjeun nerapkeun parobihan, sareng ti ayeuna anjeun ngeureunkeun nerapkeun parobihan?
Mun paréntah a sumping ka klaster urang jeung peupeus eta, lajeng urang boga replica kondisional kalawan lag jam, dimana urang bisa disebutkeun yen hayu urang ngagunakeun eta di momen, tapi urang moal nerapkeun parobahanana pikeun sapuluh menit panungtungan?
Kahiji, ngeunaan lag dikawasa réplika. Aya pamundut sapertos kitu ti pangguna, sareng kami nyiptakeun masalah dina Github kalayan pamundut: "Upami aya anu peryogi ieu, sapertos kitu, nempatkeun manah." Teu aya anu ngirimkeun, sareng masalahna ditutup. Nanging, anjeun parantos tiasa nampi kasempetan ieu ku nyetél ClickHouse. Leres, ngan mimitian ti versi 20.3.
ClickHouse terus-terusan ngahijikeun data dina latar tukang. Nalika ngahiji réngsé, sakumpulan data anu tangtu diganti ku potongan anu langkung ageung. Dina waktos anu sami, potongan-potongan data anu aya sateuacanna tetep tetep dina disk pikeun sababaraha waktos.
Kahiji, aranjeunna terus disimpen salami aya pilih queries nu make aranjeunna, dina urutan nyadiakeun operasi non-blocking. Pilih queries gampang dibaca tina sakumpulan heubeul.
Bréh, aya ogé ambang waktu - potongan data heubeul bohong dina disk pikeun dalapan menit. Dalapan menit ieu tiasa disaluyukeun sareng bahkan janten sadinten. Ieu bakal ngarugikeun spasi disk: gumantung kana aliran data, tétéla yén dina poé panungtungan data moal ngan ganda, éta bisa jadi lima kali leuwih. Tapi lamun aya masalah serius, Anjeun bisa ngeureunkeun server ClickHouse tur nyortir sagalana kaluar.
Ayeuna timbul patarosan ngeunaan kumaha ieu ngajaga ngalawan parobahan. Éta patut nyandak tampilan anu langkung jero di dieu, sabab dina versi ClickHouse anu langkung lami, alternatip damel ku cara anu ngan saukur ngarobih potongan langsung. Aya sapotong data sareng sababaraha file, sareng urang ngalakukeun, contona, ngarobah kolom serelek. Lajeng kolom ieu fisik dihapus tina sagala sakumpulan.
Tapi dimimitian ku vérsi 20.3, mékanisme alter parantos robih lengkep, sareng ayeuna potongan data sok teu tiasa dirobih. Éta henteu robih pisan - alters ayeuna tiasa dianggo dina cara anu sami sareng merges. Gantina ngaganti sapotong dina tempat, urang nyieun nu anyar. Dina chunk anyar, file nu teu robah jadi hardlinks, sarta lamun urang ngahapus kolom a, éta ngan bakal leungit dina chunk anyar. Potongan anu lami bakal dipupus sacara standar saatos dalapan menit, sareng di dieu anjeun tiasa ngarobih setélan anu disebatkeun di luhur.
Sami manglaku ka alters kayaning mutasi. Nalika anjeun ngalakukeun ngarobah ngahapus atawa ngarobah apdet, teu ngarobah sapotong, tapi nyiptakeun nu anyar. Teras mupus anu lami.
Kumaha lamun struktur tabel geus robah?
Kumaha carana mulangkeun cadangan nu dijieun kalawan skéma heubeul? Sareng patarosan anu kadua nyaéta ngeunaan kasus snapshot sareng alat sistem file. Naha Btrfs saé di dieu tibatan ZFS dina Linux LVM?
Upami anjeun ngalakukeun ngagantelkeun partisi partisi kalawan struktur béda, lajeng ClickHouse ngabejaan Anjeun yen ieu teu mungkin. Ieu solusi. Kahiji nyaeta nyieun tabel samentara tina tipe MergeTree kalawan struktur heubeul, ngagantelkeun data aya maké attach, sarta nyieun hiji query ngarobah. Teras anjeun tiasa nyalin atanapi nransper data ieu sareng ngagantelkeun deui, atanapi nganggo pamundut ngarobah partisi mindahkeun tabel.
Ayeuna patarosan kadua naha Btrfs tiasa dianggo. Pikeun mimitian, upami anjeun gaduh LVM, maka snapshot LVM cekap, sareng sistem file tiasa ext4, henteu masalah. Kalayan Btrts, sadayana gumantung kana pangalaman anjeun dina ngagunakeunana. Ieu sistem file dewasa, tapi masih aya sababaraha kacurigaan ngeunaan kumaha sagalana bakal jalan kaluar dina prakna dina skenario nu tangtu. Abdi teu bakal nyarankeun ngagunakeun ieu iwal mun gaduh Btrfs dina produksi.
Naon prakték pangalusna ayeuna dina resharding data?
Isu resharding rumit sarta multifaceted. Aya sababaraha kamungkinan jawaban di dieu. Anjeun tiasa balik ti hiji sisi sarta ngomong kieu - ClickHouse teu boga diwangun-di fitur resharding. Tapi kuring sieun jawaban ieu moal cocog saha. Kituna, anjeun bisa balik ti sisi séjén sarta nyebutkeun yén ClickHouse boga loba cara pikeun reshard data.
Lamun klaster ngalir kaluar rohangan atawa teu bisa nanganan beban, Anjeun nambahkeun server anyar. Tapi server ieu kosong sacara standar, teu aya data dina aranjeunna, teu aya beban. Anjeun kedah nyusun ulang data supados merata sumebar ka kluster énggal anu langkung ageung.
Cara kahiji anu tiasa dilakukeun nyaéta nyalin bagian tina partisi ka server énggal nganggo pamundut ngarobah partisi tabel dipulut. Salaku conto, anjeun ngagaduhan partisi ku bulan, sareng anjeun nyandak bulan kahiji 2017 sareng nyalin ka server énggal, teras nyalin bulan katilu ka sababaraha server énggal anu sanés. Sareng anjeun ngalakukeun ieu dugi ka janten langkung atanapi kirang.
Transfer tiasa dilaksanakeun ngan pikeun partisi anu henteu robih nalika ngarékam. Pikeun partisi seger, ngarékam kedah ditumpurkeun, sabab transferna henteu atom. Upami teu kitu, anjeun bakal mungkas nepi ka duplikat atawa sela dina data. Sanajan kitu, metoda ieu praktis tur jalan rada éféktif. partisi dikomprés siap-dijieun dikirimkeun ngaliwatan jaringan, nyaeta, data teu dikomprés atawa ulang disandikeun.
Metoda ieu boga hiji aral, sarta eta gumantung kana skéma sharding, naha anjeun pledged skéma sharding ieu, naon konci sharding anjeun kungsi. Dina conto anjeun pikeun kasus métrik, konci sharding nyaéta hash jalur. Lamun anjeun milih tabel disebarkeun, eta mana ka sadaya shards dina klaster sakaligus tur nyandak data ti dinya.
Ieu ngandung harti yén éta sabenerna henteu masalah ka anjeun naon data réngsé nepi kana beling nu. Hal utama nyaéta yén data sapanjang hiji jalur ditungtungan dina hiji beling, tapi anu mana anu henteu penting. Dina hal ieu, nransferkeun partisi anu siap-siap sampurna, sabab ku patarosan anu dipilih anjeun ogé bakal nampi data lengkep - naha sateuacan resharding atanapi saatos, skéma éta henteu penting pisan.
Tapi aya kasus nu leuwih kompleks. Lamun dina tingkat logika aplikasi anjeun ngandelkeun skéma sharding husus, éta klien ieu lokasina di beling sapertos na ieu, sarta pamundut nu bisa dikirim langsung ka dinya, sarta teu ka méja disebarkeun. Atanapi anjeun nganggo versi ClickHouse anu cukup anyar sareng parantos ngaktipkeun setélan ngaoptimalkeun skip beling henteu kapake. Dina hal ieu, nalika milih pamundut, éksprési dina bagian mana bakal dianalisis tur bakal diitung beling mana nu kudu dipaké nurutkeun skéma sharding. Ieu tiasa dianggo upami data dipisahkeun persis dumasar kana skéma sharding ieu. Upami anjeun nyusun ulang sacara manual, korespondensi tiasa robih.
Janten ieu mangrupikeun metode nomer hiji. Sareng kuring ngantosan jawaban anjeun, naha metodena cocog, atanapi hayu urang teraskeun.
Vladimir Kolobaev, administrator sistem kalungguhan di Avito: Alexey, metodeu anu anjeun nyarios henteu tiasa dianggo saé nalika anjeun kedah nyebarkeun beban, kalebet bacaan. Urang tiasa nyandak partisi anu bulanan sareng tiasa nyandak sasih sateuacana ka titik anu sanés, tapi nalika aya pamundut pikeun data ieu, kami ngan ukur ngamuat. Tapi urang hoyong ngamuat sakabéh klaster, sabab disebutkeun, pikeun sawatara waktu sakabéh beban bacaan bakal diolah ku dua shards.
Alexey Milovidov: Jawaban di dieu anéh - enya, éta goréng, tapi éta tiasa dianggo. Kuring bakal ngajelaskeun persis kumaha. Éta patut ningali skenario beban anu aya di tukangeun data anjeun. Upami ieu ngawaskeun data, maka urang ampir pasti tiasa nyarios yén seuseueurna pamundut kanggo data seger.
Anjeun masang server anyar, migrasi partisi heubeul, tapi ogé robah kumaha data seger kacatet. Sareng data seger bakal disebarkeun sapanjang kluster. Ku kituna, sanggeus ngan lima menit, requests pikeun lima menit panungtungan bakal merata ngamuat klaster; sanggeus sapoé, requests pikeun XNUMX jam merata beban klaster. Jeung requests pikeun bulan saméméhna, hanjakalna, ngan bakal balik ka bagian tina server klaster.
Tapi sering anjeun moal gaduh pamundut khusus pikeun Pébruari 2019. Paling dipikaresep, lamun requests lebet kana 2019, mangka bakal pikeun sakabéh 2019 - pikeun période badag waktu, teu keur rentang leutik. Sareng pamundut sapertos kitu ogé tiasa ngamuat klaster sacara merata. Tapi sacara umum, komentar anjeun leres pisan yén ieu mangrupikeun solusi ad hoc anu henteu nyebarkeun data sacara merata.
Kuring boga sababaraha titik deui pikeun ngajawab patarosan. Salah sahijina nyaéta ngeunaan kumaha mimitina mendesain skéma sharding supados re-sharding bakal nyababkeun nyeri anu langkung handap. Ieu teu salawasna mungkin.
Contona, anjeun gaduh data ngawaskeun. Data ngawaskeun ngembang pikeun tilu alesan. Anu kahiji nyaéta akumulasi data sajarah. Anu kadua nyaéta kamekaran lalu lintas. Jeung katilu nyaeta paningkatan dina jumlah hal anu tunduk kana monitoring. Aya jasa mikro sareng métrik énggal anu kedah disimpen.
Ieu mungkin nu ieu, kanaékan pangbadagna pakait sareng alesan katilu - ngaronjatna pamakéan monitoring. Sarta dina hal ieu, eta sia pilari di alam beban, naon queries pilih utama. Patarosan pilih dasar bakal paling dipikaresep dumasar kana sababaraha sawaréh métrik.
Contona, pamakéan CPU dina sababaraha server ku sababaraha layanan. Tétéla aya sawaréh konci anu ku anjeun kéngingkeun data ieu. Jeung pamundut sorangan pikeun data ieu paling dipikaresep cukup basajan tur geus réngsé dina puluhan milliseconds. Dipaké pikeun ngawaskeun jasa sareng dasbor. Kuring miharep kuring ngartos ieu leres.
Vladimir Kolobaev: Kanyataan yén urang sering pisan banding ka data sajarah, saprak urang ngabandingkeun kaayaan kiwari jeung sajarah sacara real waktu. Jeung hal anu penting pikeun urang boga wasa gancang ka jumlah badag data, sarta ClickHouse teu hiji pakasaban alus teuing jeung ieu.
Anjeun leres-leres leres, kami ngalaman seueur paménta dibaca dina dinten terakhir, sapertos sistem ngawaskeun. Tapi dina waktos anu sareng, beban data sajarah ogé cukup badag. Dasarna tina sistem ngageterkeun unggal tilu puluh detik sareng nyarios ka ClickHouse: "Pasihan abdi data salami genep minggu ka pengker. Ayeuna ngawangun kuring sababaraha jinis rata-rata gerak ti aranjeunna, sareng hayu urang ngabandingkeun nilai ayeuna sareng nilai sajarah.
Abdi hoyong nyebatkeun yén pikeun pamundut anu énggal-énggal ieu kami gaduh méja leutik anu sanés ngan ukur dua dinten data, sareng paménta utama ngapung kana éta. Urang ngan ngirimkeun queries sajarah badag kana tabel sharded badag.
Alexey Milovidov: Hanjakal, tétéla jadi kirang lumaku pikeun skenario Anjeun, tapi kuring bakal ngabejaan Anjeun pedaran dua skéma sharding goréng tur kompléks nu teu perlu dipaké, tapi nu dipaké dina layanan babaturan kuring.
Aya klaster utama sareng acara Yandex.Metrica. Kajadian nyaéta pintonan halaman, klik, sareng konvérsi. Paling requests buka ramatloka husus. Anjeun muka layanan Yandex.Metrica, anjeun boga ramatloka - avito.ru, buka laporan, sarta pamundut dijieun pikeun ramatloka anjeun.
Tapi aya pamundut sanés - analitis sareng global - anu dilakukeun ku analis internal. Ngan bisi, kuring dicatet yén analis internal nyieun requests ngan pikeun layanan Yandex. Tapi sanajan kitu, malah jasa Yandex ngeusian pangsa signifikan sadaya data. Ieu requests sanes pikeun counters husus, tapi pikeun nyaring lega.
Kumaha carana ngatur data dina cara nu sagalana jalan éfisién pikeun hiji counter, sarta queries global teuing? Kasusah sejen nyaeta jumlah requests di ClickHouse pikeun klaster metrics sababaraha rébu per detik. Dina waktu nu sarua, hiji server ClickHouse teu tiasa ngadamel requests non-trivial, contona, sababaraha sarébu per detik.
Ukuran klaster nyaéta genep ratus-hiji server. Upami anjeun ngan saukur narik méja anu disebarkeun dina klaster ieu sareng ngirim sababaraha rébu pamundut ka dinya, éta bakal langkung parah tibatan ngirim ka hiji server. Di sisi séjén, pilihan yén data disebarkeun merata, sarta kami balik sarta menta ti sagala server, geuwat mecat.
Aya hiji pilihan anu diametrically sabalikna. Bayangkeun lamun urang beling data sakuliah situs, sarta pamundut pikeun hiji situs mana anu ka hiji beling. Ayeuna klaster bakal tiasa ngadamel sapuluh rébu requests per detik, tapi dina hiji beling sagala pamundut bakal dianggo lalaunan teuing. Éta moal deui skala dina hal throughput. Utamana upami ieu situs avito.ru. Kuring moal nembongkeun rusiah lamun kuring nyebutkeun yén Avito mangrupakeun salah sahiji situs paling dilongok di RuNet. Jeung ngolah eta dina hiji beling bakal madness.
Ku alatan éta, skéma sharding dirancang ku cara anu langkung licik. Sakabéh klaster dibagi kana sababaraha klaster, nu urang sebut lapisan. Unggal klaster ngandung ti belasan nepi ka sababaraha belasan shards. Jumlahna aya tilu puluh salapan klaster.
Kumaha ieu sadayana skala? Jumlah klaster henteu robih - sabab éta tilu puluh salapan sababaraha taun ka pengker, tetep kitu. Tapi dina unggal sahijina, urang laun-laun nambahan jumlah beling nalika urang ngumpulkeun data. Sareng skéma sharding sacara gembleng sapertos kieu: klaster ieu dibagi kana situs wéb, sareng pikeun ngartos halaman wéb mana dina klaster mana, metabase anu misah dina MySQL dianggo. Hiji situs - dina hiji klaster. Sareng di jerona, sharding lumangsung dumasar kana ID sémah.
Nalika ngarékam, urang ngabagi aranjeunna ku sésa-sésa divisi ID sémah. Tapi nalika nambahkeun beling anyar, skéma sharding robah; urang terus dibeulah, tapi kalawan sésa division ku angka sejen. Ieu ngandung harti yén hiji nganjang geus lokasina di sababaraha server, jeung anjeun teu bisa ngandelkeun ieu. Hal ieu dilakukeun ngan ukur pikeun mastikeun yén data dikomprés langkung saé. Sareng nalika nyuhunkeun, urang angkat ka méja Distribusi, anu ningali kluster sareng ngaksés puluhan server. Ieu skéma bodo.
Tapi carita kuring bakal lengkep upami kuring henteu nyarios yén urang ngantunkeun skéma ieu. Dina skéma anyar, urang robah sagalana jeung nyalin sakabéh data ngagunakeun clickhouse-copier.
Dina skéma anyar, sadaya situs dibagi kana dua kategori - ageung sareng alit. Kuring henteu weruh kumaha bangbarung ieu dipilih, tapi hasilna éta situs badag kacatet dina hiji klaster, dimana aya 120 shards kalawan tilu réplika unggal - nyaeta 360 server. Sareng skéma sharding sapertos anu mana waé pamundut mana anu ka sadaya beling sakaligus. Upami anjeun ayeuna muka halaman laporan naon waé pikeun avito.ru di Yandex.Metrica, pamenta bakal angkat ka 120 server. Aya sababaraha situs ageung di RuNet. Jeung requests teu sarébu per detik, tapi malah kirang ti saratus. Sadaya ieu sacara tenang dikunyah ku méja Distribusi, anu masing-masing diolah ku 120 server.
Jeung klaster kadua pikeun situs leutik. Di handap ieu skéma sharding dumasar kana ID situs, sarta unggal pamundut mana persis hiji beling.
ClickHouse gaduh utilitas clickhouse-copier. Dupi anjeun ngabejaan urang ngeunaan dirina?
Kuring bakal langsung nyarios yén solusi ieu langkung pajeulit sareng rada kirang produktif. Kauntungannana nya éta smears data lengkep nurutkeun pola Anjeun tangtukeun. Tapi kalemahan tina utilitas téh nya éta teu reshard pisan. Éta nyalin data tina hiji skéma klaster ka skéma klaster séjén.
Ieu ngandung harti yén pikeun dianggo anjeun kedah gaduh dua klaster. Éta tiasa ditempatkeun dina server anu sami, tapi, sanaos kitu, datana moal dipindahkeun sacara bertahap, tapi bakal disalin.
Contona, aya opat server, ayeuna aya dalapan. Anjeun nyieun tabel Distributed anyar dina sagala server, tabel lokal anyar jeung ngajalankeun clickhouse-copier, nunjukkeun di dinya skéma gawé anu sakuduna maca ti dinya, nampa skéma sharding anyar jeung mindahkeun data dinya. Sarta dina server heubeul anjeun bakal butuh hiji satengah kali leuwih spasi ti ayeuna, sabab data heubeul kudu tetep dina aranjeunna, sarta satengah tina data heubeul sarua bakal anjog di luhureun aranjeunna. Upami anjeun panginten sateuacanna yén data kedah di-resharded sareng aya rohangan, maka metode ieu cocog.
Kumaha clickhouse-copier dianggo di jero? Éta ngarecah sadaya padamelan kana sakumpulan tugas pikeun ngolah hiji partisi hiji méja dina hiji beling. Sadaya pancén ieu bisa dieksekusi dina paralel, sarta clickhouse-copier bisa dijalankeun dina mesin béda dina sababaraha instansi, tapi naon hancana pikeun hiji partisi euweuh leuwih ti hiji sisipan pilih. Datana dibaca, didekompresi, dipartisi deui, tuluy dikomprés deui, ditulis wae, terus diurutkeun deui. Ieu kaputusan tougher.
Anjeun ngagaduhan hal pilot anu disebut resharding. Naon jeung manehna?
Deui dina 2017, anjeun ngagaduhan hal pilot anu disebut resharding. Malah aya pilihan di ClickHouse. Sakumaha kuring ngartos, éta henteu lepas. Naha anjeun tiasa ngawartosan naha ieu kajantenan? Sigana relevan pisan.
Sakabeh masalah nyaeta lamun perlu reshard data di tempat, sinkronisasi pisan kompléks diperlukeun pikeun ngalakukeun ieu atomically. Nalika urang mimiti ningali kumaha sinkronisasi ieu jalan, janten jelas yén aya masalah dasar. Jeung ieu masalah fundamental henteu ngan teoritis, tapi geuwat mimiti némbongkeun diri dina prakna dina bentuk hiji hal anu bisa dipedar pisan saukur - nanaon jalan.
Naha mungkin pikeun ngahijikeun sadaya potongan data sateuacan mindahkeun kana ngalambatkeun disk?
Patarosan ngeunaan TTL kalawan move mun slow pilihan disk dina konteks merges. Naha aya cara, lian ti via cron, pikeun ngahijikeun sadaya bagian janten hiji sateuacan mindahkeun kana ngalambatkeun disk?
Jawaban kana patarosan éta mungkin pikeun kumaha waé sacara otomatis lem sadaya potongan janten hiji sateuacan nransferkeunana - henteu. Ku teu sangka ieu diperlukeun. Anjeun teu kedah ngahijikeun sadaya bagian kana hiji, tapi ngan ukur ngandelkeun kanyataan yén aranjeunna bakal ditransferkeun ka disk ngalambatkeun sacara otomatis.
Kami gaduh dua kriteria pikeun aturan transfer. Anu kahiji nyaéta sakumaha anu dieusian. Lamun tingkat gudang ayeuna boga kirang ti perséntase tangtu rohangan bébas, urang milih hiji sapotong tur mindahkeun ka gudang laun. Atawa rada, teu laun, tapi nu salajengna - anjeun ngonpigurasikeun.
Kriteria kadua nyaéta ukuran. Ieu ngeunaan mindahkeun potongan badag. Anjeun tiasa nyaluyukeun bangbarung numutkeun kana rohangan bébas dina disk gancang, sareng datana bakal ditransfer sacara otomatis.
Kumaha migrasi ka versi anyar ClickHouse upami teu aya deui jalan pikeun mariksa kasaluyuan sateuacanna?
Topik ieu dibahas rutin nyokot kana akun versi béda, sarta masih. Kumaha aman pikeun ningkatkeun tina versi 19.11 ka 19.16 sareng, contona, tina 19.16 ka 20.3. Naon cara anu pangsaéna pikeun migrasi ka versi énggal tanpa tiasa mariksa kasaluyuan dina kotak pasir sateuacanna?
Aya sababaraha aturan "emas" di dieu. kahiji- . Éta ageung, tapi aya paragraf anu misah ngeunaan parobahan anu teu cocog. Ulah nganggap titik ieu salaku bandéra beureum. Ieu biasana incompatibilities minor anu ngalibatkeun sababaraha fungsionalitas ujung nu Anjeun kamungkinan teu make.
Bréh, upami teu aya deui jalan pikeun mariksa kasaluyuan dina sandbox, sareng anjeun badé ngapdet langsung dina produksi, rekomendasi nyaéta yén anjeun henteu kedah ngalakukeun ieu. Mimiti ngadamel kotak pasir sareng uji. Upami teu aya lingkungan tés, maka anjeun paling dipikaresep henteu gaduh perusahaan anu ageung pisan, anu hartosna anjeun tiasa nyalin sababaraha data kana laptop anjeun sareng pastikeun yén sadayana jalanna leres. Anjeun malah tiasa ngangkat sababaraha réplika sacara lokal dina mesin anjeun. Atanapi anjeun tiasa nyandak vérsi énggal di tempat anu caket sareng unggah sababaraha data di dinya - nyaéta, nyiptakeun lingkungan uji improvisasi.
Aturan anu sanés nyaéta henteu ngapdet pikeun saminggu saatos sékrési versi kusabab nyekel bug dina produksi sareng perbaikan gancang anu salajengna. Hayu urang angka kaluar panomeran versi ClickHouse ambéh teu meunang bingung.
Aya versi 20.3.4. Angka 20 nunjukkeun taun pabrik - 2020. Tina sudut pandang naon anu aya di jero, ieu henteu masalah, janten urang moal nengetan éta. Salajengna - 20.3. Urang ningkatkeun jumlah kadua - dina hal ieu 3 - unggal waktos urang ngaleupaskeun release kalawan sababaraha pungsi anyar. Upami urang hoyong nambihan sababaraha fitur kana ClickHouse, urang kedah ningkatkeun jumlah ieu. Hartina, dina versi 20.4 ClickHouse bakal tiasa dianggo langkung saé. Angka katilu nyaéta 20.3.4. Ieu 4 mangrupikeun jumlah pelepasan patch dimana kami henteu nambihan fitur énggal, tapi ngalereskeun sababaraha bug. Jeung 4 hartina urang ngalakukeun eta opat kali.
Ulah nganggap yén ieu téh hal dahsyat. Biasana pangguna tiasa masang vérsi pangénggalna sareng éta bakal tiasa dianggo tanpa aya masalah sareng uptime per taun. Tapi bayangkeun yén dina sababaraha fungsi pikeun ngolah bitmaps, anu ditambahkeun ku comrades Cina urang, server ngadat nalika ngalirkeun argumen lepat. Urang boga tanggung jawab pikeun ngalereskeun ieu. Urang bakal ngaleupaskeun versi patch anyar jeung ClickHouse bakal jadi leuwih stabil.
Upami Anjeun gaduh ClickHouse ngajalankeun dina produksi, sarta versi anyar tina ClickHouse kaluar kalawan fitur tambahan - contona, 20.4.1 mangrupa pisan munggaran, ulah rurusuhan nempatkeun kana produksi dina dinten pisan munggaran. Naha éta malah diperlukeun? Upami anjeun henteu acan nganggo ClickHouse, teras anjeun tiasa pasang, sareng kamungkinan sadayana bakal saé. Tapi upami ClickHouse parantos damel sacara stabil, teras perhatikeun patches sareng apdet pikeun ningali masalah naon anu urang ngalereskeun.
Kirill Shvakov: Abdi hoyong nambihan sakedik ngeunaan lingkungan tés. Sarerea sieun pisan kana lingkungan tés sareng pikeun sababaraha alesan aranjeunna yakin yén upami anjeun gaduh klaster ClickHouse anu ageung, maka lingkungan uji kedah henteu kirang atanapi sahenteuna sapuluh kali langkung alit. Teu kitu pisan.
Abdi tiasa nyarioskeun ka anjeun tina conto kuring sorangan. Kuring boga proyek, tur aya ClickHouse. Lingkungan uji kami ngan pikeun anjeunna - ieu mangrupikeun mesin virtual leutik di Hetzner pikeun dua puluh euro, dimana leres-leres sadayana disebarkeun. Jang ngalampahkeun ieu, urang boga automation pinuh di Ansible, sarta ku kituna, prinsipna mah, teu aya bédana dimana buka - ka server hardware atawa ngan nyebarkeun dina mesin virtual.
Naon anu tiasa dilakukeun? Éta hadé pikeun masihan conto dina dokuméntasi ClickHouse ngeunaan cara nyebarkeun klaster leutik di bumi anjeun nyalira - di Docker, di LXC, panginten tiasa ngadamel playbook Ansible, sabab jalma anu béda-béda gaduh panyebaran anu béda. Ieu bakal simplify pisan. Nalika anjeun nyandak sareng nyebarkeun klaster dina lima menit, éta langkung gampang pikeun nyobian terangkeun hiji hal. Ieu leuwih merenah, sabab rolling kana versi produksi nu teu acan diuji téh jalan ka nowhere. Kadang tiasa dianggo sareng kadang henteu. Ku kituna, hoping for keur ayaan goréng.
Maxim Kotyakov, insinyur backend senior Avito: Kuring bakal nambahan saeutik saeutik ngeunaan lingkungan test tina runtuyan masalah Nyanghareupan ku pausahaan badag. Kami ngagaduhan kluster panampi ClickHouse pinuh; dina hal skéma sareng setélan data, éta mangrupikeun salinan pasti tina naon anu aya dina produksi. Klaster ieu disebarkeun dina wadah anu cukup rundown kalayan sumber daya minimum. Urang nulis perséntase tangtu data produksi aya, untungna kasebut nyaéta dimungkinkeun pikeun ngayakeun réplikasi aliran di Kafka. Sagalana aya disingkronkeun sareng diskalakeun - boh tina segi kapasitas sareng aliran, sareng, dina tiori, sadaya hal anu sami, éta kedah kalakuanana sapertos produksi dina hal métrik. Sadayana anu berpotensi ngabeledug munggaran digulung kana lapak ieu sareng tinggalkeun di dinya sababaraha dinten dugi ka siap. Tapi sacara alami, solusi ieu mahal, sesah sareng gaduh biaya dukungan anu henteu nol.
Alexey Milovidov: Kuring gé ngabejaan Anjeun naon lingkungan test babaturan urang ti Yandex.Metrica. Hiji klaster miboga server 600-ganjil, sejen miboga 360, tur aya hiji katilu jeung sababaraha klaster. Lingkungan uji pikeun salah sahijina ngan ukur dua beling sareng dua réplika masing-masing. Naha dua beling? Supados anjeun henteu nyalira. Sareng kedah aya réplika ogé. Ngan jumlah minimum nu tangtu nu can mampuh.
Lingkungan tés ieu ngamungkinkeun anjeun mariksa upami patarosan anjeun jalan sareng upami aya anu rusak. Tapi mindeng masalah timbul tina alam lengkep beda, nalika sagalana jalan, tapi aya sababaraha parobahan leutik dina beban.
Hayu atuh masihan anjeun conto. Urang mutuskeun masang versi anyar tina ClickHouse. Eta geus dipasang dina lingkungan test, tés otomatis geus réngsé dina Yandex.Metrica sorangan, nu ngabandingkeun data dina versi heubeul jeung nu anyar, ngajalankeun sakabéh pipa. Sarta tangtu, tés héjo CI kami. Upami teu kitu, urang malah moal bakal ngajukeun versi ieu.
Sagalana geus rupa. Urang ngawitan ngalih kana produksi. Kuring nampi pesen yén beban dina grafik parantos ningkat sababaraha kali. Urang rolling deui versi. Kuring nempo grafik tur tingal: beban sabenerna ngaronjat sababaraha kali salila rollout nu, sarta turun deui nalika aranjeunna digulung kaluar. Teras we dimimitian rolling deui versi. Jeung beban ngaronjat dina cara nu sarua jeung turun deui dina cara nu sarua. Jadi kacindekan ieu: beban geus ngaronjat alatan perenah, euweuh héran.
Lajeng hese ngayakinkeun kolega masang versi anyar. Kuring: "Teu kunanaon, gulung kaluar. Tetep ramo Anjeun meuntas, sagalana bakal jalan. Ayeuna beban dina grafik parantos ningkat, tapi sadayana henteu kunanaon. Tetep didinya." Sacara umum, urang ngalakukeun ieu, sareng éta - versi dileupaskeun pikeun produksi. Tapi ampir kalawan unggal tata perenah masalah sarupa timbul.
Kill query sakuduna maéhan queries, tapi henteu. Naha?
A pamaké, sababaraha jenis analis, sumping ka kuring sarta dijieun pamundut nu nempatkeun klaster ClickHouse kuring. Sababaraha titik atanapi sadayana klaster, gumantung kana réplika atanapi beling mana anu dipénta. Kuring nempo yén sakabéh sumberdaya CPU dina server ieu dina rak a, sagalana beureum. Dina waktu nu sarua, ClickHouse sorangan responds kana requests. Sareng kuring nyerat: "Punten tunjukkeun kuring, daptar prosés, pamundut naon anu nyababkeun kagilaan ieu."
Kuring manggihan pamundut ieu jeung nulis maéhan eta. Sareng kuring ningali yén teu aya anu kajantenan. server abdi aya dina rak a, ClickHouse lajeng masihan kuring sababaraha paréntah, nunjukeun yen server hirup, jeung sagalana geus hébat. Tapi kuring boga degradasi dina sakabéh requests pamaké, degradasi dimimitian ku rékaman di ClickHouse, sarta query maéhan abdi teu jalan. Naha? Teu sangka maéhan query sakuduna dituju maéhan queries, tapi henteu.
Ayeuna bakal aya jawaban anu rada aneh. Intina nyaéta maéhan query henteu maéhan queries.
Kill query mariksa kotak leutik anu disebut "Kuring hoyong pamundut ieu dipaéhan." Sareng pamundut nyalira ningali bandéra ieu nalika ngolah unggal blok. Lamun disetel, pamundut eureun gawé. Tétéla teu saurang ogé maéhan paménta, manéhna sorangan kudu pariksa sagalana jeung eureun. Sareng ieu kedah dianggo dina sadaya kasus dimana pamundutna aya dina kaayaan blok ngolah data. Bakal ngolah blok data salajengna, pariksa bandéra, sareng eureun.
Ieu henteu tiasa dianggo dina kasus dimana pamundut diblokir dina sababaraha operasi. Leres, paling dipikaresep ieu sanés kasus anjeun, sabab, numutkeun anjeun, éta ngagunakeun ton sumber daya server. Ieu mungkin nu ieu teu dianggo dina kasus asihan éksternal sarta dina sababaraha rinci séjén. Tapi sacara umum ieu teu kedah lumangsung, éta bug. Sareng hiji-hijina hal anu kuring tiasa nyarankeun nyaéta pikeun ngapdet ClickHouse.
Kumaha carana ngitung waktos respon dina beban bacaan?
Aya méja nu nyimpen agrégat item - rupa counters. Jumlah garisna kurang leuwih saratus juta. Naha mungkin pikeun ngandelkeun waktos réspon anu tiasa diprediksi upami anjeun tuang 1K RPS pikeun barang 1K?
Ditilik ku konteks, urang ngobrol ngeunaan beban bacaan, sabab teu aya masalah dina nulis - malah sarébu, malah saratus rébu, sarta kadangkala sababaraha juta jajar bisa diselapkeun.
Paménta maca béda pisan. Dina milih 1, ClickHouse tiasa ngalakukeun ngeunaan puluhan rébu pamundut per detik, janten bahkan pamundut pikeun hiji konci bakal meryogikeun sababaraha sumber. Sarta queries titik sapertos bakal leuwih hese tibatan dina sababaraha basis data konci-nilai, sabab pikeun tiap bacaan perlu maca blok data ku indéks. Indéks kami alamat henteu unggal catetan, tapi unggal rentang. Hartina, anjeun kudu maca sakabéh rentang - ieu 8192 garis sacara standar. Sareng anjeun kedah nga-decompress blok data anu dikomprés tina 64 KB ka 1 MB. Ilaharna, queries sasaran misalna butuh sababaraha milliseconds pikeun réngsé. Tapi ieu pilihan pangbasajanna.
Hayu urang coba sababaraha aritmetika basajan. Upami anjeun ngalikeun sababaraha milidetik ku sarébu, anjeun bakal nampi sababaraha detik. Saolah-olah teu mungkin pikeun tetep nepi ka sarébu requests per detik, tapi dina kanyataanana mungkin, sabab urang boga sababaraha cores processor. Ku kituna, prinsipna mah, ClickHouse kadang bisa nahan 1000 RPS, tapi pikeun requests pondok, husus sasaran.
Lamun perlu skala klaster ClickHouse ku Jumlah requests basajan, teras abdi nyarankeun hal pangbasajanna - nambahan jumlah réplika sarta ngirim requests ka replica acak. Lamun hiji réplika nahan lima ratus requests per detik, nu sagemblengna realistis, lajeng tilu réplika bakal nanganan hiji satengah sarébu.
Sakapeung, tangtosna, anjeun tiasa ngonpigurasikeun ClickHouse pikeun jumlah maksimum bacaan titik. Naon anu diperlukeun pikeun ieu? Kahiji nyaéta pikeun ngurangan granularity tina indéks. Dina hal ieu, teu kudu diréduksi jadi hiji, tapi dina dasar yén jumlah éntri dina indéks bakal sababaraha juta atawa puluhan juta per server. Upami tabél ngagaduhan saratus juta jajar, teras granularitas tiasa disetel ka 64.
Anjeun tiasa ngirangan ukuran blok anu dikomprés. Aya setélan pikeun ieu ukuran blok komprési mnt, max komprési ukuran blok. Éta bisa ngurangan, refilled ku data, lajeng queries sasaran bakal leuwih gancang. Tapi tetep, ClickHouse sanes database konci-nilai. Sajumlah ageung pamundut alit mangrupikeun antipattern beban.
Kirill Shvakov: Abdi bakal masihan naséhat upami aya akun biasa di dinya. Ieu kaayaan anu cukup standar nalika ClickHouse nyimpen sababaraha jinis counter. Kuring boga pamaké, anjeunna ti nagara sapertos kitu, sarta sababaraha widang katilu, sarta kuring kudu ningkatkeun hal incrementally. Candak MySQL, jieun konci anu unik - dina MySQL mangrupikeun konci duplikat, sareng dina PostgreSQL éta konflik - sareng tambahkeun tanda tambah. Ieu bakal dianggo leuwih hadé.
Lamun anjeun teu boga loba data, aya teu pira titik dina ngagunakeun ClickHouse. Aya pangkalan data biasa sareng aranjeunna ngalakukeun ieu ogé.
Naon anu kuring tiasa tweak di ClickHouse supados langkung seueur data dina cache?
Hayu urang ngabayangkeun kaayaan - server boga 256 GB RAM, dina rutin poean ClickHouse nyokot ngeunaan 60-80 GB, di puncak - nepi ka 130. Naon bisa diaktipkeun jeung tweaked ambéh leuwih data aya dina cache sarta, sasuai, aya pangsaeutikna perjalanan ka disk?
Biasana, cache halaman sistem operasi ngalakukeun padamelan anu saé pikeun ieu. Lamun ngan muka luhur, kasampak aya sindangan atawa bébas - eta oge nyebutkeun sabaraha sindangan - mangka anjeun bakal aya bewara yen sakabeh memori bébas dipaké pikeun cache nu. Sareng nalika maca data ieu, éta bakal dibaca sanés tina disk, tapi tina RAM. Dina waktos anu sami, kuring tiasa nyebatkeun yén cache dianggo sacara efektif sabab éta data anu dikomprés anu disimpen.
Sanajan kitu, lamun hayang nyepetkeun sababaraha queries basajan malah leuwih, kasebut nyaéta dimungkinkeun pikeun ngaktipkeun cache dina data decompressed jero ClickHouse. Disebutna cache uncompressed. Dina file konfigurasi config.xml, Nyetél ukuran cache uncompressed kana nilai nu peryogi - Abdi nyarankeun henteu leuwih ti satengah tina RAM bébas, sabab sésana bakal balik dina cache kaca.
Sajaba ti éta, aya dua setélan tingkat pamundut. Setélan munggaran - ngagunakeun cache uncompressed - ngawengku pamakéan na. Disarankeun pikeun ngaktipkeun eta pikeun sakabéh requests, iwal leuwih beurat, nu bisa maca sakabéh data jeung siram cache. Jeung setelan kadua hal kawas jumlah maksimum garis ngagunakeun cache nu. Éta otomatis ngabatesan patarosan ageung supados aranjeunna ngalangkungan cache.
Kumaha carana abdi tiasa ngonpigurasikeun storage_configuration pikeun neundeun dina RAM?
Dina dokuméntasi ClickHouse anyar kuring maca bagian patali . Katerangan ngandung conto sareng SSD gancang.
Kuring heran kumaha hal anu sarua bisa ngonpigurasi kalawan volume memori panas. Sareng hiji deui patarosan. Kumaha carana milih karya kalawan organisasi data ieu, éta bakal maca sakabéh set atawa ngan hiji nu aya dina disk, sarta ieu data dikomprés dina mémori? Sareng kumaha bagian prewhere tiasa dianggo sareng organisasi data sapertos kitu?
Setelan ieu mangaruhan panyimpen sakumpulan data, sareng formatna henteu robih ku cara naon waé.
Hayu urang nempo leuwih deukeut.
Anjeun tiasa ngonpigurasikeun panyimpenan data dina RAM. Sadaya anu dikonpigurasikeun pikeun disk nyaéta jalurna. Anjeun nyiptakeun partisi tmpfs anu dipasang dina sababaraha jalur dina sistem file. Anjeun nangtukeun jalur ieu salaku jalur pikeun nyimpen data pikeun partisi hottest, potongan data mimiti anjog sarta ditulis aya, sagalana geus rupa.
Tapi kuring henteu nyarankeun ngalakukeun ieu kusabab réliabilitas anu rendah, sanaos upami anjeun ngagaduhan sahenteuna tilu réplika dina pusat data anu béda, maka éta mungkin. Upami aya kajadian, data bakal disimpen deui. Hayu urang ngabayangkeun yén server ujug-ujug dipareuman jeung dihurungkeun deui. Partisi dipasang deui, tapi teu aya nanaon. Nalika server ClickHouse dimimitian, éta ningali yén éta henteu ngagaduhan potongan ieu, sanaos, nurutkeun metadata ZooKeeper, aranjeunna kedah aya. Anjeunna ningali anu réplika gaduh aranjeunna, nyuhunkeun sareng ngaunduhana. Ku cara ieu data bakal disimpen deui.
Dina hal ieu, nyimpen data dina RAM teu fundamentally béda ti nyimpen eta dina disk, sabab lamun data ditulis kana disk, éta ogé mimiti ends up dina cache kaca sarta fisik ditulis engké. Ieu gumantung kana pilihan pamasangan sistem file. Tapi bisi waé, kuring bakal nyarios yén ClickHouse henteu fsync nalika nyelapkeun.
Dina hal ieu, data dina RAM disimpen dina format persis sarua jeung dina disk. Paménta pilih dina cara anu sami milih potongan-potongan anu kedah dibaca, milih rentang data anu diperyogikeun dina potongan-potongan, sareng macana. Sarta prewhere jalan persis sarua, paduli naha data éta dina RAM atawa dina disk.
Nepi ka sabaraha nilai unik anu efektif Low Cardinality?
Low Cardinality dirancang cleverly. Éta nyusun kamus data, tapi aranjeunna lokal. Kahiji, aya kamus béda pikeun tiap sapotong, sarta Bréh, sanajan dina hiji sapotong maranéhna bisa jadi béda pikeun tiap rentang. Nalika jumlah nilai unik ngahontal jumlah bangbarung-sajuta, kuring nyangka-kamusna ngan saukur disimpen sareng anu énggal didamel.
Jawabanna sacara umum: pikeun unggal rentang lokal - sebutkeun, pikeun unggal dinten - dugi ka sajuta nilai unik Low Cardinality efektif. Afterwards bakal aya saukur fallback, nu loba kamus béda bakal dipaké, teu ngan hiji. Bakal dianggo kira sarua salaku kolom string biasa, meureun saeutik kirang efisien, tapi moal aya degradasi kinerja serius.
Naon prakték pangsaéna pikeun milarian téks lengkep dina méja kalayan lima milyar jajar?
Aya jawaban anu béda. Anu kahiji nyaéta nyatakeun yén ClickHouse sanés mesin pencari téks lengkep. Aya sistem khusus pikeun ieu, contona, и . Nanging, kuring beuki ningali jalma anu nyarios yén aranjeunna ngalih ti Elasticsearch ka ClickHouse.
Naha ieu kajadian? Aranjeunna ngajelaskeun ieu ku kanyataan yén Elasticsearch ceases Cope jeung beban dina sababaraha jilid, dimimitian ku pangwangunan indexes. Indéks janten pajeujeut teuing, sareng upami anjeun ngan saukur mindahkeun data ka ClickHouse, tétéla aranjeunna disimpen sababaraha kali langkung éfisién dina hal volume. Dina waktu nu sarua, queries pilarian éta mindeng henteu sapertos nu diperlukeun pikeun manggihan sababaraha frase dina sakabéh volume data, nyokot kana akun morfologi, tapi sagemblengna béda. Contona, panggihan sababaraha runtuyan bait dina log salila sababaraha jam panungtungan.
Dina hal ieu, anjeun nyieun hiji indéks dina ClickHouse, widang kahiji nu bakal tanggal jeung waktu. Jeung cut-off data pangbadagna bakal dumasar kana rentang tanggal. Dina rentang tanggal nu dipilih, sakumaha aturan, geus mungkin pikeun ngalaksanakeun pilarian téks lengkep, sanajan ngagunakeun métode brute force maké kawas. Operator sapertos di ClickHouse mangrupikeun operator anu paling éfisién anu anjeun tiasa mendakan. Upami anjeun mendakan anu langkung saé, wartosan kuring.
Tapi tetep, sapertos scan pinuh. Jeung scan pinuh tiasa slow teu ukur dina CPU, tapi ogé dina disk. Upami ujug-ujug anjeun gaduh hiji terabyte data per dinten, sareng anjeun milarian kecap salami siang, maka anjeun kedah nyeken terabyte. Sarta meureun nya dina hard drive biasa, sarta dina tungtungna maranéhna bakal dimuat dina cara sapertos nu moal bisa ngakses server ieu via SSH.
Dina hal ieu, Kami siap nawiskeun hiji deui trik saeutik. Éta ékspérimén - éta tiasa dianggo, panginten henteu. ClickHouse gaduh indéks téks lengkep dina bentuk saringan trigram Bloom. Kolega urang di Arenadata parantos nyobian indéks ieu, sareng aranjeunna sering dianggo persis sakumaha anu dimaksud.
Pikeun ngagunakeunana leres, anjeun kedah gaduh pamahaman anu hadé ngeunaan kumaha aranjeunna jalanna: naon trigram saringan Bloom sareng kumaha milih ukuranana. Kuring bisa disebutkeun yen aranjeunna bakal mantuan pikeun queries on sababaraha frasa langka, substrings nu jarang kapanggih dina data. Dina hal ieu, subranges bakal dipilih ku indéks jeung kirang data bakal dibaca.
Anyar-anyar ieu, ClickHouse parantos nambihan fungsi anu langkung maju pikeun milarian téks lengkep. Ieu, mimitina, milarian sakumpulan substrings sakaligus dina hiji pas, kalebet pilihan anu sénsitip-sénsitip, sénsitip-kasus, kalayan dukungan pikeun UTF-8 atanapi ngan ukur pikeun ASCII. Pilih anu paling efektif anu anjeun peryogikeun.
Pilarian pikeun sababaraha ekspresi biasa dina hiji pass ogé geus mucunghul. Anjeun teu kedah nyerat X sapertos hiji substring atanapi X sapertos substring anu sanés. Anjeun nulis langsung, sarta sagalana geus rengse sakumaha éfisién mungkin.
Katilu, ayeuna aya perkiraan milarian regexps sareng perkiraan milarian substrings. Upami aya anu salah ngeja kecap, éta bakal dipilarian pikeun pertandingan anu maksimal.
Naon cara anu pangsaéna pikeun ngatur aksés ka ClickHouse pikeun sajumlah ageung pangguna?
Ngabejaan urang kumaha pangalusna pikeun ngatur aksés pikeun angka nu gede ngarupakeun konsumén jeung analis. Kumaha ngabentuk antrian, prioritas max queries sakaligus, sarta kalawan parabot naon?
Upami klusterna cukup ageung, maka solusi anu saé nyaéta ngangkat dua server deui, anu bakal janten titik éntri pikeun analis. Hartina, teu ngidinan analis ngakses shards husus dina klaster, tapi ngan saukur nyieun dua server kosong, tanpa data, sarta ngonpigurasikeun hak aksés dina eta. Dina hal ieu, setélan pamaké pikeun requests disebarkeun ditransferkeun ka server jauh. Nyaéta, anjeun ngonpigurasikeun sadayana dina dua server ieu, sareng setélanna gaduh pangaruh kana sadayana kluster.
Sacara prinsip, server ieu teu boga data, tapi jumlah RAM dina eta pohara penting pikeun executing requests. Disk ogé bisa dipaké pikeun data samentara lamun aggregation éksternal atawa asihan éksternal diaktipkeun.
Kadé katingal dina setélan nu pakait sareng sagala wates mungkin. Upami kuring ayeuna angkat ka klaster Yandex.Metrica salaku analis sareng naroskeun pamundut pilih cacah ti hits, teras kuring bakal langsung dipasihan pengecualian yén kuring henteu tiasa ngalaksanakeun pamundut éta. Jumlah maksimum baris anu kuring diidinan pikeun nyeken nyaéta saratus milyar, sareng jumlahna aya lima puluh triliun di antarana dina hiji méja dina kluster. Ieu watesan munggaran.
Hayu urang miceun wates baris sareng ngajalankeun pamundut deui. Teras kuring bakal ningali pengecualian di handap ieu - setélan diaktipkeun indéks gaya dumasar titimangsa. Abdi teu tiasa ngalengkepan pamundut lamun kuring teu nangtukeun rentang tanggal. Anjeun teu kedah ngandelkeun analis pikeun nangtukeun sacara manual. Kasus anu biasa nyaéta nalika rentang tanggal ditulis dimana tanggal kajadian antara minggu. Lajeng aranjeunna saukur dieusian bracket di tempat salah, sarta tinimbang na tétéla jadi atawa - atawa cocog URL. Upami teu aya watesna, éta bakal ngorondang kolom URL sareng ngan ukur ngabuang ton sumberdaya.
Salaku tambahan, ClickHouse gaduh dua setélan prioritas. Hanjakal, aranjeunna pisan primitif. Hiji ngan saukur disebut prioritas. Lamun prioritas ≠ 0, sarta requests kalawan sababaraha prioritas keur dieksekusi, tapi pamundut kalawan nilai prioritas kirang ti, nu hartina prioritas luhur, keur dieksekusi, teras pamundut kalawan nilai prioritas leuwih gede, nu hartina prioritas handap. , ngan saukur ditunda sareng moal tiasa dianggo dina waktos ieu.
Ieu mangrupikeun setting anu kasar sareng henteu cocog pikeun kasus dimana kluster ngagaduhan beban konstan. Tapi lamun boga pondok, requests bursty anu penting, sarta klaster lolobana dianggurkeun, setelan ieu cocog.
Setelan prioritas salajengna disebut Prioritas thread OS. Éta ngan saukur netepkeun nilai anu saé pikeun sadaya utas palaksanaan pamundut pikeun panjadwal Linux. Gawéna kitu-kitu, tapi tetep jalan. Upami anjeun netepkeun nilai anu saé minimum - éta mangrupikeun nilai anu panggedéna, sareng janten prioritas panghandapna - sareng nyetél -19 pikeun pamundut anu prioritasna luhur, teras CPU bakal ngonsumsi pamundut anu prioritasna kirang langkung opat kali langkung handap tina prioritas anu luhur.
Anjeun ogé kedah ngonpigurasikeun waktos palaksanaan pamundut maksimal - sebutkeun, lima menit. Laju minimum palaksanaan query mangrupikeun hal anu paling keren. Setelan ieu geus lila pisan, sarta eta diperlukeun henteu ngan pikeun negeskeun yén ClickHouse teu ngalambatkeun turun, tapi maksakeun eta.
Bayangkeun, anjeun nyetél: upami sababaraha prosés query kirang ti sajuta jajar per detik, anjeun moal tiasa ngalakukeun éta. Ieu disgraces ngaran alus urang, database alus urang. Hayu urang ngan larangan ieu. Sabenerna aya dua setélan. Hiji disebut speed palaksanaan mnt - dina garis per detik, sarta kadua disebut timeout saméméh mariksa speed palaksanaan mnt - lima belas detik sacara standar. Nyaéta, lima belas detik tiasa waé, teras, upami éta laun, teras miceun pengecualian sareng ngabatalkeun pamundut.
Anjeun ogé kedah nyetél kuota. ClickHouse boga fitur kuota diwangun-di nu diitung konsumsi sumberdaya. Tapi, hanjakalna, teu sumberdaya hardware kayaning CPU, disk, tapi logis - jumlah requests olahan, garis tur bait dibaca. Sareng anjeun tiasa ngonpigurasikeun, contona, maksimal saratus pamundut dina lima menit sareng sarébu pamundut per jam.
Naha éta penting? Kusabab sababaraha queries analytics bakal dilakukeun sacara manual langsung ti klien ClickHouse. Sareng sadayana bakal saé. Tapi upami anjeun gaduh analis canggih di perusahaan anjeun, aranjeunna bakal nyerat naskah, sareng tiasa aya kasalahan dina naskah. Sareng kasalahan ieu bakal nyababkeun pamundut dieksekusi dina loop anu henteu terbatas. Ieu naon urang kudu ngajaga diri tina.
Naha mungkin pikeun masihan hasil tina hiji pamundut ka sapuluh klien?
Kami ngagaduhan sababaraha pangguna anu resep sumping kalayan paménta anu ageung dina waktos anu sami. Paménta ageung sareng, prinsipna, dieksekusi gancang, tapi kusabab kanyataan yén aya seueur paménta sapertos kitu dina waktos anu sami, janten nyeri pisan. Naha mungkin pikeun ngalaksanakeun pamundut anu sami, anu sumping sapuluh kali berturut-turut, sakali, sareng masihan hasil ka sapuluh klien?
Masalahna nyaeta urang teu boga hasil tina cache atawa cache data panengah. Aya halaman cache tina sistem operasi, anu bakal nyegah anjeun tina maca data tina disk deui, tapi, hanjakalna, data masih bakal decompressed, deserialized na reprocessed.
Abdi hoyong kumaha bae nyingkahan ieu, boh ku cache data panengah, atawa ku ngajajar queries sarupa dina sababaraha jenis antrian jeung nambahkeun cache hasil. Urang ayeuna boga hiji pamundut narik dina ngembangkeun éta nambahkeun cache pamundut, tapi ngan pikeun subqueries di na gabung bagian - nyaeta, leyuran teu lengkep.
Nanging, urang ogé nyanghareupan kaayaan sapertos kitu. Hiji conto utamana canonical nyaeta paginated queries. Aya laporan, eta boga sababaraha kaca, tur aya nu menta wates 10. Lajeng hal anu sarua, tapi wates 10,10. Lajeng kaca salajengna. Sareng patarosanna, naha urang ngitung sadayana ieu unggal waktos? Tapi ayeuna teu aya solusi, sareng teu aya deui jalan pikeun nyingkahanana.
Aya solusi alternatif anu ditempatkeun salaku sidecar gigireun ClickHouse - .
Kirill Shvakov: ClickHouse Proxy gaduh pembatas laju anu diwangun sareng cache hasil anu diwangun. Seueur setélan anu dilakukeun di dinya kusabab masalah anu sami direngsekeun. Proxy ngidinan Anjeun pikeun ngawatesan requests ku antrian aranjeunna sarta ngonpigurasikeun sabaraha lila cache pamundut hirup. Lamun requests éta bener sarua, Proxy bakal dikirim aranjeunna sababaraha kali, tapi bakal balik ka ClickHouse ngan sakali.
Nginx ogé ngagaduhan cache dina versi gratis, sareng ieu ogé tiasa dianggo. Nginx malah gaduh setélan yén upami pamundut sumping dina waktos anu sami, éta bakal ngalambatkeun batur dugi ka réngsé. Tapi aya dina ClickHouse Proxy yén pangaturan parantos langkung saé. Éta dilakukeun khusus pikeun ClickHouse, khusus pikeun pamenta ieu, janten langkung cocog. Nya, éta gampang dipasang.
Kumaha upami operasi asynchronous sareng pintonan materialized?
Aya masalah anu operasi kalawan mesin replay asynchronous - mimitina data ditulis, lajeng collapses. Lamun tablet materialized kalawan sababaraha agrégat hirup di handapeun tanda, lajeng duplikat bakal ditulis ka dinya. Sareng upami teu aya logika anu kompleks, maka datana bakal duplikat. Naon anu anjeun tiasa lakukeun ngeunaan éta?
Aya solusi atra - pikeun nerapkeun pemicu dina kelas tangtu matviews salila operasi runtuhna Asynchronous. Naha aya pélor pérak atanapi rencana pikeun nerapkeun fungsionalitas anu sami?
Éta patut ngartos kumaha deduplication jalan. Naon anu kuring bakal nyarioskeun ka anjeun ayeuna henteu relevan pikeun patarosan, tapi upami anjeun kedah émut.
Nalika ngasupkeun kana tabel replicated, aya deduplication tina sakabéh blok diselapkeun. Upami anjeun nyelapkeun deui blok anu sami anu ngandung jumlah anu sami tina baris anu sami dina urutan anu sami, datana dideduplicated. Anjeun bakal nampa "Ok" dina respon kana sisipan, tapi dina kanyataanana hiji pakét data bakal ditulis, sarta eta moal duplicated.
Ieu diperlukeun pikeun kapastian. Upami anjeun nampi "Ok" nalika ngalebetkeun, maka data anjeun parantos diselapkeun. Upami anjeun nampi kasalahan tina ClickHouse, éta hartosna aranjeunna henteu diselapkeun sareng anjeun kedah ngulang sisipan éta. Tapi upami sambunganna rusak nalika diselapkeun, maka anjeun henteu terang naha datana diselapkeun atanapi henteu. Hiji-hijina pilihan nyaéta ngulang sisipan deui. Lamun data ieu sabenerna diselapkeun jeung anjeun reinserted eta, aya blok deduplication. Ieu diperlukeun pikeun nyegah duplikat.
Éta ogé penting kumaha gawéna pikeun pintonan materialized. Lamun data ieu deduplicated nalika diselapkeun kana tabel utama, mangka moal balik kana view materialized boh.
Ayeuna ngeunaan patarosan. Kaayaan anjeun langkung pajeulit sabab anjeun ngarékam duplikat garis individu. Hartina, teu sakabéh pak anu duplikat, tapi garis husus, sarta aranjeunna ambruk di tukang. Mémang, data bakal ambruk dina tabel utama, tapi data uncollapsed bakal balik ka view materialized, sarta salila merges nanaon bakal kajadian ka pintonan materialized. Kusabab pintonan materialized euweuh leuwih ti hiji pemicu sisipan. Salila operasi anu sanés, teu aya tambahan anu kajantenan.
Sareng kuring henteu tiasa ngajantenkeun anjeun bagja di dieu. Anjeun ngan kedah milarian solusi khusus pikeun hal ieu. Salaku conto, naha mungkin pikeun ngulang deui dina tampilan anu diwujudkeun, sareng metode deduplikasi tiasa dianggo ku cara anu sami. Tapi hanjakalna, teu salawasna. Lamun éta aggregating, éta moal jalan.
Kirill Shvakov: Urang ogé kungsi konstruksi kruk deui dina poé. Aya masalah anu aya tayangan iklan, sareng aya sababaraha data anu tiasa kami tunjukkeun sacara real waktos - ieu ngan ukur tayangan. Aranjeunna jarang duplikat, tapi lamun ieu kajadian, urang bakal ambruk aranjeunna engké atoh. Sareng aya hal anu teu tiasa diduplikasi - klik sareng sadayana carita ieu. Tapi kuring ogé hoyong nunjukkeun aranjeunna ampir langsung.
Kumaha pintonan materialized dijieun? Aya pintonan dimana eta ditulis langsung - ieu ditulis kana data atah, sarta ditulis ka pintonan. Aya, di sawatara titik data teu bener pisan, éta duplikat, jeung saterusna. Sareng aya bagian kadua tabel, dimana aranjeunna katingalina sami sareng pandangan materialized, nyaéta, strukturna sami pisan. Sakali-kali urang ngitung deui data, ngitung data tanpa duplikat, nyerat kana tabél éta.
Urang ngaliwat API - ieu moal jalan di ClickHouse sacara manual. Jeung API Sigana: lamun kuring boga tanggal tina tambahan panungtungan pikeun tabél, dimana eta dijamin yén data bener geus diitung, sarta ngajadikeun hiji pamundut ka hiji méja jeung ka méja sejen. Ti hiji pamundut milih nepi ka jumlah waktu nu tangtu, sarta ti nu séjén meunang naon teu acan diitung. Sarta gawéna, tapi teu ngaliwatan ClickHouse nyalira.
Upami anjeun gaduh sababaraha jinis API - pikeun analis, pikeun pangguna - teras, prinsipna, ieu mangrupikeun pilihan. Anjeun salawasna cacah, salawasna cacah. Ieu tiasa dilakukeun sakali sapoé atanapi dina waktos anu sanés. Anjeun milih pikeun diri sauntuyan anu anjeun henteu peryogikeun sareng henteu kritis.
ClickHouse ngagaduhan seueur log. Kumaha carana abdi tiasa ningali sagalana yén kajadian ka server di glance a?
ClickHouse ngagaduhan sajumlah ageung log anu béda, sareng jumlah ieu ningkat. Dina vérsi énggal, sababaraha di antarana diaktipkeun sacara standar; dina vérsi anu langkung lami aranjeunna kedah diaktipkeun nalika ngapdet. Sanajan kitu, aya beuki loba di antarana. Pamustunganana, abdi hoyong ningali naon anu lumangsung kalawan server abdi ayeuna, meureun dina sababaraha jenis dasbor kasimpulan.
Naha anjeun gaduh tim ClickHouse anjeun, atanapi di tim réréncangan anjeun, anu ngadukung sababaraha pungsionalitas dasbor siap-siap anu bakal nampilkeun log ieu salaku produk anu siap-siap? Pamustunganana, ngan ukur ningali log di ClickHouse saé. Tapi bakal tiis pisan upami éta parantos disiapkeun dina bentuk dasbor. Kuring bakal meunang tajongan kaluar ti eta.
Aya dasbor, sanaos henteu standar. Di perusahaan kami, sakitar 60 tim nganggo ClickHouse, sareng anu paling anéh nyaéta seueur di antarana gaduh dasbor anu didamel pikeun diri, sareng anu rada béda. Sababaraha tim nganggo pamasangan Yandex.Cloud internal. Aya sababaraha laporan anu siap-siap, sanaos henteu sadayana anu diperyogikeun. Lain boga sorangan.
kolega kuring ti Metrica boga dasbor sorangan di Grafana, sarta kuring boga sorangan pikeun klaster maranéhna. Kuring nempo hal kawas cache hit pikeun cache serif. Sareng anu langkung hese nyaéta urang ngagunakeun alat anu béda. Kuring nyiptakeun dasbor kuring nganggo alat anu lami pisan anu disebut Graphite-web. Anjeunna sagemblengna awon. Sareng kuring masih ngagunakeun cara ieu, sanaos Grafana sigana bakal langkung merenah sareng éndah.
Hal dasar dina dashboards sarua. Ieu mangrupikeun métrik sistem pikeun kluster: CPU, mémori, disk, jaringan. Batur - Jumlah requests simultaneous, Jumlah merges simultaneous, Jumlah requests per detik, Jumlah maksimum sakumpulan pikeun partitions tabel MergeTree, réplikasi lag, ukuran antrian réplikasi, Jumlah baris diselapkeun per detik, Jumlah diselapkeun blok per detik. Ieu sadayana anu dicandak sanés tina log, tapi tina métrik.
Vladimir Kolobaev: Alexey, Abdi hoyong ngalereskeun eta saeutik. Aya Grafana. Grafana gaduh sumber data, nyaéta ClickHouse. Maksudna, abdi tiasa ngadamel requests ti Grafana langsung ka ClickHouse. ClickHouse boga tabel kalawan log, éta sarua for everyone. Hasilna, kuring hoyong ngaksés tabel log ieu di Grafana sareng ningali pamundut anu dilakukeun ku server kuring. Hadé pisan mun gaduh dasbor sapertos kieu.
Kuring biked eta sorangan. Tapi kuring gaduh patarosan - upami éta sadayana standar, sareng Grafana dianggo ku sadayana, naha Yandex henteu gaduh dasbor resmi sapertos kitu?
Kirill Shvakov: Nyatana, sumber data anu nuju ka ClickHouse ayeuna ngadukung Altinity. Sareng kuring ngan ukur hoyong masihan vektor dimana ngagali sareng saha anu nyorong. Anjeun tiasa naroskeun ka aranjeunna, sabab Yandex masih ngadamel ClickHouse, sanés carita di sabudeureun éta. Altinity mangrupikeun perusahaan utama anu ayeuna promosi ClickHouse. Aranjeunna moal ngantunkeun anjeunna, tapi bakal ngadukung anjeunna. Kusabab, prinsipna mah, pikeun unggah dasbor ka situs web Grafana, anjeun ngan ukur kedah ngadaptar sareng unggah - teu aya masalah khusus.
Alexey Milovidov: Sapanjang taun katukang, ClickHouse parantos nambihan seueur kamampuan profiling query. Aya metrics pikeun tiap pamundut on sumberdaya pamakéan. Sareng nembé nembé, kami nambihan profiler pamundut tingkat langkung handap pikeun ningali dimana pamundut anu nyéépkeun unggal milidetik. Tapi pikeun ngagunakeun fungsionalitas ieu, kuring kedah muka klien konsol sareng ngetik pamundut, anu kuring sok hilap. Kuring disimpen wae terus poho dimana persis.
Kuring miharep aya alat nu ngan ceuk, didieu aya queries beurat anjeun, dikelompokeun ku kelas query. Kuring mencet on hiji, sarta aranjeunna bakal ngabejaan ka kuring yen éta naha éta beurat. Teu aya solusi sapertos ayeuna. Sareng leres-leres anéh yén nalika jalma naros ka kuring: "Béjakeun ka kuring, naha aya dasbor anu siap-siap pikeun Grafana?", Kuring nyarios: "Pindah ka situs wéb Grafana, aya komunitas "Dasbor", sareng aya dasbor. ti Dimka, aya dasbor ti Kostyan. Kuring henteu terang naon éta, kuring henteu acan dianggo nyalira. ”
Kumaha pangaruh merges supados server henteu ngadat kana OOM?
Kuring boga méja, aya ngan hiji partisi dina tabél, éta ReplacingMergeTree. Kuring geus nulis data kana eta pikeun opat taun. Abdi peryogi ngadamel parobihan sareng mupus sababaraha data.
Kuring ngalakukeun ieu, sareng nalika ngolah pamundut ieu, sadaya mémori dina sadaya server dina kluster dihakan, sareng sadaya server dina kluster angkat ka OOM. Lajeng aranjeunna sadayana gugah babarengan, dimimitian merging operasi sarua ieu, blok data ieu, sarta murag kana OOM deui. Tuluy maranehna hudang deui jeung murag deui. Jeung hal ieu teu eureun.
Lajeng tétéla yén ieu sabenerna bug nu guys dibereskeun. Ieu pisan keren, hatur nuhun pisan. Tapi résidu tetep. Sareng ayeuna, nalika kuring mikir ngeunaan nyieun sababaraha jinis ngahiji dina tabél, kuring gaduh patarosan - naha kuring henteu tiasa mangaruhan kumaha waé gabungan ieu? Contona, ngawatesan aranjeunna ku jumlah RAM diperlukeun, atawa, prinsipna mah, ku jumlah anu bakal ngolah tabel husus ieu.
Kuring boga tabel disebut "Metrics", mangga ngolah eta keur kuring dina dua threads. Teu perlu nyieun sapuluh atawa lima merges di paralel, ngalakukeun eta dina dua. Jigana mah geus cukup memori pikeun dua, tapi bisa jadi teu cukup pikeun ngolah sapuluh. Naha sieun tetep? Kusabab tabél na tumuwuh, sarta someday kuring bakal Nyanghareupan kaayaan anu, prinsipna mah, geus euweuh alatan bug, tapi kusabab data bakal robah dina jumlah badag misalna yén kuring ngan saukur moal boga cukup memori dina. server. Lajeng server bakal ngadat kana OOM nalika merging. Sumawona, abdi tiasa ngabatalkeun mutasi, tapi Merji geus euweuh.
Anjeun terang, nalika merging, server moal digolongkeun kana OOM, sabab nalika merging, jumlah RAM dipaké ngan pikeun hiji rentang leutik data. Janten sadayana bakal saé henteu paduli jumlah data.
Vladimir Kolobaev: muhun. Di dieu momen misalna yén sanggeus bug ieu dibereskeun, abdi diundeur versi anyar keur kuring sorangan, sarta dina tabel sejen, hiji leutik, dimana aya loba partitions, abdi ngalakukeun operasi sarupa. Jeung salila ngahiji, ngeunaan 100 GB RAM ieu dibeuleum dina server. Kuring kungsi 150 nempatan, 100 didahar, sarta 50 GB jandela ditinggalkeun, jadi kuring teu digolongkeun kana OOM.
Naon ayeuna ngajaga kuring tina ragrag kana OOM lamun sabenerna meakeun 100 GB RAM? Naon anu kudu dipigawé lamun ujug-ujug RAM dina merges ngalir kaluar?
Alexey Milovidov: Aya masalah sapertos anu konsumsi RAM husus pikeun merging teu diwatesan. Sareng masalah anu kadua nyaéta upami sababaraha jinis gabungan parantos ditugaskeun, maka éta kedah dieksekusi sabab kacatet dina log réplikasi. Log réplikasi nyaéta tindakan anu diperyogikeun pikeun mawa réplika kana kaayaan anu konsisten. Upami anjeun henteu ngalakukeun manipulasi manual anu bakal ngagulung deui log réplikasi ieu, ngahiji kedah dilakukeun ku cara anu sanés.
Tangtosna, éta henteu langkung ageung pikeun gaduh watesan RAM anu "ngan bisi" ngajagaan tina OOM. Éta moal ngabantosan ngahiji pikeun ngarengsekeun, éta bakal ngamimitian deui, ngahontal sababaraha bangbarung, ngalungkeun iwal, teras ngamimitian deui - moal aya anu hadé tina ieu. Tapi prinsipna mah, bakal mangpaat pikeun ngawanohkeun larangan ieu.
Kumaha supir Golang pikeun ClickHouse bakal dikembangkeun?
Supir Golang, anu ditulis ku Kirill Shvakov, ayeuna sacara resmi dirojong ku tim ClickHouse. Anjeunna , anjeunna ayeuna badag tur nyata.
Catetan leutik. Aya gudang éndah tur tercinta tina bentuk normal tina urutan taya - ieu Vertica. Éta ogé gaduh supir python resmi sorangan, anu dirojong ku pamekar Vertica. Sareng sababaraha kali kajantenan yén versi panyimpenan sareng vérsi supir diverged sacara dramatis, sareng supirna lirén damel. Jeung titik kadua. Rojongan pikeun supir resmi ieu, sigana kuring, dilumangsungkeun ku sistem "nipple" - anjeun nulis eta masalah, sarta eta hangs salawasna.
Abdi gaduh dua patarosan. Ayeuna supir Golang Kirill ampir cara standar pikeun komunikasi ti Golang sareng ClickHouse. Iwal batur masih communicates via panganteur http sabab anjeunna resep eta cara éta. Kumaha bakal ngembangkeun supir ieu? Naha éta bakal disingkronkeun sareng parobihan anu rusak dina gudang sorangan? Sareng naon prosedur pikeun nganggap hiji masalah?
Kirill Shvakov: Anu kahiji nyaéta kumaha sadayana diatur sacara birokrasi. Poin ieu teu dibahas, jadi kuring teu boga jawaban.
Pikeun ngajawab patarosan ngeunaan masalah, urang kudu saeutik sajarah supir. Kuring digawé pikeun parusahaan nu miboga loba data. Éta mangrupikeun spinner pariwara kalayan sajumlah ageung acara anu kedah disimpen di mana waé. Sarta di sawatara titik ClickHouse mucunghul. Urang dieusian ku data, sarta mimitina sagalana éta rupa, tapi lajeng ClickHouse nabrak. Dina momen éta kami mutuskeun yén kami henteu peryogi éta.
Sataun saterusna, urang balik deui ka pamanggih ngagunakeun ClickHouse, sarta kami diperlukeun pikeun nulis data aya kumaha bae. Pesen bubuka ieu: hardware pisan lemah, aya sababaraha sumber. Tapi kami geus salawasna digawé cara kieu, sarta ku kituna urang nempo ka arah protokol asli.
Kusabab kami digawé di Go, éta jelas yén kami diperlukeun supir Go. Kuring ngalakukeun éta ampir pinuh waktos - éta tugas padamelan abdi. Urang dibawa ka titik nu tangtu, sarta prinsipna mah taya sahijieun nganggap yén saha lian ti urang bakal ngagunakeun eta. Lajeng CloudFlare sumping kalawan persis masalah anu sarua, sarta pikeun sawatara waktu urang digawé kalayan aranjeunna pisan lancar, sabab maranéhna miboga tugas anu sarua. Sumawona, urang ngalakukeun ieu dina ClickHouse sorangan sareng dina supir.
Di sawatara titik, kuring ngan saukur dieureunkeun ngalakukeun eta, sabab aktivitas kuring dina watesan ClickHouse jeung karya robah saeutik. Ku alatan éta, masalah teu ditutup. Périodik, jalma anu peryogi hal sorangan komitmen ka Repository nu. Teras kuring ningali paménta tarik sareng sakapeung kuring ngédit hal sorangan, tapi ieu jarang kajadian.
Abdi hoyong uih deui ka supir. Sababaraha taun ka pengker, nalika sadayana ieu dimimitian, ClickHouse ogé béda sareng kamampuan anu béda. Ayeuna urang gaduh pamahaman kumaha ngadamel ulang supir supados tiasa dianggo saé. Upami ieu kajadian, versi 2 bakal sauyunan dina sagala hal alatan crutches akumulasi.
Kuring henteu weruh kumaha carana ngatur urusan ieu. Kuring teu boga loba waktu sorangan. Lamun sababaraha urang rengse supir, abdi tiasa mantuan aranjeunna sarta ngabejaan aranjeunna naon nu kudu. Tapi partisipasi aktif Yandex dina ngembangkeun proyék teu acan dibahas.
Alexey Milovidov: Nyatana, teu acan aya birokrasi ngeunaan supir ieu. Hiji-hijina hal anu aranjeunna dikintunkeun ka organisasi resmi, nyaéta, supir ieu diakuan salaku solusi standar resmi pikeun Go. Aya sababaraha drivers séjén, tapi datangna misah.
Kami henteu ngagaduhan pamekaran internal pikeun supir ieu. Patarosanna naha urang tiasa nyéwa hiji jalma, sanés pikeun supir khusus ieu, tapi pikeun pamekaran sadaya supir komunitas, atanapi tiasa urang mendakan batur ti luar.
Kamus éksternal henteu dimuat saatos reboot sareng setelan lazy_load diaktipkeun. Naon anu kedah dilakukeun?
Urang boga setelan lazy_load diaktipkeun, sarta sanggeus server rebooted, kamus teu dimuat sorangan. Ieu diangkat ngan sanggeus pamaké ngakses kamus ieu. Sareng pertama kalina kuring ngaksés éta, éta masihan kasalahan. Naha mungkin kumaha waé sacara otomatis ngamuat kamus nganggo ClickHouse, atanapi anjeun kedah salawasna ngontrol kesiapanna sorangan supados pangguna henteu nampi kasalahan?
Panginten urang gaduh versi ClickHouse anu lami, janten kamus henteu otomatis dimuat. Bisa jadi kieu?
Kahiji, kamus bisa dipaksa dimuat maké query kamus ulang sistem. Kadua, ngeunaan kasalahan - upami kamus parantos dimuat, maka patarosan bakal dianggo dumasar kana data anu dimuat. Lamun kamus teu acan dimuat, éta bakal dimuat langsung salila pamundut.
Ieu teu merenah pisan pikeun kamus beurat. Salaku conto, anjeun kedah narik sajuta jajar tina MySQL. Batur ngajadikeun hiji pilih basajan, tapi pilih ieu bakal ngantosan sami juta barisan. Aya dua solusi di dieu. Anu kahiji nyaéta mareuman lazy_load. Bréh, nalika server up, saméméh nempatkeun beban dina eta, ngalakukeun kamus ulang sistem atawa ngan ngalakukeun query anu ngagunakeun kamus. Lajeng kamus bakal dimuat. Anjeun kedah ngadalikeun kasadiaan kamus sareng setelan lazy_load diaktipkeun, sabab ClickHouse henteu otomatis ngamuat aranjeunna.
Jawaban kana patarosan anu terakhir nyaéta versi anu lami atanapi kedah di-debug.
Naon anu kudu dilakukeun ku kanyataan yén kamus ngamuat sistem henteu ngamuat salah sahiji tina seueur kamus upami sahenteuna salah sahiji nabrak ku kasalahan?
Aya patarosan sanés ngeunaan kamus ulang sistem. Kami gaduh dua kamus - hiji henteu dimuat, anu kadua dimuat. Dina hal ieu, kamus reload System henteu ngamuat kamus naon waé, sareng anjeun kedah ngamuat titik-demi-titik anu khusus ku namina nganggo kamus ulang sistem. Ieu ogé patali jeung versi ClickHouse?
Abdi hoyong ngabahagiakeun anjeun. kabiasaan ieu robah. Ieu ngandung harti yén lamun ngamutahirkeun ClickHouse, éta ogé bakal robah. Lamun anjeun teu senang jeung kabiasaan anjeun ayeuna kamus ulang sistem, update, sarta hayu urang miharep éta robah jadi hadé.
Aya cara pikeun ngonpigurasikeun rinci dina config ClickHouse, tapi teu nembongkeun aranjeunna bisi kasalahan?
Patarosan satuluyna ngeunaan kasalahan anu patali jeung kamus, nyaéta detil. Kami parantos netepkeun detil sambungan dina config ClickHouse pikeun kamus, sareng upami aya kasalahan, kami nampi detil sareng kecap konci ieu pikeun ngaréspon.
Urang direngsekeun kasalahan ieu ku nambahkeun rinci kana config supir ODBC. Naha aya cara pikeun ngonpigurasikeun detil dina konfigurasi ClickHouse, tapi henteu nunjukkeun detil ieu upami aya kasalahan?
Solusi nyata di dieu nyaeta pikeun nangtukeun Kapercayaan ieu dina odbc.ini, sarta di ClickHouse sorangan tangtukeun ngan ODBC Ngaran Sumber Data. Ieu moal kajantenan pikeun sumber kamus sanés - boh pikeun kamus nganggo MySQL, atanapi pikeun anu sanés, anjeun henteu kedah ningali kecap konci nalika anjeun nampi pesen kasalahan. Pikeun ODBC, kuring ogé bakal ningali - upami aya, anjeun kedah ngahapus.
Bonus: latar pikeun Zoom tina rapat
Ku ngaklik gambar, latar tukang bonus tina rapat bakal dibuka pikeun pamiarsa anu paling pengkuh. Urang mareuman seuneu babarengan sareng maskot téknologi Avito, urang ngobrol sareng kolega ti kamar administrator sistem atanapi klub komputer sakola lami, sareng urang ngalaksanakeun rapat sapopoé di handapeun sasak ngalawan latar tukang corétan.
sumber: www.habr.com