HighLoad ++ Moscow 2018, Aula Kongrés. Nopember 9, 15:00
Abstrak jeung presentasi:
Yuri Nasretdinov (VKontakte): laporan bakal ngobrol ngeunaan pangalaman ngalaksanakeun ClickHouse di parusahaan urang - naha urang peryogi eta, sabaraha data urang nyimpen, kumaha urang nulis eta, jeung saterusna.
Bahan tambahan:
Yuri Nasretdinov: - Halo sadayana! Ngaran abdi Yuri Nasretdinov, sakumaha kuring geus diwanohkeun. Abdi damel di VKontakte. Kuring bakal ngobrol ngeunaan kumaha urang ngalebetkeun data kana ClickHouse tina armada server kami (puluhan rébu).
Naon log sareng naha ngumpulkeunana?
Naon anu bakal kami nyarioskeun ka anjeun: naon anu urang laksanakeun, naha urang peryogi "ClickHouse", masing-masing, naha urang milih éta, kumaha kinerja anu anjeun tiasa kéngingkeun tanpa ngonpigurasikeun naon waé khusus. Kuring gé ngabejaan Anjeun salajengna ngeunaan tabel panyangga, ngeunaan masalah urang tadi sareng aranjeunna sarta ngeunaan solusi urang nu urang dimekarkeun tina open source - KittenHouse jeung Mercusuar.
Naha urang kedah ngalakukeun nanaon pisan (sadayana salawasna alus dina VKontakte, katuhu?). Urang hayang ngumpulkeun log debug (jeung aya ratusan terabytes data aya), meureun kumaha bae eta bakal leuwih merenah keur ngitung statistik; sarta kami boga armada puluhan rébu server ti mana sagala ieu perlu dipigawé.
Naha urang mutuskeun? Urang sigana ngagaduhan solusi pikeun nyimpen log. Di dieu - aya publik sapertos "Backend VK". Abdi nyarankeun pisan ngalanggan éta.
Naon log? Ieu mesin nu mulih arrays kosong. Mesin di VK mangrupikeun anu disebat ku batur microservices. Sareng ieu mangrupikeun stiker seuri (rada seueur anu resep). Kumaha? Muhun, dengekeun salajengna!
Naon anu tiasa dianggo pikeun nyimpen log? Mustahil mun teu nyebut Hadup. Teras, contona, Rsyslog (nyimpen log ieu dina file). LSD. Saha anu terang naon LSD? Henteu, sanés LSD ieu. Simpen file, masing-masing ogé. Nya, ClickHouse mangrupikeun pilihan anu anéh.
Clickhouse sareng pesaing: syarat sareng kasempetan
Urang hayang naon? Simkuring hoyong mastikeun yén urang teu kudu salempang teuing ngeunaan operasi, meh tiasa dianggo out of the box, preferably kalawan konfigurasi minimal. Urang rék nulis loba, jeung nulis gancang. Sarta kami hayang tetep eta pikeun sagala sorts bulan, taun, nyaeta, keur lila. Urang panginten hoyong ngartos sababaraha masalah anu aranjeunna sumping ka kami sareng nyarios, "Aya anu teu tiasa dianggo di dieu," sareng éta 3 sababaraha bulan kapengker), sareng urang hoyong ningali naon anu kajantenan 3 bulan kapengker " Komprési data - éta jelas naha éta bakal tambah - sabab ngurangan jumlah spasi nu diperlukeun nepi.
Sareng urang gaduh sarat anu pikaresepeun sapertos kitu: urang kadang nyerat kaluaran sababaraha paréntah (contona, log), éta tiasa langkung ti 4 kilobyte kalayan gampang. Tur upami hal ieu jalan leuwih UDP, mangka teu perlu méakkeun ... eta moal boga naon "overhead" pikeun sambungan, sarta pikeun angka nu gede ngarupakeun server ieu bakal tambah.
Hayu urang tingali naon open source nawiskeun urang. Firstly, urang boga Log Engine - ieu mesin urang; Sacara prinsip, anjeunna tiasa ngalakukeun sagalana, malah bisa nulis garis panjang. Nya, éta henteu sacara transparan ngompres data - urang tiasa ngompres kolom ageung upami urang hoyong ... urang, tangtosna, henteu hoyong (upami mungkin). Hiji-hijina masalah nyaéta yén anjeunna ngan ukur tiasa masihan naon anu pas dina mémorina; Maca sésana, Anjeun kudu meunang binlog mesin ieu, sarta, sasuai, waktu nu diperlukeun rada lila.
Naon pilihan séjén aya? Contona, "Hadup". Gampang operasi ... Saha anu nyangka Hadup gampang diatur? Tangtosna, teu aya masalah sareng ngarékam. Nalika maca, patarosan kadang timbul. Sacara prinsip, kuring bakal nyebutkeun meureun moal, utamana pikeun log. Panyimpen jangka panjang - tangtosna, leres, komprési data - leres, senar panjang - jelas yén anjeun tiasa ngarékam. Tapi ngarékam tina sajumlah ageung server ... Anjeun masih kedah ngalakukeun hal sorangan!
Rsyslog. Nyatana, kami nganggo éta salaku pilihan cadangan supados urang tiasa maca éta tanpa ngaleungitkeun binlog, tapi éta henteu tiasa nyerat garis panjang; prinsipna, éta henteu tiasa nyerat langkung ti 4 kilobyte. Anjeun kedah ngalakukeun komprési data dina cara anu sami. Maca bakal asalna tina file.
Lajeng aya ngembangkeun "badushka" LSD. Intina sami sareng "Rsyslog": éta ngadukung senar panjang, tapi teu tiasa dianggo via UDP sareng, kanyataanna, kusabab ieu, hanjakalna, seueur hal anu kedah ditulis deui di dinya. LSD kedah didesain ulang supados tiasa ngarékam tina puluhan rébu server.
Jeung di dieu! Pilihan anu lucu nyaéta ElasticSearch. Kumaha carana nyarios? Anjeunna nuju saé maca, nyaéta, anjeunna maca gancang, tapi henteu saé pisan dina nyerat. Firstly, lamun compresses data, éta pisan lemah. Paling dipikaresep, pilarian pinuh merlukeun struktur data leuwih badag batan volume aslina. Hese beroperasi sareng masalah sering timbul sareng éta. Sareng, deui, ngarékam dina Elastis - urang kedah ngalakukeun sadayana nyalira.
Di dieu ClickHouse mangrupa pilihan idéal, tangtu. Hiji-hijina hal nyaéta ngarékam tina puluhan rébu server mangrupikeun masalah. Tapi sahenteuna aya hiji masalah, urang tiasa nyobian pikeun ngajawab eta kumaha bae. Jeung sesa laporan ngeunaan masalah ieu. Jenis kinerja anjeun tiasa nyangka ti ClickHouse?
Kumaha urang badé ngalebetkeunana? MergeTree
Saha diantara anjeun anu teu acan uninga atanapi terang ngeunaan "ClickHouse"? Abdi kedah nyarioskeun ka anjeun, sanés? Gancang pisan. Selapkeun aya - 1-2 gigabits per detik, bursts nepi ka 10 gigabits per detik sabenerna bisa tahan konfigurasi ieu - aya dua 6-inti Xeons (nyaéta, malah teu pangkuatna), 256 gigabytes RAM, 20 terabytes. di RAID (teu aya anu ngonpigurasi, setélan standar). Alexey Milovidov, pamekar ClickHouse, meureun diuk aya nangis sabab urang teu ngonpigurasikeun nanaon (sagalana digawé kawas éta pikeun urang). Sasuai, laju scanning, sebutkeun, ngeunaan 6 miliar garis per detik tiasa didapet lamun data ieu ogé dikomprés. Upami anjeun resep% dina senar téks - 100 juta garis per detik, nyaéta, sigana gancang pisan.
Kumaha urang badé ngalebetkeunana? Nya, anjeun terang yén VK nganggo PHP. Urang bakal nyelapkeun ti unggal worker PHP via HTTP kana "ClickHouse", kana tabel MergeTree pikeun tiap rékaman. Saha anu ningali masalah sareng skéma ieu? Kanggo sababaraha alesan, teu sadaya jelema ngangkat leungeun maranéhna. Hayu atuh ngabejaan Anjeun.
Anu mimiti, aya seueur server - sasuai, bakal aya seueur sambungan (goréng). Mangka langkung saé nyelapkeun data kana MergeTree henteu langkung sering ti sakali per detik. Sareng saha anu terang naha? Oké, oké. Kuring gé ngabejaan Anjeun saeutik ngeunaan ieu. Patarosan metot séjén nyaéta yén urang teu ngalakukeun analytics, urang teu kudu enrich data, urang teu kedah server panengah, urang rék nyelapkeun langsung kana "ClickHouse" (preferably - leuwih langsung, nu hadé).
Sasuai, kumaha insersi dilakukeun dina MergeTree? Naha éta hadé pikeun nyelapkeun kana éta henteu langkung sering ti sakali sadetik atanapi kirang sering? Kanyataanna nyaéta "ClickHouse" mangrupikeun pangkalan data kolom sareng nyortir data dina urutan naek tina konci primér, sareng nalika anjeun ngalakukeun sisipan, sajumlah file didamel sahenteuna sami sareng jumlah kolom dimana data diurutkeun. dina urutan naek tina konci primér (diréktori misah dijieun, susunan file dina disk pikeun tiap sisipan). Teras sisipan salajengna sumping, sareng di latar tukang aranjeunna digabungkeun kana "partisi" anu langkung ageung. Kusabab data diurutkeun, kasebut nyaéta dimungkinkeun pikeun "ngagabung" dua file diurutkeun tanpa consuming loba memori.
Tapi, anjeun bisa nebak, lamun nulis 10 file pikeun tiap sisipan, teras ClickHouse (atawa server anjeun) bakal gancang mungkas, jadi eta disarankeun pikeun nyelapkeun dina bets badag. Sasuai, urang pernah dibuka skéma munggaran kana produksi. Kami langsung ngaluncurkeun hiji, anu di dieu No. 2 ngagaduhan:
Di dieu ngabayangkeun yén aya ngeunaan sarébu server on nu urang geus dibuka, aya ngan PHP. Sarta dina unggal server aya agén lokal urang, nu urang disebut "Kittenhouse", nu ngajaga hiji sambungan kalawan "ClickHouse" na inserts data unggal sababaraha detik. Inserts data teu kana MergeTree, tapi kana tabel panyangga, anu fungsina persis pikeun nyegah inserting langsung kana MergeTree langsung.
Gawe sareng tabel panyangga
Naon éta? tabél panyangga mangrupakeun sapotong memori anu sharded (nyaeta, eta bisa diselapkeun kana eta sering). Éta diwangun ku sababaraha lembar, sarta unggal potongan dianggo salaku panyangga bebas, sarta aranjeunna flushed bebas (lamun boga loba potongan dina panyangga, lajeng bakal loba inserts per detik). Kasebut nyaéta dimungkinkeun pikeun maca tina tabel ieu - lajeng maca union eusi panyangga jeung tabel indungna, tapi dina momen ieu nulis diblokir, jadi eta leuwih hade teu maca ti dinya. Sareng tabel panyangga nunjukkeun QPS anu saé, nyaéta, dugi ka 3 rébu QPS anjeun moal ngagaduhan masalah nalika ngalebetkeun. Ieu jelas yén lamun server leungit kakuatan, data bisa leungit, sabab ngan disimpen dina mémori.
Dina waktu nu sarua, skéma kalawan panyangga a complicates ALTER, sabab mimitina anjeun kudu leupaskeun tabel panyangga heubeul kalawan skéma heubeul (data moal ngaleungit mana, sabab bakal flushed saméméh tabél dihapus). Satuluyna anjeun "ngarobah" tabel nu peryogi tur jieun tabel panyangga deui. Sasuai, bari euweuh méja panyangga, data anjeun moal ngalir mana, tapi anjeun bisa mibanda eta dina disk sahenteuna lokal.
Naon Kittenhouse sareng kumaha jalanna?
Naon ari KittenHouse? Ieu proxy. Tebak basa naon? Kuring ngumpulkeun topik anu paling hype dina laporan kuring - "Clickhouse", Go, meureun kuring bakal émut anu sanés. Leres, ieu ditulis dina Go, sabab kuring henteu terang kumaha nyerat dina C, kuring henteu hoyong.
Sasuai, eta mertahankeun sambungan kalawan unggal server na bisa nulis ka memori. Salaku conto, upami urang nyerat log kasalahan ka Clickhouse, teras upami Clickhouse teu gaduh waktos nyelapkeun data (sanggeus sadayana, upami seueur teuing ditulis), maka urang henteu ngabareuhan mémori - urang ngan saukur buang sésana. Kusabab upami urang nyerat sababaraha gigabit per detik kasalahan, maka urang sigana tiasa ngalungkeun sababaraha. Kittenhouse tiasa ngalakukeun ieu. Tambih Deui, éta tiasa ngalaksanakeun pangiriman anu dipercaya, nyaéta, nyerat kana disk dina mesin lokal sareng sakali unggal waktos (aya, sakali unggal sababaraha detik) nyobian ngirim data tina file ieu. Sareng mimitina kami nganggo format Nilai biasa - sanés sababaraha format binér, format téks (sapertos dina SQL biasa).
Tapi lajeng ieu kajadian. Urang dipaké pangiriman dipercaya, nulis log, lajeng mutuskeun (éta klaster test kondisional) ... Ieu nempatkeun kaluar pikeun sababaraha jam sarta dibawa deui nepi, sarta sisipan dimimitian ti sarébu server - tétéla yén Clickhouse masih miboga a "Thread on sambungan" - sasuai, dina sarébu sambungan, hiji sisipan aktip ngabalukarkeun rata beban dina server ngeunaan hiji satengah sarébu. Ahéng, server narima requests, tapi data ieu masih diselapkeun sanggeus sababaraha waktu; tapi éta hésé pisan pikeun server pikeun ngalayanan éta ...
Tambahkeun nginx
Solusi sapertos kanggo Thread per modél sambungan nyaéta nginx. Kami masang nginx di payuneun Clickhouse, dina waktos anu sami nyetél balancing pikeun dua réplika (kagancangan sisipan kami ningkat ku 2 kali, sanaos sanés kanyataan yén ieu kedahna) sareng ngawatesan jumlah sambungan ka Clickhouse, ka hulu jeung, sasuai, leuwih , ti dina 50 sambungan, sigana euweuh titik inserting.
Teras we sadar yén skéma ieu umumna ngagaduhan kalemahan, sabab kami ngan ukur gaduh hiji nginx di dieu. Sasuai, lamun nginx ieu ngadat, sanajan ayana réplika, urang leungit data atawa, sahenteuna, ulah nulis mana. Éta sababna urang ngadamel kasaimbangan beban urang sorangan. Urang ogé sadar yén "Clickhouse" masih cocog pikeun log, sarta "sétan" ogé mimiti nulis log na di "Clickhouse" - pisan merenah, mun jujur. Urang masih make eta pikeun séjén "setan".
Teras kami mendakan masalah anu pikaresepeun ieu: upami anjeun nganggo metodeu non-standar pikeun nyelapkeun dina modeu SQL, éta maksakeun parser SQL basis AST anu lengkep, anu rada laun. Sasuai, kami geus ditambahkeun setélan pikeun mastikeun yén ieu pernah kajadian. Urang ngalakukeun load balancing, cek kaséhatan, ku kituna lamun hiji maot, urang masih ninggalkeun data. Urang ayeuna geus rada loba tabel nu urang kudu boga klaster Clickhouse béda. Sareng urang ogé mimiti mikir ngeunaan kagunaan anu sanés - contona, urang hoyong nyerat log tina modul nginx, tapi aranjeunna henteu terang kumaha komunikasi nganggo RPC kami. Nya, kuring hoyong ngajar aranjeunna kumaha ngirim sahenteuna kumaha waé - contona, pikeun nampi acara dina localhost via UDP teras teraskeun ka Clickhouse.
Hiji léngkah jauh tina solusi
Skéma final mimiti kasampak kawas kieu (versi kaopat tina skéma ieu): dina unggal server di hareup Clickhouse aya nginx (dina server sarua) jeung ngan saukur proxies requests ka localhost kalawan wates dina jumlah sambungan 50. popotongan. Sareng skéma ieu parantos cekap damel, sadayana lumayan saé.
Urang hirup saperti kieu salila kira sabulan. Sarerea éta senang, aranjeunna ditambahkeun tabel, aranjeunna ditambahkeun, aranjeunna ditambahkeun ... Sacara umum, tétéla yén cara kami nambahkeun tabel panyangga teu pisan optimal (hayu urang nempatkeun eta cara). Urang ngalakukeun 16 lembar dina unggal tabel sarta interval flash sababaraha detik; urang tadi 20 tabel sarta unggal tabel narima 8 inserts per detik - sarta dina titik ieu "Clickhouse" dimimitian ... rékaman mimiti ngalambatkeun turun. Henteu ngan ukur aranjeunna henteu lulus ... Sacara standar, nginx ngagaduhan hal anu pikaresepeun anu upami sambungan réngsé di hulu, maka éta ngan ukur ngabalikeun "502" ka sadaya pamundut énggal.
Sarta di dieu urang kudu (Kuring ngan nempo log di Clickhouse sorangan) ngeunaan satengah persén requests gagal. Sasuai, utilization disk éta luhur, aya loba merges. Nya, naon anu kuring lakukeun? Alami, kuring teu ganggu pikeun manggihan naha persis sambungan na hulu réngsé.
Ngaganti nginx ku proxy sabalikna
Kuring mutuskeun yén urang kedah ngatur ieu nyalira, urang henteu kedah ngantunkeun ka nginx - nginx henteu terang naon tabel anu aya di Clickhouse, sareng kuring ngagentos nginx ku proxy sabalikna, anu kuring ogé nyerat sorangan.
Naon anu anjeunna lakukeun? Gawéna dumasar kana perpustakaan fasthttp "goshnoy", nyaeta, gancang, ampir sagancang nginx. Hapunten, Igor, upami anjeun aya di dieu (catetan: Igor Sysoev mangrupikeun programer Rusia anu nyiptakeun pangladén wéb nginx). Bisa ngarti jenis queries ieu - INSERT atanapi SELECT - sasuai, eta nahan pools sambungan béda pikeun tipena béda queries.
Sasuai, sanajan urang teu boga waktu pikeun ngalengkepan requests sisipan, nu "selects" bakal lulus, sarta sabalikna. Sarta eta ngagolongkeun data kana tabel panyangga - kalawan panyangga leutik: lamun aya wae kasalahan, kasalahan sintaksis, jeung saterusna - ambéh maranéhanana moal greatly mangaruhan sesa data, sabab lamun urang saukur diselapkeun kana tabel panyangga, urang miboga "bachi" leutik, sarta sakabeh kasalahan sintaksis ngan kapangaruhan sapotong leutik ieu; sarta di dieu aranjeunna geus bakal mangaruhan panyangga badag. Leutik 1 megabyte, nyaeta, teu jadi leutik.
Nyelapkeun sinkronisasi sareng dasarna ngagentos nginx, dasarna ngalakukeun hal anu sami anu dilakukeun ku nginx sateuacanna - anjeun henteu kedah ngarobih "Kittenhouse" lokal pikeun ieu. Sarta saprak éta ngagunakeun fasthttp, éta pisan gancang - anjeun bisa nyieun leuwih ti 100 sarébu requests per detik pikeun inserts tunggal ngaliwatan proxy sabalikna. Sacara téoritis, anjeun tiasa nyelapkeun hiji baris dina hiji waktos kana proxy sabalikna kittenhouse, tapi tangtosna urang henteu ngalakukeun éta.
Skéma mimiti kasampak kawas kieu: "Kittenhouse", proxy sabalikna ngagolongkeun loba requests kana tabel sarta, kahareupna tabel panyangga nyelapkeun kana nu utama.
Killer mangrupikeun solusi samentawis, Anak ucing permanén
Ieu mangrupikeun masalah anu pikaresepeun ... Dupi anjeun kantos nganggo fasthttp? Anu dipaké fasthttp kalawan requests POST? Panginten, ieu leres-leres henteu kedah dilakukeun, sabab panyangga badan pamundut sacara standar, sareng ukuran panyangga kami disetel ka 16 megabyte. sisipan dieureunkeun tetep nepi di sawatara titik, sarta sakumpulan 16-megabyte mimiti anjog ti sagala puluhan rébu tina server, sarta maranéhanana kabéh buffered dina mémori saméméh dikirim ka Clickhouse. Sasuai, mémori béak, Out-Of-Memory Killer sumping sareng maéhan proxy sabalikna (atanapi "Clickhouse", anu sacara téoritis tiasa "dahar" langkung seueur tibatan proxy sabalikna). Siklusna terus-terusan. Teu masalah pisan pikaresepeun. Sanajan urang stumbled kana ieu ngan sanggeus sababaraha bulan operasi.
Naon anu kuring lakukeun? Sakali deui, kuring henteu resep ngartos naon anu kajantenan. Jigana éta geulis atra yén anjeun teu kudu panyangga kana memori. Abdi teu bisa patch fasthttp, sanajan kuring diusahakeun. Tapi kuring manggihan cara sangkan eta teu perlu patch nanaon, sarta kuring datang nepi ka metoda sorangan dina HTTP - I disebut anak ucing. Nya, éta logis - "VK", "Anak ucing" ... Naon deui?..
Upami pamundut sumping ka server nganggo metode Anak ucing, maka server kedah ngabales "meow" - logis. Upami anjeunna ngabales ieu, maka éta dianggap yén anjeunna ngartos protokol ieu, teras kuring nyegat sambunganna (fasthttp ngagaduhan metode sapertos kitu), sareng sambungan kana modeu "atah". Naha kuring peryogi éta? Abdi hoyong ngadalikeun kumaha maca tina sambungan TCP kajadian. TCP ngagaduhan sipat anu saé: upami teu aya anu maca ti sisi anu sanés, teras nyeratna mimiti ngantosan, sareng mémori henteu khusus diséépkeun pikeun ieu.
Sarta sangkan kuring maca ti ngeunaan 50 klien dina hiji waktu (ti lima puluh sabab lima puluh pasti kudu cukup, sanajan laju asalna ti DC sejen) ... Konsumsi geus turun kalawan pendekatan ieu sahenteuna 20 kali, tapi kuring, mun jujur. , Abdi teu tiasa ngukur persis naon waktos, sabab éta geus euweuh gunana (éta geus ngahontal tingkat kasalahan). Protokolna binér, nyaéta, ngandung nami tabel sareng data; teu aya lulugu http, jadi kuring henteu nganggo stop kontak wéb (Kuring henteu kedah komunikasi sareng panyungsi - kuring ngadamel protokol anu cocog sareng kabutuhan urang). Sareng sadayana janten saé sareng anjeunna.
Méja panyangga téh hanjelu
Nembe urang datang di sakuliah fitur metot séjén tina tabel panyangga. Sareng masalah ieu parantos langkung nyeri tibatan anu sanés. Hayu urang ngabayangkeun kaayaan ieu: anjeun geus aktip ngagunakeun Clickhouse, anjeun boga puluhan server Clickhouse, jeung anjeun gaduh sababaraha requests nu butuh waktu anu pohara lila maca (hayu urang nyebutkeun, leuwih ti 60 detik); sareng anjeun sumping sareng ngalakukeun Alter dina waktos ayeuna ... Samentawis éta, "milih" anu dimimitian sateuacan "Alter" moal dilebetkeun kana tabél ieu, "Alter" moal ngamimitian - sigana sababaraha fitur kumaha "Clickhouse" tiasa dianggo dina tempat ieu. Meureun ieu bisa dibenerkeun? Atawa teu mungkin?
Sacara umum, éta jelas yén kanyataanana ieu teu jadi masalah badag, tapi kalawan tabel panyangga janten langkung nyeri. Kusabab, upami, hayu urang sebutkeun, "Alter" timeouts anjeun (sareng éta tiasa waktos kaluar dina host anu sanés - sanés milik anjeun, tapi dina réplika, contona), teras ... Anjeun ngahapus méja panyangga, "Alter" anjeun ( atanapi sababaraha host anu sanés) waktosna. teras aya kasalahan "Alter") - anjeun masih kedah mastikeun yén data terus ditulis: anjeun nyiptakeun tabel panyangga deui (nurutkeun skéma anu sami sareng tabel indungna), teras "Ngarobah" mana ngaliwatan, ends sanggeus kabeh, sarta panyangga tabel mimiti béda dina schema ti indungna. Gumantung kana naon éta "Alter", sisipan tiasa henteu deui angkat ka méja panyangga ieu - ieu hanjelu pisan.
Aya ogé tanda sapertos kitu (panginten aya anu perhatikeun) - éta disebut query_thread_log dina versi anyar Clickhouse. Sacara standar, dina sababaraha versi aya hiji. Di dieu kami geus ngumpulkeun 840 juta rékaman dina sababaraha bulan (100 gigabytes). Ieu alatan kanyataan yén "inserts" ditulis di dinya (meureun ayeuna, ku jalan, aranjeunna henteu ditulis). Sakumaha anu kuring nyarioskeun ka anjeun, "sisipan" kami leutik - kami ngagaduhan seueur "sisipan" kana tabel panyangga. Ieu jelas yén ieu ditumpurkeun - Kuring ngan ngabejaan Anjeun naon kuring nempo dina server kami. Naha? Ieu argumen sejen ngalawan ngagunakeun tabel panyangga! Sedih pisan.
Saha anu terang yén lalaki ieu namina Spotty? Karyawan VK ngacungkeun leungeun. OKÉ.
Ngeunaan rencana pikeun "KitttenHouse"
Rencana biasana henteu dibagikeun, leres? Ujug-ujug anjeun moal minuhan aranjeunna sarta moal kasampak pohara alus dina panon batur. Tapi kuring bakal nyandak resiko! Urang rék ngalakukeun di handap: tabel panyangga, sigana kuring, masih crutch sarta kami kudu panyangga sisipan sorangan. Tapi urang tetep teu hayang nyangga eta dina disk, jadi urang bakal nyangga sisipan dina mémori.
Sasuai, nalika "sisipan" didamel, éta moal sinkron deui - éta bakal tiasa dianggo salaku méja panyangga, bakal nyelapkeun kana méja indungna (saé, engké engké) sareng ngalaporkeun via saluran anu misah anu sisipan parantos lulus sareng anu mana. teu acan.
Naha kuring teu tiasa ninggalkeun sisipan sinkron? Éta langkung merenah. Kanyataan yén lamun nyelapkeun tina 10 sarébu sarwa, lajeng sagalana geus rupa - anjeun bakal meunang saeutik saeutik ti unggal host, anjeun selapkeun aya sakali sadetik, sagalana geus rupa. Tapi Abdi hoyong skéma ieu jalan, contona, ti dua mesin, ku kituna anjeun bisa ngundeur di speed tinggi - meureun teu meunang maksimum kaluar Clickhouse, tapi nulis sahanteuna 100 megabytes per detik ti hiji mesin ngaliwatan proxy sabalikna - ieu skéma kudu skala ka duanana jumlah badag sarta leutik, jadi urang teu bisa antosan sadetik pikeun tiap sisipan, jadi kudu Asynchronous. Sareng dina cara anu sami, konfirmasi asinkron kedah sumping saatos sisipan parantos réngsé. Urang bakal terang naha éta lulus atanapi henteu.
Hal anu paling penting nyaéta yén dina skéma ieu urang terang pasti naha sisipan lumangsung atanapi henteu. Bayangkeun kaayaan ieu: anjeun gaduh méja panyangga, anjeun nyerat hal kana éta, teras, hayu urang sebutkeun, méja asup kana modeu ngan ukur maca sareng nyobian nyéépkeun panyangga. Dimana data bakal angkat? Aranjeunna bakal tetep dina panyangga. Tapi urang teu bisa mastikeun ieu - kumaha lamun aya sababaraha kasalahan sejen, alatan nu data moal tetep dina panyangga ... (Alamat Alexey Milovidov, Yandex, ClickHouse pamekar) Atawa bakal tetep? salawasna? Alexey ngayakinkeun urang yén sagalana bakal rupa. Urang teu boga alesan teu percaya manéhna. Tapi sadayana sami: upami urang henteu nganggo tabel panyangga, maka moal aya masalah sareng aranjeunna. Nyiptakeun tabel dua kali saloba ogé henteu pikaresepeun, sanaos prinsipna henteu aya masalah anu ageung. Ieu rencana.
Hayu urang ngobrol ngeunaan maca
Ayeuna hayu urang ngobrol ngeunaan maca. Kami ogé nyerat alat sorangan di dieu. Ieu bakal sigana, sumur, naha nulis instrumen sorangan didieu? .. Jeung saha dipaké Tabix? Kumaha bae sababaraha urang ngangkat leungeun maranéhna ... Jeung saha wareg jeung kinerja Tabix? Nya, kami henteu resep éta, sareng éta henteu pikaresepeun pisan pikeun ningali data. Éta henteu kunanaon pikeun analitik, tapi ngan ukur pikeun ningali éta jelas henteu dioptimalkeun. Ku kituna kuring nulis sorangan, panganteur kuring sorangan.
Saderhana pisan - ngan ukur tiasa maca data. Anjeunna henteu terang kumaha nunjukkeun grafik, anjeunna henteu terang kumaha ngalakukeun nanaon. Tapi éta tiasa nunjukkeun naon anu urang peryogikeun: contona, sabaraha baris dina tabél, sabaraha rohangan anu diperyogikeun (tanpa ngarecah kana kolom), nyaéta, antarmuka anu paling dasar nyaéta anu urang peryogikeun.
Sareng katingalina sami sareng Sequel Pro, tapi ngan ukur dilakukeun dina Bootstrap Twitter, sareng versi kadua. Anjeun nanya: "Yuri, naha dina versi kadua?" taun sabaraha? 2018? Sacara umum, kuring ngalakukeun ieu rada lila pisan pikeun "Otot" (MySQL) sareng ngan ukur ngarobih sababaraha garis dina patarosan didinya, sareng éta mimiti damel pikeun "Clickhouse", anu hatur nuhun khusus! Kusabab parser pisan sarupa jeung "otot" hiji, sarta queries pisan sarupa - pisan merenah, utamana dina mimitina.
Nya, éta tiasa nyaring tabel, tiasa nunjukkeun struktur sareng eusi méja, ngamungkinkeun anjeun nyortir, nyaring ku kolom, nunjukkeun pamundut anu nyababkeun hasilna, baris anu kapangaruhan (sabaraha hasilna), nyaéta, hal dasar pikeun nempo data. Lumayan gancang.
Aya ogé redaktur. Kuring paruk nyoba maok sakabéh redaktur ti Tabix, tapi teu bisa. Tapi kumaha bae gawéna. Sacara prinsip, éta sadayana.
"Clickhouse" cocog pikeun dens
Abdi hoyong nyarios yén Clickhouse, sanaos sagala masalah anu dijelaskeun, cocog pisan pikeun log. Anu paling penting, éta ngarengsekeun masalah urang - éta gancang pisan sareng ngamungkinkeun anjeun nyaring log ku kolom. Sacara prinsip, tabel panyangga teu dipigawé ogé, tapi biasana teu saurang weruh naha ... Meureun ayeuna anjeun terang hadé dimana anjeun bakal boga masalah.
TCP? Sacara umum, dina VK biasa nganggo UDP. Sareng nalika kuring nganggo TCP ... Tangtosna, teu aya anu nyarios ka kuring: "Yuri, naon anu anjeun carioskeun! Anjeun teu tiasa, anjeun peryogi UDP. Tétéla TCP teu jadi pikasieuneun. Hiji-hijina hal anu, lamun boga puluhan rébu sanyawa aktif nu nulis, anjeun kudu nyiapkeun eta saeutik leuwih taliti; tapi mungkin, sareng rada gampang.
Kuring jangji bakal masangkeun "Kittenhouse" sareng "Mursuar" dina HighLoad Siberia upami sadayana ngalanggan "backend VK" umum kami ... Sareng anjeun terang, henteu sadayana ngalanggan ... Tangtosna, kuring moal nungtut yén anjeun ngalanggan kami. umum. Aya kénéh loba teuing anjeun, batur malah bisa jadi gelo, tapi tetep, mangga ngalanggan (jeung didieu kuring kudu nyieun panon kawas panon ucing). Éta . Hatur nuhun pisan! Github milik urang . Kalayan Clickhouse rambut anjeun bakal lemes sareng silky.
Kalungguhan: - Babaturan, ayeuna keur patarosan. Katuhu saatos kami nampilkeun sertipikat apresiasi sareng laporan anjeun ngeunaan VHS.
Yuri Nasretdinov (saterusna disebut YN): - Kumaha anjeun tiasa ngarékam laporan kuring dina VHS upami éta parantos réngsé?
Kalungguhan: - Anjeun oge teu bisa pinuh nangtukeun kumaha "Clickhouse" bakal dianggo atanapi henteu! Babaturan, 5 menit pikeun patarosan!
patarosan
Patarosan ti panongton (satuluyna disebut Q): - Wilujeng sonten. Hatur nuhun pisan kana laporan. Abdi gaduh dua patarosan. Kuring gé mimitian ku hal sagawayah: naha jumlah hurup t dina ngaran "Kittenhouse" dina diagram (3, 4, 7 ...) mangaruhan kapuasan ucing?
YN: - Jumlah naon?
Z: – Surat t. Aya tilu t, tempat sakitar tilu t.
YN: - Naha kuring henteu ngalereskeunana? Nya, tangtos kitu! Ieu mangrupikeun produk anu béda - kuring ngan ukur nipu anjeun salami ieu. Oké, kuring bercanda - teu masalah. Ah, di dieu! Henteu, éta hal anu sami, kuring salah ketik.
Z: - Hatur nuhun. Patarosan kadua serius. Sajauh kuring ngartos, di Clickhouse, tabel panyangga hirup sacara éksklusif dina mémori, teu buffered kana disk jeung, sasuai, teu pengkuh.
YN: - Sumuhun.
Z: - Sareng dina waktos anu sami, panyangga klien anjeun kana disk, anu nunjukkeun sababaraha jaminan pangiriman log anu sami. Tapi ieu sanés dijamin di Clickhouse. Ngajelaskeun kumaha jaminan dilumangsungkeun, alatan naon?.. Ieu mékanisme ieu leuwih jéntré
YN: - Leres, sacara téoritis henteu aya kontradiksi di dieu, sabab nalika Clickhouse ragrag, anjeun tiasa leres-leres ngadeteksi dina sajuta cara anu béda. Lamun Clickhouse ngadat (lamun ends salah), anjeun tiasa, kasarna diomongkeun, mundur saeutik log anjeun nu wrote handap tur mimitian ti momen nalika sagalana éta persis rupa. Anggap anjeun mundur sakedap, nyaéta, éta dianggap yén anjeun parantos nyéépkeun sadayana dina hiji menit.
Z: - Nyaéta, "Kittenhouse" nahan jandela langkung lami sareng, upami ragrag, tiasa ngakuan sareng mundurkeunana?
YN: – Tapi ieu dina teori. Dina prakna, urang henteu ngalakukeun ieu, sareng pangiriman anu dipercaya nyaéta ti enol dugi ka takterhingga. Tapi rata-rata hiji. Kami wareg yén lamun Clickhouse nabrak pikeun sababaraha alesan atawa server "reboot," lajeng urang leungit saeutik. Dina sakabeh kasus sejenna, nanaon bakal kajadian.
Z: - Halo. Ti mimiti pisan sigana kuring yén anjeun memang bakal ngagunakeun UDP ti mimiti laporan. Anjeun gaduh http, sadayana éta ... Sareng seueur masalah anu anjeun terangkeun, sakumaha anu kuring ngartos, disababkeun ku solusi khusus ieu ...
YN: – Naon anu kami nganggo TCP?
Z: - Intina enya.
YN: - Henteu.
Z: - Éta kalayan fasthttp anjeun ngagaduhan masalah, sareng sambungan anjeun ngagaduhan masalah. Upami anjeun nembé nganggo UDP, anjeun bakal nyalametkeun diri sababaraha waktos. Nya, bakal aya masalah sareng pesen anu panjang atanapi anu sanésna ...
YN: - Jeung naon?
Z: – Jeung talatah lila, saprak eta bisa jadi teu cocog kana MTU, hal sejenna... Muhun, meureun aya masalah sorangan. Patarosan na: naha henteu UDP?
YN: - Kuring yakin yén pangarang anu ngembangkeun TCP / IP loba smarter ti kuring jeung nyaho hadé ti kuring kumaha serialize pakét (ambéh maranéhanana balik), dina waktos anu sareng ngaluyukeun jandela ngirim, teu overload jaringan, masihan eupan balik kana naon. teu dibaca, teu cacah dina sisi séjén ... Sadaya masalah ieu, dina pamanggih kuring, bakal aya dina UDP, ngan kuring bakal kudu nulis kode malah leuwih ti kuring geus wrote guna nerapkeun hal anu sarua sorangan jeung paling dipikaresep. goréng. Kuring malah teu resep nulis dina C, sumawona aya ...
Z: - Ngan merenah! Dikirim ok sareng entong ngantosan nanaon - éta henteu sinkron. Bewara sumping deui yén sadayana saé - hartosna parantos sumping; Mun teu datang, hartina goréng.
YN: - Abdi peryogi duanana - Abdi kedah tiasa ngirim duanana kalawan jaminan pangiriman sarta tanpa jaminan pangiriman. Ieu dua skenario anu béda. Abdi henteu kedah kaleungitan sababaraha log atanapi henteu leungit dina alesan.
Z: – Kuring moal runtah waktu. Ieu perlu dibahas deui. Hatur nuhun.
Kalungguhan: – Saha nu boga patarosan – leungeun ka langit!
Z: - Halo, abdi Sasha. Di mana waé di tengah laporan, aya perasaan yén, salian TCP, mungkin waé nganggo solusi anu siap-dijieun - sababaraha jinis Kafka.
YN: - Muhun ... Kuring bébéja yén kuring teu hayang make server panengah, sabab ... di Kafka, tétéla yén urang boga sapuluh sarébu sarwa; kanyataanna, urang boga leuwih - puluhan rébu sarwa. Éta ogé tiasa nyeri pikeun ngalakukeun sareng Kafka tanpa proksi. Salaku tambahan, anu paling penting, éta masih masihan "latency", masihan host tambahan anu anjeun peryogikeun. Tapi kuring henteu hoyong gaduh aranjeunna - Abdi hoyong ...
Z: "Tapi tungtungna tétéla kitu."
YN: – Henteu, teu aya host! Ieu sadayana dianggo dina host Clickhouse.
Z: - Nya, sareng "Kittenhouse", anu sabalikna - dimana anjeunna cicing?
YN: - Dina host Clickhouse, éta henteu nyerat nanaon kana disk.
Z: - Hayu urang anggap.
Kalungguhan: – Dupi anjeun wareg? Dupi urang masihan anjeun gaji?
Z: - Sumuhun, anjeun tiasa. Kanyataanna, aya loba crutches dina raraga neangan hal anu sarua, sarta ayeuna - jawaban saméméhna dina topik TCP contradicts, dina pamanggih kuring, kaayaan ieu. Ngan karasaeun sadayana tiasa dilakukeun dina tuur kuring dina waktos anu langkung sakedik.
YN: - Sareng naha kuring henteu hoyong nganggo Kafka, sabab aya seueur keluhan dina obrolan Telegram Clickhouse anu, contona, pesen ti Kafka leungit. Henteu ti Kafka sorangan, tapi dina integrasi Kafka na Clickhaus; atanapi aya anu henteu nyambung di dinya. Sacara kasar, éta kedah nyerat klien pikeun Kafka. Abdi henteu nyangka tiasa aya solusi anu langkung saderhana atanapi langkung dipercaya.
Z: - Béjakeun ka kuring, naha anjeun henteu nyobian antrian atanapi sababaraha beus umum? Kusabab anjeun nyarios yén kalayan asinkron anjeun tiasa ngirim log nyalira ngalangkungan antrian sareng nampi réspon sacara asynchronously ngalangkungan antrian?
YN: – Punten usulkeun antrian naon anu tiasa dianggo?
Z: - Sakur, sanajan tanpa jaminan yén maranéhna aya dina urutan. Sababaraha jinis Redis, RMQ ...
YN: - Kuring boga rarasaan yén Redis paling dipikaresep moal bisa narik volume misalna tina sisipan malah dina hiji host (dina rasa sababaraha server) nu metot kaluar Clickhouse. Abdi teu tiasa nyadangkeun ieu kalawan bukti wae (Kuring geus teu benchmarked eta), tapi sigana kuring nu Redis sanes solusi pangalusna di dieu. Sacara prinsip, sistem ieu bisa dianggap salaku antrian pesen improvised, tapi nu tailored ngan pikeun "Clickhouse"
Kalungguhan: – Yuri, hatur nuhun pisan. Kuring ngajukeun pikeun ngeureunkeun patarosan sareng waleran di dieu sareng sebutkeun saha anu naroskeun patarosan anu kami bakal masihan buku.
YN: – Abdi hoyong masihan buku ka jalma kahiji anu nanya.
Kalungguhan: - Éndah! Hebat! Hebat! Hatur nuhun pisan!
Sababaraha iklan 🙂
Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, , analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).
Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan
sumber: www.habr.com