HighLoad++ Moskva 2018, Kongresna dvorana. 9. studenog, 15:00
Sažeci i prezentacija:
Yuri Nasretdinov (VKontakte): izvješće će govoriti o iskustvu implementacije ClickHousea u našoj tvrtki - zašto nam je to potrebno, koliko podataka pohranjujemo, kako ih pišemo i tako dalje.
Dodatni materijali:
Jurij Nasretdinov: - Bok svima! Moje ime je Yuri Nasretdinov, kako su me već predstavili. Radim u VKontakte. Govorit ću o tome kako ubacujemo podatke u ClickHouse s naše flote poslužitelja (desetke tisuća).
Što su cjepanice i zašto ih sakupljati?
Što ćemo vam reći: što smo učinili, zašto nam je trebao „ClickHouse“, odnosno, zašto smo ga odabrali, kakvu izvedbu otprilike možete dobiti bez da bilo što posebno konfigurirate. Reći ću vam dalje o međuspremničkim tablicama, o problemima koje smo imali s njima i o našim rješenjima koja smo razvili iz otvorenog koda - KittenHouse i Lighthouse.
Zašto smo uopće morali nešto učiniti (na VKontakteu je uvijek sve dobro, zar ne?). Htjeli smo prikupiti zapisnike otklanjanja pogrešaka (a tamo je bilo stotine terabajta podataka), možda bi nekako bilo prikladnije izračunati statistiku; i imamo flotu od desetaka tisuća poslužitelja s kojih sve to treba učiniti.
Zašto smo se odlučili? Vjerojatno smo imali rješenja za skladištenje dnevnika. Evo - postoji takav javni "Backend VK". Toplo preporučujem da se pretplatite na njega.
Što su dnevnici? Ovo je mehanizam koji vraća prazne nizove. Motori u VK su ono što drugi nazivaju mikroservisima. A evo i nasmiješene naljepnice (dosta lajkova). Kako to? Pa slušajte dalje!
Što se može koristiti za pohranjivanje dnevnika? Nemoguće je ne spomenuti Hadupa. Zatim, na primjer, Rsyslog (spremanje ovih zapisa u datoteke). LSD. Tko zna što je LSD? Ne, ne ovaj LSD. Pohranite datoteke, odnosno, također. Pa, ClickHouse je čudna opcija.
Clickhouse i konkurenti: zahtjevi i mogućnosti
Što želimo? Želimo osigurati da ne moramo previše brinuti o radu, tako da radi izvan kutije, po mogućnosti s minimalnom konfiguracijom. Želimo pisati puno, i pisati brzo. I želimo ga čuvati kojekakve mjesece, godine, odnosno dugo. Možda želimo razumjeti neki problem s kojim su nam došli i rekli: "Ovdje nešto ne radi", a to je bilo prije 3 mjeseca), i želimo vidjeti što se dogodilo prije 3 mjeseca " Kompresija podataka – jasno je zašto bi to bio plus – jer smanjuje količinu prostora koji zauzima.
I imamo tako zanimljiv zahtjev: ponekad pišemo izlaz nekih naredbi (na primjer, dnevnike), vrlo lako može biti veći od 4 kilobajta. A ako ova stvar radi preko UDP-a, onda ne treba trošiti... neće imati "overhead" za vezu, a za veliki broj servera to će biti plus.
Pogledajmo što nam open source nudi. Prvo, imamo Logs Engine - ovo je naš motor; U principu, može sve, može čak i pisati duge redove. Pa, ne sažima transparentno podatke - možemo sami sažimati velike stupce ako želimo... mi, naravno, ne želimo (ako je moguće). Jedini je problem što može odati samo ono što mu stane u sjećanje; Da biste pročitali ostatak, morate dobiti binlog ovog motora i, sukladno tome, potrebno je dosta vremena.
Koje druge opcije postoje? Na primjer, "Hadup". Jednostavnost rada... Tko misli da je Hadup lako postaviti? Naravno, nema problema sa snimanjem. Prilikom čitanja ponekad se pojave pitanja. U principu, rekao bih vjerojatno ne, pogotovo za cjepanice. Dugoročna pohrana - naravno, da, kompresija podataka - da, dugi nizovi - jasno je da možete snimati. Ali snimanje s velikog broja servera... Ipak morate nešto učiniti sami!
Rsyslog. Zapravo, koristili smo ga kao rezervnu opciju kako bismo ga mogli čitati bez izbacivanja binloga, ali ne može pisati duge retke, u principu ne može pisati više od 4 kilobajta. Morate sami izvršiti kompresiju podataka na isti način. Čitanje će doći iz datoteka.
Zatim postoji "baduška" razvoj LSD-a. U suštini isto što i "Rsyslog": podržava duge nizove, ali ne može raditi preko UDP-a i, zapravo, zbog toga, nažalost, postoji dosta stvari koje treba prepisati. LSD treba redizajnirati da bi mogao snimati s desetak tisuća servera.
I ovdje! Smiješna opcija je ElasticSearch. Kako reći? Čitanje mu ide dobro, odnosno brzo čita, ali ne baš najbolje pisanje. Prvo, ako sažima podatke, vrlo je slab. Najvjerojatnije, potpuno pretraživanje zahtijeva veće strukture podataka od izvornog volumena. Teško je rukovati i često nastaju problemi s njim. I, opet, snimanje u Elasticu – sve moramo sami.
Ovdje je ClickHouse naravno idealna opcija. Jedino što je snimanje s desetak tisuća servera problem. Ali barem postoji jedan problem, možemo ga pokušati nekako riješiti. I ostatak izvješća govori o ovom problemu. Kakvu izvedbu možete očekivati od ClickHousea?
Kako ćemo ga umetnuti? Spoji stablo
Tko od vas nije čuo ili zna za “ClickHouse”? Moram ti reći, zar ne? Vrlo brzo. Umetanje tamo - 1-2 gigabita u sekundi, rafali do 10 gigabita u sekundi zapravo mogu izdržati ovu konfiguraciju - postoje dva 6-jezgrena Xeona (dakle, čak ni najsnažniji), 256 gigabajta RAM-a, 20 terabajta u RAID-u (nitko nije konfigurirao, zadane postavke). Alexey Milovidov, ClickHouse programer, vjerojatno sjedi tamo i plače jer nismo ništa konfigurirali (nama je sve tako radilo). Sukladno tome, može se postići brzina skeniranja od, recimo, oko 6 milijardi redaka u sekundi ako su podaci dobro komprimirani. Ako vam se sviđa % na tekstualnom nizu - 100 milijuna redaka u sekundi, to jest, čini se prilično brzo.
Kako ćemo ga umetnuti? Pa, znate da VK koristi PHP. Umetnut ćemo iz svakog PHP radnika putem HTTP-a u “ClickHouse”, u tablicu MergeTree za svaki zapis. Tko vidi problem u ovoj shemi? Iz nekog razloga nisu svi digli ruke. Dopustite mi da vam kažem.
Prvo, ima puno poslužitelja - prema tome, bit će puno veza (loših). Tada je bolje unositi podatke u MergeTree ne češće nego jednom u sekundi. I tko zna zašto? U redu u redu. Reći ću vam nešto više o ovome. Još jedno zanimljivo pitanje je da ne radimo analitiku, ne trebamo obogaćivati podatke, ne trebamo međuposlužitelje, želimo ubaciti izravno u "ClickHouse" (po mogućnosti - što izravnije, to bolje).
Sukladno tome, kako se vrši umetanje u MergeTree? Zašto je bolje umetati u njega ne češće nego jednom u sekundi ili rjeđe? Činjenica je da je “ClickHouse” baza podataka u stupcima i sortira podatke uzlaznim redoslijedom primarnog ključa, a kada radite insert, kreira se broj datoteka najmanje jednak broju stupaca u kojima su podaci poredani. uzlaznim redoslijedom primarnog ključa (stvara se poseban direktorij, skup datoteka na disku za svaki umetak). Zatim dolazi sljedeće umetanje, au pozadini se kombiniraju u veće "particije". Budući da su podaci razvrstani, moguće je “spojiti” dvije sortirane datoteke bez utroška puno memorije.
Ali, kao što možete pogoditi, ako napišete 10 datoteka za svaki umetak, tada će ClickHouse (ili vaš poslužitelj) brzo završiti, pa se preporučuje umetanje u velikim serijama. Sukladno tome, prvu shemu nikada nismo pustili u proizvodnju. Odmah smo lansirali jedan, koji ovdje broj 2 ima:
Ovdje zamislite da postoji oko tisuću poslužitelja na kojima smo pokrenuli, tu je samo PHP. A na svakom serveru postoji naš lokalni agent, kojeg smo nazvali “Kittenhouse”, koji održava jednu vezu sa “ClickHouseom” i ubacuje podatke svakih nekoliko sekundi. Umeće podatke ne u MergeTree, već u međuspremničku tablicu, koja služi upravo za izbjegavanje izravnog umetanja u MergeTree odmah.
Rad s međuspremničkim tablicama
Što je? Tablice međuspremnika dio su memorije koji je podijeljen (to jest, može se često umetati u nju). Sastoje se od nekoliko dijelova, a svaki od dijelova radi kao neovisni međuspremnik i ispiru se neovisno (ako imate mnogo dijelova u međuspremniku, tada će biti mnogo umetanja u sekundi). Moguće je čitati iz ovih tablica - tada čitate uniju sadržaja međuspremnika i nadređene tablice, ali u ovom trenutku pisanje je blokirano, pa je bolje ne čitati od tamo. I tablice međuspremnika pokazuju vrlo dobar QPS, odnosno do 3 tisuće QPS-a nećete imati nikakvih problema pri umetanju. Jasno je da ako poslužitelj izgubi napajanje, tada se podaci mogu izgubiti, jer su bili samo pohranjeni u memoriji.
U isto vrijeme, shema s međuspremnikom komplicira ALTER, jer prvo morate ispustiti staru međuspremnik tablicu sa starom shemom (podaci neće nigdje nestati, jer će se isprati prije brisanja tablice). Zatim "mijenjate" tablicu koja vam je potrebna i ponovno kreirate međuspremnik. U skladu s tim, dok nema međuspremnika, vaši podaci neće nikamo teći, ali ih možete imati na disku barem lokalno.
Što je Kittenhouse i kako radi?
Što je KittenHouse? Ovo je proxy. Pogodite koji jezik? Sakupio sam najviše hype tema u svom izvješću - "Clickhouse", Idi, možda se sjetim nečeg drugog. Da, ovo je napisano u Go-u, jer ja zapravo ne znam pisati u C-u, ne želim.
Sukladno tome, održava vezu sa svakim poslužiteljem i može pisati u memoriju. Na primjer, ako zapisnike grešaka pišemo u Clickhouse, onda ako Clickhouse nema vremena za umetanje podataka (uostalom, ako je previše zapisano), tada ne nabubrimo memoriju - jednostavno izbacimo ostatak. Jer ako zapišemo nekoliko gigabita u sekundi pogrešaka, tada vjerojatno možemo neke izbaciti. Kittenhouse to može. Osim toga, može izvršiti pouzdanu isporuku, to jest zapisivanje na disk na lokalnom računalu i jednom svaki put (tamo, jednom svakih nekoliko sekundi) pokušava isporučiti podatke iz ove datoteke. I u početku smo koristili uobičajeni format vrijednosti - ne neki binarni format, tekstualni format (kao u običnom SQL-u).
Ali onda se dogodilo ovo. Koristili smo pouzdanu isporuku, pisali zapisnike, a zatim odlučili (bio je to uvjetni testni klaster)... Ugašen je nekoliko sati i ponovno vraćen, a umetanje je počelo s tisuću poslužitelja - pokazalo se da Clickhouse još uvijek ima „Nit na vezi” - prema tome, u tisuću veza, aktivno umetanje dovodi do prosječnog opterećenja na poslužitelju od oko tisuću i pol. Iznenađujuće, poslužitelj je prihvatio zahtjeve, ali su podaci ipak umetnuti nakon nekog vremena; ali serveru je bilo jako teško to poslužiti...
Dodaj nginx
Takvo rješenje za Thread per connection model je nginx. Instalirali smo nginx ispred Clickhousea, istovremeno postavili balansiranje za dvije replike (brzina umetanja nam se povećala 2 puta, iako nije činjenica da bi to trebao biti slučaj) i ograničili broj veza na Clickhouse, na uzvodno i, prema tome, više , nego u 50 veza, čini se da nema smisla umetati.
Tada smo shvatili da ova shema općenito ima nedostataka, jer ovdje imamo samo jedan nginx. Prema tome, ako se ovaj nginx sruši, unatoč prisutnosti replika, gubimo podatke ili, barem, ne pišemo nigdje. Zbog toga smo napravili vlastiti balans opterećenja. Također smo shvatili da je "Clickhouse" još uvijek prikladan za zapise, a "demon" je također počeo pisati svoje zapise u "Clickhouse" - vrlo zgodno, da budem iskren. Još uvijek ga koristimo za druge "demone".
Zatim smo otkrili ovaj zanimljiv problem: ako koristite nestandardnu metodu umetanja u SQL modu, ona forsira potpuni SQL parser temeljen na AST-u, koji je prilično spor. U skladu s tim, dodali smo postavke kako bismo osigurali da se to nikada ne dogodi. Napravili smo load balancing, zdravstvene provjere, tako da ako netko umre, svejedno ostavljamo podatke. Sada imamo dosta tablica koje su nam potrebne za različite Clickhouse klastere. Također smo počeli razmišljati o drugim upotrebama - na primjer, htjeli smo pisati zapise iz nginx modula, ali oni ne znaju kako komunicirati pomoću našeg RPC-a. Eto, volio bih ih naučiti kako da barem nekako šalju - npr. primaju događaje na localhost preko UDP-a i onda ih prosljeđuju Clickhouseu.
Na korak od rješenja
Konačna shema je počela izgledati ovako (četvrta verzija ove sheme): na svakom serveru ispred Clickhousea nalazi se nginx (na istom serveru) i jednostavno prosljeđuje zahtjeve lokalnom hostu uz ograničenje broja konekcija od 50 komada. I ova shema je već prilično funkcionirala, sve je bilo prilično dobro s njom.
Tako smo živjeli oko mjesec dana. Svi su bili zadovoljni, dodavali su tablice, dodavali su, dodavali... Općenito, pokazalo se da način na koji smo dodavali međuspremnike nije baš optimalan (recimo to tako). Radili smo 16 komada u svakoj tablici i flash interval od nekoliko sekundi; imali smo 20 stolova i svaki je stol primio 8 umetaka u sekundi - i u ovom trenutku je počeo "Clickhouse"... zapisi su počeli usporavati. Ne samo da nisu prošli... Po defaultu, nginx je imao tako zanimljivu stvar da ako su veze završile na upstreamu, onda je jednostavno vraćao “502” na sve nove zahtjeve.
I ovdje imamo (upravo sam pogledao zapisnike u samom Clickhouseu) oko pola posto zahtjeva nije uspjelo. Sukladno tome, iskorištenost diska bila je visoka, bilo je puno spajanja. Pa, što sam učinio? Naravno, nisam se trudio dokučiti zašto je točno veza i uzvodno završila.
Zamjena nginxa obrnutim proxyjem
Odlučio sam da ovo trebamo sami riješiti, ne trebamo to prepustiti nginxu - nginx ne zna koje tablice postoje u Clickhouseu i zamijenio sam nginx obrnutim proxyjem, koji sam također sam napisao.
Što on radi? Radi na temelju fasthttp biblioteke “goshnoy”, odnosno brzo, gotovo jednako brzo kao nginx. Oprosti, Igore, ako si prisutan ovdje (napomena: Igor Sysoev je ruski programer koji je stvorio web poslužitelj nginx). Može razumjeti kakvi su to upiti – INSERT ili SELECT – prema tome, sadrži različita skupa veza za različite vrste upita.
U skladu s tim, čak i ako nemamo vremena ispuniti zahtjeve za umetanje, "odabiri" će proći, i obrnuto. I grupira podatke u tablice međuspremnika - s malim međuspremnikom: ako je bilo grešaka, grešaka u sintaksi i tako dalje - tako da ne bi uvelike utjecali na ostatak podataka, jer kada jednostavno umetnemo u tablice međuspremnika, imao mali "bachi", a sve sintaktičke pogreške utjecale su samo na ovaj mali komad; a ovdje će već utjecati na veliki međuspremnik. Mali je 1 megabajt, odnosno nije tako mali.
Umetanje sinkronizacije i u biti zamjena nginxa čini u biti istu stvar koju je nginx radio prije - za ovo ne morate mijenjati lokalnu "Kittenhouse". A budući da koristi fasthttp, vrlo je brz - možete napraviti više od 100 tisuća zahtjeva u sekundi za pojedinačne umetke putem obrnutog proxyja. Teoretski, možete umetnuti red po red u obrnuti proxy kittenhouse, ali mi to, naravno, ne radimo.
Shema je počela izgledati ovako: "Kittenhouse", obrnuti proxy grupira mnoge zahtjeve u tablice, a zauzvrat ih međuspremničke tablice umeću u one glavne.
Killer je privremeno rješenje, Kitten je trajno
Ovo je zanimljiv problem... Je li netko od vas koristio fasthttp? Tko je koristio fasthttp s POST zahtjevima? Vjerojatno, ovo stvarno nije trebalo biti učinjeno, jer ono sprema tijelo zahtjeva prema zadanim postavkama, a naša veličina međuspremnika postavljena je na 16 megabajta. Umetanje je u nekom trenutku prestalo pratiti i komadi od 16 megabajta počeli su pristizati sa svih desetaka tisuća poslužitelja i svi su bili spremljeni u međuspremnik u memoriju prije slanja u Clickhouse. Sukladno tome, ponestalo je memorije, došao je Out-Of-Memory Killer i ubio obrnuti proxy (ili "Clickhouse", koji bi teoretski mogao "pojesti" više od obrnutog proxyja). Ciklus se ponovio. Nije baš ugodan problem. Iako smo na ovo naletjeli tek nakon nekoliko mjeseci rada.
Što sam učinio? Opet, ne volim razumjeti što se točno dogodilo. Mislim da je prilično očito da ne biste trebali spremati u memoriju. Nisam mogao zakrpati fasthttp, iako sam pokušao. Ali pronašao sam način da to učinim tako da nema potrebe za krpanjem i smislio sam svoju metodu u HTTP-u - nazvao sam je KITTEN. Pa, logično je - "VK", "Mačić" ... Što još?..
Ako zahtjev dođe na poslužitelj metodom Kitten, tada bi poslužitelj trebao odgovoriti "mijau" - logično. Ako on na to odgovori, onda se smatra da razumije ovaj protokol, a onda ja presrećem vezu (fasthttp ima takvu metodu), i veza prelazi u “raw” mod. Zašto mi to treba? Želim kontrolirati kako se odvija čitanje iz TCP veza. TCP ima divno svojstvo: ako nitko ne čita s druge strane, tada upisivanje počinje čekati, a memorija se na to posebno ne troši.
I tako ja čitam od 50-ak klijenata odjednom (od pedesetak jer pedeset bi svakako trebalo biti dovoljno, čak i ako je stopa iz drugog DC-a)... Potrošnja se ovim pristupom smanjila barem 20 puta, ali ja, da budem iskrena , nisam mogao točno izmjeriti koliko sati, jer je to već besmisleno (već je došlo do razine greške). Protokol je binarni, odnosno sadrži naziv tablice i podatke; nema http zaglavlja, tako da nisam koristio web socket (ne moram komunicirati s preglednicima - napravio sam protokol koji odgovara našim potrebama). I sve je s njim postalo u redu.
Tampon stol je tužan
Nedavno smo naišli na još jednu zanimljivu značajku međuspremnika. A ovaj problem je već mnogo bolniji od ostalih. Zamislimo ovu situaciju: već aktivno koristite Clickhouse, imate desetke Clickhouse poslužitelja i imate neke zahtjeve za čije čitanje treba jako dugo (recimo, više od 60 sekundi); a vi dođete i učinite Alter u ovom trenutku... U međuvremenu, “odabiri” koji su počeli prije “Alter” neće biti uključeni u ovu tablicu, “Alter” se neće pokrenuti - vjerojatno neke značajke kako “Clickhouse” radi u ovo mjesto. Možda se to može popraviti? Ili je nemoguće?
Općenito, jasno je da u stvarnosti to nije tako velik problem, ali s međuspremničkim tablicama postaje bolnije. Jer, ako, recimo, vaš “Alter” istekne (a može isteći na drugom hostu - ne na vašem, nego na replici, na primjer), onda... Izbrisali ste međuspremnik tablicu, vaš “Alter” ( ili neki drugi host) isteklo vrijeme. tada se pojavila pogreška "Alter") - i dalje morate osigurati da se podaci nastavljaju pisati: kreirate međuspremnike tablice natrag (prema istoj shemi kao nadređena tablica), zatim “Alter” prolazi, nakon svega završava, a međuspremnik tablice počinje se razlikovati u shemi od roditelja. Ovisno o tome što je bio "Alter", umetak možda više neće ići u ovu međuspremničku tablicu - to je vrlo tužno.
Postoji i takav znak (možda ga je netko primijetio) - zove se query_thread_log u novim verzijama Clickhousea. Prema zadanim postavkama, u nekim verzijama postojao je jedan. Ovdje smo skupili 840 milijuna zapisa u par mjeseci (100 gigabajta). To je zbog činjenice da su tamo napisani "umetci" (možda sada, usput, nisu napisani). Kao što sam vam rekao, naši "umetci" su mali - imali smo puno "umetaka" u međuspremnike. Jasno je da je ovo onemogućeno - samo vam govorim što sam vidio na našem serveru. Zašto? Ovo je još jedan argument protiv korištenja međuspremnika! Spotty je jako tužan.
Tko je znao da se taj tip zove Spotty? Djelatnici VK digli su ruke. U REDU.
O planovima za “KitttenHouse”
Planovi se obično ne dijele, zar ne? Odjednom ih nećete ispunjavati i nećete izgledati baš dobro u očima drugih ljudi. Ali riskirat ću! Želimo napraviti sljedeće: buffer tablice, čini mi se, još uvijek su štaka i moramo sami bufferirati umetanje. Ali još uvijek ga ne želimo spremiti u međuspremnik na disku, pa ćemo umetnuti u međuspremnik u memoriju.
U skladu s tim, kada se napravi "umetak", on više neće biti sinkroni - već će raditi kao međuspremnik tablice, umetnut će se u nadređenu tablicu (dobro, jednog dana kasnije) i izvijestiti putem zasebnog kanala koji su umetci prošli, a koji nisam.
Zašto ne mogu napustiti sinkroni umetak? Mnogo je praktičnije. Činjenica je da ako ubacite od 10 tisuća hostova, onda je sve u redu - dobit ćete pomalo od svakog hosta, tamo ubacite jednom u sekundi, sve je u redu. Ali volio bih da ova shema radi, na primjer, s dva stroja, tako da možete preuzimati velikom brzinom - možda ne izvući maksimum iz Clickhousea, ali pisati najmanje 100 megabajta u sekundi s jednog stroja preko obrnutog proxyja - ovo shema mora skalirati i na velike i na male količine, tako da ne možemo čekati ni sekunde za svako umetanje, tako da mora biti asinkrona. Na isti način, asinkrone potvrde trebale bi doći nakon što je umetanje dovršeno. Znat ćemo je li prošlo ili nije.
Najvažnije je da u ovoj shemi sa sigurnošću znamo je li do umetanja došlo ili nije. Zamislite ovu situaciju: imate tablicu međuspremnika, napisali ste nešto u nju, a onda je, recimo, tablica otišla u način rada samo za čitanje i pokušala isprati međuspremnik. Gdje će podaci ići? Oni će ostati u međuspremniku. Ali u ovo ne možemo biti sigurni - što ako postoji neka druga greška, zbog koje podaci neće ostati u međuspremniku... (Adrese Alexey Milovidov, Yandex, ClickHouse developer) Ili će ostati? Stalno? Aleksej nas uvjerava da će sve biti u redu. Nemamo razloga ne vjerovati mu. Ali svejedno: ako ne koristimo međuspremnike, onda s njima neće biti problema. Stvaranje dvostruko više tablica također je nezgodno, iako u principu nema velikih problema. Ovo je plan.
Razgovarajmo o čitanju
Sada razgovarajmo o čitanju. Ovdje smo također napisali vlastiti alat. Čini se, dobro, zašto ovdje pisati svoj instrument?.. A tko je koristio Tabix? Nekako je malo tko digao ruke... A tko je zadovoljan učinkom Tabixa? Pa, nismo zadovoljni njime, a i nije baš zgodno za pregled podataka. Za analitiku je u redu, ali samo za gledanje očito nije optimiziran. Pa sam napisao svoje vlastito sučelje.
Vrlo je jednostavan - može samo čitati podatke. Ne zna prikazati grafiku, ne zna ništa napraviti. Ali može pokazati što nam treba: na primjer, koliko redaka ima tablica, koliko prostora zauzima (bez rastavljanja na stupce), odnosno vrlo jednostavno sučelje je ono što nam treba.
I izgleda vrlo slično Sequel Pro-u, ali samo napravljeno na Twitterovom Bootstrapu i drugoj verziji. Pitate: "Juri, zašto na drugoj verziji?" Koje godine? 2018.? Općenito, ovo sam napravio dosta davno za “Muscle” (MySQL) i samo sam promijenio par redaka u upitima tamo, i počelo je raditi za “Clickhouse”, na čemu posebna hvala! Budući da je parser vrlo sličan "muscle" onom, a upiti su vrlo slični - vrlo zgodno, pogotovo na početku.
Pa, može filtrirati tablice, može prikazati strukturu i sadržaj tablice, omogućuje vam sortiranje, filtriranje po stupcima, prikazuje upit koji je rezultirao rezultatom, zahvaćene retke (koliko kao rezultat), to jest, osnovne stvari za pregled podataka. Prilično brzo.
Tu je i urednik. Iskreno sam pokušao ukrasti cijeli editor Tabixu, ali nisam uspio. Ali nekako funkcionira. U principu, to je sve.
"Clickhouse" je pogodan za jazbine
Želim vam reći da je Clickhouse, unatoč svim opisanim problemima, vrlo pogodan za trupce. Što je najvažnije, rješava naš problem - vrlo je brz i omogućuje vam filtriranje zapisa po stupcima. U principu, međuspremničke tablice nisu se dobro pokazale, ali obično nitko ne zna zašto... Možda sada bolje znate gdje ćete imati problema.
TCP? Općenito, u VK je uobičajeno koristiti UDP. A kad sam koristio TCP... Naravno, nitko mi nije rekao: “Juri, o čemu ti pričaš! Ne možete, treba vam UDP." Pokazalo se da TCP nije tako strašan. Jedino, ako imate desetke tisuća aktivnih spojeva koje pišete, morate ih pripremiti malo pažljivije; ali moguće je, i to prilično lako.
Obećao sam objaviti “Kittenhouse” i “Lighthouse” na HighLoad Siberia ako se svi pretplate na naš javni “VK backend”... I znate, nisu se svi pretplatili... Naravno, neću zahtijevati da se pretplatite na naš javnost. Još uvijek vas ima previše, možda se netko i uvrijedi, ali ipak, pretplatite se (i ovdje moram napraviti oči kao u mačke). To je . Hvala vam puno! Github je naš . Uz Clickhouse vaša će kosa biti mekana i svilenkasta.
Moderator: - Prijatelji, sada pitanja. Odmah nakon što predamo zahvalnicu i vaše izvješće na VHS-u.
Jurij Nasretdinov (dalje u tekstu YN): – Kako ste mogli snimiti moju reportažu na VHS ako je upravo završila?
Moderator: – Ni vi ne možete u potpunosti odrediti kako će “Clickhouse” raditi ili ne! Prijatelji, 5 minuta za pitanja!
pitanja
Pitanje iz publike (u daljnjem tekstu Q): - Dobar dan. Hvala vam puno na izvješću. Imam dva pitanja. Počet ću s nečim neozbiljnim: utječe li broj slova t u nazivu "Kittenhouse" na dijagramima (3, 4, 7...) na zadovoljstvo mačaka?
YN: - Količina čega?
Z: – Slovo t. Ima tri t, negdje oko tri t.
YN: - Nisam li to popravio? Pa, naravno da ima! To su različiti proizvodi - sve ovo vrijeme sam vas samo obmanjivao. Dobro, šalim se - nema veze. Ah, upravo ovdje! Ne, to je ista stvar, pogriješio sam.
Z: - Hvala vam. Drugo pitanje je ozbiljno. Koliko ja razumijem, u Clickhouseu, tablice međuspremnika žive isključivo u memoriji, nisu spremne na disk i, prema tome, nisu trajne.
YN: - Da.
Z: – I u isto vrijeme, vaš klijent sprema međuspremnik na disk, što implicira određeno jamstvo isporuke tih istih zapisa. Ali to nipošto nije zajamčeno u Clickhouseu. Objasnite kako se jamstvo provodi, zbog čega?.. Evo ovog mehanizma pobliže
YN: – Da, teoretski tu nema proturječja, jer kada Clickhouse padne, zapravo to možete otkriti na milijun različitih načina. Ako se Clickhouse sruši (ako krivo završi), možete, grubo rečeno, malo premotati svoj log koji ste zapisali i krenuti od trenutka kada je sve bilo u redu. Recimo, premotate minutu unazad, odnosno smatra se da ste sve ispraznili u minuti.
Z: – Odnosno, “Kittenhouse” duže drži prozor i u slučaju pada može ga prepoznati i premotati?
YN: – Ali to je u teoriji. U praksi to ne radimo, a pouzdana isporuka je od nula do beskonačno vremena. Ali u prosjeku jedan. Zadovoljni smo činjenicom da gubimo malo ako se Clickhouse iz nekog razloga sruši ili se poslužitelji "ponovno pokrenu". U svim drugim slučajevima ništa se neće dogoditi.
Z: - Zdravo. Od samog početka mi se činilo da ćete doista koristiti UDP od samog početka izvješća. Imaš http, sve to... I većinu problema koje si opisao, koliko sam shvatio, uzrokovalo je ovo konkretno rješenje...
YN: – Što koristimo TCP?
Z: - Suštinski da.
YN: - Ne.
Z: – Imao si problema s fasthttpom, s vezom si imao problema. Da ste upravo koristili UDP, uštedjeli biste si nešto vremena. Pa bilo bi problema s dugim porukama ili nečim trećim...
YN: - S čim?
Z: – S dugim porukama, jer možda ne stane u MTU, nešto drugo... Pa može biti svojih problema. Pitanje je: zašto ne UDP?
YN: – Vjerujem da su autori koji su razvili TCP/IP puno pametniji od mene i znaju bolje od mene kako serijalizirati pakete (tako da idu), ujedno podesiti prozor slanja, ne opteretiti mrežu, dati povratnu informaciju o tome što se ne čita, ne računajući s druge strane... Svi ovi problemi bi, po mom mišljenju, postojali u UDP-u, samo što bih ja morao napisati još više koda nego što sam već napisao da sam implementiram istu stvar i najvjerojatnije slabo. Ja baš i ne volim pisati u C-u, a kamoli tamo...
Z: - Baš zgodno! Poslano u redu i ne čekajte ništa - potpuno je asinkrono. Vratila se obavijest da je sve u redu - znači stigla je; Ako ne dolazi, znači da je loše.
YN: – Trebam oboje – moram moći poslati i s garancijom isporuke i bez garancije isporuke. To su dva različita scenarija. Ne moram izgubiti neke zapise ili ih ne smijem izgubiti u razumnom roku.
Z: — Neću gubiti vrijeme. O tome treba više razgovarati. Hvala vam.
Moderator: – Tko ima pitanja – ruke u nebo!
Z: - Zdravo, ja sam Sasha. Negdje na sredini izvještaja pojavio se osjećaj da je uz TCP moguće koristiti već gotovo rješenje – neku vrstu Kafke.
YN: – Pa... rekao sam ti da ne želim koristiti međuposlužitelje, jer... u Kafki ispada da imamo deset tisuća hostova; zapravo, imamo više - desetke tisuća hostova. Također može biti bolno raditi s Kafkom bez ikakvih zastupnika. Osim toga, što je najvažnije, još uvijek daje "latenciju", daje dodatne hostove koje morate imati. Ali ja ih ne želim imati - želim...
Z: “Ali na kraju je ipak tako ispalo.”
YN: – Ne, nema domaćina! Sve ovo radi na Clickhouse hostovima.
Z: - Pa, i "Kittenhouse", što je obrnuto - gdje on živi?
YN: – Na Clickhouse hostu ne zapisuje ništa na disk.
Z: - Pretpostavimo.
Moderator: - Jesi li zadovoljan? Možemo li vam dati plaću?
Z: - Da, možete. Zapravo, ima puno štaka da bi se dobila ista stvar, a sada - prethodni odgovor na temu TCP-a proturječi, po mom mišljenju, ovoj situaciji. Čini mi se kao da je sve moglo biti učinjeno na koljenima u puno kraćem vremenu.
YN: – I zašto nisam htio koristiti Kafku, jer je bilo dosta pritužbi u Clickhouse Telegram chatu da su se, primjerice, poruke od Kafke gubile. Ne od samog Kafke, nego u integraciji Kafke i Clickhausa; ili tu nešto nije spojilo. Grubo rečeno, tada bi bilo potrebno napisati klijenta za Kafku. Mislim da ne postoji jednostavnije ili pouzdanije rješenje.
Z: – Recite mi, zašto niste pokušali s redovima ili nekim uobičajenim autobusom? Budući da kažete da biste uz asinkroniju mogli slati same zapisnike kroz red i primati odgovor asinkrono kroz red?
YN: – Predložite koji bi se redovi mogli koristiti?
Z: – Bilo koje, čak i bez garancije da su ispravni. Nekakav Redis, RMQ...
YN: – Imam osjećaj da Redis najvjerojatnije neće moći potegnuti toliki volumen umetanja niti na jednom hostu (u smislu više servera) koji izvlači Clickhouse. Ne mogu to potkrijepiti nikakvim dokazima (nisam to mjerio), ali čini mi se da Redis ovdje nije najbolje rješenje. U principu, ovaj sustav se može smatrati improviziranim redom poruka, ali koji je prilagođen samo za “Clickhouse”
Moderator: – Jurij, hvala ti puno. Predlažem da ovdje završimo s pitanjima i odgovorima i kažemo kome ćemo od onih koji su postavili pitanje pokloniti knjigu.
YN: – Prvom tko postavi pitanje poklonio bih knjigu.
Moderator: - Divno! Sjajno! Nevjerojatan! Hvala puno!
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com