ХигхЛоад++ Москва 2018, Конгресна сала. 9. новембар, 15:00
Апстракти и презентација:
Јуриј Насретдинов (ВКонтакте): Извештај ће говорити о искуству имплементације ЦлицкХоусе-а у нашој компанији – зашто нам је потребан, колико података чувамо, како их пишемо и тако даље.
Додатни материјали:
Јуриј Насретдинов: - Здраво свима! Моје име је Јуриј Насретдинов, као што сам већ представљен. Радим у ВКонтакте. Говорићу о томе како убацујемо податке у ЦлицкХоусе из наше флоте сервера (десетине хиљада).
Шта су трупци и зашто их сакупљати?
Шта ћемо вам рећи: шта смо урадили, зашто нам је био потребан „ЦлицкХоусе“, односно, зашто смо га изабрали, какве перформансе можете приближно добити без да било шта посебно конфигуришете. Рећи ћу вам даље о табелама бафера, о проблемима које смо имали са њима и о нашим решењима која смо развили из отвореног кода - КиттенХоусе и Лигхтхоусе.
Зашто смо уопште морали било шта да урадимо (на ВКонтактеу је увек све добро, зар не?). Хтели смо да прикупимо дневнике отклањања грешака (а тамо је било на стотине терабајта података), можда би некако било згодније да израчунамо статистику; а имамо флоту од десетина хиљада сервера са којих све ово треба да се уради.
Зашто смо се одлучили? Вероватно смо имали решења за чување дневника. Ево – постоји такав јавни „Бацкенд ВК“. Топло препоручујем да се претплатите на то.
Шта су дневници? Ово је мотор који враћа празне низове. Мотори у ВК-у су оно што други називају микросервисима. А ево и налепнице која се смеје (прилично лајкова). Како то? Па слушајте даље!
Шта се може користити за чување дневника? Хадупа је немогуће не поменути. Затим, на пример, Рсислог (чување ових евиденција у датотекама). ЛСД. Ко зна шта је ЛСД? Не, не овај ЛСД. Чувајте и датотеке, респективно. Па, ЦлицкХоусе је чудна опција.
Цлицкхоусе и конкуренти: захтеви и могућности
Шта ми желимо? Желимо да будемо сигурни да не морамо превише да бринемо о операцији, тако да ради из кутије, по могућности са минималном конфигурацијом. Желимо да пишемо много, и то брзо. И желимо да га задржимо свакакве месеце, године, односно дуго. Можда желимо да разумемо неки проблем са којим су нам дошли и рекли: „Овде нешто не ради“, а то је било пре 3 месеца), и желимо да можемо да видимо шта се догодило пре 3 месеца „ Компресија података – јасно је зашто би то био плус – јер смањује количину простора који заузима.
И имамо тако интересантан захтев: понекад пишемо излаз неких команди (на пример, дневника), он може бити прилично лако већи од 4 килобајта. А ако ова ствар ради преко УДП-а, онда не мора да се троши... неће имати никакве „режије“ за везу, а за велики број сервера ово ће бити плус.
Хајде да видимо шта нам нуди отворени код. Прво, имамо Логс Енгине - ово је наш мотор; У принципу, он може све, може чак и да пише дугачке редове. Па, не компримује транспарентно податке - можемо сами да компримујемо велике колоне ако желимо... ми, наравно, не желимо (ако је могуће). Једини проблем је што он уме да да само оно што му стане у памћење; Да бисте прочитали остатак, потребно је да добијете бинлог овог мотора и, сходно томе, потребно је доста времена.
Које друге опције постоје? На пример, "Хадуп". Једноставност руковања... Ко мисли да је Хадуп лако подесити? Наравно, нема проблема са снимањем. Приликом читања понекад се постављају питања. У принципу, рекао бих вероватно не, посебно за трупце. Дуготрајно складиштење - наравно, да, компресија података - да, дуги низови - јасно је да можете да снимате. Али снимање са великог броја сервера... Морате ипак нешто сами да урадите!
Рсислог. У ствари, користили смо га као резервну опцију да бисмо могли да га читамо без избацивања бинлог-а, али не може да пише дугачке редове; у принципу, не може да пише више од 4 килобајта. Компресију података морате сами да урадите на исти начин. Читање ће доћи из датотека.
Затим постоји „бадушка“ развој ЛСД-а. У суштини исто што и „Рсислог“: подржава дугачке стрингове, али не може да ради преко УДП-а и, у ствари, због тога, нажалост, доста тога мора да се тамо препише. ЛСД треба редизајнирати да би могао да снима са десетина хиљада сервера.
И овде! Смешна опција је ЕластицСеарцх. Како да кажем? Добро му иде са читањем, односно чита брзо, али не баш најбоље са писањем. Прво, ако компримује податке, веома је слаб. Највероватније, пуна претрага захтева веће структуре података од оригиналног обима. Тешко је оперисати и често се јављају проблеми са њим. И, опет, снимање у Еластику – све морамо сами.
Овде је ЦлицкХоусе идеална опција, наравно. Једино што је снимање са десетина хиљада сервера проблем. Али барем постоји један проблем, можемо покушати да га некако решимо. А остатак извештаја је о овом проблему. Какве перформансе можете очекивати од ЦлицкХоусе-а?
Како ћемо га убацити? МергеТрее
Ко од вас није чуо или зна за „ЦлицкХоусе“? Морам да ти кажем, зар не? Веома брзо. Убацивање тамо - 1-2 гигабита у секунди, рафали до 10 гигабита у секунди заправо могу да издрже ову конфигурацију - постоје два 6-језгарна Ксеона (то јест, чак ни најмоћнији), 256 гигабајта РАМ-а, 20 терабајта у РАИД-у (нико није конфигурисан, подразумевана подешавања). Алексеј Миловидов, ЦлицкХоусе програмер, вероватно седи и плаче јер ништа нисмо конфигурисали (нама је све тако функционисало). Сходно томе, брзина скенирања од, рецимо, око 6 милијарди линија у секунди може се добити ако су подаци добро компримовани. Ако волите % на текстуалном низу - 100 милиона редова у секунди, то јест, чини се прилично брзим.
Како ћемо га убацити? Па, знате да ВК користи ПХП. Убацићемо из сваког ПХП радника преко ХТТП-а у „ЦлицкХоусе“, у МергеТрее табелу за сваки запис. Ко види проблем са овом шемом? Из неког разлога нису сви дигли руке. Да вам кажем.
Прво, постоји много сервера - сходно томе, биће много веза (лоше). Тада је боље уметати податке у МергеТрее не чешће од једном у секунди. А ко зна зашто? Ок ОК. Рећи ћу вам нешто више о овоме. Још једно интересантно питање је да ми не радимо аналитику, не морамо да обогаћујемо податке, не требају нам посредни сервери, желимо да убацимо директно у „ЦлицкХоусе“ (пожељно - што директније, то боље).
Сходно томе, како се врши уметање у МергеТрее? Зашто је боље да се у њега убацује не чешће од једном у секунди или ређе? Чињеница је да је „ЦлицкХоусе“ колонаста база података и сортира податке у растућем редоследу примарног кључа, а када урадите уметање, креира се број датотека најмање једнак броју колона у којима су подаци сортирани у растућем редоследу примарног кључа (креира се посебан директоријум, скуп датотека на диску за сваки уметак). Затим долази следеће уметање, а у позадини се комбинују у веће „партиције“. Пошто су подаци сортирани, могуће је „спојити“ две сортиране датотеке без трошења много меморије.
Али, као што можете претпоставити, ако напишете 10 датотека за сваки уметак, онда ће ЦлицкХоусе (или ваш сервер) брзо завршити, па се препоручује уметање у великим серијама. Сходно томе, никада нисмо пустили прву шему у производњу. Одмах смо покренули једну, која овде број 2 има:
Ево замислите да постоји око хиљаду сервера на којима смо покренули, постоји само ПХП. И на сваком серверу постоји наш локални агент, који смо назвали „Киттенхоусе“, који одржава једну везу са „ЦлицкХоусе“-ом и убацује податке сваких неколико секунди. Убацује податке не у МергеТрее, већ у табелу бафера, која служи управо да се избегне директно уметање у МергеТрее одмах.
Рад са бафер табелама
Шта је то? Табеле бафера су део меморије који се дели (то јест, може се често убацивати у њу). Састоје се од неколико комада, а сваки од комада ради као независни пуфер, и испирају се независно (ако имате много комада у баферу, онда ће бити много уметања у секунди). Из ових табела је могуће читати - тада читате унију садржаја бафера и родитељске табеле, али у овом тренутку је уписивање блокирано, па је боље да не читате одатле. А табеле бафера показују веома добар КПС, односно до 3 хиљаде КПС нећете имати никаквих проблема при убацивању. Јасно је да ако сервер изгуби напајање, онда подаци могу бити изгубљени, јер су сачувани само у меморији.
Истовремено, шема са бафером компликује АЛТЕР, јер прво треба да испустите стару табелу бафера са старом шемом (подаци неће нестати нигде, јер ће бити испрани пре него што табела буде обрисана). Затим „измените“ табелу која вам је потребна и поново креирате табелу бафера. Сходно томе, док не постоји табела бафера, ваши подаци неће тећи нигде, али можете их имати на диску барем локално.
Шта је Киттенхоусе и како функционише?
Шта је КиттенХоусе? Ово је проки. Погодите који језик? Сакупио сам највише хипе тема у свом извештају - „Кликхаус“, Иди, можда ћу се још нечега сетити. Да, ово је написано на Го-у, јер не знам како да пишем на Ц, не желим.
Сходно томе, одржава везу са сваким сервером и може да пише у меморију. На пример, ако напишемо дневнике грешака у Цлицкхоусе, онда ако Цлицкхоусе нема времена да убаци податке (уосталом, ако је превише написано), онда не набубримо меморију - једноставно избацујемо остатак. Јер ако запишемо неколико гигабита у секунди грешака, онда вероватно можемо неке избацити. Киттенхоусе то може. Осим тога, може да изврши поуздану испоруку, односно да упише на диск на локалној машини и сваки пут (тамо, једном у неколико секунди) покуша да испоручи податке из ове датотеке. И у почетку смо користили обичан формат вредности - не неки бинарни формат, текстуални формат (као у обичном СКЛ-у).
Али онда се ово догодило. Користили смо поуздану испоруку, писали дневнике, па одлучили (био је то условни тест кластер)... Изгашен је неколико сати и поново покренут, а убацивање је почело са хиљаду сервера - испоставило се да Цлицкхоусе још увек има „Тхреад он цоннецтион“ - сходно томе, у хиљаду веза, активно уметање доводи до просека оптерећења на серверу од око хиљаду и по. Изненађујуће, сервер је прихватао захтеве, али су подаци ипак уметнути након неког времена; али серверу је било веома тешко да га послужи...
Додајте нгинк
Такво решење за модел Тхреад пер цоннецтион је нгинк. Инсталирали смо нгинк испред Цлицкхоусе-а, истовремено подесили балансирање за две реплике (наша брзина уметања је повећана за 2 пута, иако није чињеница да би то требало да буде случај) и ограничили број конекција на Цлицкхоусе, на узводно и, сходно томе, више , него у 50 веза, чини се да нема смисла убацивати.
Тада смо схватили да ова шема генерално има недостатке, јер овде имамо само један нгинк. Сходно томе, ако се овај нгинк сруши, упркос присуству реплика, губимо податке или, барем, не пишемо нигде. Зато смо направили сопствену балансирање оптерећења. Такође смо схватили да је „Цлицкхоусе“ и даље погодан за дневнике, а „демон“ је такође почео да пише своје дневнике у „Цлицкхоусе“ - врло згодно, да будем искрен. Још увек га користимо за друге „демоне“.
Затим смо открили овај интересантан проблем: ако користите нестандардни метод уметања у СКЛ режиму, он намеће пуноправни СКЛ парсер базиран на АСТ-у, који је прилично спор. Сходно томе, додали смо подешавања како бисмо осигурали да се то никада не догоди. Урадили смо балансирање оптерећења, здравствене провере, тако да ако неко умре, и даље остављамо податке. Сада имамо доста табела које су нам потребне да бисмо имали различите Цлицкхоусе кластере. Такође смо почели да размишљамо о другим употребама - на пример, желели смо да пишемо евиденције из нгинк модула, али они не знају како да комуницирају користећи наш РПЦ. Па, волео бих да их научим како да бар некако шаљу – на пример, да примају догађаје на лоцалхост преко УДП-а и да их затим проследе у Цлицкхоусе.
На корак од решења
Коначна шема је почела да изгледа овако (четврта верзија ове шеме): на сваком серверу испред Цлицкхоусе-а постоји нгинк (на истом серверу) и он једноставно проксије захтеве локалном хосту са ограничењем броја конекција од 50 комада. И ова шема је већ добро радила, све је било прилично добро са њом.
Тако смо живели око месец дана. Сви су били срећни, додавали табеле, додавали, додавали... Уопште, показало се да начин на који смо додавали табеле бафера није баш оптималан (ајде да се тако изразимо). Урадили смо 16 комада у свакој табели и интервал бљескања од неколико секунди; имали смо 20 табела и свака табела је добијала 8 уметања у секунди - и у овом тренутку је почео „Кликхаус”... записи су почели да успоравају. Нису чак ни прошли... Нгинк је подразумевано имао тако занимљиву ствар да ако се везе завршавају на узводном нивоу, онда је једноставно враћао „502“ на све нове захтеве.
И ево нас (управо сам погледао логове у самом Цлицкхоусе-у) око пола процента захтева није успело. Сходно томе, искоришћеност диска је била велика, било је много спајања. Па, шта сам урадио? Наравно, нисам се трудио да схватим зашто су се тачно веза и узводно завршили.
Замена нгинк-а обрнутим проксијем
Одлучио сам да ово треба да урадимо сами, не морамо то да препустимо нгинк-у - нгинк не зна које табеле постоје у Цлицкхоусе-у, и заменио сам нгинк обрнутим проксијем, који сам такође написао.
Шта он то ради? Ради на бази фастхттп библиотеке „госхнои“, односно брзо, скоро једнако брзо као нгинк. Извини, Игоре, ако си овде присутан (напомена: Игор Сисоев је руски програмер који је креирао нгинк веб сервер). Може да разуме какве су то упити – ИНСЕРТ или СЕЛЕЦТ – сходно томе, садржи различите скупове веза за различите типове упита.
Сходно томе, чак и ако немамо времена да завршимо захтеве за уметање, „селекти“ ће проћи, и обрнуто. И групише податке у табеле бафера – са малим бафером: ако је било грешака, грешака у синтакси и тако даље – да не би много утицали на остатак података, јер када једноставно убацимо у табеле бафера, ми имао мали "бацхи", а све синтаксне грешке су утицале само на овај мали комад; а овде ће већ утицати на велики тампон. Мала је 1 мегабајт, односно није тако мала.
Уметање синхронизације и суштински замена нгинк-а у суштини чини исту ствар коју је нгинк радио раније - не морате да мењате локални „Киттенхоусе“ за ово. А пошто користи фастхттп, веома је брз - можете направити више од 100 хиљада захтева у секунди за појединачне уметања преко обрнутог проксија. Теоретски, можете да убацујете један по један ред у реверзни прокси кућице мачића, али ми то, наравно, не радимо.
Шема је почела да изгледа овако: „Киттенхоусе“, обрнути прокси групише многе захтеве у табеле и, заузврат, табеле бафера их убацују у главне.
Убица је привремено решење, маче је трајно
Ово је занимљив проблем... Да ли је неко од вас користио фастхттп? Ко је користио фастхттп са ПОСТ захтевима? Вероватно ово заиста није требало да се уради, јер подразумевано баферује тело захтева, а величина нашег бафера је подешена на 16 мегабајта. Убацивање је у неком тренутку престало да се одржава, а делови од 16 мегабајта почели су да пристижу са свих десетина хиљада сервера, и сви су били баферовани у меморију пре него што су послати у Цлицкхоусе. Сходно томе, меморија је нестала, дошао је убица без меморије и убио обрнути прокси (или „Кликхаус“, који би теоретски могао „појести“ више од обрнутог проксија). Циклус се поновио. Није баш пријатан проблем. Иако смо на ово наишли тек након неколико месеци рада.
Шта сам урадио? Опет, не волим баш да разумем шта се тачно догодило. Мислим да је прилично очигледно да не треба баферовати у меморију. Нисам могао да закрпим фастхттп, иако сам покушао. Али сам нашао начин да то направим тако да нема потребе да било шта крпим, и смислио сам свој метод у ХТТП-у – назвао сам га КИТТЕН. Па, логично је - "ВК", "Маче"... Шта још?..
Ако захтев дође на сервер са методом Киттен, онда сервер треба да одговори „мјау“ - логично. Ако он на ово одговори, онда се сматра да разуме овај протокол, а онда ја пресретнем везу (фастхттп има такав метод), а веза прелази у „сирови“ режим. Зашто ми то треба? Желим да контролишем како се читање са ТЦП веза дешава. ТЦП има дивно својство: ако нико не чита са друге стране, онда писање почиње да чека, а меморија се не троши посебно на ово.
И тако читам од око 50 клијената одједном (од педесет јер педесет би свакако требало да буде довољно, чак и ако стопа долази из другог ДЦ)... Потрошња се овим приступом смањила најмање 20 пута, али ја, да будем искрен , нисам могао тачно да измерим колико сати, јер је већ бесмислено (већ је достигло ниво грешке). Протокол је бинарни, односно садржи име табеле и податке; нема хттп заглавља, тако да нисам користио веб утичницу (не морам да комуницирам са претраживачима - направио сам протокол који одговара нашим потребама). И све је постало добро с њим.
Табела бафера је тужна
Недавно смо наишли на још једну занимљиву карактеристику табела бафера. И овај проблем је већ много болнији од осталих. Замислимо ову ситуацију: већ активно користите Цлицкхоусе, имате десетине Цлицкхоусе сервера и имате неке захтеве за чије читање је потребно много времена (рецимо, више од 60 секунди); а ви дођете и урадите Алтер у овом тренутку... У међувремену, „селекти“ који су почели пре „Алтер“ неће бити укључени у ову табелу, „Алтер“ неће почети – вероватно неке карактеристике како „Цлицкхоусе“ функционише у ово место. Можда се ово може поправити? Или је немогуће?
Генерално, јасно је да то у стварности није тако велики проблем, али са бафер табелама постаје болније. Јер, ако, рецимо, ваша „Алтер“ тајмаута (а може истећи на другом хосту – не на вашем, већ на реплици, на пример), онда... Избрисали сте табелу бафера, свој „Алтер“ ( или неког другог хоста) истекло је временско ограничење. онда је дошло до грешке „Алтер“) – и даље морате да обезбедите да подаци и даље буду уписани: креирате табеле бафера назад (према истој шеми као и родитељска табела), а затим „Алтер“ пролази, ипак се завршава, а бафер табеле почиње да се разликује по шеми од надређеног. У зависности од тога шта је био „Алтер“, уметак можда више неће ићи у ову бафер табелу - ово је веома тужно.
Постоји и такав знак (можда га је неко приметио) - зове се куери_тхреад_лог у новим верзијама Цлицкхоусе-а. Подразумевано, у некој верзији је постојао један. Овде смо сакупили 840 милиона записа за пар месеци (100 гигабајта). То је због чињенице да су тамо написани „уметци“ (можда сада, узгред, нису написани). Као што сам вам рекао, наши "уметци" су мали - имали смо пуно "уметака" у табеле бафера. Јасно је да је ово онемогућено - само вам говорим шта сам видео на нашем серверу. Зашто? Ово је још један аргумент против коришћења табела бафера! Спотти је веома тужан.
Ко је знао да се овај тип зове Спотти? Запослени ВК дигли су руке. ОК.
О плановима за "КитттенХоусе"
Планови се обично не деле, зар не? Одједном их нећете испунити и нећете изгледати баш добро у очима других људи. Али ризиковаћу! Желимо да урадимо следеће: табеле бафера, чини ми се, још увек су штака и сами треба да баферујемо уметање. Али још увек не желимо да га баферујемо на диск, па ћемо баферовати уметање у меморију.
Сходно томе, када се направи „инсерт“, он више неће бити синхрони – већ ће радити као бафер табела, убациће се у надређену табелу (па, једног дана касније) и известити преко посебног канала који су убацивања прошли, а који нису.
Зашто не могу да оставим синхрони уметак? Много је згодније. Чињеница је да ако убаците од 10 хиљада домаћина, онда је све у реду - добићете по мало од сваког домаћина, убаците тамо једном у секунди, све је у реду. Али волео бих да ова шема ради, на пример, са две машине, тако да можете да преузимате великом брзином - можда не извлачите максимум из Цлицкхоусе-а, али пишете најмање 100 мегабајта у секунди са једне машине преко обрнутог проксија - ово се шема мора скалирати и на велике и на мале количине, тако да не можемо чекати ни секунду за свако уметање, тако да мора бити асинхрона. И на исти начин, асинхроне потврде треба да дођу након што је уметање завршено. Знаћемо да ли је прошло или не.
Најважније је да у овој шеми сигурно знамо да ли се убацивање догодило или не. Замислите ову ситуацију: имате табелу бафера, уписали сте нешто у њу, а онда је, рецимо, табела прешла у режим само за читање и покушала да испразни бафер. Где ће подаци отићи? Они ће остати у тампону. Али не можемо бити сигурни у ово - шта ако постоји нека друга грешка, због које подаци неће остати у баферу... (Адресе Алексеј Миловидов, Иандек, ЦлицкХоусе програмер) Или ће остати? Увек? Алексеј нас убеђује да ће све бити у реду. Немамо разлога да му не верујемо. Али свеједно: ако не користимо табеле бафера, онда неће бити проблема са њима. Прављење дупло већег броја табела је такође незгодно, иако у принципу нема великих проблема. Ово је план.
Хајде да причамо о читању
Хајде сада да причамо о читању. Овде смо такође написали сопствени алат. Чинило би се, па, зашто овде писати свој инструмент?.. А ко је користио Табик? Некако је мало ко дигао руке... А ко је задовољан учинком Табикса? Па, нисмо задовољни тиме, а није баш згодно за преглед података. У реду је за аналитику, али само за гледање очигледно није оптимизовано. Тако да сам написао свој, сопствени интерфејс.
Веома је једноставно - може само да чита податке. Не уме да покаже графику, не зна ништа да уради. Али може да покаже шта нам је потребно: на пример, колико редова има у табели, колико простора заузима (без разлагања на колоне), то јест, веома основни интерфејс је оно што нам треба.
И изгледа веома слично Секуел Про-у, али направљено само на Твиттер-овом Боотстрапу и другој верзији. Питате: "Јури, зашто на другој верзији?" Које године? 2018? Генерално, урадио сам ово доста давно за „Мусцле“ (МиСКЛ) и само променио пар редова у упитима тамо, и почело је да ради за „Цлицкхоусе“, на чему посебно хвала! Зато што је парсер веома сличан оном „мишићном“, а упити су веома слични - веома згодно, посебно у почетку.
Па, може да филтрира табеле, може да прикаже структуру и садржај табеле, омогућава вам сортирање, филтрирање по колонама, приказује упит који је резултирао резултатом, захваћене редове (колико као резултат), тј. основне ствари за преглед података. Веома брзо.
Ту је и уредник. Искрено, покушао сам да украдем целог уредника од Табик-а, али нисам могао. Али некако функционише. У принципу, то је све.
"Кликхаус" је погодан за јазбине
Желим да вам кажем да је Цлицкхоусе, упркос свим описаним проблемима, веома погодан за трупце. Оно што је најважније, решава наш проблем - веома је брз и омогућава вам да филтрирате дневнике по колонама. У принципу, табеле бафера нису добро радиле, али обично нико не зна зашто... Можда сада боље знате где ћете имати проблема.
ТЦП? Генерално, у ВК-у је уобичајено користити УДП. А када сам користио ТЦП... Наравно, нико ми није рекао: „Јури, шта причаш! Не можете, потребан вам је УДП." Испоставило се да ТЦП није тако застрашујући. Једина ствар је, ако имате десетине хиљада активних једињења која напишете, морате да их припремите мало пажљивије; али то је могуће, и прилично лако.
Обећао сам да ћу објавити „Киттенхоусе“ и „Лигхтхоусе“ на ХигхЛоад Сибериа ако се сви претплате на наш јавни „ВК бацкенд“... И знате, нису се сви претплатили... Наравно, нећу захтевати да се претплатите на наш јавности. И даље вас је превише, можда ће се неко и увредити, али ипак, претплатите се (а овде морам да направим очи као мачке). То је . Много вам хвала! Гитхуб је наш . Уз Цлицкхоусе ваша коса ће бити мека и свиленкаста.
Леад: - Пријатељи, сада на питања. Одмах након што вам представимо захвалницу и ваш извештај на ВХС-у.
Јуриј Насретдинов (у даљем тексту ИН): – Како сте успели да снимите мој извештај на ВХС ако се управо завршио?
Леад: – Ни ви не можете у потпуности да одредите како ће „Кликхаус” функционисати или не! Пријатељи, 5 минута за питања!
pitanja
Питање из публике (у даљем тексту П): - Добар дан. Хвала вам пуно на извештају. Имам два питања. Почећу са нечим неозбиљним: да ли број слова т у називу "Китенхаус" на дијаграмима (3, 4, 7...) утиче на задовољство мачака?
ИН: - Количина чега?
З: – Писмо т. Има три т, негде око три т.
ИН: - Нисам ли то поправио? Па, наравно да јесте! То су различити производи - само сам вас обмањивао све ово време. Добро, шалим се – није важно. Ах, овде! Не, иста је ствар, погрешио сам.
З: - Хвала вам. Друго питање је озбиљно. Колико сам разумео, у Цлицкхоусе-у, табеле бафера живе искључиво у меморији, не баферују се на диск и, сходно томе, нису упорне.
ИН: - Да.
З: – И у исто време, ваш клијент се баферује на диск, што подразумева извесну гаранцију испоруке ових истих дневника. Али то никако није гарантовано у Цлицкхоусе-у. Објасните како се спроводи гаранција, због чега?.. Ево овог механизма детаљније
ИН: – Да, теоретски овде нема контрадикторности, јер када Кликхаус падне, то заправо можете открити на милион различитих начина. Ако се Цлицкхоусе сруши (ако се заврши погрешно), можете, грубо речено, мало премотати свој дневник који сте записали и почети од тренутка када је све било у реду. Рецимо да премотате минут уназад, односно сматра се да сте све испрали за минут.
З: – То јест, „Китенхаус” дуже држи прозор и у случају пада може да га препозна и премота?
ИН: – Али ово је у теорији. У пракси то не радимо, а поуздана испорука је од нула до бесконачно време. Али у просеку један. Задовољни смо да ако се Цлицкхоусе из неког разлога сруши или се сервери „рестартују“, онда губимо мало. У свим осталим случајевима ништа се неће догодити.
З: - Здраво. Од самог почетка ми се чинило да ћете заиста користити УДП од самог почетка извештаја. Имате хттп, све то... И већина проблема које сте описали, колико сам разумео, је изазвано овим конкретним решењем...
ИН: – Шта користимо ТЦП?
З: - У суштини да.
ИН: - Не.
З: – Са фастхттп-ом сте имали проблема, са везом сте имали проблема. Да сте управо користили УДП, уштедели бисте мало времена. Па, било би проблема са дугим порукама или нечим другим...
ИН: - Са чиме?
З: – Са дугим порукама, пошто се можда не уклапа у МТУ, нешто друго... Па, можда има и својих проблема. Питање је: зашто не УДП?
ИН: – Верујем да су аутори који су развили ТЦП/ИП много паметнији од мене и знају боље од мене како да серијализују пакете (тако да иду), у исто време подешавају прозор за слање, не преоптерећују мрежу, дају повратну информацију шта се не чита, не рачунајући на другу страну... Сви ови проблеми би, по мом мишљењу, постојали у УДП-у, само бих морао да напишем још више кода него што сам већ написао да бих сам имплементирао исту ствар и највероватније слабо. Не волим баш да пишем на Ц, а камоли тамо...
З: - Баш згодно! Послато у реду и не чекајте ништа - потпуно је асинхроно. Вратило се обавештење да је све у реду – значи да је стигло; Ако не дође, то значи да је лоше.
ИН: – Треба ми и једно и друго – морам да могу да пошаљем и са гаранцијом испоруке и без гаранције испоруке. Ово су два различита сценарија. Морам да не изгубим неке дневнике или да их не изгубим у разумном року.
З: – Нећу губити време. О томе треба више разговарати. Хвала вам.
Леад: – Ко има питања – руке до неба!
З: - Здраво, ја сам Саша. Негде у средини извештаја појавио се осећај да је, поред ТЦП-а, могуће користити и готово решење – неку врсту Кафке.
ИН: – Па... рекао сам ти да нећу да користим посредне сервере, јер... у Кафки се испоставило да имамо десет хиљада хостова; у ствари, имамо више – десетине хиљада домаћина. Такође може бити болно радити са Кафком без икаквих проксија. Поред тога, што је најважније, и даље даје „латентност“, даје додатне хостове које морате да имате. Али не желим да их имам - желим...
З: „Али на крају је ипак тако испало.”
ИН: – Не, нема домаћина! Све ово ради на Цлицкхоусе хостовима.
З: - Па, и "Китенхаус", што је обрнуто - где он живи?
ИН: – На Цлицкхоусе хосту не уписује ништа на диск.
З: - Хајде да претпоставимо.
Леад: - Да ли си задовољан? Можемо ли вам дати плату?
З: - Да можете. У ствари, има много штака да би се добила иста ствар, а сада - претходни одговор на тему ТЦП-а је у супротности, по мом мишљењу, са овом ситуацијом. Само се осећам као да је све могло да се уради на коленима за много краће време.
ИН: – И зашто нисам желео да користим Кафку, јер је било доста притужби у Цлицкхоусе Телеграм ћаскању да су, на пример, Кафкине поруке изгубљене. Не од самог Кафке, већ у интеграцији Кафке и Кликхауса; или се ту нешто није повезало. Грубо речено, тада би било потребно написати клијента за Кафку. Мислим да не може постојати једноставније или поузданије решење.
З: – Реци ми, зашто ниси покушао са редовима или неким заједничким аутобусом? Пошто кажете да бисте помоћу асинхроније могли да шаљете саме евиденције кроз ред и добијате одговор асинхроно кроз ред?
ИН: – Молимо предложите који редови би се могли користити?
З: – Било које, чак и без гаранције да су у реду. Нека врста Редис-а, РМК...
ИН: – Имам осећај да Редис највероватније неће моћи да извуче толики обим уметања чак ни на једном хосту (у смислу неколико сервера) који извлачи Цлицкхоусе. Не могу ово да поткријепим никаквим доказима (нисам га бенчмаркирао), али чини ми се да Редис овдје није најбоље рјешење. У принципу, овај систем се може сматрати импровизованим редом порука, али који је прилагођен само за „Цлицкхоусе“
Леад: – Јури, хвала ти пуно. Предлажем да овде завршимо питања и одговоре и кажемо коме ћемо од оних који су поставили питање дати књигу.
ИН: – Желео бих да поклоним књигу првој особи која је поставила питање.
Леад: - Предивна! Велики! Сјајно! Хвала пуно!
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом