â Ă«shtĂ« njĂ« sistem menaxhimi bazash tĂ« dhĂ«nash me kolona pĂ«r pĂ«rpunimin online tĂ« kĂ«rkesave analitike (OLAP) me kod tĂ« hapur, i krijuar nga Yandex. PĂ«rdoret nga Yandex, CloudFlare, VK.com, Badoo dhe shĂ«rbime tĂ« tjera nĂ« mbarĂ« botĂ«n pĂ«r ruajtjen e vĂ«llimeve tĂ« mĂ«dha tĂ« tĂ« dhĂ«nave (inserimi i mijĂ«ra rreshtave nĂ« sekondĂ« ose petabayt tĂ« dhĂ«nash tĂ« ruajtura nĂ« disk).
Në një DBMS të zakonshëm, të quajtur 'të rreshtave', shembuj të të cilëve janë MySQL, Postgres, MS SQL Server, të dhënat ruhen në këtë rend:
NĂ« kĂ«tĂ« rast, vlerat qĂ« i pĂ«rkasin njĂ« rreshti ruhen fizikisht pranĂ« njĂ«ra-tjetrĂ«s. NĂ« DBMS-tĂ« me kolona, vlerat nga kolona tĂ« ndryshme ruhen veçmas, ndĂ«rsa tĂ« dhĂ«nat e njĂ« kolone â bashkĂ«:
Shembuj të DBMS-ve me kolona janë Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Kompania â mailforwarder filloi tĂ« pĂ«rdorĂ« Clickhouse nĂ« vitin 2018 pĂ«r pĂ«rgatitjen e raporteve dhe u impresionua shumĂ« nga thjeshtĂ«sia, shkallĂ«zueshmĂ«ria, mbĂ«shtetja SQL dhe shpejtĂ«sia e saj. ShpejtĂ«sia e punĂ«s sĂ« kĂ«tij DBMS ishte nĂ« prag tĂ« magjisĂ«.
Thjeshtësia
Clickhouse instalohet në Ubuntu me një komandë të vetme. Nëse e njihni SQL-in, mund të filloni menjëherë ta përdorni Clickhouse për nevojat tuaja. Megjithatë, kjo nuk do të thotë se mund të kryeni "show create table" në MySQL dhe të kopjoni-pastoni SQL-in në Clickhouse.
Në krahasim me MySQL, në këtë DBMS ekzistojnë dallime të rëndësishme në llojet e të dhënave në definicionet e skemave të tabelave, kështu që për të punuar rehat ju nevojitet pak kohë për të ndryshuar definicionet e skemave të tabelave dhe për të studiuar motorët e tabelave.
Clickhouse funksionon shkĂ«lqyer pa ndonjĂ« softuer tĂ« shtesĂ«, por nĂ«se dĂ«shironi tĂ« pĂ«rdorni replikimin, do t'ju nevojitet tĂ« instaloni ZooKeeper. Analiza e performancĂ«s sĂ« pyetjeve tregon rezultate tĂ« shkĂ«lqyera â tabelat sistemike pĂ«rmbajnĂ« tĂ« gjitha informacionet, dhe tĂ« gjitha tĂ« dhĂ«nat mund tĂ« merren pĂ«rmes SQL-it tĂ« vjetĂ«r dhe tĂ« mĂ«rzitshĂ«m.
Performanca
- krahasimi i Clickhouse me Vertica dhe MySQL në serverin me konfigurim: dy socket-e IntelŸ XeonŸ CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 me 8 6TB SATA HDD, ext4.
- krahasimi i Clickhouse me magazinën e të dhënave në cloud Amazon RedShift.
- PĂ«rmbledhje nga blogu :
Baza e tĂ« dhĂ«nave ClickHouse ka njĂ« dizajn shumĂ« tĂ« thjeshtĂ« â tĂ« gjithĂ« nyjat nĂ« klaster kanĂ« funksionalitete tĂ« njĂ«jta dhe pĂ«rdorin vetĂ«m ZooKeeper pĂ«r koordinim. Ne ndĂ«rtuam njĂ« klaster tĂ« vogĂ«l prej disa nyjash dhe kryem testime, gjatĂ« tĂ« cilave zbuluam se sistemi ka njĂ« performancĂ« mjaft mbresĂ«lĂ«nĂ«se, e cila pĂ«rputhet me avantazhet e deklaruara nĂ« benchmarket e DB-ve analitike. VendosĂ«m tĂ« shqyrtonim mĂ« nĂ« detaje konceptin nĂ« thelb tĂ« ClickHouse. Pengesa e parĂ« pĂ«r hulumtimin ishte mungesa e mjeteve dhe pakĂ«sia e komunitetit ClickHouse, prandaj u thelluam nĂ« dizajnin e kĂ«saj DB-je pĂ«r tĂ« kuptuar si funksionon.
ClickHouse nuk mbĂ«shtet marrjen e tĂ« dhĂ«nave drejtpĂ«rdrejt nga Kafka, pasi kjo Ă«shtĂ« vetĂ«m njĂ« bazĂ« tĂ« dhĂ«nash, prandaj ne shkruam njĂ« shĂ«rbim adaptues tĂ« ndĂ«rtuar me gjuhĂ«n Go. Ai lexonte mesazhet e koduara Capân Proto nga Kafka, i shndĂ«rronte ato nĂ« TSV dhe i insertonte nĂ« ClickHouse nĂ« grupe pĂ«rmes HTTP-it. MĂ« vonĂ«, ne e riparametruam kĂ«tĂ« shĂ«rbim pĂ«r tĂ« pĂ«rdorur biblioteken Go sĂ« bashku me ndĂ«rfaqen tonĂ« tĂ« ClickHouse pĂ«r tĂ« rritur performancĂ«n. GjatĂ« vlerĂ«simit tĂ« performancĂ«s sĂ« marrjes sĂ« grupeve, zbuluam njĂ« gjĂ« tĂ« rĂ«ndĂ«sishme â doli se pĂ«r ClickHouse, kjo performancĂ« varet shumĂ« nga madhĂ«sia e grupit, dmth, numri i rreshtave qĂ« insertohen nĂ« njĂ« kohĂ«. PĂ«r tĂ« kuptuar pse ndodh kjo, ne studiuam se si ClickHouse ruan tĂ« dhĂ«nat.
Motori kryesorĂ«, mĂ« saktĂ«sisht, familja e motorĂ«ve pĂ«r tabela qĂ« pĂ«rdoret nga ClickHouse pĂ«r ruajtjen e tĂ« dhĂ«nave Ă«shtĂ« MergeTree. Ky motor Ă«shtĂ« konceptualisht i ngjashĂ«m me algoritmin LSM, i cili aplikohet nĂ« Google BigTable ose Apache Cassandra, megjithatĂ« shmang ndĂ«rtimin e njĂ« tabele ndĂ«rmjetĂ«se nĂ« memorie dhe shkruan tĂ« dhĂ«nat drejtpĂ«rdrejt nĂ« disk. Kjo i jep atij njĂ« kapacitet tĂ« shkĂ«lqyer tĂ« shkrimit, pasi çdo paketĂ« e futur renditet vetĂ«m sipas âçelĂ«sit primarâ primary key, kompresohet dhe shkruhet nĂ« disk pĂ«r tĂ« formuar njĂ« segment.
Mungesa e një tabele të memories ose ndonjë koncepti të 'risisë' së të dhënave gjithashtu do të thotë se ato mund të shtohen vetëm; modifikimi ose fshirja nuk mbështetet nga sistemi. Aktualisht, mënyra e vetme për të fshirë të dhënat është t'i fshini ato sipas muajve kalendarikë, pasi segmentet kurrë nuk kalojnë kufirin e muajit. Ekipi i ClickHouse po punon aktivisht për ta bërë këtë funksionalitet të personalizueshëm. Nga ana tjetër, kjo e bën regjistrimin dhe bashkimin e segmenteve pa konflikte, kështu që kapaciteti i pranimit rritet në mënyrë lineare me numrin e inserteve paralele deri në të njëjtën kohë kur ndodh saturimi i I/O ose bërthamave.
Megjithatë, kjo situatë gjithashtu do të thotë se sistemi nuk është i përshtatshëm për paketa të vogla, prandaj përdoren shërbime Kafka dhe inserter për buferizimin. Më pas, ClickHouse vazhdon të kryejë vazhdimisht bashkimin e segmenteve në sfond, kështu që shumë pjesë të vogla informacioni do të kombinohen dhe do të shkruhen më shumë herë, duke rritur kështu intensitetin e shkruarjes. Në këtë proces, një numër i tepruar pjesësh të pazakontë do të shkaktojë një trotllem të agresiv të inserteve derisa bashkimi të vazhdojë. Ne zbuluam se kompromisi më i mirë midis pranimit të të dhënave në kohë reale dhe performancës është marrja në një tabelë e një numri të kufizuar insertesh në sekondë.
ĂelĂ«si pĂ«r performancĂ«n e leximit tĂ« tabelave Ă«shtĂ« indeksimi dhe vendosja e dhĂ«nave nĂ« disk. PavarĂ«sisht sa e shpejtĂ« Ă«shtĂ« pĂ«rpunimi, kur motorit i nevojitet tĂ« skanojĂ« terabajt tĂ« dhĂ«nash nga disku dhe tĂ« pĂ«rdorĂ« vetĂ«m njĂ« pjesĂ« tĂ« tyre, do tĂ« marrĂ« kohĂ«. ClickHouse Ă«shtĂ« njĂ« magazinĂ« kolonash, prandaj çdo segment pĂ«rmban njĂ« skedĂ« pĂ«r çdo kolone me vlera tĂ« renditura pĂ«r çdo rresht. KĂ«shtu, kolona tĂ« tĂ«ra, qĂ« nuk janĂ« tĂ« pranishme nĂ« kĂ«rkesĂ«, mund tĂ« kalohen fillimisht, dhe pastaj disa qeliza mund tĂ« pĂ«rpunohen paralelisht me ekzekutimin e vektorizuar. PĂ«r tĂ« shmangur skanimin e plotĂ«, çdo segment ka njĂ« skedĂ« tĂ« vogĂ«l indeksi.
Duke pasur parasysh se të gjitha kolonet janë të renditura sipas 'çelësit të parë', skeda e indeksit përmban vetëm etiketat (rreshtat e kapur) të çdo rreshti N-të, për të pasur mundësi t'i ruajë ato në memorie edhe për tabela shumë të mëdha. Për shembull, mund të vendosen cilësimet e paracaktuara 'të etiketohen çdo 8192 rresht', atëherë 'indeksimi i skajshëm' i një tabele me 1 trilion rreshtash, e cila lehtë përshtatet në memorie, do të marrë vetëm 122,070 karaktere.
Zhvillimi i sistemit
Zhvillimi dhe përmirësimi i Clickhouse mund të ndiqen në dhe të siguroheni se procesi i "rritjes" po ndodh me ritme të habitshme.
Popullariteti
Duket se popullariteti i Clickhouse po rritet eksponencialisht, veçanërisht në komunitetin anglishtfolës. Konferenca e vitit të kaluar High Load 2018 (Moskë, 8-9 nëntor 2018) tregoi se monstru të tillë si vk.com dhe Badoo, përdorin Clickhouse për të futur të dhëna (p.sh., loge) nga dhjetëra mijëra serverë në të njëjtën kohë. Në videon 40-minutëshe . Shpejt do të publikojmë transkriptin në Habr për lehtësimin e punës me materialin.
Fushat e aplikimit
Pas disa kohësh hulumtimi, mendoj se ka fusha ku ClickHouse mund të jetë e dobishme ose të jetë në gjendje të zëvendësojë plotësisht zgjidhje të tjera, më tradicionale dhe të njohura, si MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot dhe Druid. Më poshtë janë përshkrime të detajuara të përdorimit të ClickHouse për modernizimin ose zëvendësimin e plotë të sistemeve të menaxhimit të të dhënave të përmendura.
Zgjerimi i mundësive të MySQL dhe PostgreSQL
Para pak ditë më parë, ne zëvendësuam pjesërisht MySQL me ClickHouse për platformën e buletinëve informativë. . Problemi ishte se MySQL, për shkak të një dizajni të paplanifikuar, regjistronte çdo email të dërguar dhe çdo lidhje në këtë email me një hash base64, duke krijuar një tabelë të madhe MySQL (email_stats). Pas dërgimit të vetëm 10 milion email-e për abonentët e shërbimit, kjo tabelë zinte 150 GB hapësirë dyshe dhe MySQL fillonte të 'ngadalësohej' në kërkesat e thjeshta. Për të zgjidhur problemin e hapësirës së skedarëve, ne përdorëm me sukses kompresimin e tabelës InnoDB, e cila e zvogëloi atë me 4 herë. Megjithatë, nuk ka sens të ruhet më shumë se 20-30 milion email-e në MySQL thjesht për të lexuar historinë, pasi çdo kërkesë e thjeshtë që për një arsye ndonjëherë duhet të përfitojë një skanim të plotë sjell në swap dhe ngarkesë të madhe në I/O, për të cilën ne rregullisht merrnim paralajmërime nga Zabbix.
ClickHouse përdor dy algoritme kompresimi, të cilët reduktojnë volumet e të dhënave rreth , por në këtë rast të veçantë të dhënat ishin veçanërisht 'të kompresueshme'.
Zëvendësimi i ELK
Duke përvojës sime, staku ELK (ElasticSearch, Logstash dhe Kibana, në këtë rast konkret ElasticSearch) kërkon shumë më tepër burime për të funksionuar se sa është e nevojshme për ruajtjen e logëve. ElasticSearch është një motor i shkëlqyer, nëse ju nevojitet një kërkim i mirë me tekst të plotë në logë (dhe nuk mendoj se realisht ju duhet), por më intereson, pse de-fakto ka ndodhur që ai të bëhet standardi për mbajtjen e eksperiencave. Performanca e pranimit të tij bashkë me Logstash na ka krijuar probleme edhe me ngarkesa mjaft të vogla dhe ka kërkuar gjithnjë e më shumë memorie RAM dhe hapësirë disku. Si një DB, Clickhouse është më i mirë se ElasticSearch për arsye të mëposhtme:
- Mbështetje për dialektin SQL;
- Shkalla më e mirë e kompresionit të të dhënave të ruajtura;
- Mbështetje për kërkimin me shprehje të rregullta Regex përveç kërkimit të tekstit të plotë;
- Planifikim të përmirësuar të pyetjeve dhe performancë më të lartë në përgjithësi.
Aktualisht, problemi më i madh që lind kur krahasohet ClickHouse me ELK është mungesa e zgjidhjeve për eksportimin e logeve, si dhe mungesa e dokumentacionit dhe materialeve mësimore mbi këtë temë. Megjithatë, çdo përdorues mund ta konfigurojë ELK duke përdorur udhëzimin e Digital Ocean, gjë që është shumë e rëndësishme për një implementim të shpejtë të teknologjive të tilla. Ka një motor databazash këtu, por ende nuk ka Filebeat për ClickHouse. Po, aty ka dhe një sistem për punë me loge , ekziston një mjet për futjen në ClickHouse të të dhënave nga skedarët e logeve, por gjithçka kërkon më shumë kohë. Megjithatë, ClickHouse vazhdon të mbetet në krye për shkak të thjeshtësisë së tij, kështu që edhe fillestarët e instalojnë lehtësisht dhe fillojnë përdorimin e plotë funksional brenda vetëm 10 minutash.
Duke preferuar zgjidhje minimalistike, përpiqesha të përdorja FluentBit, një mjet për eksportimin e logeve me shumë pak kujtesë, së bashku me ClickHouse, duke u munduar të shmang përfshirjen e Kafka-s. Megjithatë, është e nevojshme të eliminohen disa moskompatibilitete të vogla, siç janë , para ta ndodhi pa një shtresë proxy që shndërron të dhënat nga FluentBit në ClickHouse.
Si një alternativë për Kibana, mund të përdorni ClickHouse si backend . Sa kam kuptuar, në këtë rast mund të ndodhin probleme me performancën gjatë renderimit të sasisë së madhe të të dhënave, veçanërisht me versionet më të vjetra të Grafana. Ne në Qwintry nuk e kemi provuar këtë deri tani, por ankesat për këtë dalin herë pas here në kanalin e mbështetjes së ClickHouse në Telegram.
Zëvendësimi i Google Big Query dhe Amazon RedShift (zgjidhje për kompani të mëdha)
Mënyra ideale për të përdorur BigQuery është të ngarkoni 1 TB të dhënash JSON dhe të kryeni kërkesa analitike mbi to. Big Query është një produkt fantastik, me një shkallëzueshmëri që është e vështirë për tu nënvlerësuar. Ky është një softuer shumë më kompleks se ClickHouse, që funksionon në një klaster të brendshëm, por nga perspektiva e përdoruesit ka shumë ngjashmëri me ClickHouse. BigQuery mund të bëhet shpejt "i shtrenjtë", sapo të filloni të paguani për çdo SELECT, kështu që kjo është një zgjidhje e vërtetë SaaS me të gjitha avantazhet dhe disavantazhet e saj.
ClickHouse është zgjidhja më e mirë nëse po kryeni shumë kërkesa të shtrenjta në mënyrë llogarithmike. Sa më shumë kërkesa SELECT që kryeni çdo ditë, aq më shumë ka kuptim të zëvendësoni Big Query me ClickHouse, sepse një zëvendësim i tillë do t'ju ndihmojë të kurseni mijëra dollarë kur flasim për shumë terabajtë të dhënash në përpunim. Kjo nuk i referohet të dhënave të ruajtura, përpunimi i të cilave në Big Query është relativisht i lirë.
Në artikullin e bashkëndërtuesit të kompanisë Altinity, Aleksandër Zajtsev përshkruhen përfitimet e një migre të tillë të DBMS.
Zëvendësimi i TimescaleDB
TimescaleDB është një zgjerim i PostgreSQL që optimizon punën me seritë e kohës (timeseries) në një bazë të dhënash normale, ).
MegjithĂ«se ClickHouse nuk Ă«shtĂ« njĂ« konkurent i rĂ«ndĂ«sishĂ«m nĂ« niĆĂ«n e serive temporale, struktura kolone dhe ekzekutimi vektorial i kĂ«rkesave e bĂ«jnĂ« atĂ« shumĂ« mĂ« tĂ« shpejtĂ« se TimescaleDB nĂ« shumicĂ«n e rasteve tĂ« pĂ«rpunimit tĂ« kĂ«rkesave analitike. Performanca e pranimit tĂ« tĂ« dhĂ«nave nĂ« grupe nga ClickHouse Ă«shtĂ« rreth 3 herĂ« mĂ« e lartĂ«, dhe pĂ«r mĂ« tepĂ«r, ai pĂ«rdor 20 herĂ« mĂ« pak hapĂ«sirĂ« disk, gjĂ« qĂ« Ă«shtĂ« me tĂ« vĂ«rtetĂ« e rĂ«ndĂ«sishme pĂ«r pĂ«rpunimin e volumit tĂ« madh tĂ« tĂ« dhĂ«nave historike:.
Në ndryshim nga ClickHouse, mënyra e vetme për të kursyer ndonjë hapësirë disk në TimescaleDB është përdorimi i ZFS ose sistemeve të ngjashme të skedarëve.
Përditësimet e ardhshme të ClickHouse, me siguri do të prezantojnë kompresimin delta, i cili do ta bëjë atë edhe më të përshtatshëm për përpunimin dhe ruajtjen e të dhënave të serive temporale. TimescaleDB mund të bëhet zgjedhja më e mirë se "ClickHouse i papërpunuar" në rastet e mëposhtme:
- instalime të vogla me sasi shumë të vogël të memorjes së brendshme (<3 GB);
- një numër të madh INSERT-esh të vogla që nuk dëshironi t'i bufferizoni në fragmente të mëdha;
- koherencë më e mirë, një formë dhe kërkesa ACI;
- mbështetje për PostGIS;
- Integrimi me tabelat ekzistuese PostgreSQL, pasi në thelb Timescale DB është PostgreSQL.
Konkurrenca me sistemet Hadoop dhe MapReduce
Hadoop dhe produkte të tjera MapReduce mund të kryejnë shumë llogaritje komplekse, por zakonisht funksionojnë me vonesa të mëdha. ClickHouse zgjidh këtë problem duke trajtuar terabajt të dhënash dhe duke e nxjerrë rezultatin pothuajse menjëherë. Kështu, ClickHouse është shumë më efektiv për kryerjen e studimeve analitike të shpejta dhe interaktive, që duhet të tërheqë specialistët në fushën e përpunimit të të dhënave.
Konkurrenca me Pinot dhe Druid
Konkurrentët më të afërt të ClickHouse janë produktet open source columnar dhe linear-scaling Pinot dhe Druid. Një krahasim i shkëlqyer i këtyre sistemeve është publikuar në artikullin më 1 shkurt 2018.
Ky artikull kĂ«rkon pĂ«rditĂ«sim â pĂ«rmendet se ClickHouse nuk mbĂ«shtet operacionet UPDATE dhe DELETE, qĂ« nuk Ă«shtĂ« plotĂ«sisht e saktĂ« pĂ«r versionet e fundit.
Nuk kemi pĂ«rvojĂ« tĂ« mjaftueshme me kĂ«to DBMS, por nuk mĂ« pĂ«lqen aspak kompleksiteti i infrastrukturĂ«s qĂ« kĂ«rkohet pĂ«r tĂ« nisur Druid dhe Pinot â Ă«shtĂ« njĂ« grumbull "pjesĂ«sh lĂ«vizĂ«se", tĂ« rrethuara nga Java nga tĂ« gjitha anĂ«t.
Druid dhe Pinot janĂ« projekte inkubator nĂ« Apache, dhe zhvillimi i tyre Ă«shtĂ« ndjekur nĂ« detaje nga Apache nĂ« faqet e projekteve tĂ« tyre nĂ« GitHub. Pinot u shfaq nĂ« inkubator nĂ« tetor 2018, ndĂ«rsa Druid u lind 8 muaj mĂ« herĂ«t â nĂ« shkurt.
Mungesa e informacionit mbi mĂ«nyrĂ«n se si funksionon AFS, mĂ« ngre disa, ndoshta, pyetje tĂ« çuditshme. ĂshtĂ« interesante, a kanĂ« vĂ«nĂ« re autorĂ«t e Pinot se Fondacioni Apache Ă«shtĂ« mĂ« i prirur ndaj Druid, dhe a ka shkaktuar njĂ« ndjenjĂ« zili pĂ«r konkurrencĂ«n? A do tĂ« ngadalĂ«sohet zhvillimi i Druid dhe do tĂ« pĂ«rshpejtohet zhvillimi i Pinot, nĂ«se sponsorĂ«t qĂ« mbĂ«shtesin tĂ« parin, papritur interesohen pĂ«r tĂ« dytin?
Disavantazhet e ClickHouse
Pjekuria: është e qartë se kjo është ende një teknologji e papjekur, por në çdo rast, nuk ka asgjë të ngjashme në DBMS të tjera me kolona.
Injektet e vogla funksionojnĂ« keq me shpejtĂ«si tĂ« lartĂ«: injektet duhet tĂ« ndahen nĂ« pjesĂ« tĂ« mĂ«dha, sepse performanca e injekteve tĂ« vogla zvogĂ«lohet proporcionalisht me numrin e kolonave nĂ« çdo rresht. KĂ«shtu ruhet tĂ« dhĂ«nat nĂ« ClickHouse nĂ« disk â çdo kolonĂ« pĂ«rfaqĂ«son 1 skedarin ose mĂ« shumĂ«, prandaj, pĂ«r tĂ« injektuar 1 rresht qĂ« pĂ«rmban 100 kolona, Ă«shtĂ« e nevojshme tĂ« hapen dhe shkruhen tĂ« paktĂ«n 100 skedarĂ«. Prandaj, nevojitet njĂ« ndĂ«rmjetĂ«s pĂ«r buferimin e injekteve (nĂ«se klienti vetĂ« nuk siguron buferimin) â zakonisht Ă«shtĂ« Kafka ose ndonjĂ« sistem menaxhimi tĂ« radhĂ«ve. Gjithashtu mund tĂ« pĂ«rdoret motori Buffer table pĂ«r tĂ« kopjuar mĂ« vonĂ« fragmente tĂ« mĂ«dha tĂ« tĂ« dhĂ«nave nĂ« tabelat MergeTree.
Këputjet e tabelave janë të kufizuara nga memoria operativë e serverit, megjithatë, të paktën, ato ekzistojnë atje! Për shembull, Druid dhe Pinot nuk kanë fare këto këputje, duke qenë se është e vështirë t'i implementosh drejtpërdrejt në sistemet e shpërndara që nuk mbështesin transferimin e copave të mëdha të të dhënave midis nyjave.
PĂ«rfundimet
Në vitet në vijim, ne planifikojmë të përdorim gjerësisht ClickHouse në Qwintry, pasi kjo bazë e të dhënash ofron një balancim të shkëlqyer midis performancës, kostove të ulta, shkallëzueshmërisë dhe thjeshtësisë. Jam pothuajse i sigurt se ajo do të fillojë të përhapet shpejt, sapo komuniteti ClickHouse të gjejë më shumë mënyra për ta përdorur në instalime të vogla dhe të mesme.
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
