HighLoad++ Moscow 2018, Balai Kongres. November 9, 15:00
Abstrak lan presentasi:
Yuri Nasretdinov (VKontakte): laporan bakal ngomong babagan pengalaman ngleksanakake ClickHouse ing perusahaan kita - kenapa kita butuh, jumlah data sing disimpen, cara nulis, lan liya-liyane.
Bahan tambahan:
Yuri Nasretdinov: - Halo kabeh! Jenengku Yuri Nasretdinov, amarga aku wis dikenalake. Aku kerja ing VKontakte. Aku bakal ngomong babagan cara nglebokake data menyang ClickHouse saka armada server kita (puluhan ewu).
Apa log lan kenapa ngumpulake?
Apa sing bakal kita pitutur marang kowe: apa sing kita lakoni, kenapa kita butuh "ClickHouse", kenapa kita milih, apa jenis kinerja sing sampeyan bisa entuk tanpa ngatur apa-apa khusus. Aku bakal ngandhani sampeyan luwih lengkap babagan tabel buffer, babagan masalah sing kita alami lan babagan solusi sing dikembangake saka open source - KittenHouse lan Mercusuar.
Yagene kita kudu nindakake apa wae (kabeh mesthi apik ing VKontakte, ta?). Kita pengin ngumpulake log debug (lan ana atusan terabyte data ing kana), bisa uga luwih trep kanggo ngitung statistik; lan kita duwe armada puluhan ewu server saka ngendi kabeh iki kudu rampung.
Yagene kita mutusake? Kita mbokmenawa duwe solusi kanggo nyimpen log. Kene - ana umum "Backend VK". Aku banget menehi saran kanggo langganan.
Apa iku log? Iki minangka mesin sing ngasilake array kosong. Mesin ing VK yaiku sing diarani layanan mikro. Lan iki stiker esem (cukup akeh sing seneng). Kepiye carane? Inggih, ngrungokake luwih!
Apa sing bisa digunakake kanggo nyimpen log? Mokal ora nyebut Hadup. Banjur, contone, Rsyslog (nyimpen log kasebut ing file). LSD. Sapa sing ngerti LSD iku? Ora, dudu LSD iki. Simpen file, mungguh, uga. Inggih, ClickHouse minangka pilihan aneh.
Clickhouse lan pesaing: syarat lan kesempatan
Apa sing dikarepake? Kita arep kanggo mesthekake yen kita ora duwe sumelang kakehan bab operasi, supaya bisa metu saka kothak, luwih karo konfigurasi minimal. Kita pengin nulis akeh, lan nulis kanthi cepet. Lan kita pengin tetep kanggo kabeh sasi, taun, yaiku, kanggo wektu sing suwe. Kita bisa uga pengin ngerti sawetara masalah sing padha teka karo kita lan ngandika, "Ana sing ora bisa digunakake ing kene," lan 3 sasi kepungkur), lan kita pengin bisa ndeleng apa sing kedadeyan 3 wulan kepungkur " Kompresi data - jelas kenapa bakal dadi plus - amarga nyuda jumlah papan sing dibutuhake.
Lan kita duwe syarat sing menarik: kadhangkala kita nulis output saka sawetara printah (contone, log), bisa uga luwih saka 4 kilobyte kanthi gampang. Lan yen bab iki bisa liwat UDP, banjur ora perlu nglampahi ... ora bakal duwe "overhead" kanggo sambungan, lan kanggo nomer akeh server iki bakal plus.
Ayo ndeleng apa sing ditawakake open source. Kaping pisanan, kita duwe Mesin Log - iki mesin kita; Ing asas, dheweke bisa nindakake kabeh, malah bisa nulis garis dawa. Inggih, ora transparan compress data - kita bisa compress kolom gedhe dhéwé yen kita pengin ... kita, mesthi, ora pengin (yen bisa). Mung masalah iku mung bisa menehi adoh apa mathuk ing memori; Kanggo maca liyane, sampeyan kudu njaluk binlog mesin iki lan, patut, iku njupuk wektu cukup dawa.
Apa pilihan liyane sing ana? Contone, "Hadup". Gampang operasi ... Sapa sing mikir yen Hadup gampang diatur? Mesthi, ora ana masalah karo rekaman. Nalika maca, kadhangkala ana pitakonan. Ing asas, aku bakal ngomong mbokmenawa ora, utamané kanggo log. Panyimpenan jangka panjang - mesthi, ya, kompresi data - ya, senar dawa - jelas yen sampeyan bisa ngrekam. Nanging ngrekam saka nomer akeh server ... Sampeyan isih kudu nindakake soko dhewe!
Rsyslog. Nyatane, kita digunakake minangka pilihan serep supaya kita bisa maca tanpa mbuwang binlog, nanging ora bisa nulis garis dawa, ing asas, ora bisa nulis luwih saka 4 kilobyte. Sampeyan kudu nindakake kompresi data kanthi cara sing padha dhewe. Maca bakal teka saka file.
Banjur ana pangembangan "badushka" LSD. Ateges padha karo "Rsyslog": ndhukung strings dawa, nanging ora bisa digunakake liwat UDP lan, ing kasunyatan, amarga iki, sayangé, cukup akèh iku kudu ditulis maneh ana. LSD kudu didesain ulang supaya bisa ngrekam saka puluhan ewu server.
Lan kene! Pilihan sing lucu yaiku ElasticSearch. Carane ngomong? Dheweke pancen apik nalika maca, yaiku maca kanthi cepet, nanging ora bisa nulis. Sepisanan, yen compresses data, iku banget banget. Paling kamungkinan, panelusuran lengkap mbutuhake struktur data sing luwih gedhe tinimbang volume asli. Iku angel kanggo operate lan masalah asring njedhul karo. Lan maneh, ngrekam ing Elastis - kita kudu nindakake kabeh dhewe.
Ing kene ClickHouse minangka pilihan sing cocog, mesthi. Ing bab mung sing ngrekam saka puluhan ewu server masalah. Nanging ing paling ana siji masalah, kita bisa nyoba kanggo ngatasi iku piye wae. Lan laporan liyane babagan masalah iki. Apa jenis kinerja sing bisa dikarepake saka ClickHouse?
Kepiye carane kita nglebokake? MergeTree
Sapa ing antarane sampeyan sing durung krungu utawa ngerti babagan "ClickHouse"? Aku kudu ngomong, ta? Banter banget. Selipan ana - 1-2 gigabits per detik, bledosan nganti 10 gigabits per detik bener bisa tahan konfigurasi iki - ana loro Xeon 6-inti (yaiku, dudu sing paling kuat), 256 gigabyte RAM, 20 terabyte ing RAID (ora ana diatur, setelan gawan). Alexey Milovidov, pangembang ClickHouse, mbokmenawa lungguh ana nangis amarga kita ora ngatur apa-apa (kabeh bisa digunakake kanggo kita). Patut, kacepetan mindhai, umpamane, udakara 6 milyar garis per detik bisa dipikolehi yen data kasebut dikompres kanthi apik. Yen sampeyan seneng % ing senar teks - 100 yuta baris per detik, yaiku, katon cepet banget.
Kepiye carane kita nglebokake? Ya, sampeyan ngerti yen VK nggunakake PHP. Kita bakal nglebokake saka saben buruh PHP liwat HTTP menyang "ClickHouse", menyang tabel MergeTree kanggo saben rekaman. Sapa sing ndeleng masalah karo skema iki? Kanggo sawetara alasan, ora saben wong ngangkat tangane. Ayo kula pitutur marang kowe.
Kaping pisanan, ana akeh server - mula, bakal ana akeh sambungan (ala). Banjur luwih becik nglebokake data menyang MergeTree ora luwih saka sepisan per detik. Lan sapa ngerti sebabe? Oke, oke. Aku bakal pitutur marang kowe sethitik liyane babagan iki. Pitakonan liyane sing menarik yaiku yen kita ora nindakake analytics, kita ora perlu nambah data, ora butuh server penengah, kita pengin nglebokake langsung menyang "ClickHouse" (luwih becik - luwih langsung, luwih apik).
Dadi, kepiye cara selipan ing MergeTree? Yagene luwih apik kanggo nglebokake ora luwih kerep tinimbang sepisan detik utawa kurang asring? Kasunyatane yaiku "ClickHouse" minangka basis data kolom lan ngurutake data kanthi urutan munggah saka kunci utama, lan nalika sampeyan nglebokake, sawetara file digawe paling ora padha karo jumlah kolom ing ngendi data diurutake. ing urutan munggah saka tombol utami (direktori kapisah digawe, pesawat saka file ing disk kanggo saben sisipan). Banjur sisipan sabanjure teka, lan ing latar mburi digabungake dadi "partisi" sing luwih gedhe. Wiwit data diurutake, iku bisa kanggo "nggabungake" loro file diurutake tanpa akeh memori.
Nanging, kaya sing sampeyan duga, yen sampeyan nulis 10 file kanggo saben sisipan, banjur ClickHouse (utawa server sampeyan) bakal cepet rampung, saengga dianjurake kanggo nglebokake batch gedhe. Mulane, kita ora tau ngluncurake skema pisanan menyang produksi. Kita langsung ngluncurake siji, sing nomer 2 ana ing kene:
Ing kene mbayangno yen ana sekitar sewu server sing wis diluncurake, mung ana PHP. Lan ing saben server ana agen lokal kita, sing diarani "Kittenhouse", sing njaga siji sambungan karo "ClickHouse" lan nglebokake data saben sawetara detik. Nglebokake data ora menyang MergeTree, nanging menyang meja buffer, sing serves sabenere supaya ora nglebokake langsung menyang MergeTree.
Nggarap tabel buffer
Opo iki? Tabel buffer minangka bagean saka memori sing dipecah (yaiku, bisa dilebokake kanthi asring). Padha kalebu sawetara bêsik, lan saben bêsik dianggo minangka buffer sawijining, lan padha flushed independen (yen sampeyan duwe akeh bêsik ing buffer, banjur bakal ana akeh sisipan per detik). Sampeyan bisa maca saka tabel kasebut - banjur sampeyan maca kesatuan isi buffer lan tabel induk, nanging ing wektu iki nulis diblokir, mula luwih becik ora maca saka kono. Lan tabel buffer nuduhake QPS sing apik banget, yaiku, nganti 3 ewu QPS sampeyan ora bakal duwe masalah nalika nglebokake. Cetha yen server kelangan daya, banjur data bisa ilang, amarga mung disimpen ing memori.
Ing wektu sing padha, skema karo buffer rumit ALTER, amarga sampeyan kudu nyelehake tabel buffer lawas kanthi skema lawas (data ora bakal ilang ing ngendi wae, amarga bakal disiram sadurunge tabel dibusak). Banjur sampeyan "ngganti" tabel sing dibutuhake lan nggawe meja buffer maneh. Patut, nalika ora ana tabel buffer, data ora bakal mili ngendi wae, nanging sampeyan bisa duwe ing disk ing paling lokal.
Apa Kittenhouse lan kepiye cara kerjane?
Apa iku KittenHouse? Iki minangka proxy. Tebak basa apa? Aku ngumpulake topik paling hype ing laporanku - "Clickhouse", Go, mungkin aku bakal ngelingi liyane. Ya, iki ditulis ing Go, amarga aku ora ngerti carane nulis ing C, aku ora pengin.
Patut, iku njogo sambungan karo saben server lan bisa nulis menyang memori. Contone, yen kita nulis log kesalahan menyang Clickhouse, banjur yen Clickhouse ora duwe wektu kanggo nglebokake data (sawise kabeh, yen kakehan ditulis), banjur kita ora swell memori - kita mung uncalan metu liyane. Amarga yen kita nulis sawetara gigabits per detik saka kasalahan, banjur kita mbokmenawa bisa uncalan sawetara metu. Kittenhouse bisa nindakake iki. Kajaba iku, bisa nindakake pangiriman sing dipercaya, yaiku, nulis menyang disk ing mesin lokal lan sapisan saben wektu (ana, saben saperangan detik) nyoba ngirim data saka file iki. Lan pisanan kita nggunakake format Nilai biasa - ora sawetara format binar, format teks (kaya ing SQL biasa).
Nanging banjur iki kedaden. Kita nggunakake pangiriman sing bisa dipercaya, nulis log, banjur mutusake (iku kluster tes kondisional). "Utas ing sambungan" - patut, ing sewu sambungan, sisipan aktif ndadékaké kanggo mbukak rata-rata ing server kira-kira siji lan setengah ewu. Kaget, server nampa panjalukan, nanging data kasebut isih dilebokake sawise sawetara wektu; nanging angel banget kanggo server kanggo ngladeni ...
Tambah nginx
Solusi kasebut kanggo model Utas saben sambungan yaiku nginx. Kita nginstal nginx ing ngarep Clickhouse, ing wektu sing padha nyiyapake balancing kanggo rong replika (kacepetan sisipan kita tambah kaping 2, sanajan dudu kasunyatan manawa iki) lan mbatesi jumlah sambungan menyang Clickhouse, menyang hulu lan, patut, luwih , saka ing 50 sambungan, misale jek ora ana gunane ing masang.
Banjur kita nyadari yen skema iki umume duwe kekurangan, amarga mung siji nginx ing kene. Mulane, yen nginx iki nabrak, sanajan ana replika, kita bakal kelangan data utawa, paling ora, ora nulis ing ngendi wae. Mulane kita nggawe load balancing dhewe. Kita uga nyadari yen "Clickhouse" isih cocok kanggo log, lan "setan" uga wiwit nulis log ing "Clickhouse" - banget trep, jujur. Kita isih nggunakake kanggo "dhemit" liyane.
Banjur kita katutup masalah menarik iki: yen sampeyan nggunakake cara non-standar masang ing mode SQL, meksa parser SQL basis AST lengkap, kang cukup alon. Patut, kita wis nambah setelan kanggo mesthekake yen iki ora bakal kelakon. Kita nindakake load balancing, mriksa kesehatan, supaya yen ana sing mati, kita isih ninggalake data kasebut. Saiki kita duwe cukup akeh tabel sing kudu duwe klompok Clickhouse sing beda. Lan kita uga wiwit mikir babagan panggunaan liyane - contone, kita pengin nulis log saka modul nginx, nanging ora ngerti carane komunikasi nggunakake RPC kita. Ya, aku pengin ngajari carane ngirim paling ora - contone, kanggo nampa acara ing localhost liwat UDP banjur diterusake menyang Clickhouse.
Siji langkah adoh saka solusi
Skema pungkasan wiwit katon kaya iki (versi kaping papat saka skema iki): ing saben server ing ngarep Clickhouse ana nginx (ing server sing padha) lan mung njaluk proxy menyang localhost kanthi watesan jumlah sambungan 50. bêsik. Lan rencana iki wis cukup makarya, kabeh iku cukup apik karo.
Kita urip kaya iki kira-kira sewulan. Saben uwong padha seneng, padha ditambahake tabel, padha ditambahake, padha ditambahake ... Umumé, ternyata cara kita nambah tabel buffer ora banget optimal (ayo sijine iku). We iya 16 bêsik ing saben meja lan interval lampu kilat saperangan detik; kita wis 20 tabel lan saben meja ditampa 8 sisipan per detik - lan ing titik iki "Clickhouse" wiwit ... cathetan wiwit alon mudhun. Ora mung dheweke ora lulus ... Kanthi gawan, nginx nduweni bab sing menarik yen sambungan rampung ing hulu, banjur mung bali "502" kanggo kabeh panjalukan anyar.
Lan ing kene kita duwe (aku mung ndeleng log ing Clickhouse dhewe) kira-kira setengah persen panjaluk gagal. Mulane, panggunaan disk dhuwur, ana akeh gabungan. Lha, apa sing tak lakoni? Alamiah, aku ora keganggu kanggo mangerteni apa persis sambungan lan hulu rampung.
Ngganti nginx karo proxy mbalikke
Aku mutusake yen kita kudu ngatur iki dhewe, kita ora perlu ninggalake kanggo nginx - nginx ora ngerti apa tabel sing ana ing Clickhouse, lan aku ngganti nginx karo proxy mbalikke, sing aku uga nulis dhewe.
Dheweke nyapo? Kerjane adhedhasar perpustakaan fasthttp "goshnoy", sing, cepet, meh minangka cepet nginx. Nuwun sewu, Igor, yen sampeyan ana ing kene (cathetan: Igor Sysoev minangka programmer Rusia sing nggawe server web nginx). Bisa ngerti apa jenis pitakon iki - INSERT utawa SELECT - cocog, duwe kolam sambungan sing beda kanggo macem-macem jinis pitakon.
Mulane, sanajan kita ora duwe wektu kanggo ngrampungake panjalukan sisipan, "pilihan" bakal lulus, lan kosok balene. Lan nglumpukake data dadi tabel buffer - kanthi buffer cilik: yen ana kesalahan, kesalahan sintaksis, lan liya-liyane - supaya ora mengaruhi data liyane, amarga nalika kita mung dilebokake ing tabel buffer, kita wis cilik "bachi", lan kabeh kesalahan sintaksis mung kena pengaruh iki Piece cilik; lan kene padha wis mengaruhi buffer gedhe. Cilik 1 megabyte, yaiku, ora cilik.
Nglebokake sinkronisasi lan ngganti nginx, sejatine padha karo nginx sadurunge - sampeyan ora perlu ngganti "Kittenhouse" lokal kanggo iki. Lan amarga nggunakake fasthttp, iku cepet banget - sampeyan bisa nggawe luwih saka 100 ewu panjalukan per detik kanggo sisipan siji liwat proxy mbalikke. Secara teoritis, sampeyan bisa nglebokake siji baris ing proxy mbalikke kittenhouse, nanging mesthi ora nindakake.
Skema kasebut wiwit katon kaya iki: "Kittenhouse", proxy mbalikke nglumpukake akeh panjaluk menyang tabel lan, ing gilirane, tabel buffer nglebokake menyang sing utama.
Killer minangka solusi sauntara, Kitten permanen
Iki masalah menarik ... Apa sampeyan wis nggunakake fasthttp? Sapa sing nggunakake fasthttp kanthi panjaluk POST? Mbokmenawa, iki pancene ora kudu rampung, amarga buffer awak panjalukan minangka standar, lan ukuran buffer kita disetel dadi 16 megabyte. Selipan mandheg ing sawetara titik, lan potongan 16 megabyte wiwit teka saka kabeh puluhan ewu server, lan kabeh padha buffered ing memori sadurunge dikirim menyang Clickhouse. Patut, memori entek, Out-Of-Memory Killer teka lan mateni proxy mbalikke (utawa "Clickhouse", kang bisa teori "mangan" luwih saka proxy mbalikke). Siklus kasebut bola-bali. Ora masalah banget penake. Senajan kita kesandhung iki mung sawise sawetara sasi operasi.
Apa aku wis rampung? Maneh, aku ora seneng ngerti apa sing kedadeyan. Aku iku cukup ketok sing ngirim ora buffer menyang memori. Aku ora bisa patch fasthttp, sanajan aku nyoba. Nanging aku nemokake cara kanggo nggawe supaya ora perlu patch apa-apa, lan aku teka karo cara dhewe ing HTTP - Aku disebut KITTEN. Inggih, logis - "VK", "Kucing"... Apa maneh?..
Yen panjaluk teka menyang server kanthi metode Kitten, mula server kudu nanggapi "meow" - kanthi logis. Yen dheweke nanggapi iki, mula dianggep dheweke ngerti protokol iki, banjur aku nyegat sambungan kasebut (fasthttp duwe cara kasebut), lan sambungan kasebut dadi mode "mentah". Apa aku kudu? Aku pengin ngontrol carane maca saka sambungan TCP mengkono. TCP nduweni sifat sing apik banget: yen ora ana sing maca saka sisih liyane, mula nulis wiwit ngenteni, lan memori ora digunakake kanggo iki.
Dadi aku maca saka udakara 50 klien sekaligus (saka sèket amarga sèket kudu cukup, sanajan tarif kasebut saka DC liyane) ... Konsumsi wis suda kanthi pendekatan iki paling ora kaping 20, nanging aku jujur. , Aku ora bisa ngukur persis apa wektu, amarga wis ora ana gunane (wis tekan tingkat kesalahan). Protokol kasebut binar, yaiku, ngemot jeneng lan data tabel; ora ana header http, mula aku ora nggunakake soket web (aku ora perlu komunikasi karo browser - aku nggawe protokol sing cocog karo kabutuhan). Lan kabeh dadi apik karo dheweke.
Tabel buffer sedih
Bubar kita teka tengen fitur menarik liyane saka tabel buffer. Lan masalah iki wis luwih lara tinimbang liyane. Ayo mbayangno kahanan iki: sampeyan wis aktif nggunakake Clickhouse, sampeyan duwe puluhan server Clickhouse, lan sampeyan duwe sawetara panjaluk sing mbutuhake wektu sing suwe kanggo maca (umpamane, luwih saka 60 detik); lan sampeyan teka lan nindakake Alter ing wayahe iki ... Ing sawetoro wektu, "milih" sing diwiwiti sadurunge "Ngganti" ora bakal kalebu ing tabel iki, "Ngganti" ora bakal miwiti - mbokmenawa sawetara fitur saka carane "Clickhouse" dianggo ing panggonan iki. Mungkin iki bisa didandani? Utawa ora bisa?
Umumé, cetha yen ing kasunyatan iki ora dadi masalah gedhe, nanging karo tabel buffer dadi luwih nglarani. Amarga, yen, ayo ngomong, wektu entek "Ngganti" sampeyan (lan bisa uga wektu entek ing host liyane - ora ing sampeyan, nanging ing replika, umpamane), banjur ... Sampeyan mbusak tabel buffer, "Alter" sampeyan ( utawa sawetara host liyane) wis entek. banjur ana kesalahan "Ngowahi") - sampeyan isih kudu mesthekake yen data terus ditulis: sampeyan nggawe tabel buffer bali (miturut skema sing padha karo tabel induk), banjur "Ngganti" dadi liwat, ends sawise kabeh, lan buffer Tabel wiwit beda-beda ing skema saka tiyang sepah. Gumantung ing apa "Alter", sisipan bisa uga ora ana maneh menyang meja buffer iki - iki sedih banget.
Ana uga tandha kasebut (mungkin ana sing ngerteni) - diarani query_thread_log ing versi anyar Clickhouse. Kanthi gawan, ing sawetara versi ana siji. Ing kene kita wis nglumpukake 840 yuta cathetan sajrone sawetara wulan (100 gigabyte). Iki amarga kasunyatan manawa "sisipan" ditulis ing kana (mungkin, kanthi cara, saiki ora ditulis). Kaya sing dakkandhakake, "sisipan" kita cilik - kita duwe akeh "sisipan" ing tabel buffer. Cetha yen iki dipateni - Aku mung ngandhani apa sing dakdeleng ing server kita. Kenging punapa? Iki minangka argumentasi liyane kanggo nggunakake tabel buffer! Spotty sedih banget.
Sapa sing ngerti yen wong iki jenenge Spotty? Karyawan VK ngangkat tangane. OK.
Babagan rencana kanggo "KitttenHouse"
Rencana biasane ora dienggo bareng, ta? Dumadakan sampeyan ora bakal nepaki lan ora bakal katon apik banget ing mripate wong liya. Nanging aku bakal njupuk risiko! Kita pengin nindakake ing ngisor iki: tabel buffer, misale jek kula, isih crutch lan kita kudu buffer sisipan dhewe. Nanging kita isih ora pengin buffer ing disk, supaya kita bakal buffer sisipan ing memori.
Mulane, nalika "sisipake" digawe, ora bakal sinkron maneh - wis bisa digunakake minangka tabel buffer, bakal dilebokake menyang tabel induk (uga, ing sawijining dina mengko) lan laporan liwat saluran kapisah sing sisipan wis liwati lan durung.
Napa aku ora bisa ninggalake sisipan sinkron? Iku luwih trep. Kasunyatane yen sampeyan nglebokake saka 10 ewu sarwa dumadi, mula kabeh apik - sampeyan bakal entuk sethithik saka saben host, sampeyan nglebokake ana sapisan, kabeh apik. Nanging aku pengin skema iki bisa digunakake, contone, saka rong mesin, supaya sampeyan bisa ngundhuh kanthi cepet - bisa uga ora entuk maksimal saka Clickhouse, nanging nulis paling sethithik 100 megabyte per detik saka siji mesin liwat proxy mbalikke - skema iki kudu ukuran kanggo jumlah gedhe lan cilik, supaya kita ora bisa ngenteni detik kanggo saben sisipan, supaya iku kudu bedo. Lan kanthi cara sing padha, konfirmasi asinkron kudu teka sawise sisipan wis rampung. Kita bakal ngerti apa wis lulus utawa ora.
Ingkang paling penting yaiku ing skema iki kita ngerti manawa selipan kasebut kedadeyan utawa ora. Mbayangno kahanan iki: sampeyan duwe meja buffer, sampeyan nulis soko menyang, lan banjur, ayo ngomong, meja banjur menyang mode mung maca lan nyoba kanggo flush buffer. Ngendi data bakal pindhah? Padha bakal tetep ing buffer. Nanging kita ora bisa yakin babagan iki - apa yen ana sawetara kesalahan liyane, amarga data kasebut ora bakal tetep ana ing buffer ... (Alamat Alexey Milovidov, Yandex, pangembang ClickHouse) Utawa bakal tetep? tansah? Alexey nggawe uwong yakin yen kabeh bakal apik. Kita ora duwe alesan kanggo ora percaya marang dheweke. Nanging kabeh padha: yen kita ora nggunakake tabel buffer, banjur ora ana masalah karo wong-wong mau. Nggawe kaping pindho minangka akeh tabel uga ora trep, sanajan ing asas ora ana masalah gedhe. Iki rencana.
Ayo dadi pirembagan bab maca
Saiki ayo ngomong babagan maca. Kita uga nulis alat kita dhewe ing kene. Iku bakal katon, uga, kok nulis instrument dhewe kene? .. Lan sing digunakake Tabix? Piye wae sawetara wong sing ngangkat tangane... Lan sapa sing puas karo kinerja Tabix? Ya, kita ora seneng, lan ora trep kanggo ndeleng data. Iku apik kanggo analytics, nanging mung kanggo ndeleng iku cetha ora optimized. Dadi aku nulis dhewe, antarmuka dhewe.
Iku banget prasaja - mung bisa maca data. Dheweke ora ngerti carane nuduhake grafis, dheweke ora ngerti carane nindakake apa-apa. Nanging bisa nuduhake apa sing kita butuhake: contone, pirang-pirang larik ing meja, pira papan sing dibutuhake (tanpa dipecah dadi kolom), yaiku antarmuka sing paling dhasar sing dibutuhake.
Lan katon meh padha karo Sequel Pro, nanging mung digawe ing Bootstrap Twitter, lan versi kapindho. Sampeyan takon: "Yuri, kenapa ing versi kapindho?" taun pinten? 2018? Umumé, aku nindakake iki cukup dangu ago kanggo "Otot" (MySQL) lan mung diganti saperangan saka garis ing pitakonan ana, lan wiwit digunakake kanggo "Clickhouse", kanggo thanks khusus! Amarga parser meh padha karo "otot", lan pitakon padha banget - trep banget, utamane ing wiwitan.
Ya, bisa nyaring tabel, bisa nuduhake struktur lan isi tabel, ngidini sampeyan ngurutake, nyaring miturut kolom, nuduhake pitakon sing ngasilake asil, baris sing kena pengaruh (pinten asil), yaiku, iku dhasar kanggo ndeleng data. Cepet banget.
Ana uga editor. Aku sajujure nyoba kanggo nyolong kabeh editor saka Tabix, nanging aku ora bisa. Nanging piye wae kerjane. Ing asas, iku kabeh.
"Clickhouse" cocok kanggo dens
Aku arep pitutur marang kowe sing Clickhouse, senadyan kabeh masalah diterangake, banget cocog kanggo log. Sing paling penting, ngrampungake masalah kita - cepet banget lan ngidini sampeyan nyaring log kanthi kolom. Ing asas, tabel buffer ora nindakake kanthi apik, nanging biasane ora ana sing ngerti sebabe ... Mungkin saiki sampeyan luwih ngerti ngendi sampeyan bakal duwe masalah.
TCP? Umumé, ing VK umume nggunakake UDP. Lan nalika aku nggunakake TCP ... Mesthi wae, ora ana sing ngandhani: "Yuri, apa sing sampeyan omongake! Sampeyan ora bisa, sampeyan butuh UDP. Ternyata TCP ora medeni. Ing bab mung, yen sampeyan duwe puluhan ewu senyawa aktif sing ditulis, sampeyan kudu nyiyapake sethitik liyane kasebut kanthi teliti,; nanging bisa, lan cukup gampang.
Aku janji bakal ngirim "Kittenhouse" lan "Lighthouse" ing HighLoad Siberia yen kabeh wong langganan "backend VK" umum kita ... Lan sampeyan ngerti, ora kabeh wong langganan ... Mesthi wae, aku ora njaluk sampeyan langganan kita umum. Sampeyan isih akeh banget, ana sing bisa uga gelo, nanging tetep, langganan (lan ing kene aku kudu nggawe mripat kaya kucing). iku . Matur nuwun sanget! Github punika kita . Kanthi Clickhouse rambute bakal alus lan silky.
Pimpin: - Kanca, saiki kanggo pitakonan. Sawise kita menehi sertifikat penghargaan lan laporan babagan VHS.
Yuri Nasretdinov (sabanjuré diarani YN): - Kepiye sampeyan bisa ngrekam laporan babagan VHS yen mung rampung?
Pimpin: - Sampeyan uga ora bisa nemtokake kanthi lengkap carane "Clickhouse" bisa digunakake utawa ora! Kanca-kanca, 5 menit kanggo pitakonan!
Pitakonan
Pitakonan saka pamirsa (sabanjuré diarani Q): - Sugeng siang. Matur nuwun kanthi sanget kanggo laporan. Aku duwe rong pitakonan. Aku bakal miwiti karo soko sembrono: apa nomer huruf t ing jeneng "Kittenhouse" ing diagrams (3, 4, 7 ...) mengaruhi kepuasan kucing?
YN: - Jumlah apa?
Z: – Layang t. Ana telung t, nang endi wae watara telung t.
YN: - Apa aku ora ndandani? Inggih, mesthi! Iki macem-macem produk - aku mung ngapusi sampeyan kabeh wektu iki. Oke, aku guyon - ora masalah. Ah, kene! Ora, iku bab sing padha, aku salah ketik.
Z: - Matur nuwun. Pitakonan kapindho serius. Sa adoh aku ngerti, ing Clickhouse, tabel buffer manggon istimewa ing memori, ora buffered kanggo disk lan, patut, ora ngengkel.
YN: - Ya.
Z: - Lan ing wektu sing padha, klien sampeyan buffer menyang disk, sing nuduhake sawetara jaminan pangiriman log sing padha. Nanging iki ora dijamin ing Clickhouse. Nerangake carane njamin dileksanakake, amarga apa?.. Punika mekanisme iki luwih rinci
YN: - Ya, sacara teoritis ora ana kontradiksi ing kene, amarga nalika Clickhouse tiba, sampeyan bisa ndeteksi kanthi sejuta cara. Yen Clickhouse kacilakan (yen rampung kanthi salah), sampeyan bisa, kira-kira, mbatalake log sing sampeyan tulis lan wiwiti nalika kabeh pancen apik. Contone, sampeyan mundur sepisan, yaiku, sampeyan wis nganggep kabeh wis disiram sajrone menit.
Z: - Yaiku, "Kittenhouse" nahan jendhela maneh lan, yen tiba, bisa ngenali lan mundur?
YN: – Nanging iki ing teori. Ing laku, kita ora nindakake iki, lan pangiriman dipercaya saka nul kanggo kaping tanpa wates. Nanging rata-rata siji. Kita wareg yen Clickhouse nabrak sakperangan alesan utawa server "reboot," banjur kita bakal kelangan sethithik. Ing kabeh kasus liyane, ora bakal kelakon.
Z: - Halo. Wiwit wiwitan, aku rumangsa yen sampeyan bakal nggunakake UDP wiwit wiwitan laporan. Sampeyan duwe http, kabeh iku ... Lan umume masalah sing sampeyan jelasake, kaya sing dakngerteni, disebabake dening solusi tartamtu iki ...
YN: – Apa kita nggunakake TCP?
Z: - Intine ya.
YN: - Ora.
Z: – Iku karo fasthttp sing duwe masalah, karo sambungan sampeyan duwe masalah. Yen sampeyan mung nggunakake UDP, sampeyan bakal ngirit wektu. Ya, bakal ana masalah karo pesen sing dawa utawa liyane ...
YN: - Kanthi apa?
Z: – Kanthi pesen dawa, awit iku bisa uga ora pas menyang MTU, mergo... Inggih, ana uga masalah dhewe. Pitakonan yaiku: kenapa ora UDP?
YN: - Aku percaya yen penulis sing ngembangake TCP / IP luwih pinter tinimbang aku lan ngerti luwih apik tinimbang aku carane serialize paket (supaya padha lunga), ing wektu sing padha nyetel jendhela ngirim, ora kakehan jaringan, menehi saran apa ora diwaca, ora ngetung ing sisih liya ... Kabeh masalah iki, miturut pendapatku, bakal ana ing UDP, mung aku kudu nulis kode sing luwih akeh tinimbang sing wis daktulis kanggo ngetrapake perkara sing padha dhewe lan kemungkinan ala. Aku malah ora seneng nulis ing C, apa maneh ana ...
Z: - Cukup trep! Dikirim ok lan aja ngenteni apa-apa - ora sinkron. Kabar teka maneh yen kabeh apik - tegese wis teka; Yen ora teka, tegese ala.
YN: – Aku kudu loro – Aku kudu bisa kanggo ngirim loro karo njamin pangiriman lan tanpa njamin kiriman. Iki minangka rong skenario sing beda. Aku kudu ora ilang sawetara log utawa ora ilang ing alesan.
Z: - Aku ora bakal mbuwang wektu. Iki kudu dirembug maneh. matur nuwun.
Pimpin: – Sing duwe pitakonan – tangan kanggo langit!
Z: - Halo, aku Sasha. Nang endi wae ing tengah laporan, ana perasaan sing, saliyane TCP, bisa uga nggunakake solusi sing wis siap - sawetara jinis Kafka.
YN: - Inggih ... Aku ngomong yen aku ora pengin nggunakake server penengah, amarga ... ing Kafka, ternyata kita duwe sepuluh ewu sarwa dumadi; ing kasunyatan, kita duwe luwih - puluhan ewu sarwa dumadi. Sampeyan uga bisa nglarani kanggo nindakake karo Kafka tanpa proxy. Kajaba iku, sing paling penting, isih menehi "latency", menehi host ekstra sing sampeyan kudu duwe. Nanging aku ora pengin duwe - aku pengin ...
Z: "Nanging pungkasane dadi kaya ngono."
YN: – Ora, ora ana host! Iki kabeh bisa digunakake ing host Clickhouse.
Z: - Inggih, lan "Kittenhouse", kang mbalikke - ngendi dheweke manggon?
YN: – Ing inang Clickhouse, ora nulis apa-apa menyang disk.
Z: - Ayo kita ngira.
Pimpin: – Apa sampeyan wareg? Apa kita bisa menehi gaji?
Z: - Ya, sampeyan bisa. Ing kasunyatan, ana akeh crutches kanggo njaluk bab sing padha, lan saiki - jawaban sadurungé ing topik TCP mbantah, ing mratelakake panemume, kahanan iki. Iku mung ngrasa kaya kabeh bisa wis rampung ing dhengkul ing wektu akeh kurang.
YN: - Lan uga kenapa aku ora pengin nggunakake Kafka, amarga ana cukup akeh keluhan ing obrolan Telegram Clickhouse sing, contone, pesen saka Kafka ilang. Ora saka Kafka dhewe, nanging ing integrasi Kafka lan Clickhaus; utawa soko ora nyambung ana. Kira-kira, kudu nulis klien kanggo Kafka. Aku ora mikir ana solusi sing luwih gampang utawa luwih dipercaya.
Z: – Marang kula, kok ora nyoba sembarang antrian utawa sawetara jenis bis umum? Wiwit sampeyan ujar manawa kanthi asinkron, sampeyan bisa ngirim log dhewe liwat antrian lan nampa tanggapan kanthi asynchronous liwat antrian?
YN: – Mangga menehi saran apa antrian bisa digunakake?
Z: – Sembarang, malah tanpa njamin sing padha supaya. Sawetara jinis Redis, RMQ ...
YN: - Aku duwe perasaan sing Redis paling ora bakal bisa narik volume selipan kasebut sanajan ing siji host (ing pangertèn saka sawetara server) sing narik Clickhouse. Aku ora bisa gawe serep iki karo bukti sembarang (Aku wis ora benchmarked), nanging misale jek kula Redis ora solusi sing paling apik kene. Ing asas, sistem iki bisa dianggep minangka antrian pesen improvisasi, nanging sing dirancang mung kanggo "Clickhouse"
Pimpin: – Yuri, matur nuwun sanget. Aku propose kanggo mungkasi pitakonan lan jawaban kene lan ngomong sapa sing takon pitakonan kita bakal menehi buku kanggo.
YN: – Aku arep menehi buku kanggo wong pisanan sing takon.
Pimpin: - Apik banget! apik tenan! Apik banget! Matur nuwun sanget!
Sawetara iklan 🙂
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com