HighLoad++ Москва 2018 година, Конгресна сала. 9 ноември, 15:00 часот
Апстракти и презентација:
Јуриј Насретдинов (ВКонтакте): извештајот ќе зборува за искуството од спроведувањето на ClickHouse во нашата компанија - зошто ни треба, колку податоци складираме, како ги пишуваме итн.
Дополнителни материјали:
Јуриј Насретдинов: - Здраво на сите! Јас се викам Јуриј Насретдинов, како што веќе ми го претставија. Работам во VKontakte. Ќе зборувам за тоа како вметнуваме податоци во ClickHouse од нашата флота на сервери (десетици илјади).
Што се трупци и зошто се собираат?
Што ќе ви кажеме: што направивме, зошто ни требаше „ClickHouse“, соодветно, зошто го избравме, какви перформанси приближно можете да добиете без да конфигурирате ништо посебно. Ќе ви кажам дополнително за табелите за тампон, за проблемите што ги имавме со нив и за нашите решенија што ги развивме од отворен код - KittenHouse и Lighthouse.
Зошто воопшто требаше да направиме нешто (сè е секогаш добро на VKontakte, нели?). Сакавме да собереме дневници за отстранување грешки (и таму имаше стотици терабајти податоци), можеби некако би било попогодно да се пресметаат статистиката; и имаме флота од десетици илјади сервери од кои сето тоа треба да се направи.
Зошто решивме? Веројатно имавме решенија за складирање на трупци. Овде - постои таков јавен „Позадински VK“. Силно препорачувам да се претплатите на него.
Што се логови? Ова е мотор кој враќа празни низи. Моторите во VK се она што другите го нарекуваат микросервис. И еве една насмеана налепница (прилично многу лајкови). Како тоа? Па, слушајте понатаму!
Што може да се користи за складирање на трупци? Невозможно е да не се спомене Хадуп. Потоа, на пример, Rsyslog (зачувување на овие дневници во датотеки). ЛСД. Кој знае што е ЛСД? Не, не овој ЛСД. Чувајте ги датотеките, соодветно, исто така. Па, ClickHouse е чудна опција.
Clickhouse и конкуренти: барања и можности
Што сакаме? Сакаме да се погрижиме да не се грижиме премногу за операцијата, за да работи надвор од кутијата, по можност со минимална конфигурација. Сакаме да пишуваме многу, и брзо да пишуваме. И сакаме да го чуваме секакви месеци, години, односно долго време. Можеби сакаме да разбереме некој проблем со кој дојдоа кај нас и рекоа: „Нешто не функционира овде“, а тоа беше пред 3 месеци), и сакаме да можеме да видиме што се случило пред 3 месеци. Компресија на податоци - јасно е зошто тоа би било плус - затоа што го намалува просторот што го зафаќа.
И имаме толку интересно барање: понекогаш го пишуваме излезот од некои команди (на пример, дневници), може да биде многу лесно повеќе од 4 килобајти. И ако оваа работа работи преку UDP, тогаш не треба да троши... нема да има никакви „горни трошоци“ за врската, а за голем број сервери ова ќе биде плус.
Ајде да видиме што ни нуди отворен код. Прво, го имаме Logs Engine - ова е нашиот мотор; Во принцип, тој може да направи сè, може дури и да пишува долги редови. Па, не ги компресира транспарентно податоците - можеме сами да компресираме големи колони ако сакаме... ние, се разбира, не сакаме (ако е можно). Единствениот проблем е што тој може да подарува само она што му се вклопува во сеќавањето; За да го прочитате остатокот, треба да го добиете бинлогот на овој мотор и, соодветно, потребно е доста долго време.
Кои други опции постојат? На пример, „Хадуп“. Леснотија на работа... Кој мисли дека Хадуп лесно се поставува? Секако, нема проблеми со снимањето. Кога читате, понекогаш се појавуваат прашања. Во принцип, би рекол веројатно не, особено за трупци. Долгорочно складирање - се разбира, да, компресија на податоци - да, долги низи - јасно е дека можете да снимате. Но, снимање од голем број на сервери... Уште нешто треба да направите сами!
Rsyslog. Всушност, ја користевме како резервна опција за да можеме да ја читаме без да го фрламе бинлогот, но не може да пишува долги редови, во принцип, не може да напише повеќе од 4 килобајти. Треба да направите компресија на податоци на ист начин сами. Читањето ќе дојде од датотеки.
Потоа, тука е развојот на „бадушка“ на ЛСД. Во суштина исто како „Rsyslog“: поддржува долги низи, но не може да работи преку UDP и, всушност, поради тоа, за жал, многу работи треба да се препишат таму. LSD треба да се редизајнира за да може да снима од десетици илјади сервери.
И тука! Смешна опција е ElasticSearch. Како да се каже? Добро му оди со читање, односно брзо чита, но не многу добро со пишување. Прво, ако ги компресира податоците, тоа е многу слабо. Најверојатно, целосното пребарување бара поголеми структури на податоци од оригиналниот волумен. Тешко е да се работи и често се појавуваат проблеми со него. И, повторно, снимање во Еластик - сè треба да направиме сами.
Тука ClickHouse е идеална опција, се разбира. Единственото нешто е што е проблем снимањето од десетици илјади сервери. Но, барем има еден проблем, можеме да се обидеме некако да го решиме. А остатокот од извештајот е за овој проблем. Какви перформанси може да очекувате од ClickHouse?
Како ќе го вметнеме? MergeTree
Кој од вас не слушнал или знае за „ClickHouse“? Треба да ти кажам, нели? Многу брзо. Вметнувањето таму - 1-2 гигабити во секунда, рафали до 10 гигабити во секунда всушност може да ја издржи оваа конфигурација - има два Xeon со 6 јадра (т.е., дури ни најмоќните), 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? Ова е прокси. Погодете на кој јазик? Собрав најмногу теми за возбуда во мојот извештај - „Кликхаус“, Оди, можеби ќе се сетам на нешто друго. Да, ова е напишано во Go, затоа што навистина не знам како да пишувам во C, не сакам.
Според тоа, одржува врска со секој сервер и може да пишува во меморијата. На пример, ако напишеме дневници за грешки во Clickhouse, тогаш ако Clickhouse нема време да вметне податоци (на крајот на краиштата, ако е напишано премногу), тогаш не ја отекуваме меморијата - едноставно го исфрламе остатокот. Затоа што ако напишеме неколку гигабити во секунда грешки, тогаш веројатно можеме да исфрлиме некои. Kittenhouse може да го направи тоа. Плус, може да изврши сигурна испорака, односно да пишува на диск на локалната машина и еднаш секој пат (таму, еднаш на секои неколку секунди) се обидува да испорача податоци од оваа датотека. И на почетокот го користевме редовниот формат на вредности - не некој бинарен формат, формат на текст (како во обичниот SQL).
Но, тогаш ова се случи. Користевме сигурна испорака, пишувавме дневници, па решивме (тоа беше условен тест кластер)... Беше изгаснат неколку часа и вратен, и започна вметнување од илјада сервери - се покажа дека Clickhouse сè уште има „Нишка на врска“ - соодветно, во илјада врски, активното вметнување води до просек на оптоварување на серверот од околу една и пол илјади. Изненадувачки, серверот прифати барања, но податоците сепак беа вметнати по некое време; но на серверот му беше многу тешко да го сервира...
Додадете nginx
Такво решение за моделот Thread per Connection е nginx. Инсталиравме nginx пред Clickhouse, во исто време поставивме балансирање за две реплики (нашата брзина на вметнување се зголеми за 2 пати, иако не е факт дека тоа треба да биде случај) и го ограничивме бројот на врски со Clickhouse, на спротиводно и, соодветно, повеќе , отколку во 50 врски, се чини дека нема смисла да се вметнува.
Тогаш сфативме дека оваа шема генерално има недостатоци, бидејќи овде имаме само еден nginx. Според тоа, ако овој nginx падне, и покрај присуството на реплики, губиме податоци или, барем, не пишуваме никаде. Затоа направивме сопствено балансирање на товарот. Сфативме и дека „Кликхаус“ сè уште е погоден за трупци, а „демонот“ исто така почна да ги пишува своите дневници во „Кликхаус“ - многу погодно, да бидам искрен. Сè уште го користиме за други „демони“.
Потоа го откривме овој интересен проблем: ако користите нестандарден метод за вметнување во режим SQL, тој принудува полноправен SQL парсер базиран на AST, кој е прилично бавен. Според тоа, додадовме поставки за да се осигураме дека тоа никогаш нема да се случи. Направивме load balancing, здравствени проверки, така што ако некој умре, сепак ги оставаме податоците. Сега имаме доста табели кои ни се потребни за да имаме различни Clickhouse кластери. И, исто така, почнавме да размислуваме за други намени - на пример, сакавме да пишуваме дневници од nginx модулите, но тие не знаат како да комуницираат користејќи го нашиот RPC. Па, би сакал да ги научам како да испраќаат барем некако - на пример, да примаат настани на localhost преку UDP и потоа да ги проследат до Clickhouse.
На чекор од решението
Конечната шема почна да изгледа вака (четвртата верзија на оваа шема): на секој сервер пред Clickhouse има nginx (на истиот сервер) и едноставно ги префрла барањата до локалниот хост со ограничување на бројот на врски од 50 парчиња. И оваа шема веќе работеше доста, сè беше прилично добро со неа.
Живеевме вака околу еден месец. Сите беа среќни, додадоа табели, додадоа, додадоа... Општо земено, испадна дека начинот на кој додадовме табели за тампон не е баш оптимален (ајде да го ставиме така). Направивме 16 парчиња во секоја табела и интервал на блиц од неколку секунди; имавме 20 табели и секоја табела добиваше 8 инсерти во секунда - и во овој момент започна „Clickhouse“... записите почнаа да се забавуваат. Тие дури и не поминаа низ... Nginx стандардно имаше толку интересно нешто што ако врските завршуваа на спротиводно, тогаш едноставно враќаше „502“ на сите нови барања.
И тука имаме (штотуку ги погледнав дневниците во самиот Clickhouse) околу половина процент од барањата не успеаја. Според тоа, искористеноста на дискот беше висока, имаше многу спојувања. Па, што направив? Секако, не се потрудив да сфатам зошто токму врската и возводно завршија.
Замена на nginx со обратен прокси
Решив дека треба сами да управуваме со ова, не треба да го препуштаме на nginx - nginx не знае какви табели има во Clickhouse и го заменив nginx со обратен прокси, кој исто така го напишав сам.
Што прави тој? Работи врз основа на библиотеката fasthttp „goshnoy“, односно брзо, скоро исто толку брзо како nginx. Извинете, Игор, ако сте присутни овде (забелешка: Игор Сисоев е руски програмер кој го создал веб-серверот nginx). Може да разбере каков тип на барања се тоа - INSERT или SELECT - соодветно, содржи различни базени за поврзување за различни типови на барања.
Според тоа, дури и ако немаме време да ги завршиме барањата за вметнување, „избраните“ ќе поминат и обратно. И ги групира податоците во табели за тампон - со мал бафер: ако има некои грешки, синтаксни грешки и слично - така што тие нема да влијаат многу на остатокот од податоците, бидејќи кога едноставно ги вметнуваме во табелите на тампон, ние имаше мали „бачи“, и сите синтаксички грешки влијаеа само на ова мало парче; и тука веќе ќе влијаат на голем тампон. Мал е 1 мегабајт, односно не толку мал.
Вметнувањето на синхронизација и суштински заменувањето на nginx, во суштина го прави истото што го правеше nginx претходно - не треба да ја менувате локалната „Куќа за мачиња“ за ова. И бидејќи користи fasthttp, тој е многу брз - можете да направите повеќе од 100 илјади барања во секунда за единечни инсерти преку обратен прокси. Теоретски, можете да вметнете една линија во исто време во обратниот прокси во куќата за мачиња, но, се разбира, ние не го правиме тоа.
Шемата почна да изгледа вака: „Куќа за мачиња“, обратниот прокси групира многу барања во табели и, пак, табелите за тампон ги вметнуваат во главните.
Убиецот е привремено решение, Мачето е трајно
Ова е интересен проблем... Дали некој од вас користел fasthttp? Кој користеше fasthttp со POST барања? Веројатно, ова навистина не требаше да се направи, бидејќи стандардно го баферира телото на барањето, а нашата големина на баферот беше поставена на 16 мегабајти. Вметнувањето престана да се одржува во одреден момент, и делови од 16 мегабајти почнаа да пристигнуваат од сите десетици илјади сервери, и сите тие беа баферирани во меморијата пред да бидат испратени до Clickhouse. Според тоа, меморијата снема, дојде убиецот без меморија и го уби обратниот прокси (или „Clickhouse“, кој теоретски може да „јаде“ повеќе од обратниот прокси). Циклусот се повтори. Не е многу пријатен проблем. Иако на ова наидовме дури по неколку месеци работа.
Што направив? Повторно, не ми се допаѓа да разберам што точно се случило. Мислам дека е прилично очигледно дека не треба да се баферирате во меморијата. Не можев да закрпам fasthttp, иако пробав. Но, најдов начин да го направам така што нема потреба да се закрпи ништо, и смислив свој метод во HTTP - го нареков МАЧЕ. Па, логично е - „ВК“, „Маче“... Што друго? ..
Ако дојде барање до серверот со методот Kitten, тогаш серверот треба да одговори „мјау“ - логично. Ако одговори на ова, тогаш се смета дека го разбира овој протокол, а потоа ја пресретнувам врската (таков метод има fasthttp), а врската оди во режим „суров“. Зошто ми треба? Сакам да контролирам како се случува читањето од TCP конекции. TCP има прекрасна особина: ако никој не чита од другата страна, тогаш пишувањето почнува да чека, а меморијата не се троши особено за ова.
И така читам од околу 50 клиенти одеднаш (од педесет затоа што педесет дефинитивно треба да биде доволно, дури и ако стапката доаѓа од друг DC)... Потрошувачката е намалена со овој пристап најмалку 20 пати, но јас, да бидам искрен , не можев точно да измерам колку време, бидејќи веќе е бесмислено (веќе е достигнато ниво на грешка). Протоколот е бинарен, односно содржи име на табелата и податоци; нема http заглавија, така што не користев веб-сокет (не треба да комуницирам со прелистувачи - направив протокол што одговара на нашите потреби). И сè стана добро со него.
Табелата е тажна
Неодамна наидовме на уште една интересна карактеристика на табелите за тампон. И овој проблем е веќе многу поболен од другите. Да ја замислиме оваа ситуација: веќе активно користите Clickhouse, имате десетици Clickhouse сервери и имате некои барања за кои е потребно многу долго време за читање (да речеме, повеќе од 60 секунди); а вие дојдете и правите Alter во овој момент... Во меѓувреме, „изборите“ што започнале пред „Alter“ нема да бидат вклучени во оваа табела, „Alter“ нема да започне - веројатно некои карактеристики за тоа како функционира „Clickhouse“ во ова место. Можеби ова може да се поправи? Или не е можно?
Генерално, јасно е дека во реалноста ова не е толку голем проблем, но со тампон-табелите станува поболно. Зашто, ако, да речеме, вашиот „Alter“ истече (и може да истече на друг хост - не на вашиот, туку на реплика, на пример), тогаш... Ја избришавте табелата за тампон, вашиот „Alter“ ( или некој друг хост) истече. тогаш се појави грешка „Alter“) - сепак треба да се осигурате дека податоците продолжуваат да се пишуваат: ги креирате табелите за тампон назад (според истата шема како матичната табела), потоа „Alter“ поминува низ, завршува, а тампонот на табелата почнува да се разликува по шема од родителот. Во зависност од тоа што беше „Alter“, вметнувањето може повеќе да не оди на оваа табела за тампон - ова е многу тажно.
Има и таков знак (можеби некој го забележал) - се вика query_thread_log во новите верзии на Clickhouse. Стандардно, во некоја верзија имаше една. Овде имаме акумулирано 840 милиони записи за неколку месеци (100 гигабајти). Ова се должи на фактот дека таму беа напишани „инсерти“ (можеби сега, патем, тие не се напишани). Како што ви реков, нашите „инсерти“ се мали - имавме многу „инсерти“ во табелите за тампон. Јасно е дека ова е оневозможено - само ви кажувам што видов на нашиот сервер. Зошто? Ова е уште еден аргумент против користење на табели за тампон! Споти е многу тажен.
Кој знаеше дека овој човек се вика Споти? Вработените во ВК кренаа раце. ДОБРО.
За плановите за „KitttenHouse“
Плановите обично не се споделуваат, нели? Одеднаш нема да ги исполните и нема да изгледате многу добро во очите на другите луѓе. Но, ќе ризикувам! Сакаме да го направиме следново: тампон-масите, ми се чини, сè уште се патерица и треба сами да го тампонираме вметнувањето. Но, сè уште не сакаме да го баферираме на дискот, така што ќе го зачуваме вметнувањето во меморијата.
Соодветно, кога ќе се направи „вметнување“, тој повеќе нема да биде синхрони - веќе ќе работи како тампон-табела, ќе се вметне во матичната табела (добро, еден ден подоцна) и ќе известува преку посебен канал кои инсерти поминале и кои нема.
Зошто не можам да го напуштам синхроното вметнување? Тоа е многу поудобно. Факт е дека ако вметнете од 10 илјади хостови, тогаш се е во ред - ќе добиете по малку од секој хост, вметнувате таму еднаш во секунда, се е во ред. Но, би сакал оваа шема да работи, на пример, од две машини, за да можете да преземате со голема брзина - можеби нема да го извлечете максимумот од Clickhouse, но напишете најмалку 100 мегабајти во секунда од една машина преку обратен прокси - ова шемата мора да се размери и на големи и на мали количини, така што не можеме да чекаме секунда за секое вметнување, па затоа мора да биде асинхроно. И на ист начин, асинхрони потврди треба да дојдат по завршувањето на вметнувањето. Ќе знаеме дали помина или не.
Најважно е дека во оваа шема со сигурност знаеме дали вметнувањето се случило или не. Замислете ја оваа ситуација: имате тампон-табела, сте напишале нешто во неа, а потоа, да речеме, табелата отишла во режим само за читање и се обиде да го испушти баферот. Каде ќе одат податоците? Тие ќе останат во тампон. Но, не можеме да бидеме сигурни во ова - што ако има некоја друга грешка, поради која податоците нема да останат во баферот... (Се обраќа на Алексеј Миловидов, Yandex, развивач на ClickHouse) Или ќе остане? Секогаш? Алексеј не убедува дека сè ќе биде добро. Немаме причина да не му веруваме. Но, сеедно: ако не користиме табели за тампон, тогаш нема да има никакви проблеми со нив. Создавањето двојно повеќе табели е исто така незгодно, иако во принцип нема големи проблеми. Ова е планот.
Ајде да зборуваме за читање
Сега ајде да зборуваме за читање. Тука напишавме и сопствена алатка. Се чини, добро, зошто да напишете свој инструмент овде?.. А кој користел Tabix? Некако малку луѓе кренаа раце... А кој е задоволен од настапот на Табикс? Па, ние не сме задоволни со тоа, и не е многу погодно за гледање податоци. Добро е за аналитика, но само за гледање очигледно не е оптимизирано. Така напишав свој, мој сопствен интерфејс.
Многу е едноставно - може да чита само податоци. Не знае да покажува графика, не знае ништо да прави. Но, може да покаже што ни треба: на пример, колку редови има во табелата, колку простор зафаќа (без да го разделиме во колони), односно, многу основен интерфејс е она што ни треба.
И изгледа многу слично на Sequel Pro, но направено само на Bootstrap на Twitter и втората верзија. Вие прашувате: „Јуриј, зошто на втората верзија? Која година? 2018? Во принцип, го направив ова многу одамна за „Muscle“ (MySQL) и само сменив неколку линии во барањата таму, и почна да работи за „Clickhouse“, за што посебна благодарност! Бидејќи парсерот е многу сличен на оној „мускулите“, а прашањата се многу слични - многу погодни, особено на почетокот.
Па, може да филтрира табели, може да ја прикаже структурата и содржината на табелата, ви овозможува да сортирате, филтрирате по колони, го прикажува барањето што резултирало со резултатот, погодените редови (колку како резултат), т.е. основни работи за гледање податоци. Прилично брзо.
Има и уредник. Искрено се обидов да го украдам целиот уредник од Табикс, но не можев. Но, некако функционира. Во принцип, тоа е сè.
„Clickhouse“ е погодна за дувла
Сакам да ви кажам дека Clickhouse, и покрај сите опишани проблеми, е многу добро прилагоден за логови. Што е најважно, го решава нашиот проблем - тој е многу брз и ви овозможува да ги филтрирате дневниците по колони. Во принцип, бафер табелите не се покажаа добро, но обично никој не знае зошто... Можеби сега знаете подобро каде ќе имате проблеми.
TCP? Во принцип, во VK вообичаено е да се користи UDP. И кога користев TCP... Се разбира, никој не ми рече: „Јуриј, што зборуваш! Не можеш, ти треба UDP“. Се испостави дека TCP не е толку страшен. Единственото нешто е, ако имате десетици илјади активни соединенија што ги пишувате, треба да го подготвите малку повнимателно; но тоа е можно, и прилично лесно.
Ветив дека ќе ги објавам „Kittenhouse“ и „Lighthouse“ на HighLoad Siberia доколку сите се претплатат на нашиот јавен „VK backend“... И знаете, не се претплатени сите... Се разбира, нема да барам да се претплатите на нашата јавен. Сè уште ве има премногу, некој може и да се навреди, но сепак, ве молам, претплатете се (и тука морам да направам очи како оние на мачката). Тоа е . Ти благодарам многу! Github е наш . Со Clickhouse вашата коса ќе биде мека и свиленкаста.
Водач: - Пријатели, сега за прашања. Веднаш откако ќе го претставиме сертификатот за благодарност и вашиот извештај за VHS.
Јуриј Насретдинов (во натамошниот текст: YN): – Како можевте да го снимите мојот извештај за VHS ако штотуку заврши?
Водач: – Исто така, не можете целосно да одредите како „Clickhouse“ ќе работи или не! Пријатели, 5 минути за прашања!
прашања
Прашање од публиката (во натамошниот текст П): - Добар ден. Ви благодарам многу за извештајот. Имам две прашања. Ќе почнам со нешто несериозно: дали бројот на буквите t во името „Куќа за мачиња“ на дијаграмите (3, 4, 7...) влијае на задоволството на мачките?
YN: - Количина од што?
З: – Писмо т. Има три т, некаде околу три т.
YN: - Нели го поправив? Па, се разбира дека тоа го прави! Тоа се различни производи - само те мамев цело ова време. Добро, се шегувам - не е важно. Ах, токму тука! Не, истото е, направив печатна грешка.
З: - Ви благодарам. Второто прашање е сериозно. Колку што разбрав, во Clickhouse, табелите за бафери живеат исклучиво во меморија, не се баферирани на дискот и, соодветно, не се постојани.
YN: - Да.
З: – И во исто време, вашиот клиент се баферира на дискот, што подразбира одредена гаранција за испорака на истите овие дневници. Но, ова во никој случај не е загарантирано во Clickhouse. Објасни како се спроведува гаранцијата, поради што?.. Еве го овој механизам подетално
YN: – Да, теоретски тука нема противречности, бидејќи кога Кликхаус паѓа, всушност можете да го откриете на милион различни начини. Ако Clickhouse падне (ако заврши погрешно), може грубо кажано, да премотате малку од дневникот што сте го запишале и да започнете од моментот кога сè беше точно во ред. Да речеме дека премотувате минута назад, односно се смета дека сте исплакнале се за една минута.
З: – Односно, „Китенхаус“ подолго го држи прозорецот и, во случај на пад, може да го препознае и да го премота?
YN: – Но, ова е во теорија. Во пракса, ние не го правиме ова, а сигурната испорака е од нула до бесконечност пати. Но, во просек по еден. Задоволни сме што ако Clickhouse падне поради некоја причина или серверите се „рестартираат“, тогаш губиме малку. Во сите други случаи, ништо нема да се случи.
З: - Здраво. Од самиот почеток ми се чинеше дека навистина ќе користите UDP од самиот почеток на извештајот. Имаш http, сето тоа... И повеќето од проблемите што ги опиша, како што јас разбирам, се предизвикани од ова конкретно решение...
YN: – Што користиме TCP?
З: - Во суштина да.
YN: - Не
З: – Со fasthttp имаше проблеми, со врската имаше проблеми. Ако штотуку користевте UDP, ќе заштедивте малку време. Па, би имало проблеми со долги пораки или нешто друго...
YN: - Со што?
З: – Со долги пораки, бидејќи можеби не се вклопува во МТУ, нешто друго... Па, може да има и свои проблеми. Прашањето е: зошто да не UDP?
YN: – Верувам дека авторите кои го развиле TCP/IP се многу попаметни од мене и знаат подобро од мене како да ги серијализираат пакетите (така да одат), во исто време го прилагодуваат прозорецот за испраќање, не ја преоптоваруваат мрежата, даваат повратни информации за тоа што не се чита, не сметајќи на другата страна... Сите овие проблеми, според мене, би постоеле во UDP, само што би морал да напишам уште повеќе код отколку што веќе напишав за да го имплементирам истото сам и најверојатно лошо. Не сакам ни да пишувам на C, а камоли таму...
З: - Само погодно! Испратено во ред и не чекајте ништо - тоа е целосно асинхроно. Се врати известување дека сè е во ред - тоа значи дека пристигнало; Ако не дојде, тоа значи дека е лошо.
YN: – Ми требаат и двете – Треба да можам да ги испратам и двете со гаранција за испорака и без гаранција за испорака. Ова се две различни сценарија. Треба да не изгубам некои трупци или да не ги изгубам во разум.
З: – Нема да губам време. За ова треба повеќе да се разговара. Ви благодарам.
Водач: – Кој има прашања – рацете кон небото!
З: - Здраво, јас сум Саша. Некаде на средината на извештајот се појави чувство дека, покрај TCP, може да се користи и готово решение - некој вид на Кафка.
YN: – Па... ти реков дека не сакам да користам интермедијарни сервери, затоа што... во Кафка, испаѓа дека имаме десет илјади хостови; всушност, имаме повеќе - десетици илјади домаќини. Може да биде болно и да се прави со Кафка без никакви прокси. Покрај тоа, што е најважно, сè уште дава „латентност“, дава дополнителни домаќини што треба да ги имате. Но, не сакам да ги имам - сакам ...
З: „Но, на крајот сепак испадна така“.
YN: – Не, нема домаќини! Сето ова функционира на хостовите на Clickhouse.
З: - Па, и „Куќа за мачиња“, што е обратно - каде живее?
YN: – На хостот Clickhouse не пишува ништо на дискот.
З: - Да претпоставиме.
Водач: - Дали си задоволен? Можеме ли да ви дадеме плата?
З: - Да ти можеш. Всушност, има многу патерици за да се добие истото, а сега - претходниот одговор на темата TCP е во спротивност, според мене, со оваа ситуација. Едноставно се чувствувам како сè да можеше да се направи на моите колена за многу помалку време.
YN: – И, исто така, зошто не сакав да го користам Кафка, бидејќи имаше доста поплаки во разговорот за Телеграм на Clickhouse дека, на пример, пораките од Кафка се изгубени. Не од самиот Кафка, туку во интеграцијата на Кафка и Кликхаус; или нешто не се поврза таму. Грубо кажано, тогаш би требало да се напише клиент за Кафка. Мислам дека не може да има поедноставно или посигурно решение.
З: – Кажи ми, зошто не пробавте редици или некој вид обичен автобус? Бидејќи велиш дека со асинхронија би можел да ги испратиш самите дневници низ редот и да го добиеш одговорот асинхроно преку редот?
YN: – Ве молиме предложете какви редици би можеле да се користат?
З: – Секакви, дури и без гаранција дека се во ред. Некој вид на Redis, RMQ...
YN: – Имам чувство дека Редис најверојатно нема да може да повлече толкав волумен на вметнување дури ни на еден хост (во смисла на неколку сервери) што го вади Clickhouse. Не можам да го поткрепам ова со никакви докази (не сум го мери), но ми се чини дека Редис не е најдоброто решение овде. Во принцип, овој систем може да се смета како импровизирана редица пораки, но која е прилагодена само за „Clickhouse“
Водач: – Јуриј, многу ти благодарам. Предлагам тука да ги завршам прашањата и одговорите и да кажеме на кој од оние кои го поставиле прашањето ќе ја дадеме книгата.
YN: – Би сакал да му подарам книга на првиот што постави прашање.
Водач: - Прекрасно! Одлично! Прекрасно! Благодарам многу!
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB 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