բաց կոդով սյունակային տվյալների բազայի կառավարման համակարգ է առցանց վերլուծական հարցումների մշակման համար (OLAP), որը ստեղծվել է Yandex-ի կողմից: Այն օգտագործվում է Yandex-ի, CloudFlare-ի, VK.com-ի, Badoo-ի և այլ ծառայությունների կողմից ամբողջ աշխարհում՝ իսկապես մեծ քանակությամբ տվյալներ պահելու համար (վայրկյանում հազարավոր տողեր կամ սկավառակի վրա պահվող petabytes տվյալների տեղադրում):
Սովորական, «լարային» DBMS-ում, որոնց օրինակներն են MySQL, Postgres, MS SQL Server, տվյալները պահվում են հետևյալ հաջորդականությամբ.
Այս դեպքում մեկ տողի հետ կապված արժեքները ֆիզիկապես պահվում են մոտակայքում: Սյունակային DBMS-ներում տարբեր սյունակների արժեքները պահվում են առանձին, իսկ մեկ սյունակի տվյալները պահվում են միասին.
Սյունակային DBMS-ների օրինակներ են 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 աջակցությամբ և արագությամբ: Այս DBMS-ի արագությունը սահմանակից էր մոգությանը:
թեթեւացնել
Clickhouse-ը տեղադրված է Ubuntu-ում մեկ հրամանով: Եթե դուք գիտեք SQL-ը, կարող եք անմիջապես սկսել Clickhouse-ն օգտագործել ձեր կարիքների համար: Այնուամենայնիվ, դա չի նշանակում, որ դուք կարող եք անել «ցուցադրել ստեղծել աղյուսակը» MySQL-ում և պատճենել-տեղադրել SQL-ը Clickhouse-ում:
Համեմատած MySQL-ի հետ՝ աղյուսակի սխեմայի սահմանումների մեջ կան տվյալների տիպի կարևոր տարբերություններ, այնպես որ ձեզ դեռ որոշ ժամանակ կպահանջվի աղյուսակի սխեմայի սահմանումները փոխելու և սեղանի շարժիչները սովորելու համար՝ հարմարավետություն ձեռք բերելու համար:
Clickhouse-ը հիանալի է աշխատում առանց որևէ լրացուցիչ ծրագրաշարի, բայց եթե ցանկանում եք կրկնօրինակել, ապա ձեզ հարկավոր է տեղադրել ZooKeeper-ը: Հարցումների կատարողականի վերլուծությունը ցույց է տալիս գերազանց արդյունքներ. համակարգի աղյուսակները պարունակում են ամբողջ տեղեկատվությունը, և բոլոր տվյալները կարող են առբերվել հին և ձանձրալի SQL-ի միջոցով:
Արտադրողականություն
- Clickhouse-ի համեմատությունները Vertica-ի և MySQL-ի հետ սերվերի կոնֆիգուրացիայի վրա. երկու վարդակներ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 ԳԲ RAM; md RAID-5 8 6TB SATA HDD-ի վրա, ext4:
- Clickhouse-ի համեմատությունը Amazon RedShift ամպային պահեստի հետ:
- Բլոգի հատվածներ :
ClickHouse տվյալների բազան ունի շատ պարզ դիզայն. կլաստերի բոլոր հանգույցներն ունեն նույն ֆունկցիոնալությունը և համակարգման համար օգտագործում են միայն ZooKeeper-ը: Մենք կառուցեցինք մի քանի հանգույցներից բաղկացած փոքր կլաստեր և կատարեցինք թեստավորում, որի ընթացքում պարզեցինք, որ համակարգն ունի բավականին տպավորիչ կատարողականություն, ինչը համապատասխանում է վերլուծական DBMS-ի չափորոշիչներում նշված առավելություններին: Մենք որոշեցինք ավելի մոտիկից նայել ClickHouse-ի հիմքում ընկած հայեցակարգին: Հետազոտության առաջին խոչընդոտը գործիքների և ClickHouse փոքր համայնքի բացակայությունն էր, ուստի մենք խորացանք այս DBMS-ի նախագծման մեջ՝ հասկանալու, թե ինչպես է այն աշխատում:
ClickHouse-ը չի աջակցում տվյալների ուղղակիորեն Kafka-ից ստանալը, քանի որ դա պարզապես տվյալների բազա է, ուստի մենք գրել ենք մեր սեփական ադապտերների ծառայությունը Go-ում: Այն կարդում էր Cap'n Proto-ի կոդավորված հաղորդագրությունները Կաֆկայից, դրանք փոխակերպում էր TSV-ի և խմբաքանակով տեղադրում ClickHouse-ում HTTP ինտերֆեյսի միջոցով: Մենք ավելի ուշ վերագրեցինք այս ծառայությունը, որպեսզի օգտագործենք Go գրադարանը ClickHouse-ի սեփական ինտերֆեյսի հետ համատեղ՝ արդյունավետությունը բարելավելու համար: Ստացող փաթեթների աշխատանքը գնահատելիս մենք հայտնաբերեցինք մի կարևոր բան. պարզվեց, որ ClickHouse-ի համար այս կատարումը մեծապես կախված է փաթեթի չափից, այսինքն՝ միաժամանակ տեղադրված տողերի քանակից: Հասկանալու համար, թե ինչու է դա տեղի ունենում, մենք նայեցինք, թե ինչպես է ClickHouse-ը պահում տվյալները:
Հիմնական շարժիչը, ավելի ճիշտ՝ սեղանի շարժիչների ընտանիքը, որն օգտագործվում է ClickHouse-ի կողմից տվյալների պահպանման համար, MergeTree-ն է: Այս շարժիչը կոնցեպտուալ առումով նման է LSM ալգորիթմին, որն օգտագործվում է Google BigTable-ում կամ Apache Cassandra-ում, սակայն խուսափում է միջանկյալ հիշողության աղյուսակ կառուցելուց և տվյալները ուղղակիորեն գրում սկավառակի վրա: Սա նրան տալիս է գրելու գերազանց թողունակություն, քանի որ յուրաքանչյուր տեղադրված փաթեթ տեսակավորվում է միայն հիմնական բանալիով, սեղմվում և գրվում սկավառակի վրա՝ հատված ձևավորելու համար:
Հիշողության աղյուսակի կամ տվյալների «թարմության» որևէ հասկացության բացակայությունը նաև նշանակում է, որ դրանք կարող են միայն ավելացվել, համակարգը չի աջակցում փոխել կամ ջնջել: Ներկայումս տվյալները ջնջելու միակ միջոցը դրանք օրացուցային ամիսներով ջնջելն է, քանի որ հատվածները երբեք չեն հատում ամսվա սահմանը: ClickHouse-ի թիմը ակտիվորեն աշխատում է այս հատկությունը հարմարեցնելու համար: Մյուս կողմից, այն ստիպում է գրել և միաձուլել հատվածները առանց վիճաբանության, այնպես որ ստացեք թողունակության սանդղակները գծային՝ միաժամանակյա ներդիրների քանակով մինչև I/O կամ միջուկի հագեցվածությունը:
Այնուամենայնիվ, սա նաև նշանակում է, որ համակարգը հարմար չէ փոքր փաթեթների համար, ուստի Kafka-ի ծառայություններն ու ներդիրները օգտագործվում են բուֆերացման համար: Հաջորդը, հետին պլանում գտնվող ClickHouse-ը շարունակում է անընդհատ կատարել հատվածների միաձուլումը, այնպես որ շատ փոքր տեղեկություններ կհամակցվեն և կգրանցվեն ավելի շատ անգամ՝ այդպիսով բարձրացնելով ձայնագրման ինտենսիվությունը: Այնուամենայնիվ, չափազանց շատ չկապակցված մասերը կհանգեցնեն ներդիրների ագրեսիվ կեղտոտմանը, քանի դեռ միաձուլումը շարունակվում է: Մենք պարզել ենք, որ լավագույն փոխզիջումը իրական ժամանակում կլանման և կուլ տալու կատարողականի միջև աղյուսակում վայրկյանում սահմանափակ թվով ներդիրների ընդունումն է:
Աղյուսակի ընթերցման աշխատանքի բանալին ինդեքսավորումն է և սկավառակի վրա տվյալների գտնվելու վայրը: Անկախ նրանից, թե որքան արագ է մշակումը, երբ շարժիչը պետք է սկանավորի տերաբայթ տվյալներ սկավառակից և օգտագործի դրա միայն մի մասը, դա ժամանակ կպահանջի: ClickHouse-ը սյունակային պահեստ է, ուստի յուրաքանչյուր հատված պարունակում է ֆայլ յուրաքանչյուր սյունակի (սյունակի) համար՝ յուրաքանչյուր տողի համար տեսակավորված արժեքներով: Այսպիսով, հարցումից բացակայող ամբողջ սյունակները կարող են սկզբում բաց թողնել, այնուհետև մի քանի բջիջներ կարող են մշակվել վեկտորացված կատարմանը զուգահեռ: Ամբողջական սկանավորումից խուսափելու համար յուրաքանչյուր հատված ունի փոքր ինդեքսային ֆայլ:
Հաշվի առնելով, որ բոլոր սյունակները դասավորված են «հիմնական բանալիով», ինդեքսի ֆայլը պարունակում է միայն յուրաքանչյուր n-րդ տողի պիտակները (գրված տողերը), որպեսզի դրանք կարողանան պահել հիշողության մեջ նույնիսկ շատ մեծ աղյուսակների համար: Օրինակ, կարող եք լռելյայն կարգավորումները դնել «նշել յուրաքանչյուր 8192-րդ տողը», ապա «խղճուկ» աղյուսակի ինդեքսավորումը 1 տրիլիոնով: Հիշողության մեջ հեշտությամբ տեղավորվող տողերը կպահանջեն ընդամենը 122 նիշ:
Համակարգի զարգացում
Clickhouse-ի զարգացմանն ու կատարելագործմանը կարելի է հետևել այստեղ և համոզվեք, որ «մեծանալու» գործընթացը տպավորիչ տեմպերով է ընթանում:
Ժողովրդականություն
Քլիքհաուսի ժողովրդականությունը, կարծես, երկրաչափական աճ է գրանցում, հատկապես ռուսալեզու համայնքում: Անցյալ տարվա High load 2018 կոնֆերանսը (Մոսկվա, 8թ. նոյեմբերի 9-2018-ը) ցույց տվեց, որ այնպիսի հրեշներ, ինչպիսիք են vk.com-ը և Badoo-ն, օգտագործում են Clickhouse-ը, որի միջոցով նրանք միաժամանակ տեղադրում են տվյալներ (օրինակ՝ տեղեկամատյաններ) տասնյակ հազարավոր սերվերներից։ 40 րոպեանոց տեսանյութում . Շուտով մենք կտեղադրենք սղագրությունը Habr-ում՝ նյութի հետ աշխատելու հեշտության համար:
Դիմումները
Որոշ ժամանակ ուսումնասիրելիս, կարծում եմ, կան ոլորտներ, որտեղ ClickHouse-ը կարող է օգտակար լինել կամ ամբողջությամբ փոխարինել այլ, ավելի ավանդական և հայտնի լուծումներ, ինչպիսիք են MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot և դրուիդ. Հետևյալը նկարագրում է ClickHouse-ի օգտագործման մանրամասները՝ վերը նշված DBMS-ն արդիականացնելու կամ ամբողջությամբ փոխարինելու համար:
Ընդլայնելով MySQL-ի և PostgreSQL-ի հնարավորությունները
Վերջերս մենք մասամբ փոխարինեցինք MySQL-ը ClickHouse-ով մեր տեղեկագրի հարթակի համար . Խնդիրն այն էր, որ MySQL-ը, վատ դիզայնի պատճառով, գրանցում էր յուրաքանչյուր ուղարկված նամակը և այդ էլփոստի յուրաքանչյուր հղումը base64 հեշով՝ ստեղծելով հսկայական MySQL աղյուսակ (email_stats): Ծառայության բաժանորդներին ընդամենը 10 միլիոն նամակ ուղարկելուց հետո այս աղյուսակը զբաղեցրեց 150 ԳԲ ֆայլի տարածք, և MySQL-ն սկսեց «հիմար» լինել պարզ հարցումների դեպքում: Ֆայլի տարածության խնդիրը շտկելու համար մենք հաջողությամբ օգտագործեցինք InnoDB աղյուսակի սեղմումը, ինչը նվազեցրեց այն 4 անգամ: Այնուամենայնիվ, դեռևս իմաստ չունի MySQL-ում ավելի քան 20-30 միլիոն էլ. նամակներ պահել միայն պատմությունը կարդալու համար, քանի որ ցանկացած պարզ հարցում, որը ինչ-ինչ պատճառներով պահանջում է ամբողջական սկանավորում, հանգեցնում է փոխանակման և շատ I-ի: /O load, ըստ որի Zabbix-ից պարբերաբար զգուշացումներ էինք ստանում։
Clickhouse-ն օգտագործում է երկու սեղմման ալգորիթմ, որոնք մոտավորապես նվազեցնում են տվյալների ծավալը , բայց կոնկրետ այս դեպքում տվյալները հատկապես «սեղմելի» էին։
ELK-ի փոխարինում
Ելնելով իմ սեփական փորձից՝ ELK stack-ը (ElasticSearch, Logstash և Kibana, այս կոնկրետ դեպքում ElasticSearch) գործարկման համար պահանջում է շատ ավելի շատ ռեսուրսներ, քան անհրաժեշտ է տեղեկամատյանները պահելու համար: ElasticSearch-ը հիանալի շարժիչ է, եթե Ձեզ անհրաժեշտ է ամբողջական տեքստային տեղեկամատյանների լավ որոնում (ինչը, կարծում եմ, իրականում ձեզ անհրաժեշտ չէ), բայց ես զարմանում եմ, թե ինչու է այն դարձել դե ֆակտո ստանդարտ անտառահատումների շարժիչ: Logstash-ի հետ զուգակցված դրա կատարողականությունը մեզ խնդիրներ առաջացրեց նույնիսկ բավականին թեթև բեռների դեպքում և մեզանից պահանջեց ավելացնել ավելի ու ավելի շատ RAM և սկավառակի տարածք: Որպես տվյալների բազա, Clickhouse-ն ավելի լավն է, քան ElasticSearch-ը հետևյալ պատճառներով.
- SQL բարբառի աջակցություն;
- Պահպանված տվյալների սեղմման լավագույն աստիճանը;
- Regex կանոնավոր արտահայտությունների որոնումների աջակցություն ամբողջական տեքստային որոնումների փոխարեն;
- Բարելավված հարցումների պլանավորում և ավելի բարձր ընդհանուր կատարողականություն:
Ներկայում ամենամեծ խնդիրը, որն առաջանում է ClickHouse-ը ELK-ի հետ համեմատելիս, տեղեկամատյանների վերբեռնման լուծումների բացակայությունն է, ինչպես նաև թեմայի վերաբերյալ փաստաթղթերի և ձեռնարկների բացակայությունը։ Ավելին, յուրաքանչյուր օգտվող կարող է կարգավորել ELK-ն՝ օգտագործելով Digital Ocean ձեռնարկը, որը շատ կարևոր է նման տեխնոլոգիաների արագ ներդրման համար։ Կա տվյալների բազայի շարժիչ, բայց ClickHouse-ի համար Filebeat դեռ չկա: Այո, այնտեղ կա և գերանների հետ աշխատելու համակարգ , կա գործիք մուտքագրման ֆայլի տվյալները ClickHouse-ում մուտքագրելու համար, սակայն այս ամենն ավելի շատ ժամանակ է պահանջում: Այնուամենայնիվ, ClickHouse-ը դեռևս առաջատարն է իր պարզության շնորհիվ, այնպես որ նույնիսկ սկսնակները կարող են հեշտությամբ տեղադրել այն և սկսել օգտագործել այն ամբողջությամբ ֆունկցիոնալ կերպով ընդամենը 10 րոպեում:
Նախընտրելով մինիմալիստական լուծումները, ես փորձեցի օգտագործել FluentBit-ը, որը շատ քիչ հիշողությամբ տեղեկամատյանների առաքման գործիք է, ClickHouse-ի հետ միասին՝ միաժամանակ փորձելով խուսափել Kafka-ի օգտագործումից: Այնուամենայնիվ, փոքր անհամատեղելիությունները պետք է լուծվեն, ինչպիսիք են նախքան դա կարելի է անել առանց վստահված անձի շերտի, որը փոխակերպում է տվյալները FluentBit-ից ClickHouse-ի:
Որպես այլընտրանք, Kibana-ն կարող է օգտագործվել որպես ClickHouse backend . Այն, ինչ ես հասկանում եմ, դա կարող է առաջացնել աշխատանքի հետ կապված խնդիրներ հսկայական թվով տվյալների կետեր ներկայացնելիս, հատկապես Grafana-ի հին տարբերակների դեպքում: Մենք դեռ չենք փորձել դա Qwintry-ում, բայց դրա վերաբերյալ բողոքները ժամանակ առ ժամանակ հայտնվում են Telegram-ի ClickHouse աջակցության ալիքում:
Google Big Query-ի և Amazon RedShift-ի փոխարինում (խոշոր ընկերությունների լուծում)
BigQuery-ի օգտագործման իդեալական դեպքն է բեռնել 1 ՏԲ JSON տվյալներ և կատարել վերլուծական հարցումներ դրա վրա: Big Query-ը հիանալի արտադրանք է, որի մասշտաբայնությունը չի կարելի գերագնահատել: Սա շատ ավելի բարդ ծրագրաշար է, քան ClickHouse-ը, որն աշխատում է ներքին կլաստերի վրա, բայց հաճախորդի տեսանկյունից այն շատ ընդհանրություններ ունի ClickHouse-ի հետ: BigQuery-ն կարող է արագ թանկանալ, երբ սկսեք վճարել մեկ SELECT-ի համար, ուստի այն իսկական SaaS լուծում է՝ իր բոլոր դրական և բացասական կողմերով:
ClickHouse-ը լավագույն ընտրությունն է, երբ դուք շատ հաշվողականորեն թանկ հարցումներ եք կատարում: Որքան շատ SELECT հարցումներ գործադրեք ամեն օր, այնքան ավելի իմաստալից կլինի Big Query-ին փոխարինել ClickHouse-ով, քանի որ նման փոխարինումը կարող է ձեզ հազարավոր դոլարներ խնայել, երբ խոսքը վերաբերում է բազմաթիվ տերաբայթ տվյալների մշակմանը: Սա չի վերաբերում պահված տվյալներին, որոնք բավականին էժան են մշակել Big Query-ում:
Altinity-ի համահիմնադիր Ալեքսանդր Զայցևի հոդվածում խոսում է նման DBMS միգրացիայի առավելությունների մասին:
TimescaleDB-ի փոխարինում
TimescaleDB-ը PostgreSQL ընդլայնում է, որն օպտիմիզացնում է ժամանակային շարքերի հետ աշխատանքը սովորական տվյալների բազայում (, ).
Թեև ClickHouse-ը լուրջ մրցակից չէ ժամանակային շարքերի, այլ սյունակային կառուցվածքի և վեկտորի հարցումների կատարման մեջ, այն շատ ավելի արագ է, քան TimescaleDB-ը վերլուծական հարցումների մշակման շատ դեպքերում: Միևնույն ժամանակ, ClickHouse-ից խմբաքանակի տվյալների ստացման արդյունավետությունը մոտավորապես 3 անգամ ավելի բարձր է, և այն նաև օգտագործում է 20 անգամ ավելի քիչ սկավառակի տարածություն, ինչը իսկապես կարևոր է մեծ ծավալի պատմական տվյալների մշակման համար. .
Ի տարբերություն ClickHouse-ի, TimescaleDB-ում սկավառակի որոշակի տարածություն խնայելու միակ միջոցը ZFS կամ նմանատիպ ֆայլային համակարգեր օգտագործելն է:
ClickHouse-ի առաջիկա թարմացումները, ամենայն հավանականությամբ, կներկայացնեն դելտա սեղմում, ինչը այն ավելի հարմար կդարձնի ժամանակային շարքերի տվյալների մշակման և պահպանման համար: TimescaleDB-ն կարող է ավելի լավ ընտրություն լինել, քան մերկ ClickHouse-ը հետևյալ դեպքերում.
- փոքր տեղակայումներ շատ քիչ RAM-ով (<3 ԳԲ);
- մեծ թվով փոքր ներդիրներ, որոնք դուք չեք ցանկանում բուֆերացնել մեծ բեկորների մեջ.
- ավելի լավ հետևողականություն, միատեսակություն և ACID պահանջներ.
- PostGIS աջակցություն;
- միանալով առկա PostgreSQL աղյուսակներին, քանի որ Timescale DB-ն ըստ էության PostgreSQL է:
Մրցակցություն Hadoop և MapReduce համակարգերի հետ
Hadoop-ը և MapReduce-ի այլ արտադրանքները կարող են շատ բարդ հաշվարկներ կատարել, բայց դրանք հակված են աշխատելու հսկայական ուշացումներով: ClickHouse-ը լուծում է այս խնդիրը՝ մշակելով տերաբայթ տվյալներ և գրեթե ակնթարթորեն արդյունք տալով: Այսպիսով, ClickHouse-ը շատ ավելի արդյունավետ է արագ, ինտերակտիվ վերլուծական հետազոտություններ կատարելու հարցում, որը պետք է հետաքրքրի տվյալների գիտնականներին:
Մրցակցություն Պինոյի և Դրուիդի հետ
ClickHouse-ի ամենամոտ մրցակիցները սյունակային, գծային մասշտաբային բաց կոդով արտադրանքներն են՝ Pinot-ը և Druid-ը: Այս համակարգերը համեմատող հիանալի աշխատանք հրապարակված է հոդվածում փետրվարի 1, 2018 թ
Այս հոդվածը թարմացման կարիք ունի. այն ասում է, որ ClickHouse-ը չի աջակցում UPDATE և DELETE գործողությունները, ինչը լիովին ճիշտ չէ վերջին տարբերակների համար:
Մենք մեծ փորձ չունենք այս տվյալների շտեմարանների հետ, բայց ինձ իսկապես դուր չի գալիս ենթակառուցվածքի բարդությունը, որն անհրաժեշտ է Druid-ը և Pinot-ը գործարկելու համար. դա շարժական մասերի մի ամբողջ փունջ է, որը շրջապատված է Java-ով բոլոր կողմերից:
Druid-ը և Pinot-ը Apache ինկուբատորի նախագծեր են, որոնց առաջընթացը մանրամասնորեն լուսաբանվում է Apache-ի կողմից իր GitHub նախագծի էջերում: Պինոն հայտնվել է ինկուբատորում 2018 թվականի հոկտեմբերին, իսկ Դրյուդը ծնվել է 8 ամիս առաջ՝ փետրվարին։
Տեղեկատվության բացակայությունն այն մասին, թե ինչպես է աշխատում AFS-ը, ինձ մոտ առաջացնում է որոշ, և գուցե հիմար հարցեր: Հետաքրքիր է, Pinot-ի հեղինակները նկատե՞լ են, որ Apache հիմնադրամն ավելի բարենպաստ է դրուիդի նկատմամբ, և արդյոք մրցակցի նկատմամբ այս վերաբերմունքը նախանձի զգացում է առաջացրել։ Արդյո՞ք Դրուիդի զարգացումը կդանդաղի, իսկ Պինոյի զարգացումը կարագանա, եթե առաջինի կողմնակիցները հանկարծ հետաքրքրվեն երկրորդով:
ClickHouse-ի թերությունները
Անհասունություն. Ակնհայտ է, որ սա դեռ ձանձրալի տեխնոլոգիա չէ, բայց ամեն դեպքում, այլ սյունակային DBMS-ներում նման բան չի նկատվում:
Փոքր ներդիրները լավ չեն աշխատում բարձր արագությամբ. ներդիրները պետք է բաժանվեն ավելի մեծ կտորների, քանի որ փոքր ներդիրների աշխատանքը վատթարանում է յուրաքանչյուր տողում սյունակների քանակի համամասնությամբ: Ահա թե ինչպես է ClickHouse-ը պահում տվյալները սկավառակի վրա. յուրաքանչյուր սյունակ ներկայացնում է 1 կամ ավելի ֆայլ, ուստի 1 սյունակ պարունակող 100 տող տեղադրելու համար անհրաժեշտ է բացել և գրել առնվազն 100 ֆայլ: Ահա թե ինչու բուֆերային ներդիրները պահանջում են միջնորդ (եթե հաճախորդն ինքը չի ապահովում բուֆերավորում)՝ սովորաբար Կաֆկա կամ հերթերի կառավարման ինչ-որ համակարգ: Դուք կարող եք նաև օգտագործել Buffer աղյուսակի շարժիչը՝ հետագայում տվյալների մեծ կտորները MergeTree աղյուսակներում պատճենելու համար:
Սեղանի միացումները սահմանափակված են սերվերի RAM-ով, բայց գոնե դրանք կան: Օրինակ, Druid-ը և Pinot-ն ընդհանրապես նման կապեր չունեն, քանի որ դրանք դժվար է իրականացնել ուղղակիորեն բաշխված համակարգերում, որոնք չեն աջակցում հանգույցների միջև տվյալների մեծ կտորների տեղափոխմանը:
Արդյունքները
Մենք նախատեսում ենք առաջիկա տարիներին լայնորեն օգտագործել ClickHouse-ը Qwintry-ում, քանի որ այս DBMS-ն ապահովում է կատարողականի գերազանց հավասարակշռություն, ցածր ծախսեր, մասշտաբայնություն և պարզություն: Համոզված եմ, որ այն կսկսի արագ տարածվել, երբ ClickHouse համայնքը կգտնի ավելի շատ եղանակներ՝ այն օգտագործելու փոքր և միջին չափի կայանքներում:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com