Huhtikuussa Avito-insinöörit kokoontuivat online-tapaamisiin ClickHousen pääkehittäjä Aleksei Milovidovin ja Integrosin Golang-kehittäjä Kirill Shvakovin kanssa. Keskustelimme siitä, kuinka käytämme tietokannan hallintajärjestelmää ja mitä vaikeuksia kohtaamme.
Kokouksen pohjalta olemme koonneet artikkelin, jossa on asiantuntijoiden vastauksia meidän ja yleisön kysymyksiin varmuuskopioinnista, tietojen uudelleenjaosta, ulkoisista sanakirjoista, Golang-ohjaimesta ja ClickHouse-versiopäivityksistä. Se voi olla hyödyllinen kehittäjille, jotka työskentelevät jo aktiivisesti Yandex DBMS:n kanssa ja ovat kiinnostuneita sen nykyisyydestä ja tulevaisuudesta. Aleksei Milovidovin vastaukset oletusarvoisesti, ellei toisin mainita.
Varo, leikkauksen alla on paljon tekstiä. Toivomme, että kysymyksiä sisältävä sisältö auttaa sinua navigoinnissa.
Pitoisuus
Jos et halua lukea tekstiä, voit katsoa tallenteen kokoontumisista . Aikaleimat ovat ensimmäisessä kommentissa videon alla.
ClickHouse päivittyy jatkuvasti, mutta tietomme eivät. Mitä tehdä sen kanssa?
ClickHouse päivittyy jatkuvasti, ja optimointi finalin käsittelemät tiedot eivät päivity ja ovat varmuuskopiossa.
Oletetaan, että meillä oli jokin ongelma ja tiedot katosivat. Päätimme palauttaa, ja kävi ilmi, että vanhat osiot, jotka on tallennettu varmuuskopiopalvelimille, eroavat suuresti nykyisestä ClickHousen versiosta. Mitä tehdä tällaisessa tilanteessa, ja onko se mahdollista?
Tilanne, jossa palautit tiedot varmuuskopiosta vanhassa muodossa, mutta uudessa versiossa niitä ei ole yhdistetty, on mahdoton. Varmistamme, että ClickHousen tietomuoto on aina taaksepäin yhteensopiva. Tämä on paljon tärkeämpää kuin taaksepäin yhteensopivuus toiminnallisuudessa, jos jonkin harvoin käytetyn toiminnon käyttäytyminen on muuttunut. Data, joka on tallennettu levylle, ClickHousen uuden version pitäisi aina pystyä lukemaan. Tämä on laki.
Mitkä ovat tämänhetkiset parhaat käytännöt ClickHousen tietojen varmuuskopiointiin?
Kuinka tehdä varmuuskopioita, kun otetaan huomioon, että meillä on optimoitu loppuoperaatiot, valtava tietokanta teratavuista ja data, joka päivitetään, sanotaan, että viimeiset kolme päivää, eikä niille tapahdu mitään toimenpiteitä?
Voimme koota oman ratkaisumme ja kirjoittaa päähän: kerää nämä varmuuskopiot niin ja sillä tavalla. Ehkä sinun ei tarvitse haukkua mitään, ja polkupyörä keksittiin kauan sitten?
Aloitetaan parhaista käytännöistä. Kollegani neuvovat aina muistuttamaan varmuuskopiointia koskeviin kysymyksiin Yandex.Cloud-palvelusta, jossa tämä tehtävä on jo ratkaistu. Joten käytä sitä, jos mahdollista.
Varmuuskopiointiin ei ole täydellistä ratkaisua, joka on sataprosenttisesti sisäänrakennettu ClickHouseen. On joitain aihioita, joita voit käyttää. Täydellisen ratkaisun saamiseksi joudut joko muokkaamaan hieman manuaalisesti tai tekemään kääreitä skriptien muodossa.
Aloitan yksinkertaisimmista ratkaisuista ja lopetan edistyneimmillä, riippuen datan määrästä ja klusterin koosta. Mitä suurempi klusteri, sitä vaikeammaksi ratkaisu tulee.
Jos tietotaulukko vie vain muutaman gigatavun, varmuuskopiointi voidaan tehdä seuraavasti:
- Tallenna taulukoiden määritelmä eli metatiedot − näytä luo taulukko.
- Tee kaatopaikka ClickHouse-ohjelmalla - valita * pöydästä arkistoida. Oletuksena saat tiedoston TabSeparated-muodossa. Jos haluat olla tehokkaampi, voit käyttää alkuperäistä muotoa.
Jos tietomäärä on suurempi, varmuuskopiointi vie enemmän aikaa ja paljon tilaa. Tätä kutsutaan loogiseks varmuuskopioksi; se ei ole sidottu ClickHouse-tietomuotoon. Jos on, voit viimeisenä keinona ottaa varmuuskopion ja ladata sen MySQL:ään palautusta varten.
Edistyneissä tapauksissa ClickHousessa on sisäänrakennettu kyky luoda tilannekuva osioista paikallisessa tiedostojärjestelmässä. Tämä ominaisuus on saatavilla pyynnöstä. muuta pöydän jäädytysosiota. Tai yksinkertaisesti muuttaa pöydän jäädytystä - Tämä on tilannekuva koko pöydästä.
Tilannekuva luodaan yhtenäiseksi yhdelle taulukolle yhdelle sirpaleelle, eli koko klusterista on mahdotonta luoda johdonmukaista tilannekuvaa tällä tavalla. Mutta useimmissa tehtävissä tällaista tarvetta ei ole, ja riittää, että suoritat pyynnön jokaiselle sirpaleelle ja saat johdonmukaisen tilannekuvan. Se on luotu kiintolinkkien muodossa, joten se ei vie ylimääräistä tilaa. Sitten kopioit tämän tilannevedoksen varmuuskopiopalvelimelle tai tallennustilaan, jota käytät varmuuskopiointiin.
Tällaisen varmuuskopion palauttaminen on melko helppoa. Ensin luodaan taulukot olemassa olevien taulukkomääritelmien mukaan. Kopioi seuraavaksi osioiden tallennetut tilannevedokset näiden taulukoiden Directory-Detachediin ja suorita kysely kiinnitä osio. Tämä ratkaisu sopii varsin vakavimpiin tietomääriin.
Joskus tarvitset jotain vielä siistimpää - tapauksissa, joissa kullakin palvelimella on kymmeniä tai jopa satoja teratavuja ja satoja palvelimia. Tässä on ratkaisu, jota vakoin Yandex.Metrican kollegoilta. En suosittele sitä kaikille - lue se ja päätä itse, sopiiko se vai ei.
Ensin sinun on luotava useita palvelimia suurilla levyhyllyillä. Seuraavaksi nosta näille palvelimille useita ClickHouse-palvelimia ja määritä ne toimimaan toisena replikoina samoille sirpaleille. Käytä sitten näiden palvelimien tiedostojärjestelmää tai jotain työkalua, jonka avulla voit luoda tilannekuvia. Tässä on kaksi vaihtoehtoa. Ensimmäinen vaihtoehto on LVM snapshots, toinen vaihtoehto on ZFS Linuxissa.
Sen jälkeen joka päivä sinun on luotava tilannekuva, se valehtelee ja vie tilaa. Luonnollisesti, jos tiedot muuttuvat, ajan myötä tilan määrä kasvaa. Voit saada tämän tilannekuvan milloin tahansa ja palauttaa tiedot, niin outo päätös. Lisäksi sinun on silti rajoitettava näitä kopioita kokoonpanossa, jotta ne eivät yritä tulla johtajiksi.
Onko mahdollista järjestää kontrolloitu jäljennöskanta kuiluihin?
Tänä vuonna aiot tehdä akselit ClickHousessa. Voidaanko niihin järjestää kontrolloitu replikoiden ruuhka? Haluaisimme käyttää sitä suojautuaksemme negatiivisilta skenaarioilta muutoksilla ja muilla muutoksilla.
Onko mahdollista tehdä jonkinlainen palautus altereille? Oletetaan esimerkiksi olemassa olevassa kuilussa, että otetaan muutokset käyttöön tähän hetkeen asti ja tästä hetkestä lähtien lopetat muutosten soveltamisen?
Jos komento tuli klusteriimme ja rikkoi sen, niin meillä on tunnin viiveellä ehdollinen replika, jossa voidaan sanoa, että käytetään sitä tällä hetkellä, mutta emme ota siihen tehtyjä muutoksia viimeisen kymmenen minuutin aikana?
Aluksi hallitusta replikoiden ruuhkasta. Käyttäjiltä tuli tällainen pyyntö, ja loimme Githubiin ongelman pyynnöllä: "Jos joku tarvitsee tätä, tykkää siitä, laita sydäntä." Kukaan ei toimittanut, ja ongelma lopetettiin. Voit kuitenkin saada tämän mahdollisuuden jo perustamalla ClickHousen. Totta, vasta versiosta 20.3 alkaen.
ClickHouse yhdistää jatkuvasti tietoja taustalla - yhdistä. Kun yhdistäminen tehdään, osa tietopaloista korvataan suuremmalla osalla. Samanaikaisesti aiemmin olleet tiedot pysyvät levyllä jonkin aikaa.
Ensinnäkin niitä säilytetään niin kauan kuin niitä käyttäviä kyselyjä on olemassa, jotta varmistetaan toiminnan estäminen. Valitut pyynnöt luetaan hiljaa vanhoista paloista.
Toiseksi, on myös aikaraja - vanhat tiedot makaavat levyllä kahdeksan minuuttia. Nämä kahdeksan minuuttia voidaan muokata ja muuttaa jopa yhdeksi päiväksi. Tämä maksaa levytilaa: tietovirrasta riippuen käy ilmi, että viimeisen päivän aikana data ei vain kaksinkertaistu, vaan se voi kasvaa viisinkertaiseksi. Mutta vakavan ongelman sattuessa voit pysäyttää ClickHouse-palvelimen ja käsitellä kaikkea.
Nyt kysymys kuuluu, kuinka tämä suojaa muutoksilta. Tässä kannattaa katsoa syvemmälle, sillä ClickHousen vanhemmissa versioissa alter toimi niin, että se yksinkertaisesti vaihtoi palasia suoraan. Joissakin tiedostoissa on dataa, ja teemme esim. muuta pudotussaraketta. Sitten tämä sarake poistetaan fyysisesti kaikista paloista.
Mutta versiosta 20.3 alkaen muutosmekanismi on täysin muuttunut, ja nyt datapalat ovat aina muuttumattomia. Ne eivät muutu ollenkaan – muutokset toimivat nyt samalla tavalla kuin yhdistämiset. Sen sijaan, että korvaamme palan paikan päällä, luomme uuden. Uudessa osassa tiedostoista, jotka eivät ole muuttuneet, tulee kovalinkkejä, ja jos poistamme sarakkeen, se yksinkertaisesti puuttuu uudesta osasta. Vanha kappale poistetaan oletusarvoisesti kahdeksan minuutin kuluttua, ja täällä voit säätää yllä mainittuja asetuksia.
Sama koskee muutoksia, kuten mutaatioita. Kun teet muuta poista tai muuta päivitystä, se ei muuta kappaletta, vaan luo uuden. Ja sitten poistaa vanhan.
Entä jos taulukon rakenne on muuttunut?
Kuinka palauttaa vanhalla mallilla tehty varmuuskopio? Ja toinen kysymys koskee tilannekuvia ja tiedostojärjestelmätyökaluja. Onko Btrfs hyvä täällä ZFS: n sijaan Linux LVM: ssä?
Jos sinä teet kiinnitä osio osioita, joilla on erilainen rakenne, ClickHouse kertoo, että tämä ei ole mahdollista. Ratkaisu on tämä. Ensimmäinen on luoda MergeTree-tyyppinen väliaikainen taulukko vanhalla rakenteella, liittää siihen tiedot liittämällä ja tehdä muutoskysely. Sitten voit joko kopioida tai siirtää nämä tiedot ja liittää uudelleen tai käyttää kyselyä muuta taulukon siirtoosiota.
Nyt toinen kysymys on, onko mahdollista käyttää Btrfs. Ensinnäkin, jos sinulla on LVM, LVM-snapshots riittää, ja tiedostojärjestelmä voi olla ext4, sillä ei ole väliä. Btrts:n kanssa kaikki riippuu kokemuksestasi. Tämä on kypsä tiedostojärjestelmä, mutta edelleen on epäilyksiä siitä, kuinka kaikki toimii käytännössä tietyssä skenaariossa. En suosittele tämän käyttöä, ellei sinulla ole Btrfs:tä tuotannossa.
Mitkä ovat nykyiset parhaat käytännöt tietojen uudelleenjakamiseen?
Kysymys uudelleenhajotuksesta on monimutkainen ja monitahoinen. Täällä voit vastata useisiin vaihtoehtoihin kerralla. Voit mennä sisään yhdeltä puolelta ja sanoa tämän - ClickHousessa ei ole sisäänrakennettua uudelleenjakovaihtoehtoa. Mutta pelkään, että tämä vastaus ei sovi kenellekään. Siksi voit mennä toiselta puolelta ja sanoa, että ClickHousella on monia tapoja murtaa tietoja uudelleen.
Jos klusterin tila loppuu tai se ei kestä kuormaa, lisää uusia palvelimia. Mutta nämä palvelimet ovat oletuksena tyhjiä, niissä ei ole tietoja, ei ole kuormaa. Sinun on siirrettävä dataa niin, että ne jakautuvat tasaisesti uudessa, suuremmassa klusterissa.
Ensimmäinen tapa tehdä tämä on kopioida osa osioista uusille palvelimille kyselyn avulla muuta taulukon nouto-osiota. Sinulla oli esimerkiksi osiot kuukausien mukaan ja otat vuoden 2017 ensimmäisen kuukauden ja kopioit sen uudelle palvelimelle ja kopioit sitten kolmannen kuukauden jollekin muulle uudelle palvelimelle. Ja niin teet, kunnes siitä tulee enemmän tai vähemmän tasaista.
Siirto voidaan suorittaa vain niille osiolle, jotka eivät muutu tallennuksen aikana. Uusissa osioissa tallennus on poistettava käytöstä, koska niiden siirto ei ole atomista. Muutoin tiedoissa on kaksoiskappaleita tai aukkoja. Tämä menetelmä on kuitenkin käytännöllinen ja toimii melko tehokkaasti. Valmiit pakatut osiot siirretään verkon yli, eli tietoja ei pakata tai koodata uudelleen.
Tällä menetelmällä on yksi haittapuoli, ja se riippuu jakojärjestelmästä, oletko sitoutunut tähän jakomalliin, mikä jakoavain sinulla oli. Esimerkissäsi mittareiden tapauksessa jakoavain on polun tiiviste. Kun valitset hajautetun taulukon, se siirtyy kaikkiin klusterin sirpaleisiin kerralla ja ottaa sieltä tietoja.
Tämä tarkoittaa, että sinulle ei itse asiassa ole väliä, mitkä tiedot päätyivät mihinkin sirpaleeseen. Pääasia on, että yhden polun tiedot päätyvät yhdelle sirpaleelle, mutta kumpi ei ole tärkeä. Tässä tapauksessa valmiiden osioiden siirtäminen on täydellistä, koska valituilla kyselyillä saat myös täydelliset tiedot - joko ennen uudelleenjakoa tai sen jälkeen, kaavalla ei ole väliä.
Mutta on tapauksia, jotka ovat monimutkaisempia. Jos luotat sovelluslogiikkatasolla erityiseen sharing-malliin, että tämä asiakas sijaitsee sellaisella ja sellaisella sirpaleella, ja pyyntö voidaan lähettää välittömästi sinne, ei Distributed-taulukkoon. Vai käytätkö melko uusinta ClickHousen versiota ja olet ottanut asetuksen käyttöön optimoida ohita käyttämättömät sirpaleet. Tässä tapauksessa valintakyselyn aikana jossa-osion lauseke analysoidaan ja lasketaan, mitä sirpaleita tulee käyttää jakokaavan mukaan. Tämä toimii edellyttäen, että tiedot on osioitu täsmälleen tämän jakojärjestelmän mukaisesti. Jos järjestit ne uudelleen manuaalisesti, vastaavuus voi muuttua.
Tämä on siis menetelmä numero yksi. Ja odotan vastaustasi, onko menetelmä sopiva, vai jatketaan.
Vladimir Kolobaev, johtava järjestelmänvalvoja Avitossa: Aleksei, mainitsemasi menetelmä ei sovi kovin hyvin, kun sinun on haettava kuormaa, mukaan lukien lukeminen. Voimme ottaa osion, joka on kuukausittain, ja voimme viedä edellisen kuukauden toiseen solmuun, mutta kun näitä tietoja pyydetään, lataamme sen vain. Mutta haluaisin ladata koko klusterin, koska muuten koko lukukuorma käsitellään jonkin aikaa kahdella sirpaleella.
Aleksei Milovidov: Vastaus tähän on outo - kyllä, se on huono, mutta se voi toimia. Selitän tarkalleen kuinka. Tietojesi mukana tulevaa latausskenaariota kannattaa tarkastella. Jos tämä on seurantatietoa, on lähes varmaa, että suurin osa pyynnöistä koskee tuoreita tietoja.
Olet asentanut uusia palvelimia, siirtänyt vanhat osiot, mutta myös muuttanut uusien tietojen kirjoitustapaa. Ja tuoretta dataa levitetään koko klusteriin. Siten viiden minuutin kuluttua viimeisen viiden minuutin pyynnöt lataavat klusterin tasaisesti, päivän kuluttua vuorokauden pyynnöt lataavat klusterin tasaisesti. Ja edellisen kuukauden pyynnöt menevät valitettavasti vain osalle klusteripalvelimista.
Mutta usein sinulla ei ole pyyntöjä helmikuulle 2019. Todennäköisesti, jos pyynnöt menevät vuoteen 2019, ne koskevat koko vuotta 2019 - pitkälle aikavälille, eivät jollekin pienelle alueelle. Ja tällaiset pyynnöt voivat myös ladata klusterin tasaisesti. Mutta yleisesti ottaen huomautuksesi on aivan oikein, että tämä on ad hoc -ratkaisu, joka ei jaa tietoja täysin tasaisesti.
Minulla on vielä muutama seikka vastatakseni kysymykseen. Yksi niistä koskee sitä, kuinka alun perin tehdään sharding-järjestelmä sellaiseksi, että uudelleenmurtamisesta aiheutuu vähemmän kipua. Tämä ei ole aina mahdollista.
Sinulla on esimerkiksi seurantatietoja. Seurantatiedot kasvavat kolmesta syystä. Ensimmäinen on historiallisten tietojen kerääminen. Toinen on liikenteen kasvu. Ja kolmas on seurannan kohteena olevien asioiden määrän kasvu. Uusia mikropalveluita ja mittareita on tallennettava.
On mahdollista, että näistä suurin kasvu johtuu kolmannesta syystä - tämä on seurannan käytön lisääntyminen. Ja tässä tapauksessa kannattaa tarkastella kuorman luonnetta, mitkä ovat tärkeimmät valintapyynnöt. Tärkeimmät valintakyselyt noudattavat todennäköisesti jotakin muuttujien osajoukkoa.
Esimerkiksi jonkin palvelun suorittimen käyttö joillakin palvelimilla. Osoittautuu, että on olemassa jokin avainten osajoukko, jolla saat nämä tiedot. Ja itse näiden tietojen pyyntö on todennäköisesti melko yksinkertainen ja suoritetaan kymmenissä millisekunneissa. Käytetään valvontapalveluihin, kojelaudoille. Toivottavasti ymmärsin tämän oikein.
Vladimir Kolobaev: Tosiasia on, että vetoamme hyvin usein historiallisiin tietoihin, koska vertaamme nykyistä sijaintia historialliseen reaaliajassa. Ja meille on tärkeää päästä nopeasti käsiksi suureen tietomäärään, ja ClickHouse tekee hyvää työtä tämän kanssa.
Olet täysin oikeassa, useimmat lukupyynnöt koemme viimeisen päivän aikana, kuten mikä tahansa valvontajärjestelmä. Mutta samaan aikaan historiatietojen kuormitus on myös melko suuri. Se on pohjimmiltaan hälytysjärjestelmästä, joka kiertää XNUMX sekunnin välein ja sanoo ClickHouselle: "Anna minulle tiedot viimeiseltä kuudelta viikolta. Rakenna minulle nyt niistä jonkinlainen liukuva keskiarvo, ja verrataanpa nykyistä arvoa historialliseen arvoon."
Haluaisin sanoa, että tällaisia erittäin tuoreita pyyntöjä varten meillä on toinen pieni taulukko, johon tallennamme vain kahden päivän tiedot, ja tärkeimmät pyynnöt lentävät siihen. Lähetämme vain suuret historialliset kyselyt suureen sirpaloituun taulukkoon.
Aleksei Milovidov: Valitettavasti se osoittautuu huonosti soveltuvaksi skenaarioosi, mutta kuvailen kaksi huonoa ja monimutkaista sirpalointijärjestelmää, joita ei tarvitse käyttää, mutta joita käytetään ystäväni palvelussa.
Yandex.Metrica-tapahtumilla on pääklusteri. Tapahtumat ovat sivun katseluja, napsautuksia ja siirtymiä. Useimmat pyynnöt menevät tietylle verkkosivustolle. Avaat Yandex.Metrica-palvelun, sinulla on verkkosivusto - avito.ru, siirryt raporttiin ja verkkosivustollesi tehdään pyyntö.
Mutta on muitakin pyyntöjä - analyyttisiä ja globaaleja - joita sisäiset analyytikot tekevät. Varmuuden vuoksi huomautan, että sisäiset analyytikot tekevät pyyntöjä vain Yandex-palveluista. Mutta silti jopa Yandex-palvelut vievät merkittävän osan kaikesta tiedosta. Nämä eivät ole tiettyjä laskureita, vaan laajempaa suodatusta koskevia pyyntöjä.
Miten järjestää tiedot niin, että kaikki toimii tehokkaasti yhdellä laskurilla ja myös globaaleilla kyselyillä? Toinen vaikeus on se, että ClickHousen Metrics-klusterin pyyntöjen määrä on useita tuhansia sekunnissa. Samanaikaisesti yksi ClickHouse-palvelin ei käsittele ei-triviaaleja pyyntöjä, esimerkiksi useita tuhansia sekunnissa.
Klusterin koko on kuusisataa ja jotain palvelimia. Jos vain venyttää hajautetun taulukon tämän klusterin päälle ja lähettää sinne useita tuhansia pyyntöjä, siitä tulee vielä pahempaa kuin lähettäminen yhdelle palvelimelle. Toisaalta vaihtoehto, että data jakautuu tasaisesti ja mennään ja kysytään kaikilta palvelimilta, hylätään heti.
On vaihtoehto, joka on täysin päinvastainen. Kuvittele, jos sirpaloisimme tiedot eri sivustoilla ja yhden sivuston pyyntö menee yhteen sirpaleeseen. Nyt klusteri pystyy käsittelemään kymmenentuhatta pyyntöä sekunnissa, mutta yhdellä sirpaleella yksi pyyntö toimii liian hitaasti. Se ei enää skaalaudu suorituskyvyn suhteen. Varsinkin jos tämä on sivusto avito.ru. En paljasta salaisuutta, jos sanon, että Avito on yksi RuNetin vierailluimmista sivustoista. Ja sen käsitteleminen yhdellä sirpaleella olisi hulluutta.
Siksi jakojärjestelmä on järjestetty monimutkaisemmalla tavalla. Koko klusteri on jaettu useisiin klustereihin, joita kutsumme tasoiksi. Jokaisen klusterin sisällä on kymmenestä useisiin kymmeniin sirpaleita. Tällaisia klustereita on yhteensä XNUMX.
Miten tämä kaikki skaalautuu? Klusterien määrä ei muutu – kuten muutama vuosi sitten oli kolmekymmentäyhdeksän, niin se pysyykin. Mutta jokaisessa niistä lisäämme asteittain sirpaleiden määrää kerääessämme tietoja. Ja sharding-järjestelmä kokonaisuudessaan on tällainen: nämä klusterit on jaettu verkkosivustoihin, ja jotta ymmärrettäisiin, mikä verkkosivusto missä klusterissa on, käytetään erillistä MySQL:n metatietokantaa. Yksi sivusto - yhdessä klusterissa. Ja sen sisällä sirpalointi tapahtuu vierailijatunnusten mukaan.
Tallennettaessa jaamme ne vierailijatunnuksen loppuosan mukaan. Mutta kun uusi sirpale lisätään, jakomalli muuttuu, jatketaan jakamista, mutta loput jaetaan toisella numerolla. Tämä tarkoittaa, että yksi vierailija sijaitsee jo useilla palvelimilla, etkä voi lyödä vetoa siitä. Tämä tehdään vain sen varmistamiseksi, että tiedot pakataan paremmin. Ja kun kyselemme, siirrymme Distributed-taulukkoon, joka tarkastelee klusteria ja käyttää kymmeniä palvelimia. Tämä on niin typerä kaava.
Mutta tarinani on epätäydellinen, jos en sano, että hylkäsimme tämän suunnitelman. Uudessa järjestelmässä muutimme kaiken ja kopioimme kaikki tiedot clickhouse-copierilla.
Uudessa järjestelmässä kaikki sivustot on jaettu kahteen luokkaan - suuriin ja pieniin. En tiedä, kuinka kynnys valittiin siellä, mutta seurauksena kävi ilmi, että suuret sivustot tallennetaan yhteen klusteriin, joissa on 120 sirpaletta, joissa kussakin on kolme kopiota - eli 360 palvelinta. Ja sirpalointijärjestelmä on sellainen, että kaikki pyynnöt menevät kaikkiin sirpaleisiin kerralla. Jos avaat nyt minkä tahansa avito.ru-raporttisivun Yandex.Metricassa, pyyntö menee 120 palvelimelle. Runetissa on muutamia suuria sivustoja. Ja pyyntöjä ei ole tuhatta sekunnissa, vaan jopa alle sata. Kaikkea tätä hiljaa pureskelee Distributed-taulukko, jossa jokainen käsittelee 120 palvelinta.
Ja toinen klusteri on tarkoitettu pienille sivustoille. Tässä on jakojärjestelmä sivustotunnuksen mukaan, ja jokainen pyyntö menee täsmälleen yhdelle sirpaleelle.
ClickHousessa on clickhouse-kopiokoneapuohjelma. Voitko kertoa hänestä?
Minun on heti sanottava, että tämä ratkaisu on hankalampi ja hieman vähemmän tuottava. Etuna on, että se tahraa tiedot kokonaan määrittämäsi skeeman mukaan. Mutta apuohjelman haittana on, että se ei murtu uudelleen ollenkaan. Se kopioi tiedot yhdestä klusteriskeemasta toiseen klusteriskeemaan.
Tämä tarkoittaa, että jotta se toimisi, sinulla on oltava kaksi klusteria. Ne voivat sijaita samoilla palvelimilla, mutta tietoja ei kuitenkaan siirretä asteittain, vaan ne kopioidaan.
Esimerkiksi palvelimia oli neljä, nyt niitä on kahdeksan. Luot uuden hajautetun taulukon kaikille palvelimille, uudet paikalliset taulukot ja käynnistät clickhouse-copierin, määrität siinä työskentelysuunnitelman, joka sen tulee lukea sieltä, hyväksyt uuden jakojärjestelmän ja siirrät tiedot sinne. Ja tarvitset puolitoista kertaa enemmän tilaa vanhoilla palvelimilla kuin nyt, koska vanhan datan on jäätävä niille ja puolet samasta vanhasta datasta tulee niiden päälle. Jos olet etukäteen ajatellut, että tiedot on jaettava uudelleen ja tilaa on, tämä menetelmä sopii.
Miten clickhouse-kopiokone toimii sisällä? Se jakaa kaiken työn tehtäviin yhden taulukon yhden osion käsittelemiseksi yhdellä sirpaleella. Kaikki nämä tehtävät voivat toimia rinnakkain, ja clickhouse-copier voi ajaa useita esiintymiä eri koneissa, mutta se, mitä se tekee yhdelle osiolle, on vain lisäysvalinta. Tiedot luetaan, puretaan, osioidaan uudelleen, sitten pakataan uudelleen, kirjoitetaan jonnekin, lajitellaan uudelleen. Tämä on vaikeampi päätös.
Sinulla oli pilottijuttu, jota kutsutaan uudelleensharkingiksi. Mitä hänen kanssaan?
Vuonna 2017 teillä oli pilottihanke, nimeltään resharding. ClickHousessa on jopa vaihtoehto. Ymmärtääkseni se ei lähtenyt liikkeelle. Voitko kertoa miksi näin kävi? Se näyttää olevan erittäin relevantti.
Koko ongelma on, että jos joudut sirottamaan tiedot uudelleen, tarvitaan erittäin monimutkainen synkronointi, jotta tämä voidaan tehdä atomisesti. Kun aloimme tarkastella tämän synkronoinnin toimintaa, kävi selväksi, että siinä on perustavanlaatuisia ongelmia. Ja nämä perusongelmat eivät ole vain teoreettisia, vaan ne alkoivat heti näkyä käytännössä sellaisena, joka voidaan selittää hyvin yksinkertaisesti - mikään ei toimi.
Onko mahdollista yhdistää kaikki tiedon osat yhteen ennen siirtymistä hitaille levyille?
Kysymys TTL:stä ja siirtymisestä hitaalle levylle yhdistämisen yhteydessä. Onko mitään muuta tapaa kuin cron yhdistää kaikki osat yhdeksi ennen siirtymistä hitaille levyille?
Vastaus kysymykseen, onko mahdollista liimata jotenkin automaattisesti kaikki palat yhdeksi ennen niiden siirtämistä, on ei. Minusta tämä ei ole välttämätöntä. Et voi yhdistää kaikkia osia yhdeksi, vaan luottaa vain siihen, että ne siirretään automaattisesti hitaille levyille.
Meillä on kaksi kriteeriä siirtosäännöille. Ensimmäinen on sellaisena kuin se on täytetty. Jos nykyisellä tallennustasolla on vähemmän kuin tietty prosenttiosuus vapaata tilaa, valitsemme yhden kappaleen ja siirrämme sen hitaampaan tallennustilaan. Tai pikemminkin, ei hitaampi, vaan seuraava - konfiguroinnin mukaan.
Toinen kriteeri on koko. Hän puhuu suurten kappaleiden siirrosta. Voit säätää kynnystä nopealla levyllä olevan vapaan tilan perusteella ja tiedot siirretään automaattisesti.
Kuinka siirtyä uusiin ClickHousen versioihin, jos yhteensopivuutta ei voi tarkistaa etukäteen?
Tästä aiheesta keskustellaan säännöllisesti eri versiot huomioon ottaen ja silti. Kuinka turvallista on päivittää versiosta 19.11 versioon 19.16 ja esimerkiksi versioon 19.16 versioon 20.3. Mikä on paras tapa siirtyä uusiin versioihin ilman, että voi tarkistaa yhteensopivuutta hiekkalaatikosta etukäteen?
Tässä on useita "kultaisia" sääntöjä. Ensimmäinen - . Se on suuri, mutta taaksepäin yhteensopimattomista muutoksista on erillisiä kohtia. Älä käsittele näitä esineitä punaisena lippuna. Nämä ovat yleensä pieniä yhteensopimattomuuksia, jotka liittyvät joihinkin reunatoimintoihin, joita et todennäköisesti käytä.
Toiseksi, jos yhteensopivuutta ei voi tarkistaa hiekkalaatikossa ja haluat päivittää heti tuotannossa, suositus on, että sinun ei tarvitse tehdä tätä. Luo ensin hiekkalaatikko ja testaa. Jos testiympäristöä ei ole, sinulla ei todennäköisesti ole kovin suurta yritystä, mikä tarkoittaa, että voit kopioida osan tiedoista kannettavaan tietokoneeseen ja varmistaa, että kaikki toimii oikein. Voit jopa nostaa useita kopioita paikallisesti koneellesi. Tai voit hankkia uuden version jostain läheltä ja ladata osan tiedoista sinne – eli luoda improvisoidun testiympäristön.
Toinen sääntö on, että päivitystä ei saa tehdä viikon sisällä version julkaisusta, koska tuotannossa havaitaan bugeja ja myöhempiä pikakorjauksia. Selvitetään ClickHouse-versioiden numerointi, jotta se ei mene sekaisin.
Siellä on versio 20.3.4. Numero 20 osoittaa valmistusvuoden - 2020. Sisällä olevan näkökulmasta tällä ei ole väliä, joten emme kiinnitä siihen huomiota. Seuraavaksi - 20.3. Suurennamme toista numeroa - tässä tapauksessa 3 - joka kerta, kun julkaisemme julkaisun jollakin uudella toiminnallisuudella. Jos haluamme lisätä jonkin ominaisuuden ClickHouseen, meidän on lisättävä tätä määrää. Eli versiossa 20.4 ClickHouse toimii vielä paremmin. Kolmas numero on 20.3.4. Tässä 4 on niiden korjaustiedostojen määrä, joihin emme lisänneet uusia ominaisuuksia, mutta korjasimme joitain virheitä. Ja 4 tarkoittaa, että teimme sen neljä kertaa.
Älä ajattele, että se on jotain kauheaa. Yleensä käyttäjä voi asentaa uusimman version ja se toimii ilman ongelmia käytettävyyden kanssa vuodessa. Mutta kuvittele, että jossain bittikarttojen käsittelytoiminnossa, jonka kiinalaiset toverimme ovat lisänneet, palvelin kaatuu, kun välitetään vääriä argumentteja. Meidän on korjattava tämä. Julkaisemme uuden korjausversion ja ClickHousesta tulee vakaampi.
Jos ClickHouse on käynnissä tuotannossa ja ClickHousesta julkaistaan uusi versio lisäominaisuuksineen - esimerkiksi 20.4.1 on aivan ensimmäinen, älä kiirehdi ottamaan sitä tuotantoon ensimmäisenä päivänä. Miksi sitä edes tarvitaan? Jos et vielä käytä ClickHousea, voit asentaa sen, ja todennäköisesti kaikki on hyvin. Mutta jos ClickHouse toimii jo vakaasti, seuraa korjaustiedostoja ja päivityksiä nähdäksesi, mitä ongelmia olemme korjaamassa.
Kirill Shvakov: Haluaisin lisätä hieman testiympäristöistä. Kaikki pelkäävät kovasti testiympäristöjä ja jostain syystä uskovat, että jos sinulla on erittäin suuri ClickHouse-klusteri, niin testiympäristön ei pitäisi olla pienempi tai vähintään kymmenen kertaa pienempi. Se ei ole ollenkaan niin.
Voin kertoa omalla esimerkilläni. Minulla on projekti ja siellä on ClickHouse. Testiympäristömme hänelle on pieni virtuaalikone Hetznerissä kahdellakymmenellä eurolla, jossa on käytössä aivan kaikki. Tätä varten meillä on täysi automaatio Ansiblessa, ja siksi periaatteessa ei ole eroa missä rullata - rautaisilla palvelimilla vai vain virtuaalikoneissa.
Mitä voidaan tehdä? Olisi mukavaa tehdä ClickHouse-dokumentaatiossa esimerkki pienen klusterin käyttöönotosta itse - Dockerissa, LXC:ssä, ehkä luoda Ansible-ohjekirja, koska eri ihmisillä on erilaisia käyttöönottoja. Tämä helpottaa monia asioita. Kun otat ja otat käyttöön klusterin viidessä minuutissa, on paljon helpompi yrittää keksiä jotain. Se on paljon kätevämpää tällä tavalla, koska sellaisen version vieminen tuotantoon, jota ei ole testattu, on tie minnekään. Joskus se toimii ja joskus ei. Ja siksi menestymisen toivominen on huonoa.
Maxim Kotyakov, vanhempi taustainsinööri Avito: Lisään hieman testiympäristöjä suurten yritysten kohtaamien ongelmien sarjasta. Meillä on täysi ClickHouse-hyväksyntäklusteri, joka on tietokaavioiltaan ja asetukseltaan tarkka kopio tuotannossa olevasta. Tämä klusteri on otettu käyttöön melko tyhjissä säiliöissä, joissa on mahdollisimman vähän resursseja. Kirjoitamme sinne tietyn prosenttiosuuden tuotantotiedoista, onneksi on mahdollista kopioida virta Kafkassa. Siellä kaikki on synkronoitua ja skaalattua - sekä kapasiteetin että virtauksen suhteen, ja teoriassa, kun kaikki muut asiat ovat samat, sen pitäisi käyttäytyä kuin tuotannon mittareilla. Kaikki mahdollisesti räjähtävä rullataan ensin tälle telineelle ja jätetään sinne useiksi päiviksi, kunnes se on valmis. Mutta luonnollisesti tämä ratkaisu on kallis, vaikea ja sen tukikustannukset eivät ole nolla.
Aleksei Milovidov: Kerron sinulle, millainen on Yandex.Metrican ystävämme testiympäristö. Yhdessä klusterissa oli noin 600 palvelinta, toisessa 360 ja on kolmas ja useita klustereita. Yhden niistä testiympäristö on vain kaksi sirpaletta, joissa kummassakin on kaksi kopiota. Miksi kaksi sirpaletta? Jotta ei olisi yksin. Ja myös jäljennöksiä. Vain pieni vähimmäissumma, johon sinulla on varaa.
Tämän testiympäristön avulla voit tarkistaa pyyntöjen kunnon ja onko jokin rikki isossa mielessä. Mutta usein ongelmat syntyvät täysin toisenlaisista, kun kaikki toimii, mutta kuormituksessa on pieniä muutoksia.
Annan sinulle esimerkin. Päätimme asentaa uuden version ClickHousesta. Se on asetettu testiympäristöön, itse Yandex.Metricassa läpäistään automaattiset testit, jotka vertaavat tietoja vanhasta versiosta ja uudesta versiosta, joka käyttää koko prosessia. Ja tietysti CI:n vihreät testit. Muuten emme olisi edes ehdottaneet tätä versiota.
Kaikki on hyvin. Aloitamme siirtymisen tuotantoon. Saan viestin, että kaavioiden kuormitus on kasvanut useita kertoja. Palautamme versiota. Katson kaaviota ja huomaan: kuormitus todellakin kasvoi useita kertoja käyttöönoton aikana ja pieneni takaisin käyttöönoton aikana. Sitten aloimme peruuttaa versiota. Ja kuorma kasvoi samalla tavalla ja putosi takaisin samalla tavalla. Johtopäätös on siis tämä - kuormitus on kasvanut laskennan yhteydessä, ei mitään yllättävää.
Sitten oli vaikea saada kollegoita asentamaan uusi versio. Sanon: "Ei hätää, rullaa ulos. Pidetään peukkuja, kaikki toimii. Nyt kuormitus on kasvanut kaavioissa, mutta kaikki on hyvin. Pidä kiinni." Yleensä teimme tämän, ja siinä se - versio on julkaistu tuotantopaikalla. Mutta melkein jokaisessa laskelmassa ilmenee samanlaisia ongelmia.
Kill-kyselyn pitäisi tappaa kyselyt, mutta se ei tapahdu. Miksi?
Käyttäjä tuli luokseni, jonkinlainen analyytikko, ja loi tietyn pyynnön, joka laittoi ClickHouse-klusterin. Jokin solmu tai koko klusteri sen mukaan, mihin replikaan tai sirpaleeseen pyyntö joutui. Näen, että kaikki tämän palvelimen CPU-resurssit ovat hyllyssä, kaikki on punaista. Samaan aikaan ClickHouse itse vastaa pyyntöihin. Ja minä kirjoitan: "Näytä minulle prosessiluettelo, mikä pyyntö aiheutti tämän hulluuden."
Löysin tämän pyynnön ja kirjoitan kill siihen. Ja näen, ettei mitään tapahdu. Palvelimeni on hyllyssä, ClickHouse antaa minulle komentoja, näyttää, että palvelin on elossa ja kaikki on hienoa. Mutta minulla on heikkeneminen kaikissa käyttäjien pyynnöissä, heikkeneminen alkaa ClickHousen tietueista, eikä tappamiskyselyni toimi. Miksi? Luulin, että tappamiskyselyn piti tappaa kyselyt, mutta se ei tapahdu.
Nyt tulee melko outo vastaus. Pointti on, että kill-kysely ei lopeta pyyntöjä.
Kill-kysely valitsee pienen ruudun nimeltä "Haluan, että tämä kysely lopetetaan". Ja itse pyyntö tarkastelee tätä lippua käsitellessään jokaista lohkoa. Jos se on asetettu, pyyntö lakkaa toimimasta. Osoittautuu, että kukaan ei tapa pyyntöä, hänen on itse tarkistettava kaikki ja lopetettava. Ja tämän pitäisi toimia kaikissa tapauksissa, joissa pyyntö on tietolohkojen käsittelytilassa. Se käsittelee seuraavan tietolohkon, tarkistaa lipun ja lopettaa.
Tämä ei toimi tapauksissa, joissa pyyntö on estetty jossain toiminnossa. Totta, todennäköisesti tämä ei ole sinun tapauksesi, koska sinun mukaan se käyttää paljon palvelinresursseja. On mahdollista, että tämä ei toimi ulkopuolisessa lajittelussa ja joissain muissa yksityiskohdissa. Mutta yleensä tämän ei pitäisi tapahtua, se on bugi. Ja ainoa asia, jota voin suositella, on ClickHousen päivittäminen.
Kuinka laskea vasteaika lukukuormituksessa?
Siellä on taulukko, joka tallentaa tuoteaggregaatit - erilaiset laskurit. Linjojen määrä on noin sata miljoonaa. Onko mahdollista luottaa ennustettavaan vasteaikaan, jos kaada 1 1 RPS XNUMX XNUMX tuotteelle?
Kontekstin perusteella puhumme lukukuormasta, koska kirjoittamisessa ei ole ongelmia - vähintään tuhat, vähintään satatuhatta ja joskus useita miljoonia rivejä voidaan lisätä.
Lukupyynnöt ovat hyvin erilaisia. Valikossa 1 ClickHouse voi suorittaa noin kymmeniä tuhansia pyyntöjä sekunnissa, joten jopa yhden avaimen pyynnöt vaativat jo jonkin verran resursseja. Ja tällaiset pistekyselyt ovat vaikeampia kuin joissakin avainarvotietokannassa, koska jokaista lukua varten on tarpeen lukea tietolohko indekseiltä. Hakemistomme ei koske kaikkia tietueita, vaan jokaista vaihteluväliä. Eli sinun on luettava koko alue - nämä ovat oletuksena 8192 riviä. Ja sinun on purettava pakattu tietolohko 64 kt:sta 1 megatavuun. Tyypillisesti tällaiset pistekyselyt kestävät muutamasta millisekunnista. Mutta tämä on helpoin vaihtoehto.
Kokeillaan yksinkertaista aritmetiikkaa. Jos kerrot muutaman millisekunnin tuhannella, saat muutaman sekunnin. Ikään kuin on mahdotonta pitää tuhatta pyyntöä sekunnissa, mutta itse asiassa se on mahdollista, koska meillä on useita prosessoriytimiä. Joten periaatteessa 1000 RPS ClickHouse voi joskus kestää, mutta lyhyillä pyynnöillä, nimittäin pisteillä.
Jos haluat skaalata ClickHouse-klusterin yksinkertaisten pyyntöjen lukumäärän mukaan, suosittelen yksinkertaisinta - lisää kopioiden määrää ja lähetä pyynnöt satunnaiseen replikaan. Jos yksi replika sisältää viisisataa pyyntöä sekunnissa, mikä on täysin realistista, niin kolmeen replikaan mahtuu puolitoista tuhatta.
Joskus tietysti voit myös määrittää ClickHousen enimmäismäärän pistelukemia. Mitä tähän tarvitaan? Ensimmäinen on vähentää indeksin tarkkuutta. Samalla sitä ei pidä pienentää yhteen, vaan sillä perusteella, että indeksin tietueiden määrä on useita miljoonia tai kymmeniä miljoonia palvelinta kohden. Jos taulukossa on sata miljoonaa riviä, 64 voidaan asettaa tarkkuusarvoksi.
Voit pienentää pakatun lohkon kokoa. Tätä varten on asetukset. min pakkauslohkon koko, enimmäispakkauslohkon koko. Niitä voidaan vähentää, täyttää uudelleen tiedoilla, jolloin kohdistetut kyselyt ovat nopeampia. Mutta silti, ClickHouse ei ole avainarvotietokanta. Suuri määrä pieniä pyyntöjä on kuormituksen vastakuvio.
Kirill Shvakov: Annan neuvoja, jos on tavallisia kirjanpitäjiä. Tämä on melko tavallinen tilanne, kun ClickHouseen on tallennettu jonkinlainen laskuri. Minulla on käyttäjä, hän on sellaisesta ja sellaisesta maasta, jostain muusta kolmannesta alasta, ja minun täytyy lisätä jotain asteittain. Ota MySQL, tee yksilöllinen avain - MySQL:ssä se on kaksoisavain, ja PostgreSQL:ssä se on ristiriita - ja lisää plusmerkki. Tämä toimii paljon paremmin.
Kun tietoja on vähän, ClickHousen käyttämisessä ei ole paljon järkeä. On olemassa säännöllisiä tietokantoja, ja ne tekevät hyvää työtä.
Mitä pitäisi säätää ClickHousessa, jotta välimuistissa olisi enemmän tietoja?
Kuvitellaanpa tilanne - palvelimissa on 256 Gt RAM-muistia, päivittäisessä rutiinissa ClickHouse vie noin 60-80 Gt, huipulla - jopa 130. Mitä voidaan ottaa käyttöön ja säätää niin, että välimuistissa on enemmän dataa ja vastaavasti , onko vähemmän matkoja levylle?
Yleensä käyttöjärjestelmän sivuvälimuisti tekee hyvää työtä tässä tehtävässä. Jos avaat vain yläosan, katsot sieltä välimuistissa tai vapaana - se kertoo myös kuinka paljon välimuistia on - niin näet, että kaikki vapaa muisti on käytetty välimuistiin. Ja kun luet näitä tietoja, niitä ei lueta levyltä, vaan RAM-muistista. Samalla voin sanoa, että välimuistia käytetään tehokkaasti, koska välimuistiin tallennetaan pakatut tiedot.
Jos kuitenkin haluat nopeuttaa joitain yksinkertaisia kyselyitä vielä enemmän, voit ottaa välimuistin käyttöön ClickHousen puretuissa tiedoissa. Sitä kutsutaan pakkaamaton välimuisti. Aseta config.xml-määritystiedostossa pakkaamattoman välimuistin koko tarvitsemaasi arvoon - suosittelen korkeintaan puolet vapaasta RAM-muistista, koska loput menevät sivun välimuistin alle.
Lisäksi on kaksi pyyntötason asetusta. Ensimmäinen asetus - käytä pakkaamatonta välimuistia - sisältää sen käytön. On suositeltavaa ottaa se käyttöön kaikissa pyynnöissä, paitsi raskaissa pyynnöissä, jotka voivat lukea kaikki tiedot ja tyhjentää tämän välimuistin. Ja toinen asetus on jotain kuin välimuistin käyttämien rivien enimmäismäärä. Se rajoittaa automaattisesti suuria pyyntöjä niin, että ne ovat välimuistin ohi.
Kuinka voin määrittää storage_configuration RAM-muistin tallennusta varten?
Uudesta ClickHouse-dokumentaatiosta luin asiaan liittyvän osion . Kuvaus sisältää esimerkin nopeasta SSD:stä.
Ihmettelen, kuinka sama asia voidaan konfiguroida volyymi kuumalla muistilla. Ja vielä yksi kysymys. Miten select toimii tämän tietoorganisaation kanssa, lukeeko se koko joukon vai vain levyllä olevan joukon ja pakataanko nämä tiedot muistiin? Ja miten prewhere-osio toimii tällaisen tietoorganisaation kanssa?
Tämä asetus vaikuttaa tietojen tallentamiseen, eikä niiden muoto muutu millään tavalla.
Katsotaanpa tarkemmin.
Voit määrittää tietojen tallennuksen RAM-muistiin. Levylle on määritetty vain sen polku. Luot tmpfs-osion, joka liitetään johonkin tiedostojärjestelmän polkuun. Määrität tämän polun tietojen tallennuspoluksi kuumimpaan osioon, dataa alkaa saapua ja kirjoittaa sinne, kaikki on hyvin.
Mutta en suosittele tämän tekemistä alhaisen luotettavuuden vuoksi, vaikka jos sinulla on vähintään kolme kopiota eri tietokeskuksissa, voit tehdä sen. Jos näin on, tiedot palautetaan. Kuvittele, että palvelin yhtäkkiä sammutettiin ja käynnistettiin uudelleen. Osio asennettiin uudelleen, mutta siinä on tyhjiö. ClickHouse-palvelin näkee käynnistyksen yhteydessä, että nämä osat puuttuvat, vaikka ZooKeeperin metatietojen mukaan niiden pitäisi olla. Hän katsoo, missä kopioissa ne ovat, pyytää niitä ja lataa ne. Näin tiedot palautetaan.
Tässä mielessä tietojen tallentaminen RAM-muistiin ei pohjimmiltaan eroa levylle tallentamisesta, koska kun tiedot kirjoitetaan levylle, se myös päätyy ensin sivun välimuistiin ja kirjoitetaan fyysisesti myöhemmin. Tämä riippuu tiedostojärjestelmän asennusvaihtoehdosta. Mutta varmuuden vuoksi sanon, että ClickHouse ei fsynkistä lisättäessä.
Tässä tapauksessa RAM-muistissa olevat tiedot tallennetaan täsmälleen samassa muodossa kuin levylle. Valintakysely valitsee luettavat osat samalla tavalla, valitsee tarvittavat tietoalueet paloista ja lukee ne. Ja prewhere toimii täsmälleen samalla tavalla riippumatta siitä, olivatko tiedot RAM-muistissa vai levyllä.
Mihin yksittäisiin arvoihin asti Low Cardinality on tehokas?
Matala kardinaliteetti on hankalaa. Se kokoaa datasanakirjoja, mutta ne ovat paikallisia. Ensinnäkin sanakirjat ovat erilaisia kullekin kappaleelle, ja toiseksi, jopa yhden kappaleen sisällä ne voivat olla erilaisia jokaiselle alueelle. Kun yksilöllisten arvojen määrä saavuttaa kynnyksen - mielestäni miljoona - sanakirja yksinkertaisesti jätetään sivuun ja luodaan uusi.
Vastaus on yleinen: jokaiselle paikalliselle alueelle - esimerkiksi jokaiselle päivälle - jossain jopa miljoona yksilöllistä arvoa, Low Cardinality on tehokas. Sen jälkeen tulee vain varmistus, jossa käytetään monia erilaisia sanakirjoja, ei vain yhtä. Se toimii paljolti samalla tavalla kuin tavallinen merkkijonotyyppinen sarake, ehkä hieman vähemmän tehokkaasti, mutta siinä ei tapahdu vakavaa suorituskyvyn heikkenemistä.
Mitkä ovat parhaat käytännöt kokotekstihaulle taulukossa, jossa on viisi miljardia riviä?
Vastauksia on erilaisia. Ensimmäinen on sanoa, että ClickHouse ei ole kokotekstihakukone. Tätä varten on olemassa erityisiä järjestelmiä, esim. и . Näen kuitenkin yhä enemmän ihmisiä, jotka sanovat siirtyvänsä Elasticsearchista ClickHouseen.
Miksi tämä tapahtuu? He selittävät tämän sillä, että Elasticsearch ei kestä joidenkin volyymien kuormitusta, alkaen indeksien rakentamisesta. Indekseistä tulee liian hankalia, ja jos tiedot yksinkertaisesti siirretään ClickHouseen, selviää, että ne tallentuvat monta kertaa tehokkaammin volyymin suhteen. Samaan aikaan hakukyselyt eivät usein olleet sellaisia, että koko tietomäärästä piti löytää jokin lause morfologia huomioon ottaen, vaan täysin erilaisia. Esimerkiksi löytääksesi lokeista muutaman tavun viimeiset tunnit.
Tässä tapauksessa luot ClickHousessa hakemiston, jonka ensimmäinen kenttä on päivämäärä ja aika. Ja suurin dataraja on tarkalleen ajanjaksolla. Valitun ajanjakson sisällä on pääsääntöisesti mahdollista tehdä kokotekstihaku jopa brute-force-menetelmällä likellä. ClickHousen samankaltainen lauseke on tehokkain samankaltainen lauseke, jonka voit löytää. Jos löydät paremman, kerro minulle.
Mutta silti, kuten on täysi skannaus. Ja täydellinen skannaus voi olla hidasta paitsi CPU:ssa myös levyllä. Jos yhtäkkiä sinulla on yksi teratavu dataa päivässä ja etsit sanaa päivässä, sinun on skannattava teratavu. Ja se on luultavasti tavallisilla kiintolevyillä, ja sen seurauksena ne ladataan siten, että et pääse tälle palvelimelle SSH:n kautta.
Tässä tapauksessa olen valmis tarjoamaan vielä yhden pienen tempun. Se on kokeellista – se saattaa toimia, ehkä ei. ClickHousessa on täystekstihakemistot trigrammin Bloom-suodattimien muodossa. Kollegamme Arenadassa ovat jo kokeilleet näitä indeksejä, ja ne toimivat usein täsmälleen tarkoitetulla tavalla.
Jotta voit käyttää niitä oikein, sinun tulee ymmärtää tarkasti, miten ne toimivat: mikä on trigram-kukintasuodatin ja kuinka valita sen koko. Voin sanoa, että ne auttavat kyselyissä joihinkin harvinaisiin lauseisiin, osamerkkijonoihin, joita tiedoista harvoin löytyy. Tässä tapauksessa alialueet valitaan indekseillä, ja vähemmän dataa luetaan.
Hiljattain ClickHouse on lisännyt entistä kehittyneempiä toimintoja koko tekstihakuun. Tämä on ensinnäkin joukon alimerkkijonojen etsimistä kerralla kerralla, mukaan lukien vaihtoehdot, joissa isot ja pienet kirjaimet ovat erottelevia, jotka tukevat UTF-8:aa tai vain ASCII:ta. Valitse tehokkain tarvitsemasi.
Haettiin myös useita säännöllisiä lausekkeita yhdellä kertaa. Sinun ei tarvitse kirjoittaa X:ää yhtenä osamerkkijonona tai X:tä toisena osamerkkijonona. Kirjoita heti, ja kaikki tehdään mahdollisimman tehokkaasti.
Kolmanneksi on nyt olemassa likimääräinen säännöllisten lausekkeiden haku ja alimerkkijonojen likimääräinen haku. Jos joku on kirjoittanut sanan väärin, siitä etsitään suurin vastaavuus.
Mikä on paras tapa järjestää ClickHousen pääsy suurelle käyttäjäjoukolle?
Kerro meille, kuinka parhaiten järjestää pääsy suurelle joukolle kuluttajia ja analyytikoita. Kuinka muodostaa jono, priorisoida enintään samanaikaiset kyselyt ja millä työkaluilla?
Jos klusteri on tarpeeksi suuri, niin hyvä ratkaisu olisi nostaa kaksi palvelinta lisää, joista tulee analyytikoiden sisääntulopaikka. Eli älä salli analyytikoiden käyttää tiettyjä klusterin sirpaleita, vaan luo vain kaksi tyhjää palvelinta ilman tietoja ja määritä niihin käyttöoikeudet. Tässä tapauksessa hajautettujen pyyntöjen käyttäjäasetukset siirretään etäpalvelimille. Eli määrität kaiken näillä kahdella palvelimella, ja asetuksilla on vaikutusta koko klusteriin.
Periaatteessa nämä palvelimet ovat ilman dataa, mutta niiden RAM-muistin määrä on erittäin tärkeä pyyntöjen suorittamisen kannalta. Levyä voidaan käyttää myös väliaikaiseen dataan, jos ulkoinen kokoaminen tai ulkoinen lajittelu on käytössä.
On tärkeää tarkastella asetuksia, jotka liittyvät kaikkiin mahdollisiin rajoituksiin. Jos menen nyt Yandex.Metrics-klusteriin analyytikkona ja asetan kyselyn valitse osumien määrä, silloin minulle annetaan välittömästi poikkeus, että en voi täyttää pyyntöä. Enimmäismäärä rivejä, joita voin skannata, on sata miljardia, ja klusterissa on yhdessä taulukossa yhteensä viisikymmentä biljoonaa. Tämä on ensimmäinen rajoitus.
Oletetaan, että poistan rivirajoituksen ja suoritan kyselyn uudelleen. Sitten näen seuraavan poikkeuksen - asetus käytössä pakottaa indeksi päivämäärän mukaan. En voi suorittaa kyselyä, jos en ole määrittänyt ajanjaksoa. Sinun ei tarvitse luottaa analyytikoihin syöttääksesi sen manuaalisesti. Tyypillinen tapaus - päivämääräalue kirjoitetaan, kun tapahtumapäivä on viikon välillä. Ja sitten he eivät vain määrittäneet hakasuljetta sinne, ja sen sijaan ja sen sijaan se osoittautui tai - tai URL-hauksi. Jos rajaa ei ole, se indeksoi URL-sarakkeen ja tuhlaa resursseja.
Lisäksi ClickHousessa on kaksi prioriteettiasetusta. Valitettavasti ne ovat hyvin alkeellisia. Yhtä kutsutaan yksinkertaisesti prioriteetti. Jos prioriteetti on ≠ 0 ja jonkin prioriteetin pyynnöt suoritetaan, mutta pyyntö, jonka prioriteettiarvo on pienempi, mikä tarkoittaa korkeampaa prioriteettia, suoritetaan, pyyntö, jonka prioriteettiarvo on suurempi kuin, mikä tarkoittaa alhaisempaa prioriteettia, on yksinkertaisesti keskeytetty, eikä se toimi ollenkaan tänä aikana.
Tämä on erittäin karkea asetus, eikä se sovellu tapauksiin, joissa klusterin kuormitus on jatkuva. Mutta jos sinulla on lyhyitä, räjähdysmäisiä pyyntöjä, jotka ovat tärkeitä ja klusteri on enimmäkseen käyttämättömänä, tämä asennus sopii.
Seuraava prioriteettiasetus kutsutaan Käyttöjärjestelmän säikeen prioriteetti. Se yksinkertaisesti paljastaa kaikki pyynnön suoritussäikeet mukavalle arvolle Linux-aikataululle. Toimii niin ja näin, mutta toimii silti. Jos asetat pienimmän mukavan arvon - se on suurin arvo ja siten alhaisin prioriteetti - ja asetat -19 korkean prioriteetin pyynnöille, CPU kuluttaa matalan prioriteetin pyyntöjä noin neljä kertaa vähemmän kuin korkean prioriteetin pyynnöt.
Sinun on myös asetettava kyselyn enimmäissuoritusaika - esimerkiksi viisi minuuttia. Pyynnön vähimmäissuoritusnopeus on siistein asia. Tämä asetus on ollut olemassa jo pitkään, ja sitä vaaditaan paitsi vakuuttamaan, että ClickHouse ei hidasta, myös pakottamaan sitä.
Kuvittele, että määrität: jos kysely käsittelee alle miljoona riviä sekunnissa, et voi tehdä tätä. Tämä häpäisee hyvää nimeämme, hyvää tietokantaamme. Kielletään se. Itse asiassa on kaksi asetusta. Yksi kutsutaan min suoritusnopeus - rivillä sekunnissa, ja sekuntia kutsutaan aikakatkaisuksi ennen minimisuoritusnopeuden tarkistamista - oletusarvoisesti viisitoista sekuntia. Eli viisitoista sekuntia on mahdollista, ja sitten, jos hitaasti, tee vain poikkeus - keskeytä pyyntö.
Sinun on myös määritettävä kiintiöt. ClickHousessa on sisäänrakennettu kiintiöominaisuus, joka laskee resurssien kulutuksen. Mutta valitettavasti eivät laitteistoresurssit, kuten CPU, levyt, vaan loogiset - käsiteltyjen pyyntöjen, luettujen rivien ja tavujen määrä. Ja voit määrittää esimerkiksi enintään sata pyyntöä viiden minuutin sisällä ja tuhat pyyntöä tunnissa.
Miksi se on tärkeää? Koska osa analytiikkapyynnöistä suoritetaan manuaalisesti suoraan ClickHouse-asiakasohjelmasta. Ja kaikki tulee olemaan hyvin. Mutta jos yrityksessäsi on edistyneitä analyytikoita, he kirjoittavat käsikirjoituksen, ja siinä voi olla virhe. Ja tämä virhe aiheuttaa pyynnön suorittamisen äärettömässä silmukassa. Tätä on suojeltava.
Onko mahdollista antaa yhden pyynnön tulokset kymmenelle asiakkaalle?
Meillä on useita käyttäjiä, jotka haluavat tulla sisään erittäin suurilla pyynnöillä samaan aikaan. Pyyntö on suuri, periaatteessa se toteutetaan nopeasti, mutta koska tällaisia pyyntöjä on useita samanaikaisesti, siitä tulee erittäin tuskallista. Onko mahdollista suorittaa sama pyyntö, joka saapui kymmenen kertaa peräkkäin, kerran ja antaa tuloksen kymmenelle asiakkaalle?
Ongelmana on, että meillä ei ole välimuistituloksia tai välimuistia. Käyttöjärjestelmässä on sivuvälimuisti, jonka avulla et voi lukea tietoja levyltä uudelleen, mutta valitettavasti tiedot puretaan, sarjoitetaan ja käsitellään uudelleen.
Haluaisin jotenkin välttää tämän, joko tallentamalla välitiedot välimuistiin tai asettamalla samanlaiset kyselyt johonkin jonoon ja lisäämällä tulosten välimuisti. Nyt meillä on kehitteillä yksi vetopyyntö, joka lisää pyyntövälimuistin, mutta vain in- ja join-osioiden alipyynnöille - eli ratkaisu on huonompi.
Meillä on kuitenkin myös tällainen tilanne. Erityisen kanoninen esimerkki ovat sivutetut kyselyt. On raportti, siinä on useita sivuja, ja siellä on pyyntö rajalle 10. Sitten sama asia, mutta raja 10,10. Sitten seuraava sivu. Ja kysymys kuuluu, miksi laskemme tämän kaiken joka kerta? Mutta nyt ei ole ratkaisua, eikä sitä voi välttää.
On olemassa vaihtoehtoinen ratkaisu, joka on sijoitettu sivuvaunuksi ClickHousen viereen - .
Kirill Shvakov: ClickHouse Proxyssa on sisäänrakennettu nopeuden rajoitin ja sisäänrakennettu tulosvälimuisti. Siellä on tehty paljon asetuksia, koska vastaava tehtävä ratkesi. Välityspalvelimen avulla voit rajoittaa pyyntöjä asettamalla ne jonoon ja määrittää, kuinka kauan pyyntövälimuisti kestää. Jos pyynnöt olivat todella samat, välityspalvelin antaa ne useita kertoja ja siirtyy ClickHouseen vain kerran.
Nginxillä on myös välimuisti ilmaisessa versiossa, ja tämäkin toimii. Nginxillä on jopa asetukset, jotka jos pyynnöt saapuvat samaan aikaan, se hidastaa muita, kunnes yksi on valmis. Mutta juuri ClickHouse Proxyssa asennus on tehty paljon paremmin. Se on tehty nimenomaan ClickHouselle, erityisesti näitä pyyntöjä varten, joten se on sopivampi. No, se on helppo asentaa.
Entä asynkroniset toiminnot ja toteutuneet näkymät?
Ongelmana on, että toistomoottorin toiminnot ovat asynkronisia - ensin kirjoitetaan tiedot, sitten se romahtaa. Jos materialisoitu tabletti, jossa on joitain aggregaatteja, asuu merkin alla, siihen kirjoitetaan kaksoiskappaleet. Ja jos monimutkaista logiikkaa ei ole, tiedot monistetaan. Mitä voit tehdä asialle?
On olemassa ilmeinen ratkaisu - liipaisimen toteuttaminen tietyssä matview-luokassa asynkronisen tiivistyksen aikana. Onko olemassa "hopealuoteja" suunnitelmia tällaisen toiminnon toteuttamiseksi?
On syytä ymmärtää, miten duplikointi toimii. Se, mitä aion sanoa, ei liity kysymykseen, mutta se kannattaa muistaa varmuuden vuoksi.
Kun lisäät kopioituun taulukkoon, kaikki lisätyt lohkot poistetaan. Jos lisäät uudelleen saman lohkon, joka sisältää saman määrän samoja rivejä samassa järjestyksessä, tiedot poistetaan. Saat "Ok" vastauksena lisäykseen, mutta yksi tietoerä todella kirjoitetaan, eikä sitä kopioida.
Tämä on välttämätöntä varmuuden vuoksi. Jos saat "Ok" lisäyksen aikana, tietosi on lisätty. Jos saat virheilmoituksen ClickHouselta, niitä ei ole lisätty, ja sinun on toistettava lisäys. Mutta jos yhteys katkeaa lisäyksen aikana, et tiedä, onko tiedot lisätty vai ei. Ainoa vaihtoehto on toistaa lisäys uudelleen. Jos tiedot on todella lisätty ja lisäsit ne uudelleen, päällekkäisyyksiä poistetaan. Tämä on tarpeen päällekkäisyyksien välttämiseksi.
Ja on myös tärkeää, miten se toimii materialisoituneiden näkemysten kohdalla. Jos tiedot on poistettu päätaulukkoon lisättäessä, ne eivät myöskään mene materialisoituun näkymään.
Nyt kysymykseen. Tilanteesi on monimutkaisempi, koska tallennat yksittäisten rivien kaksoiskappaleita. Toisin sanoen koko paketti ei kopioidu, vaan tietyt rivit, jotka romahtavat taustalla. Tieto todellakin kutistuu päätaulukossa, mutta tiivistämätön data siirtyy materialisoituneeseen näkymään, eikä yhdistämisen aikana tapahdu materialisoituneille näkymille mitään. Koska materialisoitunut näkymä ei ole mitään muuta kuin väliin liipaisin. Muiden toimintojen aikana sille ei tapahdu mitään ylimääräistä.
Ja en voi olla onnellinen täällä. On vain tarpeen etsiä erityinen ratkaisu tähän tapaukseen. Onko se esimerkiksi mahdollista korvata materialisoidussa näkymässä, ja duplikointimenetelmä toimii ehkä samalla tavalla. Mutta valitettavasti ei aina. Jos se aggregoidaan, se ei toimi.
Kirill Shvakov: Meillä oli myös luun rakentaminen aikanaan. Ongelmana oli mainosten näyttökerrat ja joitain tietoja, jotka voimme näyttää reaaliajassa - nämä ovat vain näyttökertoja. Niitä kopioidaan harvoin, mutta jos näin tapahtuu, romutamme ne joka tapauksessa. Ja oli asioita, joita ei voi kopioida - napsautukset ja koko tämä tarina. Mutta halusin myös näyttää ne melkein heti.
Miten toteutuneet näkemykset syntyivät? Oli näkymiä, joissa se kirjoitettiin suoraan - se kirjoitettiin raakadataan ja kirjoitettiin näkymiin. Siellä jossain vaiheessa tiedot eivät ole kovin oikeita, ne ovat päällekkäisiä ja niin edelleen. Ja on taulukon toinen osa, jossa ne näyttävät täsmälleen samalta kuin materialisoidut näkymät, eli ne ovat rakenteeltaan täysin identtisiä. Välillä laskemme tiedot uudelleen, laskemme tiedot ilman kaksoiskappaleita, kirjoitamme niihin taulukoihin.
Kävimme API:n läpi - tämä ei toimi ClickHousessa käsin. Ja API näyttää: kun minulla on viimeisen lisäyksen päivämäärä taulukkoon, jossa varmistetaan, että oikeat tiedot on jo laskettu, ja se tekee pyynnön yhteen taulukkoon ja toiseen taulukkoon. Yhdestä pyynnöstä valitsee tietyn ajan, ja toisesta se saa sen, mitä ei ole vielä laskettu. Ja se toimii, mutta ei yhden ClickHousen avulla.
Jos sinulla on jonkinlainen API - analyytikoille, käyttäjille - niin periaatteessa tämä on vaihtoehto. Lasket aina, aina lasket. Tämä voidaan tehdä kerran päivässä tai johonkin muuhun aikaan. Valitset itsellesi valikoiman, jota et tarvitse ja joka ei ole kriittinen.
ClickHousella on paljon lokeja. Kuinka voin nähdä kaiken, mitä palvelimelle tapahtuu yhdellä silmäyksellä?
ClickHousessa on erittäin suuri määrä erilaisia lokeja, ja tämä määrä on kasvussa. Uusissa versioissa osa niistä on jopa oletusarvoisesti käytössä, vanhemmissa versioissa ne on otettava käyttöön päivityksen yhteydessä. Niitä on kuitenkin yhä enemmän. Haluaisin vihdoin nähdä, mitä palvelimelleni tapahtuu nyt, ehkä jossain yhteenvetonäytössä.
Onko sinulla ClickHouse-tiimissäsi tai ystäviesi tiimeissä, jotka tukevat joitain valmiiden hallintapaneelien toimintoja, jotka näyttäisivät nämä lokit valmiina tuotteena? Loppujen lopuksi pelkkä lokien katsominen ClickHousessa on hienoa. Mutta olisi erittäin siistiä, jos se olisi jo valmistettu kojelaudan muodossa. Saisin potkun tästä.
Kojelaudat ovat olemassa, vaikka ne eivät ole standardoituja. Yrityksessämme on noin 60 ClickHouse-tiimiä, ja kummallisinta on, että monilla heistä on itse tekemiä kojetauluja, ja vähän erilaisia. Jotkut tiimit käyttävät sisäistä Yandex.Cloudin asennusta. Joitakin valmiita raportteja on, vaikkakaan ei kaikkia tarpeellisia. Toisilla on omansa.
Metrican kollegoillani on oma kojelauta Grafanassa, ja minulla omani heidän omaan klusteriinsa. Tarkastelen asioita, kuten välimuistiosuma serif-välimuistille. Ja vielä vaikeampaa on, että käytämme erilaisia työkaluja. Tein kojelautani hyvin vanhalle työkalulle nimeltä Graphite-web. Hän on täysin ruma. Ja käytän sitä edelleenkin sillä tavalla, vaikka Grafana olisi luultavasti kätevämpi ja kauniimpi.
Perusasia kojelaudoissa on sama. Nämä ovat klusterin järjestelmämittareita: CPU, muisti, levy, verkko. Muut - samanaikaisten pyyntöjen määrä, samanaikaisten yhdistämisten määrä, pyyntöjen määrä sekunnissa, MergeTree-taulukkoosioiden osien enimmäismäärä, replikointiviive, replikointijonon koko, lisättyjen rivien määrä sekunnissa, lisättyjen lohkojen määrä sekunnissa. Tämä on kaikki, mitä ei saada lokeista, vaan mittareista.
Vladimir Kolobaev: Aleksei, haluaisin oikaista hieman. Siellä on Grafana. Grafanalla on tietolähde, joka on ClickHouse. Eli voin tehdä pyyntöjä Grafanasta suoraan ClickHouselle. ClickHousessa on lokit sisältävä taulukko, joka on sama kaikille. Tämän seurauksena haluan käyttää tätä lokitaulukkoa Grafanassa ja nähdä palvelimeni soveltamat pyynnöt. Olisi hienoa saada tällainen kojelauta.
Itse pyöräilin. Mutta minulla on kysymys - jos se kaikki on standardoitua ja kaikki käyttävät Grafanaa, miksi Yandexillä ei ole tällaista virallista kojelautaa?
Kirill Shvakov: Itse asiassa ClickHousen tietolähde tukee nyt Altinityä. Ja haluan vain antaa vektorin siitä, mistä kaivaa ja ketä työntää. Voit kysyä heiltä, koska Yandex tekee edelleen ClickHousea, ei sitä ympäröivää tarinaa. Altinity on tällä hetkellä tärkein ClickHousea mainostava yritys. He eivät hylkää häntä, vaan tukevat häntä. Koska periaatteessa, jotta voit ladata kojelaudan Grafana-verkkosivustolle, sinun tarvitsee vain rekisteröityä ja ladata se - ei ole erityisiä ongelmia.
Aleksei Milovidov: Viime vuoden aikana ClickHouse on lisännyt paljon kyselyn profilointiominaisuuksia. Jokaiselle resurssin käyttöpyynnölle on olemassa mittareita. Ja äskettäin on lisätty vielä alemman tason kyselyprofiili, joka näyttää, mihin kysely kuluu millisekunnin välein. Mutta käyttääkseni tätä toimintoa, minun on avattava konsoliasiakas ja kirjoitettava kysely, jonka unohdan jatkuvasti. Tallensin sen jonnekin ja unohdan aina missä tarkalleen.
Toivon, että olisi työkalu, joka sanoo vain - tässä ovat raskaat kyselysi ryhmiteltynä kyselyluokan mukaan. Napsautin yhtä, ja he sanoivat minulle, että se on siksi raskas. Nyt sellaista ratkaisua ei ole. Ja on todella outoa, että kun ihmiset kysyvät minulta: "Kerro minulle, onko Grafanalle valmiita kojetauluja?" Kostyanilta. En tiedä mikä se on, en ole itse käyttänyt sitä."
Kuinka vaikuttaa merdzhiin, jotta palvelin ei joutuisi OOM:iin?
Minulla on taulukko, taulukossa on vain yksi osio, se on ReplaceingMergeTree. Olen kirjoittanut siihen dataa neljä vuotta. Minun piti tehdä siihen muutos ja poistaa joitakin tietoja.
Tein tämän, ja tämän pyynnön käsittelyn aikana kaikki klusterin palvelimien muisti kulutettiin ja kaikki klusterin palvelimet menivät OOM:iin. Sitten he kaikki nousivat yhdessä, alkoivat yhdistää tätä samaa operaatiota, tätä tietolohkoa ja putosivat jälleen OOM:iin. Sitten he nousivat uudelleen ja putosivat jälleen. Ja tämä asia ei pysähtynyt.
Sitten kävi ilmi, että tämä on itse asiassa bugi, jonka kaverit korjasivat. Tämä on erittäin siistiä, kiitos paljon. Mutta jäännös jäi. Ja nyt, kun ajattelen tarvetta tehdä tietty yhdistäminen taulukossa, minulla on kysymys - miksi en voi ottaa näitä yhdistämiä ja vaikuttaa niihin jotenkin? Rajoita niitä esimerkiksi vaaditulla RAM-muistin määrällä tai periaatteessa niiden lukumäärällä, joka käsittelee tämän taulukon.
Minulla on taulukko nimeltä "Metrics", käsittele se minulle kahdessa streamissa. Ei tarvitse tuottaa kymmentä tai viittä yhdistämistä rinnakkain, tee se kahdessa. Luulen, että kahdessa minulla on tarpeeksi muistia, mutta se ei ehkä riitä käsittelemään kymmentä. Miksi pelko säilyy? Koska taulukko kasvaa, ja jonain päivänä kohtaan tilanteen, joka ei periaatteessa johdu enää bugista, vaan siitä, että tiedot muuttuvat niin paljon, että minulla ei yksinkertaisesti ole tarpeeksi muistia palvelin. Ja sitten palvelin joutuu OOM:iin yhdistämisen aikana. Lisäksi voin peruuttaa mutaation, mutta yhdistäminen on poissa.
Tiedäthän, että yhdistämisen yhteydessä palvelin ei joudu OOM:iin, koska yhdistämisen yhteydessä RAM-muistia käytetään vain yhdelle pienelle tietoalueelle. Joten kaikki menee hyvin datamäärästä riippumatta.
Vladimir Kolobaev: Hieno. Tässä hetki on sellainen, että kun teimme virheenkorjauksen, latasin itselleni uuden version ja toisessa pöydässä, pienemmässä, jossa on paljon osioita, tein samanlaisen toimenpiteen. Ja yhdistämisen aikana palvelimelle poltettiin noin 100 Gt RAM-muistia. Minulla oli 150 kiirettä, söin 100 ja 50 Gt:n ikkuna oli jäljellä, joten en pudonnut OOM:iin.
Mikä tällä hetkellä suojaa minua joutumasta OOM:iin, jos se todella kuluttaa 100 Gt RAM-muistia? Mitä tehdä, jos yhdistämisen RAM-muisti loppuu yhtäkkiä?
Aleksei Milovidov: On olemassa sellainen ongelma, että RAM-muistin kulutus ei rajoitu merdzhiin. Ja toinen ongelma on, että jos yhdistäminen on määritetty, se on suoritettava, koska se kirjoitetaan replikointilokiin. Replikointiloki on toiminnot, joita tarvitaan replikan saattamiseksi yhdenmukaiseen tilaan. Jos et tee manuaalisia käsittelyjä, jotka tämä replikointiloki palauttaa, yhdistäminen on suoritettava tavalla tai toisella.
Tietenkään ei olisi tarpeetonta rajoittaa RAM-muistia, joka "varmuuden vuoksi" suojaa OOM:lta. Se ei auta yhdistämistä, se käynnistyy uudelleen, saavuttaa jonkin kynnyksen, tekee poikkeuksen ja aloittaa sitten uudelleen - siitä ei tule mitään hyvää. Mutta periaatteessa tämä rajoitus olisi hyödyllistä.
Miten Golang-ajurin kehitys ClickHouselle tapahtuu?
Kirill Shvakovin kirjoittamaa Golang-ohjainta tukee nyt virallisesti ClickHouse-tiimi. Hän , hän on nyt iso ja todellinen.
Pieni huomautus. Siellä on upea ja rakastettu arkisto äärettömän järjestyksen normaaleista muodoista - tämä on Vertica. Heillä on myös oma virallinen python-ajuri, jota Vertica-kehittäjät ylläpitävät. Ja useita kertoja tapahtui, että tallennustilan versiot ja ajurin versiot erosivat melko äkillisesti, ja ajuri lakkasi toimimasta jossain vaiheessa. Ja toinen hetki. Minusta näyttää siltä, että "nänni"-järjestelmä ylläpitää tukea tälle viralliselle ohjaimelle - kirjoitat heille ongelman, ja se roikkuu ikuisesti.
Minulla on kaksi kysymystä. Nyt Kirillin Golang-ohjain on lähes oletustapa kommunikoida Golangista ClickHousen kanssa. Ellei joku edelleen kommunikoi http-käyttöliittymän kautta, koska hän pitää siitä niin paljon. Miten tätä ajuria kehitetään? Synkronoidaanko se joidenkin rikkovien muutosten kanssa itse arkistossa? Ja mikä on menettelytapa asian käsittelyssä?
Kirill Shvakov: Ensimmäinen on se, miten kaikki on järjestetty byrokraattisesti. Tätä kohtaa ei käsitelty, joten minulla ei ole mitään vastausta.
Jotta voimme vastata ongelmaa koskevaan kysymykseen, tarvitsemme vähän kuljettajan historiaa. Työskentelin yrityksessä, jolla oli paljon dataa. Se oli mainospyörä, jossa oli valtava määrä tapahtumia, jotka piti tallentaa jonnekin. Ja jossain vaiheessa ClickHouse ilmestyi. Kaatoimme siihen dataa, ja aluksi kaikki oli hyvin, mutta sitten ClickHouse kaatui. Tuolloin päätimme, että emme tarvitse sitä.
Vuotta myöhemmin palasimme ajatukseen ClickHousen käytöstä, ja meidän piti jotenkin kirjoittaa tietoja sinne. Syöte oli tämä - rauta on erittäin heikko, resursseja on vähän. Mutta olemme aina toimineet tällä tavalla, ja siksi katsoimme alkuperäistä protokollaa kohti.
Koska työskentelimme Golla, oli selvää, että tarvitsemme Go-ajurin. Tein sen melkein kokopäiväisesti - se oli työtehtäväni. Tiettyyn pisteeseen asti otimme sen esille, eikä periaatteessa kukaan odottanut jonkun muun kuin me käyttävän sitä. Sitten tuli CloudFlare täsmälleen saman ongelman kanssa, ja jonkin aikaa työskentelimme heidän kanssaan erittäin sujuvasti, koska heillä oli samat tehtävät. Ja teimme sen sekä itse ClickHousessa että ohjaimessa.
Jossain vaiheessa lopetin sen tekemisen, koska toimintani ClickHousen ja työn suhteen muuttui hieman. Siksi asioita ei ole suljettu. Ajoittain ihmiset, jotka tarvitsevat jotain itse, sitoutuvat arkistoon. Sitten katson vetopyyntöä ja joskus jopa muokkaan jotain itse, mutta tätä tapahtuu harvoin.
Haluan palata kuljettajan luo. Muutama vuosi sitten, kun tämä koko juttu alkoi, ClickHouse oli myös erilainen ja eri ominaisuuksilla. Nyt on ymmärrys siitä, kuinka kuljettaja tehdään uudelleen niin, että se on hyvä. Jos näin tapahtuu, versio 2 on joka tapauksessa yhteensopimaton kertyneen kainalosauvojen vuoksi.
En tiedä miten tämän järjestäisin. Itselläni ei ole paljoa aikaa. Jos jotkut ihmiset lopettavat kuljettajan, voin auttaa heitä ja kertoa heille, mitä tehdä. Mutta Yandexin aktiivista osallistumista projektin kehittämiseen ei ole vielä keskusteltu millään tavalla.
Aleksei Milovidov: Itse asiassa näihin kuljettajiin ei vielä liity byrokratiaa. Ainoa asia on, että ne toimitetaan viralliselle organisaatiolle, toisin sanoen tämä ohjain tunnustetaan Go:n viralliseksi oletusratkaisuksi. Muitakin ohjaimia on, mutta ne tulevat erikseen.
Meillä ei ole mitään kehitystä näille kuljettajille sisällä. Kysymys kuuluu, voimmeko palkata yksittäisen henkilön, ei nimenomaan tälle kuljettajalle, vaan kaikkien yhteisön kuljettajien kehittämiseen, vai voimmeko löytää jonkun ulkopuolelta.
Ulkoinen sanakirja ei lataudu uudelleenkäynnistyksen jälkeen, kun lazy_load-asetus on käytössä. Mitä tehdä?
Lazy_load-asetus on käytössä, ja palvelimen uudelleenkäynnistyksen jälkeen sanakirja ei nouse. Se nostetaan esiin vasta, kun käyttäjä käyttää tätä sanakirjaa. Ja se antaa virheilmoituksen ensimmäisessä puhelussa. Onko mahdollista ladata sanakirjoja jotenkin automaattisesti ClickHousen avulla, vai pitääkö niiden valmiutta aina valvoa itse, jotta käyttäjät eivät saa virheitä?
Ehkä meillä on vanha versio ClickHousesta, joten sanakirja ei latautunut automaattisesti. Voisiko asia olla näin?
Ensinnäkin sanakirjat voidaan pakottaa lataamaan kyselyn avulla järjestelmän uudelleenlataussanakirjat. Toiseksi virheestä - jos sanakirja on jo ladattu, kyselyt toimivat ladatuilla tiedoilla. Jos sanakirjaa ei ole vielä ladattu, se ladataan heti pyynnön yhteydessä.
Raskaille sanakirjoille tämä ei ole kovin kätevää. Sinun on esimerkiksi haettava miljoona riviä MySQL:stä. Joku tekee yksinkertaisen valinnan, mutta tämä valinta odottaa samaa miljoonaa riviä. Tässä on kaksi ratkaisua. Ensimmäinen on kytkeä lazy_load pois päältä. Toinen on, kun palvelin nousee, ennen kuin kytket sen kuormituksen päälle järjestelmän uudelleenlataussanakirja tai vain suorita kysely, joka käyttää sanakirjaa. Sitten sanakirja ladataan. Sinun täytyy hallita sanakirjojen saatavuutta lazy_load-asetuksen ollessa käytössä, koska ClickHouse ei nosta niitä ylös automaattisesti.
Vastaus viimeiseen kysymykseen on, että versio on vanha tai se on korjattava.
Entä se, että järjestelmän uudelleenlataussanakirjat eivät lataa mitään monista sanakirjoista, jos ainakin yksi niistä kaatuu virheen vuoksi?
Toinen kysymys koskee järjestelmän uudelleenlataussanakirjoja. Meillä on kaksi sanakirjaa - yksi ei lataudu, toinen on ladattu. Järjestelmän uudelleenlataussanakirjat eivät tässä tapauksessa lataa mitään sanakirjaa, ja sinun on ladattava pisteestä pisteeseen tietty sanakirja sen nimellä käyttämällä järjestelmän uudelleenlataussanakirjaa. Liittyykö tämä myös ClickHouse-versioon?
Haluan miellyttää. Tämä käyttäytyminen on muuttunut. Joten jos päivität ClickHousen, se myös muuttuu. Jos et ole tyytyväinen nykyiseen käyttäytymiseen järjestelmän uudelleenlataussanakirjat, päivitä, ja toivotaan, että se muuttuu parempaan suuntaan.
Onko olemassa tapaa määrittää tiedot ClickHouse-konfiguraatiossa, mutta ei sytyttää niitä virheiden varalta?
Seuraava kysymys koskee sanakirjaan liittyviä virheitä, nimittäin yksityiskohtia. Olemme määrittäneet yhteystiedot sanakirjan ClickHouse-konfiguraatiossa, ja jos tapahtuu virhe, saamme vastauksena nämä tiedot ja salasanan.
Ratkaisimme tämän virheen lisäämällä tietoja ODBC-ohjaimen konfiguraatioon. Onko mitään tapaa määrittää tiedot ClickHouse-konfiguraatiossa, mutta ei näytä näitä tietoja virheissä?
Todellinen ratkaisu tässä on määrittää nämä valtuustiedot tiedostossa odbc.ini, ja itse ClickHousessa määritetään vain ODBC-tietolähteen nimi. Näin ei tapahdu muille sanakirjalähteille - ei MySQL-sanakirjalle eikä muillekaan, salasanaa ei pitäisi nähdä, kun saat virheilmoituksen. Katson myös ODBC:tä - jos se on olemassa, sinun on vain poistettava se.
Bonus: taustoja Zumalle tapaamisista
Klikkaamalla kuvaa sinnikkimmille lukijoille aukeavat bonustaustat kokoontumisista. Tulipalon sammuttaminen yhdessä Aviton teknologia-maskottien kanssa, neuvotteleminen kollegoiden kanssa järjestelmänvalvojan huoneesta tai vanhan koulun tietokonekerhosta ja päivän pitäminen sillan alla graffitien taustalla.
Lähde: will.com