HighLoad++ Москва 2018, Конгресна зала. 9 ноември, 15:00 часа
Резюмета и презентация:
Юрий Насретдинов (ВКонтакте): докладът ще говори за опита от внедряването на ClickHouse в нашата компания - защо имаме нужда от него, колко данни съхраняваме, как ги пишем и т.н.
Допълнителни материали:
Юрий Насретдинов: - Здравейте всички! Казвам се Юрий Насретдинов, както вече ме представиха. Работя във ВКонтакте. Ще говоря за това как вмъкваме данни в ClickHouse от нашия сървърен парк (десетки хиляди).
Какво представляват трупите и защо да ги събираме?
Какво ще ви кажем: какво направихме, защо имахме нужда от „ClickHouse“, съответно, защо го избрахме, каква производителност можете приблизително да получите, без да конфигурирате нищо специално. Ще ви разкажа допълнително за буферните таблици, за проблемите, които имахме с тях и за нашите решения, които разработихме от отворен код - KittenHouse и Lighthouse.
Защо изобщо трябваше да правим нещо (във VKontakte всичко винаги е наред, нали?). Искахме да събираме регистрационни файлове за отстраняване на грешки (и там имаше стотици терабайти данни), може би по някакъв начин щеше да е по-удобно да изчисляваме статистика; и имаме флот от десетки хиляди сървъри, от които трябва да се направи всичко това.
Защо решихме? Вероятно сме имали решения за съхраняване на регистрационни файлове. Ето – има такъв публичен „Backend VK“. Силно препоръчвам да се абонирате за него.
Какво представляват трупите? Това е двигател, който връща празни масиви. Двигателите във VK са това, което другите наричат микроуслуги. И ето един усмихнат стикер (доста харесвания). Как така? Е, слушайте по-нататък!
Какво може да се използва за съхраняване на регистрационни файлове? Невъзможно е да не споменем Hadup. След това, например, Rsyslog (съхраняване на тези регистрационни файлове във файлове). ЛСД. Кой знае какво е LSD? Не, не този LSD. Съхранявайте файлове, съответно, също. Е, ClickHouse е странна опция.
Clickhouse и конкуренти: изисквания и възможности
какво искаме Искаме да гарантираме, че не се налага да се тревожим твърде много за операцията, така че да работи извън кутията, за предпочитане с минимална конфигурация. Искаме да пишем много и да пишем бързо. И ние искаме да го запазим за всякакви месеци, години, тоест за дълго време. Може да искаме да разберем някакъв проблем, с който те дойдоха при нас и казаха: „Тук нещо не работи“ и това беше преди 3 месеца), и искаме да можем да видим какво се е случило преди 3 месеца " Компресиране на данни – ясно е защо би било плюс – защото намалява количеството пространство, което заема.
И имаме такова интересно изискване: понякога записваме изхода на някои команди (например регистрационни файлове), той може да бъде повече от 4 килобайта доста лесно. И ако това нещо работи през UDP, тогава няма нужда да харчи... няма да има никакви "режийни" за връзката, а за голям брой сървъри това ще е плюс.
Да видим какво ни предлага отвореният код. Първо, имаме Logs Engine - това е нашият двигател; По принцип може всичко, дори може да пише дълги редове. Е, той не компресира прозрачно данни - можем сами да компресираме големи колони, ако искаме... ние, разбира се, не искаме (ако е възможно). Единственият проблем е, че той знае как да даде само това, което се побира в паметта му; За да прочетете останалото, трябва да получите binlog на този двигател и съответно отнема доста време.
Какви други опции има? Например "Hadup". Лесна работа... Кой си мисли, че Hadup е лесен за настройка? Разбира се, няма проблеми със записа. При четене понякога възникват въпроси. По принцип бих казал, че вероятно не, особено за трупи. Дългосрочно съхранение - разбира се, да, компресиране на данни - да, дълги низове - ясно е, че можете да записвате. Но записването от голям брой сървъри... Все пак трябва да направите нещо сами!
Rsyslog. Всъщност го използвахме като резервна опция, за да можем да го четем, без да изхвърляме binlog, но той не може да пише дълги редове, по принцип не може да пише повече от 4 килобайта. Вие сами трябва да направите компресиране на данни по същия начин. Четенето ще идва от файлове.
След това има "бадушка" развитие на LSD. По същество същото като „Rsyslog“: поддържа дълги низове, но не може да работи чрез UDP и всъщност поради това, за съжаление, доста неща трябва да бъдат пренаписани там. LSD трябва да бъде преработен, за да може да записва от десетки хиляди сървъри.
И тук! Забавна опция е ElasticSearch. Как да кажа? С четенето се справя добре, тоест чете бързо, но не много добре с писането. Първо, ако компресира данни, това е много слабо. Най-вероятно пълното търсене изисква по-големи структури от данни от оригиналния обем. Трудно се работи и често възникват проблеми с него. И отново, запис в Elastic - трябва да направим всичко сами.
Тук ClickHouse е идеален вариант, разбира се. Единственото нещо е, че записването от десетки хиляди сървъри е проблем. Но поне има един проблем, можем да се опитаме да го разрешим по някакъв начин. И останалата част от доклада е за този проблем. Какво представяне можете да очаквате от ClickHouse?
Как ще го вкараме? MergeTree
Кой от вас не е чувал или знае за “ClickHouse”? Трябва да ти кажа, нали? Много бързо. Вмъкването там - 1-2 гигабита в секунда, изблици до 10 гигабита в секунда наистина издържат на тази конфигурация - има два 6-ядрени Xeon-а (тоест дори не е най-мощният), 256 гигабайта RAM, 20 терабайта в RAID (никой не е конфигурирал, настройки по подразбиране). Алексей Миловидов, разработчик на ClickHouse, вероятно седи и плаче, защото не сме конфигурирали нищо (при нас всичко работи така). Съответно може да се получи скорост на сканиране от да кажем около 6 милиарда реда в секунда, ако данните са добре компресирани. Ако харесвате % върху текстов низ - 100 милиона реда в секунда, тоест изглежда доста бързо.
Как ще го вкараме? Е, знаете, че VK използва PHP. Ще вмъкнем от всеки PHP работник чрез HTTP в „ClickHouse“, в таблицата MergeTree за всеки запис. Кой вижда проблем в тази схема? По някаква причина не всички вдигнаха ръце. Нека ви кажа.
Първо, има много сървъри - съответно ще има много връзки (лоши). Тогава е по-добре да вмъквате данни в MergeTree не по-често от веднъж в секунда. И кой знае защо? Добре добре. Ще ви разкажа малко повече за това. Друг интересен въпрос е, че не правим анализи, не е необходимо да обогатяваме данните, не се нуждаем от междинни сървъри, искаме да вмъкнем директно в „ClickHouse“ (за предпочитане - колкото по-директно, толкова по-добре).
Съответно, как се извършва вмъкването в MergeTree? Защо е по-добре да вмъквате в него не по-често от веднъж в секунда или по-рядко? Факт е, че “ClickHouse” е колонна база данни и сортира данните във възходящ ред на първичния ключ, а когато правите вмъкване, се създават брой файлове, поне равен на броя на колоните, в които са сортирани данните във възходящ ред на първичния ключ (създава се отделна директория, набор от файлове на диска за всяко вмъкване). След това идва следващото вмъкване и на заден план те се комбинират в по-големи „дялове“. Тъй като данните са сортирани, е възможно да се „слеят“ два сортирани файла, без да се изразходва много памет.
Но, както може би се досещате, ако пишете 10 файла за всяко вмъкване, тогава ClickHouse (или вашият сървър) бързо ще приключи, така че се препоръчва да вмъквате в големи партиди. Съответно, ние така и не пуснахме първата схема в производство. Веднага пуснахме един, който тук номер 2 има:
Тук си представете, че има около хиляда сървъра, на които сме стартирали, има само PHP. И на всеки сървър има наш локален агент, който нарекохме „Kittenhouse“, който поддържа една връзка с „ClickHouse“ и вмъква данни на всеки няколко секунди. Вмъква данни не в MergeTree, а в буферна таблица, която служи именно за избягване на директно вмъкване в MergeTree веднага.
Работа с буферни таблици
Какво е? Буферните таблици са част от паметта, която е шардинг (т.е. може да се вмъква често в нея). Те се състоят от няколко парчета и всяко от парчетата работи като независим буфер и се промиват независимо (ако имате много парчета в буфера, тогава ще има много вмъквания в секунда). Възможно е четене от тези таблици - тогава четете обединението на съдържанието на буфера и родителската таблица, но в този момент записът е блокиран, така че е по-добре да не четете от там. И буферните таблици показват много добри QPS, тоест до 3 хиляди QPS няма да имате никакви проблеми при поставяне. Ясно е, че ако сървърът загуби захранване, тогава данните могат да бъдат загубени, тъй като са били съхранявани само в паметта.
В същото време схемата с буфер усложнява ALTER, защото първо трябва да премахнете старата буферна таблица със старата схема (данните няма да изчезнат никъде, защото ще бъдат изчистени преди таблицата да бъде изтрита). След това „променяте“ таблицата, от която се нуждаете, и създавате отново буферната таблица. Съответно, докато няма буферна таблица, вашите данни няма да текат никъде, но можете да ги имате на диск поне локално.
Какво е Kittenhouse и как работи?
Какво е KittenHouse? Това е прокси. Познайте на какъв език? Събрах най-много теми за реклама в моя доклад - „Clickhouse“, Go, може би ще си спомня нещо друго. Да, това е написано на Go, защото всъщност не знам как да пиша на C, не искам.
Съответно поддържа връзка с всеки сървър и може да пише в паметта. Например, ако пишем регистрационни файлове за грешки в Clickhouse, тогава ако Clickhouse няма време да вмъкне данни (в края на краищата, ако е написано твърде много), тогава не набъбваме паметта - просто изхвърляме останалото. Защото, ако записваме няколко гигабита в секунда грешки, тогава вероятно можем да изхвърлим някои. Kittenhouse може да направи това. Плюс това, той може да извършва надеждна доставка, тоест запис на диск на локалната машина и веднъж всеки път (там, веднъж на няколко секунди) се опитва да достави данни от този файл. И в началото използвахме обикновения формат на стойностите - не някакъв двоичен формат, текстов формат (както в обикновения SQL).
Но тогава се случи това. Използвахме надеждна доставка, написахме регистрационни файлове, след което решихме (това беше условен тестов клъстер)... Беше пуснат за няколко часа и възстановен и започна вмъкване от хиляда сървъра - оказа се, че Clickhouse все още има „Нишка при връзка“ - съответно при хиляда връзки активното вмъкване води до средно натоварване на сървъра от около хиляда и половина. Изненадващо, сървърът прие заявки, но данните все още бяха вмъкнати след известно време; но беше много трудно за сървъра да го обслужва...
Добавете nginx
Такова решение за модела Thread per connection е nginx. Инсталирахме nginx пред Clickhouse, в същото време настроихме балансиране за две реплики (скоростта на вмъкване се увеличи 2 пъти, въпреки че не е факт, че трябва да е така) и ограничихме броя на връзките към Clickhouse, до upstream и съответно повече , отколкото в 50 връзки, изглежда няма смисъл да се вмъква.
Тогава разбрахме, че тази схема като цяло има недостатъци, защото тук имаме само един nginx. Съответно, ако този nginx се срине, въпреки наличието на реплики, ние губим данни или поне не пишем никъде. Ето защо направихме собствено балансиране на натоварването. Разбрахме също, че „Clickhouse“ все още е подходящ за трупи и „демонът“ също започна да пише своите журнали в „Clickhouse“ - много удобно, честно казано. Все още го използваме за други „демони“.
След това открихме този интересен проблем: ако използвате нестандартен метод за вмъкване в SQL режим, той принуждава пълноценен базиран на AST анализатор на SQL, който е доста бавен. Съответно сме добавили настройки, за да гарантираме, че това никога не се случва. Направихме балансиране на натоварването, проверки на здравето, така че ако някой умре, пак да оставим данните. Сега имаме доста маси, от които се нуждаем, за да имаме различни клъстери на Clickhouse. И също така започнахме да мислим за други употреби - например искахме да пишем регистрационни файлове от модули на nginx, но те не знаят как да комуникират с помощта на нашия RPC. Е, бих искал да ги науча как да изпращат поне по някакъв начин - например да получават събития на localhost чрез UDP и след това да ги препращат към Clickhouse.
На крачка от решението
Окончателната схема започна да изглежда така (четвъртата версия на тази схема): на всеки сървър пред Clickhouse има nginx (на същия сървър) и той просто проксира заявки към localhost с ограничение на броя на връзките от 50 парчета. И тази схема вече беше доста работеща, всичко беше доста добре с нея.
Живяхме така около месец. Всички бяха доволни, добавяха таблици, добавяха, добавяха... Като цяло се оказа, че начинът, по който добавихме буферни таблици, не е много оптимален (да го кажем така). Направихме 16 парчета във всяка маса и флаш интервал от няколко секунди; имахме 20 маси и всяка маса получи 8 вмъквания в секунда - и в този момент започна "Clickhouse"... записите започнаха да се забавят. Те дори не преминаха... Nginx по подразбиране имаше толкова интересно нещо, че ако връзките завършваха нагоре, тогава просто връщаше „502“ на всички нови заявки.
И тук имаме (току-що погледнах регистрационните файлове в самия Clickhouse) около половин процент от заявките са неуспешни. Съответно, използването на диска беше високо, имаше много сливания. Е, какво направих? Естествено, не си направих труда да разбера защо точно връзката и upstream приключиха.
Замяна на nginx с обратен прокси
Реших, че трябва да управляваме това сами, не е нужно да го оставяме на nginx - nginx не знае какви таблици има в Clickhouse и замених nginx с обратен прокси, който също написах сам.
Какво прави той? Работи въз основа на библиотеката fasthttp „goshnoy“, тоест бързо, почти толкова бързо, колкото nginx. Съжалявам, Игор, ако присъствате тук (забележка: Игор Сисоев е руски програмист, създал уеб сървъра nginx). Той може да разбере какъв вид заявки са това – INSERT или SELECT – съответно, той съдържа различни пулове за връзки за различни типове заявки.
Съответно, дори ако нямаме време да изпълним заявките за вмъкване, „селектите“ ще преминат и обратно. И групира данните в буферни таблици - с малък буфер: ако има някакви грешки, синтактични грешки и така нататък - така че те да не повлияят значително на останалите данни, защото когато просто вмъкнем в буферни таблици, ние имаше малък "bachi" и всички синтактични грешки засягаха само това малко парче; и тук вече ще засегнат голям буфер. Малък е 1 мегабайт, тоест не е толкова малък.
Вмъкването на синхронизация и по същество замяната на nginx прави по същество същото нещо, което nginx правеше преди - не е необходимо да променяте локалната „Kittenhouse“ за това. И тъй като използва fasthttp, той е много бърз - можете да направите повече от 100 хиляди заявки в секунда за единични вмъквания през обратен прокси. Теоретично можете да вмъквате ред по ред в обратния прокси сървър на котешка къща, но ние, разбира се, не го правим.
Схемата започна да изглежда така: „Kittenhouse“, обратният прокси групира много заявки в таблици и от своя страна буферните таблици ги вмъкват в основните.
Killer е временно решение, Kitten е постоянно
Това е интересен проблем... Някой от вас използвал ли е fasthttp? Кой използва fasthttp с POST заявки? Вероятно това наистина не трябваше да се прави, защото буферира тялото на заявката по подразбиране и нашият размер на буфера беше зададен на 16 мегабайта. Вмъкването спря да се поддържа в някакъв момент и 16-мегабайтови парчета започнаха да пристигат от всички десетки хиляди сървъри и всички те бяха буферирани в паметта, преди да бъдат изпратени до Clickhouse. Съответно паметта свърши, убиецът на липса на памет дойде и уби обратното прокси (или „Clickhouse“, което теоретично можеше да „изяде“ повече от обратното прокси). Цикълът се повтори. Не много приятен проблем. Въпреки че се натъкнахме на това едва след няколко месеца работа.
Какво съм направил? Отново не ми харесва да разбирам какво точно се е случило. Мисля, че е доста очевидно, че не трябва да буферирате в паметта. Не можах да закърпя fasthttp, въпреки че опитах. Но намерих начин да го направя така, че да няма нужда да пачвам нищо, и измислих свой собствен метод в HTTP - нарекох го KITTEN. Е, логично е - "ВК", "Коте"... Какво още?..
Ако заявка дойде до сървъра с метода Kitten, тогава сървърът трябва да отговори „мяу“ - логично. Ако той отговори на това, тогава се счита, че той разбира този протокол и тогава аз прихващам връзката (fasthttp има такъв метод) и връзката преминава в „суров“ режим. Защо ми трябва? Искам да контролирам как се извършва четенето от TCP връзки. TCP има прекрасно свойство: ако никой не чете от другата страна, тогава записът започва да чака и паметта не се изразходва особено за това.
И така чета от около 50 клиента наведнъж (от петдесет, защото петдесет определено трябва да са достатъчни, дори ако тарифата идва от друг DC)... Потреблението е намаляло с този подход поне 20 пъти, но аз, за да бъда честен , не можах да измеря точно колко часа, защото вече е безсмислено (вече е достигнало нивото на грешка). Протоколът е двоичен, т.е. съдържа името на таблицата и данните; няма http заглавки, така че не използвах уеб сокет (не е необходимо да комуникирам с браузъри - направих протокол, който отговаря на нашите нужди). И всичко с него се оправи.
Буферната маса е тъжна
Наскоро се натъкнахме на друга интересна функция на буферните таблици. И този проблем вече е много по-болезнен от останалите. Нека си представим тази ситуация: вие вече активно използвате Clickhouse, имате десетки сървъри на Clickhouse и имате някои заявки, които отнемат много време за четене (да кажем, повече от 60 секунди); и вие идвате и правите Alter в този момент... Междувременно „селекти“, които са започнали преди „Alter“, няма да бъдат включени в тази таблица, „Alter“ няма да започне - вероятно някои характеристики на това как работи „Clickhouse“ в това място. Може би това може да се поправи? Или е невъзможно?
Като цяло е ясно, че реално това не е толкова голям проблем, но с буферните таблици става по-болезнено. Защото, ако, да кажем, времето за изчакване на “Alter” изтече (и то може да изтече на друг хост - не на вашия, а на реплика, например), тогава... Вие изтрихте буферната таблица, вашият “Alter” ( или някой друг хост) изтече времето за изчакване. след това е възникнала грешка „Промяна“) - все пак трябва да се уверите, че данните продължават да се записват: създавате обратно буферните таблици (съгласно същата схема като родителската таблица), след това „Промяна“ минава, приключва в крайна сметка и буферът на таблицата започва да се различава по схема от родителя. В зависимост от това какво беше „Промяната“, вмъкването може вече да не отива в тази буферна таблица - това е много тъжно.
Има и такъв знак (може би някой го е забелязал) - в новите версии на Clickhouse се нарича query_thread_log. По подразбиране в някои версии имаше такъв. Тук сме натрупали 840 милиона записа за няколко месеца (100 гигабайта). Това се дължи на факта, че там са написани „вложки“ (може би сега, между другото, те не са написани). Както ви казах, нашите „вмъквания“ са малки – имахме много „вмъквания“ в буферни таблици. Ясно е, че това е деактивирано - просто ви казвам какво видях на нашия сървър. Защо? Това е още един аргумент срещу използването на буферни таблици! Споти е много тъжен.
Кой знаеше, че името на този човек е Споти? Служителите на VK вдигнаха ръце. ДОБРЕ.
За плановете за “KitttenHouse”
Плановете обикновено не се споделят, нали? Изведнъж няма да ги изпълните и няма да изглеждате много добре в очите на другите. Но ще поема риска! Искаме да направим следното: буферните таблици, струва ми се, все още са патерица и трябва сами да буферираме вмъкването. Но ние все още не искаме да го буферираме на диска, така че ще буферираме вмъкването в паметта.
Съответно, когато се направи „вмъкване“, то вече няма да е синхронно - вече ще работи като буферна таблица, ще вмъкне в родителската таблица (е, някой ден по-късно) и ще докладва по отделен канал кои вмъквания са преминали и кои нямам.
Защо не мога да напусна синхронната вложка? Много по-удобно е. Факт е, че ако вмъкнете от 10 хиляди хоста, тогава всичко е наред - ще получите малко от всеки хост, вмъквате там веднъж на секунда, всичко е наред. Но бих искал тази схема да работи например от две машини, така че да можете да изтегляте с висока скорост - може би да не извлечете максимума от Clickhouse, но да пишете поне 100 мегабайта в секунда от една машина през обратен прокси - това схемата трябва да се мащабира както за големи, така и за малки количества, така че не можем да чакаме секунда за всяко вмъкване, така че трябва да е асинхронно. И по същия начин асинхронните потвърждения трябва да идват след завършване на вмъкването. Ще разберем дали е минало или не.
Най-важното е, че в тази схема знаем със сигурност дали вмъкването е станало или не. Представете си тази ситуация: имате буферна таблица, записахте нещо в нея и след това, да речем, таблицата премина в режим само за четене и се опита да изчисти буфера. Къде ще отидат данните? Те ще останат в буфера. Но не можем да сме сигурни в това - ами ако има някаква друга грешка, поради която данните няма да останат в буфера... (Адреси Alexey Milovidov, Yandex, ClickHouse developer) Или ще останат? Винаги? Алексей ни убеждава, че всичко ще бъде наред. Нямаме причина да не му вярваме. Но все пак: ако не използваме буферни таблици, тогава няма да има проблеми с тях. Създаването на два пъти повече таблици също е неудобно, въпреки че по принцип няма големи проблеми. Това е планът.
Да поговорим за четенето
Сега да поговорим за четенето. Тук също написахме наш собствен инструмент. Изглежда, добре, защо да пишете свой собствен инструмент тук?.. И кой използва Tabix? Някак малко хора вдигнаха ръце... А кой е доволен от представянето на Tabix? Е, не сме доволни от него и не е много удобно за преглед на данни. Добре е за анализ, но само за гледане явно не е оптимизиран. Така че написах свой собствен, мой собствен интерфейс.
Много е просто - може само да чете данни. Той не знае как да показва графики, той не знае как да прави нищо. Но може да покаже от какво се нуждаем: например колко реда има в таблицата, колко място заема (без да я разбиваме на колони), тоест много елементарен интерфейс е това, от което се нуждаем.
И изглежда много подобно на Sequel Pro, но направено само в Bootstrap на Twitter и втората версия. Питате: „Юри, защо във втората версия?“ Коя година? 2018? Като цяло, направих това преди доста време за “Muscle” (MySQL) и просто промених няколко реда в заявките там и започна да работи за “Clickhouse”, за което специални благодарности! Тъй като анализаторът е много подобен на „мускулния“ и заявките са много сходни - много удобно, особено в началото.
Е, може да филтрира таблици, може да показва структурата и съдържанието на таблицата, позволява ви да сортирате, филтрирате по колони, показва заявката, която е довела до резултата, засегнатите редове (колко в резултат), т.е. основни неща за преглед на данни. Доста бързо.
Има и редактор. Честно се опитах да открадна целия редактор от Tabix, но не успях. Но някак си работи. По принцип това е всичко.
"Clickhouse" е подходящ за леговища
Искам да ви кажа, че Clickhouse, въпреки всички описани проблеми, е много подходящ за трупи. Най-важното е, че решава нашия проблем - той е много бърз и ви позволява да филтрирате регистрационни файлове по колони. По принцип буферните таблици не се представят добре, но обикновено никой не знае защо... Може би сега вече знаете по-добре къде ще имате проблеми.
TCP? По принцип във VK е обичайно да се използва UDP. И когато използвах TCP... Разбира се, никой не ми каза: „Юри, какво говориш! Не можете, имате нужда от UDP.“ Оказа се, че TCP не е толкова страшен. Единственото нещо е, че ако имате десетки хиляди активни съединения, които пишете, трябва да ги подготвите малко по-внимателно; но е възможно и то доста лесно.
Обещах да публикувам „Kittenhouse“ и „Lighthouse“ в HighLoad Siberia, ако всички се абонират за нашия публичен „VK бекенд“... И знаете ли, не всички се абонираха... Разбира се, няма да изисквам да се абонирате за нашия публичен. Все още сте твърде много, може някой дори да се обиди, но все пак, моля, абонирайте се (и тук трябва да направя очи като на котка). Това е . Благодаря ти много! Github е наш . С Clickhouse косата ви ще бъде мека и копринена.
Модератор: - Приятели, сега за въпроси. Веднага след като представим сертификата за благодарност и вашия доклад на VHS.
Юрий Насретдинов (наричан по-долу YN): – Как успяхте да запишете доклада ми на VHS, ако току-що приключи?
Модератор: – Вие също не можете напълно да определите как „Clickhouse“ ще работи или не! Приятели, 5 минути за въпроси!
Въпроси
Въпрос от публиката (наричан по-долу Q): - Добър ден. Благодаря ви много за доклада. Имам два въпроса. Ще започна с нещо несериозно: броят на буквите t в името "Kittenhouse" в диаграмите (3, 4, 7...) влияе ли на удовлетвореността на котките?
YN: - Количество на какво?
Я: – Буква т. Има три т-та, някъде около три т-та.
YN: - Не го ли оправих? Е, разбира се! Това са различни продукти - просто ви заблуждавах през цялото това време. Добре, шегувам се - няма значение. А, точно тук! Не, същото е, направих печатна грешка.
Я: - Благодаря ти. Вторият въпрос е сериозен. Доколкото разбирам, в Clickhouse буферните таблици живеят изключително в паметта, не се буферират на диск и съответно не са постоянни.
YN: - Да.
Я: – И в същото време вашият клиент буферира на диск, което предполага известна гаранция за доставка на същите тези регистрационни файлове. Но това в никакъв случай не е гарантирано от Clickhouse. Обяснете как се осъществява гаранцията, поради какво?.. Ето този механизъм по-подробно
YN: – Да, теоретично тук няма противоречия, защото когато Clickhouse падне, всъщност можете да го откриете по милиони различни начини. Ако Clickhouse се срине (ако завърши неправилно), можете, грубо казано, да превъртите малко назад от вашия дневник, който сте записали, и да започнете от момента, в който всичко беше точно наред. Да кажем, че превъртате минута назад, тоест се счита, че сте изчистили всичко за минута.
Я: – Тоест “Kittenhouse” държи прозореца по-дълго и при падане може да го разпознае и пренавие?
YN: – Но това е на теория. На практика ние не правим това и надеждната доставка е от нула до безкрайност пъти. Но средно един. Доволни сме, че ако Clickhouse се срине по някаква причина или сървърите се „рестартират“, тогава губим малко. Във всички останали случаи нищо няма да се случи.
Я: - Здравейте. От самото начало ми се струваше, че наистина ще използвате UDP от самото начало на доклада. Имате http, всичко това... И повечето от проблемите, които описахте, както разбирам, са причинени от това конкретно решение...
YN: – Какво използваме TCP?
Я: - По същество да.
YN: - Не.
Я: – С fasthttp имаше проблеми, с връзката имаше проблеми. Ако току-що бяхте използвали UDP, щяхте да си спестите време. Е, ще има проблеми с дълги съобщения или нещо друго...
YN: - С какво?
Я: – С дълги съобщения, тъй като може да не се побира в MTU, нещо друго... Е, може да има собствени проблеми. Въпросът е: защо не UDP?
YN: – Вярвам, че авторите, разработили TCP/IP, са много по-умни от мен и знаят по-добре от мен как да сериализират пакети (така че да отидат), в същото време да коригират прозореца за изпращане, да не претоварват мрежата, да дават обратна връзка за това, което не се чете, без да се брои от другата страна... Всички тези проблеми според мен биха съществували в UDP, само че ще трябва да напиша още повече код, отколкото вече съм написал, за да внедря същото нещо сам и най-вероятно лошо. Дори не обичам да пиша на C, камо ли там...
Я: - Просто удобно! Изпратено е добре и не чакайте нищо - това е напълно асинхронно. Върна се известие, че всичко е наред - това означава, че е пристигнало; Ако не дойде, това означава, че е лошо.
YN: – Трябват ми и двете – трябва да мога да изпратя и двете с гаранция за доставка и без гаранция за доставка. Това са два различни сценария. Трябва да не загубя някои регистрационни файлове или да не ги загубя в рамките на разумното.
Я: – Няма да губя време. Това трябва да се обсъди повече. Благодаря ти.
Модератор: – Който има въпроси – ръцете до небето!
Я: - Здравейте, аз съм Саша. Някъде по средата на доклада се появи усещането, че в допълнение към TCP е възможно да се използва готово решение - някакъв вид Kafka.
YN: – Добре... казах ви, че не искам да използвам междинни сървъри, защото... в Kafka се оказва, че имаме десет хиляди хоста; всъщност имаме повече - десетки хиляди хостове. Също така може да бъде болезнено да се прави с Кафка без пълномощници. Освен това, най-важното, той все още дава „латентност“, дава допълнителни хостове, които трябва да имате. Но не искам да ги имам - искам...
Я: — Но в крайна сметка все пак се оказа така.
YN: – Не, няма домакини! Всичко това работи на хостове Clickhouse.
Я: - Е, и "Kittenhouse", което е обратното - къде живее?
YN: – На хоста Clickhouse не записва нищо на диска.
Я: - Да предположим.
Модератор: - Доволни ли сте? Може ли да ви дадем заплата?
Я: - Да, можеш. Всъщност има много патерици, за да се получи същото, а сега - предишният отговор по темата за TCP противоречи, според мен, на тази ситуация. Просто имам чувството, че всичко можеше да бъде направено на колене за много по-малко време.
YN: – И също защо не исках да използвам Kafka, защото имаше доста оплаквания в чата на Clickhouse Telegram, че например съобщенията от Kafka са били изгубени. Не от самия Кафка, а в интеграцията на Кафка и Кликхаус; или нещо не се връзва там. Грубо казано, тогава ще трябва да напишем клиент за Кафка. Не мисля, че може да има по-просто или по-надеждно решение.
Я: – Кажете ми, защо не опитахте някакви опашки или някакъв общ автобус? Тъй като казвате, че с асинхронност бихте могли да изпратите самите регистрационни файлове през опашката и да получите отговора асинхронно през опашката?
YN: – Моля, предложете какви опашки могат да се използват?
Я: – Всякакви, дори без гаранция, че са изрядни. Някакъв вид Redis, RMQ...
YN: – Имам чувството, че Redis най-вероятно няма да може да изтегли такъв обем вмъкване дори на един хост (в смисъл на няколко сървъра), който изтегля Clickhouse. Не мога да подкрепя това с никакви доказателства (не съм го сравнил), но ми се струва, че Redis не е най-доброто решение тук. По принцип тази система може да се разглежда като импровизирана опашка от съобщения, но която е пригодена само за „Clickhouse“
Модератор: – Юрий, благодаря ти много. Предлагам тук да приключим с въпросите и отговорите и да кажем на кого от задалите въпроса ще подарим книгата.
YN: – Бих искал да подаря книга на първия, който зададе въпрос.
Модератор: - Чудесен! Страхотен! Страхотно! Благодаря много!
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com