HighLoad++ Moskova 2018, kongressitalo. 9. marraskuuta klo 15
Tiivistelmät ja esittely:
Juri Nasretdinov (VKontakte): raportti kertoo ClickHousen käyttöönoton kokemuksista yrityksessämme - miksi tarvitsemme sitä, kuinka paljon dataa tallennamme, miten kirjoitamme ja niin edelleen.
Lisämateriaalit:
Juri Nasretdinov: - Hei kaikki! Nimeni on Juri Nasretdinov, koska minut on jo esitelty. Työskentelen VKontaktessa. Puhun siitä, kuinka lisäämme tietoja ClickHouseen palvelinkannastamme (kymmeniä tuhansia).
Mitä ovat lokit ja miksi niitä kerätään?
Mitä me kerromme sinulle: mitä teimme, miksi tarvitsimme "ClickHousen", miksi valitsimme sen, millaisen suorituskyvyn voit suunnilleen saada ilman mitään erityistä konfigurointia. Kerron sinulle lisää puskuritaulukoista, ongelmista, joita meillä oli niiden kanssa, ja ratkaisuistamme, jotka olemme kehittäneet avoimesta lähdekoodista - KittenHouse ja Lighthouse.
Miksi meidän piti tehdä mitään (VKontaktessa kaikki on aina hyvin, eikö?). Halusimme kerätä virheenkorjauslokeja (ja siellä oli satoja teratavuja dataa), ehkä jotenkin olisi mukavampaa laskea tilastoja; ja meillä on kymmenien tuhansien palvelimien laivasto, jolta kaikki tämä on tehtävä.
Miksi päätimme? Meillä oli luultavasti ratkaisuja tukkien säilyttämiseen. Täällä on sellainen julkinen "Backend VK". Suosittelen lämpimästi sen tilaamista.
Mitä ovat lokit? Tämä on moottori, joka palauttaa tyhjiä taulukoita. VK:n moottoreita muut kutsuvat mikropalveluiksi. Ja tässä hymyilevä tarra (melko paljon tykkäyksiä). Kuinka niin? No, kuuntele lisää!
Mitä voidaan käyttää lokien tallentamiseen? On mahdotonta olla mainitsematta Hadupia. Sitten esimerkiksi Rsyslog (näiden lokien tallentaminen tiedostoihin). LSD. Kuka tietää mitä LSD on? Ei, ei tämä LSD. Tallenna myös tiedostoja. No, ClickHouse on outo vaihtoehto.
Clickhouse ja kilpailijat: vaatimukset ja mahdollisuudet
Mitä me haluamme? Haluamme varmistaa, että meidän ei tarvitse huolehtia liikaa toiminnasta, jotta se toimii heti valmiina, mieluiten minimaalisella kokoonpanolla. Haluamme kirjoittaa paljon ja kirjoittaa nopeasti. Ja haluamme säilyttää sen kaikenlaisia kuukausia, vuosia, eli pitkään. Haluamme ehkä ymmärtää jonkin ongelman, jonka kanssa he tulivat luoksemme ja sanoivat: "Jotain ei toimi täällä", ja se oli 3 kuukautta sitten), ja haluamme nähdä, mitä tapahtui 3 kuukautta sitten." Tietojen pakkaus – on selvää, miksi se olisi plussaa – koska se vähentää viemäänsä tilaa.
Ja meillä on niin mielenkiintoinen vaatimus: kirjoitamme joskus joidenkin komentojen (esimerkiksi lokien) tulosteen, se voi olla melko helposti yli 4 kilotavua. Ja jos tämä asia toimii UDP:n yli, sen ei tarvitse kuluttaa... sillä ei ole "yhteyttä" yhteydelle, ja suurelle määrälle palvelimia tämä on plussaa.
Katsotaan mitä avoin lähdekoodi tarjoaa meille. Ensinnäkin meillä on Logs Engine - tämä on moottorimme; Periaatteessa hän osaa tehdä kaiken, jopa kirjoittaa pitkiä rivejä. No, se ei pakkaa tietoja läpinäkyvästi - voimme pakata suuria sarakkeita itse, jos haluamme... emme tietenkään halua (jos mahdollista). Ainoa ongelma on, että hän voi antaa pois vain sen, mikä sopii hänen muistiinsa; Jotta voit lukea loput, sinun on hankittava tämän moottorin binlog, ja vastaavasti se kestää melko kauan.
Mitä muita vaihtoehtoja on? Esimerkiksi "Hadup". Helppokäyttöisyys... Kuka uskoo, että Hadup on helppo asentaa? Nauhoituksen kanssa ei tietenkään ole ongelmia. Lukeessa herää joskus kysymyksiä. Periaatteessa sanoisin, että luultavasti ei, varsinkin hirsien osalta. Pitkäaikainen tallennus - tietysti, kyllä, tietojen pakkaus - kyllä, pitkät merkkijonot - on selvää, että voit tallentaa. Mutta tallennus suurelta määrältä palvelimia... Jotain on silti tehtävä itse!
Rsyslog. Itse asiassa käytimme sitä varavaihtoehtona, jotta voisimme lukea sen ilman binlogia, mutta se ei voi kirjoittaa pitkiä rivejä, periaatteessa se ei voi kirjoittaa enempää kuin 4 kilotavua. Tietojen pakkaus on tehtävä samalla tavalla itse. Lukeminen tulee tiedostoista.
Sitten on LSD:n "badushka" kehitys. Pohjimmiltaan sama kuin “Rsyslog”: se tukee pitkiä merkkijonoja, mutta ei voi toimia UDP:n kautta, ja itse asiassa tämän takia sinne on valitettavasti kirjoitettava aika paljon asioita uudelleen. LSD on suunniteltava uudelleen, jotta se pystyy tallentamaan kymmeniltä tuhansilta palvelimilta.
Ja täällä! Hauska vaihtoehto on ElasticSearch. Miten sanoa? Hän pärjää hyvin lukemisessa, eli hän lukee nopeasti, mutta ei kovin hyvin kirjoittamisessa. Ensinnäkin, jos se pakkaa tietoja, se on erittäin heikko. Todennäköisesti täydellinen haku vaatii suurempia tietorakenteita kuin alkuperäinen määrä. Sen käyttö on vaikeaa ja siihen liittyy usein ongelmia. Ja taas Elasticilla äänitys – meidän on tehtävä kaikki itse.
Tässä ClickHouse on tietysti ihanteellinen vaihtoehto. Ainoa asia on, että tallentaminen kymmeniltä tuhansilta palvelimilta on ongelma. Mutta ainakin yksi ongelma on, voimme yrittää ratkaista sen jotenkin. Ja loput raportista käsittelevät tätä ongelmaa. Millaista suorituskykyä voit odottaa ClickHouselta?
Kuinka aiomme lisätä sen? MergeTree
Kuka teistä ei olisi kuullut tai tiedä "ClickHousesta"? Minun täytyy kertoa sinulle, eikö? Erittäin nopea. Lisäys sinne - 1-2 gigabittiä sekunnissa, purskeet jopa 10 gigabittiä sekunnissa voi todella kestää tämän kokoonpanon - siellä on kaksi 6-ytimistä Xeonia (eli ei edes tehokkain), 256 gigatavua RAM-muistia, 20 teratavua RAIDissa (ketään ei ole määritetty, oletusasetukset). Alexey Milovidov, ClickHouse-kehittäjä, istuu luultavasti siellä itkien, koska emme konfiguroineet mitään (meillä kaikki toimi niin). Vastaavasti voidaan saada esimerkiksi noin 6 miljardia riviä sekunnissa skannausnopeus, jos data on hyvin pakattu. Jos pidät % tekstistä - 100 miljoonaa riviä sekunnissa, eli se näyttää melko nopealta.
Kuinka aiomme lisätä sen? Tiedäthän, että VK käyttää PHP:tä. Lisäämme jokaiselta PHP-työntekijältä HTTP:n kautta "ClickHouseen" kunkin tietueen MergeTree-taulukkoon. Kuka näkee ongelman tässä järjestelmässä? Jostain syystä kaikki eivät nostaneet käsiään. Haluan kertoa teille.
Ensinnäkin palvelimia on paljon - vastaavasti yhteyksiä on paljon (huonoja). Silloin on parempi lisätä tietoja MergeTreeen enintään kerran sekunnissa. Ja kuka tietää miksi? Selvä. Kerron tästä hieman lisää. Toinen mielenkiintoinen kysymys on, että emme tee analytiikkaa, meidän ei tarvitse rikastaa tietoja, emme tarvitse välipalvelimia, haluamme lisätä suoraan "ClickHouseen" (mieluiten - mitä suoremmin, sen parempi).
Näin ollen, kuinka lisäys tehdään MergeTreessä? Miksi on parempi lisätä siihen enintään kerran sekunnissa tai harvemmin? Tosiasia on, että "ClickHouse" on saraketietokanta ja lajittelee tiedot ensisijaisen avaimen nousevaan järjestykseen, ja kun teet lisäyksen, tiedostoja luodaan vähintään yhtä monta kuin sarakkeita, joissa tiedot lajitellaan. ensisijaisen avaimen nousevassa järjestyksessä (luodaan erillinen hakemisto, joukko tiedostoja levyllä jokaista lisäystä varten). Sitten tulee seuraava lisäys, ja taustalla ne yhdistetään suurempiin "osioihin". Koska tiedot on lajiteltu, on mahdollista "yhdistää" kaksi lajiteltua tiedostoa kuluttamatta paljon muistia.
Mutta kuten arvata saattaa, jos kirjoitat 10 tiedostoa jokaiselle lisäyksellä, ClickHouse (tai palvelimesi) loppuu nopeasti, joten on suositeltavaa lisätä suuria eriä. Näin ollen emme koskaan käynnistäneet ensimmäistä järjestelmää tuotantoon. Julkaisimme heti sellaisen, joka tässä nro 2 sisältää:
Kuvittele tässä, että meillä on noin tuhat palvelinta, joilla olemme käynnistäneet, on vain PHP. Ja jokaisella palvelimella on paikallinen agenttimme, jota kutsuimme "Kittenhouseksi", joka ylläpitää yhtä yhteyttä "ClickHousen" kanssa ja lisää tietoja muutaman sekunnin välein. Ei lisää tietoja MergeTreeen, vaan puskuritaulukkoon, joka toimii juuri sen välttämiseksi, että lisääminen suoraan MergeTreeen heti.
Työskentely puskuritaulukoiden kanssa
Mikä se on? Puskuritaulukot ovat muistinpala, joka on sirpaloitu (eli se voidaan lisätä siihen usein). Ne koostuvat useista kappaleista ja jokainen pala toimii itsenäisenä puskurina, ja ne huuhdellaan itsenäisesti (jos puskurissa on monta kappaletta, niin lisäyksiä tulee paljon sekunnissa). Näistä taulukoista on mahdollista lukea - silloin luet puskurin ja päätaulukon sisällön liitoksen, mutta tällä hetkellä kirjoitus on estetty, joten on parempi olla lukematta sieltä. Ja puskuritaulukot osoittavat erittäin hyvän QPS: n, eli 3 tuhatta QPS: ään asti, sinulla ei ole mitään ongelmia asettamisen yhteydessä. On selvää, että jos palvelimen virta katkeaa, tiedot voivat kadota, koska ne tallennettiin vain muistiin.
Samaan aikaan puskurilla varustettu kaavio monimutkaistaa ALTERia, koska sinun on ensin pudotettava vanha puskuritaulukko vanhan kaavan kanssa (tiedot eivät katoa mihinkään, koska ne huuhdellaan ennen taulukon poistamista). Sitten "muutat" tarvitsemaasi taulukkoa ja luot puskuritaulukon uudelleen. Näin ollen, vaikka puskuritaulukkoa ei ole, tietosi eivät kulje minnekään, mutta voit säilyttää ne levyllä ainakin paikallisesti.
Mikä on Kittenhouse ja miten se toimii?
Mikä on KittenHouse? Tämä on välityspalvelin. Arvaa mitä kieltä? Keräsin raporttiini eniten hype-aiheita - "Clickhouse", Mene, ehkä muistan jotain muuta. Kyllä, tämä on kirjoitettu Go-kielellä, koska en todellakaan osaa kirjoittaa C-kielellä, enkä haluakaan.
Näin ollen se ylläpitää yhteyttä jokaisen palvelimen kanssa ja voi kirjoittaa muistiin. Jos esimerkiksi kirjoitamme virhelokeja Clickhouseen, niin jos Clickhousella ei ole aikaa lisätä tietoja (jos kirjoitetaan liikaa), emme turvota muistia - heitämme loput pois. Koska jos kirjoitamme useita gigabittejä sekunnissa virheitä, voimme luultavasti heittää niistä pois. Kittenhouse voi tehdä tämän. Lisäksi se voi suorittaa luotettavan toimituksen, toisin sanoen kirjoittaa levylle paikallisella koneella ja kerran joka kerta (siellä kerran parin sekunnin välein) se yrittää toimittaa tietoja tästä tiedostosta. Ja aluksi käytimme tavallista Arvot-muotoa - ei jotain binaarimuotoa, tekstimuotoa (kuten tavallisessa SQL:ssä).
Mutta sitten tämä tapahtui. Käytimme luotettavaa toimitusta, kirjoitimme lokeja, sitten päätimme (se oli ehdollinen testiklusteri)... Sitä otettiin ulos useiksi tunteiksi ja otettiin takaisin, ja lisäys alkoi tuhannesta palvelimesta - kävi ilmi, että Clickhousella oli vielä "Käie yhteydessä" - vastaavasti tuhannessa yhteydessä aktiivinen lisäys johtaa palvelimen kuormituksen keskiarvoon noin puolitoista tuhatta. Yllättäen palvelin hyväksyi pyynnöt, mutta tiedot lisättiin silti jonkin ajan kuluttua; mutta palvelimen oli erittäin vaikea palvella sitä...
Lisää nginx
Tällainen ratkaisu Thread per connection -mallille on nginx. Asensimme nginxin Clickhousen eteen, samalla asetimme tasapainotuksen kahdelle replikalle (lisäysnopeus kasvoi 2 kertaa, vaikka ei ole tosiasia, että näin pitäisi olla) ja rajoitimme Clickhousen yhteyksien määrää ylävirtaan ja vastaavasti enemmän , kuin 50 yhteydessä, ei näytä olevan mitään järkeä lisätä.
Sitten tajusimme, että tällä järjestelmällä on yleensä haittoja, koska meillä on täällä vain yksi nginx. Näin ollen, jos tämä nginx kaatuu, replikoiden läsnäolosta huolimatta, menetämme tietoja tai emme ainakaan kirjoita mihinkään. Siksi teimme oman kuormituksen tasauksen. Ymmärsimme myös, että "Clickhouse" sopii edelleen tukille, ja "demoni" alkoi myös kirjoittaa lokejaan "Clickhouseen" - erittäin kätevää, ollakseni rehellinen. Käytämme sitä edelleen muille "demoneille".
Sitten havaitsimme tämän mielenkiintoisen ongelman: jos käytät epätyypillistä lisäysmenetelmää SQL-tilassa, se pakottaa täysimittaisen AST-pohjaisen SQL-jäsentimen, joka on melko hidas. Siksi olemme lisänneet asetuksia varmistaaksemme, että näin ei koskaan tapahdu. Teimme kuormituksen tasauksen, terveystarkastukset, niin että jos joku kuolee, jätämme tiedot silti. Meillä on nyt melko paljon pöytiä, joita tarvitsemme eri Clickhouse-klustereiksi. Aloimme myös miettiä muita käyttötapoja - esimerkiksi halusimme kirjoittaa lokeja nginx-moduuleista, mutta he eivät osaa kommunikoida RPC:n avulla. No, haluaisin opettaa heille lähettämään ainakin jotenkin - esimerkiksi vastaanottamaan tapahtumia localhostilla UDP:n kautta ja välittämään ne sitten Clickhouselle.
Yksi askel ratkaisusta
Lopullinen kaava alkoi näyttää tältä (tämän mallin neljäs versio): jokaisessa Clickhousen edessä olevassa palvelimessa on nginx (samalla palvelimella) ja se yksinkertaisesti välittää pyynnöt localhostille rajoittaen 50 yhteyksien määrää. kappaletta. Ja tämä suunnitelma toimi jo melko hyvin, kaikki oli sen kanssa melko hyvin.
Elimme näin noin kuukauden. Kaikki olivat tyytyväisiä, lisäsivät taulukoita, lisäsivät, lisäsivät... Yleisesti kävi ilmi, että tapa, jolla puskuritaulukoita lisättiin, ei ollut kovin optimaalinen (puhutaanpa näin). Teimme 16 kappaletta jokaisessa pöydässä ja parin sekunnin välähdysväli; meillä oli 20 pöytää ja jokainen pöytä sai 8 lisäystä sekunnissa - ja tässä vaiheessa "Clickhouse" alkoi... ennätykset alkoivat hidastua. Ne eivät edes menneet läpi... Nginxillä oli oletuksena niin mielenkiintoinen asia, että jos yhteydet päättyivät ylävirtaan, se palautti yksinkertaisesti "502" kaikille uusille pyynnöille.
Ja tässä meillä on (katsoin juuri itse Clickhousen lokit) noin puoli prosenttia pyynnöistä epäonnistui. Vastaavasti levyn käyttöaste oli korkea, sulautumisia oli paljon. No, mitä minä tein? En tietenkään vaivautunut selvittämään, miksi yhteys ja ylävirta päättyivät tarkalleen.
Korvaa nginx käänteisellä välityspalvelimella
Päätin, että meidän on hoidettava tämä itse, meidän ei tarvitse jättää sitä nginxille - nginx ei tiedä mitä taulukoita Clickhousessa on, ja korvasin nginxin käänteisellä välityspalvelimella, jonka myös kirjoitin itse.
Mitä hän tekee? Se toimii fasthttp-kirjaston "goshnoy" perusteella, eli nopeasti, melkein yhtä nopeasti kuin nginx. Anteeksi, Igor, jos olet täällä (huomaa: Igor Sysoev on venäläinen ohjelmoija, joka loi nginx-verkkopalvelimen). Se voi ymmärtää, millaisia kyselyitä nämä ovat – INSERT tai SELECT – vastaavasti, sillä on erilaisia yhteysvarantoja erityyppisille kyselyille.
Vastaavasti, vaikka meillä ei olisi aikaa suorittaa lisäyspyyntöjä, "valitut" menevät läpi ja päinvastoin. Ja se ryhmittelee tiedot puskuritaulukoihin - pienellä puskurilla: jos oli virheitä, syntaksivirheitä ja niin edelleen - jotta ne eivät vaikuttaisi suuresti muuhun dataan, koska kun vain lisäsimme puskuritaulukoihin, oli pieni "bachi", ja kaikki syntaksivirheet vaikuttivat vain tähän pieneen kappaleeseen; ja täällä ne vaikuttavat jo suureen puskuriin. Pieni on 1 megatavu, eli ei niin pieni.
Synkronoinnin lisääminen ja olennaisesti nginxin korvaaminen tekee olennaisesti saman asian kuin nginx teki aiemmin - sinun ei tarvitse muuttaa paikallista "Kittenhousea" tätä varten. Ja koska se käyttää fasthttp:tä, se on erittäin nopea - voit tehdä yli 100 tuhatta pyyntöä sekunnissa yksittäisille lisäyksille käänteisen välityspalvelimen kautta. Teoriassa voit lisätä yhden rivin kerrallaan kissanpentujen käänteiseen välityspalvelimeen, mutta emme tietenkään tee niin.
Kaava alkoi näyttää tältä: "Kittenhouse", käänteinen välityspalvelin ryhmittelee monet pyynnöt taulukoihin ja vuorostaan puskuritaulukot lisäävät ne tärkeimpiin.
Killer on väliaikainen ratkaisu, Kitten on pysyvä
Tämä on mielenkiintoinen ongelma... Onko kukaan teistä käyttänyt fasthttp:tä? Kuka käytti fasthttp:tä POST-pyyntöjen kanssa? Todennäköisesti tätä ei todellakaan olisi pitänyt tehdä, koska se puskuroi oletuksena pyynnön rungon ja puskurimme kooksi asetettiin 16 megatavua. Lisäys lakkasi pysymästä jossain vaiheessa, ja 16 megatavun paloja alkoi saapua kaikilta kymmeniltä tuhansilta palvelimilta, ja ne kaikki puskuroitiin muistiin ennen lähettämistä Clickhouseen. Vastaavasti muisti loppui, Out-Of-Memory Killer tuli ja tappoi käänteisen välityspalvelimen (tai "Clickhousen", joka voisi teoriassa "syötä" enemmän kuin käänteinen välityspalvelin). Kierros toistui. Ei kovin miellyttävä ongelma. Vaikka törmäsimme tähän vasta useiden kuukausien käytön jälkeen.
Mitä olen tehnyt? Jälleen kerran, en todellakaan halua ymmärtää, mitä tarkalleen tapahtui. Mielestäni on melko selvää, että sinun ei pitäisi puskuroida muistiin. En voinut korjata fasthttp, vaikka yritin. Mutta löysin tavan tehdä se niin, että mitään ei tarvinnut korjata, ja keksin oman menetelmäni HTTP:ssä - kutsuin sitä KITTEN. No, se on loogista - "VK", "Kitten"... Mitä muuta?...
Jos pyyntö tulee palvelimelle Kitten-menetelmällä, palvelimen pitäisi vastata "miau" - loogisesti. Jos hän vastaa tähän, katsotaan, että hän ymmärtää tämän protokollan, ja sitten sieppaan yhteyden (fasthttp:llä on tällainen menetelmä), ja yhteys menee "raaka"-tilaan. Miksi tarvitsen sitä? Haluan hallita kuinka TCP-yhteyksistä lukeminen tapahtuu. TCP:llä on upea ominaisuus: jos kukaan ei lue toiselta puolelta, kirjoitus alkaa odottaa, eikä muistia kuluteta erityisesti tähän.
Ja niin luen noin 50 asiakkaalta kerrallaan (viidestäkymmenestä, koska viidenkymmenen pitäisi ehdottomasti riittää, vaikka kurssi tuleekin toisesta DC:stä)... Kulutus on vähentynyt tällä lähestymistavalla ainakin 20 kertaa, mutta rehellisesti sanottuna , En pystynyt mittaamaan tarkkaa aikaa, koska se on jo turhaa (on jo saavutettu virhetaso). Protokolla on binäärinen, eli se sisältää taulukon nimen ja tiedot; http-otsikoita ei ole, joten en käyttänyt verkkoliitäntää (minun ei tarvitse kommunikoida selaimien kanssa - tein tarpeisiimme sopivan protokollan). Ja hänen kanssaan kaikki meni hyvin.
Puskuritaulukko on surullinen
Äskettäin löysimme toisen mielenkiintoisen puskuritaulukoiden ominaisuuden. Ja tämä ongelma on jo paljon tuskallisempi kuin muut. Kuvitellaanpa tämä tilanne: käytät jo aktiivisesti Clickhousea, sinulla on kymmeniä Clickhouse-palvelimia ja sinulla on joitakin pyyntöjä, joiden lukeminen kestää hyvin kauan (oletetaan, että yli 60 sekuntia); ja sinä tulet ja teet Alterin tällä hetkellä... Sillä välin ennen "Alter" alkaneita "valintoja" ei sisällytetä tähän taulukkoon, "Alter" ei käynnisty - luultavasti joitain ominaisuuksia siitä, miten "Clickhouse" toimii Tämä paikka. Ehkä tämä voidaan korjata? Vai eikö se ole mahdollista?
Yleisesti ottaen on selvää, että todellisuudessa tämä ei ole niin suuri ongelma, mutta puskuritaulukoiden kanssa siitä tulee tuskallisempaa. Koska jos esimerkiksi "Alter"-aikakatkaisusi (ja se saattaa aikakatkaista toisessa isännässä - ei sinun, vaan replikassa, esimerkiksi), niin... Poistit puskuritaulukon, "Alter" ( tai jokin muu isäntä) aikakatkaistiin. sitten on tapahtunut "Alter"-virhe) - sinun on silti varmistettava, että tietojen kirjoittaminen jatkuu: luot puskuritaulukot takaisin (saman kaavion mukaan kuin emotaulukko), sitten "Alter" menee läpi, loppuu loppujen lopuksi ja puskurin taulukko alkaa poiketa skeemaltaan emosta. Riippuen siitä, mikä "Alter" oli, lisäys ei ehkä enää mene tähän puskuritaulukkoon - tämä on erittäin surullista.
On myös tällainen merkki (ehkä joku huomasi sen) - sitä kutsutaan Clickhousen uusissa versioissa query_thread_log. Oletuksena joissakin versioissa sellainen oli. Täällä meillä on parissa kuukaudessa kertynyt 840 miljoonaa levyä (100 gigatavua). Tämä johtuu siitä, että sinne kirjoitettiin "lisäosat" (ehkä nyt muuten niitä ei kirjoiteta). Kuten sanoin, "insertimme" ovat pieniä - meillä oli paljon "lisäosia" puskuritaulukoihin. On selvää, että tämä on poistettu käytöstä - kerron vain, mitä näin palvelimellamme. Miksi? Tämä on toinen argumentti puskuritaulukoiden käyttöä vastaan! Spotty on hyvin surullinen.
Kuka tiesi, että tämän tyypin nimi oli Spotty? VK:n työntekijät nostivat kätensä. OK.
Tietoja "KitttenHouse"-suunnitelmista
Suunnitelmia ei yleensä jaeta, eikö niin? Yhtäkkiä et täytä niitä etkä näytä kovin hyvältä muiden silmissä. Mutta otan riskin! Haluamme tehdä seuraavaa: puskuritaulukot, mielestäni, ovat edelleen kainalosauva ja meidän on puskuroitava lisäys itse. Emme kuitenkaan halua puskuroida sitä levylle, joten puskuroimme lisäyksen muistiin.
Vastaavasti, kun "lisäys" tehdään, se ei ole enää synkroninen - se toimii jo puskuritaulukkona, lisätään päätaulukkoon (no, joskus myöhemmin) ja raportoi erillisen kanavan kautta mitkä lisäykset ovat menneet läpi ja mitkä. ei ole.
Miksi en voi jättää synkronista lisäystä? Se on paljon kätevämpää. Tosiasia on, että jos lisäät 10 tuhannesta isännästä, kaikki on hyvin - saat vähän jokaisesta isännästä, lisäät sinne kerran sekunnissa, kaikki on hyvin. Mutta haluaisin tämän järjestelmän toimivan esimerkiksi kahdelta koneelta, jotta voit ladata suurella nopeudella - ehkä et saa maksimaalista hyötyä Clickhousesta, mutta kirjoittaa vähintään 100 megatavua sekunnissa yhdestä koneesta käänteisen välityspalvelimen kautta - tässä kaavion on skaalattava sekä suuriin että pieniin määriin, joten emme voi odottaa sekuntia jokaista lisäystä, joten sen on oltava asynkroninen. Ja samalla tavalla asynkronisten vahvistusten pitäisi tulla lisäyksen jälkeen. Tiedämme menikö vai ei.
Tärkeintä on, että tässä järjestelmässä tiedämme varmasti, tapahtuiko lisäys vai ei. Kuvittele tämä tilanne: sinulla on puskuritaulukko, kirjoitit siihen jotain, ja sitten sanotaan, että taulukko siirtyi vain luku -tilaan ja yritti tyhjentää puskuria. Minne tiedot menevät? Ne jäävät puskuriin. Mutta emme voi olla varmoja tästä - entä jos tulee jokin muu virhe, jonka vuoksi tiedot eivät jää puskuriin... (Osoitteet Aleksei Milovidov, Yandex, ClickHouse-kehittäjä) Vai jääkö se? Aina? Aleksei vakuuttaa meidät, että kaikki tulee olemaan hyvin. Meillä ei ole mitään syytä olla uskomatta häntä. Mutta sama: jos emme käytä puskuritaulukoita, niiden kanssa ei ole ongelmia. Kaksinkertaisen määrän taulukoiden luominen on myös hankalaa, vaikka periaatteessa suuria ongelmia ei ole. Tämä on suunnitelma.
Puhutaanpa lukemisesta
Puhutaanpa nyt lukemisesta. Kirjoitimme tänne myös oman työkalumme. Vaikuttaa siltä, että miksi kirjoittaa tänne omaa instrumenttia?... Ja kuka käytti Tabixia? Jotenkin harvat ihmiset nostivat kätensä... Ja kuka on tyytyväinen Tabixin suorituskykyyn? No, emme ole tyytyväisiä siihen, emmekä ole kovin kätevää tietojen katseluun. Se sopii hyvin analytiikkaan, mutta pelkästään katselua varten sitä ei selvästikään ole optimoitu. Joten kirjoitin oman, oman käyttöliittymäni.
Se on hyvin yksinkertainen - se voi vain lukea tietoja. Hän ei osaa näyttää grafiikkaa, hän ei osaa tehdä mitään. Mutta se voi näyttää mitä tarvitsemme: esimerkiksi kuinka monta riviä taulukossa on, kuinka paljon tilaa se vie (jakamatta sitä sarakkeisiin), eli tarvitsemme hyvin peruskäyttöliittymän.
Ja se näyttää hyvin samanlaiselta kuin Sequel Pro, mutta tehty vain Twitterin Bootstrapissa ja toisessa versiossa. Kysyt: "Juri, miksi toisessa versiossa?" Mikä vuosi? 2018? Yleisesti ottaen tein tämän melko kauan sitten "Musclelle" (MySQL) ja vaihdoin vain pari riviä siellä olevissa kyselyissä, ja se alkoi toimia "Clickhousessa", mistä erityiskiitos! Koska jäsentäjä on hyvin samanlainen kuin "lihas" ja kyselyt ovat hyvin samanlaisia - erittäin kätevä, varsinkin aluksi.
No, se voi suodattaa taulukoita, näyttää taulukon rakenteen ja sisällön, voit lajitella, suodattaa sarakkeiden mukaan, näyttää tulokseen johtaneen kyselyn, vaikutuksen alaiset rivit (kuinka monta tuloksena), eli perusasiat tietojen katseluun. Melko nopea.
Siellä on myös toimittaja. Rehellisesti sanottuna yritin varastaa koko editorin Tabixista, mutta en onnistunut. Mutta jotenkin se toimii. Periaatteessa siinä kaikki.
"Clickhouse" sopii luolille
Haluan kertoa teille, että Clickhouse sopii kaikista kuvatuista ongelmista huolimatta erittäin hyvin tukille. Mikä tärkeintä, se ratkaisee ongelmamme - se on erittäin nopea ja antaa sinun suodattaa lokit sarakkeiden mukaan. Periaatteessa puskuritaulukot eivät ole toimineet hyvin, mutta yleensä kukaan ei tiedä miksi... Ehkä nyt tiedät paremmin missä sinulla on ongelmia.
TCP? Yleensä VK:ssa on tapana käyttää UDP:tä. Ja kun käytin TCP:tä... Kukaan ei tietenkään sanonut minulle: "Juri, mitä sinä puhut! Et voi, tarvitset UDP:tä." Kävi ilmi, että TCP ei ole niin pelottava. Ainoa asia on, jos kirjoitat kymmeniä tuhansia aktiivisia yhdisteitä, sinun on valmisteltava se hieman huolellisemmin; mutta se on mahdollista ja melko helppoa.
Lupasin julkaista "Kittenhouse" ja "Lighthouse" HighLoad Siberiassa, jos kaikki tilaavat julkisen "VK-taustajärjestelmämme"... Ja tiedätkö, kaikki eivät tilannut... Tietenkään en vaadi sinua tilaamaan meidän julkinen. Teitä on vielä liikaa, joku saattaa jopa loukkaantua, mutta silti, tilaakaa (ja tässä minun täytyy tehdä kissan silmät). Se on . Kiitos paljon! Github on meidän . Clickhousen avulla hiuksistasi tulee pehmeät ja silkkiset.
Moderaattori: - Ystävät, nyt kysymyksiä. Heti sen jälkeen, kun olemme esittäneet kiitostodistuksen ja VHS-raporttisi.
Juri Nasretdinov (jäljempänä YN): – Kuinka pystyit nauhoittamaan raporttini VHS:lle, jos se vain päättyi?
Moderaattori: – Et myöskään voi täysin määrittää, kuinka "Clickhouse" toimii vai ei! Ystävät, 5 minuuttia kysymyksille!
kysymykset
Kysymys yleisöltä (jäljempänä Q): - Hyvää iltapäivää. Kiitos paljon raportista. Minulla on kaksi kysymystä. Aloitan jostain kevytmielisestä: vaikuttaako kaavioiden (3, 4, 7...) nimessä "Kissantalo" olevien t-kirjainten määrä kissojen tyytyväisyyteen?
YN: - Minkä määrä?
З: – Kirjain t. Siellä on kolme t:tä, jossain noin kolme t:tä.
YN: - Enkö korjannut sitä? No, tietysti tekee! Nämä ovat erilaisia tuotteita – olen vain pettänyt sinua koko tämän ajan. Okei, vitsailen - sillä ei ole väliä. Ah, tässä! Ei, se on sama asia, tein kirjoitusvirheen.
З: - Kiitos. Toinen kysymys on vakava. Ymmärtääkseni Clickhousessa puskuritaulukot elävät yksinomaan muistissa, niitä ei puskuroida levylle eivätkä näin ollen ole pysyviä.
YN: - Joo.
З: – Ja samaan aikaan asiakas puskuroi levylle, mikä tarkoittaa jonkinlaista takuuta samojen lokien toimittamisesta. Mutta tämä ei ole mitenkään taattu Clickhousessa. Selitä, miten takuu toteutetaan, mistä johtuu?.. Tässä tämä mekanismi tarkemmin
YN: – Kyllä, teoriassa tässä ei ole ristiriitoja, koska Clickhousen kaatuessa sen voi tunnistaa miljoonalla eri tavalla. Jos Clickhouse kaatuu (jos se päättyy väärin), voit karkeasti katsottuna kelata hieman muistiin kirjoittamaasi lokia ja aloittaa siitä hetkestä, jolloin kaikki oli täsmälleen hyvin. Oletetaan, että kelaat minuutin taaksepäin, eli katsotaan, että olet huuhtelenut kaiken minuutissa.
З: – Eli "Kittenhouse" pitää ikkunaa pidempään ja pystyykö putoamisen yhteydessä tunnistamaan sen ja kelaamaan sen taaksepäin?
YN: – Mutta tämä on teoriassa. Käytännössä emme tee näin, ja luotettava toimitus on nollasta äärettömyyteen. Mutta keskimäärin yksi. Olemme tyytyväisiä siihen, että jos Clickhouse kaatuu jostain syystä tai palvelimet "käynnistetään uudelleen", menetämme vähän. Kaikissa muissa tapauksissa ei tapahdu mitään.
З: - Hei. Alusta asti minusta näytti, että käytät todella UDP:tä raportin alusta lähtien. Sinulla on http, kaikki se... Ja suurin osa kuvailemistasi ongelmista, ymmärtääkseni, johtui juuri tästä ratkaisusta...
YN: – Mitä käytämme TCP:tä?
З: - Pohjimmiltaan kyllä.
YN: - Ei.
З: – Fasthttp:n kanssa oli ongelmia, yhteyden kanssa ongelmia. Jos olisit juuri käyttänyt UDP:tä, olisit säästänyt aikaasi. Pitkissä viesteissä tai muussa olisi ongelmia...
YN: - Millä?
З: – Pitkillä viesteillä, koska se ei ehkä sovi MTU:hun, jotain muuta... No, voi olla omat ongelmansa. Kysymys kuuluu: miksi ei UDP?
YN: – Uskon, että TCP/IP:tä kehittäneet kirjoittajat ovat minua paljon älykkäämpiä ja tietävät minua paremmin, kuinka paketit sarjoidaan (jotta ne menevät), samalla säädetään lähetysikkunaa, ei ylikuormiteta verkkoa, annetaan palautetta siitä, mitä ei lueta, ei lasketa toiselta puolelta... Kaikki nämä ongelmat olisivat mielestäni olemassa UDP:ssä, vain minun pitäisi kirjoittaa vielä enemmän koodia kuin jo kirjoitin, jotta voisin toteuttaa saman asian itse ja mitä todennäköisimmin huonosti. En edes pidä C-kielellä kirjoittamisesta, saati sitten siellä...
З: - Ihan kätevää! Lähetetty ok, älä odota mitään - se on täysin asynkroninen. Palautti ilmoitus, että kaikki oli hyvin - se tarkoittaa, että se saapui; Jos se ei tule, se tarkoittaa, että se on huono.
YN: – Tarvitsen molempia – Minun täytyy pystyä lähettämään sekä toimitustakuulla että ilman toimitustakuuta. Nämä ovat kaksi eri skenaariota. Minun ei tarvitse kadottaa joitain lokeja tai olla menettämättä niitä järkevän rajoissa.
З: – En tuhlaa aikaa. Tästä on keskusteltava enemmän. Kiitos.
Moderaattori: – Kenellä on kysymyksiä – kädet taivaalle!
З: - Hei, olen Sasha. Jossain raportin puolivälissä ilmaantui tunne, että TCP:n lisäksi oli mahdollista käyttää valmiita ratkaisuja - jonkinlaista Kafkaa.
YN: – No... Sanoin, että en halua käyttää välipalvelimia, koska... Kafkassa käy ilmi, että meillä on kymmenentuhatta isäntiä; itse asiassa meillä on enemmän - kymmeniä tuhansia isäntiä. Se voi myös olla tuskallista tehdä Kafkan kanssa ilman valtakirjoja. Lisäksi, mikä tärkeintä, se antaa edelleen "latenssia", se antaa ylimääräisiä isäntiä, joita tarvitset. Mutta en halua niitä - haluan...
З: "Mutta lopulta siitä kävi kuitenkin niin."
YN: – Ei, isäntiä ei ole! Tämä kaikki toimii Clickhouse-isännissä.
З: - No, ja "Kittenhouse", joka on päinvastainen - missä hän asuu?
YN: – Clickhouse-isännällä se ei kirjoita mitään levylle.
З: - Oletetaan.
Moderaattori: - Oletko tyytyväinen? Voimmeko antaa sinulle palkkaa?
З: - Kyllä sinä voit. Itse asiassa saman asian saamiseksi on paljon kainalosauvoja, ja nyt - edellinen vastaus TCP-aiheesta on mielestäni ristiriidassa tämän tilanteen kanssa. Tuntuu vain siltä, että kaiken olisi voinut tehdä polvillani paljon lyhyemmässä ajassa.
YN: – Ja myös se, miksi en halunnut käyttää Kafkaa, koska Clickhouse Telegramin chatissa oli aika paljon valituksia siitä, että esimerkiksi Kafkan viestit katosivat. Ei itse Kafkasta, vaan Kafkan ja Clickhausin integraatiosta; tai jokin ei liittynyt siihen. Karkeasti sanottuna Kafkalle olisi silloin tarpeen kirjoittaa asiakas. En usko, että yksinkertaisempaa tai luotettavampaa ratkaisua voisi olla.
З: – Kerro minulle, miksi et kokeillut mitään jonoja tai jotain yleistä bussia? Koska sanot, että asynkronisella voit lähettää itse lokit jonon läpi ja saada vastauksen asynkronisesti jonon kautta?
YN: – Ehdottakaa, mitä jonoja voitaisiin käyttää?
З: – Kaikki, jopa ilman takuuta, että ne ovat kunnossa. Jonkinlainen Redis, RMQ...
YN: – Minulla on sellainen tunne, että Redis ei todennäköisesti pysty vetämään sellaista lisäysmäärää edes yhdelle isännälle (usean palvelimen mielessä), joka vetää Clickhousen pois. En voi tukea tätä millään todisteella (en ole vertaillut sitä), mutta minusta näyttää siltä, että Redis ei ole paras ratkaisu tässä. Periaatteessa tätä järjestelmää voidaan pitää improvisoituna viestijonona, mutta joka on räätälöity vain "Clickhouse"
Moderaattori: – Yuri, kiitos paljon. Ehdotan, että lopetan kysymykset ja vastaukset tähän ja sanon kenelle kysymyksen esittäneistä annamme kirjan.
YN: – Haluaisin antaa kirjan ensimmäiselle kysymyksen esittäjälle.
Moderaattori: - Mahtavaa! Loistava! Upeaa! Kiitos paljon!
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com