Я правильно понимаю, что таймзона в toDateTime только для того, чтоб привести время в нужном поясе в качестве стринг, но она не используется при попытке время привести к секундам? select toDateTime(1535979088, 'Europe/Helsinki'), toDateTime(1535979088), toInt32(toDateTime(1535979088, 'Europe/Helsinki')), toInt32(toDateTime(1535979088)), timezone()

Время всегда хранится как unix timestamp. Таймзона определяет как переводить человекочитаемое время в этот самый таймстамп и обратно. При вызове toDateTime(.. 'Europe/Helsinki') создается таймстам и в ТИПЕ данных (не в самих данных) записывается что показывать этот таймстамп нужно переводя его в тз Хельсинки.

А есть простой способо перевести timestamp в timestamp с учетом часовой зоны?

привет! пожалуйста, дайте совет - как сделать так, чтобы аггрегатная функция count возвращала 0, если записей нет?

Время всегда хранится как unix timestamp. Таймзона определяет как переводить человекочитаемое время в этот самый таймстамп и обратно. При вызове toDateTime(.. 'Europe/Helsinki') создается таймстам и в ТИПЕ данных (не в самих данных) записывается что показывать этот таймстамп нужно переводя его в тз Хельсинки.

А есть простой способо перевести timestamp в timestamp с учетом часовой зоны?

Если int64 недостаточно (макс значение для знакового 9223372036854775807), а float использовать нельзя (тут деньги), то вариантов немного - 1) подождать релиза Decimal, вроде как уже в мастере - попробуйте в тестовой версии, он там на 128 битных интах работает. 2) поразрядно хранить и обрабатывать - просто хранение - без проблем, но арифметика будет утомительна из-за ручного обслуживания переполнений.

А есть примерное понимание когда будет зарелизена поддержка decimal?

Тестовая версия будет в сентябре, примерно

Кто нибудь знает что означает в log файле clickhouse-server значения в квадратных скобках в каждой строке после колонкивремени( например [3], [21] и так далее...)?

thread_number ( Номер потока )

Столкнулся с интересной проблемой: выгружен файл из кликхауса на другом сервере как tsv, смотрел спецсимволы через vi - действительно tsv. Вгружается с помощью Clickhouse-Client в кх в таблицу типа Memory - и вот начинаются странности: строки String становятся числами, причём какой-то рандом. Может, кто-то может объяснить или выразить предположение, отчего так? И я так понимаю DateTime столбец для Memory движка не нужен же?

Столкнулся с интересной проблемой: выгружен файл из кликхауса на другом сервере как tsv, смотрел спецсимволы через vi - действительно tsv. Вгружается с помощью Clickhouse-Client в кх в таблицу типа Memory - и вот начинаются странности: строки String становятся числами, причём какой-то рандом. Может, кто-то может объяснить или выразить предположение, отчего так? И я так понимаю DateTime столбец для Memory движка не нужен же?

Согласно спецификации, первые четыре байта LZ4 - 0x184D2204. Прошёлся по .bin-файлам хексдампом, не нашёл. Походу Кликхаусом пишется raw stream.

Добрый день. Кластер из трёх нод, каждая из которых является репликой для своего шарда и для одного из соседних (перекрёстная репликация). При отвале ноды и её переподключении с восстановлением структуры таблиц ошибка "путь в зукипере уже существует". Можно было бы удалять скриптом, но там значение - массив, который нельзя удалять целиком: replicas:[1,2] Подскажите, как побороть?

Добрый день. Кластер из трёх нод, каждая из которых является репликой для своего шарда и для одного из соседних (перекрёстная репликация). При отвале ноды и её переподключении с восстановлением структуры таблиц ошибка "путь в зукипере уже существует". Можно было бы удалять скриптом, но там значение - массив, который нельзя удалять целиком: replicas:[1,2] Подскажите, как побороть?

Привет, а запрос с sample должен ведь работать быстрее, чем без примерно весгда? У меня есть ReplicatedMergeTree в котороым при сэмплинге выше 0.1 скорость ниже чем без сэмплинга, и я вот слегка затрудняюсь понять что происходит

Есть несколько причин, почему это может быть: 1) Медленно вычисляется хэш-функция. 2) ключ сэмплирования находится после мелко-гранулированная часть PK 3) Ключ сэмплирования не равномерно распределенный в своем типе данных.

sipHash64 я использую, это не intHash32 конечно, но он же вроде бы вставку только должен тормозить, нет? sipHash64 от текстового представления uid который id пользователя. Кажется, что оно должно быть достаточно равномрено в логе событий по поводу 2) не очень понял

https://www.youtube.com/playlist?list=PLQC2_0cDcSKC67lFACl5wAeCOHS6J_XaN

Хороший ключ сэмплирования должен быть легким для чтения и быстро вычислим. Про второй пункт вот пример: Плохо: ORDER BY (Timestamp, sample_key); Хорошо: ORDER BY (CounterID, Date, sample_key). Об этом можно почитать вот тут (https://github.com/yandex/clickhouse-presentations/tree/master/rit2018)

sipHash64 я использую, это не intHash32 конечно, но он же вроде бы вставку только должен тормозить, нет? sipHash64 от текстового представления uid который id пользователя. Кажется, что оно должно быть достаточно равномрено в логе событий по поводу 2) не очень понял

Более правильная ссылка: https://yandex.github.io/clickhouse-presentations/rit2018/

Более правильная ссылка: https://yandex.github.io/clickhouse-presentations/rit2018/

уже есть лучшие практики как правильно проектировать витрину под СН ? типа - джойнов как можно меньше - все кладите в витрину и т.д. и т.п

перенесите себе правки для массивов?

А последовательность столбцов в данных и в запросе INSERT совпадают?

Кажется, я заставил ClickHouse тормозить

В чём юмор про два байта?

Добрый вечер, в документации источника внешнего словаря по http: https://clickhouse.yandex/docs/ru/query_language/dicts/external_dicts_dict_sources/#dicts-external_dicts_dict_sources-http написано, что «Если тип размещения словаря cache и complex_key_cache, то ClickHouse запрашивает необходимые ключи, отправляя запрос методом POST» Можете пожалуйста разъяснить этот момент поподробнее, сейчас сделал внешний словарь на http сервер, и при его использовании на сервер приходит пустой POST запрос. <yandex> <dictionary> <name>ext_test</name> <source> <http> <url>http://localhost/dict.php</url> <format>TabSeparated</format> </http> </source> <layout> <cache> <size_in_cells>10000</size_in_cells> </cache> </layout> <structure> <id> <name>ip</name> </id> <attribute> <name>city_id</name> <type>UInt64</type> <null_value>0</null_value> </attribute> </structure> <lifetime>3600</lifetime> </dictionary> </yandex> select toUInt64(ip),dictGetUInt64('ext_test','city_id',toUInt64(ip)) city_id FROM test.test where hour = 426517 LIMIT 10

Добрый день, возник вопрос: использую официальный JDBC драйвер КХ, пишу разными потоками в разные таблицы через спринговый JdbcTemplate которому подсунут ClickhouseDatasource, стабильно вываливается ошибка Code: 373, e.displayText() = DB::Exception: Session is locked by a concurrent client. Подскажите куда копать?

Доброго дня. Подскажите как быть, КХ генерит ~10 гб данных в день, за пару месяцев забивает диск сервака под завязку. Может кто автоматизировал процесс деатача старых данных и их отправку в долгосрочное хранилище? Либо есть какие-то практики как поступать в подобных случаях?

Для каждого потока укажите отлельную сессию. КХ не разрешает писать паралельно в рамках одной сессии. Параметр session_id

т.е. получается нужно по отдельному датасорсу для каждого потока?

https://youtu.be/Ac2C2G2g8Cg очень крутой доклад

Да, воткните в сервера больше дисков, КХ нормальное долгосрочное хранилище

мы малюсинький стартапчик в котором количество данных планирует увеличиватся(мы надеемся) и если оно увеличится хотя бы в 10 раз мы будем генерировать 100 гб сырых данных в день, в долгосрочной перспективе мы исчерпаем возможности по увелечению диска. а так сырые данные я преображаю и записываю в инфлюкс(получается очень компактно где-то 5 MB инфлюксовских данных равняются выборке из 100 GB сырых). Но руководство и маркетинг хотят по какой-то причине хранить сырые данные

мы малюсинький стартапчик в котором количество данных планирует увеличиватся(мы надеемся) и если оно увеличится хотя бы в 10 раз мы будем генерировать 100 гб сырых данных в день, в долгосрочной перспективе мы исчерпаем возможности по увелечению диска. а так сырые данные я преображаю и записываю в инфлюкс(получается очень компактно где-то 5 MB инфлюксовских данных равняются выборке из 100 GB сырых). Но руководство и маркетинг хотят по какой-то причине хранить сырые данные

Доброго дня, подскажите Python библиотеку для работы с КХ, в которой можно открыть коннект и посылать запросы в рамках одного коннекта, а не открывать новый для каждого нового запроса.

Попробуйте отключить сессии в драйвере, указав session_id как пустую строку

Уточните, почему именно в рамках одного коннекта?

Всем привет Есть таблицы - Потребитель Kafka. - Целевая таблица с необходимой структурой. - И материализованное представление. Материализованное представление перекладывает данные из очереди (потребитель Kafka) в целевую таблицу. Данные поступают непрерывно, и в целевой таблице появляются пачками, в моих тестах через 15 минут. Для моих целей это очень долго, и я хочу управлять этим временем, сделать этот период поменьше. Судя по тому что вижу, матерализованное представление пишет данные пачками по 256 МБ, вроде бы. Сбственно вопрос какими настройками конфигурируется состояние, при котором произойдет запись в целевую таблицу? Уменьшила min_insert_block_size_bytes в 1024 раза до 262144 На всякий случай уменьшила min_insert_block_size_rows до 1024 Но ничего не изменилось

stream_flush_interval_ms ?

Тогда уменьшение max_block_size?

https://github.com/yandex/ClickHouse/blob/master/libs/libdaemon/src/OwnPatternFormatter.cpp

Всем привет Есть таблицы - Потребитель Kafka. - Целевая таблица с необходимой структурой. - И материализованное представление. Материализованное представление перекладывает данные из очереди (потребитель Kafka) в целевую таблицу. Данные поступают непрерывно, и в целевой таблице появляются пачками, в моих тестах через 15 минут. Для моих целей это очень долго, и я хочу управлять этим временем, сделать этот период поменьше. Судя по тому что вижу, матерализованное представление пишет данные пачками по 256 МБ, вроде бы. Сбственно вопрос какими настройками конфигурируется состояние, при котором произойдет запись в целевую таблицу? Уменьшила min_insert_block_size_bytes в 1024 раза до 262144 На всякий случай уменьшила min_insert_block_size_rows до 1024 Но ничего не изменилось

Кто-нибудь дружил КХ и MySQL, если оба в контейнере? КХ не видит MySQL, пишет Poco::Exception. Code: 1000, e.code() = 2002, e.displayText() = mysqlxx::ConnectionFailed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ((nullptr):0), e.what() = mysqlxx::ConnectionFailed

Как выглядит вызов функции?