— սա բաց կոդով տվյալների բազաների համակցված համակարգ է, որը նախատեսված է օնլայն վերլուծական запросների (OLAP) մշակման համար, ստեղծված է Yandex-ի կողմից։ Այն օգտագործում են Yandex, CloudFlare, VK.com, Badoo և այլ ծառայություններ ամբողջ աշխարհում՝ իսկապես մեծ ծավալի տվյալների (հազարների շարքեր մեկ վայրկյանում կամ պետաբայտների տվյալներ, որոնք պահվում են սկավառում) պահպանության համար։
Սովորական, «տողի» տվյալների բազաներում, որոնց օրինակները ցույց են տալիս MySQL, Postgres, MS SQL Server, տվյալները պահվում են այդ կարգով՝
Այդ ընթացքում, մեկ տողի հետ կապված արժեքները ֆիզիկապես միմյանց մոտ են պահվում։ Կոմբինացված տվյալների բազաներում արժեքները պահպանվում են առանձին սյուների համար՝ իսկ մեկ սյունի տվյալները՝ միասին.
Կոմբինացված տվյալների բազաների օրինակներ են Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+։
Ընկերություն – поштовый пересыльщик պատասխանատու է Clickhouse-ի օգտագործման համար 2018 թվականին հաշվետվություններ կազմելու համար և շատ զարմացած է նրա պարզությունից, մասշտաբայնությունից, SQL-ի աջակցությունից և արագությունից։ Այս տվյալների բազայի աշխատանքի արագությունը կախարդանքի հետ սահմանակից էր։
Հեշտություն
Clickhouse-ը կարող է տեղադրվել Ubuntu-ում միակ հրահանգով։ Եթե դուք գիտեք SQL, ապա կարող եք անմիջապես սկսել օգտագործել Clickhouse-ը ձեր կարիքների համար։ Պատահում է, որ դուք չեք կարող անել «show create table» MySQL-ում և պարզել SQL-ը Clickhouse-ում։
MySQL-ի համեմատ, այս տվյալների բազայում կան կարևոր տարբերություններ սյուների տեսակների սահմանման մեջ, այնպես որ հարմարավետ աշխատանք ունենալու համար ձեզ потребуется որոշ ժամանակ, որպեսզի փոխեք սյուների սահմանումները և ուսումնասիրեք սյուների շարժիչները։
Clickhouse-ը великолепно работает без какого-либо дополнительно программного обеспечения, но если вы захотите использовать репликацию, вам потребуется установить ZooKeeper։ Запросов производительности показывает отличные результаты — системные таблицы содержат всю информацию, а все данные могут быть получены с помощью старого и скучного SQL։
Կազմակերպություն
- Clickhouse-ի համեմատության հետ Vertica-ի և MySQL-ի վրա, серверի կազմաձևով՝ երկու Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 на 8 6TB SATA HDD, ext4.
- Clickhouse-ի համեմատ Ռեդշիֆթ ամպային տվյալների պահեստի հետ.
- Բլոգի выдержки :
ClickHouse երկդ_replaceit աշխատում է շատ պարզ ձևավորումով՝ բոլոր կլաստերի հանգույցները ունի նույն գործառույթը և միայն ZooKeeper-ի միջոցով համակարգում է: Մենք կազմեցինք մի փոքր կլաստեր մի քանի հանգույցներով և կատարեցինք փորձարկում, որի ընթացքում հայտնաբերվեց, որ համակարգն ունի բավականին տպավորիչ կատարողականություն, որը համապատասխանում է հայտարարված առավելություններին վերլուծական DBMS-ներում: Ցուցադրելու համար մենք որոշեցինք ավելի մանրամասն ուսումնասիրել ClickHouse-ի հիմքում լծված կոնցեպտը: Առաջին խոչընդոտը հետազոտությունների համար եղել է գործիքների բացակայությունը և ClickHouse համայնքի փոքրությունը, ուստի մենք խորասուզվեցինք այս DBMS-ի ձևավորման մեջ՝ հասկանալու, թե ինչպես է այն գործում.
ClickHouse-ն չի աջակցում տվյալների ընդունմանը՝ անմիջականորեն Kafka-ից, քանի որ դա ընդամենը տվյալների բազա է, հետևաբար մենք գրեցինք մեր սեփական ադապտերների ծառայությունը Go լեզվով: Այն կարդում էր Kafka-ի Cap’n Proto կոդավորված հաղորդագրությունները, դրանք վերածում TSV-ի և դրանք խմբերով մտցնում ClickHouse HTTP-հանրահայտի միջոցով: Հետո մենք նորից գրեցինք այդ ծառայությունը՝ օգտագործելով Go գրադարանը մեր սեփական ClickHouse ինտերֆեյսի հետ՝ արտադրողականությունը բարելավելու համար: Փաթեթների ընդունման արտադրողականությունը գնահատելիս մենք հայտնաբերեցինք կարևոր մի բան՝ դարձավ որ ClickHouse-ում այս արտադրողականությունը շատ կախված է փաթեթի չափից, այսինքն՝ միաժամանակ մտցվող տողերի քանակից: Ակնկալելու համար, թե ինչու դա տեղի է ունենում, մենք ուսումնասիրեցինք, թե ինչպես ClickHouse-ն պահպանում է տվյալները.
ClickHouse-ի տվյալները պահելու համար օգտագործվող հիմնական շարժիչը, ճիշտ կլիներ ասել, սեղանի երկարատև շարժիչներ, MergeTree-ն է: Այս շարժիչը կոնցեպտուալ նման է Google BigTable կամ Apache Cassandra-ի LSM ալգորիթմին, սակայն խուսափում է միջանկյալ հիշողության սեղան կառուցելուց և տվյալները անմիջապես գրում է սկավառակի վրա: Սա տալիս է նրան գերազանց գրառման թողունակություն, քանի որ յուրաքանչյուր սեղան գրված փաթեթը դասավորվում է միայն «մասնագիտական բանալիի» primary key միջոցով, հավաքվում և գրանցվում է սկավառակի վրա՝ հատված կազմելու համար.
Հիշողության սեղանի կամ տվյալների «մահ կամ օրինականության» բովանդակություն բացակայությունը նշանակում է, որ տվյալները միայն կարելի է ավելացնել, փոփոխությունները կամ ջնջումը სისტեմն չի աջակցում: Այսօր տվյալները ջնջելու միակ միջոցը նրանց ջնջելն է ամսական օրացույցներով, քանի որ հատվածները երբեք չեն հատում ամսվա սահմանը: ClickHouse թիմը ակտիվորեն աշխատում է, որպեսզի այս ֆունկցիան կարգավորելի դառնա: Այլ կողմից, դա Անգլիայում գրանցման և հատվածների միավորման համար հակասական չի, հետևաբար ընդունման թողունակությունը գծային բարձրանում է զուգահեռ գրառումներով մինչև I/O կամ միջուկների սպառման դեպքում:
Այնուամ գումարած հանգամանքն էլ նշանակում է, որ համակարգը չի համապատասխանում փոքր փաթեթների համար, ուստի բուֆերման օգտագործվում են Kafka ծառայություններն ու ներդնողները: Հաջորդը, ClickHouse-ը ֆոնում շարունակաբար իրականացնում է սեգմենտների միաձուլում, այնպես որ, շատ փոքր տեղեկատվության կտորներ կմիավորվեն և գրանցվեն ավելի մեծ քանակությամբ, այսպիսով, ավելացնելով գրանցման ինտենսիվությունը: Այս ընթացում շատ առանձին կտորներ կծնեն ագրեսիվ ներդրումների սահմանափակում, մինչև միաձուլումը շարունակվի: Մենք հայտնաբերել ենք, որ լավագույն կոմպրոմիսը իրական ժամանակում տվյալների ընդունման և ընդունման արտադրողականության միջև է, երբ ընդունվում է սեղանակից սահմանափակ թվով ներդրումներ վայրկյանում.
Սեղանների ընթերցման արտադրողականության բանալին ինդեքսավորումն ու տվյալների տեղադրությունն է սկավառակում: Ամեն դեպքում, որքան էլ արագ լինի մշակումը, երբ շարժիչն անհրաժեշտ է սկանի տերաբայթ տվյալներ սկավառակից և օգտագործի դրանցից միայն մի մասը, դա կտևի ժամանակ: ClickHouse-ը սյունակային պահեստավորում է, այդ պատճառով յուրաքանչյուր սեգմենտում կա փաստաթուղթ յուրաքանչյուր սյունակի համար (որոշակի սյունակների) ձեռքբերովի արժեքներով յուրաքանչյուր շարքի համար: Այսպիսով, ամբողջական սյունակներ, որոնք բացակայում են հարցումից, առաջին հերթին կարող են բացակայել, իսկ հետո մի քանի բջիջներ կարող են հետագա ժամանակահատվածում իրականացնել զուգահեռացված կատարման համահրդավիրում: Լրիվ սկանավորումից խուսափելու համար, յուրաքանչյուր սեգմենտ ունի փոքրիկ ինդեքսային փաստաթուղթ.
Հաշվի առնելով, որ բոլոր սյունակները դասավորված են «հիմնարար բանալիով», ինդեքսային փաստաթուղթը պարունակում է միայն նշաններ (ձևավորված շարքեր) յուրաքանչյուր N-րդ շարքի համար, որպեսզի կարողանանք պահպանել դրանք հիշողության մեջ նույնիսկ շատ մեծ սեղանների համար: Օրինակ, կարելի է սահմանել պարամետրեր «նշել յուրաքանչյուր 8192-րդ շարքը», ապա «ճգնաժամային» սեղան, որը ունի 1 տրլն. շարք, որը հեշտորեն տեղավորվում է հիշողության մեջ, կպահանջի ընդամենը 122 070 նիշ:
Համակարգի զարգացում
Clickhouse-ի զարգացումը և կատարելագործումը կարելի է հետևել և համոզվել, որ «մեծացման» գործընթացն ընթանում է զարմանալի արագությամբ.
Սիրվածություն
Դ נראה parece que la popularidad de Clickhouse está creciendo exponencialmente, especialmente en la comunidad de habla rusa. La conferencia del año pasado High load 2018 (Moscú, 8-9 de noviembre de 2018) mostró que monstruos como vk.com y Badoo usan Clickhouse, con el que insertan datos (por ejemplo, registros) desde decenas de miles de servidores al mismo tiempo. En un video de 40 minutos . Pronto subiremos la transcripción a Habr para facilitar el trabajo con el material.
Դիտումների ոլորտները
Հետազոտություններից որոշ समय անցկացնելուց հետո կարծում եմ, որ կան ոլորտներ, որտեղ ClickHouse կարող է օգտակար լինել կամ ամբողջովին փոխարինել այլ, ավելի ավանդական և հանրաճանաչ լուծումներին, ինչպիսիք են MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot և Druid: Ներքևում ներկայացված են ClickHouse-ի օգտագործման մանրամասները վերոնշյալ DBMS-ների արդիականացման կամ լրիվ փոխարինման համար:
MySQL-ի և PostgreSQL-ի հնարավորությունների ընդլայնում
Արժեք ունեցող, վերջերս մենք جزئیորեն փոխարինեցինք MySQL -ն ClickHouse- ի հետ տեղեկատվական բյուլիտենների պլատֆորմի համար . Ինքնին խնդիրն այն էր, որ MySQL-ն անմշակ նախագծի պատճառով գրանցում էր ուղարկված յուրաքանչյուր նամակ և այդ նամակում յուրաքանչյուր հղում base64-ի հեշով, ստեղծելով MySQL (email_stats) մեծ աղյուսակ: Միայն 10 միլիոն նամակներ ուղարկելուց հետո, այս աղյուսակը զբաղեցնում էր 150 ԳԲ ֆայլային տարածություն, և MySQL-ը սկսում էր «թուլանալ» պարզ հարցերում: Ֆայլային տարածության խնդիրները լուծելու համար մենք հաջողությամբ կիրառեցինք InnoDB աղյուսակի սեղմումը, որը իջեցրեց այն 4 անգամ: Բայց նաև տրամաբանական չէ պահել ավելի քան 20-30 միլիոն էլփոստեր MySQL-ում միայն պատմությունը կարդալու համար, քանի որ ցանկացած պարզ հարց, որը որոշ պատճառով պետք է կատարի ամբողջական սկավառման, հանգեցնում է swap-ի և մեծ բեռի I/O-ի վրա, որի մասին մենք կանոնավոր կերպով предупреждения էինք ստանում Zabbix-ից:
Clickhouse-ը օգտագործում է երկու սեղմման ալգորիթմներ, որոնք նվազեցնում են տվյալների ծավալը մոտ , բայց այս կոնկրետ դեպքում տվյալները առանձնապես «սեղմելի» էին:
ELK-ի փոխարինում
Ի դիմի մեր սեփական փորձին, ELK փաթեթը (ElasticSearch, Logstash և Kibana, այստեղ՝ հատկապես ElasticSearch) պահանջում է ավելի շատ ռեսուրսներ գործարկման համար, քան անհրաժեշտ է լոգերի պահելու համար: ElasticSearch-ն отличный շարժիչ է, եթե ձեզ անհրաժեշտ է լավ լիախոհական որոնում լոգերում (և ես չեմ կարծում, որ դա ձեզ իրականում անհրաժեշտ է), բայց ինձ հետաքրքրում է, թե ինչու de-facto նա դարձել է ստանդարտ շարժիչ日志 վարելու համար: Նրա ներածման կատարողականությունը Logstash-ի հետ համակցվում էր մեզ խնդիրներ առաջացնել նույնիսկ բավականին փոքր բեռների ժամանակ և պահանջում էր ավելի մեծ հիշողություն ու սկավառակի տարածություն: Ուորկային DB-ով Clickhouse-ն ավելի լավ է, քան ElasticSearch, հետևյալ պատճառներով:
- SQL դիալեկտի աջակցում;
- Պահվող տվյալների ավելի լավ սեղման աստիճան;
- Կրագրային արտահայտությունների Regex որոնման աջակցություն փոխարեն լիախոհական որոնման;
- Փոխել հարցումների ծրագրումը և ավելի բարձր ընդհանուր կատարողականություն:
Եթե ներկայումս ամենամեծ խնդիրը, որը առաջանում է ClickHouse-ի և ELK-ի համեմատության ժամանակ, այն է, որ չկա գրանցման տվյալների արտահանում համար լուծումներ, ինչպես նաև տեղեկատվության և ուսումնական գիրքերի պարտք։ Ամեն օգտագործող կարող է կարգավորել ELK օգտագործելով Digital Ocean-ի ուղեցույց, ինչը շատ կարևոր է նման տեխնոլոգիաների արագ իրացման համար։ Այստեղ կա տվյալների բազայի շարժիչ, սակայն այժմ դեռևս չկա Filebeat ClickHouse-ի համար։ Այո, այնտեղ առկա է ու գրանցման տվյալների հետ աշխատելու համակարգը , առկա է գործիք ClickHouse-ի համար գրանցման ֆայլերից տվյալների ներմուծման համար, սակայն այս ամենը ավելի շատ ժամանակ է պահանջում։ Չերն, ClickHouse-ը դեռ առաջնորդող դիրքում է իր պարզության պատճառով, ուստի նույնիսկ նորեկները հեշտությամբ այն տեղադրում են և անցնում լիարժեք օգտագործման՝ գրեթե 10 րոպեում։
Հակառակ minimalist լուծումների, ես փորձեցի օգտագործել FluentBit-ը, որը կատարման շատ փոքր հիշողություն ունեցող տվյալների արտահանման գործիք, միասին ClickHouse-ի հետ, փորձելով խուսափել Kafka-ի օգտագործումից։ Սակայն պետք է հաղթահարել մի քանի փոքր несовместимости, ինչպես , նախքան դա հնարավոր կլինի կատարել առանց proxy-շերտի, որը կվերածի տվյալները FluentBit-ից ClickHouse։
Kibana-ի փոխարեն հնարավոր է օգտագործել ClickHouse որպես բեքենդ ։ Ինչպես ես հասկացա, այս դեպքում կարող են առաջանալ կատարողականի խնդիրներ, երբ արտացոլվում են տվյալների մեծ վեկտորներ, հատկապես ավելի հին տարբերակների հետ Grafana-ի։ Մենք Qwintry-ում դեռ փորձած չենք, բայց դժգոհությունները այդ ժամանակ-ժամանակ առաջանում են ClickHouse-ի աջակցման ալիքներում Telegram-ում։
Google Big Query-ի և Amazon RedShift-ի փոխարինում է (փ حلول企业)
Իդեալային BigQuery-ի օգտագործման տարբերակն է 1 ԹԲ JSON տվյալների ներբեռնելը և դրանց վրա վերլուծական հարցումներ կատարել։ Big Query-ը հրաշահարված արտադրանք է, որի ընդլայնելիությունն դժվար է գնահատել։ Սա ClickHouse-ից շատ ավելի բարդ ծրագրական ապահովում է, որն աշխատում է ներքին կլաստերում, սակայն հաճախորդի տեսանկյունից շատ ընդհանուր ունի ClickHouse-ի հետ։ BigQuery-ն կարող է արագ 'գնակալել', երբ սկսում եք վճարել յուրաքանչյուր SELECT-ի համար, այնպես որ սա իրական SaaS լուծում է իր բոլոր առավելություններով և բացասական կողմերով։
ClickHouse-ը լավագույն ընտրությունն է այն ժամանակ, երբ դուք կատարում եք շատ թանկ հաշվարկային հարցումներ։ Չեմ շատ SELECT հարցումներ, որոնք կատարում եք ամեն օր — այնքան ավելի իմաստ ունի Big Query-ի փոխարինումը ClickHouse-ով, քանի որ նման փոխարինումը կօգնեք ձեր հազարավոր դոլարներ խնայել, եթե խոսքը վերաբերում է շատ տերաբիտի տվյալներին։ Սա չի վերաբերում պահպանվող տվյալներին, որոնց մշակումը Big Query-ում բավականաչափ էժան է։
Altinity ընկերության համահիմնադիր Ալեքսանդր Զայցևի հոդվածում նպատակակիրում է տվյալների բազայի այս տրանսֆորմացիայի առավելությունները։
TimescaleDB-ի փոխարինում
TimescaleDB PostgreSQL-ի ընդլայնում է, որը օպտիմալացնում է ժամանակային շարքերի (timeseries) աշխատանքը սովորական տվյալների բազայում,, ).
Չնայած այն հանգամանքին, որ ClickHouse-ը ժամանակային շարքերում ոչ կարևոր մրցակից է, բայց սյունային կառուցվածքով և վեկտորային QUERY-ի կատարմամբ, մեծ մասամբ անալիտիկ հարցումների մշակման դեպքում այն զգալիորեն արագ է TimescaleDB-ից։ Այսինքն, ClickHouse-ի խմբային տվյալների ընդունման արդյունավետությունը մոտ 3 անգամ ավելի բարձր է, ընդլայնելով այն 20 անգամ քիչ տեղով, ինչը շատ կարևոր է պատմական մեծ տվյալների մշակման համար։.
ClickHouse-ի տարբերությամբ, TimescaleDB-ում միակ եղանակը մի փոքր տեղ տնտեսելն է ZFS կամ նմանակ ֆայլային համակարգերի միջոցով։
ClickHouse-ի առաքվելու թարմացումները, ամենայն հավանականությամբ, կհռչակեն դելտա-համփարում, որը կդարձնի այն ավելի հարմար ապրելագրերի (temporal) տվյալների մշակման և պահպանման համար։ TimescaleDB- ն կարող է ավելի լավ ընտրություն լինել, քան 'թողարկված' ClickHouse-ը հետևյալ դեպքերում՝
- չնչին ինստալյացիաներ շատ փոքր օպերատիվ հիշողությամբ (<3 Գբ);
- շատ փոքր INSERT-ներ, որոնք դուք չեք ցանկանում բուֆերացնել մեծ կտորների մեջ;
- լավագույն համաչափություն, միատեսակություն և AСID պահանջներ;
- PostGIS-ի աջակցություն;
- PostgreSQL-ի ներկայիս աղյուսակների հետ միացում, քանի որ TimescaleDB-ն իրականում PostgreSQL է։
Hadoop եւ MapReduce համակարգերի հետ մրցակցություն
Hadoop եւ մյուս MapReduce արտադրանքները կարող են իրականացնել բազմաթիվ բարդ հաշվարկներ, բայց, ընդհանրապես, նրանք աշխատում են մեծ լանջերով։ ClickHouse-ը լուծում է այդ խնդիրը` մշակելով տերաբայթներ տվյալներ եւ գրեթե անիմաստ արդյունքներ տալիս։ Այդպիսով, ClickHouse-ը շատ ավելի արդյունավետ է արագ, ինտերակտիվ վերլուծական հետազոտական անել համար, ինչը պետք է հետաքրքրի տվյալների մշակման մասնագետներին։
Pinot-ի եւ Druid-ի հետ մրցակցություն
ClickHouse-ի մոտակա մրցակիցներն են սյունային, գծային-շռված open source արտադրանքները Pinot եւ Druid։ Այս համակարգերի համեմատականը հրաշալի կերպով հրապարակված է 2018 թվականի փետրվարի 1-ին։
Այս հոդվածը պահանջում է թարմացում՝ ցանկությամբ, որ ClickHouse-ը չի աջակցում UPDATE եւ DELETE գործողություններին, ինչը վերջին տարբերակների առումով ոչ լրիվ ճիշտ է։
Մենք չունենք բավարար փորձ այս DBMS-ների հետ, բայց ինձ շատ դուր չի գալիս Druid եւ Pinot գործելու համար անհրաժեշտ ենթակառուցվածքի բարդությունը՝ դա մի ամբողջ գումար ԱՊԴ-եր է, որոնք Java-ով շրջապատված են։
Druid եւ Pinot Apache-ի ինկուբատորային նախագծեր են, որոնց զարգացումը մանրամասնում է Apache-ն իրենց GitHub նախագծերի էջերում։ Pinot-ը երևացել է ինկուբատորում 2018 թվականի հոկտեմբերին, իսկ Druid-ը ծնվել է 8 ամիս առաջ՝ փետրվարին։
AFS-ի աշխատանքի մեթոդոլոգիայի մասին տեղեկատվության բացակայությունը ինձ մի քանի, և հնարավոր է, գ前年 հարցեր է առաջացնում: Հետաքրքիր է, թե արդյոք Pinot-ի հեղինակները նկատել են, որ Apache Foundation-ը ավելի սրտացավ է Druid-ի նկատմամբ, և արդյոք այդպիսի մոտեցումը չի հարուցել մրցակցի նկատմամբ յանձնարարական զգացմունք? Ցանկացող է Druid-ի զարգացումն դանդաղել և Pinot-ի զարգացումն արագանալ, եթե առաջինը համասեռող բանվորները հանկարծ հետաքրքրվեն երկրորդով:
ClickHouse-ի թերությունները
Անընդհանուրություն: Ըստ երևույթին, սա դեռևս հետաքրքիր տեխնոլոգիա է, սակայն մյուսը ոչնչի նման չի երևում այլ սյունակի տվյալների բազաների մեջ:
Չնչին ներմուծումները վատ են աշխատում բարձր արագությամբ: Ներմուծումները պետք է բաժանվեն մեծ մասերի, քանի որ փոքր ներմուծումների կատարողականությունը նվազում է յուրաքանչյուր տողի մեջ սյուների քանակի համեմատ: Այդպես ClickHouse-ում տվյալները պահվում են սկավառակում. յուրաքանչյուր սյուն նշանակում է 1 կամ ավելի ֆայլ, այնպես որ, 100 սյուն ունեցող 1 տողի ներմուծման համար անհրաժեշտ է բացել և գրավոր ոչ պակաս 100 ֆայլ: Այդ պատճառով ներմուծումների բուֆերային ներիշների համար պետք է միջնորդ (如果客户自身不提供缓冲器) — սովորաբար դա Kafka է կամ ինչ-որ հերթերի կառավարման համակարգ: Կարող եք նաև օգտագործել Buffer table շարժիչ, որպեսզի հետո մեծ մասերով տվյալները տեղափոխեն MergeTree աղյուսակներում:
Աղյուսակների միացումը սահմանափակված է սերվերի օպերատիվ հիշողությամբ, սակայն, ամեն դեպքում, դրանք կան այնտեղ: Օրինակ, Druid և Pinot-ում ընդհանրապես այդպիսի միացումներ չկան, քանի որ դրանք դժվար է իրականացնել ուղղակի բաշխված համակարգերում, որոնք չեն աջակցում մեծ տվյալների կտորների տեղափոխմանը узловերի միջև:
Արդուկները
Մոտ ապագայում մենք պլանավորում ենք լայնածավալ օգտագործել ClickHouse-ն Qwintry-ում, քանի որ այս տվյալների բազան обеспечивает отличный баланс производительности, низких накладных расходов, масштабируемости и простоты. Я почти уверен, что она начнет быстро распространяться, как только сообщество ClickHouse придумает больше способов ее использования на малых и средних инсталляциях.
Մի փոքր գովազդ 🙂
Շնորհակալություն, որ մնում եք մեզ հետ։ Ձեզ դուր են գալիս մեր հոդվածները։ Ուզում եք տեսնել ավելի հետաքրքիր նյութեր։ Օգնեք մեզ` պատվեր ձևակերպելով կամ ծանոթներին խորհուրդ տալով։ , յուրաքանչյուր այլընտրանք, որը մենք առաջարկել ենք ձեզ՝ (և RAID1, RAID10 տարբերակներ հասանելի են, մինչև 24 միջուկներ և մինչև 40GB DDR4):
Dell R730xd-ը կրկնակի անգամ էժան է Equinix Tier IV տվյալային կենտրոնում Ամստերդամում։ Մ seuls է մեզ մոտ նավահանգստի Նիդերլանդներում! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — սկսվում է $99-ից! Կարդացեք այն մասին
Ընտանիք: habr.com
