HighLoad++ Moscow 2018, зала «Кангрэс-хол». 9 лістапада, 15:00
Тэзы і прэзентацыя:
Юрый Насрэтдзінаў (УКантакце): у дакладзе будзе расказана аб вопыце ўкаранення ClickHouse ў нашай кампаніі - для чаго ён нам патрэбен, колькі мы захоўваем дадзеных, як іх пішам і гэтак далей.
Дадатковыя матэрыялы:
Юрый Насрэтдзінаў: - Ўсім прывітанне! Мяне клічуць Юры Насрэтдзінаў, як ужо прадставілі мяне. Я працую ва "УКантакце". Я буду расказваць пра тое, як мы ўстаўляем дадзеныя ў «ClickHouse» з нашага парку сервераў (дзясяткі тысяч).
Што такое логі і навошта іх збіраць?
Што мы будзем расказваць: што мы рабілі, навошта нам спатрэбіўся «ClickHouse», адпаведна – чаму мы яго выбралі, якую прадукцыйнасць вы можаце прыкладна атрымаць, нічога не канфігуруючы спецыяльна. Раскажу далей пра буферныя табліцы, пра праблемы, якія ў нас з імі былі і пра нашыя рашэнні, якія мы распрацавалі з «опен-сорса» – KittenHouse і Lighthouse.
Навошта нам спатрэбілася ўвогуле нешта рабіць (ва «Укантакце» заўсёды ўсё добра, так?). Мы хацелі збіраць дэбаг-лагі (і іх там было сотні тэрабайт дадзеных), можа, яшчэ неяк статыстыку ямчэй лічыць; і ў нас парк сервераў у дзясяткі тысяч, з якіх усё гэта трэба рабіць.
Чаму мы вырашылі? У нас жа, напэўна, былі рашэнні для захоўвання логаў. Вось - ёсць такі паблік «Бэкенд ВК». Вельмі рэкамендую падпісацца на яго.
Што такое logs? Гэта рухавічок, які вяртае пустыя масівы. Рухавікамі ў «ВК» называецца тое, што мікрасэрвісамі астатнія называюць. І такі вось стыкер усмешлівы (даволі шмат лайкаў). Як так? Ну, слухайце далей!
Што ўвогуле можна выкарыстоўваць для захоўвання логаў? Нельга не згадаць "Хадуп". Потым, напрыклад, Rsyslog (захоўванне ў файлах гэтых логаў). LSD. Хто ведае, што такое ЛСД? Не, не гэты ЛСД. Файлы захоўваць, адпаведна, таксама. Ну і ClickHouse - дзіўны варыянт нейкі.
"Клікхаус" і канкурэнты: патрабаванні і магчымасці
Што мы жадаем? Мы жадаем, каб нам не трэба было асоба парыцца з эксплуатацыяй, каб яна працавала са скрынкі пажадана, з мінімальнай наладай. Жадаем пісаць вельмі шмат, а пісаць хутка. І жадаем захоўваць гэта ўсякія месяцы, гады, гэта значыць доўга. Мы можам хацець разабрацца ў праблеме нейкай, з якой да нас прыйшлі, сказалі – «У нас тут нешта не працуе», – а гэта было 3 месяцы таму), і мы хочам мець магчымасць паглядзець, каб было 3 месяцы таму ». Сціск дадзеных - зразумела, чаму яно будзе плюсам, - таму што скарачаецца колькасць месца, якое займаецца.
І ў нас ёсць такое цікавае патрабаванне: мы часам пішам output якіх-небудзь каманд (напрыклад, логі), яно можа быць больш за 4 кілабайт зусім спакойна. І калі гэтая штука мае працаваць па UDP, то ёй не трэба марнаваць… у яе не будзе ніякага "оверхеда" на злучэнне, і для вялікай колькасці сервераў гэта будзе плюсам.
Давайце паглядзім, што прапануе "опен-сорс" нам. Па-першае, у нас ёсць Logs Engine - гэта наш рухавічок; ён у прынцыпе ўсё ўмее, нават доўгія радкі ўмее пісаць. Ну, празрыста дадзеныя ён не сціскае - мы можам вялікія калонкі самі сціскаць, калі захочам… мы, вядома, не жадаем (па магчымасці). Адзіная праблема - ён умее аддаваць толькі тое, што ў яго змяшчаецца ў памяці; астатняе, каб прачытаць, трэба даставаць binlog гэтага рухавічка і, адпаведна, гэта даволі доўга.
Якія ёсць варыянты іншыя? Напрыклад, "Хадуп". Прастата эксплуатацыі ... Хто лічыць, што «Хадуп» лёгка наладжваецца? З запісам, вядома ж, праблем няма. З чытаннем пытанні часам узнікаюць. У прынцыпе я сказаў бы, што хутчэй не, асабліва для логаў. Доўгачасовае захоўванне - вядома, так, сціск дадзеных - так, доўгія радкі - зразумела, што можна запісваць. А вось запісваць з вялікай колькасці сервераў… Усё роўна трэба самім нешта рабіць!
Rsyslog. Насамрэч мы яго выкарыстоўвалі як запасны варыянт, для таго каб можна было без дампа Бінго чытаць, але ён не можа ў доўгія радкі, у прынцыпе больш за 4 кілабайт не можа запісаць. Сціск дадзеных сапраўды гэтак жа самім трэба рабіць. Чытанне будзе ісці з файлаў.
Затым ёсць «бадушная» тэхналогія LSD. Тое ж самае па сутнасці, што і "Rsyslog": доўгія радкі падтрымлівае, але па UDP працаваць не ўмее і, уласна, з-за гэтага, на жаль, там даволі шмат чаго перапісваць трэба. LSD трэба перарабляць, каб можна было ажыццяўляць запіс з дзясяткаў тысяч сервераў.
А вось! Смешны варыянт - ElasticSearch. Ну, як сказаць? З чытаннем у яго ўсё добра, то бок ён чытае хутка, але з запісам не вельмі добра. Па-першае, дадзеныя ён, калі і сціскае, то вельмі слаба. Хутчэй за ўсё, для паўнавартаснага пошуку патрабуюцца больш аб'ёмныя структуры даных, чым зыходны аб'ём. Эксплуатаваць цяжка, з ім часта праблемы ўзнікаюць. І, зноў жа, запіс у «Эластык» - усе мы самі павінны рабіць.
Вось ClickHouse - ідэальны варыянт, зразумелая справа. Адзінае, запіс з дзясяткаў тысяч сервераў - гэта праблема. Але яна хаця б адна, мы яе можам паспрабаваць неяк вырашыць. І вось пра гэтую праблему ўвесь астатні даклад. Якую ўвогуле прадукцыйнасць ад «ClickHouseа» можна чакаць?
Як будзем устаўляць? MergeTree
Хто з вас пра "ClickHouse" не чуў, не ведае? Трэба расказаць, не трэба? Вельмі хутка. Устаўка там - 1-2 гігабіта ў секунду, воплескамі да 10 гігабіт у секунду на самай справе можа вытрымліваць на вось такой канфігурацыі - там два 6-ядзерных «Ксеона» (гэта значыць нават не самыя магутныя), 256 гігаў аператывы, 20 тэрабайтаў у RAID (ніхто не наладжваў, дэфолтныя налады). Аляксей Мілавідаў, распрацоўшчык ClickHouse, напэўна, плача сядзіць, што мы нічога не настройвалі (у нас усё працавала так). Адпаведна, хуткасць сканавання, дапусцім, каля 6 мільярдаў радкоў у секунду можна атрымаць, калі дадзеныя добра сціскаюцца. Калі вы like% па тэкставым радку робіце - 100 мільёнаў радкоў у секунду, гэта значыць здаецца, што вельмі хутка.
Як будзем устаўляць? Ну, вы ведаеце, што ў "ВК" - на PHP. Мы з кожнага PHP-воркера будзем па HTTP устаўляць у "ClickHouse", у таблічку MergeTree на кожны запіс. Хто бачыць праблему ў гэтай схеме? Чамусьці не ўсе паднялі рукі. Давайце раскажу.
Па-першае, сервераў шмат - адпаведна, злучэнняў будзе станавіцца шмат (дрэнна). Затым у MergeTree лепш устаўляць дадзеныя не часцей, чым раз у секунду. А хто ведае чаму? Добра, добра. Я раскажу крыху падрабязней пра гэта. Яшчэ цікавае пытанне - што мы як бы не аналітыку робім, нам не трэба ўзбагачаць дадзеныя, нам не патрэбныя прамежкавыя сервера, мы хочам устаўляць прама ў "ClickHouse" (пажадана - чым прамей, тым лепш).
Адпаведна, як ажыццяўляецца ўстаўка ў MergeTree? Чаму ў яго лепш устаўляць не часцей, чым раз у секунду ці радзей? Справа ў тым, што "ClickHouse" - стаўбцовая база дадзеных і сартуе дадзеныя ў парадку ўзрастання першаснага ключа, і калі вы робіце ўстаўку, ствараецца колькасць файлаў як мінімум па колькасці калонак, у якіх дадзеных адсартаваныя ў парадку ўзрастання першаснага ключа (ствараецца асобная дырэкторыя, набор файлаў на дыску на кожны insert). Потым наступная ўстаўка ідзе, і ў фоне яны аб'ядноўваюцца ў большага памеру "партыцыі". Паколькі дадзеныя адсартаваныя, то "смержыць" два адсартаваных файла можна без вялікага спажывання памяці.
Але, як вы здагадваецеся, калі запісаць па 10 файлаў на кожны insert, то ClickHouse хутка скончыцца (ці ваш сервер), таму рэкамендуецца ўстаўляць вялікімі пачкамі. Адпаведна, схему першую мы ніколі не запускалі ў прадакшн. Мы адразу запусцілі такую, якая тут № 2 мае:
Тут уявіце сабе, што есць каля тысячы сервераў, на якіх мы запусцілі, там проста PHP. І на кожным серверы стаіць наш лакальны агент, які мы назвалі «Кітэнхаўс», які трымае адно злучэнне з «ClickHouse» і раз у некалькі секунд устаўляе дадзеныя. Устаўляе дадзеныя не ў MergeTree, а ў буферную табліцу, якая як раз служыць для таго, каб не ўстаўляць напрамую ў MergeTree, адразу.
Праца з буфернымі табліцамі
Што гэта такое? Буферныя табліцы - гэта кавалак памяці, пашардаваны (гэта значыць у яго можна часта ўстаўляць). Яны складаюцца з некалькіх кавалкаў, і кожны з кавалкаў працуе як незалежны буфер, і яны незалежна скачацца (калі ў вас шмат кавалкаў у буфера, то і ўставак будзе шмат у секунду). Чытаць з гэтых табліц можна - тады вы чытаеце аб'яднанне змесціва буфера і бацькоўскай табліцы, але ў гэты момант блакуецца запіс, таму лепш не чытаць адтуль. І вельмі добры QPS паказваюць буферныя табліцы, гэта значыць да 3 тысяч QPS у вас не ўзнікне наогул ніякіх праблем пры ўстаўцы. Зразумела, што, калі знікла сілкаванне ў сервера, то дадзеныя можна страціць, бо яны толькі ў памяці захоўваліся.
Пры гэтым схему з буферам ускладняе ALTER, таму што вам трэба спачатку дропнуць старую буферную табліцу са старой схемай (дадзеныя нікуды не знікнуць пры гэтым, таму што яны зафлашацца перад тым, як табліца выдаліцца). Потым вы "альтэрыце" патрэбную вам табліцу і ствараеце буферную табліцу нанова. Адпаведна, пакуль няма буфернай табліцы, у вас дадзеныя нікуды не льюцца, але вы можаце іх на дыску хаця б лакальна.
Што такое «Кітэнхаўс» і як гэта працуе?
Што з сябе ўяўляе KittenHouse? Гэта проксі. Адгадайце, на якой мове? Я сабраў самыя хайповые тэмы ў сваім дакладзе - гэта "Клікхаус", Go, можа, яшчэ што-небудзь успомню. Так, на Го гэта напісана, таму што я не вельмі ўмею пісаць на Сі, не хачу.
Адпаведна, яно трымае злучэнне з кожным серверам, умее пісаць у памяць. Напрыклад, калі мы пішам error-лагі ў "Клікхаўс", то, калі "Клікхаўс" не паспявае ўстаўляць дадзеныя (усёткі калі іх занадта шмат пішацца), то мы не распухаем па памяці - мы проста выкідваем астатняе. Бо калі ў нас пішацца некалькі гігабіт у секунду памылак, то, напэўна, нам можна нейкія выкінуць. «Кітэнхаўс» гэта ўмее. Плюс, ён умее надзейную дастаўку, гэта значыць запіс на дыск на лакальнай машыне і раз у нейкі час (там, раз у пару секунд) спрабуе дадзеныя з гэтага файла даставіць. І мы спачатку выкарыстоўвалі звычайны фармат Values - не нейкі бінарны фармат, тэкставы фармат (як у звычайным SQL).
Але далей адбылося вось такое вось. Мы выкарыстоўвалі надзейную дастаўку, пісалі логі, потым вырашылі (гэта быў такі, умоўна тэставы кластар)… На некалькі гадзін яго патушылі і паднялі назад, і з тысячы сервераў пайшла ўстаўка – аказалася, што ў «Клікхаўса» ўсё ж такі мадэль «Трэд на злучэнне» – адпаведна, у тысячу злучэнняў актыўная ўстаўка прыводзіць да load average на серверы дзесьці ў паўтары тысячы. На здзіўленне, сервер прымаў запыты, а дадзеныя такія ўсё ж уставіліся праз нейкі час; але вельмі цяжка было серверу гэта абслугоўваць…
Дадаем nginx
Такое рашэнне для мадэлі Thread per connection - гэта nginx. Мы паставілі nginx перад "Клікхаўсам", заадно наладзілі балансаванне на дзве рэплікі (у нас яшчэ ў 2 разы павялічылася хуткасць устаўкі, хоць не факт, што так павінна быць) і абмежавалі колькасць злучэнняў да "Клікхаўса", да апстрыму і, адпаведна, больш , чым у 50 злучэнняў, здаецца, сэнсу ўстаўляць няма.
Потым мы зразумелі, што ўвогуле гэтая схема мае недахопы, таму што ў нас тут – адзін nginx. Адпаведна, калі гэты nginx кладзецца, нягледзячы на наяўнасць рэплік, мы дадзеныя губляем ці, прынамсі, нікуды не пішам. Таму мы зрабілі сваё балансаванне нагрузкі. Таксама мы зразумелі, што «Клікхаўс» усё ж для логаў падыходзіць і «дэман» таксама пачаў пісаць свае логі таксама ў «Клікхаўс» – вельмі зручна, калі шчыра. Да гэтага часу выкарыстоўваем яшчэ і для іншых «дэманаў».
Потым выявілі такую цікавую праблему: калі вы выкарыстоўваеце не зусім стандартны спосаб устаўкі ў SQL-рэжыме, тое фарсіцца паўнавартасны SQL-парсер на аснове AST, які даволі павольны. Адпаведна, мы дадалі налады, каб такога не адбывалася ніколі. Зрабілі балансаванне нагрузкі, health-чэкі, каб, калі адна памірае, то мы ўсё роўна пакідалі дадзеныя. У нас стала дастаткова шмат табліц, каб нам стала трэба розныя кластары «Клікхаўса» мець. І яшчэ мы пачалі думаць пра іншыя выкарыстанні - напрыклад, мы жадалі пісаць логі з nginx-модуляў, а яны па нашым RPC мець зносіны не ўмеюць. Ну, хацелася б іх хоць неяк навучыць адпраўляць - напрыклад, па UDP прымаць падзеі на localhost і потым ужо іх перасылаць у «Клікхаўс».
За крок ад рашэння
Выніковая схема стала выглядаць вось так (чацвёрты варыянт гэтай схемы): на кожным серверы перад "Клікхаусам" стаіць nginx (на тым жа серверы прычым) і проста на localhost праксіруе запыты з абмежаваннем па колькасці злучэнняў у 50 штук. І вось гэтая схема ўжо працоўная цалкам была, з ёй было ўсё даволі добра.
Мы жылі так недзе месяц. Усе радаваліся, дадавалі табліцы, дадавалі, дадавалі… Увогуле, аказалася, што тое, як мы дадавалі буферныя табліцы, яно не вельмі аптымальна (скажам так) было. Мы рабілі па 16 кавалкаў у кожнай табліцы і флаш-інтэрвал пару секунд; у нас было 20 табліц і ў кожную табліцу ішло па 8 уставак у секунду - і ў гэтым моманце «Клікхаус» пачаў… запісы пачыналі тупіць. Яны нават не тое што не праходзілі… У nginx'а па змаўчанні была такая цікавая штука, што, калі канекты сканчаліся ў апстрыму, то на ўсе новыя запыты ён проста аддае "502".
І вось у нас (гэта я проста па логах у самім жа «Клікхаўсе» я паглядзеў) недзе паўпрацэнта запытаў фэйлілася. Адпаведна, утылізацыя дыска была высокая, шмат мяржэй было. Што я зрабіў? Я, натуральна, не стаў разбірацца, чаму менавіта сканчаецца канэкт і апстрым.
Замена nginx на рэверс-проксі
Я вырашыў, што нам трэба кіраваць гэтым самім, не трэба гэта даваць на водкуп nginx - nginx не ведае, якія табліцы ў "Клікхаусе" ёсць, і замяніў nginx на reverse-проксі, які таксама я сам напісаў.
Ён што робіць? Ён працуе на аснове бібліятэкі fasthttp "гошнай", гэта значыць хуткі, амаль такі ж хуткі, як nginx. Выбачыце, Ігар, калі вы тут прысутнічаеце (заўв.: Ігар Сысоев – рускі праграміст, які стварыў вэб-сервер nginx). Ён умее разумець, якія гэта запыты - INSERT або SELECT - адпаведна, розныя пулы злучэння трымае для розных відаў запытаў.
Адпаведна, нават калі мы на ўстаўку не паспяваем выканаць запыты, то "селекты" будуць праходзіць, і наадварот. І групуе дадзеныя па буферных табліцах - з невялікім буферам: калі там былі нейкія памылкі, сінтаксічныя памылкі і гэтак далей - каб яны нямоцна ўплывалі на астатнія дадзеныя, таму што, калі мы ўстаўлялі проста ў буферныя табліцы, то ў нас былі маленькія бачы», і ўсе памылкі памылкі сінтаксісу ўплывалі толькі на гэты маленькі кавалачак; а тут яны будуць уплываць ужо на вялікі буфер. Маленькі - гэта 1 мегабайт, гэта значыць не такі ўжо і маленькі.
Устаўка сінхрана і па сутнасці замяняе nginx, робіць па сутнасці тое ж самае, што і рабіў nginx да гэтага – «Кітэнхаус» лакальны мяняць для гэтага не трэба. І паколькі ён выкарыстоўвае fasthttp, ён вельмі хуткі - можна больш за 100 тысяч запытаў у секунду адзінкавых insert'аў рабіць праз reverse-проксі. Тэарэтычна можна ўстаўляць па адным радку ў kittenhouse reverse-проксі, але мы, вядома, так не які робіцца.
Схема стала выглядаць вось так: «Кітэнхаўс», reverse-проксі групуе шмат запытаў па табліцах і ўжо ў сваю чаргу буферныя табліцы ўстаўляюць іх у асноўныя.
Killer рашэнне часавае, Kitten сталае
Устала такая цікавая праблема… Хто-небудзь з вас выкарыстоўваў fasthttp? Хто пры гэтым выкарыстоўваў fasthttp з POST-запытамі? Мусіць, так не варта было рабіць насамрэч, таму што ён буферызуе цела запыту па змаўчанні, а ў нас памер буфера 16 мегабайт быў выстаўлены. Устаўка перастала паспяваць у нейкі момант, і з усіх дзясяткаў тысяч сервераў пачалі прыходзіць 16-мегабайтныя чанкі, і яны ўсё буферызаваліся ў памяці перад тым, як аддацца ў «Клікхаус». Адпаведна, памяць канчалася, Out-Of-Memory Killer прыходзіў, забіваў reverse-проксі (або "Клікхаўс", які мог тэарэтычна "жэрці" больш, чым reverse-проксі). Цыкл паўтараўся. Не надта прыемная праблема. Хаця мы на гэта натыкнуліся толькі праз некалькі месяцаў эксплуатацыі.
Што я зрабіў? Ізноў жа, я не вельмі кахаю разбірацца ў тым, што менавіта адбылося. Мне здаецца, даволі відавочна, што ня трэба буфэрызаваць у памяць. Я не змог прапатчыць fasthttp, хоць спрабаваў. Але я знайшоў спосаб, як зрабіць так, каб не трэба было нічога патчыць, і прыдумаў свой метад у HTTP - назваў яго KITTEN. Ну, лагічна - "ВК", "Кітэн"… Як яшчэ?..
Калі прыходзіць запыт на сервер з метадам Kitten, то сервер павінен адказаць "мяу" (meow) - лагічна. Калі ён на гэта адказвае, то лічыцца, што ён разумее гэты пратакол, і далей я перахапляю злучэнне (у fasthttp такі метад ёсць), і злучэнне пераходзіць у "волкі" рэжым. Навошта мне гэта патрэбна? Я хачу кіраваць тым, як адбываецца чытанне з TCP-злучэнняў. У TCP ёсць выдатная ўласцівасць: калі ніхто не чытае з таго боку, то запіс пачынае чакаць, і памяць асоба не выдаткоўваецца на гэта.
І вось я чытаю недзе з 50 кліентаў за раз (з пяцідзесяці таму, што пяцідзесяці ўжо сапраўды павінна хапіць, нават калі гэта з іншага ДЦ стаўка ідзе)… Спажыванне зменшылася з такім падыходам як мінімум у 20 разоў, але я, калі шчыра , не змог замерыць, у колькі менавіта, таму што гэта ўжо бессэнсоўна (яно ўжо на ўзроўні хібнасці стала). Пратакол бінарны, гэта значыць, там ідзе імя табліцы і дадзеныя; няма http-загалоўкаў, таму я не выкарыстоўваў вэб-сокет (мне ж з браўзэрамі не трэба мець зносіны - я зрабіў пратакол, які падыходзіць пад нашы патрэбы). І з ім стала ўсё добра.
Буферная табліца - гэта сумна
Нядаўна мы сутыкнуліся з цікавай асаблівасцю буферных табліц. І вось гэтая праблема ўжо нашмат больш балюча, чым астатнія. Уявім сабе такую сітуацыю: у вас ужо актыўна выкарыстоўваецца «Клікхаўс», у вас дзясяткі сервераў «Клікхаўса», і ў вас ёсць некаторыя запыты, якія чытаюць вельмі доўга (дапусцім, больш за 60 секунд); і вы такія прыходзьце і робіце Alter у гэты момант… А пакуль "селекты", якія пачаліся да "Альтэра", у гэтую табліцу не ўвойдуць, "Альтэр" не пачнецца - верагодна, нейкія асаблівасці таго, як працуе "Клікхаус" у гэтым месцы. Можа, гэта можна выправіць? Ці нельга?
Увогуле, зразумела, што насамрэч гэта не такая ўжо вялікая праблема, але з буфернымі табліцамі яна становіцца балючай. Таму што, калі, дапусцім, у вас «Альтэр» таймаўціцца (прычым затаймаўціцца можа на іншым хасце – не на вашым, а на рэпліцы, напрыклад), то… Вы такія выдалілі буферную табліцу, у вас затаймаўціўся «Альтэр» (ці якая- то памылка "Альтэра" адбылася) - трэба ж, каб усёткі дадзеныя працягвалі пісацца: вы ствараеце буферныя табліцы зваротна (па той жа схеме, што была ў бацькоўскай табліцы), потым "Альтэр" праходзіць, усёткі завяршаецца, і буферная табліца пачынае адрознівацца па схеме ад бацькоўскай. У залежнасці ад таго, што быў за "Альтэр", можа ўстаўка больш не ісці ў гэтую буферную табліцу - гэта вельмі сумна.
Яшчэ ёсць такая таблічка (можа, хто яе заўважаў) - называецца ў новых версіях "Клікхауса" query_thread_log. Па змаўчанні, у нейкай версіі была адзінка. Вось мы назапасілі 840 запісаў за пару месяцаў (100 гігабайт). Звязана гэта з тым, што туды пісаліся (можа, зараз, дарэчы, і не пішуцца) "інсерты" (inserts). Як я вам расказваў, у нас «інсерты» маленькія – у нас вельмі шмат «інсертаў» у буферныя табліцы ішло. Зразумела, што гэта адключаецца – гэта я вам проста расказваю, што я бачыў у нас на сэрвэры. Чаму? Гэта яшчэ адзін аргумент супраць таго, каб выкарыстоўваць буферныя табліцы! Споці вельмі сумуе.
А хто ведаў, што гэтага таварыша клічуць Соці? Паднялі рукі супрацоўнікі "ВК". Ну добра.
Аб планах «KitttenHouse»
Звычайна планамі не дзеляцца, так? Раптам вы іх не будзеце выконваць і будзеце выглядаць не вельмі добрае ў чужых вачах. Але я рызыкну! Мы жадаем зрабіць наступнае: буферныя табліцы, як мне здаецца, гэта ўсёткі мыліца і трэба буферызаваць устаўку самім. Але мы ўсё яшчэ не жадаем буферызаваць яе на дыску, таму мы будзем буферызаваць устаўку ў памяці.
Адпаведна, калі робіцца "інсерт", ён ужо не будзе сінхронны - ён будзе ўжо працаваць як буферная табліца, будзе ўстаўляць у бацькоўскую табліцу (ну, калі-небудзь потым) і па асобным канале паведамляць, якія ўстаўкі прайшлі, якія - не.
Чаму нельга пакінуць сінхронную ўстаўку? Яна ж нашмат зручней. Справа ў тым, што, калі ўстаўляеце з 10 тысяч хастоў, тое ўсё добра - у вас з кожнага хаста будзе ліцца па ледзь-ледзь, вы там раз у секунду ўстаўляеце, усё выдатна. Але жадаецца, каб гэтая схема працавала, напрыклад, і з двух машын, каб вы маглі ліць на вялікай хуткасці можа, не выціскаць максімум з Клікхауса , але хоць бы 100 мегабайт у секунду пісаць з адной машыны праз рэверс-проксі гэтая схема павінна маштабавацца і на вялікую колькасць, і на маленькую, таму мы не можам чакаць на кожную ўстаўку па секундзе, таму яна павінна быць асінхроннай. І сапраўды гэтак жа асінхронныя пацверджанні павінны прыходзіць пасля таго, як устаўка здзейснілася. Мы будзем ведаць аб тым, прайшла яна ці не.
Самае галоўнае, што ў гэтай схеме мы сапраўды ведаем, прайшла ўстаўка ці не. Уявіце сабе такую сітуацыю: у вас буферная табліца, вы ў яе нешта запісалі, а потым, дапусцім, табліца перайшла ў read only і спрабуе зафлашыцца буфер. Куды пайдуць дадзеныя? Застануцца ў буферы. Але мы ў гэтым упэўненыя быць не можам - раптам нейкая іншая памылка, з-за якой не застануцца ў буферы дадзеныя ... (Звяртаецца да Аляксею Мілавідаву, "Яндэкс", распрацоўшчык ClickHouse) Ці застануцца? Заўсёды? Аляксей пераконвае нас, што ўсё будзе добра. У нас няма прычын яму не верыць. Але ўсё роўна: калі мы не выкарыстоўваем буферныя табліцы, то і праблем з імі сапраўды не будзе. Ствараць у два разы больш табліц таксама няёмка, хоць у прынцыпе вялікіх праблем няма. Гэта плян.
Пагаворым аб чытанні
А зараз давайце пагаворым пра чытанне. Мы тут таксама напісалі свой інструмент. Здавалася б, ну навошта тут пісаць свой інструмент?.. А хто карыстаўся "Табіксам"? Неяк мала людзей падняло рукі... А каго задавальняе прадукцыйнасць "Табікса"? Ну вось, нас не задавальняе, і ён не вельмі зручны для прагляду даных. Для аналітыкі ён падыходзіць нармальна, а проста для прагляду ён яўна не аптымізаваны. Таму я напісаў сваё інтэрфейс.
Ён вельмі просты - ён умее толькі чытаць дадзеныя. Ён не ўмее графікі паказваць, нічога не ўмее. Але ўмее паказваць тое, што нам трэба: напрыклад, якая колькасць радкоў у табліцы, колькі месца яна займае (без разбіўкі па калонках), гэта значыць вельмі базавы інтэрфейс - тое, што нам трэба.
І выглядае ён вельмі падобна на Sequel Pro, але толькі зроблены на твітэраўскім «Бутстрапе», прычым другой версіі. Вы спытаеце: "Юрый, а чаму на другой версіі-то?" Які год? 2018-ы? Увогуле, рабіў я гэта досыць даўно для «Мускуля» (MySQL) і проста памяняў тамака пару радкоў у запытах, і ён стаў працаваць для «Клікхаўса», завошта асобнае дзякуй! Таму што парсер вельмі падобны на "мускулеўскі", і запыты вельмі падобныя - вельмі зручна, асабліва спачатку.
Ну, умее ён фільтраванне табліц, умее паказваць структуру, змесціва табліцы, сартаваць дазваляе, фільтраваць па калонках, паказвае запыт, які атрымаўся ў выніку, affected rows (колькі ў выніку), гэта значыць базавыя рэчы для прагляду дадзеных. Даволі хутка.
Рэдактар таксама ёсць. Я сапраўды паспрабаваў выкрасці рэдактар цалкам з «Табікса», але не змог. Але ўсё ж неяк ён працуе. У прынцыпе, на гэтым усё.
«Клікхаус» падыходзіць для логаў
Я вам хачу сказаць, што «Клікхаўс», нягледзячы на ўсе апісаныя праблемы, вельмі добра падыходзіць для логаў. Ён, самае галоўнае, вырашае нашу праблему - ён вельмі хуткі і дазваляе фільтраваць логі па калонках. У прынцыпе буферныя табліцы паказалі сябе не з лепшага боку, але звычайна ніхто не ведае чаму… Можа, вы зараз больш ведаеце, дзе ў вас будуць праблемы.
TCP? Наогул, у "ВК" прынята выкарыстоўваць UDP. І калі я выкарыстоўваў TCP… Мне, вядома, ніхто не казаў: «Юрый, ну ты што! Нельга, трэба UDP». Аказалася, што TCP не так ужо і страшны. Адзінае, калі ў вас дзясяткі тысяч актыўных злучэнняў, якія ў вас пішуць - трэба крыху акуратней яго рыхтаваць; але можна, і даволі лёгка.
"Кітэнхаўс" і "Лайтхаус" я абяцаў выкласці на HighLoad Siberia, калі ўсе падпішуцца на наш паблік "ВК бэкэнд"... І ведаеце, не ўсе падпісаліся... Я ўжо з вас, вядома, патрабаваць падпісацца на наш паблік не буду. Вас усёткі занадта шмат, хтосьці можа пакрыўдзіцца нават, але ўсё роўна - падпісвайцеся, калі ласка (і я тут павінен такія вочы, як у катка, зрабіць). Вось і . Вялікі дзякуй! Github наш . З «Клікхаўсам» вашыя валасы будуць мяккімі і шаўкавістымі.
вядучы: - Сябры, а цяпер пытанні. Адразу пасля таго, як мы ўручым падзячную грамату і твой даклад на VHS.
Юрый Насрэтдзінаў (далей – ЮН): - А як вы змаглі запісаць мой даклад на VHS, калі ён толькі што скончыўся?
вядучы: - Ты ж таксама не можаш да канца вызначыць, як "Клікхаус" - запрацуе ці не запрацуе! Сябры, 5 хвілін на пытанні!
пытанні
Пытанне з залы (далей - З): - Добры дзень. Дзякуй вялікі за даклад. У мяне два пытанні. Пачну з несур'ёзнага: ці ўплывае колькасць літар t у назве «Кітэнхаўс» на схемах (3, 4, 7…) на задаволенасць коцікаў?
ЮН: - Колькасць чаго?
З: - Літар t. Там тры t, недзе тры t.
ЮН: - Няўжо я гэта не паправіў? Ну, вядома, уплывае! Гэта розныя прадукты - я проста вас падманваў увесь гэты час. Добра, я жартую - не ўплывае. А, вось тут! Не, гэта адно і тое ж, гэта я апячатаўся.
З: - Дзякуй. Другое пытанне сур'ёзнае. Наколькі я разумею, у "Клікхаусе" буферныя табліцы жывуць выключна ў памяці, на дыск не буферызуюцца і, адпаведна, не з'яўляюцца persistent.
ЮН: - Так.
З: - А пры гэтым у вас на кліенце ажыццяўляецца буферызацыя на дыск, што мае на ўвазе некаторую гарантыю дастаўкі гэтых самых логаў. Але на «Клікхаўсе» гэта ніяк не гарантуецца. Патлумачце, як ажыццяўляецца гарантыя, за кошт чаго?.. Вось гэты вось механізм больш падрабязна
ЮН: - Так, тэарэтычна супярэчнасцяў тут няма, таму што вы пры падзенні «Клікхаўса» можаце дэтэктаваць мільёнам розных спосабаў насамрэч. Пры падзенні «Клікхауса» (пры некарэктным завяршэнні) вы можаце, груба кажучы, адмотваць крыху свой лог, які вы запісвалі, і пачынаць з моманту, калі сапраўды ўсё было добра. Дапушчальны, на хвіліну назад адкруціць, гэта значыць лічыцца, што за хвіліну зафлашыў усё.
З: - Гэта значыць «Кітэнхаус» трымае акно даўжэй і ў выпадку падзення ўмее яго распазнаваць і адмотваць?
ЮН: - Але гэта ў тэорыі. На практыцы мы гэтага не робім, і надзейная дастаўка - гэта ад нуля да бясконцасці разоў. Але ў сярэднім адзін. Нас задавальняе, што, калі "Клікхаўс" падае па нейкай прычыне або серверы "рэбутаюць", то мы трошкі губляем. Ва ўсіх астатніх выпадках нічога не будзе адбывацца.
З: - Добры дзень. Мне з самага пачатку здавалася, што сапраўды вы будзеце выкарыстоўваць UDP з самага пачатку даклада. У вас - http, усё такое… І большасць праблем, якія вы апісалі, як я зразумеў, былі выкліканыя менавіта гэтым рашэннем…
ЮН: - Што мы выкарыстоўваем TCP?
З: – Па сутнасці так.
ЮН: - Не.
З: - Менавіта з fasthttp былі ў вас праблемы, са злучэннем у вас былі праблемы. Калі б вы проста выкарыстоўвалі UDP, зэканомілі б сабе час. Ну, былі б праблемы з доўгімі паведамленнямі ці яшчэ нешта…
ЮН: - З чым?
З: – З доўгімі паведамленнямі, паколькі ў MTU можа не ўлезці, яшчэ нешта… Ну, там свае праблемы могуць узнікнуць. Пытанне ў чым: чаму ўсё ж такі не UDP?
ЮН: – Я веру ў тое, што аўтары, якія распрацоўвалі TCP/IP, нашмат разумнейшыя за мяне і ўмеюць лепш мяне рабіць серыялізацыю пакетаў (каб яны ішлі), адначасова рэгуляваць акно адпраўкі, не перагружаць сетку, даваць зваротную сувязь аб тым, што не чытае, не лічачы з таго боку… Усе гэтыя праблемы, на маю думку, былі б і ў UDP, толькі мне прыйшлося б пісаць яшчэ больш кода, чым я ўжо напісаў, каб усё тое ж самае рэалізаваць самому і хутчэй за ўсё дрэнна. Я нават на Сі не вельмі кахаю пісаць, не тое што тамака…
З: - Якраз зручна! Адправіў ok і не чакаеш нічога - у цябе абсалютна асінхронна. Прыйшло назад апавяшчэнне аб тым, што ўсё добра - значыць, прыйшло; не прыйшло - значыць, дрэнна.
ЮН: - Мне трэба і тое і іншае - мне трэба ўмець адпраўляць і з гарантыяй дастаўкі, і без гарантыі дастаўкі. Гэта два розныя сцэнары. Некаторыя логі мне трэба не губляць ці не губляць у межах разумнага.
З: - Не буду адбіраць час. Гэта трэба даўжэй абмяркоўваць. Дзякуй.
вядучы: - У каго ёсць пытанні - ручкі ў неба!
З: - Прывітанне, я - Саша. Дзесьці ў сярэдзіне дакладу з'явілася адчуванне, што можна было, акрамя TCP, выкарыстаць гатовае рашэнне - "Кафку" якую-небудзь.
ЮН: – Ну як… Я ж казаў, што не хачу выкарыстоўваць прамежкавыя серверы, таму што… у «Кафку» — акажацца, што ў нас дзесяць тысяч хастоў; насамрэч у нас больш – дзясяткі тысяч хастоў. З «Кафкай» без якіх-небудзь праксей таксама можа балюча рабіць. Да таго ж, самае галоўнае, яно ўсё роўна дае "latency", дае лішнія хасты, якія трэба мець. А я не хачу іх мець - я хачу…
З: - А ў выніку так і атрымалася ўсё роўна.
ЮН: - Не, ніякіх хастоў няма! Гэта ўсё працуе на хастах «Клікхаўса».
З: - Ну а "Кітэнхаус", ревверс які - ён дзе жыве?
ЮН: – На хасце «Клікхаўса», ён не піша на дыск нічога.
З: - Ну, дапусцім.
вядучы: - Уладкоўвае вас? Можам заробак даваць?
З: - Можна, так. Насамрэч шмат мыліц дзеля таго, каб атрымалася тое ж самае, і вось - папярэдні адказ на тэму TCP супярэчыць, на мой погляд, вось гэтай сітуацыі. Проста такое адчуванне, што можна было ўсё зрабіць на каленцы за значна меншы час.
ЮН: – А яшчэ чаму я не хацеў выкарыстоўваць «Кафку», таму што былі ў чатыку «Клікхаўса» тэлеграмаўскім даволі шмат скаргаў на тое, што, напрыклад, паведамленні з «Кафкі» губляліся. Не з самой "Кафкі", а ў інтэграцыі "Кафкі" і "Клікхаўса"; ці там не канэкцілася нешта. Грубіянска кажучы, трэба было б тады і кліент для «Кафкі» пісаць тады. Я не думаю, што атрымалася б больш простае і больш надзейнае рашэнне.
З: - Скажыце, а чаму якія-небудзь чэргі не спрабавалі або якую-небудзь такую агульную шыну? Раз вы кажаце, што ў вас з асінхронам можна было праз чаргу ганяць самі логі і ў адказ атрымаць таксама асінхронна праз чаргу?
ЮН: - Прапануйце, калі ласка, якія можна было б чэргі выкарыстоўваць?
З: - Любыя, нават без гарантыі, што яны па парадку ідуць. Redis які-небудзь, RMQ…
ЮН: – У мяне ёсць адчуванне, што Redis хутчэй за ўсё не зможа цягнуць такі аб'ём устаўкі нават на адным хасце (у сэнсе на некалькіх серверах), які выцягвае "Клікхаус". Я не магу вам пацвердзіць гэта нейкімі сведчаннямі (я не бэнчмаркал яго), але мне здаецца, што Redis тут - не самае ўдалае рашэнне. У прынцыпе можна разглядаць вось гэтую сістэму як імправізаваную чаргу паведамленняў, але якая заточаная толькі пад «Клікхаўс»
вядучы: - Юры, дзякуй вялікі. Я прапаную на гэтым скончыць пытанні і адказы і сказаць, каму з тых, хто задаў пытанне, мы падорым кніжку.
ЮН: - Я б хацеў падарыць кніжку першаму чалавеку, які задаў пытанне.
вядучы: - Выдатна! Выдатна! Пышна! Дзякуй вялікі!
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з 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! Чытайце аб тым
Крыніца: habr.com