HighLoad++ Moscow 2018, Congress Hall. Nobyembre 9, 15:00
Abstract at presentasyon:
Yuri Nasretdinov (VKontakte): tatalakayin ng ulat ang karanasan ng pagpapatupad ng ClickHouse sa aming kumpanya - kung bakit kailangan namin ito, kung gaano karaming data ang iniimbak namin, kung paano namin isinulat ito, at iba pa.
Mga karagdagang materyales:
Yuri Nasretdinov: - Kamusta kayong lahat! Ang pangalan ko ay Yuri Nasretdinov, dahil naipakilala na ako. Nagtatrabaho ako sa VKontakte. Pag-uusapan ko kung paano namin ipasok ang data sa ClickHouse mula sa aming server fleet (sampu-sampung libo).
Ano ang mga log at bakit kokolektahin ang mga ito?
Ano ang sasabihin namin sa iyo: kung ano ang ginawa namin, kung bakit kailangan namin ng "ClickHouse", ayon sa pagkakabanggit, kung bakit namin ito pinili, kung anong uri ng pagganap ang maaari mong makuha nang walang espesyal na pag-configure. Sasabihin ko pa sa iyo ang tungkol sa mga buffer table, tungkol sa mga problema namin sa kanila at tungkol sa aming mga solusyon na binuo namin mula sa open source - KittenHouse at Lighthouse.
Bakit kailangan nating gumawa ng kahit ano (lahat ay palaging mabuti sa VKontakte, tama?). Nais naming mangolekta ng mga debug log (at mayroong daan-daang terabytes ng data doon), marahil kahit papaano ay magiging mas maginhawang kalkulahin ang mga istatistika; at mayroon kaming isang fleet ng sampu-sampung libong mga server kung saan ang lahat ng ito ay kailangang gawin.
Bakit tayo nagdesisyon? Marahil ay mayroon kaming mga solusyon para sa pag-iimbak ng mga log. Dito - mayroong isang pampublikong "Backend VK". Lubos kong inirerekumenda ang pag-subscribe dito.
Ano ang mga log? Ito ay isang makina na nagbabalik ng mga walang laman na array. Ang mga makina sa VK ay tinatawag ng iba na mga microservice. At narito ang isang nakangiting sticker (medyo maraming likes). Paano kaya? Well, makinig pa!
Ano ang maaaring gamitin upang mag-imbak ng mga log? Imposibleng hindi banggitin si Hadup. Pagkatapos, halimbawa, Rsyslog (pag-iimbak ng mga log na ito sa mga file). LSD. Sino ang nakakaalam kung ano ang LSD? Hindi, hindi itong LSD. Mag-imbak din ng mga file, ayon sa pagkakabanggit. Well, ang ClickHouse ay isang kakaibang opsyon.
Clickhouse at mga kakumpitensya: mga kinakailangan at pagkakataon
Ano ang gusto natin? Nais naming tiyakin na hindi namin kailangang mag-alala nang labis tungkol sa operasyon, upang gumana ito nang wala sa kahon, mas mabuti na may kaunting configuration. Gusto naming magsulat ng marami, at magsulat ng mabilis. At gusto naming panatilihin ito sa lahat ng uri ng buwan, taon, iyon ay, sa mahabang panahon. Maaaring gusto naming maunawaan ang ilang problema na dinala nila sa amin at sinabing, "May hindi gumagana dito," at iyon ay 3 buwan na ang nakalipas), at gusto naming makita kung ano ang nangyari 3 buwan na ang nakalipas " Ang compression ng data - malinaw kung bakit ito ay magiging isang plus - dahil binabawasan nito ang dami ng espasyo na kinukuha nito.
At mayroon kaming isang kagiliw-giliw na kinakailangan: kung minsan ay isinusulat namin ang output ng ilang mga utos (halimbawa, mga log), maaari itong maging higit sa 4 kilobytes nang madali. At kung ang bagay na ito ay gumagana sa UDP, kung gayon hindi ito kailangang gumastos... hindi ito magkakaroon ng anumang "overhead" para sa koneksyon, at para sa isang malaking bilang ng mga server ito ay magiging isang plus.
Tingnan natin kung ano ang inaalok sa atin ng open source. Una, mayroon kaming Logs Engine - ito ang aming makina; Sa prinsipyo, kaya niyang gawin ang lahat, kaya niyang magsulat ng mahabang linya. Well, hindi ito malinaw na nag-compress ng data - maaari naming i-compress ang malalaking column sa aming sarili kung gusto namin... siyempre, ayaw namin (kung maaari). Ang problema lang ay maibibigay lang niya ang bagay sa kanyang alaala; Upang basahin ang natitira, kailangan mong makuha ang binlog ng makinang ito at, nang naaayon, ito ay tumatagal ng medyo mahabang panahon.
Ano ang iba pang mga pagpipilian doon? Halimbawa, "Hadup". Dali ng operasyon... Sino ang nag-iisip na madaling i-set up ang Hadup? Siyempre, walang mga problema sa pag-record. Kapag nagbabasa, minsan bumabangon ang mga tanong. Sa prinsipyo, sasabihin kong malamang na hindi, lalo na para sa mga log. Pangmatagalang storage - siyempre, oo, data compression - oo, mahabang string - malinaw na maaari kang mag-record. Ngunit nagre-record mula sa isang malaking bilang ng mga server... Kailangan mo pa ring gawin ang iyong sarili!
Rsyslog. Sa katunayan, ginamit namin ito bilang isang backup na opsyon upang mabasa namin ito nang hindi itinatapon ang binlog, ngunit hindi ito makakasulat ng mahabang linya; sa prinsipyo, hindi ito makakasulat ng higit sa 4 na kilobytes. Kailangan mong gawin ang data compression sa parehong paraan sa iyong sarili. Ang pagbabasa ay magmumula sa mga file.
Pagkatapos ay mayroong "badushka" na pag-unlad ng LSD. Mahalagang kapareho ng "Rsyslog": sinusuportahan nito ang mahabang mga string, ngunit hindi ito gagana sa pamamagitan ng UDP at, sa katunayan, dahil dito, sa kasamaang-palad, medyo maraming bagay ang kailangang muling isulat doon. Ang LSD ay kailangang muling idisenyo upang makapag-record mula sa libu-libong mga server.
At dito! Ang isang nakakatawang opsyon ay ang ElasticSearch. Kung paano sabihin? Magaling siya sa pagbabasa, ibig sabihin, mabilis siyang magbasa, ngunit hindi masyadong magaling sa pagsusulat. Una, kung ito ay nag-compress ng data, ito ay napakahina. Malamang, ang isang buong paghahanap ay nangangailangan ng mas malalaking istruktura ng data kaysa sa orihinal na dami. Mahirap itong patakbuhin at madalas na lumitaw ang mga problema dito. At, muli, nagre-record sa Elastic - kailangan nating gawin ang lahat sa ating sarili.
Narito ang ClickHouse ay isang perpektong opsyon, siyempre. Ang tanging bagay ay ang pagre-record mula sa libu-libong mga server ay isang problema. Pero at least may isang problema, subukan nating lutasin ito kahit papaano. At ang natitirang ulat ay tungkol sa problemang ito. Anong uri ng pagganap ang maaari mong asahan mula sa ClickHouse?
Paano natin ito isasingit? MergeTree
Sino sa inyo ang hindi nakarinig o nakakaalam tungkol sa "ClickHouse"? Kailangan kong sabihin sa iyo, hindi ba? Napakabilis. Ang pagpasok doon - 1-2 gigabits bawat segundo, mga pagsabog ng hanggang 10 gigabits bawat segundo ay talagang makatiis sa pagsasaayos na ito - mayroong dalawang 6-core Xeon (iyon ay, hindi kahit na ang pinakamalakas), 256 gigabytes ng RAM, 20 terabytes sa RAID (walang naka-configure, mga default na setting). Si Alexey Milovidov, ClickHouse developer, ay malamang na nakaupo doon na umiiyak dahil hindi kami nag-configure ng anuman (lahat ay gumana nang ganoon para sa amin). Alinsunod dito, ang bilis ng pag-scan ng, sabihin nating, humigit-kumulang 6 bilyong linya bawat segundo ay maaaring makuha kung ang data ay mahusay na naka-compress. Kung gusto mo ang % sa isang string ng teksto - 100 milyong mga linya bawat segundo, ibig sabihin, tila napakabilis.
Paano natin ito isisingit? Well, alam mo na ang VK ay gumagamit ng PHP. Ipasok namin mula sa bawat manggagawa sa PHP sa pamamagitan ng HTTP sa "ClickHouse", sa talahanayan ng MergeTree para sa bawat tala. Sino ang nakakakita ng problema sa scheme na ito? Sa ilang kadahilanan, hindi lahat ay nagtaas ng kanilang mga kamay. Hayaan mo akong sabihin sa iyo.
Una, mayroong maraming mga server - naaayon, magkakaroon ng maraming mga koneksyon (masama). Kung gayon, mas mainam na magpasok ng data sa MergeTree nang hindi hihigit sa isang beses bawat segundo. At sino ang nakakaalam kung bakit? Okay, okay. Sasabihin ko sa iyo ng kaunti pa tungkol dito. Ang isa pang kawili-wiling tanong ay hindi kami gumagawa ng analytics, hindi namin kailangang pagyamanin ang data, hindi namin kailangan ng mga intermediate na server, gusto naming direktang ipasok sa "ClickHouse" (mas mabuti - mas direkta, mas mabuti).
Alinsunod dito, paano ginagawa ang pagpasok sa MergeTree? Bakit mas mainam na ipasok ito nang hindi mas madalas kaysa isang beses sa isang segundo o mas madalas? Ang katotohanan ay ang "ClickHouse" ay isang columnar database at pinag-uuri-uri ang data sa pataas na pagkakasunud-sunod ng pangunahing key, at kapag gumawa ka ng isang insert, ang isang bilang ng mga file ay nilikha ng hindi bababa sa katumbas ng bilang ng mga haligi kung saan ang data ay pinagsunod-sunod. sa pataas na pagkakasunud-sunod ng pangunahing key (isang hiwalay na direktoryo ay nilikha, isang hanay ng mga file sa disk para sa bawat insert). Pagkatapos ay darating ang susunod na pagpasok, at sa background sila ay pinagsama sa mas malaking "mga partisyon". Dahil ang data ay pinagsunod-sunod, posible na "pagsamahin" ang dalawang pinagsunod-sunod na mga file nang hindi kumukonsumo ng maraming memorya.
Ngunit, tulad ng maaari mong hulaan, kung sumulat ka ng 10 mga file para sa bawat insert, pagkatapos ay ang ClickHouse (o ang iyong server) ay mabilis na matatapos, kaya inirerekomenda na magpasok sa malalaking batch. Alinsunod dito, hindi namin inilunsad ang unang pamamaraan sa produksyon. Agad naming inilunsad ang isa, na dito No. 2 ay mayroong:
Dito isipin na mayroong halos isang libong mga server kung saan tayo naglunsad, mayroon lamang PHP. At sa bawat server ay mayroong aming lokal na ahente, na tinawag naming "Kittenhouse", na nagpapanatili ng isang koneksyon sa "ClickHouse" at naglalagay ng data bawat ilang segundo. Ipinapasok ang data hindi sa MergeTree, ngunit sa isang buffer table, na nagsisilbing tiyak upang maiwasan ang direktang pagpasok sa MergeTree kaagad.
Paggawa gamit ang mga buffer table
Ano ito? Ang mga buffer table ay isang piraso ng memorya na na-sharded (iyon ay, maaari itong ipasok nang madalas dito). Binubuo ang mga ito ng ilang piraso, at ang bawat isa sa mga piraso ay gumagana bilang isang independiyenteng buffer, at ang mga ito ay i-flush nang nakapag-iisa (kung marami kang piraso sa buffer, magkakaroon ng maraming pagsingit bawat segundo). Posibleng magbasa mula sa mga talahanayan na ito - pagkatapos ay basahin mo ang unyon ng mga nilalaman ng buffer at ang talahanayan ng magulang, ngunit sa sandaling ito ay naharang ang pagsulat, kaya mas mahusay na huwag magbasa mula doon. At ang mga talahanayan ng buffer ay nagpapakita ng napakahusay na QPS, iyon ay, hanggang sa 3 libong QPS ay hindi ka magkakaroon ng anumang mga problema kapag nagpasok. Ito ay malinaw na kung ang server ay nawalan ng kapangyarihan, kung gayon ang data ay maaaring mawala, dahil ito ay naka-imbak lamang sa memorya.
Kasabay nito, ang scheme na may buffer ay nagpapakumplikado sa ALTER, dahil kailangan mo munang i-drop ang lumang buffer table na may lumang scheme (ang data ay hindi mawawala kahit saan, dahil ito ay ma-flush bago matanggal ang talahanayan). Pagkatapos ay "palitan" mo ang talahanayang kailangan mo at gagawa muli ng buffer table. Alinsunod dito, habang walang buffer table, ang iyong data ay hindi dadaloy kahit saan, ngunit maaari mo itong ilagay sa disk nang hindi bababa sa lokal.
Ano ang Kittenhouse at paano ito gumagana?
Ano ang KittenHouse? Ito ay isang proxy. Hulaan kung anong wika? Nakolekta ko ang pinakamaraming hype na paksa sa aking ulat - "Clickhouse", Go, baka may maalala pa ako. Oo, ito ay nakasulat sa Go, dahil hindi ko talaga alam kung paano magsulat sa C, ayoko.
Alinsunod dito, nagpapanatili ito ng koneksyon sa bawat server at maaaring sumulat sa memorya. Halimbawa, kung sumulat kami ng mga error log sa Clickhouse, kung gayon kung ang Clickhouse ay walang oras upang magpasok ng data (pagkatapos ng lahat, kung masyadong marami ang nakasulat), hindi namin pinalaki ang memorya - itinatapon lang namin ang natitira. Dahil kung magsusulat tayo ng ilang gigabits bawat segundo ng mga error, malamang na maitatapon natin ang ilan. Magagawa ito ng Kittenhouse. Dagdag pa, maaari itong magsagawa ng maaasahang paghahatid, iyon ay, pagsulat sa disk sa lokal na makina at isang beses sa bawat oras (doon, isang beses bawat ilang segundo) sinusubukan nitong maghatid ng data mula sa file na ito. At sa una ginamit namin ang regular na format ng Mga Halaga - hindi ilang binary na format, isang format ng teksto (tulad ng sa regular na SQL).
Ngunit pagkatapos ay nangyari ito. Gumamit kami ng maaasahang paghahatid, nagsulat ng mga log, pagkatapos ay nagpasya (ito ay isang conditional test cluster)... Ito ay pinalabas ng ilang oras at ibinalik, at nagsimula ang isang insertion mula sa isang libong server - lumabas na ang Clickhouse ay mayroon pa ring "Thread sa koneksyon" - nang naaayon, sa isang libong mga koneksyon, ang isang aktibong pagpapasok ay humahantong sa isang average ng pag-load sa server na halos isa at kalahating libo. Nakakagulat, tinanggap ng server ang mga kahilingan, ngunit ang data ay ipinasok pa rin pagkatapos ng ilang oras; ngunit napakahirap para sa server na ihatid ito...
Magdagdag ng nginx
Ang ganitong solusyon para sa Thread per connection model ay nginx. Nag-install kami ng nginx sa harap ng Clickhouse, sabay-sabay na nag-set up ng pagbabalanse para sa dalawang replika (nadagdagan ng 2 beses ang bilis ng pagpasok namin, bagama't hindi ito isang katotohanan na ito ang dapat mangyari) at limitado ang bilang ng mga koneksyon sa Clickhouse, sa upstream at, nang naaayon, higit pa , kaysa sa 50 na koneksyon, tila walang saysay ang pagpasok.
Pagkatapos ay napagtanto namin na ang scheme na ito sa pangkalahatan ay may mga disadvantages, dahil mayroon lamang kaming isang nginx dito. Alinsunod dito, kung nag-crash ang nginx na ito, sa kabila ng pagkakaroon ng mga replika, nawawalan kami ng data o, hindi bababa sa, huwag sumulat kahit saan. Kaya naman gumawa kami ng sarili naming load balancing. Napagtanto din namin na ang "Clickhouse" ay angkop pa rin para sa mga log, at ang "demonyo" ay nagsimula ring isulat ang kanyang mga log sa "Clickhouse" - napaka maginhawa, upang maging matapat. Ginagamit pa rin namin ito para sa ibang mga “demonyo”.
Pagkatapos ay natuklasan namin ang kawili-wiling problemang ito: kung gumamit ka ng hindi karaniwang paraan ng pagpasok sa SQL mode, pinipilit nito ang isang ganap na AST-based SQL parser, na medyo mabagal. Alinsunod dito, nagdagdag kami ng mga setting upang matiyak na hindi ito mangyayari. Nag-load balancing kami, nag-check ng kalusugan, para kung may namatay, iniiwan pa rin namin ang data. Mayroon na kaming napakaraming mga talahanayan na kailangan namin upang magkaroon ng iba't ibang mga cluster ng Clickhouse. At nagsimula rin kaming mag-isip tungkol sa iba pang mga gamit - halimbawa, gusto naming magsulat ng mga log mula sa mga module ng nginx, ngunit hindi nila alam kung paano makipag-usap gamit ang aming RPC. Well, gusto kong turuan sila kung paano magpadala ng kahit papaano - halimbawa, upang makatanggap ng mga kaganapan sa localhost sa pamamagitan ng UDP at pagkatapos ay ipasa ang mga ito sa Clickhouse.
Isang hakbang ang layo mula sa solusyon
Ang huling scheme ay nagsimulang magmukhang ganito (ang ika-apat na bersyon ng scheme na ito): sa bawat server sa harap ng Clickhouse ay mayroong nginx (sa parehong server) at nag-proxy lang ito ng mga kahilingan sa localhost na may limitasyon sa bilang ng mga koneksyon na 50 mga piraso. At ang scheme na ito ay gumagana na, ang lahat ay medyo maganda dito.
Halos isang buwan kaming namuhay ng ganito. Lahat ay masaya, nagdagdag sila ng mga talahanayan, nagdagdag sila, nagdagdag sila... Sa pangkalahatan, lumabas na ang paraan ng pagdaragdag ng mga talahanayan ng buffer ay hindi masyadong optimal (let's put it that way). Gumawa kami ng 16 na piraso sa bawat talahanayan at isang flash interval ng ilang segundo; mayroon kaming 20 table at bawat table ay nakatanggap ng 8 insert bawat segundo - at sa puntong ito nagsimula ang “Clickhouse”... nagsimulang bumagal ang mga record. Hindi lamang sila hindi pumasa... Bilang default, ang nginx ay may isang kawili-wiling bagay na kung ang mga koneksyon ay natapos sa upstream, pagkatapos ay ibinalik lamang nito ang "502" sa lahat ng mga bagong kahilingan.
At narito kami (tumingin lang ako sa mga log sa Clickhouse mismo) humigit-kumulang kalahating porsyento ng mga kahilingan ang nabigo. Alinsunod dito, ang paggamit ng disk ay mataas, mayroong maraming mga pagsasanib. Aba, anong ginawa ko? Naturally, hindi ako nag-abala upang malaman kung bakit eksaktong natapos ang koneksyon at upstream.
Pinapalitan ang nginx ng reverse proxy
Napagpasyahan ko na kailangan naming pamahalaan ito sa aming sarili, hindi namin kailangang iwanan ito sa nginx - hindi alam ng nginx kung anong mga talahanayan ang mayroon sa Clickhouse, at pinalitan ko ang nginx ng isang reverse proxy, na ako rin mismo ang sumulat.
Ano ang ginagawa niya? Gumagana ito batay sa fasthttp library na "goshnoy", iyon ay, mabilis, halos kasing bilis ng nginx. Paumanhin, Igor, kung naroroon ka rito (tandaan: Si Igor Sysoev ay isang Russian programmer na lumikha ng nginx web server). Maiintindihan nito kung anong uri ng mga query ito – INSERT o SELECT – ayon dito, nagtataglay ito ng iba't ibang pool ng koneksyon para sa iba't ibang uri ng mga query.
Alinsunod dito, kahit na wala kaming oras upang kumpletuhin ang mga kahilingan sa pagpasok, ang "mga pinili" ay lilipas, at kabaliktaran. At pinapangkat nito ang data sa mga buffer table - na may maliit na buffer: kung mayroong anumang mga error, syntax error, at iba pa - upang hindi sila makakaapekto nang malaki sa natitirang data, dahil kapag ipinasok lang namin sa mga buffer table, kami may maliit na "bachi", at lahat ng mga error sa syntax ay nakaapekto lamang sa maliit na pirasong ito; at dito makakaapekto na sila sa isang malaking buffer. Ang maliit ay 1 megabyte, ibig sabihin, hindi gaanong maliit.
Ang pagpasok ng isang pag-synchronize at mahalagang pagpapalit ng nginx, ay talagang kapareho ng ginawa ng nginx dati - hindi mo kailangang baguhin ang lokal na "Kittenhouse" para dito. At dahil ito ay gumagamit ng fasthttp, ito ay napakabilis - maaari kang gumawa ng higit sa 100 libong mga kahilingan sa bawat segundo para sa mga solong pagsingit sa pamamagitan ng isang reverse proxy. Sa teoryang, maaari kang magpasok ng isang linya sa isang pagkakataon sa kittenhouse reverse proxy, ngunit siyempre hindi namin ginagawa iyon.
Ang scheme ay nagsimulang magmukhang ganito: "Kittenhouse", ang reverse proxy ay nagpangkat ng maraming mga kahilingan sa mga talahanayan at, sa turn, ang mga buffer table ay ipinapasok ang mga ito sa mga pangunahing.
Ang mamamatay ay pansamantalang solusyon, ang Kuting ay permanente
Ito ay isang kawili-wiling problema... Mayroon ba sa inyo na gumamit ng fasthttp? Sino ang gumamit ng fasthttp sa mga kahilingan sa POST? Marahil, hindi talaga ito dapat ginawa, dahil bina-buffer nito ang katawan ng kahilingan bilang default, at ang laki ng buffer namin ay itinakda sa 16 megabytes. Ang pagpasok ay tumigil sa pagsubaybay sa ilang mga punto, at ang 16-megabyte na mga tipak ay nagsimulang dumating mula sa lahat ng sampu-sampung libong mga server, at lahat sila ay na-buffer sa memorya bago ipadala sa Clickhouse. Alinsunod dito, ang memorya ay naubos, ang Out-Of-Memory Killer ay dumating at pinatay ang reverse proxy (o "Clickhouse", na maaaring theoretically "kumain" ng higit pa kaysa sa reverse proxy). Ang pag-ikot ay paulit-ulit. Hindi isang napakagandang problema. Bagama't natisod namin ito pagkatapos lamang ng ilang buwang operasyon.
Ang aking nagawa? Muli, hindi ko talaga gustong intindihin ang eksaktong nangyari. Sa tingin ko medyo halata na hindi ka dapat mag-buffer sa memorya. Hindi ko ma-patch ang fasthttp, kahit na sinubukan ko. Ngunit nakahanap ako ng isang paraan upang gawin ito upang hindi na kailangang mag-patch ng anuman, at nakaisip ako ng sarili kong pamamaraan sa HTTP - tinawag ko itong KUTING. Well, ito ay lohikal - "VK", "Kuting"... Ano pa?..
Kung ang isang kahilingan ay dumating sa server na may pamamaraang Kuting, dapat na tumugon ang server ng "meow" - lohikal. Kung siya ay tumugon dito, pagkatapos ay itinuturing na naiintindihan niya ang protocol na ito, at pagkatapos ay naharang ko ang koneksyon (ang fasthttp ay may ganitong paraan), at ang koneksyon ay napupunta sa "raw" na mode. Bakit kailangan ko ito? Gusto kong kontrolin kung paano nangyayari ang pagbabasa mula sa mga koneksyon sa TCP. Ang TCP ay may kahanga-hangang pag-aari: kung walang nagbabasa mula sa kabilang panig, pagkatapos ay magsisimulang maghintay ang pagsulat, at ang memorya ay hindi partikular na ginugol dito.
At kaya nagbasa ako mula sa humigit-kumulang 50 mga kliyente sa isang pagkakataon (mula sa limampu dahil singkwenta ay tiyak na sapat, kahit na ang rate ay mula sa isa pang DC)... Ang pagkonsumo ay nabawasan sa diskarteng ito ng hindi bababa sa 20 beses, ngunit ako, sa totoo lang , hindi ko masusukat nang eksakto kung anong oras, dahil wala na itong kabuluhan (naabot na nito ang antas ng error). Ang protocol ay binary, iyon ay, naglalaman ito ng pangalan ng talahanayan at data; walang mga http header, kaya hindi ako gumamit ng web socket (hindi ko kailangang makipag-ugnayan sa mga browser - gumawa ako ng protocol na nababagay sa aming mga pangangailangan). At naging maayos ang lahat sa kanya.
Ang buffer table ay malungkot
Kamakailan ay nakatagpo kami ng isa pang kawili-wiling tampok ng mga buffer table. At ang problemang ito ay mas masakit kaysa sa iba. Isipin natin ang sitwasyong ito: aktibo ka nang gumagamit ng Clickhouse, mayroon kang dose-dosenang mga server ng Clickhouse, at mayroon kang ilang mga kahilingan na tumatagal ng napakatagal na oras upang mabasa (sabihin nating, higit sa 60 segundo); at darating ka at gawin ang Alter sa sandaling ito... Pansamantala, ang "mga pinili" na nagsimula bago ang "Alter" ay hindi isasama sa talahanayang ito, ang "Alter" ay hindi magsisimula - marahil ilang mga tampok kung paano gumagana ang "Clickhouse" sa ang lugar na ito. Baka maaayos ito? O hindi pwede?
Sa pangkalahatan, malinaw na sa katotohanan ay hindi ito isang malaking problema, ngunit sa mga buffer table ay nagiging mas masakit ito. Dahil, kung, sabihin natin, ang iyong "Baguhin" na mga timeout (at maaaring mag-time out ito sa isa pang host - hindi sa iyo, ngunit sa isang kopya, halimbawa), kung gayon... Tinanggal mo ang buffer table, ang iyong "Alter" ( o ilang iba pang host) nag-time out. pagkatapos ay may naganap na error na "Baguhin") - kailangan mo pa ring tiyakin na patuloy na maisusulat ang data: gagawa ka ng mga buffer table pabalik (ayon sa parehong scheme ng parent table), pagkatapos Ang "Baguhin" ay napupunta, nagtatapos pagkatapos ng lahat, at ang buffer ng talahanayan ay nagsisimulang mag-iba sa schema mula sa magulang. Depende sa kung ano ang "Alter", ang insert ay maaaring hindi na mapunta sa buffer table na ito - ito ay napakalungkot.
Mayroon ding ganoong palatandaan (marahil may nakapansin nito) - tinatawag itong query_thread_log sa mga bagong bersyon ng Clickhouse. Bilang default, sa ilang bersyon mayroong isa. Dito kami ay nakaipon ng 840 milyong mga tala sa loob ng ilang buwan (100 gigabytes). Ito ay dahil sa ang katunayan na ang mga "insert" ay nakasulat doon (marahil ngayon, sa pamamagitan ng paraan, hindi sila nakasulat). Tulad ng sinabi ko sa iyo, ang aming mga "insert" ay maliit - mayroon kaming maraming "insert" sa mga buffer table. Malinaw na hindi ito pinagana - Sinasabi ko lang sa iyo kung ano ang nakita ko sa aming server. Bakit? Ito ay isa pang argumento laban sa paggamit ng mga buffer table! Napakalungkot ni Spotty.
Sino ang nakakaalam na ang pangalan ng lalaking ito ay Spotty? Nagtaas ng kamay ang mga empleyado ng VK. OK.
Tungkol sa mga plano para sa "KitttenHouse"
Ang mga plano ay karaniwang hindi ibinabahagi, tama ba? Biglang hindi mo matutupad ang mga ito at hindi magiging maganda sa paningin ng ibang tao. Pero ipagsapalaran ko! Nais naming gawin ang mga sumusunod: ang mga buffer table, tila sa akin, ay isang saklay pa rin at kailangan nating i-buffer ang pagpasok sa ating sarili. Ngunit ayaw pa rin naming i-buffer ito sa disk, kaya i-buffer namin ang pagpasok sa memorya.
Alinsunod dito, kapag ang isang "insert" ay ginawa, hindi na ito magkakasabay - ito ay gagana na bilang isang buffer table, ipapasok sa parent table (well, balang araw) at mag-uulat sa pamamagitan ng isang hiwalay na channel kung saan ang mga pagsingit ay lumipas at kung saan hindi pa.
Bakit hindi ko maiwan ang kasabay na insert? Ito ay mas maginhawa. Ang katotohanan ay kung magpasok ka mula sa 10 libong mga host, kung gayon ang lahat ay maayos - makakakuha ka ng kaunti mula sa bawat host, ipasok mo doon isang beses sa isang segundo, lahat ay maayos. Ngunit nais kong gumana ang scheme na ito, halimbawa, mula sa dalawang makina, upang makapag-download ka sa mataas na bilis - marahil ay hindi makuha ang maximum mula sa Clickhouse, ngunit sumulat ng hindi bababa sa 100 megabytes bawat segundo mula sa isang makina sa pamamagitan ng isang reverse proxy - ito ang scheme ay dapat na sukat sa parehong malaki at maliit na dami, kaya hindi tayo makapaghintay ng isang segundo para sa bawat pagpapasok, kaya dapat itong maging asynchronous. At sa parehong paraan, ang mga asynchronous na pagkumpirma ay dapat na dumating pagkatapos makumpleto ang pagpapasok. Malalaman natin kung pumasa o hindi.
Ang pinakamahalagang bagay ay na sa pamamaraang ito ay alam nating sigurado kung naganap ang pagpapasok o hindi. Isipin ang sitwasyong ito: mayroon kang buffer table, nagsulat ka ng isang bagay dito, at pagkatapos, sabihin natin, ang talahanayan ay napunta sa read only mode at sinubukang i-flush ang buffer. Saan pupunta ang data? Mananatili sila sa buffer. Ngunit hindi namin matiyak ito - paano kung may ilang iba pang error, dahil sa kung saan ang data ay hindi mananatili sa buffer... (Mga Address Alexey Milovidov, Yandex, ClickHouse developer) O mananatili ba ito? palagi? Kinumbinsi kami ni Alexey na magiging maayos ang lahat. Wala tayong dahilan para hindi maniwala sa kanya. Ngunit pareho lang: kung hindi kami gagamit ng mga buffer table, hindi magkakaroon ng anumang problema sa kanila. Ang paglikha ng dalawang beses sa maraming mga talahanayan ay hindi rin maginhawa, bagaman sa prinsipyo ay walang malalaking problema. Ito ang plano.
Pag-usapan natin ang pagbabasa
Ngayon ay pag-usapan natin ang tungkol sa pagbabasa. Nagsulat din kami ng sarili naming tool dito. Mukhang, mabuti, bakit sumulat ng iyong sariling instrumento dito?.. At sino ang gumamit ng Tabix? Kahit papaano kakaunti lang ang nagtaas ng kamay... At sino ang kuntento sa performance ng Tabix? Well, hindi kami nasisiyahan dito, at hindi ito masyadong maginhawa para sa pagtingin ng data. Mabuti para sa analytics, ngunit para lamang sa pagtingin ay malinaw na hindi ito na-optimize. Kaya sinulat ko ang sarili ko, ang sarili kong interface.
Ito ay napaka-simple - maaari lamang itong magbasa ng data. Hindi siya marunong magpakita ng graphics, hindi siya marunong gumawa ng kahit ano. Ngunit maaari itong ipakita kung ano ang kailangan natin: halimbawa, kung gaano karaming mga hilera ang nasa talahanayan, kung gaano karaming espasyo ang tumatagal (nang hindi ito hinahati sa mga hanay), iyon ay, isang napakapangunahing interface ang kailangan natin.
At mukhang halos kapareho sa Sequel Pro, ngunit ginawa lamang sa Bootstrap ng Twitter, at ang pangalawang bersyon. Itanong mo: "Yuri, bakit sa pangalawang bersyon?" Anong taon? 2018? Sa pangkalahatan, matagal ko nang ginawa ito para sa "Muscle" (MySQL) at binago ko lang ang ilang linya sa mga query doon, at nagsimula itong gumana para sa "Clickhouse", na espesyal na salamat! Dahil ang parser ay halos kapareho sa "kalamnan", at ang mga query ay halos magkapareho - napaka maginhawa, lalo na sa una.
Kaya, maaari itong mag-filter ng mga talahanayan, maipakita ang istraktura at mga nilalaman ng talahanayan, pinapayagan kang mag-uri-uriin, mag-filter ayon sa mga hanay, nagpapakita ng query na nagresulta sa resulta, ang mga apektadong hilera (kung gaano karami ang resulta), iyon ay, ang mga pangunahing bagay para sa pagtingin ng data. medyo mabilis.
May editor din. Sa totoo lang sinubukan kong nakawin ang buong editor mula sa Tabix, ngunit hindi ko magawa. Ngunit sa anumang paraan ito gumagana. Sa prinsipyo, iyon lang.
Ang "Clickhouse" ay angkop para sa mga lungga
Gusto kong sabihin sa iyo na ang Clickhouse, sa kabila ng lahat ng mga problemang inilarawan, ay napakahusay na angkop para sa mga log. Pinakamahalaga, nalulutas nito ang aming problema - napakabilis nito at nagbibigay-daan sa iyo na i-filter ang mga log ayon sa mga column. Sa prinsipyo, ang mga buffer table ay hindi gumanap nang maayos, ngunit kadalasan ay walang nakakaalam kung bakit... Siguro ngayon mas alam mo na kung saan ka magkakaroon ng mga problema.
TCP? Sa pangkalahatan, sa VK kaugalian na gumamit ng UDP. At noong gumamit ako ng TCP... Syempre, walang nagsabi sa akin: “Yuri, ano ba yang pinagsasabi mo! Hindi mo kaya, kailangan mo ng UDP." Ito ay lumabas na ang TCP ay hindi nakakatakot. Ang tanging bagay ay, kung mayroon kang libu-libong mga aktibong compound na iyong isinulat, kailangan mong ihanda ito nang mas maingat; ngunit ito ay posible, at medyo madali.
Nangako akong mag-post ng "Kittenhouse" at "Lighthouse" sa HighLoad Siberia kung ang lahat ay nag-subscribe sa aming pampublikong "VK backend"... At alam mo, hindi lahat ay nag-subscribe... Siyempre, hindi ko hihilingin na mag-subscribe ka sa aming pampubliko. Napakarami pa rin sa inyo, baka may masaktan pa, pero mag-subscribe pa rin (and here I have to make eyes like those of a cat). Iyon ay . Maraming salamat! Amin ang Github . Sa Clickhouse magiging malambot at malasutla ang iyong buhok.
Humantong: - Mga kaibigan, ngayon para sa mga katanungan. Pagkatapos naming ipakita ang sertipiko ng pagpapahalaga at ang iyong ulat sa VHS.
Yuri Nasretdinov (mula rito ay tinutukoy bilang YN): – Paano mo naitala ang aking ulat sa VHS kung katatapos lang nito?
Humantong: – Hindi mo rin ganap na matukoy kung paano gagana o hindi ang "Clickhouse"! Mga kaibigan, 5 minuto para sa mga tanong!
mga katanungan
Tanong mula sa madla (mula rito ay tinutukoy bilang Q): - Magandang hapon. Maraming salamat sa ulat. Mayroon akong dalawang tanong. Magsisimula ako sa isang bagay na walang kabuluhan: ang bilang ng mga titik t sa pangalang "Kittenhouse" sa mga diagram (3, 4, 7...) ay nakakaapekto sa kasiyahan ng mga pusa?
YN: - Dami ng ano?
Z: – Liham t. Mayroong tatlong t, sa isang lugar sa paligid ng tatlong t.
YN: - Hindi ko ba naayos? Well, siyempre ito ay! Iba't ibang produkto ito - niloloko lang kita all this time. Okay, biro ko - hindi mahalaga. Ah, dito! Hindi, pareho lang, nagka-typo ako.
Z: - Salamat. Seryoso ang pangalawang tanong. Sa pagkakaintindi ko, sa Clickhouse, ang mga buffer table ay nabubuhay nang eksklusibo sa memorya, ay hindi naka-buffer sa disk at, nang naaayon, ay hindi nagpapatuloy.
YN: - Oo.
Z: – At sa parehong oras, ang iyong kliyente ay buffer sa disk, na nagpapahiwatig ng ilang garantiya ng paghahatid ng parehong mga log. Ngunit hindi ito garantisadong sa Clickhouse. Ipaliwanag kung paano isinasagawa ang garantiya, dahil sa ano?.. Narito ang mekanismong ito nang mas detalyado
YN: – Oo, ayon sa teorya ay walang mga kontradiksyon dito, dahil kapag bumagsak ang Clickhouse, maaari mo talagang makita ito sa isang milyong iba't ibang paraan. Kung nag-crash ang Clickhouse (kung hindi tama ang pagtatapos nito), maaari mong, sa halos pagsasalita, i-rewind ang kaunti sa iyong log na isinulat mo at magsimula sa sandaling maayos ang lahat. Sabihin nating nag-rewind ka ng isang minuto, iyon ay, itinuturing na na-flush mo ang lahat sa isang minuto.
Z: – Ibig sabihin, mas matagal na hinahawakan ng “Kittenhouse” ang bintana at, kung sakaling mahulog, makikilala ba ito at i-rewind?
YN: - Ngunit ito ay nasa teorya. Sa pagsasagawa, hindi namin ito ginagawa, at ang maaasahang paghahatid ay mula sa zero hanggang sa infinity times. Ngunit sa karaniwan ay isa. Kami ay nasisiyahan na kung ang Clickhouse ay nag-crash sa ilang kadahilanan o ang mga server ay "reboot," pagkatapos ay mawawalan kami ng kaunti. Sa lahat ng iba pang mga kaso, walang mangyayari.
Z: - Kamusta. Sa simula pa lang ay tila sa akin ay talagang gagamit ka ng UDP sa simula pa lamang ng ulat. Mayroon kang http, lahat ng iyon... At karamihan sa mga problemang inilarawan mo, ayon sa pagkakaintindi ko, ay sanhi ng partikular na solusyong ito...
YN: – Ano ang ginagamit natin sa TCP?
Z: - Sa totoo lang oo.
YN: - Hindi.
Z: – Sa fasthttp na nagkaroon ka ng mga problema, sa koneksyon na nagkaroon ka ng mga problema. Kung ginamit mo lang ang UDP, nailigtas mo ang iyong sarili ng ilang oras. Well, magkakaroon ng mga problema sa mahabang mensahe o iba pa...
YN: - Sa ano?
Z: – Sa mahahabang mensahe, dahil maaaring hindi ito magkasya sa MTU, iba pa... Well, maaaring may mga sarili nilang problema. Ang tanong ay: bakit hindi UDP?
YN: – Naniniwala ako na ang mga may-akda na bumuo ng TCP/IP ay mas matalino kaysa sa akin at mas alam kaysa sa akin kung paano i-serialize ang mga packet (upang pumunta sila), sabay na ayusin ang window ng pagpapadala, hindi labis na karga ang network, magbigay ng feedback sa kung ano ay hindi nababasa, hindi binibilang sa kabilang panig... Ang lahat ng mga problemang ito, sa palagay ko, ay iiral sa UDP, kailangan ko lang magsulat ng higit pang code kaysa sa naisulat ko na upang maipatupad ang parehong bagay sa aking sarili at malamang mahina. Hindi ako mahilig magsulat sa C, pabayaan na lang doon...
Z: - Maginhawa lang! Naipadala nang ok at huwag maghintay ng anuman - ganap itong asynchronous. Bumalik ang isang abiso na maayos ang lahat - nangangahulugan iyon na dumating ito; Kung hindi ito dumating, ito ay nangangahulugan na ito ay masama.
YN: – Kailangan ko pareho – Kailangan kong maipadala pareho nang may garantiya ng paghahatid at walang garantiya ng paghahatid. Dalawang magkaibang senaryo ang mga ito. Kailangan kong hindi mawala ang ilang mga log o hindi mawala ang mga ito sa loob ng dahilan.
Z: - Hindi ako mag-aaksaya ng oras. Ito ay kailangang pag-usapan pa. Salamat.
Humantong: – Sino ang may mga katanungan – mga kamay sa langit!
Z: - Hello, ako si Sasha. Sa isang lugar sa gitna ng ulat, lumitaw ang isang pakiramdam na, bilang karagdagan sa TCP, posible na gumamit ng isang handa na solusyon - isang uri ng Kafka.
YN: – Buweno... Sinabi ko sa iyo na ayaw kong gumamit ng mga intermediate server, dahil... sa Kafka, lumalabas na mayroon kaming sampung libong host; sa katunayan, mayroon kaming higit pa - sampu-sampung libong mga host. Masakit ding gawin sa Kafka nang walang anumang mga proxy. Bilang karagdagan, ang pinakamahalaga, nagbibigay pa rin ito ng "latency", nagbibigay ito ng mga karagdagang host na kailangan mong magkaroon. Ngunit hindi ko nais na magkaroon ng mga ito - gusto ko ...
Z: "Ngunit sa huli ay naging ganoon pa rin."
YN: – Hindi, walang mga host! Gumagana ang lahat ng ito sa mga host ng Clickhouse.
Z: - Well, at "Kittenhouse", na kabaligtaran - saan siya nakatira?
YN: – Sa Clickhouse host, hindi ito nagsusulat ng kahit ano sa disk.
Z: - Ipagpalagay natin.
Humantong: – Nasiyahan ka ba? Maaari ba namin kayong bigyan ng suweldo?
Z: - Oo kaya mo. Sa katunayan, mayroong maraming mga saklay upang makuha ang parehong bagay, at ngayon - ang nakaraang sagot sa paksa ng TCP ay sumasalungat, sa aking opinyon, ang sitwasyong ito. Pakiramdam ko lahat ay nagawa sa aking mga tuhod sa mas kaunting oras.
YN: – At kung bakit hindi ko gustong gamitin ang Kafka, dahil napakaraming reklamo sa Clickhouse Telegram chat na, halimbawa, nawala ang mga mensahe mula sa Kafka. Hindi mula sa Kafka mismo, ngunit sa pagsasama ng Kafka at Clickhaus; o may hindi nakakonekta doon. Sa halos pagsasalita, kakailanganing magsulat ng isang kliyente para sa Kafka noon. Sa palagay ko ay hindi maaaring magkaroon ng isang mas simple o mas maaasahang solusyon.
Z: – Sabihin mo sa akin, bakit hindi mo sinubukan ang anumang pila o ilang uri ng karaniwang bus? Dahil sinabi mo na sa asynchrony maaari mong ipadala ang mga log sa kanilang sarili sa pamamagitan ng pila at makatanggap ng tugon nang asynchronous sa pamamagitan ng pila?
YN: – Mangyaring imungkahi kung anong mga pila ang maaaring gamitin?
Z: – Anuman, kahit na walang garantiya na maayos ang mga ito. Ilang uri ng Redis, RMQ...
YN: – Mayroon akong pakiramdam na ang Redis ay malamang na hindi magagawang hilahin ang ganoong dami ng pagpasok kahit sa isang host (sa kahulugan ng ilang mga server) na kumukuha ng Clickhouse. Hindi ko ito mai-back up ng anumang katibayan (hindi ko ito na-benchmark), ngunit sa tingin ko ay hindi si Redis ang pinakamahusay na solusyon dito. Sa prinsipyo, ang system na ito ay maaaring ituring bilang isang improvised na pila ng mensahe, ngunit na iniayon lamang para sa "Clickhouse"
Humantong: – Yuri, maraming salamat. Iminumungkahi kong tapusin ang mga tanong at sagot dito at sabihin kung sino sa mga nagtanong ang bibigyan namin ng libro.
YN: – Gusto kong bigyan ng libro ang unang taong nagtanong.
Humantong: - Kahanga-hanga! Malaki! Fabulous! Maraming salamat!
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com