TimeStamp тоже не вариант использовать, потому что записей бывает по нескольку в мс

TimeStamp тоже не вариант использовать, потому что записей бывает по нескольку в мс

64 битный таймстэмп, наносекунды с эпохи?

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

Ну будет разная версия, с отличием в 5 секунд, разницы не будет если в эти 5 секунд не нужно перезапись сделать

Не очень понял про низкую вероятность перезаписи сразу же, если совпадёт timestamp, то он же перезапишет предыдущие строки. При этом одну из них может и не нужно перезаписывать

Да, про наносекунды как-то не подумал. Это может решить проблему. Ну или взятие хэша...

Не очень понял про низкую вероятность перезаписи сразу же, если совпадёт timestamp, то он же перезапишет предыдущие строки. При этом одну из них может и не нужно перезаписывать

если еще и ключ одинаковый

Да, у нас ключи могут быть одинаковые)

Да, у нас ключи могут быть одинаковые)

может эту проблему стоит решить? ) Добавить source_host туда например

что потом делать с данными где много одинаковых строк, которые так и должны быть одинаковыми?

Ну тут хранятся заранее не определенные строки с заранее не определенными типами, я просто не могу заранее наложить на всё это Primary Key, потому что на ходу может добавиться колонка

В принципе хэш от всего можно считать на клиенте и он даст примерно похожий результат, как и Primary Key

Ну тут хранятся заранее не определенные строки с заранее не определенными типами, я просто не могу заранее наложить на всё это Primary Key, потому что на ходу может добавиться колонка

Какой то айди источника

На стороне клиента Auto_increment сделать затруднительно, так как в одну базу смотрит сразу несколько процессов

UUID?

UUID?

или так

Да, всем спасибо, вроде разобрался)

Ребята добрый вечер! Подскажите такое извращение как вьюшка из словаря может как то быть реализовано. Или просто я чуток туплю. Словари внешние ведь в КХ не отображаются как таблицы.

Всем привет, использую ReplacingMergeTree и столкнулся с ситуацийе (но не даёт гарантий отсутствия дубликатов ...) что даже после OPTIMIZE TABLE остаются дубликаты, Final в селекте помогает исправить ситуацию, но идет фулскан, и это очень долго

У этого движка так же есть столбец версий, можете делать селект с Group by чтобы получать уникальные строки

9 дней назад в коммиты был добавлено support DEDUPLICATE option in OPTIMIZE query

Прикольно

Прикольно, а сейчас есть есть работающий метод удалить дубликаты?

вроде бы гарантированного нет

но ждем комметариев от разработчиков )

Ну тут ведь логика простая. Все операции с данными происходят при слиянии. А гарантированного времени слияния нет.

Как я понял все упирается в это. Можно детально разобрать триггеры слияний и отталкиваться от этого.

Либо не париться и делать доагрегацию запросом

Либо не париться и делать доагрегацию запросом

Имеется ввиду select final?

Или самому агрегировать несагрегированные строки?

Самому

Т.е. CH будет процессить бОльшую часть данных, а все остальное в реалтайме.

Такая рекомендация звучит уже давно, причём вроде как для всех движков которые меняют данные.

Мне вот вообще непонятно когда это должно происходить. Я залил пару миллионов строк, а они вообще не смержились. Есть какие - то настройки, влияющие на это дело?

Мне вот вообще непонятно когда это должно происходить. Я залил пару миллионов строк, а они вообще не смержились. Есть какие - то настройки, влияющие на это дело?

Где то в системных таблицах есть логи мержей если я не ошибаюсь. Либо просто в логах. А вот как срабатывает триггер мержа, я к сожалению в деталях авторитетно не смогу рассказать.

а если пробовать вызвать https://clickhouse.yandex/reference_ru.html#OPTIMIZE

сижу на хакатоне, думаю clickhouse потрогать, успею всё поднять, нормально встает?

в докере если - ваще пять минут)

круть, попробуем тогда c:

Да и без докера ставится одной командой)

и то правда :)

тем более Нетфликс недавно очень крутой доклад подогнал на тему, что в конетйенарх очень много софта работает решительно хуже

тем более Нетфликс недавно очень крутой доклад подогнал на тему, что в конетйенарх очень много софта работает решительно хуже

а поделитесь пожалуйста ссылкой на доклад?

https://www.slideshare.net/brendangregg/container-performance-analysis

там в основном по яве катаются, очень так хорошо =) В основном проблема, что в конетйнере показываются процы от хоста, память от хоста и софт на это ориентируется часто, что приводит.. ни к чему хорошему не приводит

спасибо

Из доки " 2. For aggregation, query results must fit in the RAM on a single server. However, the volume of source data for a query may be indefinitely large." Т.е. если я делаю груп бай, который бежит по миллиарду строк, а после группировки оставляет уже миллион строк, то весь миллион должен уместиться в памяти?

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

Еще вопрос: "This is not a cross-platform system. It requires Linux Ubuntu Precise (12.04) or newer, x86_64 architecture with SSE 4.2 instruction set." - т.е. на Центось КликХаус не поставить?

центос какой версии?

с 7кой явно проблем не будет

6ка... оно ровесник динозавров ) там может быть все что угодно

ну или внутри контейнера вполне себе в центоси будет жить

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

Да, но так же есть external group by и своп )

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

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

В соответствии с 2119, да. https://www.ietf.org/rfc/rfc2119.txt

Вот именно

Еще вопрос: "This is not a cross-platform system. It requires Linux Ubuntu Precise (12.04) or newer, x86_64 architecture with SSE 4.2 instruction set." - т.е. на Центось КликХаус не поставить?

Вопрос про древность софта. На 7-ку он собирается не то чтоб совсем просто, но достаточно просто

7-ая центось по софту как раз где-то на уровне Ubuntu 12.04

если взять gcc и boost из sclo

https://github.com/redsoftbiz/clickhouse-rpm

Спасибо!

А есть какие-нибудь хитрые способы ускорить одноразовую большую вливку в пустую таблицу (например, при восстановлении из дампа)? В mysql, например, иногда помогает перед вливкой удалить ключи и создать их заново уже по окончании вливки.

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

Да, это уже кое-что, попробую, спасибо. Но интересно ещё, может, имеет смысл отключить какие-то внутренние фоновые процессы ClickHouse на время вливки

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

Ну возможно это и так) но я говорю на практике.

И ещё вопрос: нет ли какой-нибудь опции у OPTIMIZE, заставляющей его гарантированно доводить работу до самого конца? Т.е. чтобы можно было в одну команду получить результат, аналогичный результату таких операций: CREATE tmpTable AS myTable; INSERT INTO tmpTable SELECT * FROM myTable FINAL; DROP myTable; RENAME tmpTable TO myTable; Пусть медленно, но без лишних телодвижений с временной таблицей.

Optimize final

Как я понял, optimize final всё же не гарантирует того же результата, что insert into .. select from .. final

OPTIMIZE TABLE [db.]name [PARTITION partition] [FINAL] Просит движок таблицы сделать что-нибудь, что может привести к более оптимальной работе. Если указан PARTITION, то оптимизация будет производиться только для указаной партиции. Если указан FINAL, то оптимизация будет производиться даже когда все данные уже лежат в одном куске.

всем привет а насколько сложно реализовать ALTER TABLE .. ADD COLUMN IF NOT EXIST column <TYPE> [default_expr]?

OPTIMIZE TABLE [db.]name [PARTITION partition] [FINAL] Просит движок таблицы сделать что-нибудь, что может привести к более оптимальной работе. Если указан PARTITION, то оптимизация будет производиться только для указаной партиции. Если указан FINAL, то оптимизация будет производиться даже когда все данные уже лежат в одном куске.

Final всегда будет запускать слияние. Единственное, если таблица реплицированна, запрос будет выполняться асинхронно

Запускать-то он будет, но запуск слияния разве означает, что схлопнуто будет абсолютно всё? Я так понимаю, он означает, что "возможно, что-то будет схлопнуто"

Final насколько я помню гарантирует слияние в одну партицию

А почему у меня optimize final требует указать партицию?

таблица на ReplacingMergeTree

хочется от Алексея или других разработчиков комментария по опции deduplication для optimize

Запускать-то он будет, но запуск слияния разве означает, что схлопнуто будет абсолютно всё? Я так понимаю, он означает, что "возможно, что-то будет схлопнуто"

Будет схлопнуто какое-то подмножество кусков, не факт что все (смерживать одновременно много кусков довольно затратно по памяти). Для этого хотим сделать специальный "флаг" FORCE для OPTIMIZE, который будет иерархически сливать все данные партиции в один кусок.

А почему у меня optimize final требует указать партицию?

Он только на уровне партиций работает (что в каком-то смысле логично).

А правильно я понимаю что обязательное поле типа Date - первый аргумент во всех engine, как раз определяет целевой партишн? а партишины идут по месяцам?

А правильно я понимаю что обязательное поле типа Date - первый аргумент во всех engine, как раз определяет целевой партишн? а партишины идут по месяцам?

Партиционирование по месяцам, да, по этому полю

modification_time в system.parts ? поменяется если я всталю данные на соответствующий ключ?

ок, сам проверю

FINAL OPTIMIZE в итоге сводит сливание всех кусков в один?

или есть дополнительная оптимизация, которая будет дробить партицию на куски ?

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

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

Если все данные будут лежать в одном месяце, и OPTIMIZE'aми вы добьетесь того, чтобы они лежали в одном куске - то да.

Огромное спасибо

Глупый вопрос - делаю запрос: select cluster, count() from metricstats where mtime < (select max(mtime)-7*86400 from metricstats) and version = (select max(version) from metricstats) group by cluster Можно ли как-то его модифицировать, чтобы добавить не только count() с учетом фильтра, но и общее количество записей с группировкой по cluster?

Типо с фильтром и без фильтра?

Ага

Посмотри в сторону countIf