Meqenëse ClickHouse është një sistem i specializuar, gjatë përdorimit të tij është e rëndësishme të merren parasysh veçoritë e arkitekturës së tij. Në këtë raport, Alexey do të flasë për shembuj të gabimeve të zakonshme kur përdorni ClickHouse, të cilat mund të çojnë në punë joefektive. Shembujt praktikë do të tregojnë se si zgjedhja e një skeme të përpunimit të të dhënave mund të ndryshojë performancën sipas rendit të madhësisë.
Pershendetje te gjitheve! Emri im është Alexey, unë bëj ClickHouse.
Së pari, unë nxitoj t'ju kënaq menjëherë, sot nuk do t'ju tregoj se çfarë është ClickHouse. Të them të drejtën, jam lodhur nga kjo. Sa herë që ju them se çfarë është. Dhe ndoshta të gjithë tashmë e dinë.
Në vend të kësaj, unë do t'ju tregoj se cilat gabime të mundshme ka, domethënë se si mund ta përdorni gabimisht ClickHouse. Në fakt, nuk ka nevojë të kesh frikë, sepse ne po zhvillojmë ClickHouse si një sistem që është i thjeshtë, i përshtatshëm dhe funksionon jashtë kutisë. E instalova, nuk ka probleme.
Por ende duhet të keni parasysh që ky sistem është i specializuar dhe lehtë mund të hasni në një rast përdorimi të pazakontë që do ta nxjerrë këtë sistem nga zona e tij e rehatisë.
Pra, çfarë lloj rakete ka? Kryesisht do të flas për gjëra të dukshme. Gjithçka është e qartë për të gjithë, të gjithë kuptojnë gjithçka dhe mund të jenë të lumtur që janë kaq të zgjuar, dhe ata që nuk kuptojnë do të mësojnë diçka të re.
Shembulli i parë dhe më i thjeshtë, i cili, për fat të keq, ndodh shpesh, është një numër i madh insertesh me tufa të vogla, pra një numër i madh futjesh të vogla.
Nëse marrim parasysh se si ClickHouse kryen futjen, atëherë mund të dërgoni të paktën një terabajt të dhënash në një kërkesë. Nuk është problem.
Dhe le të shohim se cila do të ishte performanca tipike. Për shembull, ne kemi një tabelë nga të dhënat Yandex.Metrica. Hitet. 105 disa kolona. 700 bajt të pakompresuara. Dhe ne do të fusim në mënyrë të mirë në grupe prej një milion rreshtash.
Ne futim MergeTree në tabelë, rezulton gjysmë milioni rreshta në sekondë. E madhe. Në një tabelë të përsëritur do të jetë pak më e vogël, afërsisht 400 rreshta në sekondë.
Dhe nëse aktivizoni futjen e kuorumit, ju merrni pak më pak, por gjithsesi performancë të mirë, 250 terma për sekondë. Futja e kuorumit është një veçori e padokumentuar në ClickHouse*.
* Që nga viti 2020, .
Çfarë ndodh nëse bëni diçka të keqe? Fusim një rresht në tabelën MergeTree dhe marrim 59 rreshta për sekondë. Kjo është 10 herë më ngadalë. Në ReplicatedMergeTree – 000 rreshta për sekondë. Dhe nëse kuorumi është i ndezur, atëherë rezulton 6 rreshta në sekondë. Sipas mendimit tim, kjo është një lloj katrahure absolute. Si mund të ngadalësosh kështu? Unë madje e kam të shkruar në bluzën time që ClickHouse nuk duhet të ngadalësojë. Por megjithatë ndonjëherë ndodh.
Në fakt, kjo është e meta jonë. Mund të kishim bërë lehtësisht gjithçka të funksiononte mirë, por nuk e bëmë. Dhe ne nuk e bëmë sepse skenari ynë nuk e kërkonte atë. Tashmë kishim kasapë. Sapo morëm tufa në hyrje dhe pa asnjë problem. Ne e futim atë dhe gjithçka funksionon mirë. Por, sigurisht, të gjitha llojet e skenarëve janë të mundshëm. Për shembull, kur keni një grup serverësh në të cilët gjenerohen të dhënat. Dhe ata nuk futin të dhëna aq shpesh, por përsëri përfundojnë me futje të shpeshta. Dhe ne duhet ta shmangim disi këtë.
Nga pikëpamja teknike, çështja është se kur bëni një insert në ClickHouse, të dhënat nuk përfundojnë në asnjë memtable. Ne nuk kemi as një strukturë të vërtetë log MergeTree, por thjesht një MergeTree, sepse nuk ka as një regjistër dhe as një memTable. Ne thjesht shkruajmë menjëherë të dhënat në sistemin e skedarëve, tashmë të rregulluar në kolona. Dhe nëse keni 100 kolona, atëherë më shumë se 200 skedarë do të duhet të shkruhen në një drejtori të veçantë. E gjithë kjo është shumë e rëndë.
Dhe lind pyetja: "Si ta bëjmë siç duhet?" Nëse situata është e tillë që ju ende duhet të regjistroni disi të dhënat në ClickHouse.
Metoda 1. Kjo është mënyra më e lehtë. Përdorni një lloj radhe të shpërndarë. Për shembull, Kafka. Ju thjesht nxjerrni të dhëna nga Kafka dhe i grumbulloni ato një herë në sekondë. Dhe gjithçka do të jetë mirë, ju regjistroni, gjithçka funksionon mirë.
Disavantazhet janë se Kafka është një tjetër sistem i rëndë i shpërndarë. Unë gjithashtu e kuptoj nëse tashmë e keni Kafkën në shoqërinë tuaj. Është mirë, është i përshtatshëm. Por nëse nuk ekziston, atëherë duhet të mendoni tre herë përpara se të tërhiqni një sistem tjetër të shpërndarë në projektin tuaj. Dhe kështu ia vlen të merren parasysh alternativat.
Metoda 2. Kjo është një alternativë e vjetër dhe në të njëjtën kohë shumë e thjeshtë. A keni ndonjë lloj serveri që gjeneron regjistrat tuaj. Dhe thjesht shkruan regjistrat tuaj në një skedar. Dhe një herë në sekondë, për shembull, ne riemërtojmë këtë skedar dhe heqim një të ri. Dhe një skript i veçantë, ose nëpërmjet cron ose ndonjë demon, merr skedarin më të vjetër dhe e shkruan atë në ClickHouse. Nëse regjistroni regjistrat një herë në sekondë, atëherë gjithçka do të jetë mirë.
Por disavantazhi i kësaj metode është se nëse serveri juaj në të cilin janë krijuar regjistrat zhduket diku, atëherë të dhënat gjithashtu do të zhduken.
Metoda 3. Ekziston një metodë tjetër interesante, e cila nuk kërkon fare skedarë të përkohshëm. Për shembull, ju keni një lloj spinner reklamimi ose ndonjë demon tjetër interesant që gjeneron të dhëna. Dhe mund të grumbulloni një grup të dhënash direkt në RAM, në buffer. Dhe kur të ketë kaluar mjaftueshëm kohë, ju e lini mënjanë këtë buffer, krijoni një të ri dhe në një fije të veçantë, futni atë që është grumbulluar tashmë në ClickHouse.
Nga ana tjetër, të dhënat gjithashtu zhduken me kill -9. Nëse serveri juaj prishet, do t'i humbni këto të dhëna. Dhe një problem tjetër është se nëse nuk keni mundur të shkruani në bazën e të dhënave, atëherë të dhënat tuaja do të grumbullohen në RAM. Dhe ose RAM do të mbarojë, ose thjesht do të humbni të dhënat.
Metoda 4. Një metodë tjetër interesante. A keni një lloj procesi serveri. Dhe mund të dërgojë të dhëna në ClickHouse menjëherë, por ta bëjë atë në një lidhje. Për shembull, dërgova një kërkesë http me kodim transferimi: copëtuar me insert. Dhe gjeneron copa jo shumë rrallë, ju mund të dërgoni çdo rresht, megjithëse do të ketë shpenzime të përgjithshme për inkuadrimin e këtyre të dhënave.
Megjithatë, në këtë rast të dhënat do të dërgohen në ClickHouse menjëherë. Dhe ClickHouse do t'i ruajë ato vetë.
Por lindin edhe probleme. Tani ju do të humbni të dhëna, duke përfshirë kur procesi juaj është vrarë dhe nëse procesi ClickHouse është vrarë, sepse do të jetë një insert jo i plotë. Dhe në ClickHouse futjet janë atomike deri në një prag të caktuar të specifikuar në madhësinë e rreshtave. Në parim, kjo është një mënyrë interesante. Mund të përdoret gjithashtu.
Metoda 5. Këtu është një metodë tjetër interesante. Ky është një lloj serveri i zhvilluar nga komuniteti për grumbullimin e të dhënave. Unë nuk e kam parë vetë, kështu që nuk mund të garantoj asgjë. Megjithatë, nuk ofrohen garanci për vetë ClickHouse. Ky është gjithashtu me burim të hapur, por nga ana tjetër, ju mund të jeni mësuar me disa standarde cilësie që ne përpiqemi të ofrojmë. Por për këtë gjë - nuk e di, shkoni në GitHub, shikoni kodin. Ndoshta kanë shkruar diçka normale.
* që nga viti 2020, gjithashtu duhet të shtohet në konsideratë .
Metoda 6. Një metodë tjetër është përdorimi i tabelave Buffer. Avantazhi i kësaj metode është se është shumë e lehtë për të filluar përdorimin. Krijoni një tabelë Buffer dhe futeni në të.
Disavantazhi është se problemi nuk është zgjidhur plotësisht. Nëse, në një normë si MergeTree, ju duhet të gruponi të dhënat me një grup për sekondë, atëherë në një normë në një tabelë buffer, duhet të gruponi të paktën deri në disa mijëra në sekondë. Nëse është më shumë se 10 në sekondë, do të jetë akoma keq. Dhe nëse e futni në grupe, atëherë e keni parë që rezulton të jetë njëqind mijë rreshta në sekondë. Dhe kjo është tashmë në të dhëna mjaft të rënda.
Dhe gjithashtu tabelat buffer nuk kanë një regjistër. Dhe nëse ka diçka që nuk shkon me serverin tuaj, atëherë të dhënat do të humbasin.
Dhe si bonus, kohët e fundit kemi marrë mundësinë në ClickHouse për të tërhequr të dhëna nga Kafka. Ka një motor tavoline - Kafka. Ju thjesht krijoni. Dhe ju mund të varni përfaqësime të materializuara në të. Në këtë rast, ai vetë do të nxjerrë të dhëna nga Kafka dhe do t'i futë ato në tabelat që ju nevojiten.
Dhe ajo që është veçanërisht e këndshme për këtë mundësi është se nuk ishim ne që e bëmë atë. Kjo është një veçori e komunitetit. Dhe kur them "tipar i komunitetit", e kam parasysh pa asnjë përbuzje. Ne lexuam kodin, bëmë një rishikim, duhet të funksionojë mirë.
* Që nga viti 2020, mbështetje e ngjashme është shfaqur për .
Çfarë tjetër mund të jetë e papërshtatshme ose e papritur kur futni të dhëna? Nëse bëni një kërkesë për futje vlerash dhe shkruani disa shprehje të llogaritura në vlera. Për shembull, tani() është gjithashtu një shprehje e llogaritur. Dhe në këtë rast, ClickHouse detyrohet të lançojë interpretuesin e këtyre shprehjeve në çdo rresht dhe performanca do të bjerë me urdhër të madhësisë. Është më mirë ta shmangni këtë.
* për momentin, problemi është zgjidhur plotësisht, nuk ka më regresion të performancës kur përdoren shprehjet në VALUES.
Një shembull tjetër është kur mund të ketë disa probleme kur keni të dhëna në një grup që i përket një grupi ndarjesh. Si parazgjedhje, ndarjet e ClickHouse janë sipas muajit. Dhe nëse futni një grup prej një milion rreshtash, dhe ka të dhëna për disa vjet, atëherë do të keni disa dhjetëra ndarje atje. Dhe kjo është e barabartë me faktin se do të ketë tufa disa dhjetëra herë më të vogla në madhësi, sepse brenda ato ndahen gjithmonë së pari në ndarje.
* Kohët e fundit, në modalitetin eksperimental, ClickHouse shtoi mbështetje për formatin kompakt të pjesëve dhe pjesëve në RAM me regjistrin e shkrimit përpara, i cili pothuajse e zgjidh plotësisht problemin.
Tani le të shohim llojin e dytë të problemit - shtypjen e të dhënave.
Shtypja e të dhënave mund të jetë strikte ose varg. String është kur sapo e morët dhe deklaruat se të gjitha fushat tuaja janë të tipit string. Kjo gjë e keqe. Nuk ka nevojë për ta bërë këtë.
Le të kuptojmë se si ta bëjmë atë saktë në ato raste kur doni të thoni se kemi një fushë, një varg dhe le ta kuptojë vetë ClickHouse, dhe unë nuk do të shqetësohem. Por prapëseprapë ia vlen të bëni pak përpjekje.
Për shembull, ne kemi një adresë IP. Në një rast, e ruajtëm si varg. Për shembull, 192.168.1.1. Dhe në një rast tjetër, do të jetë një numër i tipit UInt32*. 32 bit janë të mjaftueshëm për një adresë IPv4.
Së pari, çuditërisht, të dhënat do të kompresohen afërsisht në mënyrë të barabartë. Do të ketë një ndryshim, sigurisht, por jo aq i madh. Pra, nuk ka probleme të veçanta me I/O të diskut.
Por ka një ndryshim serioz në kohën e procesorit dhe kohën e ekzekutimit të pyetjes.
Le të numërojmë numrin e adresave IP unike nëse ato ruhen si numra. Kjo arrin në 137 milionë rreshta në sekondë. Nëse e njëjta është në formën e vargjeve, atëherë 37 milionë rreshta në sekondë. Nuk e di pse ndodhi kjo rastësi. Këto kërkesa i kam kryer vetë. Por ende rreth 4 herë më ngadalë.
Dhe nëse llogaritni ndryshimin në hapësirën e diskut, atëherë ka gjithashtu një ndryshim. Dhe ndryshimi është rreth një e katërta, sepse ka mjaft adresa IP unike. Dhe nëse do të kishte rreshta me një numër të vogël kuptimesh të ndryshme, atëherë ato do të kompresoheshin lehtësisht sipas fjalorit në përafërsisht të njëjtin vëllim.
Dhe diferenca e katërfishtë e kohës nuk qëndron në rrugë. Ndoshta s'të merr mendja, sigurisht, por kur shoh një ndryshim të tillë, më vjen keq.
Le të shohim raste të ndryshme.
1. Një rast kur keni pak vlera unike të ndryshme. Në këtë rast, ne përdorim një praktikë të thjeshtë që ju ndoshta e dini dhe mund ta përdorni për çdo DBMS. E gjithë kjo ka kuptim jo vetëm për ClickHouse. Thjesht shkruani identifikuesit numerikë në bazën e të dhënave. Dhe mund të konvertoheni në vargje dhe të ktheheni në anën e aplikacionit tuaj.
Për shembull, ju keni një rajon. Dhe ju po përpiqeni ta ruani atë si një varg. Dhe atje do të shkruhet: Moska dhe Rajoni i Moskës. Dhe kur shoh që thotë "Moska", nuk është asgjë, por kur është Moska, disi bëhet plotësisht e trishtuar. Kjo është sa bajt.
Në vend të kësaj, ne thjesht shkruajmë numrin Ulnt32 dhe 250. Ne kemi 250 në Yandex, por i juaji mund të jetë i ndryshëm. Për çdo rast, unë do të them që ClickHouse ka një aftësi të integruar për të punuar me një gjeobazë. Ju thjesht shkruani një drejtori me rajone, duke përfshirë një hierarki, d.m.th. do të ketë Moskë, Rajoni i Moskës dhe gjithçka që ju nevojitet. Dhe mund të konvertohet në nivelin e kërkesës.
Opsioni i dytë është afërsisht i njëjtë, por me mbështetje brenda ClickHouse. Ky është lloji i të dhënave Enum. Ju thjesht shkruani të gjitha vlerat që ju nevojiten brenda Enum. Për shembull, lloji i pajisjes dhe shkruani atje: desktop, celular, tablet, TV. Janë 4 opsione në total.
Disavantazhi është se ju duhet ta ndryshoni atë në mënyrë periodike. Është shtuar vetëm një opsion. Le të bëjmë një tabelë tjetër. Në fakt, tabela e ndryshimit në ClickHouse është falas. Veçanërisht falas për Enum sepse të dhënat në disk nuk ndryshojnë. Por megjithatë, alter fiton një bllokim* në tryezë dhe duhet të presë derisa të ekzekutohen të gjitha përzgjedhjet. Dhe vetëm pasi ky ndryshim do të ekzekutohet, pra ka ende disa shqetësime.
* në versionet më të fundit të ClickHouse, ALTER është bërë plotësisht jo-bllokues.
Një tjetër opsion që është mjaft unik për ClickHouse është lidhja e fjalorëve të jashtëm. Ju mund të shkruani numra në ClickHouse dhe t'i mbani drejtoritë tuaja në çdo sistem të përshtatshëm për ju. Për shembull, mund të përdorni: MySQL, Mongo, Postgres. Ju madje mund të krijoni mikroshërbimin tuaj që do t'i dërgojë këto të dhëna përmes http. Dhe në nivelin ClickHouse, ju shkruani një funksion që do t'i konvertojë këto të dhëna nga numra në vargje.
Kjo është një mënyrë e specializuar por shumë efikase për të kryer një bashkim në një tavolinë të jashtme. Dhe ka dy opsione. Në një mishërim, këto të dhëna do të ruhen plotësisht në memorie, plotësisht të pranishme në RAM dhe do të përditësohen me një farë frekuence. Dhe në një opsion tjetër, nëse këto të dhëna nuk përshtaten në RAM, atëherë mund t'i ruani pjesërisht ato.
Ja një shembull. Ekziston Yandex.Direct. Dhe ka një kompani reklamuese dhe parulla. Ndoshta ka rreth dhjetëra miliona kompani reklamuese. Dhe ato përshtaten përafërsisht në RAM. Dhe ka miliarda banderola, ato nuk përshtaten. Dhe ne përdorim një fjalor të memorizuar nga MySQL.
Problemi i vetëm është se fjalori i memorizuar do të funksionojë mirë nëse shkalla e goditjes është afër 100%. Nëse është më i vogël, atëherë kur përpunoni pyetje për çdo grup të dhënash, në fakt do t'ju duhet të merrni çelësat që mungojnë dhe të shkoni të merrni të dhënat nga MySQL. Rreth ClickHouse, unë ende mund të garantoj se - po, nuk ngadalësohet, nuk do të flas për sisteme të tjera.
Dhe si bonus, fjalorët janë një mënyrë shumë e thjeshtë për të përditësuar në mënyrë retroaktive të dhënat në ClickHouse. Domethënë keni pasur një raport për kompanitë reklamuese, përdoruesi thjesht ka ndryshuar kompaninë e reklamave dhe në të gjitha të dhënat e vjetra, në të gjitha raportet kanë ndryshuar edhe këto të dhëna. Nëse shkruani rreshta direkt në tabelë, do të jetë e pamundur t'i përditësoni ato.
Një mënyrë tjetër kur nuk dini ku t'i merrni identifikuesit për vargjet tuaja. ju thjesht mund ta hash atë. Për më tepër, opsioni më i thjeshtë është të marrësh një hash 64-bit.
Problemi i vetëm është se nëse hash-i është 64-bit, atëherë pothuajse me siguri do të keni përplasje. Sepse nëse ka një miliard rreshta atje, atëherë probabiliteti tashmë bëhet i dukshëm.
Dhe nuk do të ishte shumë mirë që emrat e kompanive reklamuese të haseshin në këtë mënyrë. Nëse ngatërrohen fushatat reklamuese të kompanive të ndryshme, atëherë do të ketë diçka të pakuptueshme.
Dhe ka një truk të thjeshtë. Vërtetë, nuk është gjithashtu shumë i përshtatshëm për të dhëna serioze, por nëse diçka nuk është shumë serioze, atëherë thjesht shtoni identifikuesin e klientit në çelësin e fjalorit. Dhe atëherë do të keni përplasje, por vetëm brenda një klienti. Dhe ne e përdorim këtë metodë për hartat e lidhjeve në Yandex.Metrica. Ne kemi URL atje, ruajmë hash. Dhe ne e dimë se, natyrisht, ka përplasje. Por kur shfaqet faqja, probabiliteti që në një faqe të një përdoruesi disa URL të jenë ngjitur së bashku dhe kjo të vihet re mund të neglizhohet.
Si bonus, për shumë operacione mjaftojnë vetëm hash-et dhe vetë vargjet nuk kanë nevojë të ruhen askund.
Një shembull tjetër është nëse vargjet janë të shkurtra, për shembull, domenet e uebsajtit. Ato mund të ruhen ashtu siç janë. Ose, për shembull, gjuha e shfletuesit ru është 2 bajt. Sigurisht, më vjen shumë keq për bajtet, por mos u shqetësoni, 2 bajt nuk janë për të ardhur keq. Ju lutemi mbajeni ashtu siç është, mos u shqetësoni.
Një rast tjetër është kur, përkundrazi, ka shumë linja dhe ka shumë unike në to, madje edhe grupi është potencialisht i pakufizuar. Një shembull tipik janë frazat e kërkimit ose URL-të. Kërko frazat, duke përfshirë gabimet e shtypit. Le të shohim se sa fraza kërkimi unike ka në ditë. Dhe rezulton se ato janë pothuajse gjysma e të gjitha ngjarjeve. Dhe në këtë rast, mund të mendoni se duhet të normalizoni të dhënat, të numëroni identifikuesit dhe t'i vendosni në një tabelë të veçantë. Por ju nuk keni nevojë ta bëni këtë. Thjesht mbani këto rreshta ashtu siç janë.
Është më mirë të mos shpikni asgjë, sepse nëse e ruani veçmas, do t'ju duhet të bëni një bashkim. Dhe ky bashkim është, në rastin më të mirë, një akses i rastësishëm në memorie, nëse ende përshtatet në memorie. Nëse nuk përshtatet, atëherë do të ketë probleme.
Dhe nëse të dhënat ruhen në vend, atëherë ato thjesht lexohen në rendin e kërkuar nga sistemi i skedarëve dhe gjithçka është në rregull.
Nëse keni URL ose ndonjë varg tjetër kompleks të gjatë, atëherë ia vlen të merret parasysh që mund të llogaritni paraprakisht një lloj ekstrakti dhe ta shkruani atë në një kolonë të veçantë.
Për URL-të, për shembull, mund ta ruani domenin veçmas. Dhe nëse vërtet keni nevojë për një domen, atëherë thjesht përdorni këtë kolonë dhe URL-të do të qëndrojnë atje, dhe ju as nuk do t'i prekni ato.
Le të shohim se cili është ndryshimi. ClickHouse ka një funksion të specializuar që llogarit domenin. Është shumë i shpejtë, e kemi optimizuar. Dhe, për të qenë i sinqertë, as nuk përputhet me RFC-në, por megjithatë merr parasysh gjithçka që na nevojitet.
Dhe në një rast ne thjesht do të marrim URL-të dhe do të llogarisim domenin. Kjo funksionon deri në 166 milisekonda. Dhe nëse merrni një domen të gatshëm, atëherë rezulton të jetë vetëm 67 milisekonda, domethënë pothuajse tre herë më i shpejtë. Dhe është më e shpejtë jo sepse duhet të bëjmë disa llogaritje, por sepse lexojmë më pak të dhëna.
Kjo është arsyeja pse një kërkesë, e cila është më e ngadalshme, ka një shpejtësi më të madhe prej gigabajt për sekondë. Sepse lexon më shumë gigabajt. Këto janë të dhëna krejtësisht të panevojshme. Kërkesa duket se funksionon më shpejt, por kërkon më shumë kohë për t'u plotësuar.
Dhe nëse shikoni sasinë e të dhënave në disk, rezulton se URL-ja është 126 megabajt, dhe domeni është vetëm 5 megabajt. Rezulton 25 herë më pak. Por megjithatë, kërkesa ekzekutohet vetëm 4 herë më shpejt. Por kjo për shkak se të dhënat janë të nxehta. Dhe nëse do të ishte ftohtë, ndoshta do të ishte 25 herë më i shpejtë për shkak të hyrjes/daljes së diskut.
Meqë ra fjala, nëse vlerësoni se sa më i vogël është një domen se një URL, rezulton të jetë rreth 4 herë më i vogël, por për disa arsye, të dhënat zënë 25 herë më pak në disk. Pse? Për shkak të ngjeshjes. Dhe URL-ja është e ngjeshur dhe domeni është i ngjeshur. Por shpesh URL-ja përmban një grumbull mbeturinash.
Dhe, sigurisht, ia vlen të përdorni llojet e duhura të të dhënave që janë krijuar posaçërisht për vlerat e dëshiruara ose që janë të përshtatshme. Nëse jeni në IPv4, atëherë ruani UInt32*. Nëse IPv6, atëherë FixedString(16), sepse adresa IPv6 është 128 bit, pra e ruajtur direkt në format binar.
Por, çka nëse ndonjëherë keni adresa IPv4 dhe ndonjëherë IPv6? Po, mund t'i ruani të dyja. Një kolonë për IPv4, një tjetër për IPv6. Sigurisht, ekziston një mundësi për të shfaqur IPv4 në IPv6. Kjo do të funksionojë gjithashtu, por nëse shpesh keni nevojë për një adresë IPv4 në kërkesat, atëherë do të ishte mirë ta vendosni atë në një kolonë të veçantë.
* ClickHouse tani ka lloje të veçanta të dhënash IPv4, IPv6 që ruajnë të dhënat në mënyrë po aq efikase sa numrat, por i përfaqësojnë ato në mënyrë të përshtatshme si vargjet.
Është gjithashtu e rëndësishme të theksohet se ia vlen të përpunohen paraprakisht të dhënat. Për shembull, ju merrni disa shkrime të papërpunuara. Dhe ndoshta nuk duhet t'i vendosni ato menjëherë në ClickHouse, megjithëse është shumë joshëse të mos bëni asgjë dhe gjithçka do të funksionojë. Por ende ia vlen të kryhen llogaritjet që janë të mundshme.
Për shembull, versioni i shfletuesit. Në disa departamente të afërta, të cilat nuk dua t'i drejtoj gishtin, versioni i shfletuesit ruhet si ky, domethënë si varg: 12.3. Dhe më pas, për të bërë një raport, ata marrin këtë varg dhe e ndajnë atë në një grup, dhe më pas në elementin e parë të grupit. Natyrisht, gjithçka ngadalësohet. E pyeta pse e bëjnë këtë. Ata më thanë se nuk u pëlqen optimizimi i parakohshëm. Dhe nuk më pëlqen pesimizimi i parakohshëm.
Pra, në këtë rast do të ishte më e saktë të ndahej në 4 kolona. Mos kini frikë këtu, sepse ky është ClickHouse. ClickHouse është një bazë të dhënash kolone. Dhe sa më shumë kolona të vogla të pastra, aq më mirë. Do të ketë 5 versione të shfletuesit, bëni 5 kolona. Kjo është mirë.
Tani le të shohim se çfarë të bëni nëse keni shumë vargje shumë të gjata, vargje shumë të gjata. Ato nuk kanë nevojë të ruhen fare në ClickHouse. Në vend të kësaj, ju mund të ruani vetëm një identifikues në ClickHouse. Dhe vendosini këto rreshta të gjata në një sistem tjetër.
Për shembull, një nga shërbimet tona analitike ka disa parametra ngjarjesh. Dhe nëse ka shumë parametra për ngjarjet, ne thjesht ruajmë 512 të parët që hasen. Sepse 512 nuk është për të ardhur keq.
Dhe nëse nuk mund të vendosni për llojet e të dhënave tuaja, atëherë mund të regjistroni të dhëna edhe në ClickHouse, por në një tabelë të përkohshme të llojit Log, e veçantë për të dhëna të përkohshme. Pas kësaj, mund të analizoni se çfarë shpërndarje vlerash keni atje, çfarë ka në përgjithësi dhe të krijoni llojet e duhura.
*ClickHouse tani ka një lloj të dhënash e cila ju lejon të ruani vargjet në mënyrë efikase me më pak përpjekje.
Tani le të shohim një rast tjetër interesant. Ndonjëherë gjërat funksionojnë çuditërisht për njerëzit. Unë hyj dhe e shoh këtë. Dhe menjëherë duket se kjo është bërë nga një administrator shumë me përvojë, i zgjuar, i cili ka përvojë të gjerë në konfigurimin e versionit 3.23 të MySQL.
Këtu shohim një mijë tabela, secila prej të cilave regjistron pjesën e mbetur të pjesëtimit kush e di çfarë me një mijë.
Në parim, unë respektoj përvojën e njerëzve të tjerë, duke përfshirë të kuptuarit e vuajtjes që mund të fitohet përmes kësaj përvoje.
Dhe arsyet janë pak a shumë të qarta. Këto janë stereotipe të vjetra që mund të jenë grumbulluar gjatë punës me sisteme të tjera. Për shembull, tabelat MyISAM nuk kanë një çelës primar të grupuar. Dhe kjo mënyrë e ndarjes së të dhënave mund të jetë një përpjekje e dëshpëruar për të marrë të njëjtin funksionalitet.
Një arsye tjetër është se është e vështirë të bësh ndonjë operacion ndryshimi në tavolina të mëdha. Gjithçka do të bllokohet. Edhe pse në versionet moderne të MySQL ky problem nuk është më aq serioz.
Ose, për shembull, microsharding, por më shumë për këtë më vonë.
Nuk ka nevojë ta bëni këtë në ClickHouse, sepse, së pari, çelësi primar është i grupuar, të dhënat renditen nga çelësi primar.
Dhe ndonjëherë njerëzit më pyesin: "Si ndryshon performanca e pyetjeve të diapazonit në ClickHouse në varësi të madhësisë së tabelës?" Unë them që nuk ndryshon fare. Për shembull, ju keni një tabelë me një miliard rreshta dhe lexoni një gamë prej një milion rreshtash. Cdo gje eshte ne rregull. Nëse ka një trilion rreshta në një tabelë dhe ju lexoni një milion rreshta, do të jetë pothuajse e njëjtë.
Dhe, së dyti, të gjitha llojet e gjërave si ndarjet manuale nuk kërkohen. Nëse hyni dhe shikoni se çfarë është në sistemin e skedarëve, do të shihni se tabela është një punë mjaft e madhe. Dhe ka diçka si ndarje brenda. Kjo do të thotë, ClickHouse bën gjithçka për ju dhe ju nuk keni pse të vuani.
Alter në ClickHouse është falas nëse ndryshon kolonën e shtimit/heqjes.
Dhe nuk duhet të bëni tabela të vogla, sepse nëse keni 10 rreshta ose 10 rreshta në një tabelë, atëherë nuk ka fare rëndësi. ClickHouse është një sistem që optimizon xhiron, jo vonesën, kështu që nuk ka kuptim të përpunosh 000 rreshta.
Është e saktë të përdoret një tavolinë e madhe. Hiqni qafe stereotipet e vjetra, gjithçka do të jetë mirë.
Dhe si bonus, në versionin e fundit ne tani kemi mundësinë të krijojmë një çelës ndarjeje arbitrare në mënyrë që të kryejmë të gjitha llojet e operacioneve të mirëmbajtjes në ndarjet individuale.
Për shembull, ju duhen shumë tabela të vogla, për shembull, kur ka nevojë për të përpunuar disa të dhëna të ndërmjetme, ju merrni copa dhe ju duhet të kryeni një transformim mbi to përpara se të shkruani në tabelën përfundimtare. Për këtë rast, ekziston një motor i mrekullueshëm tavoline - StripeLog. Është disi si TinyLog, vetëm më mirë.
* tani ka edhe ClickHouse .
Një tjetër antimodel është microsharding. Për shembull, ju duhet të copëtoni të dhënat dhe keni 5 serverë, dhe nesër do të ketë 6 serverë. Dhe ju mendoni se si të ribalanconi këto të dhëna. Dhe në vend të kësaj ju nuk ndaheni në 5 copëza, por në 1 copëza. Dhe pastaj ju hartoni secilën nga këto mikrosharda në një server të veçantë. Dhe ju do të merrni, për shembull, 000 ClickHouses në një server, për shembull. Instancat e ndara në porte të veçanta ose baza të të dhënave të veçanta.
Por kjo nuk është shumë e mirë në ClickHouse. Sepse edhe një shembull i ClickHouse përpiqet të përdorë të gjitha burimet e disponueshme të serverit për të përpunuar një kërkesë. Kjo do të thotë, ju keni një lloj serveri dhe ai ka, për shembull, 56 bërthama procesori. Ju po ekzekutoni një pyetje që zgjat një sekondë dhe do të përdorë 56 bërthama. Dhe nëse vendosni 200 ClickHouses atje në një server, atëherë rezulton se do të fillojnë 10 tema. Në përgjithësi, gjithçka do të jetë shumë e keqe.
Një arsye tjetër është se shpërndarja e punës në këto raste do të jetë e pabarabartë. Disa do të mbarojnë më herët, disa do të përfundojnë më vonë. Nëse e gjithë kjo do të ndodhte në një rast, atëherë vetë ClickHouse do të kuptonte se si të shpërndante saktë të dhënat midis temave.
Dhe një arsye tjetër është se ju do të keni komunikim ndërprocesor nëpërmjet TCP. Të dhënat do të duhet të serializohen, deserializohen, dhe ky është një numër i madh mikroshardash. Thjesht nuk do të funksionojë në mënyrë efektive.
Një tjetër antipattern, megjithëse vështirë se mund të quhet antipattern. Kjo është një sasi e madhe e para-grumbullimit.
Në përgjithësi, para-grumbullimi është i mirë. Kishit një miliard rreshta, i grumbulluat dhe u bënë 1 rreshta dhe tani pyetja ekzekutohet menjëherë. Gjithçka është e mrekullueshme. Ti mund ta besh kete. Dhe për këtë, edhe ClickHouse ka një lloj tabele të veçantë, AggregatingMergeTree, e cila kryen grumbullim në rritje ndërsa futen të dhënat.
Por ka raste kur mendoni se ne do të grumbullojmë të dhëna si kjo dhe do të grumbullojmë të dhëna si kjo. Dhe në disa departamente fqinje, gjithashtu nuk dua të them se cilin, ata përdorin tabelat SummingMergeTree për të përmbledhur sipas çelësit primar, dhe rreth 20 kolona përdoren si çelësi kryesor. Për çdo rast, unë ndryshova emrat e disa rubrikave për fshehtësi, por pak a shumë.
Dhe lindin probleme të tilla. Së pari, vëllimi i të dhënave tuaja nuk ulet shumë. Për shembull, zvogëlohet me tre herë. Tre herë do të ishte një çmim i mirë për të përballuar aftësitë e pakufizuara analitike që lindin nëse të dhënat tuaja nuk grumbullohen. Nëse të dhënat grumbullohen, atëherë në vend të analitikës merrni vetëm statistika të mjerueshme.
Dhe çfarë është kaq e veçantë në lidhje me të? Fakti është se këta njerëz nga departamenti fqinj ndonjëherë shkojnë dhe kërkojnë të shtojnë një kolonë tjetër në çelësin primar. Kjo do të thotë, ne i grumbulluam të dhënat kështu, por tani duam pak më shumë. Por ClickHouse nuk ka një çelës primar alter. Prandaj, duhet të shkruajmë disa skripta në C++. Dhe nuk më pëlqejnë skriptet, edhe nëse janë në C++.
Dhe nëse shikoni se për çfarë është krijuar ClickHouse, atëherë të dhënat jo të grumbulluara janë pikërisht skenari për të cilin ka lindur. Nëse po përdorni ClickHouse për të dhëna jo të grumbulluara, atëherë po e bëni mirë. Nëse grumbulloni, kjo ndonjëherë është e falshme.
Një rast tjetër interesant janë pyetjet në një lak të pafund. Ndonjëherë shkoj te ndonjë server prodhimi dhe shikoj listën e proceseve të shfaqjes atje. Dhe sa herë zbuloj se diçka e tmerrshme po ndodh.
Për shembull, si kjo. Është menjëherë e qartë se gjithçka mund të bëhet me një kërkesë. Thjesht shkruani url-në dhe listën atje.
Pse shumë pyetje të tilla në një lak të pafund janë të këqija? Nëse një indeks nuk përdoret, atëherë do të keni shumë kalime mbi të njëjtat të dhëna. Por nëse përdoret indeksi, për shembull, ju keni një çelës primar për ru dhe shkruani url = diçka atje. Dhe ju mendoni se nëse lexohet vetëm një URL nga tabela, gjithçka do të jetë mirë. Por në fakt jo. Sepse ClickHouse bën gjithçka në grupe.
Kur duhet të lexojë një gamë të caktuar të dhënash, ai lexon pak më shumë, sepse indeksi në ClickHouse është i rrallë. Ky indeks nuk ju lejon të gjeni një rresht individual në tabelë, vetëm një gamë të një lloji. Dhe të dhënat kompresohen në blloqe. Për të lexuar një rresht, duhet të merrni të gjithë bllokun dhe ta zhbllokoni atë. Dhe nëse jeni duke bërë një sërë pyetjesh, do të keni shumë mbivendosje dhe do të keni shumë punë për të bërë vazhdimisht.
Dhe si bonus, mund të vini re se në ClickHouse nuk duhet të keni frikë të transferoni edhe megabajt dhe madje qindra megabajt në seksionin IN. Më kujtohet nga praktika jonë që nëse në MySQL transferojmë një mori vlerash në seksionin IN, për shembull, transferojmë 100 megabajt të disa numrave atje, atëherë MySQL ha 10 gigabajt memorie dhe asgjë tjetër nuk i ndodh, gjithçka. punon keq.
Dhe e dyta është se në ClickHouse, nëse pyetjet tuaja përdorin një indeks, atëherë ai nuk është gjithmonë më i ngadalshëm se një skanim i plotë, d.m.th. nëse duhet të lexoni pothuajse të gjithë tabelën, ajo do të shkojë në mënyrë sekuenciale dhe do të lexojë të gjithë tabelën. Në përgjithësi, ai do ta kuptojë vetë.
Por megjithatë ka disa vështirësi. Për shembull, fakti që IN me një nënpyetje nuk përdor indeksin. Por ky është problemi ynë dhe ne duhet ta rregullojmë atë. Këtu nuk ka asgjë thelbësore. Do ta rregullojmë*.
Dhe një tjetër gjë interesante është se nëse keni një kërkesë shumë të gjatë dhe përpunimi i kërkesës së shpërndarë është në proces, atëherë kjo kërkesë shumë e gjatë do t'i dërgohet çdo serveri pa kompresim. Për shembull, 100 megabajt dhe 500 serverë. Dhe, në përputhje me rrethanat, do të keni 50 gigabajt të transferuar në rrjet. Do të transmetohet dhe më pas gjithçka do të përfundojë me sukses.
* tashmë duke përdorur; Gjithçka u rregullua siç ishte premtuar.
Dhe një rast mjaft i zakonshëm është kur kërkesat vijnë nga API. Për shembull, keni krijuar një lloj shërbimi tuajin. Dhe nëse dikush ka nevojë për shërbimin tuaj, atëherë ju hapni API dhe fjalë për fjalë dy ditë më vonë shihni se diçka e pakuptueshme po ndodh. Gjithçka është e mbingarkuar dhe po vijnë disa kërkesa të tmerrshme që nuk duhet të kishin ndodhur kurrë.
Dhe ka vetëm një zgjidhje. Nëse e keni hapur API-në, atëherë do t'ju duhet ta shkurtoni atë. Për shembull, futni një lloj kuotash. Nuk ka opsione të tjera normale. Përndryshe, ata do të shkruajnë menjëherë një skenar dhe do të ketë probleme.
Dhe ClickHouse ka një veçori të veçantë - llogaritjen e kuotave. Për më tepër, ju mund të transferoni çelësin tuaj të kuotës. Kjo është, për shembull, ID e brendshme e përdoruesit. Dhe kuotat do të llogariten në mënyrë të pavarur për secilën prej tyre.
Tani një tjetër gjë interesante. Ky është përsëritje manuale.
Unë di shumë raste kur, pavarësisht se ClickHouse ka mbështetje të integruar për replikimin, njerëzit e përsërisin ClickHouse manualisht.
Cili është parimi? Ju keni një tubacion për përpunimin e të dhënave. Dhe funksionon në mënyrë të pavarur, për shembull, në qendra të ndryshme të të dhënave. Ju shkruani të njëjtat të dhëna në të njëjtën mënyrë në ClickHouse. Vërtetë, praktika tregon se të dhënat ende do të ndryshojnë për shkak të disa veçorive në kodin tuaj. Shpresoj të jetë në tuajën.
Dhe herë pas here do t'ju duhet ende të sinkronizoni manualisht. Për shembull, një herë në muaj administratorët bëjnë rsync.
Në fakt, është shumë më e lehtë të përdorësh replikimin e integruar në ClickHouse. Por mund të ketë disa kundërindikacione, sepse për këtë ju duhet të përdorni ZooKeeper. Nuk do të them asgjë të keqe për ZooKeeper, në parim sistemi funksionon, por ndodh që njerëzit të mos e përdorin atë për shkak të java-fobisë, sepse ClickHouse është një sistem kaq i mirë, i shkruar në C++, të cilin mund ta përdorni dhe çdo gjë do të jetë mirë. Dhe ZooKeeper është në java. Dhe disi as që dëshironi të shikoni, por atëherë mund të përdorni përsëritjen manuale.
ClickHouse është një sistem praktik. Ajo merr parasysh nevojat tuaja. Nëse keni përsëritje manuale, atëherë mund të krijoni një tabelë të shpërndarë që shikon kopjet tuaja manuale dhe bën një dështim midis tyre. Dhe madje ekziston një opsion i veçantë që ju lejon të shmangni dështimet, edhe nëse linjat tuaja ndryshojnë sistematikisht.
Probleme të mëtejshme mund të lindin nëse përdorni motorë primitivë tavoline. ClickHouse është një konstruktor që ka një mori motorësh të ndryshëm tabelash. Për të gjitha rastet e rënda, siç shkruhet në dokumentacion, përdorni tabela nga familja MergeTree. Dhe të gjitha të tjerat - kjo është kështu, për raste individuale ose për teste.
Në një tabelë MergeTree, nuk keni nevojë të keni ndonjë datë dhe orë. Mund ta përdorni akoma. Nëse nuk ka datë dhe orë, shkruani se parazgjedhja është 2000. Kjo do të funksionojë dhe nuk do të kërkojë burime.
Dhe në versionin e ri të serverit, madje mund të specifikoni që keni ndarje të personalizuar pa një çelës ndarjeje. Njësoj do të jetë.
Nga ana tjetër, ju mund të përdorni motorë primitivë tavoline. Për shembull, plotësoni të dhënat një herë dhe shikoni, rrotulloni dhe fshini. Ju mund të përdorni Log.
Ose ruajtja e vëllimeve të vogla për përpunim të ndërmjetëm është StripeLog ose TinyLog.
Memoria mund të përdoret nëse sasia e të dhënave është e vogël dhe thjesht mund të rrotulloni diçka në RAM.
ClickHouse nuk i pëlqen vërtet të dhënat e rinormalizuara.
Ja një shembull tipik. Ky është një numër i madh URL-sh. Ju i vendosni ato në tabelën tjetër. Dhe më pas ata vendosën të bëjnë JOIN me ta, por kjo nuk do të funksionojë, si rregull, sepse ClickHouse mbështet vetëm Hash JOIN. Nëse nuk ka RAM të mjaftueshëm për shumë të dhëna që duhen lidhur, atëherë JOIN nuk do të funksionojë*.
Nëse të dhënat janë me kardinalitet të lartë, atëherë mos u shqetësoni, ruajini ato në një formë të denormalizuar, URL-të janë direkt në vend në tabelën kryesore.
* dhe tani ClickHouse ka gjithashtu një bashkim të bashkimit dhe funksionon në kushte kur të dhënat e ndërmjetme nuk futen në RAM. Por kjo është joefektive dhe rekomandimi mbetet në fuqi.
Edhe nja dy shembuj, por tashmë dyshoj nëse janë kundër modelit apo jo.
ClickHouse ka një të metë të njohur. Nuk di të përditësojë*. Në disa mënyra, kjo është edhe e mirë. Nëse keni disa të dhëna të rëndësishme, për shembull, kontabilitetin, atëherë askush nuk do të jetë në gjendje t'i dërgojë ato, sepse nuk ka përditësime.
* Mbështetja për përditësimin dhe fshirjen në modalitetin e grupit është shtuar shumë kohë më parë.
Por ka disa mënyra të veçanta që lejojnë përditësimet sikur në sfond. Për shembull, tabela si ReplaceMergeTree. Ata bëjnë përditësime gjatë bashkimeve të sfondit. Ju mund ta detyroni këtë duke përdorur tabelën e optimizimit. Por mos e bëni këtë shumë shpesh, sepse do ta mbishkruajë plotësisht ndarjen.
JOIN-et e shpërndara në ClickHouse trajtohen gjithashtu keq nga planifikuesi i pyetjeve.
E keqe, por ndonjëherë në rregull.
Përdorimi i ClickHouse vetëm për të lexuar të dhënat duke përdorur Select*.
Unë nuk do të rekomandoja përdorimin e ClickHouse për llogaritjet e rënda. Por kjo nuk është plotësisht e vërtetë, sepse ne tashmë po largohemi nga ky rekomandim. Dhe së fundmi kemi shtuar aftësinë për të aplikuar modele të mësimit të makinerive në ClickHouse - Catboost. Dhe më shqetëson sepse mendoj: “Çfarë tmerri. Ja sa cikle për bajt rezulton! Unë vërtet e urrej humbjen e orëve në bajt.
Por mos kini frikë, instaloni ClickHouse, gjithçka do të jetë mirë. Nëse ka ndonjë gjë, ne kemi një komunitet. Nga rruga, komuniteti jeni ju. Dhe nëse keni ndonjë problem, të paktën mund të shkoni në bisedën tonë dhe shpresojmë se ata do t'ju ndihmojnë.
Pyetjet tuaja
Faleminderit për raportin! Ku mund të ankohem për rrëzimin e ClickHouse?
Mund të më ankoheni personalisht tani.
Kohët e fundit kam filluar të përdor ClickHouse. Menjëherë hoqa ndërfaqen cli.
Çfarë rezultati.
Pak më vonë e prisha serverin me një përzgjedhje të vogël.
Ju keni talent.
Hapa një gabim të GitHub, por ai u shpërfill.
Do ta shohim.
Alexey më mashtroi për të marrë pjesë në raport, duke më premtuar se do të më tregonte se si i qaseni të dhënave brenda.
Shumë e thjeshtë.
Këtë e kuptova dje. Më shumë specifika.
Nuk ka truke të tmerrshme atje. Ka vetëm kompresim bllok pas blloku. Parazgjedhja është LZ4, mund të aktivizoni ZSTD*. Bllokon nga 64 kilobajt në 1 megabajt.
* Ekziston gjithashtu mbështetje për kodekët e specializuar të kompresimit që mund të përdoren në një zinxhir me algoritme të tjera.
A janë blloqet thjesht të dhëna të papërpunuara?
Jo plotësisht i papërpunuar. Ka vargje. Nëse keni një kolonë numerike, atëherë numrat në një rresht vendosen në një grup.
Është e qartë.
Alexey, një shembull që ishte me uniqExact mbi IP-të, pra fakti që uniqExact merr më shumë kohë për t'u llogaritur me rreshta sesa me numra, e kështu me radhë. Po sikur të përdorim një shtirje me veshët tanë dhe të hedhim në kohën e korrigjimit? Kjo është, ju duket se keni thënë se në diskun tonë nuk është shumë ndryshe. Nëse lexojmë rreshta nga disku dhe hedhim, a do të jenë agregatët tanë më të shpejtë apo jo? Apo do të fitojmë pak këtu? Më duket se e keni testuar këtë, por për disa arsye nuk e treguat atë në pikë referimi.
Unë mendoj se do të jetë më i ngadalshëm se pa casting. Në këtë rast, adresa IP duhet të analizohet nga vargu. Sigurisht, në ClickHouse, analizimi i adresës sonë IP është gjithashtu i optimizuar. Ne u përpoqëm shumë, por atje i keni numrat të shkruar në formën e dhjetëmijtë. Shumë e pakëndshme. Nga ana tjetër, funksioni uniqExact do të funksionojë më ngadalë në vargje, jo vetëm sepse këto janë vargje, por edhe sepse është zgjedhur një specializim i ndryshëm i algoritmit. Vargjet thjesht përpunohen ndryshe.
Po sikur të marrim një lloj të dhënash më primitiv? Për shembull, ne shënuam ID-në e përdoruesit, të cilin e kemi, e shkruajmë si rresht dhe më pas e gërvishtëm, do të jetë më argëtues apo jo?
Dyshoj. Mendoj se do të jetë edhe më e trishtueshme, sepse në fund të fundit, analizimi i numrave është një problem serioz. Më duket se ky koleg madje ka dhënë një raport se sa e vështirë është të analizosh numrat në formën e dhjetë mijëshe, por ndoshta jo.
Alexey, faleminderit shumë për raportin! Dhe faleminderit shumë për ClickHouse! Kam një pyetje për planet. A ka ndonjë plan që një veçori të përditësojë fjalorët në mënyrë jo të plotë?
Kjo është, një rindezje e pjesshme?
Po Po. Ashtu si aftësia për të vendosur një fushë MySQL atje, d.m.th. përditësimi më pas në mënyrë që vetëm këto të dhëna të ngarkohen nëse fjalori është shumë i madh.
Një veçori shumë interesante. Dhe unë mendoj se dikush e sugjeroi atë në bisedën tonë. Ndoshta ishe edhe ti.
Unë nuk mendoj kështu.
E shkëlqyeshme, tani rezulton se ka dy kërkesa. Dhe ngadalë mund të filloni ta bëni atë. Por unë dua t'ju paralajmëroj menjëherë se kjo veçori është mjaft e thjeshtë për t'u zbatuar. Kjo do të thotë, në teori, ju vetëm duhet të shkruani numrin e versionit në tabelë dhe më pas të shkruani: version më i vogël se i tillë dhe i tillë. Kjo do të thotë që, ka shumë të ngjarë, ne do t'ua ofrojmë këtë entuziastëve. A jeni një entuziast?
Po, por, për fat të keq, jo në C++.
A dinë kolegët tuaj të shkruajnë në C++?
Unë do të gjej dikë.
E shkëlqyeshme*.
* funksioni u shtua dy muaj pas raportit - autori i pyetjes e zhvilloi atë dhe e dërgoi të tijën .
Ju faleminderit!
Përshëndetje! Faleminderit për raportin! Ju përmendët se ClickHouse është shumë i mirë në konsumimin e të gjitha burimeve të disponueshme për të. Dhe folësi pranë Luxoft foli për zgjidhjen e tij për Russian Post. Ai tha se atyre u pëlqente shumë ClickHouse, por ata nuk e përdorën atë në vend të konkurrentit të tyre kryesor, pikërisht sepse po hante të gjithë CPU-në. Dhe ata nuk mund ta lidhnin atë në arkitekturën e tyre, në ZooKeeper-in e tyre me dokerë. A është e mundur të kufizohet disi ClickHouse në mënyrë që të mos konsumojë gjithçka që bëhet e disponueshme për të?
Po, është e mundur dhe shumë e lehtë. Nëse dëshironi të konsumoni më pak bërthama, atëherë thjesht shkruani set max_threads = 1. Dhe kjo është ajo, ajo do të ekzekutojë kërkesën në një bërthamë. Për më tepër, mund të specifikoni cilësime të ndryshme për përdorues të ndryshëm. Pra nuk ka problem. Dhe tregoni kolegëve tuaj nga Luxoft se nuk është mirë që nuk e gjetën këtë cilësim në dokumentacion.
Alexey, përshëndetje! Do të doja të pyesja për këtë pyetje. Kjo nuk është hera e parë që kam dëgjuar që shumë njerëz kanë filluar të përdorin ClickHouse si ruajtje për regjistrat. Në raport ju thatë të mos e bëni këtë, d.m.th. nuk keni nevojë të ruani vargje të gjata. Çfarë mendoni ju në lidhje me të?
Së pari, shkrimet, si rregull, nuk janë vargje të gjata. Ka, natyrisht, përjashtime. Për shembull, një shërbim i shkruar në java hedh një përjashtim, ai regjistrohet. Dhe kështu me radhë në një lak të pafund, dhe hapësira në hard disk mbaron. Zgjidhja është shumë e thjeshtë. Nëse linjat janë shumë të gjata, atëherë prijini ato. Çfarë do të thotë gjatë? Dhjetëra kilobajt janë të këqija*.
* në versionet më të fundit të ClickHouse, është aktivizuar "granulariteti i indeksit adaptiv", i cili eliminon problemin e ruajtjes së rreshtave të gjata në pjesën më të madhe.
A është një kilobajt normal?
Normal.
Përshëndetje! Faleminderit për raportin! Unë tashmë e pyeta për këtë në chat, por nuk mbaj mend nëse mora një përgjigje. A ka plane për të zgjeruar disi seksionin ME në mënyrën e CTE?
Ende jo. Seksioni ynë ME është disi joserioz. Është si një veçori e vogël për ne.
e kuptoj. Faleminderit!
Faleminderit për raportin! Shumë interesante! Pyetje globale. A ka ndonjë plan për të modifikuar fshirjen e të dhënave, ndoshta në formën e një lloj cung?
Domosdoshmërisht. Kjo është detyra jonë e parë në radhën tonë. Tani po mendojmë në mënyrë aktive se si të bëjmë gjithçka në mënyrë korrekte. Dhe duhet të filloni të shtypni tastierën*.
* shtypi butonat në tastierë dhe bëri gjithçka.
A do të ndikojë kjo disi në performancën e sistemit apo jo? A do të jetë futja aq shpejt sa është tani?
Ndoshta vetë fshirjet dhe vetë përditësimet do të jenë shumë të rënda, por kjo nuk do të ndikojë në performancën e përzgjedhjeve ose performancën e inserteve.
Dhe një pyetje tjetër e vogël. Në prezantim folët për çelësin primar. Prandaj, ne kemi ndarje, e cila është mujore si parazgjedhje, apo jo? Dhe kur vendosim një interval datash që përshtatet në një muaj, atëherë lexohet vetëm kjo ndarje, apo jo?
Po.
Një pyetje. Nëse nuk mund të zgjedhim asnjë çelës primar, atëherë a është e saktë ta bëjmë atë në mënyrë specifike sipas fushës "Data" në mënyrë që në sfond të ketë më pak rirregullim të këtyre të dhënave në mënyrë që të përshtaten në një mënyrë më të rregullt? Nëse nuk keni pyetje për intervalin dhe nuk mund të zgjidhni as ndonjë çelës primar, a ia vlen të vendosni një datë në çelësin kryesor?
Po.
Ndoshta ka kuptim të vendosësh një fushë në çelësin primar që do t'i kompresojë të dhënat më mirë nëse ato renditen sipas kësaj fushe. Për shembull, ID e përdoruesit. Përdoruesi, për shembull, shkon në të njëjtin sajt. Në këtë rast, vendosni ID-në e përdoruesit dhe kohën. Dhe atëherë të dhënat tuaja do të kompresohen më mirë. Sa i përket datës, nëse vërtet nuk keni dhe nuk keni kurrë pyetje për datat, atëherë nuk keni pse ta vendosni datën në çelësin kryesor.
Mirë, faleminderit shumë!
Burimi: www.habr.com