Update roadmap. Also revert digital degradation due to accidential changes with automatic scripts.

docs/ru/extended_roadmap.md

@@ -39,18 +39,20 @@ Upd. Большая часть задачи реализована и добав
 
 Требует 1.3. Будет делать [Александр Сапин](https://github.com/alesapin). Ура, сделано.
 
-### 1.5. ALTER RENAME COLUMN. {#alter-rename-column}
+### 1.5. + ALTER RENAME COLUMN. {#alter-rename-column}
 
 [\#6861](https://github.com/ClickHouse/ClickHouse/issues/6861)
 
 Требует 1.3. Будет делать [Александр Сапин](https://github.com/alesapin).
 
-### 1.6. Полиморфные куски данных. {#polimorfnye-kuski-dannykh}
+### 1.6. + Полиморфные куски данных. {#polimorfnye-kuski-dannykh}
 
-Компактные куски - Q1, куски в оперативке Q1/Q2.
+Компактные куски - Q1, куски в оперативке Q1/Q2 - пункт 1.7.
 
 Компактные куски реализованы, ещё не включены по-умолчанию. Первым шагом включаем по-умолчанию для системных таблиц.
 
+Upd. Включено для системных таблиц.
+
 Делает [Антон Попов](https://github.com/CurtizJ), первый рабочий вариант в декабре. Пререквизит чтобы снизить сложность мелких INSERT, что в свою очередь нужно для 1.12, иначе задача 1.12 не сможет нормально работать. Особенно нужно для Яндекс.Облака.
 
 Данные в таблицах типа MergeTree в ClickHouse хранятся в виде набора независимых «кусков». Внутри куска, каждый столбец, а также индекс, хранится в отдельных файлах. Это сделано для возможности быстрых манипуляций со столбцами (пример - запрос ALTER DROP COLUMN). При вставке данных (INSERT), создаётся новый кусок. Для таблиц с большим количеством столбцов, запросы INSERT с маленьким количеством строк являются неэффективными, так как требуют создания большого количества файлов в файловой системе. Это является врождённой особенностью ClickHouse - одной из первой проблем, с которыми сталкиваются пользователи. Пользователям приходится буферизовывать данные и собирать их в более крупные пачки перед вставкой в ClickHouse.
@@ -61,7 +63,7 @@ Upd. Большая часть задачи реализована и добав
 
 ### 1.7. Буферизация и WAL в MergeTree. {#buferizatsiia-i-wal-v-mergetree}
 
-Требует 1.6.
+Требует 1.6. Антон Попов. Задача взята в работу. Q2.
 
 ### 1.8. + Перенос между разделами по TTL. {#perenos-mezhdu-razdelami-po-ttl}
 
@@ -74,7 +76,7 @@ Q1. Закоммичено, но есть технический долг, ко
 
 Будет делать Сорокин Николай, ВШЭ и Яндекс.
 
-Сейчас пользователь может задать в таблице выражение, которое определяет, сколько времени хранятся данные. Обычно это выражение задаётся относительно значения столбца с датой - например: удалять данные через три месяца. https://clickhouse.tech/docs/ru/operations/table\_engines/mergetree/\#table\_engine-mergetree-ttl
+Сейчас пользователь может задать в таблице выражение, которое определяет, сколько времени хранятся данные. Обычно это выражение задаётся относительно значения столбца с датой - например: удалять данные через три месяца. https://clickhouse.tech/docs/ru/operations/table_engines/mergetree/\#table_engine-mergetree-ttl
 
 Это может быть задано для всей таблицы (тогда строки целиком удаляются после указанного времени) или для отдельных столбцов (тогда данные столбца физически удаляются с диска, а строки в таблице остаются; при чтении значений столбца, они читаются как значения по-умолчанию).
 
@@ -88,7 +90,7 @@ Q1. Закоммичено, но есть технический долг, ко
 
 А вот пункт 2 требуется продумать. Не очевидно даже, какой лучше использовать синтаксис для этого при создании таблицы. Но мы придумаем - сразу видно несколько вариантов.
 
-Частный случай такой задачи уже есть в https://clickhouse.tech/docs/ru/operations/table\_engines/graphitemergetree/ Но это было сделано для конкретной задачи. А надо обобщить.
+Частный случай такой задачи уже есть в https://clickhouse.tech/docs/ru/operations/table_engines/graphitemergetree/ Но это было сделано для конкретной задачи. А надо обобщить.
 
 ### 1.10. Пережатие старых данных в фоне. {#perezhatie-starykh-dannykh-v-fone}
 
@@ -100,17 +102,15 @@ Q1. Закоммичено, но есть технический долг, ко
 
 Предлагается добавить в ClickHouse настройки по пережатию данных и фоновые потоки, выполняющие эту задачу.
 
-### 1.11. Виртуальная файловая система. {#virtualnaia-failovaia-sistema}
+### 1.11. + Виртуальная файловая система. {#virtualnaia-failovaia-sistema}
 
-В процессе реализации, сейчас на VFS переведены Log, TinyLog, StripeLog, готовится MergeTree.
+На VFS переведены Log, TinyLog, StripeLog, а также MergeTree, что доказывает состоятельность реализации.
 
-Q2.
-
-Нужно для Яндекс.Облака. Делает Александр, Яндекс.Облако, а также Олег Ершов, ВШЭ и Яндекс.
+Нужно для Яндекс.Облака. Делает Александр, Яндекс.Облако.
 
 ClickHouse использует для хранения данных локальную файловую систему. Существует сценарий работы, в котором размещение старых (архивных) данных было бы выгодно на удалённой файловой системе. Если файловая система POSIX совместимая, то это не составляет проблем: ClickHouse успешно работает с Ceph, GlusterFS, MooseFS. Также востребованным является сценарий использования S3 (из-за доступности в облаке) или HDFS (для интеграции с Hadoop). Но эти файловые системы не являются POSIX совместимыми. Хотя для них существуют FUSE драйверы, но скорость работы сильно страдает и поддержка неполная.
 
-ClickHouse использует небольшое подмножество функций ФС, но в то же время, и некоторые специфические части: симлинки и хардлинки, O\_DIRECT. Предлагается выделить всё взаимодействие с файловой системой в отдельный интерфейс.
+ClickHouse использует небольшое подмножество функций ФС, но в то же время, и некоторые специфические части: симлинки и хардлинки, O_DIRECT. Предлагается выделить всё взаимодействие с файловой системой в отдельный интерфейс.
 
 ### 1.12. Экспериментальная реализация VFS поверх S3 и HDFS. {#eksperimentalnaia-realizatsiia-vfs-poverkh-s3-i-hdfs}
 
@@ -121,13 +121,15 @@ Q2.
 
 Upd. Олег будет делать только часть про HDFS.
 
+Upd. Реализация поверх S3 является рабочей на уровне PoC.
+
 ### 1.13. Ускорение запросов с FINAL. {#uskorenie-zaprosov-s-final}
 
-Требует 2.1. Делает [Николай Кочетов](https://github.com/KochetovNicolai). Нужно для Яндекс.Метрики.
+Требует 2.1. Делает [Николай Кочетов](https://github.com/KochetovNicolai). Нужно для Яндекс.Метрики. Q2.
 
 ### 1.14. Не писать столбцы, полностью состоящие из нулей. {#ne-pisat-stolbtsy-polnostiu-sostoiashchie-iz-nulei}
 
-Антон Попов. Q1/Q2.
+Антон Попов. Q2.
 В очереди. Простая задача, является небольшим пререквизитом для потенциальной поддержки полуструктурированных данных.
 
 ### 1.15. Возможность иметь разный первичный ключ в разных кусках. {#vozmozhnost-imet-raznyi-pervichnyi-kliuch-v-raznykh-kuskakh}
@@ -146,6 +148,7 @@ Upd. Олег будет делать только часть про HDFS.
 
 Требует 1.3 и 1.6. Полная замена hard links на sym links, что будет лучше для 1.12.
 
+
 ## 2. Крупные рефакторинги. {#krupnye-refaktoringi}
 
 Для обоснования необходимости смотрите ссылки в описании других задач.
@@ -161,6 +164,8 @@ Upd. Включили по-умолчанию. Удаление старого
 
 Upd. Уже есть первый релиз, в котором это включено по-умолчанию.
 
+Upd. Всё ещё ждём удаление старого кода, которое должно случиться после релиза 20.4.
+
 ### 2.2. Инфраструктура событий/метрик/ограничений/квот/трассировки. {#infrastruktura-sobytiimetrikogranicheniikvottrassirovki}
 
 В очереди. https://gist.github.com/alexey-milovidov/d62d73222d83b9319dc519cbb13aeff6
@@ -193,6 +198,8 @@ Upd. Каталог БД вынесен из Context.
 
 Средний приоритет. Нужно для YQL.
 
+Upd. В очереди. Иван Лежанкин.
+
 ### 2.9. Логгировние в format-стиле. {#loggirovnie-v-format-stile}
 
 Делает [Иван Лежанкин](https://github.com/abyss7). Низкий приоритет.
@@ -212,10 +219,14 @@ Upd. Каталог БД вынесен из Context.
 
 Задачу делает Алексей Миловидов. Прогресс 50% и разработка временно приостановлена.
 
+Upd. Разработка всё ещё приостановлена.
+
 ### 2.13. Каждая функция в отдельном файле. {#kazhdaia-funktsiia-v-otdelnom-faile}
 
 Задачу делает Алексей Миловидов. Прогресс 80%. Потребуется помощь других разработчиков.
 
+Upd. Поползновения наблюдаются.
+
 ### 2.14. Все функции с состоянием переделать на FunctionBuilder. {#vse-funktsii-s-sostoianiem-peredelat-na-functionbuilder}
 
 Долг [Николай Кочетов](https://github.com/KochetovNicolai). Сейчас код находится в переходном состоянии, что неприемлемо.
@@ -224,13 +235,14 @@ Upd. Каталог БД вынесен из Context.
 
 Для нормализации работы materialized views поверх Merge, Distributed, Kafka.
 
+
 ## 3. Документация. {#dokumentatsiia}
 
 Здесь задачи только по инфраструктуре документации.
 
 ### 3.1. Перенос документации по функциям в код. {#perenos-dokumentatsii-po-funktsiiam-v-kod}
 
-Требует 2.12 и 2.13. Хотим в Q1/Q2, средний приоритет.
+Требует 2.12 и 2.13. Хотим в Q2, средний приоритет.
 
 ### 3.2. Перенос однородных частей документации в код. {#perenos-odnorodnykh-chastei-dokumentatsii-v-kod}
 
@@ -246,11 +258,12 @@ Upd. Иван Блинков сделал эту задачу путём зам
 
 Эту задачу сделает [Иван Блинков](https://github.com/blinkov/), до конца декабря 2019. Сделано.
 
+
 ## 4. Сетевое взаимодействие. {#setevoe-vzaimodeistvie}
 
 ### 4.1. Уменьшение числа потоков при распределённых запросах. {#umenshenie-chisla-potokov-pri-raspredelionnykh-zaprosakh}
 
-[Никита Лапков](https://github.com/laplab), весна 2020. Upd. Есть прототип. Upd. Он не работает.
+Весна 2020. Upd. Есть прототип. Upd. Он не работает. Upd. Человек отказался от задачи, теперь сроки не определены.
 
 ### 4.2. Спекулятивное выполнение запросов на нескольких репликах. {#spekuliativnoe-vypolnenie-zaprosov-na-neskolkikh-replikakh}
 
@@ -262,6 +275,8 @@ Upd. Иван Блинков сделал эту задачу путём зам
 
 Сейчас для распределённых запросов используется по потоку на соединение. Это позволяет хорошо распараллелить вычисления над полученными данными и утилизировать сеть, но становится сильно избыточным для больших кластеров. Для примера, создание 1000 потоков для чтения данных из 1000 серверов кластера - лишь расходует ресурсы и увеличивает время выполнения запроса. Вместо этого необходимо использовать количество потоков не большее количества процессорных ядер, и мультиплексировать в одном потоке общение с серверами. Реализация нетривиальна, так как мультиплексировать необходимо каждую стадию общения по сети, включая установку соединения и обмен handshake.
 
+Upd. Сейчас обсуждается, как сделать другую задачу вместо этой.
+
 ### 4.3. Ограничение числа одновременных скачиваний с реплик. {#ogranichenie-chisla-odnovremennykh-skachivanii-s-replik}
 
 Дмитрий Григорьев, ВШЭ.
@@ -284,14 +299,16 @@ Upd. Иван Блинков сделал эту задачу путём зам
 Дмитрий Григорьев, ВШЭ.
 В очереди. Исправить проблему, что восстанавливающаяся реплика перестаёт мержить. Частично компенсируется 4.3.
 
+
 ## 5. Операции. {#operatsii}
 
-### 5.1. Разделение задач на более мелкие куски в clickhouse-copier. {#razdelenie-zadach-na-bolee-melkie-kuski-v-clickhouse-copier}
+### 5.1. + Разделение задач на более мелкие куски в clickhouse-copier. {#razdelenie-zadach-na-bolee-melkie-kuski-v-clickhouse-copier}
 
 [\#9075](https://github.com/ClickHouse/ClickHouse/pull/9075)
 Q1. Нужно для Метрики, в очереди. Никита Михайлов.
 
 Upd. Задача на финальной стадии разработки.
+Upd. Сделано. Эффективность работы под вопросом. Есть варианты, как сделать лучше.
 
 ### 5.2. Автонастройка лимита на оперативку и размера кэшей. {#avtonastroika-limita-na-operativku-i-razmera-keshei}
 
@@ -305,6 +322,8 @@ Upd. Задача на финальной стадии разработки.
 
 Требует 7.5. Задачу хочет Метрика, Облако, БК, Маркет и Altinity. Первой LTS версией уже стала версия 19.14.
 Метрика, БК, Маркет, Altinity уже используют более свежие версии чем LTS.
+Upd. Появилась вторая версия LTS - 20.3.
+
 
 ## 6. Инструментирование. {#instrumentirovanie}
 
@@ -321,7 +340,7 @@ Upd. Задача на финальной стадии разработки.
 
 ### 6.3. Учёт оперативки total расширить не только на запросы. {#uchiot-operativki-total-rasshirit-ne-tolko-na-zaprosy}
 
-Исправление долгоживущей проблемы с дрифтом учёта оперативки. Нужна для Метрики и БК. Иван Лежанкин. Q1.
+Исправление долгоживущей проблемы с дрифтом учёта оперативки. Нужна для Метрики и БК. Иван Лежанкин. Q1. Странно, как будто не сделано.
 
 ### 6.4. Поддержка perf events как метрик запроса. {#podderzhka-perf-events-kak-metrik-zaprosa}
 
@@ -339,7 +358,7 @@ Upd. Задача на финальной стадии разработки.
 
 Сейчас есть стек трейс для почти всех, но не всех исключений. Требует 7.4.
 
-### 6.7. + Таблица system.stack\_trace. {#tablitsa-system-stack-trace}
+### 6.7. + Таблица system.stack_trace. {#tablitsa-system-stack-trace}
 
 Сравнительно простая задача, но только для опытных разработчиков.
 
@@ -351,6 +370,7 @@ Upd. Задача на финальной стадии разработки.
 
 ### 6.10. Сбор общих системных метрик. {#sbor-obshchikh-sistemnykh-metrik}
 
+
 ## 7. Сопровождение разработки. {#soprovozhdenie-razrabotki}
 
 ### 7.1. + ICU в submodules. {#icu-v-submodules}
@@ -361,7 +381,7 @@ Upd. Задача на финальной стадии разработки.
 
 Сделал Алексей Миловидов.
 
-### 7.3. Обновление Poco. {#obnovlenie-poco}
+### 7.3. + Обновление Poco. {#obnovlenie-poco}
 
 Алексанр Кузьменков.
 
@@ -383,13 +403,18 @@ Upd. Задача на финальной стадии разработки.
 Уже есть ASan, TSan, UBSan. Не хватает тестов под MSan. Они уже добавлены в CI, но не проходят.
 [Александр Кузьменков](https://github.com/akuzm) и [Александр Токмаков](https://github.com/tavplubix).
 
-### 7.8. Добавить clang-tidy. {#dobavit-clang-tidy}
+Upd. Задача всё ещё медленно тащится.
+
+### 7.8. + Добавить clang-tidy. {#dobavit-clang-tidy}
 
 Уже есть PVS-Studio. Мы очень довольны, но этого недостаточно.
 
 Upd. Алексей Миловидов. Добавлено некоторое множество проверок, но нужно рассмотреть все проверки подряд и добавить всё, что можно.
+Upd. Рассмотрели все проверки подряд.
 
-### 7.9. Проверки на стиль имён с помощью clang-tidy. {#proverki-na-stil-imion-s-pomoshchiu-clang-tidy}
+### 7.9. + Проверки на стиль имён с помощью clang-tidy. {#proverki-na-stil-imion-s-pomoshchiu-clang-tidy}
+
+Сделано. Только в .cpp файлах и только для имён локальных переменных. Остальное слишком сложно.
 
 ### 7.10. Включение UBSan и MSan в интеграционных тестах. {#vkliuchenie-ubsan-i-msan-v-integratsionnykh-testakh}
 
@@ -399,6 +424,8 @@ UBSan включен в функциональных тестах, но не в
 
 У нас мало unit тестов по сравнению с функциональными тестами и их использование не обязательно. Но они всё-равно важны и нет причин не запускать их под всеми видами sanitizers.
 
+Илья Яцишин.
+
 ### 7.12. Показывать тестовое покрытие нового кода в PR. {#pokazyvat-testovoe-pokrytie-novogo-koda-v-pr}
 
 Пока есть просто показ тестового покрытия всего кода.
@@ -413,6 +440,8 @@ UBSan включен в функциональных тестах, но не в
 
 Подключение replxx вместо readline сделал Иван Лежанкин.
 
+Есть технический долг с лицензиями файлов консорциума Unicode.
+
 ### 7.14.1. Улучшение возможностей интерактивного режима clickhouse-client. {#uluchshenie-vozmozhnostei-interaktivnogo-rezhima-clickhouse-client}
 
 Тагир Кускаров, ВШЭ.
@@ -476,7 +505,7 @@ https://github.com/ClickHouse/ClickHouse/issues/8027\#issuecomment-566670282
 Проверили на настоящем сервере Huawei, а также в специальном Docker контейнере, который содержит внутри qemu-user-static.
 Также можно проверить на Cavium, на Raspberry Pi а также на твоём Android телефоне.
 
-### 7.20. Автосборка для FreeBSD x86\_64. {#avtosborka-dlia-freebsd-x86-64}
+### 7.20. Автосборка для FreeBSD x86_64. {#avtosborka-dlia-freebsd-x86-64}
 
 [Иван Лежанкин](https://github.com/abyss7).
 
@@ -535,6 +564,8 @@ Fuzzing тестирование - это тестирование случай
 Также можно сделать функции с детерминированным генератором случайных чисел (аргументом передаётся seed) для воспроизводимости тестовых кейсов.
 
 Upd. Сергей Штыков сделал функцию `randomPrintableASCII`.
+Upd. Илья Яцишин сделал табличную функцию `generateRandom`.
+Upd. Эльдар Заитов добавляет OSS Fuzz.
 
 ### 7.24. Fuzzing лексера и парсера запросов; кодеков и форматов. {#fuzzing-leksera-i-parsera-zaprosov-kodekov-i-formatov}
 
@@ -557,10 +588,12 @@ Upd. Сергей Штыков сделал функцию `randomPrintableASCII
 
 Нужно для CHYT и YQL.
 
-UPD: Все патчи Максима отправлены в master. Задача взята в работу.
+Upd: Все патчи Максима отправлены в master. Задача взята в работу.
 
 Upd: Задача в процессе реализации. Синхронизироваться будет master. Делает [Иван Лежанкин](https://github.com/abyss7)
 
+Upd: Есть собирающийся прототип, но сборка как будто ещё не в trunk Аркадии.
+
 ### 7.26. Побайтовая идентичность репозитория с Аркадией. {#pobaitovaia-identichnost-repozitoriia-s-arkadiei}
 
 Команда DevTools. Прогресс по задаче под вопросом.
@@ -617,6 +650,7 @@ Upd: Задача в процессе реализации. Синхронизи
 Upd. Иван Блинков настроил CDN repo.clickhouse.tech, что решает проблему с доступностью зарубежом.
 Вопрос с operations, visibility пока актуален.
 
+
 ## 8. Интеграция с внешними системами. {#integratsiia-s-vneshnimi-sistemami}
 
 ### 8.1. Поддержка ALTER MODIFY SETTING для Kafka. {#podderzhka-alter-modify-setting-dlia-kafka}
@@ -629,11 +663,11 @@ Altinity. Никто не делает эту задачу.
 
 [Александр Кузьменков](https://github.com/akuzm).
 
-### 8.3. Доработки globs (правильная поддержка диапазонов, уменьшение числа одновременных stream-ов). {#dorabotki-globs-pravilnaia-podderzhka-diapazonov-umenshenie-chisla-odnovremennykh-stream-ov}
+### 8.3. + Доработки globs (правильная поддержка диапазонов, уменьшение числа одновременных stream-ов). {#dorabotki-globs-pravilnaia-podderzhka-diapazonov-umenshenie-chisla-odnovremennykh-stream-ov}
 
 [Ольга Хвостикова](https://github.com/stavrolia).
 
-Уменьшение числа stream-ов сделано, а вот правильная поддержка диапазонов - нет. Будем надеяться на Q1/Q2.
+Уменьшение числа stream-ов сделано, а вот правильная поддержка диапазонов - нет. Будем надеяться на Q1/Q2. Сделано.
 
 ### 8.4. Унификация File, HDFS, S3 под URL. {#unifikatsiia-file-hdfs-s3-pod-url}
 
@@ -690,19 +724,21 @@ Andrew Onyshchuk. Есть pull request. Q1. Сделано.
 
 Павел Круглов, ВШЭ и Яндекс. Есть pull request.
 
-### 8.16.2. Поддержка формата Thrift. {#podderzhka-formata-thrift}
+### 8.16.2. - Поддержка формата Thrift. {#podderzhka-formata-thrift}
 
-Павел Круглов, ВШЭ и Яндекс.
+Павел Круглов, ВШЭ и Яндекс. Задача отменена.
 
 ### 8.16.3. Поддержка формата MsgPack. {#podderzhka-formata-msgpack}
 
 Павел Круглов, ВШЭ и Яндекс.
 Задача взята в работу.
 
-### 8.16.4. Формат Regexp. {#format-regexp}
+Upd. Почти готово - есть лишь небольшой технический долг.
+
+### 8.16.4. + Формат Regexp. {#format-regexp}
 
 Павел Круглов, ВШЭ и Яндекс.
-Есть pull request.
+Есть pull request. Готово.
 
 ### 8.17. ClickHouse как MySQL реплика. {#clickhouse-kak-mysql-replika}
 
@@ -735,6 +771,7 @@ Maxim Fedotov, Wargaming + Yuri Baranov, Яндекс.
 Нужно для БК. Декабрь 2019.
 В декабре для БК сделан минимальный вариант этой задачи.
 Максимальный вариант, вроде, никому не нужен.
+Upd. Всё ещё кажется, что задача не нужна.
 
 ### 8.22. Поддержка синтаксиса для переменных в стиле MySQL. {#podderzhka-sintaksisa-dlia-peremennykh-v-stile-mysql}
 
@@ -746,6 +783,7 @@ Upd. Юрий Баранов работает в Google, там запрещен
 
 Желательно 2.15.
 
+
 ## 9. Безопасность. {#bezopasnost}
 
 ### 9.1. + Ограничение на хосты в запросах ко внешним системам. {#ogranichenie-na-khosty-v-zaprosakh-ko-vneshnim-sistemam}
@@ -761,7 +799,12 @@ ClickHouse предоставляет возможность обратитьс
 Вместо этого предлагается описывать необходимые данные в конфигурационном файле сервера или в отдельном сервисе и ссылаться на них по именам.
 
 ### 9.3. Поддержка TLS для ZooKeeper. {#podderzhka-tls-dlia-zookeeper}
+
 [#10174](https://github.com/ClickHouse/ClickHouse/issues/10174)
+
+Есть pull request.
+
+
 ## 10. Внешние словари. {#vneshnie-slovari}
 
 ### 10.1. + Исправление зависания в библиотеке доступа к YT. {#ispravlenie-zavisaniia-v-biblioteke-dostupa-k-yt}
@@ -777,6 +820,7 @@ ClickHouse предоставляет возможность обратитьс
 Нужно для БК и Метрики. Поиск причин - [Александр Сапин](https://github.com/alesapin). Дальшейшее исправление возможно на стороне YT.
 
 Upd. Одну причину устранили, но ещё что-то неизвестное осталось.
+Upd. Нас заставляют переписать эту библиотеку с одного API на другое, так как старое внезапно устарело. Кажется, что переписывание случайно исправит все проблемы.
 
 ### 10.3. Возможность чтения данных из статических таблиц в YT словарях. {#vozmozhnost-chteniia-dannykh-iz-staticheskikh-tablits-v-yt-slovariakh}
 
@@ -802,7 +846,7 @@ Upd. Одну причину устранили, но ещё что-то неи
 
 Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.
 
-### 10.9. Уменьшение блокировок для cache словарей за счёт одновременных запросов одного и того же. {#umenshenie-blokirovok-dlia-cache-slovarei-za-schiot-odnovremennykh-zaprosov-odnogo-i-togo-zhe}
+### 10.9. - Уменьшение блокировок для cache словарей за счёт одновременных запросов одного и того же. {#umenshenie-blokirovok-dlia-cache-slovarei-za-schiot-odnovremennykh-zaprosov-odnogo-i-togo-zhe}
 
 Заменено в пользу 10.10, 10.11.
 
@@ -825,7 +869,7 @@ Upd. Одну причину устранили, но ещё что-то неи
 
 ### 10.14. Поддержка всех типов в функции transform. {#podderzhka-vsekh-tipov-v-funktsii-transform}
 
-Задачу взяла Ольга Хвостикова.
+Задачу взяла Ольга Хвостикова. Upd. Статус неизвестен.
 
 ### 10.15. Использование словарей как специализированного layout для Join. {#ispolzovanie-slovarei-kak-spetsializirovannogo-layout-dlia-join}
 
@@ -843,6 +887,7 @@ Upd. Одну причину устранили, но ещё что-то неи
 
 ### 10.19. Возможность зарегистрировать некоторые функции, использующие словари, под пользовательскими именами. {#vozmozhnost-zaregistrirovat-nekotorye-funktsii-ispolzuiushchie-slovari-pod-polzovatelskimi-imenami}
 
+
 ## 11. Интерфейсы. {#interfeisy}
 
 ### 11.1. Вставка состояний агрегатных функций в виде кортежа аргументов или массива кортежей аргументов. {#vstavka-sostoianii-agregatnykh-funktsii-v-vide-kortezha-argumentov-ili-massiva-kortezhei-argumentov}
@@ -851,6 +896,8 @@ Upd. Одну причину устранили, но ещё что-то неи
 
 Нужно разобраться, как упаковывать Java в статический бинарник, возможно AppImage. Или предоставить максимально простую инструкцию по установке jdbc-bridge. Может быть будет заинтересован Александр Крашенинников, Badoo, так как он разработал jdbc-bridge.
 
+Upd. Александр Крашенинников перешёл в другую компанию и больше не занимается этим.
+
 ### 11.3. + Интеграционные тесты ODBC драйвера путём подключения ClickHouse к самому себе через ODBC. {#integratsionnye-testy-odbc-draivera-putiom-podkliucheniia-clickhouse-k-samomu-sebe-cherez-odbc}
 
 Михаил Филимонов, Altinity. Готово.
@@ -881,12 +928,13 @@ zhang2014, есть pull request.
 
 Возможность описать в конфигурационном файле handler (путь в URL) для HTTP запросов к серверу, которому соответствует некоторый параметризованный запрос. Пользователь может вызвать этот обработчик и не должен передавать SQL запрос.
 
+
 ## 12. Управление пользователями и доступом. {#upravlenie-polzovateliami-i-dostupom}
 
-### 12.1. Role Based Access Control. {#role-based-access-control}
+### 12.1. + Role Based Access Control. {#role-based-access-control}
 
-[Виталий Баранов](https://github.com/vitlibar). Финальная стадия разработки, рабочая версия в начале февраля 2019.
-Q1. Сейчас сделаны все интерфейсы в коде и запросы, но не сделаны варианты хранения прав кроме прототипа.
+[Виталий Баранов](https://github.com/vitlibar). Финальная стадия разработки, рабочая версия в начале апреля 2019.
+Q2. Сейчас сделаны все интерфейсы в коде и запросы, но не сделаны варианты хранения прав кроме прототипа.
 Upd. Сделано хранение прав. До готового к использованию состояния осталось несколько доработок.
 
 ### 12.2. + Управление пользователями и правами доступа с помощью SQL запросов. {#upravlenie-polzovateliami-i-pravami-dostupa-s-pomoshchiu-sql-zaprosov}
@@ -897,7 +945,7 @@ Q1. Сделано управление правами полностью, но
 ### 12.3. Подключение справочника пользователей и прав доступа из LDAP. {#podkliuchenie-spravochnika-polzovatelei-i-prav-dostupa-iz-ldap}
 
 [Виталий Баранов](https://github.com/vitlibar). Требует 12.1.
-Q1/Q2.
+Q2.
 
 ### 12.4. Подключение IDM системы Яндекса как справочника пользователей и прав доступа. {#podkliuchenie-idm-sistemy-iandeksa-kak-spravochnika-polzovatelei-i-prav-dostupa}
 
@@ -911,6 +959,7 @@ Q1/Q2.
 
 [Виталий Баранов](https://github.com/vitlibar). Требует 12.1.
 
+
 ## 13. Разделение ресурсов, multi-tenancy. {#razdelenie-resursov-multi-tenancy}
 
 ### 13.1. Overcommit запросов по памяти и вытеснение. {#overcommit-zaprosov-po-pamiati-i-vytesnenie}
@@ -926,6 +975,8 @@ Q1/Q2.
 Требует 13.2 или сможем сделать более неудобную реализацию раньше.
 Обсуждается вариант неудобной реализации. Пока средний приоритет, целимся на Q1/Q2.
 Вариант реализации выбрал Александр Казаков.
+Upd. Не уследили, и задачу стали обсуждать менеджеры.
+
 
 ## 14. Диалект SQL. {#dialekt-sql}
 
@@ -936,8 +987,6 @@ Q1/Q2.
 
 ### 14.2. Поддержка WITH для подзапросов. {#podderzhka-with-dlia-podzaprosov}
 
-Михаил Коротов.
-
 ### 14.3. Поддержка подстановок для множеств в правой части IN. {#podderzhka-podstanovok-dlia-mnozhestv-v-pravoi-chasti-in}
 
 ### 14.4. Поддержка подстановок для идентификаторов (имён) в SQL запросе. {#podderzhka-podstanovok-dlia-identifikatorov-imion-v-sql-zaprose}
@@ -993,7 +1042,7 @@ zhang2014
 
 ### 14.16. Синонимы для функций из MySQL. {#sinonimy-dlia-funktsii-iz-mysql}
 
-### 14.17. Ввести понятие stateful функций. {#vvesti-poniatie-stateful-funktsii}
+### 14.17. + Ввести понятие stateful функций. {#vvesti-poniatie-stateful-funktsii}
 
 zhang2014.
 Для runningDifference, neighbour - их учёт в оптимизаторе запросов.
@@ -1018,13 +1067,15 @@ zhang2014.
 
 Павел Потёмкин, ВШЭ.
 
+
 ## 15. Улучшение поддержки JOIN. {#uluchshenie-podderzhki-join}
 
-### 15.1. Доведение merge JOIN до продакшена. {#dovedenie-merge-join-do-prodakshena}
+### 15.1. + Доведение merge JOIN до продакшена. {#dovedenie-merge-join-do-prodakshena}
 
 Артём Зуйков. Сейчас merge JOIN включается вручную опцией и всегда замедляет запросы. Хотим, чтобы он замедлял запросы только когда это неизбежно.
 Кстати, смысл merge JOIN появляется только совместно с 15.2 и 15.3.
 Q1. Сделали адаптивный вариант, но вроде он что-то всё-ещё замедляет.
+Задача сделана, но всё работает слишком медленно.
 
 ### 15.1.1. Алгоритм two-level merge JOIN. {#algoritm-two-level-merge-join}
 
@@ -1052,6 +1103,7 @@ Q1. Сделали адаптивный вариант, но вроде он ч
 
 Артём Зуйков.
 
+
 ## 16. Типы данных и функции. {#tipy-dannykh-i-funktsii}
 
 ### 16.1. + DateTime64. {#datetime64}
@@ -1073,6 +1125,7 @@ Upd. Секретного изменения в работе не будет, з
 
 ### 16.6. Функции нормализации и хэширования SQL запросов. {#funktsii-normalizatsii-i-kheshirovaniia-sql-zaprosov}
 
+
 ## 17. Работа с географическими данными. {#rabota-s-geograficheskimi-dannymi}
 
 ### 17.1. Гео-словари для определения региона по координатам. {#geo-slovari-dlia-opredeleniia-regiona-po-koordinatam}
@@ -1105,6 +1158,7 @@ Upd. Андрей сделал прототип более оптимально
 
 Сейчас функция тихо не работает в случае полигонов с самопересечениями, надо кидать исключение.
 
+
 ## 18. Машинное обучение и статистика. {#mashinnoe-obuchenie-i-statistika}
 
 ### 18.1. Инкрементальная кластеризация данных. {#inkrementalnaia-klasterizatsiia-dannykh}
@@ -1123,6 +1177,7 @@ Upd. Андрей сделал прототип более оптимально
 
 В очереди. Возможно, Александр Кожихов. У него сначала идёт задача 24.26.
 
+
 ## 19. Улучшение работы кластера. {#uluchshenie-raboty-klastera}
 
 ### 19.1. Параллельные кворумные вставки без линеаризуемости. {#parallelnye-kvorumnye-vstavki-bez-linearizuemosti}
@@ -1153,7 +1208,7 @@ Upd. Алексей сделал какой-то вариант, но борет
 
 Hold. Полезно для заказчиков внутри Яндекса, но есть риски. Эту задачу никто не будет делать.
 
-### 19.4. internal\_replication = ‘auto’. {#internal-replication-auto}
+### 19.4. internal_replication = ‘auto’. {#internal-replication-auto}
 
 ### 19.5. Реплицируемые базы данных. {#replitsiruemye-bazy-dannykh}
 
@@ -1177,18 +1232,20 @@ Hold. Полезно для заказчиков внутри Яндекса, н
 
 Требует 1.6, 19.1, 19.6, 19.7, 19.8, 19.9.
 
+
 ## 20. Мутации данных. {#mutatsii-dannykh}
 
 Пока все задачи по точечным UPDATE/DELETE имеют низкий приоритет, но ожидаем взять в работу в середине 2020.
 
 ### 20.1. Поддержка DELETE путём запоминания множества затронутых кусков и ключей. {#podderzhka-delete-putiom-zapominaniia-mnozhestva-zatronutykh-kuskov-i-kliuchei}
 
-### 20.2. Поддержка DELETE путём преобразования множества ключей в множество row\_numbers на реплике, столбца флагов и индекса по диапазонам. {#podderzhka-delete-putiom-preobrazovaniia-mnozhestva-kliuchei-v-mnozhestvo-row-numbers-na-replike-stolbtsa-flagov-i-indeksa-po-diapazonam}
+### 20.2. Поддержка DELETE путём преобразования множества ключей в множество row_numbers на реплике, столбца флагов и индекса по диапазонам. {#podderzhka-delete-putiom-preobrazovaniia-mnozhestva-kliuchei-v-mnozhestvo-row-numbers-na-replike-stolbtsa-flagov-i-indeksa-po-diapazonam}
 
 ### 20.3. Поддержка ленивых DELETE путём запоминания выражений и преобразования к множеству ключей в фоне. {#podderzhka-lenivykh-delete-putiom-zapominaniia-vyrazhenii-i-preobrazovaniia-k-mnozhestvu-kliuchei-v-fone}
 
 ### 20.4. Поддержка UPDATE с помощью преобразования в DELETE и вставок. {#podderzhka-update-s-pomoshchiu-preobrazovaniia-v-delete-i-vstavok}
 
+
 ## 21. Оптимизации производительности. {#optimizatsii-proizvoditelnosti}
 
 ### 21.1. + Параллельный парсинг форматов. {#parallelnyi-parsing-formatov}
@@ -1201,7 +1258,7 @@ Hold. Полезно для заказчиков внутри Яндекса, н
 
 После 21.1, предположительно Никита Михайлов. Задача сильно проще чем 21.1.
 
-### 21.3. Исправление низкой производительности анализа индекса в случае большого множества в секции IN. {#ispravlenie-nizkoi-proizvoditelnosti-analiza-indeksa-v-sluchae-bolshogo-mnozhestva-v-sektsii-in}
+### 21.3. + Исправление низкой производительности анализа индекса в случае большого множества в секции IN. {#ispravlenie-nizkoi-proizvoditelnosti-analiza-indeksa-v-sluchae-bolshogo-mnozhestva-v-sektsii-in}
 
 Нужно всем (Zen, БК, DataLens, TestEnv…). Антон Попов, Q1/Q2.
 
@@ -1309,23 +1366,23 @@ Constraints позволяют задать выражение, истиннос
 
 В ClickHouse используется неоптимальный вариант top sort. Суть его в том, что из каждого блока достаётся top N записей, а затем, все блоки мержатся. Но доставание top N записей у каждого следующего блока бессмысленно, если мы знаем, что из них в глобальный top N войдёт меньше. Конечно нужно реализовать вариацию на тему priority queue (heap) с быстрым пропуском целых блоков, если ни одна строка не попадёт в накопленный top.
 
-1.  Рекурсивный вариант сортировки по кортежам.
+2.  Рекурсивный вариант сортировки по кортежам.
 
 Для сортировки по кортежам используется обычная сортировка с компаратором, который в цикле по элементам кортежа делает виртуальные вызовы `IColumn::compareAt`. Это неоптимально - как из-за короткого цикла по неизвестному в compile-time количеству элементов, так и из-за виртуальных вызовов. Чтобы обойтись без виртуальных вызовов, есть метод `IColumn::getPermutation`. Он используется в случае сортировки по одному столбцу. Есть вариант, что в случае сортировки по кортежу, что-то похожее тоже можно применить… например, сделать метод `updatePermutation`, принимающий аргументы offset и limit, и допереставляющий перестановку в диапазоне значений, в которых предыдущий столбец имел равные значения.
 
-1.  RadixSort для сортировки.
+3.  RadixSort для сортировки.
 
 Один наш знакомый начал делать задачу по попытке использования RadixSort для сортировки столбцов. Был сделан вариант indirect сортировки (для `getPermutation`), но не оптимизирован до конца - есть лишние ненужные перекладывания элементов. Для того, чтобы его оптимизировать, придётся добавить немного шаблонной магии (на последнем шаге что-то не копировать, вместо перекладывания индексов - складывать их в готовое место). Также этот человек добавил метод MSD Radix Sort для реализации radix partial sort. Но даже не проверил производительность.
 
 Наиболее содержательная часть задачи может состоять в применении Radix Sort для сортировки кортежей, расположенных в оперативке в виде Structure Of Arrays неизвестного в compile-time размера. Это может работать хуже, чем то, что описано в пункте 2… Но попробовать не помешает.
 
-1.  Three-way comparison sort.
+4.  Three-way comparison sort.
 
 Виртуальный метод `compareAt` возвращает -1, 0, 1. Но алгоритмы сортировки сравнениями обычно рассчитаны на `operator<` и не могут получить преимущества от three-way comparison. А можно ли написать так, чтобы преимущество было?
 
-1.  pdq partial sort
+5.  pdq partial sort
 
-Хороший алгоритм сортировки сравнениями `pdqsort` не имеет варианта partial sort. Заметим, что на практике, почти все сортировки в запросах ClickHouse являются partial\_sort, так как `ORDER BY` почти всегда идёт с `LIMIT`. Кстати, Данила Кутенин уже попробовал это и показал, что в тривиальном случае преимущества нет. Но не очевидно, что нельзя сделать лучше.
+Хороший алгоритм сортировки сравнениями `pdqsort` не имеет варианта partial sort. Заметим, что на практике, почти все сортировки в запросах ClickHouse являются partial_sort, так как `ORDER BY` почти всегда идёт с `LIMIT`. Кстати, Данила Кутенин уже попробовал это и показал, что в тривиальном случае преимущества нет. Но не очевидно, что нельзя сделать лучше.
 
 ### 21.20. Использование материализованных представлений для оптимизации запросов. {#ispolzovanie-materializovannykh-predstavlenii-dlia-optimizatsii-zaprosov}
 
@@ -1344,6 +1401,7 @@ Constraints позволяют задать выражение, истиннос
 zhang2014.
 Есть pull request.
 
+
 ## 22. Долги и недоделанные возможности. {#dolgi-i-nedodelannye-vozmozhnosti}
 
 ### 22.1. + Исправление неработающих таймаутов, если используется TLS. {#ispravlenie-nerabotaiushchikh-taimautov-esli-ispolzuetsia-tls}
@@ -1362,6 +1420,7 @@ N.Vartolomei.
 
 Александр Казаков. Нужно для Яндекс.Метрики и Datalens. Задача постепенно тащится и исправлениями в соседних местах стала менее актуальна.
 В Q1 будет сделана или отменена с учётом 1.2. и 1.3.
+Upd. Добавили таймауты.
 
 ### 22.5. + Исправление редких срабатываний TSan в stress тестах в CI. {#ispravlenie-redkikh-srabatyvanii-tsan-v-stress-testakh-v-ci}
 
@@ -1470,18 +1529,19 @@ Altinity.
 
 [Александр Сапин](https://github.com/alesapin)
 
+
 ## 23. Default Festival. {#default-festival}
 
-### 23.1. + Включение minimalistic\_part\_header в ZooKeeper. {#vkliuchenie-minimalistic-part-header-v-zookeeper}
+### 23.1. + Включение minimalistic_part_header в ZooKeeper. {#vkliuchenie-minimalistic-part-header-v-zookeeper}
 
 Сильно уменьшает объём данных в ZooKeeper. Уже год в продакшене в Яндекс.Метрике.
 Алексей Миловидов, ноябрь 2019.
 
-### 23.2. Включение distributed\_aggregation\_memory\_efficient. {#vkliuchenie-distributed-aggregation-memory-efficient}
+### 23.2. Включение distributed_aggregation_memory_efficient. {#vkliuchenie-distributed-aggregation-memory-efficient}
 
 Есть риски меньшей производительности лёгких запросов, хотя производительность тяжёлых запросов всегда увеличивается.
 
-### 23.3. Включение min\_bytes\_to\_external\_sort и min\_bytes\_to\_external\_group\_by. {#vkliuchenie-min-bytes-to-external-sort-i-min-bytes-to-external-group-by}
+### 23.3. Включение min_bytes_to_external_sort и min_bytes_to_external_group_by. {#vkliuchenie-min-bytes-to-external-sort-i-min-bytes-to-external-group-by}
 
 Желательно 5.2. и 13.1.
 
@@ -1489,7 +1549,7 @@ Altinity.
 
 Есть гипотеза, что плохо работает на очень больших кластерах.
 
-### 23.5. Включение compile\_expressions. {#vkliuchenie-compile-expressions}
+### 23.5. Включение compile_expressions. {#vkliuchenie-compile-expressions}
 
 Требует 7.2. Задачу изначально на 99% сделал Денис Скоробогатов, ВШЭ и Яндекс. Остальной процент доделывал Алексей Миловидов, а затем [Александр Сапин](https://github.com/alesapin).
 
@@ -1514,6 +1574,7 @@ Q1. [Николай Кочетов](https://github.com/KochetovNicolai).
 Возможность mlock бинарника сделал Олег Алексеенков [\#3553](https://github.com/ClickHouse/ClickHouse/pull/3553)
 . Поможет, когда на серверах кроме ClickHouse работает много посторонних программ (мы иногда называем их в шутку «треш-программами»).
 
+
 ## 24. Экспериментальные задачи. {#eksperimentalnye-zadachi}
 
 ### 24.1. Веб-интерфейс для просмотра состояния кластера и профилирования запросов. {#veb-interfeis-dlia-prosmotra-sostoianiia-klastera-i-profilirovaniia-zaprosov}
@@ -1553,7 +1614,7 @@ ClickHouse поддерживает LZ4 и ZSTD для сжатия данных
 
 Смотрите также 24.5.
 
-1.  Шифрование отдельных значений.
+2.  Шифрование отдельных значений.
     Для этого требуется реализовать функции шифрования и расшифрования, доступные из SQL. Для шифрования реализовать возможность добавления нужного количества случайных бит для исключения одинаковых зашифрованных значений на одинаковых данных. Это позволит реализовать возможность «забывания» данных без удаления строк таблицы: можно шифровать данные разных клиентов разными ключами, и для того, чтобы забыть данные одного клиента, потребуется всего лишь удалить ключ.
 
 ### 24.6. Userspace RAID. {#userspace-raid}
@@ -1586,7 +1647,7 @@ RAID позволяет одновременно увеличить надёжн
 
 Дмитрий Ковальков, ВШЭ и Яндекс.
 
-Подавляющее большинство кода ClickHouse написана для x86\_64 с набором инструкций до SSE 4.2 включительно. Лишь отдельные редкие функции поддерживают AVX/AVX2/AVX512 с динамической диспетчеризацией.
+Подавляющее большинство кода ClickHouse написана для x86_64 с набором инструкций до SSE 4.2 включительно. Лишь отдельные редкие функции поддерживают AVX/AVX2/AVX512 с динамической диспетчеризацией.
 
 В первой части задачи, следует добавить в ClickHouse реализации некоторых примитивов, оптимизированные под более новый набор инструкций. Например, AVX2 реализацию генератора случайных чисел pcg: https://github.com/lemire/simdpcg
 
@@ -1598,6 +1659,8 @@ RAID позволяет одновременно увеличить надёжн
 
 Продолжение 24.8.
 
+Upd. Есть pull request.
+
 ### 24.10. Поддержка типов half/bfloat16/unum. {#podderzhka-tipov-halfbfloat16unum}
 
 [\#7657](https://github.com/ClickHouse/ClickHouse/issues/7657)
@@ -1633,6 +1696,7 @@ ClickHouse предоставляет достаточно богатый наб
 В компании nVidia сделали прототип offloading вычисления GROUP BY с некоторыми из агрегатных функций в ClickHouse и обещат предоставить исходники в публичный доступ для дальнейшего развития. Предлагается изучить этот прототип и расширить его применимость для более широкого сценария использования. В качестве альтернативы, предлагается изучить исходные коды системы `OmniSci` или `Alenka` или библиотеку `CUB` https://nvlabs.github.io/cub/ и применить некоторые из алгоритмов в ClickHouse.
 
 Upd. В компании nVidia выложили прототип, теперь нужна интеграция в систему сборки.
+Upd. Интеграция в систему сборки - Иван Лежанкин.
 
 ### 24.13. Stream запросы. {#stream-zaprosy}
 
@@ -1791,7 +1855,7 @@ Amos Bird, но его решение слишком громоздкое и п
 
 ### 25.10. Митапы в России и Беларуси: Москва x2 + митап для разработчиков или хакатон, Санкт-Петербург, Минск, Нижний Новгород, Екатеринбург, Новосибирск и/или Академгородок, Иннополис или Казань. {#mitapy-v-rossii-i-belarusi-moskva-x2-mitap-dlia-razrabotchikov-ili-khakaton-sankt-peterburg-minsk-nizhnii-novgorod-ekaterinburg-novosibirsk-iili-akademgorodok-innopolis-ili-kazan}
 
-Екатерина - организация
+Екатерина - организация. Upd. Проведено два онлайн митапа на русском.
 
 ### 25.11. Митапы зарубежные: восток США (Нью Йорк, возможно Raleigh), возможно северо-запад (Сиэтл), Китай (Пекин снова, возможно митап для разработчиков или хакатон), Лондон. {#mitapy-zarubezhnye-vostok-ssha-niu-iork-vozmozhno-raleigh-vozmozhno-severo-zapad-sietl-kitai-pekin-snova-vozmozhno-mitap-dlia-razrabotchikov-ili-khakaton-london}
 
@@ -1807,7 +1871,8 @@ Amos Bird, но его решение слишком громоздкое и п
 
 ### 25.14. Конференции в России: все HighLoad, возможно CodeFest, DUMP или UWDC, возможно C++ Russia. {#konferentsii-v-rossii-vse-highload-vozmozhno-codefest-dump-ili-uwdc-vozmozhno-c-russia}
 
-Алексей Миловидов и все подготовленные докладчики
+Алексей Миловидов и все подготовленные докладчики.
+Upd. Есть Saint HighLoad online.
 
 ### 25.15. Конференции зарубежные: Percona, DataOps, попытка попасть на более крупные. {#konferentsii-zarubezhnye-percona-dataops-popytka-popast-na-bolee-krupnye}
 
@@ -1848,7 +1913,7 @@ Amos Bird, но его решение слишком громоздкое и п
 
 ### 25.22. On-site помощь с ClickHouse компаниям в дни рядом с мероприятиями. {#on-site-pomoshch-s-clickhouse-kompaniiam-v-dni-riadom-s-meropriiatiiami}
 
-[Иван Блинков](https://github.com/blinkov/) - организация
+[Иван Блинков](https://github.com/blinkov/) - организация. Проверил мероприятие для турецкой компании.
 
 ### 25.23. Новый мерч для ClickHouse. {#novyi-merch-dlia-clickhouse}