DC
toUInt64() и возможно придется добавить intDiv в зависимости от хранимой точности
toUInt64 сделает только секунды
Size: a a a
2020 July 14
VB
да, отдало только секунлды
DC
ребят, подскажите плз как достать таймстемп из
DateTime64 с точностью до миллисекундникак, парсить строку
VB
жаль
ну да ладно
ну да ладно
VB
спасибо
VB
toUInt64() и возможно придется добавить intDiv в зависимости от хранимой точности
DC
когда-нибудь появится функция reinterpretAsUInt64
DT
вообще неожиданно если честно.
DC
вообще неожиданно если честно.
МШ
временные таблицы, или сложить все массив в with
если правильно понимаю, with допускает только 1 строку в запросе...
VB
@den_crane @unamedrus поборол )
DC
Михаил Ш
если правильно понимаю, with допускает только 1 строку в запросе...
одно значение даже. Сколько всего строк в рубриках ?
МШ
одно значение даже. Сколько всего строк в рубриках ?
в среднем в одной выборке - около 2млн (результат фильтрации по признаку + датам), иногда до 5млн. Общее число записей в таблице около 10млрд
DC
Михаил Ш
в среднем в одной выборке - около 2млн (результат фильтрации по признаку + датам), иногда до 5млн. Общее число записей в таблице около 10млрд
оставьте все как в изначальном запросе тогда
МШ
Это значит "там все не супер плохо" или "на таких мелочах нечего тюниться"? :)
DC
Михаил Ш
Это значит "там все не супер плохо" или "на таких мелочах нечего тюниться"? :)
думаю лучше не станет.
ну или можно попробовать с временной таблицей
еще можно группировку сделать в запросе к items
ну или можно попробовать с временной таблицей
еще можно группировку сделать в запросе к items
IZ
Добрый день! Наблюдаю проблему с тем, что конфигурация rollup в GraphiteMergeTree в какой-то момент перестала выполнять агрегацию. Версия кликхаус
Настройки rollup:
Конфигурация таблицы:
Запрос метрики за 17.06.2020 (сегодня 14.07.2020) возвращает метрики с интервалом в 1 сек, хотя согласно настройкам метрика должна остаться 1 метрика за 30 мин.
А запрос метрики за 16.06.2020 возвращает метрики с интервалом в 1 минуту, и тоже не подходит не под одно правило
Метрики за 26.06.2020 хранятся по одной секунде, а уже за 27.06.2020 - по одной минуте.
При выполнении OPTIMIZE получаю следующее:
Сами размеры партиций меньше, чем размер на диске, требуемый для выполнения OPTIMIZE:
Правильно ли я понимаю, что rollup не может выполниться из-за нехватки места на диске? если это так, то какие минимальные требования по размеру диска нужно закладывать при проектировании, если в качестве хранилища graphite метрик использовать clickhouse? Записываются ли в логи ошибки слияния партиций, чтобы по ним можно было сразу среагировать на невыполненное слияние?
ClickHouse server version 19.8.3.8 (official build). Настройки rollup:
<graphite_rollup>
<path_column_name>Path</path_column_name>
<time_column_name>Time</time_column_name>
<value_column_name>Value</value_column_name>
<version_column_name>Timestamp</version_column_name>
<default>
<function>avg</function>
<retention>
<age>0</age>
<precision>1</precision>
</retention>
<retention>
<age>86400</age>
<precision>60</precision>
</retention>
<retention>
<age>864000</age>
<precision>900</precision>
</retention>
<retention>
<age>1728000</age>
<precision>1800</precision>
</retention>
</default>
</graphite_rollup>
Конфигурация таблицы:
CREATE TABLE graphite (`Path` String, Value Float64, Time DateTime, Date Date, Timestamp UInt32) ENGINE = GraphiteMergeTree('graphite_rollup') PARTITION BY toYYYYMM(Date) ORDER BY (Path, Time) SETTINGS index_granularity = 8192Запрос метрики за 17.06.2020 (сегодня 14.07.2020) возвращает метрики с интервалом в 1 сек, хотя согласно настройкам метрика должна остаться 1 метрика за 30 мин.
SELECT *
FROM graphite
WHERE (Date = '2020-06-17') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2
┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │ 4 │ 2020-06-17 23:59:59 │ 2020-06-17 │ 1592427599 │
│ statsd.numStats │ 4 │ 2020-06-17 23:59:58 │ 2020-06-17 │ 1592427598 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘
А запрос метрики за 16.06.2020 возвращает метрики с интервалом в 1 минуту, и тоже не подходит не под одно правило
SELECT *
FROM graphite
WHERE (Date = '2020-06-16') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2
┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │ 4 │ 2020-06-16 23:59:00 │ 2020-06-16 │ 1592341199 │
│ statsd.numStats │ 4 │ 2020-06-16 23:58:00 │ 2020-06-16 │ 1592341139 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘
Метрики за 26.06.2020 хранятся по одной секунде, а уже за 27.06.2020 - по одной минуте.
При выполнении OPTIMIZE получаю следующее:
## SET optimize_throw_if_noop = 1
## OPTIMIZE TABLE graphite PARTITION 202007 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 191.81 GB.
## OPTIMIZE TABLE graphite PARTITION 202006 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 124.50 GB.
Сами размеры партиций меньше, чем размер на диске, требуемый для выполнения OPTIMIZE:
SELECT
table,
sum(rows),
partition,
count() AS number_of_parts,
formatReadableSize(sum(bytes)) AS sum_size
FROM system.parts
WHERE table = 'graphite'
GROUP BY
table,
partition
ORDER BY partition ASC
┌────table─┬──────sum(rows)─┬─partition─┬─number_of_parts─┬─sum_size───┐
│ graphite │ 7171581973 │ 202006 │ 9 │ 57.98 GiB │
│ graphite │ 14093390942 │ 202007 │ 619 │ 89.65 GiB │
└──────────┴────────────────┴───────────┴─────────────────┴────────────┘
Правильно ли я понимаю, что rollup не может выполниться из-за нехватки места на диске? если это так, то какие минимальные требования по размеру диска нужно закладывать при проектировании, если в качестве хранилища graphite метрик использовать clickhouse? Записываются ли в логи ошибки слияния партиций, чтобы по ним можно было сразу среагировать на невыполненное слияние?
МШ
думаю лучше не станет.
ну или можно попробовать с временной таблицей
еще можно группировку сделать в запросе к items
ну или можно попробовать с временной таблицей
еще можно группировку сделать в запросе к items
понял, спасибо
АФ
Всем привет, есть такая проблема. Примерно 2к селектов в секунду. Сначала всё ок. А потом начинает возвращать ошибку, что вся память закончилось. Не подскажите как решить? Кликхаус не умеет высвобождать память? Или нужно set max_memory_usage перед каждым запросом выставлять?
DC
Добрый день! Наблюдаю проблему с тем, что конфигурация rollup в GraphiteMergeTree в какой-то момент перестала выполнять агрегацию. Версия кликхаус
Настройки rollup:
Конфигурация таблицы:
Запрос метрики за 17.06.2020 (сегодня 14.07.2020) возвращает метрики с интервалом в 1 сек, хотя согласно настройкам метрика должна остаться 1 метрика за 30 мин.
А запрос метрики за 16.06.2020 возвращает метрики с интервалом в 1 минуту, и тоже не подходит не под одно правило
Метрики за 26.06.2020 хранятся по одной секунде, а уже за 27.06.2020 - по одной минуте.
При выполнении OPTIMIZE получаю следующее:
Сами размеры партиций меньше, чем размер на диске, требуемый для выполнения OPTIMIZE:
Правильно ли я понимаю, что rollup не может выполниться из-за нехватки места на диске? если это так, то какие минимальные требования по размеру диска нужно закладывать при проектировании, если в качестве хранилища graphite метрик использовать clickhouse? Записываются ли в логи ошибки слияния партиций, чтобы по ним можно было сразу среагировать на невыполненное слияние?
ClickHouse server version 19.8.3.8 (official build). Настройки rollup:
<graphite_rollup>
<path_column_name>Path</path_column_name>
<time_column_name>Time</time_column_name>
<value_column_name>Value</value_column_name>
<version_column_name>Timestamp</version_column_name>
<default>
<function>avg</function>
<retention>
<age>0</age>
<precision>1</precision>
</retention>
<retention>
<age>86400</age>
<precision>60</precision>
</retention>
<retention>
<age>864000</age>
<precision>900</precision>
</retention>
<retention>
<age>1728000</age>
<precision>1800</precision>
</retention>
</default>
</graphite_rollup>
Конфигурация таблицы:
CREATE TABLE graphite (`Path` String, Value Float64, Time DateTime, Date Date, Timestamp UInt32) ENGINE = GraphiteMergeTree('graphite_rollup') PARTITION BY toYYYYMM(Date) ORDER BY (Path, Time) SETTINGS index_granularity = 8192Запрос метрики за 17.06.2020 (сегодня 14.07.2020) возвращает метрики с интервалом в 1 сек, хотя согласно настройкам метрика должна остаться 1 метрика за 30 мин.
SELECT *
FROM graphite
WHERE (Date = '2020-06-17') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2
┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │ 4 │ 2020-06-17 23:59:59 │ 2020-06-17 │ 1592427599 │
│ statsd.numStats │ 4 │ 2020-06-17 23:59:58 │ 2020-06-17 │ 1592427598 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘
А запрос метрики за 16.06.2020 возвращает метрики с интервалом в 1 минуту, и тоже не подходит не под одно правило
SELECT *
FROM graphite
WHERE (Date = '2020-06-16') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2
┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │ 4 │ 2020-06-16 23:59:00 │ 2020-06-16 │ 1592341199 │
│ statsd.numStats │ 4 │ 2020-06-16 23:58:00 │ 2020-06-16 │ 1592341139 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘
Метрики за 26.06.2020 хранятся по одной секунде, а уже за 27.06.2020 - по одной минуте.
При выполнении OPTIMIZE получаю следующее:
## SET optimize_throw_if_noop = 1
## OPTIMIZE TABLE graphite PARTITION 202007 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 191.81 GB.
## OPTIMIZE TABLE graphite PARTITION 202006 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 124.50 GB.
Сами размеры партиций меньше, чем размер на диске, требуемый для выполнения OPTIMIZE:
SELECT
table,
sum(rows),
partition,
count() AS number_of_parts,
formatReadableSize(sum(bytes)) AS sum_size
FROM system.parts
WHERE table = 'graphite'
GROUP BY
table,
partition
ORDER BY partition ASC
┌────table─┬──────sum(rows)─┬─partition─┬─number_of_parts─┬─sum_size───┐
│ graphite │ 7171581973 │ 202006 │ 9 │ 57.98 GiB │
│ graphite │ 14093390942 │ 202007 │ 619 │ 89.65 GiB │
└──────────┴────────────────┴───────────┴─────────────────┴────────────┘
Правильно ли я понимаю, что rollup не может выполниться из-за нехватки места на диске? если это так, то какие минимальные требования по размеру диска нужно закладывать при проектировании, если в качестве хранилища graphite метрик использовать clickhouse? Записываются ли в логи ошибки слияния партиций, чтобы по ним можно было сразу среагировать на невыполненное слияние?
rollup делается во время мержей. Мержи букают 2 размера суммарного исходных партов.
<function>avg</function> -- считается неправильно, потому что это avg