Мы выставили за прокси и CH и webgui. В хост порт надо писать со слэшем в конце, работает

ЧЯДНТ? https:/site.com/styles/vendor-3f2c460027.css 404

т.е. за прокси с относительным путем /frontend/ фронтэнд запрашивает из корня. это должно работать?

ЧЯДНТ? https:/site.com/styles/vendor-3f2c460027.css 404

Я поправил index.html, дописав location в путях до статики

<base href="http://guiclickhouse.smi2.ru/">

в кх есть where, а есть prewhere

При этом оптимизатор может решить перенести where в prewhere, но если есть понимание, что после where данных будет мало, лучше явно prewhere задать

Привет. А можите направить меня как лучше в кластере удалять по месяцам?

Alter table drop partition на каждом шарде. А в чём вопрос?

Alter table drop partition на каждом шарде. А в чём вопрос?

Так и сделал. Выполнил запрос на удаление на каждой реплике. Для верности. Еще момент что если дата при импорте не проставляется, то надо удалять партицию 197001

Ребят, а тут некоторые писали, что с кафкой есть опыт

может кто отозваться, есть пара вопросов

Используем, но пока не с CH. Но работаем над тем чтоб flink докрутить до правильной загрузки в CH.

В чем вопрос?

Ребят, а тут некоторые писали, что с кафкой есть опыт

Добрый ! каков вопрос?

Добрый ! подскажите как лучше организовать данные в КХ. есть товары и есть их категории, каждый товар может относится сразу к нескольким категориям. Под категориями понимаются как нормальные иерархические категории (типа мобильный телефон ) так и некоторые специфические (например, "распродажа июля" и т.п.) есть 2 идеи: 1.сделать в таблице поля goods + category[], где последнее поле это массив 2. сделать несколько записей для каждого товара т.е. goods + category, и для каждого товара делать столько строк в скольких категориях он состоит... запросу будут потом стандартные типа вывести список товаров входящих в ту или иную категорию и т.п.

На всякий спрошу: вы не собираетесь часом использовать КХ в качестве основного хранилища?

На всякий спрошу: вы не собираетесь часом использовать КХ в качестве основного хранилища?

нет... туда будет сливаться поток покупок с основного хранилища... ну и дальше хотим анализ всякий делать

можно ".сделать в таблице поля goods + category[], где последнее поле это массив" А если надо развернуть с строки типо "товар, категория", то для этого потом сделать Array Join

будет ли это не хуже чем ручное развертывание перед записью в базу? просто мне кажется что массив будет не очень эффективно храниться...

Массив будет хорошо работать. Но хранить лучше только категории в которых непосредственно лежит товар

Родительские категории лучше хранить в иерархическом словаре

Массив будет хорошо работать. Но хранить лучше только категории в которых непосредственно лежит товар

А как орагнизовано хранение массива? Есть ли какие-нибудь рекомендации по количеству элементов (например, если у меня будет их 500)? Будут ли хорошо работать строковые массивы?

Лучше чтобы был массив интов конечно

А зачем для категорий строки?

Но в любом случае массив будет лучше, чем множить записи

Здравствуйте, может кто пожалуйста подсказать как в clickhouse jdbc делать пакетное выполнение запросов (batch)?

делаю как в других выдает java.sql.SQLFeatureNotSupportedException

DataSource ds = new ClickHouseDataSource("jdbc:clickhouse://localhost:8123/default"); Connection dbConnection = ds.getConnection("default", ""); String insertTableSQL = "INSERT INTO Measure" + "(Id_Measure, value, date_metric, id_meter,user_id, resource) " + "VALUES" + "(?,?,?,?,?,?)"; PreparedStatement pstmt = dbConnection.prepareStatement(insertTableSQL); Random random = new Random(); int currentBatch = 0; int batchSize = 5000; for (Integer i = 10; i < 100000; i++) { pstmt.setObject(1, i.toString()); pstmt.setObject(2, random.nextDouble()); Integer i1 = random.nextInt(5) + 1; pstmt.setObject(3, new Date(1994,12,12)); pstmt.setObject(4, i1.toString()); Integer i2 = random.nextInt(4) + 1; pstmt.setObject(5, i2.toString()); pstmt.setObject(6, i2.toString()); currentBatch++; if (currentBatch <= batchSize) { pstmt.addBatch(); } else { pstmt.executeBatch(); currentBatch = 0; } } if (currentBatch != 0) { pstmt.executeBatch(); } dbConnection.close();

Можно ли привести конфигурацию таблиц, конфигурацию кластера и примеры запросов с временем выполнения? Можно в почту на clickhouse-feedback. Вдруг получится догадаться.

К сожалению не успел вчера отправить запрошенную информацию на почту. Выслал сегодня. В письме продублировал вопрос

А зачем для категорий строки?

ну это я так на перспективу спросил.... т.е. массивы будут лучше чем несколько строк? странно а я думал наоброт...она же колонки быстрее должна тащить... или массивы то же как то магически хранятся (со сжатием и всем таким)?

DataSource ds = new ClickHouseDataSource("jdbc:clickhouse://localhost:8123/default"); Connection dbConnection = ds.getConnection("default", ""); String insertTableSQL = "INSERT INTO Measure" + "(Id_Measure, value, date_metric, id_meter,user_id, resource) " + "VALUES" + "(?,?,?,?,?,?)"; PreparedStatement pstmt = dbConnection.prepareStatement(insertTableSQL); Random random = new Random(); int currentBatch = 0; int batchSize = 5000; for (Integer i = 10; i < 100000; i++) { pstmt.setObject(1, i.toString()); pstmt.setObject(2, random.nextDouble()); Integer i1 = random.nextInt(5) + 1; pstmt.setObject(3, new Date(1994,12,12)); pstmt.setObject(4, i1.toString()); Integer i2 = random.nextInt(4) + 1; pstmt.setObject(5, i2.toString()); pstmt.setObject(6, i2.toString()); currentBatch++; if (currentBatch <= batchSize) { pstmt.addBatch(); } else { pstmt.executeBatch(); currentBatch = 0; } } if (currentBatch != 0) { pstmt.executeBatch(); } dbConnection.close();

Я бы начал проверять по порядку: 0. По умолчанию в датасорсе стоит очень маленький таймаут на соединение (вроде 50 мс). Если проблема в нём (можно понять по внимательному изучению cause исключения), то лечится так: ClickHouseProperties properties = new ClickHouseProperties(); properties.setConnectionTimeout(10 * 1000); return new ClickHouseDataSource("jdbc:clickhouse://localhost:8123/default", properties); 1. Есть ли какие-то подробности в cause бросаемого исключения? На какой строчке происходит исключение? Какой его стэк трейс? 2. Есть ли таблица Measure в базе default 3. Совпадает ли схема таблицы по типа с тем, что мы в неё заливаем. 4. Ещё подозрительно использование setObject в вашем случае, когда вам известен тип вставляемых значений.

Exception в pstmt.addBatch() возникает

Все работает, если не использовать batch, т.е. По одному инсерту

Setobject это я эксперементировал, так там типы явно указать можно конечно

Сейчас попробую, то что вы посоветовали

Exception в pstmt.addBatch() возникает

А cause/message у него какой?

java.sql.SQLFeatureNotSupportedException

Exception in thread "main" java.sql.SQLFeatureNotSupportedException at ru.yandex.clickhouse.ClickHousePreparedStatementImpl.addBatch(ClickHousePreparedStatementImpl.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at ru.yandex.clickhouse.util.LogProxy.invoke(LogProxy.java:42) at com.sun.proxy.$Proxy3.addBatch(Unknown Source) at com.mycompany.javaapplication1.Test.main(Test.java:51)

java.sql.SQLFeatureNotSupportedException

Попробуйте его отловить в коде, встать на дебаге, и посмотреть e.getMessage() и e.getCause(). Вообще, стоит пройтись по стек трейсу до точки, где оно непосредственно выбрасывается. Код JDBC драйвера довольно простой у ClickHouse

Сразу станет ясно, какая валидация не прошла при выполнении addBatch

Да просто не реализовано

Что там ловить

Не реализовано пакетное выполнение запросов в jdbc clickhouse?

https://github.com/yandex/clickhouse-jdbc/blob/master/src/main/java/ru/yandex/clickhouse/ClickHousePreparedStatementImpl.java#L320

Вообще, реализовано

Возможно, старая версия?

Вообще не старая, но изменил версию и заработало, спасибо)

Всем привет, подскажите, пожалуйста, как правильно записывать данные в кликхауз: У меня есть таблица, которая хранит информацию пользователя о переходах по страницам сайта и дополнительные параметры Должен ли я предварительно записывать данные в промежуточное хранилище, или сразу записывать данные в таблицу кликхауза с типом buffer?

Зависит от числа событий.

Чем больше вы можете сделать батч для вставки

Тем лучше

Т.е. если событий много, то лучше сразу одним батчем писать в кликхауз, а при небольшом количестве событий - использовать промежуточное хранилище?

не, смотрите

если у вас данные итак уже где-то имеются, а не поступают равномерном поштучно, условно

то просто собирайте их по 100-1000 штук и вставляйте в CH

буфер таблица в этом случае совершено не нужна

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

но буфер таблица - тоже своеобразная штука, CH не особо быстр, если в него вваливать сотни тысяч/миллионы записей в секунду в эту таблциу

Спасибо большое, вы очень помогли! :)

Добрый день! А какой алгоритм сжатия использует КХ для хранения таблиц на диске (*MergeTree) и можно ли как-то настройками потюнить коэффициент сжатия? В доке не нашел ничего по этому поводу, только размер блока несжатых данных (по-умолчанию, 1MiB)

Добрый день! А какой алгоритм сжатия использует КХ для хранения таблиц на диске (*MergeTree) и можно ли как-то настройками потюнить коэффициент сжатия? В доке не нашел ничего по этому поводу, только размер блока несжатых данных (по-умолчанию, 1MiB)

По-умолчанию используется LZ4 (для достаточно больших кусков данных, маленькиt хранятся как есть). Можно выбрать другой метод сжатия (zstd). Подробнее тут https://github.com/yandex/ClickHouse/blob/master/dbms/src/Server/config.xml#L197

Спасибо большое! А compression rate можно настраивать?

а есть сравнения эффективности?

Вот да

https://fastcompression.blogspot.ru/2015/01/zstd-stronger-compression-algorithm.html Пока нашел вот, zstd рвет по скорости (компрессии)

Но в остальном сомнительно, что он круче lz4

я боюсь это шибко зависит от проца

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

если тянет zstd и не проваливается по скорости - вперед с песней :)

Но у zstd, как я понял, скорость декомпрессии раза в 3 ниже, чем lz4

А это скажется на скорости запросов

При одинаковом compression ratio zstd лучше, чем lz4 по всем параметрам. Но обычно им все же пытаются пожать получше, и тогда выигрыш или неочевиден, или его нет. Какие настройки в ClickHouse -- это вопрос к Яндексу, но думаю, что там нет особого проигрыша

Кстати, было бы неплохо поддержать еще и brotli -- колонки со строками и всяким json должен жать значительно лучше и быстрее (правда, скорее всего только английскими)

бротли Алексей вроде на митапе предлагал

подняло руки за него примерно 0 человек )

Я что-то нигде не нашёл, где zstd обыгрывает lz4 при схожем compression ratio по скорости

Скорее, выходит наоборот

Кажется, что наоборот. Судя по этой статье, с учётом времени на передачу, zstd выгоднее при данных размером примерно до 32 MiB, а выше — уже lz4 https://fastcompression.blogspot.ru/2015/01/zstd-stronger-compression-algorithm.html

По скорости компресии и декомпресии выигрывает lz4, при том коэффициент сжатия почти не отличается (2.7-2.8)

Статья древняя. Померяйте -- увидите. За бротли никто не поднял, видимо, потому что о нем мало знают

Возможно. Кстати, сам фейсбук показывает, что lz4 по скорости раза в 3 быстрее zstd, правда там и ratio чуть хуже получается https://github.com/facebook/zstd

Правда, там же пишут, что можно играться с настройками и повышать скорость zstd за счет ratio

zstd у нас используется с level = 1

А lz4?

Там нет привычных уровней. Есть lz4 и lz4hc. Плюс некоторые уровни для ускорения сжатия. Мы используем обычный lz4.

@milovidov_an скажи, а не расследовали причины "bad size of marks file"? Просто последнее время часто что-то в чатах начала всплывать такая ошибка у людей

Мы ещё не нашли причину. Есть два сообщения, но пока непонятны условия, при которых это проявляется. В одном случае подозрение на ALTER Enum в Nested. В другом - не так (обычный String столбец). Сами с таким не сталкивались.

Там нет привычных уровней. Есть lz4 и lz4hc. Плюс некоторые уровни для ускорения сжатия. Мы используем обычный lz4.

Спасибо за пояснение!

Кстати, было бы неплохо поддержать еще и brotli -- колонки со строками и всяким json должен жать значительно лучше и быстрее (правда, скорее всего только английскими)

да, про brotli был опрос. можете поднять руку сейчас

<base href="http://guiclickhouse.smi2.ru/">

Ага, спасибо

сейчас еще подумаю как нормально докер-файл написать чтобы из ENV брать эту настройку

В каком нить пхп getenv() в других языках тоже аналоги думаю есть

Пытался воспользоваться настройками input_format_allow_errors_num и input_format_allow_errors_ratio, чтобы пропускать при вставке битые строчки. Прописал в файле users.xml в блоке default эти параметры со значениями 1 и 0.1 соответственно. При запуске сервера настройки подхватились, но при выполнении внешнего запроса на вставку из файла CH все равно ругается на неправильную строчку. Что не так делаю, подскажите пожалуйста?

Отправляете с помощью clickhouse-client или по HTTP? Если первое - надо указать эти настройки параметрами командной строки для клиента. PS. Вы прописали, что максимально можно пропустить одну строку с ошибкой или 0.1 долю от ранее прочитанных строк.

Отправляете с помощью clickhouse-client или по HTTP? Если первое - надо указать эти настройки параметрами командной строки для клиента. PS. Вы прописали, что максимально можно пропустить одну строку с ошибкой или 0.1 долю от ранее прочитанных строк.

С помщью clickhouse-client. Все понял спасибо за ответ

При одинаковом compression ratio zstd лучше, чем lz4 по всем параметрам. Но обычно им все же пытаются пожать получше, и тогда выигрыш или неочевиден, или его нет. Какие настройки в ClickHouse -- это вопрос к Яндексу, но думаю, что там нет особого проигрыша

На моих данных zstd может 52.6% за224 секунды. xz с нашими параметрами дает 45.7% за 238с. Но из xz можно выжать еще ~10%, а zstd ниже 50% выйти не получается вообще.