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 вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com