ClickHouse за напреднали потребители в въпроси и отговори

През април инженерите на Авито планираха онлайн срещи с главния разработчик на ClickHouse Алексей Миловидов и Кирил Шваков, Golang разработчик от компанията Integros. Обсъждаха как използваме системата за управление на бази данни и какви проблеми срещаме.

На базата на срещата събрахме статия с отговори от експертите на нашите и зрителските въпроси относно бекъпите, решардинга на данни, външните речници, Golang драйвера и актуализацията на версиите на ClickHouse. Тя може да бъде полезна за разработчиците, които вече активно работят с СУБД на «Яндекс» и се интересуват от нейното настояще и бъдеще. По подразбиране отговорите са на Алексей Миловидов, освен ако не е посочено друго.

Внимание, под катта има много текст. Надяваме се, че съдържанието с въпросите ще ви помогне да се ориентирате.

Съдържание

• ClickHouse постоянно се актуализира, а нашите данни - не. Какво можем да направим по този въпрос?
• Какви са най-добрите практики в момента за резервно копиране на данни от ClickHouse?
• Може ли да се организира контролирано изоставане на репликите в ватовете?
• Какво да правим, ако структурата на таблицата се е променила?
• Какви са най-добрите практики в решардинга на данни в момента?
• В ClickHouse има утилита clickhouse-copier. Можете ли да ни разкажете за нея?
• Имахте пилотен проект, който се наричаше решардинг. Какво стана с него?
• Може ли да обединим всички части на данните преди преместването им на по-бавни дискове?
• Как да преминем към нови версии на ClickHouse, ако нямаме възможност предварително да проверим съвместимостта?
• Kill query трябва да убива заявки, но не го прави. Защо?
• Как да изчислим времето за отговор при четяща натовареност?
• Какво да настроим в ClickHouse, за да има повече данни в кеша?
• Как можем да настроим storage_configuration за съхранение в оперативна памет?
• До колко уникални стойности е ефективен Low Cardinality?
• Какви са най-добрите практики за полнотекстово търсене в таблица с пет милиарда реда?
• Как най-добре да организираме достъпа до ClickHouse за голям брой потребители?
• Може ли да предоставим резултатите от една заявка на десет клиенти?
• Как да подходим към асинхронните операции и материализираните представления?
• В ClickHouse има много логове. Как мога да видя всичко, което се случва с сървъра в момента?
• Как да се отразим на мерджовете, за да не пада сървърът в OOM?
• Как ще протича разработката на Golang драйвера за ClickHouse?
• Външният речник не се зарежда след рестартиране с активирана настройка lazy_load. Какво да правим?
• Как да се справим с факта, че system reload dictionaries не зарежда нито един от многото речници, ако поне един от тях се проваля с грешка?
• Има ли начин да конфигурираме реквизитите в конфигурацията на ClickHouse, но да не ги разкриваме при грешки?
• Бонус: фонове за Zoom от срещите

Ако не искате да четете текста, можете да гледате записа от срещите на нашия YouTube канал. Таймкодове - в първия коментар под видеото.

ClickHouse постоянно се актуализира, а нашите данни не. Какво да правим с това?

ClickHouse постоянно се актуализира, а нашите данни, които са били обработени с optimize final, не се актуализират и остават в резервното копие.

Предполагаме, че имаме някакъв проблем и данните са били загубени. Решихме да се възстановим и установихме, че старите партиции, които са на съхранение в сървърите за резервни копия, много силно се разминават с използваната в момента версия на ClickHouse. Какво да правим в такава ситуация и възможна ли е тя?

Ситуацията, при която възстановявате данни от резервно копие в стар формат, а на новата версия те не се свързват, не е възможна. Следим, за да гарантираме, че форматът на данните в ClickHouse винаги остава обратно съвместим. Това е много по-важно от обратно съвместимост по функционалност, ако поведението на някаква рядко използвана функция се е променило. Данните, които се съхраняват на диска, новата версия на ClickHouse винаги трябва да може да чете. Това е закон.

Какви са най-добрите практики в момента за резервно копиране на данни от ClickHouse?

Как да правим резервни копия с оглед на факта, че имаме операции optimize final, огромна база данни на терабайти и данни, които се актуализират, да кажем, в последните три дни, а по-далеч с тях не се извършват никакви процедури?

Можем да създадем собствено решение и на баше да напишем: събирай така и така тези резервни копия. Може би не е нужно да правим костилки, а велосипедът отдавна е изобретен?

Първо по отношение на най-добрите практики. Моите колеги винаги съветват в отговор на въпроси за резервни копия да напомнят за услугата «Yandex.Cloud», където тази задача вече е решена. Така че, ползвайте я, ако имате такава възможност.

Не съществува пълно решение, което да е на сто процента вградено в ClickHouse за бекъпи. Има някои заготовки, които могат да се използват. За да получите пълно решение, ще трябва или да се поразхождате на ръка, или да направите обвивки под формата на скриптове.

Ще започна с най-простите решения и ще завърша с най-сложните в зависимост от обема на данните и размера на клъстера. Колкото по-голям е клъстерът, толкова по-сложно става решението.

Ако таблицата с данни заема само няколко гигабайта, бекъпът може да се направи по следния начин:

1. Запазете определението на таблиците, т.е. метаданните — show create table.
2. Направете дамп с помощта на клиента на ClickHouse — select * from table в файл. По подразбиране ще получите файл в формат TabSeparated. Ако искате по-ефективно — можете в Native формат.

Ако обемът на данните е по-голям, бекъпът ще отнеме повече време и ще заеме много пространство. Това се нарича логически бекъп, който не е свързан формата на данните ClickHouse. Ако го имате, в краен случай можете да вземете бекъпа и да го заредите в MySQL за възстановяване.

За по-напреднали случаи в ClickHouse е вградена възможност за създаване на снимки на партиции в локалната файлова система. Тази възможност е достъпна под формата на заявка alter table freeze partition. Или просто alter table freeze — това е снимка на цялата таблица.

Снимката ще бъде създадена консистентно за една таблица на един шард, т.е. не е възможно да се създаде консистентна снимка на целия клъстер по този начин. Но за повечето задачи такава необходимост няма, и е достатъчно на всеки шард да изпълните заявката и да получите консистентна снимка. Тя се създава под формата на хардлинкове и затова не заема допълнително пространство. След това копирате тази снимка на бекъп-сървъра или в хранилището, което използвате за бекъпи.

Възстановяването на такъв бекъп е достатъчно лесно. Първо — създавате таблици по наличните определения на таблиците. След това копирате запазените снимки на партициите в Directory-Detached за тези таблици и изпълнявате заявката attach partition. Това решение е напълно подходящо за най-сериозните обеми данни.

Понякога се изисква нещо наистина впечатляващо – в случаите, когато разполагате с десетки или дори стотици терабайти на всеки сървър и стотици сървъри. Има решение, което видях при колеги от „Яндекс.Метрика“. Не бих го препоръчал на всеки – прочетете и сами решете дали е подходящо за вас.

Първо трябва да създадете няколко сървъра с големи дискови модули. След това на тези сървъри да инсталирате няколко сървъра ClickHouse и да ги настроите така, че да работят като още една реплика за същите шарда. И след това да използвате на тези сървъри файловата система или инструмент, който позволява създаването на snapshot-ове. Има два варианта. Първият вариант е LVM snapshot-ове, вторият вариант е ZFS на Linux.

След това всеки ден е необходимо да създавате snapshot, който ще заема известно място. Разбира се, ако данните се променят, с времето обемът на заетото място ще нараства. Този snapshot може да бъде извлечен по всяко време и данните да бъдат възстановени, е такова странно решение. Освен това трябва да ограничите тези реплики в конфигурацията, за да не се опитват да стават лидери.

Може ли да се организира контролирано изоставане на репликите в ватовете?

Тази година планирате да правите вали в ClickHouse. Ще бъде ли възможно да организирате контролирано отставане на репликите? Бихме искали с негова помощ да се предпазим от негативни сценарии с alter-и и други промени.

Може ли да се направят някакви roll back за alter-ите? Например, в съществуващ вал да вземете и да кажете, че до този момент прилагайте промените, а от този момент нататък спирайте да прилагате изменения?

Ако в нашия клъстер дойде команда и го повреди, то имаме условна реплика с отставане от един час, където можем да кажем, че нека я използваме точно в този момент, но последните десет минути изменения в нея да не ги прилагаме?

Първо за контролираното отставане на репликите. Такъв запитване от потребителите имаше, и създадохме issue в GitHub с молба: „Ако на някого това е нужно, сложете лайк, сложете сърце“. Никой не постави, и issue беше затворен. Въпреки това, вече сега може да се получи такава възможност, настройвайки ClickHouse. Истината е, че само от версия 20.3.

ClickHouse постоянно в фоновом режиме выполняет слияние данных — мердж. Когда мердж завершён, определённый набор кусков данных заменяется на более крупный кусок. При этом предыдущие куски данных остаются на диске на некоторое время.

Во-первых, они продолжают храниться до тех пор, пока есть запросы select, которые их используют, чтобы обеспечить неблокирующую работу. Запросы select могут спокойно считывать старые куски.

Во-вторых, есть также временной порог — старые куски данных хранятся на диске восемь минут. Эти восемь минут можно настроить и увеличить до одного дня. Это повлечёт за собой использование дискового пространства: в зависимости от потока данных за последний день объем данных может не просто удвоиться, а увеличиться в пять раз. Но при серьёзной проблеме вы сможете остановить сервер ClickHouse и разобраться со всеми вопросами.

Теперь возникает вопрос, как это защищает от альтеров. Здесь стоит углубиться, потому что в прежних версиях ClickHouse альтер работал так, что просто менял куски данных. Есть кусок данных с некоторыми файлами, и, например, мы выполняем alter drop column. В этом случае столбец физически удаляется из всех кусков.

Однако начиная с версии 20.3 механизм альтеров был полностью изменён, и теперь куски данных всегда иммутабельные. Они не подвергаются изменениям вообще — альтеры теперь работают примерно так же, как мерджи. Вместо изменения куска на месте мы создаём новый. В новом куске файлы, которые не изменились, становятся хардлинками, и если мы удалили какой-то столбец, он просто не будет присутствовать в новом куске. Старый кусок по умолчанию удаляется через восемь минут, и здесь можно настроить параметры, о которых говорилось выше.

То же касается альтеров типа мутаций. Когда вы выполняете alter delete или илиalter update

Какво да правим, ако структурата на таблицата се е променила?

, он не изменяет кусок, а создаёт новый. А затем удаляет старый.

Как восстановить бэкап, который был сделан со старой схемой? И второй вопрос касается сценария со снимками и средствами файловой системы. Подойдёт ли здесь Btrfs вместо ZFS на Linux LVM? attach partition Ако имате партиции с друга структура, ClickHouse ще ви каже, че така не може. Решението е следното. Първо – да създадете временная таблица от тип MergeTree със старата структура, да прикрепите данните там, като използвате attach, и след това да направите запрос alter. След това можете или да копирате или да преместите тези данни и отново да направите attach, или да използвате запрос. alter table move partition.

Сега вторият въпрос – може ли да се използва Btrfs. Първо, ако имате LVM, достатъчни са LVM снимките, а файловата система може да бъде и ext4, това не е от значение. С Btrfs всичко зависи от вашия опит с него. Това е зряла файловая система, но все пак все още има известни съмнения относно това как всичко ще работи на практика в конкретен сценарий. Не бих препоръчал да го използвате, ако нямате Btrfs в продукция.

Какви са най-добрите практики в решардинга на данни в момента?

Въпросът за преразпределението е сложен и многогранен. Можете да отговорите веднага с няколко варианта. Можете да го погледнете от едната страна и да кажете, че в ClickHouse няма вградена възможност за преразпределение. Но се страхувам, че този отговор никого няма да задоволи. Затова можете да го погледнете от другата страна и да кажете, че в ClickHouse има много начини за преразпределение на данните.

Ако свършва мястото в клъстера или той не се справя с натоварването, добавяте нови сървъри. Но тези сървъри по подразбиране са празни, няма данни на тях, няма натоварване. Нужно е да прехвърлите данните, за да станат равномерно разпределени по новия, увеличен в размери, клъстер.

Първият начин, по който можете да го направите, е да копирате част от партициите на новите сървъри с помощта на запрос. alter table fetch partition. Например, имали сте партиции по месеци и копирате първия месец от 2017 год. на нов сървър, после – третия месец копирате на някакъв друг нов сървър. И така правите, докато не стане по-равномерно.

Прехвърлянето може да се извърши само за тези партиции, които не се променят при запис. За свежите партиции записът трябва да бъде изключен, защото тяхното прехвърляне не е атомарно. В противен случай ще получите дубликати или пропуски в данните. Тем не менее, този метод е практичен и работи достатъчно ефективно. По мрежата се предават вече готови компресирани партиции, т.е. данните не се презаписват и не се кодирани отново.

Този метод има един недостатък, който зависи от схемата на шардинг, дали сте се доверили на тази схема на шардинг и какъв е бил вашият ключ за шардинг. Във вашия пример за случая с метриките ключът за шардинг е хеш от пътя. Когато правите select в Разпределената таблица, той отива веднага на всичките шардове на клъстера и извлича данни оттам.

Това означава, че фактически за вас няма значение какви данни са се оказали на кой шард. Най-важното е, че данните по един път се оказват на един шард, а именно кой, няма значение. В този случай преместването на готови партиции е чудесно, защото при запитвания select вие също - независимо от прешардирането, схемата на стойност не има особено значение - ще получавате пълни данни.

Но понякога се случват и по-сложни случаи. Ако на нивото на логиката на приложението заложите на специална схема на шардинг, че този клиент се намира на определен шард, и заявката може да бъде изпратена директно там, а не в Разпределената таблица. Или използвате достатъчно нова версия на ClickHouse и сте активирали настройката optimize skip unused shards. В този случай по време на заявка select изразът в секцията where ще бъде анализиран, и ще бъдат изчислени на кои шардове е необходимо да се отиде според схемата на шардинг. Това работи при условие, че данните са разпределени точно в съответствие с тази схема на шардинг. Ако сте ги преместили ръчно, съответствието може да се промени.

И така, това е начин номер едно. Очаквам вашия отговор, подходящ ли е методът или продължаваме.

Владимир Колобаев, водещ системен администратор в Авито: Алексей, методът, който споменахте, не се вписва много добре, когато трябва да разпределим натоварването, включително и за четене. Можем да вземем партиция, която е месечна и можем предишния месец да пренесем на друга нода, но когато дойде заявка за тези данни, ще натоварваме само нея. А искаме да натоварваме целия клъстер, защото в противен случай, за известно време, всичкото натоварване при четене ще се обработва от два шарда.

Алексей Миловидов: Отговорът тук е странен — да, лошо е, но може и да проработи. Ще обясня как точно. Трябва да се разгледа сценарият на натоварване, който стои зад вашите данни. Ако това са данни за мониторинг, почти със сигурност може да се каже, че подавляващото мнозинство от заявките идва за свежи данни.

Сложили сте нови сървъри, пренесли сте старите партиции, но също така сте променили начина на записване на свежите данни. И свежите данни ще бъдат разпределени по целия клъстер. Така след пет минути заявките за последните пет минути ще натоварят равномерно клъстера, след ден заявките за днешния ден ще натоварят равномерно клъстера. А заявките за предишния месец, за съжаление, ще отидат само на част от сървърите на клъстера.

Но често пъти няма да имате заявки точно за февруари 2019 година. Най-вероятно, ако вече заявките са за 2019 година, те ще бъдат за цялата 2019 година — за голям времеви интервал, а не за някакъв малък диапазон. И такива заявки също ще могат равномерно да натоварят клъстера. Но като цяло вашето наблюдение е съвсем верно, че това е ad hoc решение, което не разпределя данните напълно равномерно.

Имам още няколко точки за отговор на въпроса. Една от тях е как първоначално да направите схемата на шардирование така, че да има по-малко болка от повторното шардирование. Това не е възможно винаги.

Например, имате данни за мониторинг. Данните за мониторинг растат по три причини. Първата — натрупване на исторически данни. Втората — нарастване на трафика. И третата — увеличаване на броя на нещата, които попадат под мониторинг. Появяват се нови микросервизи и метрики, които трябва да се запазят.

Възможно е, че от тях най-голямото нарастване е свързано точно с третата причина — увеличаване на използването на мониторинг. И в този случай трябва да се разгледа характера на натоварването, какви са основните заявки за select. Основните заявки за select, най-вероятно, ще идват от някакво подмножество метрики.

Например, използване на CPU на някакви сървъри от някаква услуга. Получава се, че има известно подмножество ключове, по които извличате тези данни. И самият запит за тези данни е вероятно достатъчно прост и се изпълнява за десетки милисекунди. Използва се за мониторинг услуги, за табла с информация. Надявам се, че правилно разбирам.

Владимир Колобаев: Работата е там, че много често се опираме на исторически данни, тъй като в реално време сравняваме текущото състояние с историческото. И за нас е важно да имаме бърз достъп до голямо количество данни, а ClickHouse се справя отлично с това.

Абсолютно прави сте, повечето запитвания за четене получаваме за последния ден, както и всяка система за мониторинг. Но в същото време натоварването на историческите данни също е доста голямо. То идва основно от системата за предупреждение, която на всеки тридесет секунди проверява ClickHouse: „Дай ми данни за последните шест седмици. А сега ми изгради някаква скользяща средна стойност и нека да сравним текущата стойност с историческата“.

Бих искал да кажа, че за такива много свежи запитвания имаме още една малка таблица, в която съхраняваме данни само за два дни, и основните запитвания отиват в нея. В голямата разпределена таблица изпращаме само големи исторически запитвания.

Алексей Миловидов: За съжаление, за вашия сценарий не е приложимо, но ще ви разкажа за две лоши и сложни схеми на шардирование, които не трябва да се използват, но които се използват в услугата на моите приятели.

Има основен клъстер със събития от „Яндекс.Метрика“. Събитията са прегледи на страници, кликвания и преходи. Повечето запитвания отиват към конкретен уебсайт. Вие отваряте услугата „Яндекс.Метрика“, имате сайт — avito.ru, влизате в отчета и се извършва запитване за вашия сайт.

Но има и други запитвания — аналитични и глобални, които правят вътрешни анализатори. За всеки случай ще отбележа, че вътрешните анализатори правят запитвания само по услугите на „Яндекс“. Въпреки това дори услугите на „Яндекс“ заемат значителна част от всички данни. Това са запитвания не по конкретни метрики, а по по-широка филтрация.

Как да организираме данните така, че да работят ефективно както на един измервател, така и за глобални запитвания? Проблемът е, че броят на запитванията в ClickHouse на клъстера 'Метрики' достига хиляди в секунда. При това, нестандартни запитвания, например, хиляди в секунда, един сървър ClickHouse не може да обработи.

Размерът на клъстера е около шестстотин сървъра. Ако просто натоварим този клъстер с разпределена таблица и изпращаме хиляди запитвания, ще стане дори по-лошо, отколкото да ги изпращаме на един сървър. От друга страна, вариантът, при който данните са равномерно разпределени и ние правим запитвания от всички сървъри, веднага се отхвърля.

Съществува диаметрално противоположен вариант. Представете си, ако данните бъдат шардированы по сайтовете, и запитването за един сайт отива на един шард. Сега клъстерът спокойно може да издържи десет хиляди запитвания в секунда, но на един шард определено запитване ще се изпълнява твърде бавно. То вече няма да може да се мащабира по пропускната способност. Особено ако това е сайт avito.ru. Няма да разкрия тайна, ако кажа, че Авито е един от най-посещаваните сайтове в Рунета. И да го обработваме на един шард би било нонсенс.

Затова схемата за шардироване е организирана по по-уместен начин. Целият клъстер е разделен на няколко клъстера, които наричаме слоеве. Вътре в всеки клъстер има от десет до няколко десетки шара. А общо такива клъстера са тридесет и девет.

Как всичко това се мащабира? Броят на кластерите не се променя – остана тридесет и девет, както беше преди няколко години. Но вътре в тях постепенно увеличаваме броя на шардовете в зависимост от натрупаните данни. И основната схема на шардироване е такава – разпределението на тези клъстери става по уебсайтове, и за да разберем кой сайт е на кой клъстер, се използва отделна метабаза в MySQL. Един сайт – на един клъстер. А вътре в него шардироването става по идентификаторите на посетителите.

При записването ги разделяме според остатъка от делението на идентификатора на посетителя. Но при добавянето на нов шард схемата за шардизиране се променя, продължаваме да разделяме, но при остатъка от делението на друго число. Това означава, че един посетител всъщност може да бъде разположен на няколко сървъра, и не може да се разчита на това. Това е направено изцяло с цел данните да се компресират по-добре. А при заявките отиваме в Distributed таблицата, която проверява клъстера и се свързва с десетки сървъри. Ето такава объркваща схема.

Но разказът ми ще бъде непълен, ако не спомена, че се отказахме от тази схема. В новата схема всичко променихме и всички данни копирахме с помощта на clickhouse-copier.

В новата схема всички сайтове се делят на две категории - големи и малки. Не знам как е определен прагът, но в крайна сметка големите сайтове се записват на един клъстер, където има 120 шарда с по три реплики на всеки - тоест 360 сървъра. И схемата на шардизиране е такава, че всяка заявка отива веднага на всички шардове. Ако в момента отворите в "Яндекс.Метрика" всяка страница на отчета за avito.ru, заявката ще отиде на 120 сървъра. Големите сайтове в руския интернет са малко. И заявките не са хиляда в секунда, а дори по-малко от сто. Всичко това спокойно обработва Distributed таблицата, която всеки от тях обработва с 120 сървъра.

А вторият клъстер е за малките сайтове. Тук схемата на шардизиране е по идентификатора на сайта, и всяка заявка отива точно на един шард.

В ClickHouse има утилита clickhouse-copier. Можете ли да ни разкажете за нея?

Веднага ще кажа, че това решение е по-обемно и малко по-малко производително. Предимството е, че то разпределя данните напълно според схемата, която указвате. Но недостатъкът на инструмента е, че той не извършва перешардизиране. Той копира данните от едната схема на клъстера в другата схема на клъстера.

Това означава, че за работата му трябва да имате два клъстера. Те могат да бъдат разположени на едни и същи сървъри, но въпреки това, данните няма да се преместват инкрементално, а ще бъдат копирани.

Например, ако имате четири сървъра, след това стават осем. Създавате ново разпределено таблично пространство на всички сървъри, нови локални таблици и стартирате clickhouse-copier, в който указвате схемата на работа, за да чете оттам, да приеме новата схема на шардове и да прехвърля данните натам. И на старите сървъри ще ви трябва място, 1.5 пъти повече, отколкото имате в момента, защото старите данни трябва да останат там, и отгоре на тях ще дойде половината от същите тези стари данни. Ако предварително сте помислили, че данните трябва да бъдат преразпределени и подредени, тогава този метод е подходящ.

Как функционира clickhouse-copier отвътре? Той разделя цялата работа на набор от задачи за обработка на една партиция от една таблица на един шард. Всички тези задачи могат да се изпълняват паралелно, и clickhouse-copier може да бъде стартиран на различни машини в няколко екземпляра, но това, което прави за една партиция, всъщност е просто insert select. Данните се четат, разархивират, преразпределят, след това отново се архивират, записват някъде и сортират наново. Това е по-тежко решение.

Имахте пилотен проект, който се наричаше решардинг. Какво стана с него?

Вие имахте още през 2017 година пилотен проект, който се наричаше решардинг. Има дори опция в ClickHouse. Разбирам, че това не избухна. Можете ли да кажете защо се получи така? Изглежда много актуално.

Цялата работа е в това, че при необходимост от преразпределение на данните на място се изисква доста сложна синхронизация, за да се направи това атомарно. Когато започнахме да изследваме как е устроена тази синхронизация, стана ясно, че има фундаментални проблеми. И тези фундаментални проблеми не са само теоретични, а веднага започнаха да се проявяват на практика под формата, която може да се обясни много просто — нищо не работи.

Може ли да обединим всички части на данните преди преместването им на по-бавни дискове?

Въпрос за TTL с опцията move to slow disk в контекста на сливанията. Има ли начин, освен чрез cron, да се слеят всички части в една преди прехвърлянето на бавни дискове?

Отговорът на въпроса, дали по някакъв начин може автоматично да се слеят всички части в една преди прехвърлянето им — не. Смятам, че в това няма нужда. Не е необходимо да се сливат всички части в една, а просто да се разчита, че те ще бъдат прехвърлени на бавни дискове автоматично.

Имаме два критерия за прехвърляне. Първият - според запълняемостта. Ако на текущото ниво на хранилището има по-малко от определен процент свободно пространство, избираме един сегмент и го прехвърляме на по-бавно хранилище. По-точно, не на по-бавно, а на следващото - както сте настроили.

Вторият критерий - според размера. Той касае прехвърляне на големи сегменти. Можете да настроите прага за свободно място на бързия диск, и данните ще се прехвърлят автоматично.

Как да преминем към нови версии на ClickHouse, ако нямаме възможност предварително да проверим съвместимостта?

Тази тема се обсъжда редовно в телеграм чата ClickHouse с оглед на различни версии, и все пак. Колко безопасно е да се актуализирате от версия 19.11 на 19.16 и, например, от 19.16 на 20.3? Как е най-добре да преминете на нови версии, без да имате възможност предварително да проверите съвместимостта в тестова среда?

Тук има няколко „златни“ правила. Първото - прочетете changelog. Той е голям, но там има отделни точки за обратно несъвместими промени. Не трябва да се отнасяте към тези точки като към червен флаг. Обикновено това са малки несъвместимости, свързани с някаква краен функционалност, която вероятно не използвате.

Второто - ако нямате възможност да проверите съвместимостта в тестова среда и искате да се актуализирате веднага в продукцията, препоръката е такава - не го правете. Първо създайте тестова среда и проверете. Ако нямате тестова среда, вероятно не сте много голяма компания, и следователно можете да копирате част от данните на лаптопа си и на него да се уверите, че всичко работи коректно. Можете дори да инсталирате няколко реплики локално на машината си. Или можете някъде наблизо да инсталирате новата версия и да качите там част от данните - т.е. да създадете импровизирана тестова среда.

Още едно правило - не се актуализирайте в рамките на седмица след излизането на версията по причина за отстраняване на грешки в продукцията и последващите бързи фиксове. Нека разгледаме нумерацията на версиите на ClickHouse, за да не се объркаме.

Има версия 20.3.4. Числото 20 означава годината на издаване — 2020. От гледна точка на вътрешното съдържание, това няма значение, така че няма да му обръщаме внимание. Следващото — 20.3. Втората цифра — в този случай 3 — я увеличаваме всеки път, когато пускаме нова версия с нова функционалност. Ако искаме да добавим някаква възможност в ClickHouse, сме задължени да увеличим това число. Тоест в версия 20.4 ClickHouse ще работи още по-добре. Третата цифра — 20.3.4. Тук 4 е броят на патч-релизите, в които не сме добавили нови функционалности, но сме коригирали някакви бъгове. А 4 означава, че сме го направили четири пъти.

Не трябва да мислите, че това е нещо ужасно. Обикновено потребителят може да инсталира най-новата версия и тя ще работи без проблеми с ъптайм от година. Но представете си, че в някаква функция за обработка на битмапи, която са добавили нашите китайски партньори, при предаване на неправилни аргументи сървърът пада. Ние сме длъжни да го поправим. Ще пуснем нова патч-версия и ClickHouse ще стане по-стабилен.

Ако ClickHouse работи в продукция и излиза нова версия ClickHouse с допълнителни функции — например, 20.4.1 — не бързайте да я инсталирате в продукция в първия ден. Каква е нуждата от нея? Ако все още не използвате ClickHouse, можете да я инсталирате и вероятно всичко ще бъде наред. Но ако ClickHouse вече работи стабилно, следете за патчове и актуализации — какви проблеми поправяме.

Кирил Шваков: Искам да добавя малко за тестовите среди. Всички много се страхуват от тестовите среди и по някаква причина считат, че ако имате много голям кластер ClickHouse, тестовата среда също трябва да бъде не по-малка или поне десет пъти по-малка. Това съвсем не е така.

Мога да кажа от собствения си опит. Имам проект и там имам ClickHouse. Наша тестова среда именно за него е малка виртуална машина в Hetzner за двадесет евро, където абсолютно всичко е разгръщано. За да го направим, имаме пълна автоматизация в Ansible и затова в принципе няма разлика къде да разгръщаме — на физически сървъри или просто да се развием в виртуалки.

Какво може да се направи? Щеше да е добре да се направи в документацията на ClickHouse пример как да се разгрее малък кластер при себе си – в Docker, в LXC, а може би да се създаде Ansible playbook, защото различните хора имат различни деплойки. Това би опростило много. Когато за пет минути разгръщаш кластер, е много по-лесно да се опиташ да разбереш нещо. Така е много по-удобно, тъй като да прехвърлиш в продукционна версия, която не си проверил – е пътят към нищото. Понякога работи, а понякога не. И затова да се надяваш на успех – е лошо.

Максим Котяков, старши бекенд инженер в Авито: Някъде ще добавя относно тестовите среди от серията проблеми на големите компании. Имаме пълноценен приёмъчен кластер ClickHouse, който е точна копия на данните и настройките на продукцията. Този кластер е разгряян в доста износени контейнери с минимум ресурси. Пишем там някакъв процент от продукционните данни, за щастие имаме възможност да репликираме потока в Kafka. Там всичко е синхронизирано и разширено – и по мощност, и по поток, и, теоретично, при равни условия, трябва да се държи като продукция. Всичко потенциално експлозивно първо преминава на този стенд и там настоява няколко дни до готовност. Но естествено, това решение е скъпо, сложно и с ненулеви разходи за поддръжка.

Алексей Миловидов: Ще разкажа какво представлява тестовата среда на нашите приятели от «Яндекс.Метрика». Един кластер беше с 600 и нещо сървъра, другият с 360, а освен това има и трети и няколко клъстера. Тестовата среда за един от тях е просто два шарда с две реплики в всеки. Защо два шарда? За да не бъде само един. И също така репликите да са налични. Просто минималното количество, което можем да си позволим.

Тази тестова среда позволява да се провери работоспособността на запитванията и дали не е счупено нещо сериозно. Но често проблемите възникват от съвсем друг характер, когато всичко работи, но има някои малки изменения с натоварването.

Ще дам пример. Решихме да инсталираме нова версия на ClickHouse. Тя е разположена в тестовата среда, преминали са автоматизирани тестове в самата «Яндекс.Метрика», които сравняват данните на старата версия и на новата, като пускат целия конвейер. И разбира се, зелени тестове на нашия CI. В противен случай дори нямаше да предложим тази версия.

Всичко е прекрасно. Започваме да пускаме в продукция. Получавам съобщение, че натоварването на графиците е нараснало няколко пъти. Връщаме версията. Поглеждам графика и виждам: натоварването наистина се е увеличило няколко пъти по време на пускането и след това отново намаля, когато версията беше изтеглена. След това започнахме да връщаме версията. И натоварването също така се увеличи и също така обратно падна. Изводът е, че натоварването се е увеличило във връзка с пускането, нищо странно.

После беше трудно да убедя колегите все пак да инсталират новата версия. Казвам: „Всичко е наред, пускайте. Дръжте палци, всичко ще бъде наред. В момента натоварването на графиците е нараснало, но всичко е наред. Дръжте се.” В крайна сметка, така направихме и всичко — версията е пусната на продукция. Но почти при всяко пускане възникват подобни проблеми.

Kill query трябва да убива заявки, но не го прави. Защо?

При мен дойде потребител, някакъв анализатор, и създаде запитване, което закова моят кластер ClickHouse. Някоя нода или кластерът като цяло — в зависимост от това в каква реплика или шард запитването е попаднало. Виждам, че всички ресурси по CPU на този сървър са на максимум, всичко е червено. Въпреки това самият ClickHouse отговаря на запитванията. И пиша: „Покажи ми, моля, списъка с процеси, кое запитване предизвика това безумие.”

Намирам това запитване и му пиша да убие. И виждам, че нищо не се случва. Моят сървър е на максимум, ClickHouse продължава да ми издава някакви команди, показва, че сървърът е жив и всичко е наред. Но имам деградация във всички потребителски запитвания, започва деградация по записа в ClickHouse и моят kill query не сработва. Защо? Мислех, че kill query трябва да убива запитвания, а това не се случва.

Сега ще дам доста странен отговор. Работата е там, че kill query не убива запитвания.

Kill query поставя малък флаг с надпис „искам това запитване да бъде убито”. А самото запитване при обработка на всеки блок проверява този флаг. Ако той е зададен, запитването спира да работи. Получава се, че никой не убива запитването, то само трябва да провери всичко и да спре. И това трябва да работи във всички случаи, когато запитването е в състояние на обработка на блокове данни. То обработва следващия блок данни, проверява флага и спира.

Това не работи в случаи, когато заявката е блокирана за някаква операция. Вероятно, това не е вашият случай, тъй като, според вашите думи, той използва много ресурси на сървъра. Може би не работи при външно сортиране и в някои други детайли. Но като цяло не трябва да бъде така, това е бъг. Единственото, което мога да ви посъветвам, е да обновите ClickHouse.

Как да изчислим времето за отговор при четящо натоварване?

Има таблица, в която се съхраняват агрегати по item — различни броячи. Броят на редовете е около сто милиона. Може ли да се разчита на предсказуемо време за отговор, ако се налеят 1K RPS по 1K item’а?

Судя по контекста, става въпрос за четящо натоварване, тъй като при запис няма проблеми — можете да добавяте хиляди, стотици хиляди, а понякога и няколко милиона реда.

Четящите заявки могат да бъдат много различни. В select 1 ClickHouse може да изпълнява около десетки хиляди заявки в секунда, така че дори заявки по един ключ ще изискват известни ресурси. И такива точкови заявки ще бъдат по-сложни, отколкото в някакви key-value бази данни, тъй като при всяко четене е необходимо да се прочете блок от данни по индекса. Индексът адресира не всяка записа, а всеки диапазон. Тоест ще трябва да се прочете целият диапазон — това е 8192 реда по подразбиране. И ще трябва да разархивирате компресирания блок данни от 64 Kб до 1 Mb. Обикновено такива точкови заявки отнемат от няколко милисекунди. Но това е най-простият вариант.

Нека опитаме да направим проста аритметика. Ако умножим няколко милисекунди по хиляда, получаваме няколко секунди. Все едно, че не можем да поддържаме хиляда заявки в секунда, но всъщност можем, тъй като имаме няколко процесорни ядра. Така че в принцип 1000 RPS ClickHouse понякога може да поддържа, но на къси заявки, именно точкови.

Ако трябва да мащабирате кластера ClickHouse по брой обикновени заявки, препоръчвам най-простото — да увеличите броя на репликите и да изпращате заявки на произволна реплика. Ако една реплика поддържа петстотин заявки в секунда, което е напълно реалистично, тогава три реплики ще поддържат хиляда и петстотин.

Понякога, разбира се, е възможно да настроите ClickHouse за максимален брой точкови четения. Какво е необходимо за това? Първо - трябва да намалите гранулираността на индекса. При това, намаляването не трябва да е до единица, а с разчет, че броят на записите в индекса ще бъде няколко милиона или десетки милиони на сървъра. Ако в таблицата има сто милиона реда, то за гранулираност може да се зададе 64.

Може да се намали размерът на компресирания блок. За това има настройки min compress block size, max compress block size. Те могат да бъдат намалени, данните да бъдат пренесени и тогава точковите запитвания ще бъдат по-бързи. Но все пак ClickHouse не е база данни key-value. Голямото количество малки запитвания е антипатерн на натоварването.

Кирил Шваков: Ще дам съвет в случай, че там има обикновени акаунти. Това е доста стандартна ситуация, когато в ClickHouse се съхранява някакъв брояч. Имам потребител, той е от такава страна, има още едно трето поле и е необходимо инкрементно да се увеличава нещо. Вземете MySQL, направете уникален ключ - в MySQL той е duplicate key, а в PostgreSQL е conflict - и добавете с плюс. Това ще работи значително по-добре.

Когато имате малко данни, няма особена смисъл да използвате ClickHouse. Има обикновени бази данни и те се справят добре с това.

Какво да настроим в ClickHouse, за да имаме повече данни в кеша?

Представете си ситуация - на сървърите има 256 ГБ RAM, в ежедневната рутина ClickHouse взема около 60-80 ГБ, в пикови моменти - до 130. Какво може да се включи и настрои, за да има повече данни в кеша и, съответно, да има по-малко обаждания към диска?

Обикновено page cache на операционната система добре се справя с тази задача. Ако отворите просто top, погледнете там cached или free - там също е написано колко е кеширано - тогава можете да забележите, че всяка свободна памет е използвана за кеш. И тези данни при четене ще се четат не от диска, а от оперативната памет. При това мога да кажа, че кешът се използва ефективно, защото се кешират именно компресирани данни.

Все пак, ако искате да ускорите някои прости запитвания още повече, има възможност да включите кеширане вътре в ClickHouse за разкомпресирани данни. Това се нарича uncompressed cache. В конфигурационния файл config.xml задавате размера на uncompressed cache до желаната стойност — препоръчвам не повече от половината от свободната оперативна памет, тъй като остатъкът отива за page cache.

Освен това, има две настройки на ниво заявка. Първата настройка — use uncompressed cache — активира използването му. Препоръчва се да бъде включен за всички заявки, с изключение на тежките, които могат да прочетат всички данни и да изчистят този кеш. И втората настройка — нещо като максимален брой редове за използване на кеша. Тя автоматично ограничава големите заявки, така че те да заобикалят кеша.

Как можем да настроим storage_configuration за съхранение в оперативна памет?

В новата документация на ClickHouse прочетох раздел, свързан с data storage. В описанието има пример с бърз SSD.

Интересно е как може да се конфигурира същото с volume hot memory. И още един въпрос. Как работи select с такава организация на данните, ще чете ли целия набор или само този, който е на диска, и компресират ли се тези данни в паметта? И как работи секцията prewhere в такава организация на данните?

Тази настройка влияе на съхранението на парчетата данни и форматът им не се променя.
Нека разгледаме по-подробно.

Може да се настрои съхранението на данни в оперативната памет. Всичко, което се конфигурира за диска, е неговият път. Създавате tmpfs дял, който е монтиран на определен път в файловата система. Посочвате този път като път за съхранение на данни за самия горещ дял, където започват да постъпват и се записват парчета данни, всичко е наред.

Но не препоръчвам да се прави така поради ниска надеждност, въпреки че, ако имате минимум три реплики в различни дата центрове, е възможно. В случай на проблем, данните ще бъдат възстановени. Да предположим, че сървърът внезапно спре и след това се включи отново. Дялът отново е монтиран, но там е пусто. Сървърът на ClickHouse при стартиране вижда, че тези парчета липсват, въпреки че според метаданните в ZooKeeper те трябва да са налични. Той проверява на кои реплики ги има, запитва ги и ги сваля. По този начин данните ще бъдат възстановени.

В това отношение съхранението на данни в оперативната памет принципно не се различава от съхранението им на диск, защото при запис на данни на диска те също първо попадават в page cache и физически се записват отложено. Това зависи от варианта на монтиране на файловата система. Но все пак ще кажа, че ClickHouse не прави fsync при insert.

Данните в оперативната памет се съхраняват в точно такъв формат, какъвто е и на диска. Запитването select избира точно така, както е необходимо, парчета от данни, и чете необходимите диапазони. И prewhere работи абсолютно по същия начин, независимо от това дали данните са в оперативната памет или на диска.

До колко уникални стойности е ефективен Low Cardinality?

Low Cardinality е хитро устроен. Той съставя локални речници на данни. На първо място, речниците са свои за всеки фрагмент, а на второ място, дори в рамките на един фрагмент те могат да бъдат различни за всеки диапазон. Когато броят на уникалните стойности достигне прагова стойност — мисля, че един милион — речникът просто се отлага и се създава нов.

Отговорът е в общи линии следният: за всеки локален диапазон — да кажем, за всеки ден — до около милион уникални стойности Low Cardinality е ефективен. След това ще има просто fallback, при който ще се използват много различни речници, а не един. Работата ще бъде приблизително същата, като обикновен стълбец от тип string, може би малко по-малко ефективна, но сериозно понижаване на производителността няма да настъпи.

Какви са най-добрите практики за полнотекстово търсене в таблица с пет милиарда реда?

Има различни варианти на отговор. Първият — да се каже, че ClickHouse не е система за пълнотекстово търсене. За това съществуват специализирани системи например, Elasticsearch и Sphinx. Въпреки това, все по-често срещам хора, които казват, че преминават от Elasticsearch на ClickHouse.

Защо се случва това? Те обясняват, че Elasticsearch спира да справя с натоварването на определени обеми, особено що се отнася до изграждането на индекси. Индексите стават твърде обемисти, и ако просто се прехвърлят данните в ClickHouse, те се съхраняват много по-ефективно по обем. Междувременно запитванията често не са такива, че да е необходимо да се намери в целия обем данни някаква фраза, отчитане на морфологията, а съвсем различни. Например, да се намерят в логовете за последните няколко часа по някаква подпоследователност от байтове.

В този случай в ClickHouse създавате индекс, чийто първо поле е дата с време. Най-голямото отсяване на данни ще бъде именно по диапазона на датите. В рамките на избрания диапазон на датите обикновено може да се извърши и пълнотекстово търсене дори с брутфорс метод с помощта на like. Операторът like в ClickHouse е най-ефективният оператор, който можете да намерите. Ако намерите по-добър, кажете ми.

Но все пак like е full scan. И full scan може да бъде бавен не само по CPU, но и по диск. Ако случайно имате един терабайт данни на ден и търсите някаква дума за един ден, ще трябва да сканирате терабайт. А той със сигурност е на обикновени твърди дискове, и в крайна сметка те ще бъдат натоварени до такава степен, че няма да можете да влезете в сървъра по SSH.

В този случай съм готов да предложа още един малък трик. Той е от експерименталната категория – може да сработи, а може и не. В ClickHouse има пълнотекстови индекси под формата на триграмни Блум-филтри. Нашите колеги от компанията Arenadata вече са изпробвали тези индекси и често те работят точно както е предвидено.

За да ги използвате правилно, трябва да разбирате добре как точно работят: какво е триграмният Блум-филтър и как да изберете неговия размер. Мога да кажа, че те ще помогнат за заявките по някакви редки фрази, подстрингове, които рядко се срещат в данните. В този случай по индексите ще бъдат избрани поддиапазони и ще се прочетат по-малко данни.

Напоследък в ClickHouse се появиха още по-усъвършенствани функции за пълнотекстово търсене. Това е, на първо място, търсене на куп подстрингове на един проход, включително варианти с оглед на регистъра, без оглед на регистъра, с поддръжка на UTF-8 или само за ASCII. Изберете най-ефективния, от който се нуждаете.

Също така се появи търсене на няколко регулярни израза на един проход. Не е нужно да пишете X like един подстринг or X like друг подстринг. Просто пишете наведнъж и всичко се изпълнява максимално ефективно.

Трето – сега има приближено търсене на регекспи и приближено търсене на подстрингове. Ако някой е написал дума с печатна грешка, тя ще бъде търсена по максимално сходство.

Как най-добре да организираме достъпа до ClickHouse за голям брой потребители?

Кажете как да организирате достъпа за голям брой потребители и анализатори. Как да се формира опашка, да се приоритизират заявките за max concurrent queries и с какви инструменти?

Ако клъстерът е достатъчно голям, то добро решение би било да се създадат още два сървъра, които да станат точка за вход за анализаторите. Тоест, да не се допуска анализаторите до конкретни шардове на клъстера, а просто да се създадат два празни сървъра, без данни, и на тях вече да се настроят права за достъп. При това настройките на потребителите при разпределени заявки се предават на отдалечените сървъри. Тоест, настройвате всичко на тези два сървъра и настройките имат ефект на целия клъстер.

В принципе, тези сървъри са без данни, но обемът на оперативната памет на тях е доста важен за изпълнението на заявките. Дискът също може да се използва за временни данни, ако е активирана външната агрегация или външното сортиране.

Важно е да се погледне на настройките, свързани с всички възможни лимити. Ако сега вляза в клъстера „Яндекс.Метрика“ като анализатор и дам заявка select count from hits, веднага ще получа изключение, че не мога да изпълня заявката. Максималното количество редове, които им е разрешено да сканират, е сто милиарда, а общо в клъстера има петдесет трилиона в една таблица. Това е първото ограничение.

Да предположим, че махам ограничението за брой редове и изпълнявам заявката отново. Тогава ще видя следното изключение – включена е настройката force index by date. Не мога да изпълня заявката, ако не съм указал диапазон от дати. Не трябва да разчитате, че анализаторите ще го задават ръчно. Типичен случай – написан е диапазон от дати where event date between неделя. А после просто не е там указана скобата, и вместо and е получил or – or URL match. Ако ограничението няма, то ще сканира колоната URL и просто ще похарчи тонна ресурси.

Освен това, в ClickHouse има две настройки за приоритети. За съжаление, те са много примитивни. Едната се нарича просто priority. Ако priority ≠ 0 и се изпълняват заявки с някакъв приоритет, но в същото време се изпълнява заявка с приоритет, който има по-ниска стойност, означаваща по-висок приоритет, то заявката с по-висока стойност, означаваща по-нисък приоритет, просто се спира и изобщо не работи през това време.

Това е много груба настройка и не е подходяща за случаи, когато на клъстера има постоянна натовареност. Но ако имате кратки, импулсивни важни заявки, а основно клъстерът е в покой, такава настройка ще е подходяща.

Следващата настройка на приоритетите се нарича приоритет на потока на ОС. Тя просто задава за всички потоци при изпълнение на заявката стойност nice за шедулера на Linux. Работи си така-така, но все пак работи. Ако зададете най-ниската стойност nice — най-високата по стойност, и означава най-нисък приоритет — а за заявките с висок приоритет зададете -19, то CPU ще консумира нископриоритетни заявки приблизително четири пъти по-малко, отколкото високоприоритетни.

Също така трябва да настроите максималното време за изпълнение на заявка — да кажем, пет минути. Минималната скорост за изпълнение на заявка — това е най-якото. Тази настройка е налична отдавна и е необходима, за да не просто твърдим, че ClickHouse не забавя, а за да го принудим.

Представете си, че настройвате: ако някоя заявка обработва по-малко от един милион реда в секунду — така не може. Това опетнява доброто ни име, нашата добра база данни. Нека просто да го забраним. Всъщност там има две настройки. Едната се нарича минимална скорост на изпълнение — в редове в секунда, а другата се нарича тайм-аут преди проверка за минимална скорост на изпълнение — по подразбиране петнадесет секунди. Тоест петнадесет секунди е позволено, а след това, ако е бавно, просто да изхвърлите изключение — да прекратите заявката.

Също така трябва да настроите квоти. В ClickHouse има вградена функция за квоти, която отчита потреблението на ресурси. Но, за съжаление, не на железни ресурси като CPU, дискове, а логически — количество обработени заявки, редове и прочетени байтове. И можете да настроите, например, максимум сто заявки в течениe на пет минути и хиляда заявки на час.

Защо е важно? Защото част от заявките за анализ ще бъдат изпълнявани ръчно директно от клиента на ClickHouse. И всичко ще бъде наред. Но ако във вашата компания има напреднали анализатори, те ще напишат скрипт, а в скрипта може да се допусне грешка. Тази грешка може да доведе до безкраен цикъл на изпълнение на заявката. Трябва да се защитим от това.

Може ли да предоставим резултатите от една заявка на десет клиенти?

Имаме няколко потребители, които обичат да идват с много големи заявки в един и същи момент. Заявката е голяма, изпълнява се бързо, но тъй като такива заявки са много на брой едновременно, става много болезнено. Може ли същата заявка, която идва десет пъти подред, да бъде изпълнена само веднъж, а резултатът да бъде предоставен на десетте клиента?

Проблемът е, че нямаме кеш на резултатите или кеш на междинните данни. Има кеш на страниците на операционната система, който позволява да не се четат данните от диска повторно, но за съжаление, данните все пак ще трябва да бъдат разопаковани, десериализирани и обработени повторно.

Би било желателно по някакъв начин да го избегнем, или като кешираме междинните данни, или като подредим подобни заявки в опашка и добавим кеш на резултатите. В момента имаме разработка на един pull request, който добавя кеш за заявки, но само за подзаявки в секцията in и join — т.е. решението не е пълноценно.

Въпреки това, и при нас възниква такава ситуация. Особено класическият пример — това са заявки с пагинация. Има отчет, в него както и много страници, и се изпълнява заявка limit 10. После същото, но limit 10,10. След това още следваща страница. И се пита, защо всеки път изчисляваме всичко това? Но в момента решение няма и няма как да го избегнем.

Има алтернативно решение, което се поставя като сайдкар до ClickHouse — ClickHouse Proxy.

Кирил Шваков: В ClickHouse Proxy има вграден лимитатор на заявките и вграден кеш на резултатите. Там са направени много настройки, защото се решаваше подобна задача. Proxy позволява да се лимитират заявките, подреждайки ги в опашка, и конфигуриране колко дълго време живее кеша на заявките. Ако заявките наистина са идентични, Proxy ще ги предостави много пъти, а ще се свърже с ClickHouse само веднъж.

В Nginx също има кеш в безплатната версия, и това също ще работи. В Nginx дори има настройки, които, ако заявките дойдат едновременно, той ще забави другите, докато едната не бъде изпълнена. Но именно в ClickHouse Proxy настройката е направена много по-добре. Тя е разработена специално за ClickHouse, специално за тези заявки, затова е по-подходяща. И се инсталира лесно.

Как да подходим към асинхронните операции и материализираните представления?

Има такъв проблем, че операциите с реплейсинг-движка са асинхронни - първо се записват данни, след което настъпва тяхното свиване. Ако под таблицата живее материализирана таблица с някакви агрегати, то дубли ще се запишат в нея. И ако няма сложна логика, данните ще бъдат дублирани. Какво може да се направи с това?

Има очевидно решение - да се реализира тригер за определен клас матвюхи при асинхронна операция на свиване. Има ли някакви "сребърни куршуми", планове за реализиране на подобни функционалности?

Струва си да се разгледа как работи дедупликацията. Това, за което ще говоря сега, не се отнася пряко до въпроса, но за всеки случай е добре да се спомена.

При вмъкване в реплицирана таблица има дедупликация на цялостно вмъкнатите блокове. Ако повторно вмъкнете един и същ блок, съдържащ същото количество от същите редове в същия ред, данните се дедуплицират. Ще получите "Ok" в отговор на insert, но всъщност ще бъде записан един пакет данни и той няма да бъде дублиран.

Това е необходимо за определеност. Ако по време на вмъкването получите "Ok", значи данните ви са вмъкнати. Ако получите грешка от ClickHouse, значи те не са вмъкнати и е нужно да повторите вмъкването. Но ако по време на вмъкването връзката е прекъсната, не знаете дали данните са вмъкнати или не. Единственият вариант е да повторите вмъкването отново. Ако данните всъщност са били вмъкнати и вие ги вмъкнете повторно, има дедупликация на блоковете. Тя е необходима за избягване на дубликати.

И е важно как работи за материализирани представления. Ако данните са били дедуплицирани при вмъкване в основната таблица, то в материализираното представление те също няма да отидат.

Сега по отношение на въпроса. Имате по-сложна ситуация, защото записвате дубликати на отделни редове. Тоест не е целия пакет дублиран, а именно конкретни редове, и те в фона се сливат. Наистина, данните ще се слеят в основната таблица, а в материализираното представление ще отидат неслятите, и при обединенията няма да се случи нищо с материализираните представления. Защото материализираното представление е нищо друго освен тригер за insert. При други операции нищо допълнително не се случва с него.

И тук не мога да ви зарадвам. Трябва само да се търси конкретно решение за този случай. Например, може ли в материализираното представление да се направи и неговото заместване, и начинът на дедупликация може би ще работи по същия начин. Но за съжаление, не винаги. Ако е агрегиращо, няма да се получи.

Кирил Шваков: При нас също имаше доста чудатости. Имаше проблем, че има показвания на реклама и има някои данни, които можем да показваме в реално време — просто показвания. Те рядко се дублират, но ако това се случи, все пак ще ги слеем после. И имаше неща, които не можеха да се дублират — кликове и цялата тази история. Но извеждането им искаше веднага.

Как бяха направени материализираните представления? Имаше представления, където записите ставаха директно — записва се в суровите данни и се пише във вижъмите. Там в някой момент данните не бяха много правилни, дублираха се и така нататък. И има втора част от таблицата, където те изглеждат абсолютно по същия начин като материализираните представления, тоест по структура са абсолютно идентични. В определено време преизчисляваме данните, допълваме данните без дубликати, записваме в тези таблици.

Ние се свързвахме през API — в ClickHouse ръчно това няма да работи. И API-то гледа: когато имам дата на последното добавяне в таблицата, където гарантирано вече има правилни данни, изчислени, той прави заявка към една таблица и към друга таблица. От едната заявка избира до определено количество време и от другата взема това, което все още не е изчислено. И това работи, но не със средствата на един ClickHouse.

Ако имате API - за анализатори, за потребителите - това е вариант. Вие винаги можете да изчислявате, винаги можете да преизчислявате. Можете да правите това веднъж на ден или в друго време. Вие сами избирате диапазона, който не е необходим и не е критичен.

ClickHouse съдържа много логове. Как мога да видя всичко, което се случва със сървъра в момента?

В ClickHouse има много различни логове и това количество нараства. В новите версии част от тях дори са включени по подразбиране, докато в старите версии трябва да бъдат активирани при актуализация. Въпреки това, броят им продължава да нараства. Искам в крайна сметка да виждам какво се случва в момента с моя сървър, може би на някакво обобщено табло.

Няма ли в екипа на ClickHouse или в екипите на вашите приятели, които поддържат определен функционал на готови табла, които да показват тези логове като готов продукт? В крайна сметка, просто да гледате логове в ClickHouse е страхотно. Но би било наистина удобно, ако вече се предлагаше под формата на табло. Бих се радвал на това.

Има табла, но те не са стандартизирани. При нас в компанията около 60 екипа използват ClickHouse и най-странното е, че много от тях имат табла, които самите те са направили, и те са малко различни. Някои екипи използват вътрешна инсталация на "Яндекс.Облака". Там има някои готови отчети, макар и не всички необходими. Другите имат свои собствени.

Колегите ми от "Метрики" имат свое табло в Grafana, а аз имам свое по техния клъстер. Там наблюдавам неща като кеш хит за кеша на засечките. И дори е още по-сложно, защото използваме различни инструменти. Моето табло създадох на много стар инструмент, който се нарича Graphite-web. То е напълно неестетично. И така все още го използвам, макар Grafana вероятно да е по-удобна и красива.

Основната информация в таблото за управление е една и съща. Това са системните метрики на кластера: CPU, памет, диск, мрежа. Други метрики включват брой едновременни заявки, брой едновременни обединения, заявки в секунда, максимален брой парчета за партиции на таблиците MergeTree, закъснение на репликацията, размер на опашката за репликация, брой вмъкнати редове в секунда, брой вмъкнати блокове в секунда. Това всичкото идва от метрики, а не от логовете.

Владимир Колобаев: Алексей, искам да направя малко корекции. Има Grafana. Grafana има data source, който е ClickHouse. Тоест мога да правя заявки от Grafana директно към ClickHouse. В ClickHouse има таблица с логове, която е еднаква за всички. Искам в резултат в Grafana да имам достъп до тази таблица с логове и да виждам заявките, които прави моят сървър. Би било страхотно да имам такова табло за управление.

Аз сам го създадох. Но имам един въпрос – ако всичко е стандартизирано и Grafana се използва от всички, защо в "Яндекс" няма такова официално табло за управление?

Кирил Шваков: Всъщност data source, свързан с ClickHouse, сега се поддържа от Altinity. И просто искам да дам насока, където да се копае и кой да се тласне. Може да питате тях, тъй като "Яндекс" все пак разработва ClickHouse, а не исторически събития около него. Altinity е основната компания, която в момента проправя пътя за ClickHouse. Те няма да го оставят на произвола, а ще го поддържат. Защото в принцип, за да качите табло за управление на сайта на Grafana, просто трябва да се регистрирате и да го качите – проблеми на практика няма.

Алексей Миловидов: През последната година в ClickHouse бяха добавени много възможности за профилиране на заявки. Има метрики за всяка заявка по използване на ресурси. Съвсем наскоро беше добавен и по-нискостепенен профайлер на заявките, за да се види къде всяка заявка прекарва всяка милисекунда. Но за да се възползвам от тази функционалност, трябва да отворя конзолния клиент и да напиша заявката, която постоянно забравям. Записал съм я някъде и постоянно забравям къде точно.

Бих искал инструмент, който просто да покаже - ето вашите тежки заявки, групирани по класове на заявки. Натискаме на някоя и ми говорят, че тя е тежка поради това. В момента такова решение няма. И наистина е доста странно, че когато хората ме питат: "Кажете, има ли готови дашбордове за Grafana?", аз казвам: "Отидете на сайта на Grafana, там има общност 'Дашбордове', и там има дашборд от Димка, има дашборд от Костяна. Какво е това, не знам, аз самият не съм го използвал."

Как да повлияя на мерджовете, за да не пада сървърът в OOM?

Имам таблица, в която има само една партиция, тя е ReplacingMergeTree. Пиша в нея данни от четири години. Трябваше да направя алтер и да изтрия някои данни.

Направих го, и по време на обработката на тази заявка се изчерпа цялата памет на всички сървъри в клъстера, и всички сървъри в клъстера дружно паднаха в OOM. После всички те се събраха отново, започнаха да извършват мердж на същата операция, на този блок от данни, и отново паднаха в OOM. След това отново се събраха и отново паднаха. И този цикъл не спираше.

По-късно се оказа, че това всъщност е бъг, който момчетата поправиха. Това е страхотно, благодаря много. Но остави следа. И сега, когато мисля за това, че трябва да направя някакъв мердж в таблицата, имам въпрос - защо не мога по някакъв начин да влияя на тези мерджове? Например, да ги ограничавам по количество необходима оперативна памет или по принцип по количеството, което ще обработва конкретно тази таблица.

Имам таблица, която се нарича 'Метрики', моля те, обработвай я в два потока. Не е нужно да правиш десет или пет мерджове паралелно, направи в два. Смятам, че в два ще имам достатъчно памет, а за десет може да не стигне. Защо остава страхът? Защото таблицата расте, и някога ще се сблъскам със ситуация, в която вече не заради бъг, а заради това, че данните ще се променят в такова голямо количество, че просто няма да имам достатъчно памет на сървера. И тогава сървърът ще пада в OOM при мердж. Освен това мутацията мога да отменя, но мерджовете не.

Знаете ли, при слияниях съедаемая оперативная память не будет превышать минимальный объем, поскольку используется только для небольшого диапазона данных. Так что все будет в порядке независимо от объема данных.

Владимир Колобаев: Хорошо. Тут такой момент, что после фикса ошибки я скачал новую версию и на другой, более маленькой таблице с множеством партиций сделал такую же операцию. В процессе слияния на сервере было потрачено около 100 Гб оперативной памяти. У меня было занято 150 Гб, из которых 100 Гб ушло, и осталось 50 Гб, так что я не вылетел в OOM.

Что в данный момент защищает меня от падения в OOM, если действительно используется 100 Гб оперативной памяти? Как быть, если вдруг оперативная память на слияниях закончится?

Алексей Миловидов: Существует проблема, что расход оперативной памяти на слияния не ограничивается. Вторая проблема заключается в том, что если назначено какое-то слияние, его нужно выполнить, так как оно записано в журнал репликации. Журнал репликации — это те действия, которые необходимы для приведения реплики в согласованное состояние. Если не выполнить ручные манипуляции, которые отменят этот журнал репликации, слияние так или иначе придется выполнить.

Конечно, полезно иметь ограничение по оперативной памяти, которое «на всякий случай» защитит от OOM. Оно не поможет в выполнении слияния, оно снова начнется, дойдет до определенного порога, вызовет исключение и снова начнется — ничего хорошего из этого не получится. Но, в принципе, введение этого ограничения было бы полезно.

Как будет происходить разработка драйвера на Golang для ClickHouse?

Драйвер на Golang, который написал Кирилл Шваков, сейчас официально поддерживается командой ClickHouse. Он в репозитории ClickHouse, он теперь большой и настоящий.

Небольшо́ предупрежде́ние. Съществува чудесно и всеохватыващо хранилище на нормализирани форми от безкраен ред — това е Vertica. Те също имат свой официален Python драйвер, който се поддържа от разработчиците на Vertica. Имало е случаи, когато версиите на хранилището и драйвера са се разминавали значително, в резултат на което драйверът е спирал да работи. И второ, поддръжката на този официален драйвер, смятам, се осъществява чрез системата "ниппел" — пишеш им issue и то остава висящо завинаги.

Имам два въпроса. В момента Go драйверът на Кирил е почти стандартният начин за комуникация от Golang с ClickHouse. Разбира се, винаги е имало някой, който да комуникира през HTTP интерфейса, ако му допада. Как ще протича разработката на този драйвер? Ще бъде ли синхронизирана с някакви breaking changes в самото хранилище? И какъв е порядъкът за разглеждане на issue?

Кирил Шваков: Първо — как е организирана бюрокрацията. Този момент не е дискутиран, затова нямам отговор.

За да отговоря на въпроса за issue, трябва да разкажа малко история за драйвера. Работих в компания, в която имаше много данни. Това беше рекламна платформа с огромно количество събития, които трябваше да се съхраняват. Някакъв момент открихме ClickHouse. Вложихме данните там и първото време всичко беше наред, но после ClickHouse се провали. В онзи момент решихме, че не ни е нужен.

След година се върнахме към идеята за използване на ClickHouse и трябваше по някакъв начин да писаме данни там. Условията бяха такива — хардуерът беше много слаб, ресурсите бяха оскъдни. Но ние винаги работехме така, затова погледнахме към нативния протокол.

Тъй като работихме на Go, беше очевидно, че необходим е драйвер на Go. Работих по него почти на пълен работен ден — това беше моята работна задача. До известен момент го доведохме до работоспособност, и в принципе никой не е предполагал, че някой освен нас ще го използва. После дойде CloudFlare с абсолютно същия проблем и за известно време работихме много тясно заедно, защото имахме едни и същи задачи. И направихме това както в ClickHouse, така и в драйвера.

В някакъв момент просто спрях да се занимавам с тях, защото активността ми относно ClickHouse и работата ми леко се промени. Затова проблемите не се затварят. Периодично в репозиторията комитват хора, на които им е необходимо нещо. Тогава разглеждам pull request и понякога дори сам правя нещо, но това се случва рядко.

Искам да се върна към драйвера. Няколко години назад, когато всичко това започна, ClickHouse беше различен и имаше различни възможности. Сега вече имам представа как да преработя драйвера, за да е добре. Ако това се случи, версия 2 във всеки случай ще бъде несъвместима заради натрупаните решения.

Не знам как да организирам това. Аз самият нямам много време. Ако някои хора започнат да усъвършенстват драйвера, ще мога да им помагам и да обяснявам какво да правят. Но точно активното участие на 'Яндекс' в развитието на проекта все още не е обсъждано.

Алексей Миловидов: Всъщност в момента няма никаква бюрокрация относно тези драйвери. Единственото е, че те са изнесени в официална организация, тоест този драйвер е признат за официално решение по подразбиране за Go. Има и други драйвери, но те са отделни.

Вътрешно нямаме никаква разработка за тези драйвери. Въпросът е дали можем да наемем отделен човек, не конкретно за този драйвер, а за развитието на всички общностни драйвери, или можем да намерим някого отвън.

Външният речник не се активира след рестартиране с включена настройка lazy_load. Какво да правя?

Имаме включена настройка lazy_load и след рестартиране на сървъра речникът сам не се активира. Активира се само след като потребителят се обърне към него. И при първото запитване дава грешка. Може ли по някакъв начин автоматично чрез ClickHouse да се зареждат речниците, или трябва сами винаги да контролираме тяхната готовност, за да не получават потребителите грешки?

Възможно е при нас да има стара версия на ClickHouse, затова речникът автоматично не се зарежда. Може ли да е така?

На първо място, речниците могат да се заредят насилствено с помощта на заявка system reload dictionaries. На второ място, относно грешката — ако речникът вече е зареден, запросите ще работят с данните, които са били заредени. Ако речникът все още не е бил зареден, той ще се зарежда точно по време на запитването.

За тежки речници това не е много удобно. Например, необходимо е да се изтеглят милион редове от MySQL. Някой прави прост select, но този select ще чака именно милиона редове. Тук има две решения. Първото - да се изключи lazy_load. Второто - когато сървърът стартира, преди да се включи натоварването, да се направи system reload dictionary или просто да се изпълни заявка, която използва речника. Тогава речникът ще бъде зареден. Необходимо е сами да контролирате достъпността на речниците с включено lazy_load, защото автоматично ClickHouse не ги зарежда.

На последния въпрос отговорът е - или версията е стара, или трябва да се отстранява.

Как да се справим с факта, че system reload dictionaries не зарежда нито един от многото речници, ако поне един от тях се проваля с грешка?

Има и въпрос относно system reload dictionaries. Имаме два речника - един не се зарежда, вторият се зарежда. В такъв случай system reload dictionaries не зарежда нито един речник и се налага да се зарежда конкретен по името му с помощта на system reload dictionary. Също това ли е свързано с версията на ClickHouse?

Искам да ви зарадвам. Това поведение се е променило. Значи, ако обновите ClickHouse, то също ще се промени. Ако не сте удовлетворени от текущото поведение system reload dictionaries, обновете се и ще се надяваме, че то ще се промени в по-добра посока.

Има ли начин да конфигурираме реквизитите в конфигурацията на ClickHouse, но да не ги разкриваме при грешки?

Следващият въпрос е за грешките, свързани с речника, а именно реквизитите. Ние описахме реквизитите за връзка в конфигурацията на ClickHouse към речника, и при грешка получаваме тези реквизити и паролата в отговора.

Решихме тази грешка, като изнесохме реквизитите в конфигурацията на ODBC драйвера. Има ли някакъв начин да конфигурирате реквизитите в конфигурацията на ClickHouse, но да не се показват тези реквизити при грешки?

Тук решението наистина е - да се посочат тези credentials в odbc.ini, а в самия ClickHouse да се посочи само името на ODBC Data Source. За другите източници на речници такова нещо няма да има - нито за речника с MySQL, нито за останалите не трябва да виждате паролата при съобщение за грешка. Ще погледна и за ODBC - ако има такова нещо, просто трябва да се премахне.

Бонус: фонове за Zoom от срещите

При кликване на картинката за най-упоритите читатели ще се отворят бонус фонове от посиделките. В гасенето на пожара заедно с маскотите на технологиите на Авито, съвещаваме се с колеги от стаята на системния администратор или олдскул компютърния клуб и провеждаме дейли под моста на фона на графити.

Източник: habr.com