{"id":89878,"date":"2020-07-27T01:42:42","date_gmt":"2020-07-26T23:42:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g"},"modified":"2020-07-27T01:42:42","modified_gmt":"2020-07-26T23:42:42","slug":"teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g","title":{"rendered":"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/b46b964324a3311157d5df737526b1d1.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selvom data nu findes n\u00e6sten overalt, er analytiske databaser stadig ret eksotiske. De er d\u00e5rligt kendt, og det er endnu v\u00e6rre med effektiv brug. Mange forts\u00e6tter med at \"spise kaktus\" med MySQL eller PostgreSQL, der er designet til andre scenarier, at k\u00e6mpe med NoSQL eller at betale for dyre kommercielle l\u00f8sninger. ClickHouse \u00e6ndrer spillereglerne og s\u00e6nker betydeligt indgangsbarrieren til verden af analytiske DBMS.<\/p>\n<p><\/p>\n<p>Dette er en pr\u00e6sentation fra BackEnd Conf 2018 og er offentliggjort med foredragsholderens tilladelse.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"9MwKE30aUPs\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/9MwKE30aUPs\/hqdefault.jpg\" alt=\"Afspil video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/6c55b639d9703f460d99e0b0b1194507.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHvem er jeg, og hvorfor taler jeg om ClickHouse? Jeg er udviklingsdirekt\u00f8r hos LifeStreet, som bruger ClickHouse. Desuden er jeg grundl\u00e6gger af Altinity. Dette er en partner til Yandex, der promoverer ClickHouse og hj\u00e6lper Yandex med at g\u00f8re ClickHouse mere succesfuld. Jeg er ogs\u00e5 klar til at dele min viden om ClickHouse. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/36af6acba62271f7aa19dda2eb470870.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og jeg er ikke bror til Petja Zaitsev. Jeg bliver ofte spurgt om det. Nej, vi er ikke br\u00f8dre.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/6ca605f97619a1373bb8a92f88d480d5.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00bbAlle ved\u00ab, at ClickHouse:<\/p>\n<p><\/p>\n<ul>\n<li>Er meget hurtig,<\/li>\n<li>Er meget brugervenlig, <\/li>\n<li>Bruges i Yandex. <\/li>\n<\/ul>\n<p><\/p>\n<p>Lidt mindre kendt er, i hvilke virksomheder og hvordan det bruges. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/c097b003bf8ea13b8a3bb765270e99c8.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Jeg vil fort\u00e6lle jer, hvad, hvor og hvordan ClickHouse bruges, udover Yandex. <\/p>\n<p><\/p>\n<p>Jeg vil fort\u00e6lle, hvordan specifikke opgaver l\u00f8ses med ClickHouse i forskellige virksomheder, hvilke v\u00e6rkt\u00f8jer ClickHouse kan bruges til i jeres opgaver, og hvordan de er blevet brugt i forskellige virksomheder.<\/p>\n<p><\/p>\n<p>Jeg har fundet tre eksempler, der viser ClickHouse fra forskellige vinkler. Jeg tror, det vil v\u00e6re interessant.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/d3cab92ceccd6c7d01ca1f28b028803f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Det f\u00f8rste sp\u00f8rgsm\u00e5l: \"Hvorfor er ClickHouse n\u00f8dvendigt?\" Det virker som et ret \u00e5benlyst sp\u00f8rgsm\u00e5l, men der er mere end \u00e9t svar p\u00e5 det. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/1a4e14cc041a3c01ad0fd2a305aeeab0.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Det f\u00f8rste svar \u2013 p\u00e5 grund af ydeevnen. ClickHouse er meget hurtig. Analyse med ClickHouse er ogs\u00e5 meget hurtig. Den kan ofte bruges der, hvor noget andet fungerer meget langsomt eller meget d\u00e5rligt. <\/li>\n<li>Det andet svar \u2013 det er omkostningerne. Og i f\u00f8rste omgang omkostningerne ved skalering. For eksempel er Vertica en fremragende database. Den fungerer rigtig godt, hvis du har ikke s\u00e5 mange terabyte data. Men n\u00e5r det drejer sig om hundreder af terabyte eller petabyte, bliver licens- og supportomkostningerne ret betydelige. Og det er dyrt. ClickHouse derimod er gratis. <\/li>\n<li>Den tredje respons er driftsomkostningen. Dette er en tilgang set fra en lidt anden vinkel. RedShift er et fremragende alternativ. Med RedShift kan man hurtigt finde en l\u00f8sning. Det vil fungere godt, men man vil hver time, hver dag og hver m\u00e5ned betale en relativt h\u00f8j pris til Amazon, fordi det er en betydeligt dyr service. Google BigQuery ogs\u00e5. Hvis nogen har brugt det, ved de, at man kan k\u00f8re flere foresp\u00f8rgsler og pludselig f\u00e5 en regning p\u00e5 hundrede dollars. <\/li>\n<\/ul>\n<p><\/p>\n<p>I ClickHouse er der ikke disse problemer. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/3084a8bd9271f14726d73989946816c5.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvor bruges ClickHouse nu? Udover Yandex bruges ClickHouse i mange forskellige forretninger og virksomheder. <\/p>\n<p><\/p>\n<ul>\n<li>F\u00f8rst og fremmest til analyse af webapplikationer, dvs. det er et use case, der kommer fra Yandex.<\/li>\n<li>Mange AdTech-virksomheder bruger ClickHouse. <\/li>\n<li>Talrige virksomheder, der har brug for at analysere driftslogger fra forskellige kilder.<\/li>\n<li>Flere virksomheder bruger ClickHouse til overv\u00e5gning af sikkerhedslogs. De uploader dem til ClickHouse, laver rapporter og f\u00e5r de n\u00f8dvendige resultater.<\/li>\n<li>Virksomheder begynder at bruge det til finansiel analyse; dvs. gradvist ogs\u00e5 store virksomheder n\u00e6rmer sig ClickHouse. <\/li>\n<li>CloudFlare. Hvis nogen f\u00f8lger med i ClickHouse, har de nok h\u00f8rt om denne virksomhed. Det er en af de v\u00e6sentlige bidragydere fra community'et. Og de har en meget seri\u00f8s ClickHouse-installation. For eksempel har de lavet Kafka Engine til ClickHouse. <\/li>\n<li>Telekommunikationsfirmaer er begyndt at bruge det. Flere virksomheder bruger ClickHouse enten som proof of concept eller allerede i produktion.<\/li>\n<li>\u00c9n virksomhed bruger ClickHouse til overv\u00e5gning af produktionsprocesser. De tester mikrochips, registrerer mange parametre, omkring 2.000 karakteristika, og analyserer derefter \u2013 er det en god eller d\u00e5rlig batch.<\/li>\n<li>Blockchain-analyse. Der er et russisk firma ved navn Bloxy.info. Dette er analyse af Ethereum-netv\u00e6rket. De har ogs\u00e5 lavet det p\u00e5 ClickHouse. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/8a0c1924a20ed2d15cd0f959e9b3e499.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Desuden har st\u00f8rrelsen ingen betydning. Der er mange virksomheder, der bruger en lille server. Og den tillader dem at l\u00f8se deres problemer. Endnu flere virksomheder bruger store klynger af mange <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1513\">servere<\/a> eller dusinvis af servere. <\/p>\n<p><\/p>\n<p>Og hvis man ser p\u00e5 rekorderne:<\/p>\n<p><\/p>\n<ul>\n<li>Yandex: 500+ servere, de gemmer 25 milliarder poster om dagen.<\/li>\n<li>LifeStreet: 60 servere, cirka 75 milliarder poster om dagen. F\u00e6rre servere, flere poster end i Yandex. <\/li>\n<li>CloudFlare: 36 servere, de gemmer 200 milliarder poster om dagen. De har f\u00e6rre servere og gemmer endnu mere data. <\/li>\n<li>Bloomberg: 102 <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/dts-los-angeles\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3643\">server<\/a>, omtrent en billion poster om dagen. Rekordholder for poster.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/49194030b6586221cb17029889ce33da.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Geografisk set er det ogs\u00e5 meget. Kortet her viser heatmap, hvor ClickHouse bruges i verden. Her fremh\u00e6ves Rusland, Kina, Amerika tydeligt. Der er f\u00e5 europ\u00e6iske lande. Og vi kan udpege 4 klynger.<\/p>\n<p><\/p>\n<p>Dette er en komparativ analyse, her skal man ikke lede efter absolutte tal. Det er en analyse af bes\u00f8gende, der l\u00e6ser engelsksprogede materialer p\u00e5 Altinitys hjemmeside, fordi der ikke er nogen russisktalende der. Rusland, Ukraine, Hviderusland, alts\u00e5 den russisk talende del af samfundet, er de mest talrige brugere. Derefter f\u00f8lger USA og Canada. Kina n\u00e6rmer sig meget hurtigt. For seks m\u00e5neder siden var Kina n\u00e6sten ikke til stede, nu har Kina allerede overhalet Europa og forts\u00e6tter med at vokse. Gamle Europa h\u00e6nger heller ikke bagefter, og overraskende nok er Frankrig lederen i brugen af ClickHouse. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/3a8305c51b1bd62f3467b795402df4ed.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><strong>Hvorfor fort\u00e6ller jeg alt dette? For at vise, at ClickHouse bliver en standardl\u00f8sning til analyse af store data og allerede bruges mange steder.<\/strong> Hvis du bruger det, er du med p\u00e5 den rigtige trend. Hvis du endnu ikke bruger det, beh\u00f8ver du ikke frygte at st\u00e5 alene, og at der ikke er nogen, der vil hj\u00e6lpe dig, for mange besk\u00e6ftiger sig allerede med det.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/6aa635f3a35034d3af837c78b2c8fe60.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dette er eksempler p\u00e5 reel brug af ClickHouse i flere virksomheder. <\/p>\n<p><\/p>\n<ul>\n<li>Det f\u00f8rste eksempel er et annoncesystem: migration fra Vertica til ClickHouse. Jeg kender flere virksomheder, der har skiftet fra Vertica eller er i gang med at skifte. <\/li>\n<li>Det andet eksempel er et transaktionslager p\u00e5 ClickHouse. Dette eksempel er bygget p\u00e5 antipatterns. Alt, hvad man ikke skal g\u00f8re i ClickHouse if\u00f8lge udviklernes r\u00e5d, er gjort her. Og alligevel er det gjort s\u00e5 effektivt, at det fungerer. Og det fungerer langt bedre end en typisk transaktionel l\u00f8sning. <\/li>\n<li>Det tredje eksempel er distribuerede beregninger p\u00e5 ClickHouse. Der var et sp\u00f8rgsm\u00e5l om, hvordan ClickHouse kan integreres i Hadoop-\u00f8kosystemet. Jeg vil vise et eksempel p\u00e5, hvordan en virksomhed har lavet noget, der ligner en map-reduce beholder p\u00e5 ClickHouse, mens de holder \u00f8je med dataenes lokalisering osv., for at l\u00f8se en meget ikke-triviel opgave. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/e08ab5418500599f08d40324ccdfbcd0.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>LifeStreet \u2013 Dette er et Ad Tech-firma, der har alle de teknologier, der er forbundet med et annoncesystem. <\/li>\n<li>Det besk\u00e6ftiger sig med optimering af annoncer, programmatisk budgivning. <\/li>\n<li>Store data: around 10 billion events per day. At the same time, these events can be split into several sub-events.<\/li>\n<li>Many clients require this data, and it\u2019s not just people; there are numerous algorithms involved in programmatic bidding. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/2da99b53eb25f675a2431027f86db934.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The company has gone through a long and challenging path. I shared details about it at HighLoad. Initially, LifeStreet transitioned from MySQL (with a brief stop at Oracle) to Vertica. You can find more about it. <\/p>\n<p><\/p>\n<p>Everything was going well, but it quickly became clear that data was growing and Vertica was expensive. Therefore, various alternatives were sought. Some of them are listed here. In fact, we conducted a proof of concept or performance testing for almost all databases available in the market from 2013 to 2016 that roughly matched our functional requirements. I discussed some of them at HighLoad as well.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/4bebd2f43892cbef9249ddded1b8a70a.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The task was to migrate from Vertica first because data was growing. It grew exponentially for several years. Then it leveled off, but nevertheless. Anticipating this growth, and the business requirements for the volume of data to be analyzed, it was clear that discussions about petabytes would soon arise. And paying for petabytes is very costly, so we were looking for an alternative. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/f170a4307168e8560122966eab85c24e.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Where to go? For a long time, it was completely unclear where to go, because on one hand, there are commercial databases that seem to work quite well. Some perform almost as well as Vertica, while others are less effective. But they are all expensive, and nothing cheaper or better could be found. <\/p>\n<p><\/p>\n<p>On the other hand, there are a few open-source solutions which can be counted on your fingers for analytics. They are free or inexpensive, but operate slowly. Additionally, they often lack the necessary and useful functionalities.<\/p>\n<p><\/p>\n<p>And to find something that combines the best features of commercial databases and everything available in open source \u2014 there was nothing. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/abbefbf0d9578b554f81579b87213a50.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>There was nothing until Yandex unexpectedly pulled ClickHouse out like a rabbit from a magician's hat. It was an unexpected solution, and questions like 'Why?' are still being asked, but nonetheless. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/c88981aace9d5925396ca5171241b7d2.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og straks sommeren 2016 begyndte vi at se, hvad ClickHouse kunne. Og det viste sig, at det nogle gange kan v\u00e6re hurtigere end Vertica. Vi testede forskellige scenarier med forskellige foresp\u00f8rgsler. Og hvis foresp\u00f8rgslen kun brugte \u00e9n tabel, alts\u00e5 uden nogen join, s\u00e5 var ClickHouse to gange hurtigere end Vertica. <\/p>\n<p><\/p>\n<p>Jeg gad ikke se bort fra, at jeg kiggede p\u00e5 Yandex' tests for nylig. Der var det det samme: ClickHouse var to gange hurtigere end Vertica, og derfor taler de ofte om det. <\/p>\n<p><\/p>\n<p>Men hvis der er joins i foresp\u00f8rgslerne, s\u00e5 bliver alt lidt mere uklart. Og ClickHouse kan v\u00e6re to gange langsommere end Vertica. Hvis vi justerer foresp\u00f8rgslen lidt og omskriver den, s\u00e5 bliver de nogenlunde lige. Ikke d\u00e5rligt. Og gratis. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/188bf56b72123175a18d2cb97d989a47.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og efter at have f\u00e5et testresultaterne og set p\u00e5 det fra forskellige vinkler, tog LifeStreet over til ClickHouse.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/1183b9b7681916686c52786fc95ccb45.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dette er 2016, husk. Det var som i en anekdote om musene, der gr\u00e6d og stak sig, men fortsatte med at spise kaktussen. Og dette blev beskrevet i detaljer, der findes videoer om det osv. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/993052ed83dc295c3777e614c7703456.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Derfor vil jeg ikke g\u00e5 i detaljer om det, men kun fort\u00e6lle om resultaterne og nogle interessante ting, som jeg ikke n\u00e6vnte dengang. <\/p>\n<p><\/p>\n<p>Resultaterne er:<\/p>\n<p><\/p>\n<ul>\n<li>En vellykket migration, og systemet har allerede v\u00e6ret i produktion i mere end et \u00e5r. <\/li>\n<li>Ydelsen og fleksibiliteten er steget. Af de 10 milliarder poster, vi kunne tillade os at opbevare p\u00e5 en dag, men kun i kort tid, opbevarer LifeStreet nu 75 milliarder poster p\u00e5 en dag og kan g\u00f8re det i 3 m\u00e5neder eller mere. I spidsbelastning er det op til en million h\u00e6ndelser pr. sekund, der gemmes. Mere end en million SQL-foresp\u00f8rgsler ankommer til dette system hver dag, prim\u00e6rt fra forskellige bots. <\/li>\n<li>P\u00e5 trods af at der blev brugt flere servere til ClickHouse end til Vertica, opn\u00e5ede vi besparelser p\u00e5 hardware, fordi Vertica brugte ret dyre SAS-diske. I ClickHouse blev der brugt SATA. Og hvorfor? Fordi vertica-inserts er synkrone. Og synkronisering kr\u00e6ver, at diskene ikke bremser for meget, og at netv\u00e6rket heller ikke bremser meget, det er en relativt dyr operation. Men i ClickHouse er insert asynkrone. Desuden kan man altid skrive lokalt, der er ingen ekstra omkostninger ved det, s\u00e5 data kan inds\u00e6ttes i ClickHouse meget hurtigere end i Vertica, selv p\u00e5 ikke de hurtigste diske. L\u00e6sning er omtrent den samme. L\u00e6sning p\u00e5 SATA, hvis de er i RAID, s\u00e5 g\u00e5r det hele ret hurtigt. <\/li>\n<li>Uden licensbegr\u00e6nsninger, dvs. 3 petabyte data p\u00e5 60 servere (20 servere \u2013 en kopi) og 6 trillioner optegnelser i fakta og aggregationer. Intet lignende kunne lade sig g\u00f8re p\u00e5 Vertica. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/f461cdc12917ee655655dd7eb9c32bb2.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nu g\u00e5r jeg videre til de praktiske aspekter i dette eksempel.<\/p>\n<p><\/p>\n<ul>\n<li>Det f\u00f8rste er et effektivt schema. Schemat afh\u00e6nger af meget. <\/li>\n<li>Det andet er generation af effektiv SQL.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/e7dc2a217e77c8794ff6e8a754e78c85.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>En typisk OLAP-foresp\u00f8rgsel er en select. Nogle kolonner g\u00e5r til group by, mens andre kolonner bruges i aggregatfunktioner. Der er en where-klausul, som kan betragtes som et udsnit af kuben. Hele group by kan ses som en projektion. Derfor kaldes det multimensionel dataanalyse. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/a03a2d7fd28905ae83183346f0c673e2.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Oftest modelleres dette i form af et star-schema, hvor der er et centralt faktum og karakteristika for dette faktum i retningerne. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/d9671af4b39cc83e1ae49e6fd75d0e02.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og med hensyn til det fysiske design, dvs. hvordan det placeres i tabellen, laves der normalt en normaliseret repr\u00e6sentation. Du kan denormalisere, men det er dyrt i diskplads og ikke s\u00e6rlig effektivt med foresp\u00f8rgsler. Derfor laver man normalt en normaliseret repr\u00e6sentation, dvs. en fakta-tabel og mange-mange dimensions-tabeller. <\/p>\n<p><\/p>\n<p>Men i ClickHouse fungerer dette d\u00e5rligt. Der er to grunde: <\/p>\n<p><\/p>\n<ul>\n<li>Den f\u00f8rste er, at ClickHouse ikke har s\u00e6rligt gode joins, dvs. der findes joins, men de er d\u00e5rlige. Indtil videre er de d\u00e5rlige. <\/li>\n<li>Den anden grund er, at tabellerne ikke opdateres. Normalt i disse sm\u00e5 tabeller omkring star-schemaet, skal der \u00e6ndres noget. For eksempel kunde-navn, firmanavn osv. Og det fungerer ikke. <\/li>\n<\/ul>\n<p><\/p>\n<p>Og der er en l\u00f8sning p\u00e5 dette i ClickHouse. Faktisk er der to: <\/p>\n<p><\/p>\n<ul>\n<li>Det f\u00f8rste er brugen af ordb\u00f8ger. Eksterne ordb\u00f8ger er noget, der hj\u00e6lper med at l\u00f8se problemet med star-schemaet, opdateringer osv. med 99 %. <\/li>\n<li>Det andet er brugen af arrays. Arrays hj\u00e6lper ogs\u00e5 med at slippe for joins og problemer med normalisering. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/775972cc412651600799173407384492.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Joins er ikke n\u00f8dvendige. <\/li>\n<li>Opdaterbare. Fra marts 2018 blev der introduceret en uudokumenteret mulighed (du finder det ikke i dokumentationen) for delvist at opdatere ordb\u00f8ger, dvs. de optegnelser, der er \u00e6ndret. For praktisk talt er det som en tabel.<\/li>\n<li>Altid i hukommelsen, derfor fungerer joins med ordb\u00f8ger hurtigere end hvis det var en tabel, der ligger p\u00e5 disken, og man kan ikke v\u00e6re sikker p\u00e5, at den er i cache, sandsynligvis er den ikke. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/f73176a650b6d885011e3265c2af2fc3.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Joins er ogs\u00e5 ikke n\u00f8dvendige.<\/li>\n<li>Dette er en kompakt repr\u00e6sentation 1 til mange. <\/li>\n<li>Og efter min mening er arrays lavet til n\u00f8rder. Det er lambda-funktioner og andet. <\/li>\n<\/ul>\n<p><\/p>\n<p>Dette er ikke bare for at sige det. Det er en meget kraftfuld funktionalitet, der g\u00f8r mange ting meget enkelt og elegant. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/5d813952ca8f3da7a74c6f2a15d80a9b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Typiske eksempler, der hj\u00e6lper med at h\u00e5ndtere arrays. Disse eksempler er enkle og ret illustrative:<\/p>\n<p><\/p>\n<ul>\n<li>S\u00f8gning efter tags. Hvis du har hashtags der, og du vil finde nogle indl\u00e6g efter hashtag. <\/li>\n<li>S\u00f8gning efter key-value par. Der er ogs\u00e5 nogle attributter med v\u00e6rdier. <\/li>\n<li>Opbevaring af lister med n\u00f8gler, som du skal overs\u00e6tte til noget andet.<\/li>\n<\/ul>\n<p><\/p>\n<p>Alle disse opgaver kan l\u00f8ses uden arrays. Tags kan placeres i en enkelt linje og v\u00e6lges med et regul\u00e6rt udtryk, eller i en separat tabel, men s\u00e5 skal du lave joins.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/dbbf90eee098c4564206532f24156823.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I ClickHouse skal du ikke g\u00f8re noget, det er nok at beskrive et array af string til hashtags, eller lave en indlejret struktur til systemer af typen key-value.<\/p>\n<p><\/p>\n<p>Indlejret struktur \u2013 det er m\u00e5ske ikke det bedste navn. Det er to arrays, der har en f\u00e6lles del i navnet og nogle relaterede egenskaber. <\/p>\n<p><\/p>\n<p>Og det er meget enkelt at s\u00f8ge efter tags. Der er en funktion <code>has<\/code>, der kontrollerer, om der er et element i arrayet. Vi har fundet alle indl\u00e6g, der relaterer sig til vores konference.<\/p>\n<p><\/p>\n<p>S\u00f8gningen efter subid er lidt mere kompliceret. Vi skal f\u00f8rst finde indekset af n\u00f8glen, og derefter tage elementet med dette indeks og kontrollere, at v\u00e6rdien er den, vi har brug for. Men det er stadig meget enkelt og kompakt.<\/p>\n<p><\/p>\n<p>Det regul\u00e6re udtryk, du ville skrive, hvis du gemte alt dette i en enkelt linje, ville for det f\u00f8rste v\u00e6re klodset. Og for det andet ville det tage meget l\u00e6ngere tid at k\u00f8re end to arrays. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/17664c3121b2b0d33188adbfaa653d4e.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Et andet eksempel. Du har et array, hvor du gemmer ID'er. Og du kan overs\u00e6tte dem til navne. Funktionen <code>arrayMap<\/code>. Dette er en typisk lambda-funktion. Du sender lambda-udtryk dertil. Og den henter v\u00e6rdien af navnet for hver ID fra ordbogen.<\/p>\n<p><\/p>\n<p>P\u00e5 samme m\u00e5de kan du lave en s\u00f8gning. En pr\u00e6dikatsfunktion sendes ind, der kontrollerer, hvad elementerne svarer til. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/146917b71a35d38a550cd9accf6ab2f7.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Disse ting forenkler helt klart skemaet og l\u00f8ser mange problemer. <\/p>\n<p><\/p>\n<p>Men det n\u00e6ste problem, vi st\u00f8dte p\u00e5, og som jeg gerne vil n\u00e6vne, er effektive foresp\u00f8rgsler. <\/p>\n<p><\/p>\n<ul>\n<li>I ClickHouse er der ingen foresp\u00f8rgselsplanl\u00e6gger. Overhovedet ikke. <\/li>\n<li>Men komplekse foresp\u00f8rgsler skal stadig planl\u00e6gges. I hvilke tilf\u00e6lde? <\/li>\n<li>Hvis foresp\u00f8rgslen indeholder flere joins, som du pakker ind i underforesp\u00f8rgsler, s\u00e5 har r\u00e6kkef\u00f8lgen, de udf\u00f8res i, betydning. <\/li>\n<li>Og for det andet \u2013 hvis foresp\u00f8rgslen er distribueret. Fordi i en distribueret foresp\u00f8rgsel udf\u00f8res kun den inderste underforesp\u00f8rgsel distribueret, mens alt andet sendes til en server, som du er tilsluttet, og udf\u00f8res der. Derfor, hvis du har distribuerede foresp\u00f8rgsler med mange joins, er det vigtigt at v\u00e6lge r\u00e6kkef\u00f8lgen. <\/li>\n<\/ul>\n<p><\/p>\n<p>Og selv i enklere tilf\u00e6lde kan det nogle gange v\u00e6re n\u00f8dvendigt at udf\u00f8re planl\u00e6gningsarbejdet og \u00e6ndre foresp\u00f8rgslerne en smule. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/217d422b429e8b4bc13abbf0efdf6be1.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Her er et eksempel. I venstre side er der en foresp\u00f8rgsel, der viser de 5 bedste lande. Og den tager 2,5 sekunder, mener jeg. P\u00e5 h\u00f8jre side er den samme foresp\u00f8rgsel, men lidt \u00e6ndret. Vi er i stedet for at gruppere efter streng, begyndt at gruppere efter n\u00f8gle (int). Og det er hurtigere. Derefter tilsluttede vi en ordbog til resultatet. I stedet for 2,5 sekunder tager foresp\u00f8rgslen 1,5 sekunder. Det er godt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/f19fb7d7f0397a3b38b2a3bd179c156b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Et lignende eksempel med omskrivning af filtre. Her er der en foresp\u00f8rgsel om Rusland. Den tager 5 sekunder. Hvis vi omskriver den p\u00e5 en m\u00e5de, s\u00e5 vi sammenligner igen ikke streng, men tal med et s\u00e6t af de n\u00f8gler, der relaterer til Rusland, s\u00e5 vil det v\u00e6re meget hurtigere. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/0c1dd1f317133d1d106ffef85f337079.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der er mange s\u00e5danne tricks. Og de g\u00f8r det muligt at v\u00e6sentligt fremskynde foresp\u00f8rgsler, som du m\u00e5ske tror allerede fungerer hurtigt, eller omvendt, fungerer langsomt. De kan g\u00f8res endnu hurtigere.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/25b132790b03f239e38237af5e92ab63.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Maksimal arbejdsindsats i distribueret tilstand. <\/li>\n<li>Sortering efter de mindste typer, som jeg gjorde med int. <\/li>\n<li>Hvis der er nogen joins, ordb\u00f8ger, er det bedst at lave dem som det sidste, n\u00e5r du allerede har data, der i det mindste er delvist grupperet, s\u00e5 vil join- eller ordbogsoperationen blive kaldt f\u00e6rre gange, og det vil v\u00e6re hurtigere. <\/li>\n<li>Udskiftning af filtre. <\/li>\n<\/ul>\n<p><\/p>\n<p>Der er ogs\u00e5 andre teknikker, ikke kun dem, jeg har vist. Og alle disse tillader nogle gange at v\u00e6sentligt fremskynde udf\u00f8relsen af foresp\u00f8rgsler.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/175832796bee525909d8875bd723a881.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lad os g\u00e5 videre til det n\u00e6ste eksempel. Firma X fra USA. Hvad g\u00f8r det? <\/p>\n<p><\/p>\n<p>Opgaven var: <\/p>\n<p><\/p>\n<ul>\n<li>Offline forbindelser mellem reklame transaktioner. <\/li>\n<li>Modellering af forskellige forbindelsesmodeller. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/0136b71a1205512d86f13e86761146f4.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvad best\u00e5r scenariet i?<\/p>\n<p><\/p>\n<p>En almindelig bes\u00f8gende bes\u00f8ger hjemmesiden eksempelvis 20 gange om m\u00e5neden fra forskellige annoncer eller bare uafh\u00e6ngigt af annoncer, fordi de husker denne side. De ser p\u00e5 nogle produkter, l\u00e6gger dem i kurven, fjerner dem fra kurven. Og til sidst k\u00f8ber de noget. <\/p>\n<p><\/p>\n<p>Relevante sp\u00f8rgsm\u00e5l: \"Hvem skal betale for reklamen, hvis det er n\u00f8dvendigt?\" og \"Hvilken reklame p\u00e5virkede dem, hvis nogen?\" Alts\u00e5, hvorfor k\u00f8bte de, og hvordan kan vi f\u00e5 mennesker, der minder om denne person, til ogs\u00e5 at k\u00f8be?<\/p>\n<p><\/p>\n<p>For at l\u00f8se denne opgave skal man forbinde begivenhederne, der sker p\u00e5 webstedet p\u00e5 korrekt m\u00e5de, alts\u00e5 skabe nogle forbindelser mellem dem. Derefter skal de sendes til analyse i DWH. P\u00e5 baggrund af denne analyse opbygges modeller for, hvem og hvilken reklame der skal vises.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/e53ec81ce89150697d0eca4d72886638.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>En reklame-transaction er et s\u00e6t af relaterede brugerbegivenheder, der starter med visningen af en annonce, derefter sker der noget, s\u00e5 m\u00e5ske et k\u00f8b, og der kan muligvis v\u00e6re flere k\u00f8b relateret til dette k\u00f8b. For eksempel, hvis dette er en mobilapplikation eller et mobilspil, s\u00e5 sker installationen typisk gratis, men hvis der laves flere handlinger, kan det kr\u00e6ve penge. Og jo mere en person bruger i applikationen, jo mere v\u00e6rdifuld er de. Men for dette skal alt binds sammen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/a2213613f1ef660409124ef8bcdd4fe3.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der er mange modeller for at forbinde. <\/p>\n<p><\/p>\n<p>De mest popul\u00e6re er:<\/p>\n<p><\/p>\n<ul>\n<li>Last Interaction, hvor interaction er enten et klik eller en visning.<\/li>\n<li>First Interaction, det vil sige den f\u00f8rste ting, der f\u00f8rte personen til hjemmesiden.<\/li>\n<li>Line\u00e6r kombination \u2013 alle f\u00e5r lige meget. <\/li>\n<li>Udd\u00f8en.<\/li>\n<li>Og andet. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/9523307d557e094d981da5b525ed0b59.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og hvordan fungerede det hele oprindeligt? Der var Runtime og Cassandra. Cassandra blev brugt som transaction storage, det vil sige, at den opbevarede alle relaterede transaktioner. N\u00e5r en begivenhed kom til Runtime, for eksempel visning af en side eller noget andet, blev der lavet en foresp\u00f8rgsel til Cassandra \u2013 eksisterede denne person eller ej. Derefter blev transaktionerne, der vedr\u00f8rte dem, hentet. Og s\u00e5 blev der lavet en forbindelse.<\/p>\n<p><\/p>\n<p>Og hvis man var heldig, at foresp\u00f8rgslen indeholdt et transaction id, s\u00e5 var det nemt. Men ofte er man ikke heldig. Derfor skulle man finde den seneste transaktion eller transaktionen ved sidste klik osv. <\/p>\n<p><\/p>\n<p>Og det fungerede allesammen rigtig godt, s\u00e5 l\u00e6nge bindingen var til det sidste klik. Fordi der er 10 millioner klik om dagen, 300 millioner om m\u00e5neden, hvis man s\u00e6tter vinduet til en m\u00e5ned. Og da dette i Cassandra skal v\u00e6re i hukommelsen for at fungere hurtigt, fordi Runtime skal svare hurtigt, kr\u00e6vede det omtrent 10-15 servere. <\/p>\n<p><\/p>\n<p>Men da man ville knytte transaktionen til visningen, blev det med det samme ikke s\u00e5 sjovt. Og hvorfor? Det var tydeligt, at der skulle gemmes 30 gange flere begivenheder. Og derfor er der brug for 30 gange flere servere. Og det viser sig, at det er et astronomisk tal. At skulle holde op til 500 servere for at lave bindingen, samtidig med at der er betydeligt f\u00e6rre servere i Runtime, er et forkert tal. Man begyndte at t\u00e6nke p\u00e5, hvad der skulle g\u00f8res. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/7af35f1ade680232cc83a6887891bc5c.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og man endte med ClickHouse. Men hvordan g\u00f8r man det p\u00e5 ClickHouse? Ved f\u00f8rste \u00f8jekast virker det som et s\u00e6t antipatterns. <\/p>\n<p><\/p>\n<ul>\n<li>Transaktionen vokser, vi tilknytter flere og flere nye begivenheder til den, det vil sige, den er mutable, og ClickHouse fungerer ikke s\u00e5 godt med mutable objekter. <\/li>\n<li>N\u00e5r der kommer en bes\u00f8gende til os, skal vi tr\u00e6kke hans transaktioner ud efter n\u00f8glen, efter hans visit id. Det er ogs\u00e5 et point query, som ikke g\u00f8res s\u00e5dan i ClickHouse. Normalt i ClickHouse er der store... scanninger, men her har vi brug for at f\u00e5 fat i et par poster. Ogs\u00e5 et antipattern. <\/li>\n<li>Derudover var transaktionen i json, men man \u00f8nskede ikke at omskrive den, s\u00e5 man ville opbevare json ustruktureret, og hvis det er n\u00f8dvendigt, tr\u00e6kke noget ud af den. Og det er ogs\u00e5 et antipattern. <\/li>\n<\/ul>\n<p><\/p>\n<p>Det vil sige et s\u00e6t antipatterns. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/2473129a5880ee3172b8ab7bf4afc376.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men alligevel lykkedes det at lave et system, der fungerede meget godt. <\/p>\n<p><\/p>\n<p>Hvad blev gjort? ClickHouse dukkede op, hvor loggene blev kastet ind og opdelt i poster. Der kom en attributt service, som fik loggene fra ClickHouse. Derefter fik man for hver post efter visit id transaktioner, der muligvis ikke var blevet behandlet, og derudover snapshots, det vil sige transaktioner, der allerede var knyttet, nemlig resultatet af det tidligere arbejde. Herfra blev logikken lavet, den rigtige transaktion blev udvalgt, og nye begivenheder blev tilsluttet. Det blev igen skrevet til loggen. Loggen blev sendt tilbage til ClickHouse, det vil sige, dette er et konstant cyklisk system. Og derudover blev det sendt til DWH for at blive analyseret der. <\/p>\n<p><\/p>\n<p>Det fungerede ikke s\u00e6rlig godt i denne form. For at g\u00f8re det lettere for ClickHouse, n\u00e5r foresp\u00f8rgslen kom p\u00e5 visit id, blev disse foresp\u00f8rgsler grupperet i blokke af 1.000-2.000 visit id, og vi trak alle transaktioner for 1.000-2.000 personer. S\u00e5 begyndte det hele at fungere.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/d920ce231e6e4b5fd5b27ab28f848aed.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvis vi ser ind i ClickHouse, er der kun 3 hovedtabeller, der underst\u00f8tter dette hele. <\/p>\n<p><\/p>\n<p>Den f\u00f8rste tabel, hvor loggene indl\u00e6ses, og loggene indl\u00e6ses n\u00e6sten uden behandling.<\/p>\n<p><\/p>\n<p>Den anden tabel. Gennem materialiseret visning blev de endnu ikke attribuerede h\u00e6ndelser fra disse logge udtrukket, alts\u00e5 urelaterede. Og via materialiseret visning blev transaktioner udtrukket fra disse logge for at danne et snapshot. Specifikt byggede en s\u00e6rlig materialiseret visning snapshot, nemlig den seneste akkumulerede tilstand af transaktionen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/12b0adb691f483923a6c35bb6e4a5017.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Her er teksten skrevet i SQL. Jeg vil gerne kommentere nogle vigtige ting i den. <\/p>\n<p><\/p>\n<p>Den f\u00f8rste vigtige ting er muligheden for at tr\u00e6kke kolonner, felter ud af json i ClickHouse. Der er nogle metoder til at arbejde med json. De er meget, meget primitive. <\/p>\n<p><\/p>\n<p>visitParamExtractInt g\u00f8r det muligt at tr\u00e6kke attributter ud af json, alts\u00e5 den f\u00f8rste forekomst aktiveres. P\u00e5 den m\u00e5de kan man udtr\u00e6kke transaction id eller visit id. Det er det f\u00f8rste. <\/p>\n<p><\/p>\n<p>For det andet \u2013 her bruges et smart materialiseret felt. Hvad betyder det? Det betyder, at du ikke kan inds\u00e6tte det i tabellen, alts\u00e5 det inds\u00e6ttes ikke; det beregnes og gemmes ved inds\u00e6ttelse. Ved inds\u00e6ttelse udf\u00f8rer ClickHouse arbejdet for dig. Og det, du senere har brug for, tr\u00e6kkes ud af json.<\/p>\n<p><\/p>\n<p>I dette tilf\u00e6lde er materialiseret visning for ubehandlede r\u00e6kker. Og den bruger den f\u00f8rste tabel med n\u00e6sten r\u00e5 logs. Hvad g\u00f8r det? For det f\u00f8rste \u00e6ndrer det sorteringen, alts\u00e5 sorteringen g\u00e5r nu efter visit id, fordi vi hurtigt skal tr\u00e6kke transaktionen for en bestemt person. <\/p>\n<p><\/p>\n<p>Den anden vigtige ting er index_granularity. Hvis du har set MergeTree, s\u00e5 er index_granularity normalt sat til 8.192 som standard. Hvad er det? Dette er parameteren for indexets sparsommelighed. I ClickHouse er indekset sparsomt, det indekserer aldrig hver post. Det g\u00f8r det hver 8.192. Og det er godt, n\u00e5r der kr\u00e6ves mange data at t\u00e6lle, men d\u00e5rligt, n\u00e5r det er lidt, fordi det giver en stor overhead. Hvis man reducerer index granularity, reducerer man overhead. Det kan ikke reduceres til \u00e9n, fordi der m\u00e5ske ikke er nok hukommelse. Indekset opbevares altid i hukommelsen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/5fe303061977cad64e6c0333b125d595.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og snapshot bruger nogle interessante funktioner i ClickHouse.<\/p>\n<p><\/p>\n<p>For det f\u00f8rste er det AggregatingMergeTree. Og i AggregatingMergeTree opbevares argMax, dvs. det er tilstanden af transaktionen, der svarer til den seneste timestamp. Transaktioner genereres hele tiden nye for denne bes\u00f8gte bruger. Og i den seneste tilstand af denne transaktion tilf\u00f8jede vi en h\u00e6ndelse, og vi fik en ny tilstand. Den kom igen ind i ClickHouse. Og gennem argMax i denne materialiserede visning kan vi altid f\u00e5 den aktuelle tilstand.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/d1b87301ab5206a36bf035679f79d35a.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Bindingen er 'uafh\u00e6ngig' af Runtime. <\/li>\n<li>Der gemmes og behandles op til 3 milliarder transaktioner om m\u00e5neden. Det er en orden mere end i Cassandra, dvs. i et typisk transaktionssystem. <\/li>\n<li>Clusteret best\u00e5r af 2x5 ClickHouse-servere. 5 servere, og hver server har en replika. Det er endda f\u00e6rre end der var i Cassandra for at lave click based attribution, og her har vi impression based. Dvs. i stedet for at \u00f8ge antallet af servere 30 gange, er det blevet muligt at reducere dem. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/583779fe9e133df519411e2256401eb3.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og et sidste eksempel er finansfirma Y, som analyserede korrelationer mellem aktiekurser. <\/p>\n<p><\/p>\n<p>Og opgaven var som f\u00f8lger:<\/p>\n<p><\/p>\n<ul>\n<li>Der er cirka 5.000 aktier. <\/li>\n<li>Kursene er kendt hvert 100. millisekund. <\/li>\n<li>Dataene er samlet i 10 \u00e5r. For nogle virksomheder er det muligvis mere, for andre mindre. <\/li>\n<li>I alt cirka 100 milliarder r\u00e6kker. <\/li>\n<\/ul>\n<p><\/p>\n<p>Og det var n\u00f8dvendigt at beregne korrelationen mellem \u00e6ndringerne. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/b02051e6cadec8c51e7f6e351ef903f9.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Her er der to aktier og deres kurser. Hvis den ene g\u00e5r op, og den anden g\u00e5r op, s\u00e5 er det en positiv korrelation, dvs. den ene stiger, og den anden stiger. Hvis den ene g\u00e5r op, som i slutningen af grafen, og den anden g\u00e5r ned, s\u00e5 er det en negativ korrelation, dvs. n\u00e5r den ene stiger, falder den anden. <\/p>\n<p><\/p>\n<p>Ved at analysere disse gensidige \u00e6ndringer kan man lave forudsigelser p\u00e5 finansmarkedet. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/31329cf7523eef6a167632d281a634ce.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men opgaven er kompleks. Hvad g\u00f8res der for dette? Vi har 100 milliarder poster, der indeholder: tid, aktie og pris. Vi skal f\u00f8rst beregne runningDifference fra prisalgoritmen 100 milliarder gange. RunningDifference er en funktion i ClickHouse, der beregner forskellen mellem to r\u00e6kker sekventielt. <\/p>\n<p><\/p>\n<p>Og efter dette skal korrelationen beregnes, og den skal beregnes for hvert par. For 5.000 aktier er der 12,5 millioner par. Og det er meget, dvs. 12,5 gange skal en s\u00e5dan korrelationsfunktion beregnes. <\/p>\n<p><\/p>\n<p>Og hvis nogen har glemt det, s\u00e5 er \u035ex og \u035ey det matematiske forventningsv\u00e6rdi for pr\u00f8verne. Det vil sige, at man ikke bare skal regne r\u00f8dder og summer, men ogs\u00e5 lave yderligere summer inden for disse summer. En hel masse beregninger skal udf\u00f8res 12,5 millioner gange, og s\u00e5 skal de grupperes efter timer. Og vi har ogs\u00e5 mange timer. Og det skal g\u00f8res inden for 60 sekunder. Det er en sp\u00f8g. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/567a07f586a824c91671820fe21ec305.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi skulle helst n\u00e5 det p\u00e5 en eller anden m\u00e5de, for alt dette fungerede meget, meget langsomt, f\u00f8r ClickHouse kom.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/3eca1af4c3f25ff4b23fce9b84e16659.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>De pr\u00f8vede at beregne det p\u00e5 Hadoop, p\u00e5 Spark, p\u00e5 Greenplum. Og alt dette var meget langsomt eller dyrt. Det vil sige, at det kunne beregnes p\u00e5 en eller anden m\u00e5de, men det var derefter dyrt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/37608c7e87ddb9a7d54854643044c369.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og s\u00e5 kom ClickHouse, og alt blev meget bedre. <\/p>\n<p><\/p>\n<p>Jeg minder om, at vi har et problem med lokalitet af data, da korrelationer ikke kan lokaliseres. Vi kan ikke l\u00e6gge en del data p\u00e5 \u00e9n server, en del p\u00e5 en anden og derefter beregne; vi skal have alle data overalt. <\/p>\n<p><\/p>\n<p>Hvad gjorde de? Oprindeligt var dataene lokaliserede. P\u00e5 hver af serverne er der data om priss\u00e6tning af et bestemt udvalg af aktier. Og de overlapper ikke. Derfor kan logReturn beregnes parallelt og uafh\u00e6ngigt, alt dette sker mens det er parallelt og distribueret. <\/p>\n<p><\/p>\n<p>Derefter besluttede de at reducere disse data uden at miste udtryksfuldheden. At reducere ved hj\u00e6lp af arrays, alts\u00e5 for hver tidsperiode at lave et array af aktier og et array af priser. P\u00e5 den m\u00e5de fylder dataene meget mindre. Og de er ogs\u00e5 lettere at arbejde med. Det er n\u00e6sten parallelle operationer, det vil sige, at vi delvist beregner parallelt og derefter skriver til serveren. <\/p>\n<p><\/p>\n<p>Efter dette kan det replikeres. Bogstavet \u201er\u201c betyder, at vi har replikeret disse data. Det vil sige, at vi har de samme data p\u00e5 alle tre servere \u2013 netop disse arrays. <\/p>\n<p><\/p>\n<p>Og derefter kan man med et specielt script lave pakker fra dette s\u00e6t p\u00e5 12,5 millioner korrelationer, der skal beregnes. Det vil sige 2.500 opgaver med 5.000 par korrelationer. Og denne opgave kan beregnes p\u00e5 en bestemt ClickHouse-server. Alle dataene er der, fordi dataene er ens, og den kan beregne dem sekventielt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/587c6d587a48f2407dd2687f5423d44a.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Endnu en gang, hvordan det ser ud. F\u00f8rst har vi alle data i s\u00e5dan en struktur: tid, aktier, pris. Derefter har vi beregnet logReturn, dvs. data i samme struktur, men i stedet for prisen har vi nu logReturn. Derefter har vi ombearbejdet dem, s\u00e5 vi har tid og groupArray for aktierne og priserne. Vi har replikeret dem. Og derefter genererede vi en masse opgaver og fodrede ClickHouse, s\u00e5 den kunne beregne dem. Og det fungerer. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/434e7385aebcffcc03d1bd1a2020c8bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>P\u00e5 proof of concept- opgaven var det en delopgave, dvs. vi tog f\u00e6rre data. Og det var alt sammen p\u00e5 tre servere.<\/p>\n<p><\/p>\n<p>De f\u00f8rste to faser: beregning af Log_return og indpakning i arrays tog cirka en time hver. <\/p>\n<p><\/p>\n<p>Og beregningen af korrelationen tog omkring 50 timer. Men 50 timer er lidt, fordi tidligere k\u00f8rte det i uger. Det var en stor succes. Og hvis man beregner det, blev alt regnet 70 gange i sekundet p\u00e5 dette cluster.<\/p>\n<p><\/p>\n<p>Men det vigtigste er, at dette system n\u00e6rmest ikke har flaskehalse, dvs. det skalerer n\u00e6sten line\u00e6rt. Og de har testet det. De har med succes skaleret det. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/5a595a84897e492b49dccfb0f058b1b8.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Den rigtige skema er halvdelen af succesen. Og den rigtige skema er at bruge alle de n\u00f8dvendige teknologier i ClickHouse. <\/li>\n<li>Summing\/AggregatingMergeTrees er teknologier, der g\u00f8r det muligt at aggregere eller beregne snapshot state som en s\u00e6rlig sag. Og det forenkler mange ting betydeligt. <\/li>\n<li>Materialized Views tillader at omg\u00e5 begr\u00e6nsningen til \u00e9n indeks. M\u00e5ske sagde jeg ikke det s\u00e5 klart, men n\u00e5r vi indl\u00e6ste loggene, var de r\u00e5 logs i en tabel med \u00e9n indeks, mens attributloggene var i en tabel, dvs. de samme data, bare filtreret, men indekset var helt anderledes. Det synes at v\u00e6re de samme data, men med forskellig sortering. Og Materialized Views tillader, at hvis du har brug for det, at omg\u00e5 denne ClickHouse-begr\u00e6nsning. <\/li>\n<li>Reducer indeksets granularitet for punktforesp\u00f8rgsler. <\/li>\n<li>Og fordel dataene intelligent, fors\u00f8g at lokalisere dataene s\u00e5 meget som muligt inden for serveren. Og s\u00f8rg for, at foresp\u00f8rgslerne ogs\u00e5 bruger lokalisering der, hvor det er muligt. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/c0fc1737986e3f18ed1d3c53df9f0252.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og for at opsummere denne korte tale, kan man sige, at ClickHouse nu solidt har etableret sig b\u00e5de som en kommerciel database og som en open source database, dvs. specifikt til analyse. Det passer glimrende ind i dette landskab. Og mere end det, begynder det stille og roligt at udfordre andre, fordi n\u00e5r der er ClickHouse, har man ikke brug for InfiniDB. Vertica vil m\u00e5ske snart ikke v\u00e6re n\u00f8dvendig, hvis de laver ordentlig SQL-support. Brug det!<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018)\" src=\"\/wp-content\/uploads\/2020\/07\/6e9a65d32eb6de7f9f139a30e7ab0d25.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u2014<em>Tak for pr\u00e6sentationen! Meget interessant! Var der nogle sammenligninger med Apache Phoenix?<\/em><\/p>\n<p><\/p>\n<p>- Nej, jeg har ikke h\u00f8rt om, at nogen har lavet sammenligninger. Vi og Yandex pr\u00f8ver at holde \u00f8je med alle sammenligninger af ClickHouse med forskellige databaser. Fordi hvis der pludselig er noget, der viser sig at v\u00e6re hurtigere end ClickHouse, s\u00e5 kan Alexey Milovidov ikke sove om natten og g\u00e5r hurtigt i gang med at optimere det. Jeg har ikke h\u00f8rt om en s\u00e5dan sammenligning. <\/p>\n<p><\/p>\n<ul>\n<li>\n<p><em>(Alexey Milovidov) Apache Phoenix er en SQL-motor p\u00e5 Hbase. Hbase er prim\u00e6rt designet til key-value arbejds-scenarier. I hver r\u00e6kke kan der v\u00e6re et vilk\u00e5rligt antal kolonner med vilk\u00e5rlige navne. Dette g\u00e6lder for systemer som Hbase, Cassandra. Og h\u00e5rde analytiske foresp\u00f8rgsler vil ikke fungere ordentligt p\u00e5 dem. Eller man kunne tro, at de fungerer ordentligt, hvis man ikke har haft nogen erfaring med ClickHouse.<\/em><\/p>\n<p>\n<\/li>\n<li>\n<p>Tak<\/p>\n<p><\/p>\n<ul>\n<li>\n<p><em>Goddag! Jeg har interesseret mig meget for dette emne, fordi jeg har et analytisk subsystem. Men n\u00e5r jeg ser p\u00e5 ClickHouse, f\u00e5r jeg indtryk af, at ClickHouse er meget velegnet til analyse af events, mutable. Og hvis jeg skal analysere mange forretningsdata med masser af store tabeller, s\u00e5 er ClickHouse, s\u00e5 vidt jeg kan forst\u00e5, ikke s\u00e5 velegnet for mig? Is\u00e6r hvis de \u00e6ndrer sig. Er dette korrekt, eller findes der eksempler, der kan modsige dette?<\/em><\/p>\n<p>\n<\/li>\n<li>\n<p>Det er korrekt. Og det er sandt for de fleste specialiserede analytiske databaser. De er designet til at h\u00e5ndtere en eller flere store tabeller, som er muterbare, og mange sm\u00e5, der \u00e6ndrer sig langsomt. Alts\u00e5 er ClickHouse ikke som Oracle, hvor man kan putte alt og lave meget komplekse foresp\u00f8rgsler. For at udnytte ClickHouse effektivt skal man opbygge schemaet p\u00e5 en m\u00e5de, der fungerer godt i ClickHouse. Det vil sige, man skal undg\u00e5 overdreven normalisering, bruge ordb\u00f8ger og fors\u00f8ge at lave f\u00e6rre lange relationer. Hvis man opbygger schemaet p\u00e5 denne m\u00e5de, kan de samme forretningsopgaver p\u00e5 ClickHouse blive l\u00f8st meget mere effektivt end med en traditionel relationsdatabase. <\/p>\n<p>\n<\/li>\n<\/ul>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Tak for din pr\u00e6sentation! Jeg har et sp\u00f8rgsm\u00e5l om den seneste finansielle sag. De havde en analyse. Det var n\u00f8dvendigt at sammenligne, hvordan det gik op og ned. Og jeg forst\u00e5r det s\u00e5dan, at I byggede systemet specifikt til denne analyse? Hvis de i morgen for eksempel har brug for en anden rapport baseret p\u00e5 disse data, skal schemaet s\u00e5 bygges op fra bunden igen og dataene indl\u00e6ses? Det vil sige, skal der laves en eller anden form for forbehandling for at f\u00e5 foresp\u00f8rgslen?<\/em><\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig er dette brugen af ClickHouse til en ganske konkret opgave. Den kunne mere traditionelt have v\u00e6ret l\u00f8st inden for Hadoop. For Hadoop er det en ideel opgave. Men p\u00e5 Hadoop er det meget langsomt. Mit m\u00e5l er at demonstrere, at man med ClickHouse kan l\u00f8se opgaver, der normalt l\u00f8ses med helt andre v\u00e6rkt\u00f8jer, men samtidig g\u00f8re det meget mere effektivt. Det er tilpasset en konkret opgave. Det er klart, at hvis man har en lignende opgave, kan man l\u00f8se den p\u00e5 en tilsvarende m\u00e5de. <\/p>\n<p><\/p>\n<p><em>Forst\u00e5et. Du sagde, at der blev behandlet i 50 timer. Er det fra starten, da dataene blev indl\u00e6st, eller fra man fik resultaterne?<\/em><\/p>\n<p><\/p>\n<p>Ja- ja.<\/p>\n<p><\/p>\n<p><em>Godt, mange tak.<\/em><\/p>\n<p><\/p>\n<p>Det er p\u00e5 en 3-serverklynge. <\/p>\n<p><\/p>\n<p><em>Hej! Tak for din pr\u00e6sentation! Alt er virkelig interessant. Jeg vil ikke sp\u00f8rge s\u00e5 meget om funktionaliteten, men om brugen af ClickHouse set fra stabilitetens synspunkt. Er der sket nogen udfordringer, har I v\u00e6ret n\u00f8dt til at gendanne noget? Hvordan opf\u00f8rer ClickHouse sig i s\u00e5danne tilf\u00e6lde? Har I oplevet, at en replika ogs\u00e5 er g\u00e5et ned? Vi har for eksempel st\u00f8dt p\u00e5 et problem med ClickHouse, n\u00e5r den faktisk overskrider sin gr\u00e6nse og g\u00e5r ned.<\/em><\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig er der ikke perfekte systemer, og ClickHouse har ogs\u00e5 sine problemer. Men har du nogensinde h\u00f8rt om, at Yandex.Metrica ikke fungerede i lang tid? Nok ikke. Den har fungeret p\u00e5lideligt siden omkring 2012-2013 med ClickHouse. Jeg kan ogs\u00e5 tale om min egen erfaring. Vi har aldrig haft komplette nedbrud. Der kunne ske nogle delvise problemer, men de har aldrig v\u00e6ret kritiske nok til at p\u00e5virke vores forretning alvorligt. S\u00e5dan har det aldrig v\u00e6ret. ClickHouse er ret p\u00e5lideligt og falder ikke tilf\u00e6ldigt ned. Det er noget, man ikke beh\u00f8ver at bekymre sig om. Det er ikke en beta-version. Det er bevist af mange virksomheder. <\/p>\n<p><\/p>\n<p><em>Hej! Du sagde, at man straks skal t\u00e6nke godt over dataskemaet. Hvad hvis det er sket? Mine data flyder ind, og efter et halvt \u00e5r indser jeg, at jeg ikke kan leve s\u00e5dan, jeg skal genindl\u00e6se dataene og g\u00f8re noget ved dem.<\/em> <\/p>\n<p><\/p>\n<p>Det afh\u00e6nger selvf\u00f8lgelig af dit system. Der er flere m\u00e5der at g\u00f8re dette n\u00e6sten uden nedetid. For eksempel kan du oprette en Materialized View med en anden dataskema, hvis det kan kortl\u00e6gges entydigt. Det vil sige, hvis det tillader kortl\u00e6gning med ClickHouse's midler, dvs. udtr\u00e6k af visse elementer, \u00e6ndring af prim\u00e6rn\u00f8glen, \u00e6ndring af partitionering, s\u00e5 kan du lave en Materialized View. Dine gamle data kan skrives om til den, de nye vil blive skrevet automatisk. Og s\u00e5 kan du bare skifte til at bruge Materialized View og derefter skifte skrivningen og slette den gamle tabel. Dette er en metode helt uden nedetid. <\/p>\n<p><\/p>\n<p><em>Tak.<\/em><\/p>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/512304\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0445 \u0441\u0435\u0439\u0447\u0430\u0441 \u043c\u043d\u043e\u0433\u043e \u043f\u043e\u0447\u0442\u0438 \u0432\u0435\u0437\u0434\u0435, \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0411\u0414 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u044d\u043a\u0437\u043e\u0442\u0438\u0447\u043d\u044b. \u0418\u0445 \u043f\u043b\u043e\u0445\u043e \u0437\u043d\u0430\u044e\u0442 \u0438 \u0435\u0449\u0435 \u0445\u0443\u0436\u0435 \u0443\u043c\u0435\u044e\u0442 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u041c\u043d\u043e\u0433\u0438\u0435 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044e\u0442 &quot;\u0435\u0441\u0442\u044c \u043a\u0430\u043a\u0442\u0443\u0441&quot; \u0441 MySQL \u0438\u043b\u0438 PostgreSQL, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u044b \u043f\u043e\u0434 \u0434\u0440\u0443\u0433\u0438\u0435 \u0441\u0446\u0435\u043d\u0430\u0440\u0438\u0438, \u043c\u0443\u0447\u0438\u0442\u044c\u0441\u044f \u0441 NoSQL \u0438\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u043b\u0430\u0447\u0438\u0432\u0430\u0442\u044c \u0437\u0430 \u043a\u043e\u043c\u043c\u0435\u0440\u0447\u0435\u0441\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f. ClickHouse \u043c\u0435\u043d\u044f\u0435\u0442 \u043f\u0440\u0430\u0432\u0438\u043b\u0430 \u0438\u0433\u0440\u044b \u0438 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u043f\u043e\u0440\u043e\u0433 \u0432\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u044f \u0432 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":89879,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-89878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0422\u0435\u043e\u0440\u0438\u044f \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f ClickHouse \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445. \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u0417\u0430\u0439\u0446\u0435\u0432 (2018\u0433) | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-07-26T23:42:42+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-26T23:42:42+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Teori og praksis for brug af ClickHouse i virkelige applikationer. Alexander Zaitsev (2018) | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0435\u043e\u0440\u0438\u044f \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f ClickHouse \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445. \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u0417\u0430\u0439\u0446\u0435\u0432 (2018\u0433) | ProHoster","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-clickhouse-v-realnyh-prilozheniyah-aleksandr-zajczev-2018g","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-26T23:42:42+00:00","article:modified_time":"2020-07-26T23:42:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"89878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:02:37","updated":"2026-02-22 15:29:33","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/89878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=89878"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/89878\/revisions"}],"predecessor-version":[{"id":162171,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/89878\/revisions\/162171"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/89879"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=89878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=89878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=89878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}