је систем за управљање колонском базом података отвореног кода за онлајн аналитичку обраду упита (ОЛАП), креиран од стране Иандек-а. Користе га Иандек, ЦлоудФларе, ВК.цом, Бадоо и други сервиси широм света за складиштење заиста великих количина података (убацивање хиљада редова у секунди или петабајта података ускладиштених на диску).
У обичном, „стринг“ ДБМС, чији су примери МиСКЛ, Постгрес, МС СКЛ Сервер, подаци се чувају следећим редоследом:
У овом случају, вредности које се односе на један ред су физички ускладиштене у близини. У колонским ДБМС-овима, вредности из различитих колона се чувају одвојено, а подаци из једне колоне се чувају заједно:
Примери стубних ДБМС-ова су Вертица, Параццел (Ацтиан Матрик, Амазон Редсхифт), Сибасе ИК, Екасол, Инфобригхт, ИнфиниДБ, МонетДБ (ВецторВисе, Ацтиан Вецтор), ЛуцидДБ, САП ХАНА, Гоогле Дремел, Гоогле ПоверДрилл, Друид, кдб+.
Компанија за отпрему поште је почео да користи Цлицкхоусе 2018. године за извештавање и био је веома импресиониран његовом једноставношћу, скалабилности, СКЛ подршком и брзином. Брзина овог ДБМС-а се граничила са магијом.
ублажити
Цлицкхоусе се инсталира на Убунту помоћу једне наредбе. Ако знате СКЛ, можете одмах почети да користите Цлицкхоусе за своје потребе. Међутим, то не значи да можете да урадите „прикажи креирање табеле“ у МиСКЛ-у и да копирате и залепите СКЛ у Цлицкхоусе-у.
У поређењу са МиСКЛ-ом, постоје важне разлике у типовима података у дефиницијама шеме табеле, тако да ће вам и даље требати неко време да промените дефиниције шеме табеле и научите механизме табела да бисте се лакше снашли.
Цлицкхоусе ради одлично без икаквог додатног софтвера, али ако желите да користите репликацију, мораћете да инсталирате ЗооКеепер. Анализа перформанси упита показује одличне резултате – системске табеле садрже све информације, а сви подаци се могу преузети помоћу старог и досадног СКЛ-а.
Перформансе
- поређења Цлицкхоусе-а са Вертица-ом и МиСКЛ-ом на конфигурацији сервера: два сокета Интел® Ксеон® ЦПУ Е5-2650 в2 @ 2.60ГХз; 128 ГиБ РАМ; мд РАИД-5 на 8 6ТБ САТА ХДД, ект4.
- поређење Цлицкхоусе-а са Амазон РедСхифт складиштем у облаку.
- Изводи из блогова :
ЦлицкХоусе база података има веома једноставан дизајн - сви чворови у кластеру имају исту функционалност и користе само ЗооКеепер за координацију. Направили смо мали кластер од неколико чворова и извршили тестирање, током којег смо утврдили да систем има прилично импресивне перформансе, што одговара наведеним предностима у аналитичким ДБМС бенцхмарковима. Одлучили смо да ближе погледамо концепт иза ЦлицкХоусе-а. Прва препрека истраживању био је недостатак алата и мала ЦлицкХоусе заједница, па смо се удубили у дизајн овог ДБМС-а да бисмо разумели како он функционише.
ЦлицкХоусе не подржава пријем података директно од Кафке јер је то само база података, па смо написали сопствену услугу адаптера у Го. Читао је Цап'н Прото кодиране поруке из Кафке, претварао их у ТСВ и убацивао их у ЦлицкХоусе у серијама преко ХТТП интерфејса. Касније смо поново написали ову услугу да бисмо користили Го библиотеку у комбинацији са сопственим интерфејсом ЦлицкХоусе-а да бисмо побољшали перформансе. Приликом процене перформанси пријема пакета, открили смо важну ствар - испоставило се да за ЦлицкХоусе ова изведба јако зависи од величине пакета, односно броја истовремено убачених редова. Да бисмо разумели зашто се то дешава, погледали смо како ЦлицкХоусе чува податке.
Главни механизам, односно породица машина за табеле, коју ЦлицкХоусе користи за складиштење података је МергеТрее. Овај механизам је концептуално сличан ЛСМ алгоритму који се користи у Гоогле БигТабле-у или Апацхе Цассандри, али избегава конструисање међутабеле меморије и уписује податке директно на диск. Ово му даје одличну пропусност писања, пошто се сваки уметнути пакет сортира само по примарном кључу, компримује и записује на диск да би се формирао сегмент.
Одсуство табеле меморије или било каквог концепта „свежине“ података такође значи да се они могу само додати; систем не подржава мењање или брисање. Тренутно, једини начин за брисање података је да их избришете по календарском месецу, пошто сегменти никада не прелазе границу месеца. ЦлицкХоусе тим активно ради на томе да ову функцију учини прилагодљивом. С друге стране, чини сегменте за писање и спајање без сукоба, тако да се пропусност прима линеарно са бројем истовремених уметања док не дође до засићења улаза/излаза или језгра.
Међутим, то такође значи да систем није погодан за мале пакете, па се за баферовање користе Кафкини сервиси и убацивачи. Затим, ЦлицкХоусе у позадини наставља да константно врши спајање сегмената, тако да ће се многи мали делови информација комбиновати и снимати више пута, чиме се повећава интензитет снимања. Међутим, превише неповезаних делова ће изазвати агресивно пригушивање уметака све док се спајање наставља. Открили смо да је најбољи компромис између уноса у реалном времену и перформанси уноса унос ограниченог броја уметања у секунди у табелу.
Кључ за перформансе читања табеле је индексирање и локација података на диску. Без обзира колико је обрада брза, када машина треба да скенира терабајте података са диска и користи само њихов део, биће потребно време. ЦлицкХоусе је стубна продавница, тако да сваки сегмент садржи датотеку за сваку колону (колона) са сортираним вредностима за сваки ред. На овај начин, целе колоне које недостају у упиту могу се прво прескочити, а затим се више ћелија може обрадити паралелно са векторизованим извршавањем. Да би се избегло потпуно скенирање, сваки сегмент има малу индексну датотеку.
С обзиром на то да су све колоне сортиране према „примарном кључу“, индексна датотека садржи само ознаке (ухваћене редове) сваког Н-тог реда да би их могла задржати у меморији чак и за веома велике табеле. На пример, можете подесити подразумевана подешавања на „означите сваки 8192. ред“, а затим на „оскудно“ индексирање табеле са 1 трилион. редови који се лако уклапају у меморију заузимају само 122 знакова.
Развој система
Развој и унапређење Цлицкхоусе-а може се пратити на и побрините се да се процес „одрастања“ одвија импресивним темпом.
Популарност
Изгледа да Цлицкхоусе-ова популарност расте експоненцијално, посебно у заједници која говори руски. Прошлогодишња конференција Хигх лоад 2018 (Москва, 8-9. новембар 2018) показала је да чудовишта као што су вк.цом и Бадоо користе Цлицкхоусе, помоћу које истовремено убацују податке (на пример, логове) са десетина хиљада сервера. У видеу од 40 минута . Ускоро ћемо транскрипт поставити на Хабр ради лакшег рада са материјалом.
Апликације
Након што сам провео неко време у истраживању, мислим да постоје области у којима би ЦлицкХоусе могао бити користан или би могао у потпуности да замени друга, традиционалнија и популарнија решења као што су МиСКЛ, ПостгреСКЛ, ЕЛК, Гоогле Биг Куери, Амазон РедСхифт, ТимесцалеДБ, Хадооп, МапРедуце, Пинот и Друид. У наставку су описани детаљи коришћења ЦлицкХоусе-а за модернизацију или потпуну замену горњег ДБМС-а.
Проширивање могућности МиСКЛ-а и ПостгреСКЛ-а
Недавно смо делимично заменили МиСКЛ са ЦлицкХоусе за нашу платформу за билтен . Проблем је био у томе што је МиСКЛ, због лошег дизајна, бележио сваку послату е-пошту и сваку везу у тој е-поруци са басе64 хешом, стварајући огромну МиСКЛ табелу (емаил_статс). Након слања само 10 милиона писама претплатницима услуге, ова табела је заузела 150 ГБ простора за датотеке, а МиСКЛ је почео да буде „глуп“ на једноставне упите. Да бисмо решили проблем са простором датотека, успешно смо користили компресију табеле ИнноДБ која га је смањила за 4к. Међутим, и даље нема смисла чувати више од 20-30 милиона е-порука у МиСКЛ само ради читања историје, пошто сваки једноставан упит који из неког разлога треба да изврши потпуно скенирање резултира заменом и доста ја /О лоад, о чему смо редовно добијали упозорења од Заббик-а.
Цлицкхоусе користи два алгоритма компресије који смањују обим података отприлике , али у овом конкретном случају подаци су били посебно "компримљиви".
Замена ЕЛК
На основу мог сопственог искуства, ЕЛК стек (ЕластицСеарцх, Логстасх и Кибана, у овом конкретном случају ЕластицСеарцх) захтева много више ресурса за покретање него што је потребно за складиштење дневника. ЕластицСеарцх је одличан мотор ако вам је потребна добра претрага по целом тексту дневника (за коју мислим да вам заиста није потребна), али се питам зашто је постао де фацто стандардни механизам за евидентирање. Његове перформансе уноса у комбинацији са Логстасх-ом стварале су нам проблеме чак и под прилично малим оптерећењима и захтевале су од нас да додајемо све више РАМ-а и простора на диску. Као база података, Цлицкхоусе је бољи од ЕластицСеарцх-а из следећих разлога:
- подршка за СКЛ дијалект;
- Најбољи степен компресије ускладиштених података;
- Подршка за претрагу регуларних израза Регек уместо претраживања целог текста;
- Побољшано заказивање упита и већи укупни учинак.
Тренутно највећи проблем који настаје када се упореди ЦлицкХоусе са ЕЛК-ом је недостатак решења за уплоад логова, као и недостатак документације и туторијала на ту тему. Штавише, сваки корисник може да конфигурише ЕЛК користећи приручник Дигитал Оцеан, што је веома важно за брзу имплементацију оваквих технологија. Постоји механизам за базе података, али још увек не постоји Филебеат за ЦлицкХоусе. Да, тамо је и систем за рад са балванима , постоји алат да унесете податке из датотеке евиденције у ЦлицкХоусе, али све ово захтева више времена. Међутим, ЦлицкХоусе је и даље лидер због своје једноставности, па чак и почетници могу лако да га инсталирају и почну да га потпуно функционално користе за само 10 минута.
Преферирајући минималистичка решења, покушао сам да користим ФлуентБит, алатку за испоруку дневника са врло мало меморије, заједно са ЦлицкХоусе, док сам покушавао да избегнем употребу Кафке. Међутим, потребно је решити мање некомпатибилности, као нпр пре него што се ово може урадити без прокси слоја који конвертује податке из ФлуентБит-а у ЦлицкХоусе.
Као алтернатива, Кибана се може користити као ЦлицкХоусе бацкенд . Колико сам разумео, ово може да изазове проблеме са перформансама при приказивању огромног броја тачака података, посебно са старијим верзијама Графане. Ово још нисмо испробали у Квинтри-у, али се притужбе о томе с времена на време појављују на ЦлицкХоусе каналу подршке на Телеграму.
Замена Гоогле Биг Куери и Амазон РедСхифт (решење за велике компаније)
Идеалан случај употребе БигКуери-ја је учитавање 1 ТБ ЈСОН података и покретање аналитичких упита на њима. Биг Куери је одличан производ чија се скалабилност не може преценити. Ово је много сложенији софтвер од ЦлицкХоусе-а, који ради на интерном кластеру, али са становишта клијента има много заједничког са ЦлицкХоусе-ом. БигКуери може брзо да поскупи када почнете да плаћате по СЕЛЕЦТ, тако да је то право СааС решење са свим својим предностима и недостацима.
ЦлицкХоусе је најбољи избор када покрећете много рачунарски скупих упита. Што више СЕЛЕЦТ упита покрећете сваког дана, то има смисла заменити Биг Куери са ЦлицкХоусе, јер вам таква замена може уштедети хиљаде долара када је у питању много терабајта података који се обрађују. Ово се не односи на ускладиштене податке, који су прилично јефтини за обраду у Биг Куерију.
У чланку суоснивача Алтинити Александра Зајцева говори о предностима такве миграције ДБМС.
ТимесцалеДБ замена
ТимесцалеДБ је ПостгреСКЛ екстензија која оптимизује рад са временским серијама у редовној бази података (, ).
Иако ЦлицкХоусе није озбиљан конкурент у ниши временских серија, већ колонарне структуре и векторског извршења упита, он је много бржи од ТимесцалеДБ-а у већини случајева аналитичке обраде упита. Истовремено, перформансе пријема групних података од ЦлицкХоусе-а су приближно 3 пута веће, а такође користи 20 пута мање простора на диску, што је заиста важно за обраду великих количина историјских података: .
За разлику од ЦлицкХоусе-а, једини начин да уштедите мало простора на диску у ТимесцалеДБ-у је коришћење ЗФС-а или сличних система датотека.
Предстојећа ажурирања ЦлицкХоусе-а ће вероватно увести делта компресију, што ће га учинити још погоднијим за обраду и складиштење података временских серија. ТимесцалеДБ може бити бољи избор од голог ЦлицкХоусе-а у следећим случајевима:
- мале инсталације са врло мало РАМ-а (<3 ГБ);
- велики број малих ИНСЕРТ-а које не желите да баферујете у велике фрагменте;
- боља конзистентност, униформност и захтеви за АЦИД;
- ПостГИС подршка;
- спајање са постојећим ПостгреСКЛ табелама, пошто је Тимесцале ДБ у суштини ПостгреСКЛ.
Конкуренција са системима Хадооп и МапРедуце
Хадооп и други МапРедуце производи могу да изврше много сложених прорачуна, али имају тенденцију да раде са великим кашњењем. ЦлицкХоусе решава овај проблем тако што обрађује терабајте података и даје резултате скоро тренутно. Дакле, ЦлицкХоусе је много ефикаснији у обављању брзих, интерактивних аналитичких истраживања, што би требало да буде од интереса за научнике података.
Такмичење са Пинотом и Друидом
Најближи конкуренти ЦлицкХоусе-а су колонасти, линеарно скалабилни производи отвореног кода Пинот и Друид. Одличан рад који упоређује ове системе је објављен у чланку 1. фебруара 2018. године
Овај чланак треба ажурирати - каже да ЦлицкХоусе не подржава операције УПДАТЕ и ДЕЛЕТЕ, што није сасвим тачно за најновије верзије.
Немамо много искуства са овим базама података, али ми се баш и не свиђа сложеност инфраструктуре која је потребна за покретање Друида и Пинот-а – то је читава гомила покретних делова окружених Јавом са свих страна.
Друид и Пинот су пројекти Апацхе инкубатора, чији напредак је детаљно покривен од стране Апацхе на својим страницама ГитХуб пројекта. Пинот се појавио у инкубатору у октобру 2018. године, а Друид је рођен 8 месеци раније - у фебруару.
Недостатак информација о томе како АФС функционише поставља нека, и можда глупа, питања за мене. Питам се да ли су аутори Пиноа приметили да је Апач фондација наклоњенија Друиду и да ли је овакав однос према конкуренту изазвао осећај зависти? Да ли ће се Друидов развој успорити, а Пинотов развој убрзати ако се присталице првог изненада заинтересују за другог?
Недостаци ЦлицкХоусе-а
Незрелост: Очигледно, ово још увек није досадна технологија, али у сваком случају, ништа слично се не види у другим колумнарским ДБМС-овима.
Мали уметци не раде добро при великој брзини: уметци се морају поделити на веће комаде јер се перформансе малих уметака смањују пропорционално броју колона у сваком реду. Овако ЦлицкХоусе чува податке на диску – свака колона представља 1 датотеку или више, тако да да бисте уметнули 1 ред који садржи 100 колона, потребно је да отворите и упишете најмање 100 датотека. Због тога је за уметање у баферовање потребан посредник (осим ако сам клијент не обезбеди баферовање) - обично Кафка или нека врста система за управљање редовима. Такође можете да користите машину за табелу бафера да бисте касније копирали велике комаде података у МергеТрее табеле.
Придруживања таблица су ограничена РАМ-ом сервера, али су барем тамо! На пример, Друид и Пинот уопште немају такве везе, пошто их је тешко имплементирати директно у дистрибуиране системе који не подржавају премештање великих комада података између чворова.
Налази
Планирамо да у наредним годинама нашироко користимо ЦлицкХоусе у Квинтри-у, јер овај ДБМС пружа одличну равнотежу перформанси, ниске трошкове, скалабилност и једноставност. Прилично сам сигуран да ће почети брзо да се шири када ЦлицкХоусе заједница смисли више начина да га користи у малим и средњим инсталацијама.
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом