Это всё для Replicated таблиц, но если у вас ценные данные, то конечно нужно реплицировать. Блок это один INSERT, если в нём меньше 1048576 строк, или часть инсерта размером 1048576 строк. Предположим, вы вставляли данные в реплицируемую таблицу и в середине INSERT-а прервалась связь. Были реально ли вставлены данные, неизвестно. Но можно ещё раз повторить вставку (те же данные в том же порядке), и если за это время не было вставлено больше 100 блоков, дублей не будет.

Подробнее в документации: https://clickhouse.yandex/reference_ru.html#%D0%A0%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

все ясно, спасибо

Фича re2: (?!re) before text not matching re (NOT SUPPORTED) https://github.com/google/re2/wiki/Syntax

Спасибо. Жаль.

а impressions в ответе в ~10 раз отличаются?

И всё равно не понятно, откуда такой неравномерный сэмплинг берётся. Посмотрел уникальные значения ключа сэмплирования для разных значений доли сэмпла: select * from (select '1' as samplePart, uniqExact(sampleKey) as keysInSample from fact union all select '0.1' as samplePart, uniqExact(sampleKey) as keysInSample from fact sample 0.1 union all select '0.05' as samplePart, uniqExact(sampleKey) as keysInSample from fact sample 0.05 union all select '0.01' as samplePart, uniqExact(sampleKey) as keysInSample from fact sample 0.01) order by keysInSample desc format TabSeparated 1 3600 0.1 3600 0.05 3276 0.01 655

То есть где-то до 0.05 в сэмпл попадают все ключи

Alter is not finished because timeout when waiting for some replicas Как после такого сообщения понять, когда альтер будет завершен?

То есть где-то до 0.05 в сэмпл попадают все ключи

3600/2^16=0.0549

Ну да, предполагается, что ключ семплирования будет равномерно распределён по всему юниверсуму, а тут он от 0 до 3600

Спасибо.

Только в один

а как вы сами резервируете графиты тогда?

рубрика "Хозяйке на заметку:" А знаете ли вы что у некоторых из вас в следующем релизе всё сломается? Для безопасности мы поменяли listen_host по умолчанию на localhost . всем кто использует соединение с других серверов и конфиг по умолчанию нужно будет вернуть в конфиг <listen_host>::</listen_host> а еще <listen_host> теперь можно указывать несколько раз https://github.com/yandex/ClickHouse/commit/107fb86a40e39deaaa2a00d32fe2f0af6595348b

да мы уже видели в ченджлоге

а где changelog?

это была натужная шутка

А сделайте, плиз, чтобы при INSERT INTO table FORMAT CSV булевские поля воспринимали текст true/false

в clickhouse ведь нет типа boolean

Unit8

Будет работать как boolean

Вот чтобы при вставке в UInt8 текста "true"/"false" из CSV он вставлялся как 1/0 )

А смысл гонять текст и делать для него парсер? :)

Смысла нет, но мы не может изменить код формирователя CSV файла, а он приходит так(

sed ?

Будет работать как boolean

ok, типа нет, но UInt8 будет вести себя как boolean )

Можно, наверное, сделать временную таблицу с типами как полчится, а потом сделать INSERT … FROM SELECT … и навесить функций.

Добрый вечер. Помогите разобраться с тем, как используется ключ сэмплирования при параллельных запросах к репликам. На тестовых запросах по таблице с 4-мя репликами не заметил разницы по времени между max_parallel_replicas 1, 2 и 4

При добавлении секции SAMPLE в запрос он ускоряется пропорционально тому, насколько сэмпл меньше всего объёма данных

Добрый вечер. Помогите разобраться с тем, как используется ключ сэмплирования при параллельных запросах к репликам. На тестовых запросах по таблице с 4-мя репликами не заметил разницы по времени между max_parallel_replicas 1, 2 и 4

max_parallel_replicas работает полностью аналогично SAMPLE: с каждой реплики читается соответствующая доля данных. В общем случае использования SAMPLE, отсутствие ускорения может быть вызвано следующим: - требуется читать и, возможно, вычислять ключ сэмплирования, тогда как в изначальном запросе соответствующие столбцы не использовались; - ключ сэмплирования задан так, что он разбивает данные неравномерно; - в первичном ключе, перед ключом сэмплирования есть столбцы, которые разбивают данные на слишком мелкие куски, внутри каждого из которых, ключ сэмплирования уже не позволяет пропустить достаточное количество строк. В случае max_parallel_replicas отсутствие ускорения может быть вызвано необходимостью передавать по сети и объединять большее количество данных (в случае большого размера промежуточных данных).

max_parallel_replicas работает полностью аналогично SAMPLE: с каждой реплики читается соответствующая доля данных. В общем случае использования SAMPLE, отсутствие ускорения может быть вызвано следующим: - требуется читать и, возможно, вычислять ключ сэмплирования, тогда как в изначальном запросе соответствующие столбцы не использовались; - ключ сэмплирования задан так, что он разбивает данные неравномерно; - в первичном ключе, перед ключом сэмплирования есть столбцы, которые разбивают данные на слишком мелкие куски, внутри каждого из которых, ключ сэмплирования уже не позволяет пропустить достаточное количество строк. В случае max_parallel_replicas отсутствие ускорения может быть вызвано необходимостью передавать по сети и объединять большее количество данных (в случае большого размера промежуточных данных).

А как можно посмотреть объём промежуточных данных, передаваемых по сети?

Примерно оценить - если есть GROUP BY с большим результатом, DISTINCT, ORDER BY без маленького лимита и т. п., то объём передаваемых по сети промежуточных данных может быть большим. Посмотреть вживую - используя утилиту dstat во время выполнения запроса.

это была натужная шутка

Мы рождены, чтоб шутку сделать былью! https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

Alter is not finished because timeout when waiting for some replicas Как после такого сообщения понять, когда альтер будет завершен?

Пойти на указанную реплику, посмотреть лог по слову ALTER.

Привет. Можно ли как-то разделить в http-запросе SELECT и значения, которые мы в него подставляем? Или нет, из коробки ничего такого нет, экранируйте кавычки сами?

Мы рождены, чтоб шутку сделать былью! https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

Еееее

Привет. Можно ли как-то разделить в http-запросе SELECT и значения, которые мы в него подставляем? Или нет, из коробки ничего такого нет, экранируйте кавычки сами?

Такого нет. Да, экранируем.

дурацкий вопрос - в выражении if(a, b, c) вычисляется ли б) если выражение а) - false?

такое ощущение что b,c - считаются вне зависимости от a)

Да, так и есть.

тут скрытый смысл?)

просто никак не мог понять почему выдавало ошибку на преобразование типов

Да, так проще сделать вычисление над пачками значений, а не по отдельности. Но когда один из аргументов - сложное выражение, то это вредно.

странновато ну да ладно)

Всем привет. А никто не сталкивался с задачей расчета LTV(lifetime value) по данным из КХ? Пока вижу только вариант выгрузки данных из КХ в excel c последующей экстроляция их экселевким солвером. Но чувствую есть варианты более удобные, может быть есть что-то внутри КХ для экстраполяции?

вопрос - а LIMIT BY с какой версии будет работать. Что то пропустил)) Спасибо заранее

И еще вопрос. У нас сейчас на проде версия 1.1.54010, хотим обновиться на актуальную, но страшно. Какой шанс потерять данные или получить даунтайм? Может стоит через промежуточные?

Или лучше в начале поднять актуальную версию и на нее реплицировать данные? Сейчас репликация не используется

вопрос - а LIMIT BY с какой версии будет работать. Что то пропустил)) Спасибо заранее

С января 2017. Если не ошибаюсь, это версия 1.1.54134.

Всем привет. А никто не сталкивался с задачей расчета LTV(lifetime value) по данным из КХ? Пока вижу только вариант выгрузки данных из КХ в excel c последующей экстроляция их экселевким солвером. Но чувствую есть варианты более удобные, может быть есть что-то внутри КХ для экстраполяции?

Встроенного нет. Если формула простая, то может быть, можно прямо в SQL изобразить.

И еще вопрос. У нас сейчас на проде версия 1.1.54010, хотим обновиться на актуальную, но страшно. Какой шанс потерять данные или получить даунтайм? Может стоит через промежуточные?

Шанса потерять данные из-за обновления нет. Можете обновляться спокойно. Это делается путём установки нового пакета и перезапуска сервера.

Встроенного нет. Если формула простая, то может быть, можно прямо в SQL изобразить.

У меня есть вариант реализации, через solver в excel. Там формула с 3 переменными значения которых подбираются под известные данные через GRG Nonlinear. В принципе представляю как все реализовать на SQL, кроме подбора этих переменных.

Наверное, это не получится сейчас сделать только средствами ClickHouse.

С января 2017. Если не ошибаюсь, это версия 1.1.54134.

Спасибо

похоже в пакете для Убунту 14/04 баг

sudo service clickhouse-server start

/etc/init.d/clickhouse-server: 303: [: stop: unexpected operator {start|stop|status|restart|forcestop|forcerestart|reload|condstart|condstop|condrestart|condreload|initdb} Stop clickhouse-server service:

:(

шелл?)

Да, это так. Тем не менее, пакет работоспособен. Исправили в master-е.

шел вижу /bin/sh

на что менять? на /bin/bash?

вроде да. Тут по моему уже задавали подобный вопрос

в поиске

запустился :)

да! спасибо за наводку :)

Алексей, а вы спите иногда?))

судя по всему кочует из часового пояса в часовой пояс)

в rspamd используется модуль clickhouse. Неплохо.

а зачем?

я вот к fastnetmon прикручиваю :)

для netflow CH почти идеальное хранилище

Вопрос по образу докера - новый образ root@dd363fb012f7:/# apt-get update E: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (2: No such file or directory)

ну про netflow речь вообще не идет. КХ как будто для него и создан)) Если не секрет а чем льете туда? скриптом?

кастомный коллектор же

https://github.com/pavel-odintsov/fastnetmon/blob/master/src/netflow_plugin/netflow_collector.cpp

в общем виде его залить в CH сложно

там тогда получается нужно отдельную таблицу на каждое устройство, если хранить все доступные поля

я упростил себе жизнь и хочу заливать лишь поддерживаемый всеми subset полей

давно это было уже лет 6 назад)) зачем? там же формат нетфлоу обычный. Мы например хранили полей 20. Не больше. Правда били потом на куски. По дням по моему.

или там все поменялось? с тех пор)

netflow9 еще более-менее стандартен

IPFIX - там полноценная поддержка любых полей внутри шаблона

то есть прилететь может все что угодно, страна, например, уровень доверия к IP (от какого-нибудь дивайса с этим )

)) да. когда я работал такого не было)))

это я думаю был netflow5

он прост как кирпич

struct NF5_FLOW { u_int32_t src_ip, dest_ip, nexthop_ip; u_int16_t if_index_in, if_index_out; u_int32_t flow_packets, flow_octets; u_int32_t flow_start, flow_finish; u_int16_t src_port, dest_port; u_int8_t pad1; u_int8_t tcp_flags, protocol, tos; u_int16_t src_as, dest_as; u_int8_t src_mask, dst_mask; u_int16_t pad2; } __packed;

и фсе

а вот если netflo9/ipfix, то все плохо

каждый дивайс генерирует структуру динамически, высылает ее каждые 30 секунд (обычно)

@pavel_odintsov я пока думаю над записю в ch ipfix с nat машини

и ее нужно в рантайме собрать в "а-ля структуру" и выдернуть нужные поля

nat events?

я думаю должно быть просто

ага

там просто вот только приемник нужно сделать (наверно как обычно - на го)