HighLoad++ Mosku 2018, Kongresu Aretoa. Azaroak 9, 15:00
Laburpenak eta aurkezpena:
Yuri Nasretdinov (VKontakte): txostenak gure enpresan ClickHouse ezartzeko esperientziari buruz hitz egingo du - zergatik behar dugun, zenbat datu gordetzen ditugun, nola idazten dugun eta abar.
Material osagarriak:
Yuri Nasretdinov: - Kaixo guztioi! Nire izena Yuri Nasretdinov da, dagoeneko aurkeztu nautenez. VKontakte-n egiten dut lan. Gure zerbitzarien flotatik (hamarka mila) datuak ClickHouse-n nola txertatzen ditugun hitz egingo dut.
Zer dira erregistroak eta zergatik bildu?
Zer esango dizugu: zer egin genuen, zergatik behar genuen “ClickHouse”, hurrenez hurren, zergatik aukeratu genuen, zer nolako errendimendua lor dezakezun gutxi gorabehera ezer berezirik konfiguratu gabe. Buffer-taulei buruz gehiago esango dizut, haiekin izan ditugun arazoei buruz eta kode irekitik garatu ditugun soluzioei buruz - KittenHouse eta Lighthouse.
Zergatik egin behar genuen ezer (VKontakte-n dena beti ona da, ezta?). Arazteen erregistroak bildu nahi genituen (eta ehunka terabyteko datu zeuden bertan), agian nolabait erosoagoa izango litzateke estatistikak kalkulatzea; eta hamarnaka mila zerbitzariz osatutako flota dugu, eta hori guztia egin behar da.
Zergatik erabaki genuen? Seguruenik, erregistroak gordetzeko irtenbideak izan genituen. Hemen - "Backend VK" publikoa dago. Harpidetza egitea gomendatzen dut.
Zer dira erregistroak? Hau array hutsak itzultzen dituen motorra da. VK-ko motorrak besteek mikrozerbitzuak deitzen dituztenak dira. Eta hona hemen eranskailu irribarretsu bat (gustatu asko). Nolatan? Tira, entzun gehiago!
Zer erabil daiteke erregistroak gordetzeko? Ezinezkoa da Hadup ez aipatzea. Ondoren, adibidez, Rsyslog (erregistro hauek fitxategietan gordetzea). LSDa. Nork daki zer den LSDa? Ez, ez LSD hau. Gorde fitxategiak ere, hurrenez hurren. Beno, ClickHouse aukera bitxia da.
Clickhouse eta lehiakideak: baldintzak eta aukerak
Zer nahi dugu? Funtzionamenduaz gehiegi kezkatu behar ez dugula ziurtatu nahi dugu, kutxatik kanpo funtziona dezan, ahal dela konfigurazio minimoarekin. Asko idatzi nahi dugu, eta azkar idatzi. Eta era guztietako hilabete, urte, hau da, denbora luzez mantendu nahi dugu. Baliteke arazoren bat ulertzea, guregana etorri eta esan zuten: "Hemen zerbait ez dabil" eta duela 3 hilabete izan zen), eta duela 3 hilabete gertatu zena ikusi nahi dugu " Datuen konpresioa -argi dago zergatik izango litzatekeen abantaila-, hartzen duen espazioa murrizten duelako.
Eta baldintza interesgarri bat dugu: batzuetan komando batzuen irteera idazten dugu (adibidez, erregistroak), 4 kilobyte baino gehiago izan daitezke nahiko erraz. Eta gauza honek UDPren bidez funtzionatzen badu, orduan ez du gastatu behar... ez du konexiorako "gastu"rik izango, eta zerbitzari kopuru handientzat hau plus bat izango da.
Ikus dezagun zer eskaintzen digun kode irekiak. Lehenik eta behin, Logs Engine dugu - hau da gure motorra; Printzipioz, denetarik egin dezake, lerro luzeak ere idatzi ditzake. Beno, ez ditu datuak gardenki konprimitzen - zutabe handiak geuk konprimi ditzakegu nahi badugu... guk, noski, ez dugu nahi (ahal bada). Arazo bakarra da bere oroimenean kabitzen dena soilik eman dezakeela; Gainerakoa irakurtzeko, motor honen binlog-a lortu behar duzu eta, horrenbestez, denbora nahiko luzea behar da.
Zein beste aukera daude? Adibidez, "Hadup". Funtzionatzeko erraztasuna... Nork uste du Hadup konfiguratzeko erraza dela? Noski, grabazioarekin ez dago arazorik. Irakurtzean, batzuetan galderak sortzen dira. Printzipioz, seguruenik ezetz esango nuke, batez ere erregistroetarako. Epe luzerako biltegiratzea - noski, bai, datuen konpresioa - bai, kate luzeak - graba dezakezula argi dago. Baina zerbitzari askotatik grabatzen... Oraindik zuk zeuk egin behar duzu zerbait!
Rsyslog. Izan ere, kopia-aukera gisa erabili dugu, binlog-a bota gabe irakurri ahal izateko, baina ezin du lerro luzerik idatzi; printzipioz, ezin du idatzi 4 kilobyte baino gehiago. Datuen konpresioa zuk zeuk egin behar duzu modu berean. Irakurketa fitxategietatik etorriko da.
Ondoren, LSDaren "badushka" garapena dago. Funtsean, "Rsyslog"-en berdina: kate luzeak onartzen ditu, baina ezin du UDP bidez funtzionatu eta, hain zuzen, horregatik, tamalez, gauza asko berridatzi behar dira bertan. LSDa birdiseinatu behar da dozenaka mila zerbitzarietatik grabatu ahal izateko.
Eta hemen! Aukera dibertigarri bat ElasticSearch da. Nola esan? Irakurtzen ondo dabil, hau da, azkar irakurtzen du, baina idazten ez oso ondo. Lehenik eta behin, datuak konprimitzen baditu, oso ahula da. Seguruenik, bilaketa osoak jatorrizko bolumena baino datu-egitura handiagoak behar ditu. Zaila da funtzionatzea eta askotan arazoak sortzen dira. Eta, berriro ere, Elastic-en grabatzea, dena geuk egin behar dugu.
Hemen ClickHouse aukera ezin hobea da, noski. Gauza bakarra da hamarnaka mila zerbitzarietatik grabatzea arazo bat dela. Baina arazo bat behintzat badago, nolabait konpontzen saia gaitezke. Eta gainerako txostenak arazo honi buruzkoak dira. Zer nolako errendimendua espero dezakezu ClickHousetik?
Nola sartuko dugu? MergeTree
Zuetako nork ez du entzun edo daki “ClickHouse”-ri buruz? Esan behar dizut, ezta? Oso azkar. Bertan txertatzeak - 1-2 gigabit segundoko, 10 gigabit segundoko eztandak benetan jasan ditzakete konfigurazio hau - 6 nukleoko bi Xeon daude (hau da, indartsuenak ere ez), 256 gigabyte RAM, 20 terabyte. RAID-en (inor ez da konfiguratuta, ezarpen lehenetsiak). Alexey Milovidov, ClickHouse garatzailea, ziurrenik hor eserita dago negarrez, ez genuelako ezer konfiguratu (guretzat horrela funtzionatu zuen dena). Horren arabera, segundoko 6 milioi lerro inguruko eskaneatzeko abiadura lor daiteke datuak ondo konprimituta badaude. Testu-kate batean % gustatzen bazaizu - 100 milioi lerro segundoko, hau da, nahiko azkarra dirudi.
Nola sartuko dugu? Bada, badakizu VK-k PHP erabiltzen duela. PHP langile bakoitzetik HTTP bidez txertatuko dugu "ClickHouse"-n, erregistro bakoitzeko MergeTree taulan. Nork ikusten du arazo bat eskema honekin? Zerbaitegatik, denek ez zuten eskua altxatu. Esango dizut.
Lehenik eta behin, zerbitzari asko daude; horren arabera, konexio asko egongo dira (txarrak). Orduan hobe da datuak MergeTree-n txertatzea segundoko behin baino gehiagotan. Eta nork daki zergatik? Ados, ados. Honi buruz pixka bat gehiago kontatuko dizut. Beste galdera interesgarri bat da ez dugula analitikarik egiten ari, ez ditugula datuak aberastu behar, ez ditugu tarteko zerbitzaririk behar, zuzenean "ClickHouse"-n txertatu nahi dugu (hobe - zenbat eta zuzenago, orduan eta hobeto).
Horren arabera, nola egiten da txertaketa MergeTree-n? Zergatik da hobe segundoan behin baino gehiagotan edo gutxiagotan sartzea? Izan ere, "ClickHouse" zutabe-datu-base bat da eta datuak gako nagusiaren goranzko ordenan ordenatzen ditu, eta txertaketa bat egiten duzunean, fitxategi kopuru bat sortzen da, gutxienez, datuak ordenatzen diren zutabe kopuruaren berdina. gako nagusiaren goranzko ordenan (direktorio bereizi bat sortzen da, diskoan fitxategi multzo bat txertatze bakoitzeko). Ondoren, hurrengo txertaketa dator, eta atzealdean "partizio" handiagoetan konbinatzen dira. Datuak ordenatuta daudenez, posible da ordenatutako bi fitxategi “batzea” memoria asko kontsumitu gabe.
Baina, asma dezakezun bezala, txertatze bakoitzeko 10 fitxategi idazten badituzu, ClickHouse (edo zure zerbitzaria) azkar amaituko da, beraz, sorta handietan sartzea gomendatzen da. Ondorioz, ez dugu inoiz lehen eskema produkziora abiarazi. Berehala kaleratu genuen bat, hemen 2. zenbakia duena:
Hemen imajinatu abiarazi ditugun mila zerbitzari inguru daudela, PHP besterik ez dagoela. Eta zerbitzari bakoitzean gure tokiko agentea dago, "Kittenhouse" deitu geniona, "ClickHouse"-rekin konexio bat mantentzen duena eta segundo gutxitan datuak sartzen ditu. Datuak MergeTree-n ez txertatzen ditu, buffer-taula batean baizik, eta horrek zehazki MergeTree-n zuzenean txertatzeko balio du.
Buffer taulekin lan egitea
Zer da hau? Buffer-taulak zatitutako memoria zati bat dira (hau da, maiz txerta daitezke). Hainbat piezaz osatuta daude, eta pieza bakoitzak buffer independente gisa funtzionatzen du, eta modu independentean garbitzen dira (bufferean pieza asko badituzu, txertaketa asko egongo dira segundoko). Posible da taula hauetatik irakurtzea - gero buffer-aren eta gurasoen taularen edukien batasuna irakurtzen duzu, baina momentu honetan idazketa blokeatuta dago, beraz, hobe da hortik ez irakurtzea. Eta buffer-taulek QPS oso ona erakusten dute, hau da, 3 mila QPS arte ez duzu inolako arazorik izango txertatzerakoan. Argi dago zerbitzariak potentzia galtzen badu, datuak gal daitezkeela, memorian bakarrik gordetzen zirelako.
Aldi berean, buffer batekin eskemak ALTER zaildu egiten du, lehenik eta behin buffer taula zaharra eskema zaharrarekin bota behar duzulako (datuak ez dira inon desagertuko, taula ezabatu baino lehen garbitu egingo delako). Ondoren, behar duzun taula "aldatu" eta buffer taula berriro sortzen duzu. Horren arabera, buffer taularik ez dagoen bitartean, zure datuak ez dira inora joango, baina diskoan eduki ditzakezu lokalean behintzat.
Zer da Kittenhouse eta nola funtzionatzen du?
Zer da KittenHouse? Hau proxy bat da. Asmatu zein hizkuntza? Nire txostenean bildu nituen gai gehien: "Clickhouse", Go, agian beste zerbait gogoratuko dut. Bai, hau Go-n idatzita dago, ez baitakit benetan C-n idazten, ez dut nahi.
Horren arabera, zerbitzari bakoitzarekin konexioa mantentzen du eta memorian idatzi dezake. Adibidez, Clickhouse-n errore-erregistroak idazten baditugu, orduan Clickhouse-k datuak txertatzeko denborarik ez badu (azken finean, gehiegi idazten bada), ez dugu memoria puzten; gainerakoak bota besterik ez ditugu egiten. Zeren eta segundoko hainbat gigabit akats idazten baditugu, seguruenik batzuk bota ditzakegu. Kittenhousek hau egin dezake. Gainera, entrega fidagarria egin dezake, hau da, tokiko makinan diskoan idazten eta behin (bertan, segundo parean behin) fitxategi horretatik datuak ematen saiatzen da. Hasieran Balioen formatu arrunta erabili genuen, ez formatu bitar bat, testu formatua (SQL arruntean bezala).
Baina gero hau gertatu zen. Bidalketa fidagarria erabili genuen, erregistroak idatzi, gero erabaki (baldintzatutako proba-kluster bat zen)... Hainbat orduz atera eta berriro itzuli zen, eta mila zerbitzarietatik txertatze bat hasi zen - Clickhouse-k oraindik zeukan "Haria konexioan" - horren arabera, mila konexiotan, txertatze aktibo batek zerbitzarian mila eta erdi inguruko karga bat dakar. Harrigarria bada ere, zerbitzariak eskaerak onartu zituen, baina denboraren buruan datuak oraindik txertatzen ziren; baina zerbitzariarentzat oso zaila zen hura zerbitzatzea...
Gehitu nginx
Thread per konexio-ereduaren irtenbidea nginx da. Clickhouse-ren aurrean nginx instalatu genuen, eta, aldi berean, bi errepliketarako balantzea ezarri genuen (gure txertatzeko abiadura 2 aldiz handitu zen, hala izan behar denik ere ez den arren) eta Clickhouse-rako konexio kopurua mugatu genuen. ibaian gora eta, horrenbestez, 50 konexiotan baino gehiago, badirudi ez duela txertatzeko balio.
Orduan konturatu ginen eskema honek orokorrean desabantailak dituela, hemen nginx bakarra dugulako. Horren arabera, nginx hau huts egiten bada, erreplikak egon arren, datuak galtzen ditugu edo, behintzat, ez dugu inon idazten. Horregatik egin dugu gure karga orekatzeko. Gainera, konturatu ginen "Clickhouse" erregistroetarako egokia dela oraindik, eta "deabrua" ere bere erregistroak idazten hasi zen "Clickhouse"-n - oso erosoa, egia esan. Oraindik beste "deabruentzako" erabiltzen dugu.
Orduan aurkitu dugu arazo interesgarri hau: SQL moduan txertatzeko metodo ez-estandarra erabiltzen baduzu, AST-n oinarritutako SQL analizatzaile osoa behartzen du, nahiko motela. Horren arabera, ezarpenak gehitu ditugu hori inoiz gertatu ez dadin. Karga-balantzea, osasun-kontrolak egin genituen, bat hiltzen bada, datuak uzten ditugu oraindik. Orain taula asko ditugu Clickhouse kluster desberdinak izan behar ditugunak. Eta beste erabilera batzuei buruz ere pentsatzen hasi ginen - adibidez, nginx moduluetatik erregistroak idatzi nahi genituen, baina ez dakite nola komunikatu gure RPC erabiliz. Beno, gutxienez nola edo hala nola bidali irakatsi nahiko nieke; adibidez, localhost-en gertaerak UDP bidez jaso eta gero Clickhouse-ra bidaltzeko.
Konponbidetik pauso batera
Azken eskema honela hasi zen (eskema honen laugarren bertsioa): Clickhouse-ren aurrean zerbitzari bakoitzean nginx dago (zerbitzari berean) eta localhost-era eskaerak proxy besterik ez ditu egiten 50 konexio kopuruaren mugarekin. piezak. Eta eskema hau jada nahiko funtzionatzen zuen, dena nahiko ondo zegoen.
Hilabete inguru horrela bizi izan ginen. Denak pozik zeuden, taulak gehitu, gehitu, gehitu... Oro har, buffer taulak gehitzeko modua ez zela oso optimoa atera zen (esan dezagun horrela). Taula bakoitzean 16 pieza egin genituen eta segundo pare bateko flash tartea; 20 taula genituen eta mahai bakoitzak 8 txertaketa jasotzen zituen segundoko - eta momentu honetan “Clickhouse” hasi zen... erregistroak moteltzen hasi ziren. Ez zuten pasatu ere egin... Nginx-ek lehenespenez hain gauza interesgarria zuen, konexioak goran amaitzen baziren, "502" besterik ez zuen itzultzen eskaera berri guztiei.
Eta hemen dugu (Clickhousen bertan erregistroak begiratu berri ditut) eskaeren ehuneko erdiak huts egin du. Horren arabera, diskoaren erabilera handia izan zen, bateratze asko egon ziren. Tira, zer egin nuen? Jakina, ez nintzen trabarik hartu zergatik amaitu zen konexioa eta upstream.
Nginx ordezkatuz alderantzizko proxy batekin
Hau geuk kudeatu behar dugula erabaki nuen, ez dugula nginx-i utzi behar - nginx-ek ez daki Clickhouse-n zer taula dauden, eta nginx ordezkatu nuen alderantzizko proxy batekin, nik neuk ere idatzi nuena.
Zertan ari da? "goshnoy" fasthttp liburutegian oinarrituta funtzionatzen du, hau da, azkarra, ia nginx bezain azkar. Barkatu, Igor, hemen bazaude (oharra: Igor Sysoev nginx web zerbitzaria sortu zuen Errusiako programatzailea da). Zer-nolako kontsultak diren uler dezake - txertatu edo HAUTATU -, horren arabera, kontsulta mota desberdinetarako konexio-multzo desberdinak ditu.
Horren arabera, txertatze-eskaerak betetzeko denborarik ez badugu ere, "hautatuak" gaindituko dira, eta alderantziz. Eta datuak buffer-tauletan biltzen ditu -buffer txiki batekin: akatsak, sintaxi-akatsak eta abar egongo balira-, gainerako datuei asko eragin ez diezaieten, buffer-tauletan txertatzean, besterik gabe, guk "bachi" txikia zuen, eta sintaxi akats guztiek pieza txiki honi bakarrik eragiten zioten; eta hemen dagoeneko buffer handi bati eragingo diote. Txikia megabyte 1 da, hau da, ez hain txikia.
Sinkronizazio bat txertatzeak eta funtsean nginx ordezkatzeak, funtsean, nginx-ek lehen egiten zuen gauza bera egiten du: ez duzu tokiko "Kittenhouse" aldatu behar horretarako. Eta fasthttp erabiltzen duenez, oso azkarra da; segundoko 100 mila eskaera baino gehiago egin ditzakezu txertatze bakarreko alderantzizko proxy baten bidez. Teorian, lerro bat txerta dezakezu kittenhouse alderantzizko proxyan, baina, noski, ez dugu horrelakorik egiten.
Eskema honela hasi zen: "Kittenhouse", alderantzizko proxy-ak eskaera asko tauletan biltzen ditu eta, aldi berean, buffer-taulek nagusietan txertatzen dituzte.
Hiltzailea behin-behineko irtenbidea da, Kitten iraunkorra
Hau arazo interesgarria da... Zuetako batek erabili al du fasthttp? Nork erabili zuen fasthttp POST eskaerarekin? Seguruenik, hau ez litzateke egin behar, eskaeraren gorputza lehenespenez bufferatzen duelako eta gure bufferaren tamaina 16 megabyte-n ezarri baitzen. Txertazioak uneren batean mantentzeari utzi zion, eta hamarnaka mila zerbitzarietatik 16 megabyte-ko zatiak iristen hasi ziren, eta guztiak memorian gorde ziren Clickhousera bidali aurretik. Horren arabera, memoria agortu zen, Memoriaz Kanpoko Hiltzailea etorri zen eta alderantzizko proxya (edo "Clickhouse", teorian alderantzizko proxyak baino gehiago "jan" zezakeen) hil zuen. Zikloa errepikatu zen. Ez da oso arazo atsegina. Hainbat hilabetetan funtzionamenduaren ondoren bakarrik topatu genuen arren.
Zer egin dut? Berriz ere, ez zait asko gustatzen zer gertatu zen zehazki ulertzea. Uste dut nahiko argia dela ez duzula memorian gorde behar. Ezin izan nuen adabaki azkar http, saiatu nintzen arren. Baina egiteko modu bat aurkitu nuen ezer adabaki beharrik ez izateko, eta HTTP-n nire metodo propioa sortu nuen - KITTEN deitu nion. Beno, logikoa da - "VK", "Kitten"... Zer gehiago?...
Eskaera bat Kitten metodoarekin zerbitzariari heltzen bazaio, zerbitzariak "meow" erantzun beharko luke - logikoki. Honi erantzuten badu, protokolo hau ulertzen duela uste da, eta orduan konexioa atzematen dut (fasthttp-k horrelako metodoa du), eta konexioa "gordina" moduan sartzen da. Zergatik behar dut? TCP konexioetatik irakurketa nola gertatzen den kontrolatu nahi dut. TCP-k propietate zoragarria du: inork ez badu beste alde batetik irakurtzen ari, orduan idazketa itxaroten hasten da, eta memoria ez da horretarako bereziki gastatzen.
Eta, beraz, aldi berean 50 bat bezerorengandik irakurri nuen (berrogeita hamarretik berrogeita hamar nahikoa izan beharko lukeelako, tasa beste DC batetik badator ere)... Ikuspegi honekin gutxienez 20 aldiz jaitsi da kontsumoa, baina nik, egia esateko , ezin izan dut zehatz-mehatz neurtu zein ordutan, jadanik alferrikakoa delako (dagoeneko akats mailara iritsi da). Protokoloa bitarra da, hau da, taularen izena eta datuak ditu; ez dago http goibururik, beraz, ez dut web socket bat erabili (ez dut arakatzaileekin komunikatu behar - gure beharretara egokitzen den protokoloa egin dut). Eta dena ondo atera zitzaion.
Buffer mahaia triste dago
Duela gutxi buffer taulen beste ezaugarri interesgarri bat topatu dugu. Eta arazo hau dagoeneko beste batzuk baino askoz mingarriagoa da. Imajina dezagun egoera hau: Clickhouse aktiboki erabiltzen ari zara dagoeneko, dozenaka Clickhouse zerbitzari dituzu eta irakurtzeko oso denbora luzea behar duten eskaera batzuk dituzu (demagun, 60 segundo baino gehiago); eta une honetan etorri eta Alter egiten duzu... Bitartean, "Alter" baino lehen hasitako "hautaketak" ez dira taula honetan sartuko, "Alter" ez da hasiko - ziurrenik "Clickhouse"-n funtzionatzen duen ezaugarri batzuk. leku hau. Agian hau konpondu daiteke? Edo ez al da posible?
Oro har, argi dago errealitatean hori ez dela hain arazo handia, baina buffer-taulekin mingarriagoa bihurtzen da. Zeren eta, demagun, zure "Alter" denbora-muga igarotzen bada (eta baliteke beste ostalari batean denbora-muga agortzea - ez zurean, baizik eta erreplika batean, adibidez), orduan... Buffer taula ezabatu duzu, zure "Alter" ( edo beste ostalariren bat) denbora-muga gainditu du, gero "Altertu" errore bat gertatu da) - oraindik ere ziurtatu behar duzu datuak idazten jarraitzen duela: buffer-taulak berriro sortzen dituzu (taula nagusiaren eskema beraren arabera), gero "Alter" igarotzen da, amaitzen da azken finean, eta taularen buffer-a eskemaren arabera aldatzen hasten da gurasoarekiko. "Alter" izan zenaren arabera, baliteke txertatzea buffer taula honetara ez joatea - oso tristea da.
Halako seinale bat ere badago (agian norbaitek nabaritu zuen) - Clickhouse-ren bertsio berrietan query_thread_log deitzen da. Berez, bertsio batzuetan bazegoen bat. Hemen 840 milioi disko pilatu ditugu hilabete pare batean (100 gigabyte). Hor “txertaketak” idazten zirelako da hori (agian orain, bide batez, ez daude idatzita). Esan dizudan bezala, gure "txertaketak" txikiak dira - "txertatze" asko genituen buffer-tauletan. Argi dago hori desgaituta dagoela - gure zerbitzarian ikusi dudana kontatzen ari naiz. Zergatik? Hau buffer taulak erabiltzearen aurkako beste argudio bat da! Spotty oso triste dago.
Nork zekien tipo honen izena Spotty zela? VKko langileek eskuak altxatu zituzten. ADOS.
"KitttenHouse"-ren planei buruz
Normalean ez dira planak partekatzen, ezta? Bat-batean ez dituzu beteko eta ez duzu oso ondo ikusiko besteen begietan. Baina arriskua hartuko dut! Hauxe egin nahi dugu: buffer taulak, iruditzen zait, oraindik makulu bat dira eta geuk txertatu behar dugu buffer. Baina oraindik ez dugu diskoan gorde nahi, beraz, memorian txertatzea gordeko dugu.
Horren arabera, "txertaketa" bat egiten denean, jada ez da sinkronoa izango - dagoeneko buffer-taula gisa funtzionatuko du, gurasoen taulan txertatuko da (beno, egunen batean) eta kanal bereizi baten bidez jakinaraziko du zein txertatu diren eta zeintzuk diren. ez daukate.
Zergatik ezin dut txertaketa sinkronikoa utzi? Askoz erosoagoa da. Kontua da 10 mila ostalaritik sartzen badituzu, dena ondo dago - ostalari bakoitzarengandik pixka bat lortuko duzu, segundoan behin txertatzen duzu, dena ondo dago. Baina gustatuko litzaidake eskema honek funtzionatzea, adibidez, bi makinetatik, abiadura handian deskargatu ahal izateko - agian Clickhouse-tik gehienez ez ateratzea, baina idatzi gutxienez 100 megabyte segundoko makina batetik alderantzizko proxy baten bidez - hau eskemak kantitate handi zein txikietara eskalatu behar du, beraz, ezin dugu segundo bat itxaron txertatze bakoitzeko, beraz asinkronoa izan behar du. Eta era berean, baieztapen asinkronoak txertaketa amaitu ondoren etorri beharko lirateke. Pasa den ala ez jakingo dugu.
Garrantzitsuena da eskema honetan txertaketa egin den ala ez ziur dakigula. Imajinatu egoera hau: buffer-taula bat duzu, zerbait idatzi duzu eta gero, demagun, taula irakurtzeko moduan sartu eta buffera garbitzen saiatu zen. Nora joango dira datuak? Bufferean geratuko dira. Baina ezin dugu honetaz ziur egon - zer gertatzen da beste erroreren bat badago, eta horren ondorioz datuak ez dira bufferean geratuko... (Alexey Milovidov, Yandex, ClickHouse garatzaileari helbideak) Edo geratuko al da? Beti? Alexeyk konbentzitzen gaitu dena ondo egongo dela. Ez dugu berari ez sinesteko arrazoirik. Baina berdin: ez baditugu buffer taulak erabiltzen, orduan ez da arazorik izango haiekin. Taula bikoitza sortzea ere deserosoa da, printzipioz arazo handirik ez dagoen arren. Hau da plana.
Hitz egin dezagun irakurketaz
Orain hitz egin dezagun irakurketaz. Gure tresna ere idatzi dugu hemen. Badirudi, ba, zergatik idatzi zure tresna hemen?... Eta nork erabili zuen Tabix? Nolabait jende gutxik altxatu zuen eskua... Eta nor dago pozik Tabixen emanaldiarekin? Tira, ez gaude pozik, eta ez da oso erosoa datuak ikusteko. Analitiketarako ondo dago, baina ikusteko bakarrik ez dago optimizatuta. Beraz, nire interfazea idatzi nuen.
Oso erraza da - datuak soilik irakur ditzake. Ez daki grafikoak erakusten, ez daki ezer egiten. Baina behar duguna erakutsi dezake: adibidez, zenbat errenkada dauden taulan, zenbat leku hartzen duen (zutabeetan zatitu gabe), hau da, oso oinarrizko interfazea da behar duguna.
Eta Sequel Pro-ren oso antzekoa da, baina Twitterren Bootstrap-en eta bigarren bertsioan bakarrik egina. Galdetzen duzu: "Yuri, zergatik bigarren bertsioan?" Zein urte? 2018? Orokorrean, duela denbora dezente egin nuen hau "Muscle"-rako (MySQL) eta lerro pare bat aldatu besterik ez nuen egin hango kontsultetan, eta "Clickhouse"-rako lanean hasi zen, horregatik eskerrik asko! Analizatzailea "muskulu"aren oso antzekoa delako eta kontsultak oso antzekoak direlako, oso erosoa, batez ere hasieran.
Beno, taulak iragazten ditu, taularen egitura eta edukia erakutsi dezake, ordenatzeko aukera ematen du, zutabeen arabera iragazteko, emaitzaren emaitza izan duen kontsulta erakusten du, kaltetutako errenkadak (ondorioz zenbat), hau da, datuak ikusteko oinarrizko gauzak. Nahiko azkarra.
Editore bat ere badago. Zintzotasunez saiatu nintzen Tabixeko editore osoa lapurtzen, baina ezin izan nuen. Baina nolabait funtzionatzen du. Printzipioz, hori da dena.
"Clickhouse" densetarako egokia da
Esan nahi dizut Clickhouse, deskribatutako arazo guztiak gorabehera, oso egokia dela erregistroetarako. Garrantzitsuena, gure arazoa konpontzen du - oso azkarra da eta erregistroak zutabeen arabera iragazteko aukera ematen du. Printzipioz, buffer-taulek ez dute ondo funtzionatu, baina normalean inork ez daki zergatik... Agian orain hobeto dakizu non izango dituzun arazoak.
TCP? Oro har, VKn UDP erabiltzea ohikoa da. Eta TCP erabili nuenean... Noski, inork ez zidan esan: “Yuri, zertaz ari zara! Ezin duzu, UDP behar duzu». Agertu zen TCP ez dela hain beldurgarria. Gauza bakarra da, idazten dituzun dozenaka mila konposatu aktibo badituzu, kontu handiz prestatu behar duzula; baina posible da, eta nahiko erraza.
"Kittenhouse" eta "Lighthouse" HighLoad Siberian argitaratuko nituen hitza eman nuen denek gure "VK backend" publikora harpidetzen baziren... Eta badakizu, denek ez zuten harpidetu... Noski, ez dizut exijituko gure harpidetzara harpidetzeko. publiko. Oraindik gehiegi zarete, norbait mindu ere egin daiteke, baina hala ere, mesedez harpidetu zaitez (eta hemen katu baten moduko begiak egin behar ditut). Hori da . Eskerrik asko! Github gurea da . Clickhouse-rekin zure ilea leuna eta zetatsua izango da.
Liderra: - Lagunak, orain galderak egiteko. Berehala, estimazio-ziurtagiria eta zure VHSari buruzko txostena aurkezten ditugu.
Yuri Nasretdinov (aurrerantzean YN deitzen da): – Nola grabatu ahal izan zenuen nire txostena VHS-n amaitu berri bazen?
Liderra: - Ezin duzu guztiz zehaztu "Clickhouse" nola funtzionatuko duen edo ez! Lagunak, 5 minutu galderak egiteko!
Zure galderak
Entzuleen galdera (aurrerantzean Q deitzen zaio): - Arratsalde on. Mila esker erreportajeagatik. Bi galdera ditut. Zerbait fribolo batekin hasiko naiz: eskemetan (3, 4, 7...) "Kittenhouse" izenaren t letren kopuruak eragiten al du katuen gogobetetasunean?
YN: - Zer kantitatea?
Z: – T letra. Hiru t daude, nonbait hiru t inguruan.
YN: - Ez al dut konpondu? Beno, noski! Produktu desberdinak dira - denbora honetan guztian engainatzen ari nintzen. Ados, txantxetan ari naiz, ez du axola. Ah, hementxe! Ez, gauza bera da, akatsa egin dut.
Z: - Eskerrik asko. Bigarren galdera serioa da. Ulertzen dudanez, Clickhouse-n, buffer-taulak memorian soilik bizi dira, ez dira diskoan bufferatzen eta, ondorioz, ez dira iraunkorrak.
YN: - Bai.
Z: – Eta, aldi berean, zure bezeroak diskoan bufferatzen du, eta horrek erregistro horiek beraiek entregatzeko bermea dakar. Baina hori ez dago inolaz ere ziurtatzen Clickhousen. Azaldu nola egiten den bermea, zer dela eta?.. Hona hemen mekanismo hau zehatzago
YN: – Bai, teorikoki ez dago kontraesanik hemen, izan ere, Clickhouse erortzen denean milioi bat modu ezberdinetan detektatu dezakezu. Clickhouse-k huts egiten badu (gaizki amaitzen bada), gutxi gorabehera, idatzi duzun erregistrotik apur bat atzera egin dezakezu eta dena ondo zegoen momentutik hasi. Demagun minutu bat atzera egiten duzula, hau da, minutu batean dena garbitu duzula kontsideratzen da.
Z: – Hau da, “Kittenhouse”-k leihoari luzeago eusten dio eta, eroriko balitz, ezagutu eta atzera bota dezake?
YN: – Baina hau teorian dago. Praktikan, ez dugu horrelakorik egiten, eta entrega fidagarria zerotik infinitura bitartekoa da. Baina batez beste bat. Pozik gaude Clickhouse arrazoiren batengatik huts egiten badu edo zerbitzariak "berrabiarazi" egiten badu, pixka bat galtzen dugula. Gainerako kasuetan, ez da ezer gertatuko.
Z: - Kaixo. Hasiera-hasieratik iruditu zitzaidan UDP erabiliko zenuela txostenaren hasieratik. http daukazu, hori guztia... Eta deskribatu dituzun arazo gehienak, nik ulertzen dudanez, konponbide berezi honek eragin ditu...
YN: – Zer erabiltzen dugu TCP?
Z: - Funtsean bai.
YN: - Ez.
Z: – Fasthttprekin arazoak izan dituzu, konexioarekin arazoak izan dituzu. UDP erabili berri bazenu denbora pixka bat aurreztuko zenuke. Tira, arazoak egongo lirateke mezu luzeekin edo beste zerbaitekin...
YN: - Zerekin?
Z: – Mezu luzeekin, agian MTUn sartzen ez denez, beste zerbait... Tira, arazo propioak egon daitezke. Galdera da: zergatik ez UDP?
YN: – Uste dut TCP/IP garatu duten egileak ni baino askoz adimentsuagoak direla eta ni baino hobeto dakitela paketeak nola serializatzen (joateko), aldi berean bidalketa leihoa egokitu, sarea gainkargatu gabe, zeri buruzko iritzia ematen ez da irakurtzen, ez beste aldean kontatu... Arazo hauek guztiak, nire ustez, UDPn egongo lirateke, nik bakarrik idatzi dudana baino kode gehiago idatzi beharko nuke nik neuk eta ziurrenik gauza bera ezartzeko gaizki. C-n idaztea ere ez zait asko gustatzen, are gutxiago...
Z: - Erosoa besterik ez! Ondo bidali da eta ez itxaron ezertarako - guztiz asinkronoa da. Jakinarazpen bat itzuli zen, dena ondo zegoela esan nahi du; horrek esan nahi du iritsi zela; Etortzen ez bada, txarra dela esan nahi du.
YN: – Biak behar ditut – Biak bidaltzeko gai izan behar ditut bidaltzeko bermearekin eta bidaltzeko bermerik gabe. Hauek bi eszenatoki ezberdin dira. Erregistro batzuk ez galdu edo arrazoiaren barruan ez galdu behar.
Z: —Ez dut denbora galduko. Hau gehiago eztabaidatu behar da. Eskerrik asko.
Liderra: – Nork ditu galderak – eskuak zerura!
Z: - Kaixo, Sasha naiz. Txostenaren erdian nonbait, TCPaz gain, prest egindako irtenbide bat erabiltzea posible zelako sentsazioa agertu zen, Kafka moduko bat.
YN: – Bueno... esan dizut ez dudala bitarteko zerbitzariak erabili nahi, zeren... Kafkan, hamar mila ostalari ditugula ateratzen da; izan ere, gehiago ditugu —hamarka mila ostalari—. Mingarria ere izan daiteke Kafkarekin inolako proxyrik gabe egitea. Horrez gain, garrantzitsuena, oraindik "latentzia" ematen du, izan behar dituzun ostalari gehigarriak ematen ditu. Baina ez ditut eduki nahi - nahi ditut...
Z: «Baina azkenean horrela atera zen hala ere».
YN: – Ez, ez dago ostalaririk! Horrek guztiak Clickhouse ostalarietan funtzionatzen du.
Z: - Beno, eta "Kittenhouse", zein da alderantziz - non bizi da?
YN: – Clickhouse ostalarian, ez du ezer idazten diskoan.
Z: - Demagun.
Liderra: – Pozik al zaude? Eman al dizuegu soldata?
Z: - Bai, egin dezakezu. Izan ere, makulu asko daude gauza bera lortzeko, eta orain - TCP gaiari buruzko aurreko erantzuna, nire ustez, egoera honekin kontraesanean dago. Besterik gabe, dena denbora gutxiagoan belauniko egin zitekeela iruditzen zait.
YN: – Eta baita zergatik ez nuen Kafka erabili nahi, Clickhouse Telegrameko txatean kexa dezente egon zirelako, adibidez, Kafkaren mezuak galdu zirelako. Kafkatik bertatik ez, Kafka eta Clickhausen integrazioan baizik; edo zerbait ez zen hor lotzen. Gutxi gorabehera, Kafkarentzat bezero bat idaztea beharrezkoa izango litzateke orduan. Ez dut uste irtenbide sinpleago edo fidagarriagorik egon daitekeenik.
Z: – Esadazu, zergatik ez zenuen probatu ilararik edo autobus arrunten bat? Asinkroniarekin erregistroak beraiek ilararen bidez bidal ditzakezula eta ilararen bidez erantzuna modu asinkronoan jaso ditzakezula esaten duzunez?
YN: – Mesedez, iradoki zer ilara erabil daitezkeen?
Z: – Edozein, ondo daudela bermatu gabe ere. Nolabaiteko Redis, RMQ...
YN: – Sentsazioa dut Redis-ek ziurrenik ezin izango duela horrelako txertatze bolumena atera Clickhouse ateratzen duen ostalari batean ere (hainbat zerbitzariren zentzuan). Ezin dut frogarik egin (ez dut erreferentziarik egin), baina iruditzen zait Redis ez dela hemen irtenbiderik onena. Printzipioz, sistema hau mezu-ilara inprobisatu gisa har daiteke, baina "Clickhouse"-rako soilik egokituta dagoena.
Liderra: -Yuri, eskerrik asko. Galderak eta erantzunak hemen amaitzea eta galdera egin dutenen artean liburua zeini emango diogun esatea proposatzen dut.
YN: – Liburu bat eman nahiko nioke galdera bat egin duen lehen pertsonari.
Liderra: - Zoragarria! Bikaina! Zoragarria! Mila esker!
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com