MergeTree требует функцию для партиционирования, по-умолчанию - от даты. Где-то в недрах док есть пример по созданию таблиц с кастомным ключом.

MergeTree вообще не требует партиционирования. Можно использовать без партиционирования - не указывать PARTITION BY: https://clickhouse.yandex/docs/ru/single/#proizvolnyi-klyuch-particzionirovaniya

Привет! а можно ли методом Detach / Attach изменить гранулированность индекса до, 32768 строк, например?

Привет! а можно ли методом Detach / Attach изменить гранулированность индекса до, 32768 строк, например?

Нет, гранулированность индекса нельзя так изменить.

только экспортом в native и имтортом?

Можно INSERT SELECT.

Спасибо, буду пробовать

Кто-то подбирал оптимальный размер грануляции для хранения метрик из графита?

сжатых данных - единицы ТБ( в графите)

index_granularity (почти) не влияет на сжатие данных.

а что влияет?

как увеличить размер партишена?

сейчас это умолчальные ГГГГ-ММ

ребят а никто не скажет почему DATEADD в PowerPivot перестал работать?

Всем привет. А кто-нибудь замечал катастрофическое падение производительности при работе с вьюхами (нематериализованными)? Есть таблица MergeTree, несколько миллиардов записей, простой запрос вида получить количество строк, min/max по одному полю работает за пару секунд, скорость обработки в районе полутора миллиардов строк в секунду. Вьюха вида create view as select field_list from table выдает 7-8 миллионов стров в секунду

С view сейчас все плохо, они не пробрасывают условия в запросе. Они сначала выполняют запрос который был указан при создании, а потом к результату применяют условие

народ, подскажите, если в настройках сервера стоит utc timezone, а на сервере msk, при работе с фукциями времени из клиента kshvakov будет учитываться msk?

там сейчас (в клиенте) все плохо с датами, по сути это из-за того, что у нас все в UTC и небыло необходимости реализовывать нормальную работу. Сейчас есть запрос на это, скоро сделаю

там сейчас (в клиенте) все плохо с датами, по сути это из-за того, что у нас все в UTC и небыло необходимости реализовывать нормальную работу. Сейчас есть запрос на это, скоро сделаю

шикардос ?

Вопрос к разработчикам. Поймали серьёзную деградацию на работе с промежуточными состояниями аггрегатных функций. Под условия WHERE нет подходящих строк, но попытка обращения к колонке с состоянием деградирует запрос в 10-20 раз. Полечилось заменой на PREWHERE. Вопрос - это баг/фича? Подробности в gist: https://gist.github.com/alex-krash/035d32a87fd94be2483055e60ba3a383

пишу для себя доку по ClickHouse. Заголовок: ## Набросики про запросики обкринжился, обзмеился. закоммитил

кто говорил, что сжатие не зависит от грануляции индекса? Вот занимаемый объем 2х копий одной БД: 91G /var/lib/clickhouse/data/default/graphite 4.9G /var/lib/clickhouse/data/default/graphite32 у первой грануляцияя 8к, у второй 32к

O_o

А как то на скорости отражается?

но и при чтении полностью будет читатся блок на 32к

Чем то мы все равно обязаны за это заплатить)

/me пока предпочтёт меньше сжатие, быстрее селекты...

Но вообще мысль интересная, для архивных БД имеет смысл.

архивная бд это наверно не кликхаус должен быть

архивная бд это наверно не кликхаус должен быть

why not?)

Архивная - в смысле запросы туда будут очень редко по сравнению с оперативной. Но будут.

кто говорил, что сжатие не зависит от грануляции индекса? Вот занимаемый объем 2х копий одной БД: 91G /var/lib/clickhouse/data/default/graphite 4.9G /var/lib/clickhouse/data/default/graphite32 у первой грануляцияя 8к, у второй 32к

А что за данные, сказать честно слабо поставляю как увеличение гранулярности в четыре раза увеличило сжатие в 20 раз

у меня есть вопрос не по делу, но может кто-то что-то про Elliptics сказать

судя по гиту проект заброшен

Извиняюсь за возможно "тупой вопрос" но какой тип данных на выходе функции "IPv4StringToNum" UInt32?

SELECT toTypeName(IPv4StringToNum('')) ┌─toTypeName(IPv4StringToNum(\'\'))─┐ │ UInt32 │ └───────────────────────────────────┘

CH еще померджил и теперь так: 91G /var/lib/clickhouse/data/default/graphite 992M /var/lib/clickhouse/data/default/graphite32

это магия какаето, не?

ожидаю увеличение нагрузки на проц/память при чтении

какие данные там?

сейчас пробую на чтейджинге, там данных 419Г

Метрики вида: SELECT * FROM graphite32 LIMIT 10 ┌─Path──────────────────────────────────────────┬────────────────Value─┬───────Time─┬───────Date─┬──Timestamp─┐ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.0389436323509751 │ 1504602000 │ 2017-09-05 │ 1504605559 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.4234314005793237 │ 1504605600 │ 2017-09-05 │ 1504609159 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.06484408469669414 │ 1504609200 │ 2017-09-05 │ 1504612759 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.0584435594397823 │ 1504612800 │ 2017-09-05 │ 1504616359 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.46180635307718176 │ 1504616400 │ 2017-09-05 │ 1504619959 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.2120542505403427 │ 1504620000 │ 2017-09-05 │ 1504623559 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.038896276398391764 │ 1504623600 │ 2017-09-05 │ 1504627159 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.32418759041312556 │ 1504627200 │ 2017-09-05 │ 1504630759 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.09047379551616919 │ 1504630800 │ 2017-09-05 │ 1504634359 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.0773744348789403 │ 1504634400 │ 2017-09-05 │ 1504637959 │ └───────────────────────────────────────────────┴──────────────────────┴────────────┴────────────┴────────────┘ 10 rows in set. Elapsed: 0.026 sec.

CH еще померджил и теперь так: 91G /var/lib/clickhouse/data/default/graphite 992M /var/lib/clickhouse/data/default/graphite32

Что это за магия черт побери

может у тебя просто чтото в процессе удаляется?)

нечаенно)

Там алгоритм сжатия имени Алексея Бабушкина случайно не имплементировали?

кто говорил, что сжатие не зависит от грануляции индекса? Вот занимаемый объем 2х копий одной БД: 91G /var/lib/clickhouse/data/default/graphite 4.9G /var/lib/clickhouse/data/default/graphite32 у первой грануляцияя 8к, у второй 32к

Дак на сколько я понял, сжатие происходит блоками

не знаю, данные есть: SELECT * FROM graphite32 WHERE (Path = '#_MetricsPath_.vm-cs-live1.cpu.total.usertime') AND (Time > 1504602000) LIMIT 4 ┌─Path──────────────────────────────────────────┬───────────────Value─┬───────Time─┬───────Date─┬──Timestamp─┐ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.47772479651173677 │ 1514732400 │ 2017-12-31 │ 1514735964 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.7136187427061282 │ 1514736000 │ 2017-12-31 │ 1514739564 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.21159345972670585 │ 1514739600 │ 2017-12-31 │ 1514743164 │ │ #_MetricsPath_.vm-cs-live1.cpu.total.usertime │ 0.7101888501598004 │ 1514743200 │ 2017-12-31 │ 1514746765 │ └───────────────────────────────────────────────┴─────────────────────┴────────────┴────────────┴────────────┘ 4 rows in set. Elapsed: 0.007 sec. Processed 131.07 thousand rows, 12.13 MB (17.93 million rows/s., 1.66 GB/s.) :)

count(*) схожие числа выдаёт?

на стейдже актульные данные, дольет там, гляну

кто говорил, что сжатие не зависит от грануляции индекса? Вот занимаемый объем 2х копий одной БД: 91G /var/lib/clickhouse/data/default/graphite 4.9G /var/lib/clickhouse/data/default/graphite32 у первой грануляцияя 8к, у второй 32к

А вы когда меряли, */detached/* исключили?

нет, все мерял

там данные не меняются, нет там detached , копировал INSERT SELECT

SELECT toTypeName(IPv4StringToNum('')) ┌─toTypeName(IPv4StringToNum(\'\'))─┐ │ UInt32 │ └───────────────────────────────────┘

Спасибо.

count(*) схожие числа выдаёт?

Нет, ┌─────count()─┐ │ 13903321793 │ └─────────────┘ 1 rows in set. Elapsed: 2.248 sec. Processed 13.90 billion rows, 27.81 GB (6.18 billion rows/s., 12.37 GB/s.) :) select count(*) from graphite32; SELECT count(*) FROM graphite32 ┌───count()─┐ │ 489786511 │ └───────────┘ 1 rows in set. Elapsed: 0.083 sec. Processed 489.79 million rows, 979.57 MB (5.90 billion rows/s., 11.79 GB/s.) Не понятно, почему

вот и вся архивация)

КХ подропал строки ?

потерял по дороге

или может урезал при операции insert select

с чем мб связано?

в clickhouse-server.err.log пусто

с чем мб связано?

А в данных много дубликатов? Какой движок таблицы?

GraphiteMergeTree, дубликатов быть не должно

как искать?

насколько вижу, данные не повторяются: SELECT * FROM graphite WHERE Path = 'DevOps.system.vm-graphite-ch1.loadavg.load_normalized' ORDER BY Timestamp ASC LIMIT 20 ┌─Path──────────────────────────────────────────────────┬─Value─┬───────Time─┬───────Date─┬──Timestamp─┐ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.04 │ 1504604340 │ 2017-09-05 │ 1504604384 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.04 │ 1504604400 │ 2017-09-05 │ 1504604444 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03 │ 1504604460 │ 2017-09-05 │ 1504604504 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.02 │ 1504604520 │ 2017-09-05 │ 1504604564 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.01 │ 1504604580 │ 2017-09-05 │ 1504604624 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504604640 │ 2017-09-05 │ 1504604684 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504604700 │ 2017-09-05 │ 1504604744 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.02 │ 1504604760 │ 2017-09-05 │ 1504604804 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03 │ 1504604820 │ 2017-09-05 │ 1504604864 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.01 │ 1504604880 │ 2017-09-05 │ 1504604924 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504604940 │ 2017-09-05 │ 1504604984 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605000 │ 2017-09-05 │ 1504605044 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605060 │ 2017-09-05 │ 1504605104 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605120 │ 2017-09-05 │ 1504605164 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605180 │ 2017-09-05 │ 1504605224 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.02 │ 1504605240 │ 2017-09-05 │ 1504605284 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.01 │ 1504605300 │ 2017-09-05 │ 1504605344 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605360 │ 2017-09-05 │ 1504605404 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605420 │ 2017-09-05 │ 1504605464 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504605480 │ 2017-09-05 │ 1504605524 │ └───────────────────────────────────────────────────────┴───────┴────────────┴────────────┴────────────┘

Но КХ их отсеял: SELECT count(*) FROM graphite WHERE Path = 'DevOps.system.vm-graphite-ch1.loadavg.load_normalized' ┌─count()─┐ │ 25437 │ └─────────┘ 1 rows in set. Elapsed: 0.004 sec. Processed 106.50 thousand rows, 6.59 MB (29.55 million rows/s., 1.83 GB/s.) :) select count(*) from graphite32 where Path='DevOps.system.vm-graphite-ch1.loadavg.load_normalized' ; SELECT count(*) FROM graphite32 WHERE Path = 'DevOps.system.vm-graphite-ch1.loadavg.load_normalized' ┌─count()─┐ │ 850 │ └─────────┘ 1 rows in set. Elapsed: 0.006 sec. Processed 229.38 thousand rows, 17.09 MB (37.33 million rows/s., 2.78 GB/s.) :)

CH сделал rollup и сохранил только ежечасные данные вместо минутных: SELECT * FROM graphite32 WHERE Path = 'DevOps.system.vm-graphite-ch1.loadavg.load_normalized' ORDER BY Time ASC LIMIT 10 ┌─Path──────────────────────────────────────────────────┬────────────────Value─┬───────Time─┬───────Date─┬──Timestamp─┐ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.010952380952380953 │ 1504602000 │ 2017-09-05 │ 1504605584 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.026949152542372883 │ 1504605600 │ 2017-09-05 │ 1504609184 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.013166666666666672 │ 1504609200 │ 2017-09-05 │ 1504612784 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03533333333333333 │ 1504612800 │ 2017-09-05 │ 1504616384 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.030333333333333337 │ 1504616400 │ 2017-09-05 │ 1504619984 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.005333333333333334 │ 1504620000 │ 2017-09-05 │ 1504623584 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.05322033898305082 │ 1504623600 │ 2017-09-05 │ 1504627184 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03616666666666666 │ 1504627200 │ 2017-09-05 │ 1504630784 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03000000000000001 │ 1504630800 │ 2017-09-05 │ 1504634384 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.008666666666666668 │ 1504634400 │ 2017-09-05 │ 1504637984 │ └───────────────────────────────────────────────────────┴──────────────────────┴────────────┴────────────┴────────────┘ 10 rows in set. Elapsed: 0.008 sec. Processed 229.38 thousand rows, 21.22 MB (30.06 million rows/s., 2.78 GB/s.) :) select * from graphite where Path='DevOps.system.vm-graphite-ch1.loadavg.load_normalized' and Time >1504601999 order by Time limit 10; SELECT * FROM graphite WHERE (Path = 'DevOps.system.vm-graphite-ch1.loadavg.load_normalized') AND (Time > 1504601999) ORDER BY Time ASC LIMIT 10 ┌─Path──────────────────────────────────────────────────┬─Value─┬───────Time─┬───────Date─┬──Timestamp─┐ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.04 │ 1504604340 │ 2017-09-05 │ 1504604384 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.04 │ 1504604400 │ 2017-09-05 │ 1504604444 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03 │ 1504604460 │ 2017-09-05 │ 1504604504 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.02 │ 1504604520 │ 2017-09-05 │ 1504604564 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.01 │ 1504604580 │ 2017-09-05 │ 1504604624 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504604640 │ 2017-09-05 │ 1504604684 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0 │ 1504604700 │ 2017-09-05 │ 1504604744 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.02 │ 1504604760 │ 2017-09-05 │ 1504604804 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.03 │ 1504604820 │ 2017-09-05 │ 1504604864 │ │ DevOps.system.vm-graphite-ch1.loadavg.load_normalized │ 0.01 │ 1504604880 │ 2017-09-05 │ 1504604924 │ └───────────────────────────────────────────────────────┴───────┴────────────┴────────────┴────────────┘ 10 rows in set. Elapsed: 0.005 sec. Processed 106.50 thousand rows, 8.50 MB (21.14 million rows/s., 1.69 GB/s.) :)

прореживание при встаавке только делается?

в схеме сервера: прореживать до час все что старше одного месяца, он сам это не делает? почему в исходно все данные?

это <graphite_rollup> <default> <function>avg</function> <retention> <age>0</age> <precision>60</precision> </retention> <retention> <age>2592000</age> <precision>3600</precision> </retention> </default> </graphite_rollup> работает только при вставке?

всем привет! После обновления что-то стало с iptree словарем...

2018.02.21 11:52:55.786256 [ 20 ] <Error> executeQuery: Code: 117, e.displayText() = DB::Exception: Expected end of line, e.what() = DB::Exception (from [::1]:60671) (in query: SELECT dictGetString('maxmind_country_codes', 'country_name', toUInt64(dictGetUInt32('maxmind_geoip', 'geoname_id', tuple(toUInt32(IPv4StringToNum('11.22.33.44')))) as geoname_id)) as country), Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x15) [0x7317e35] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1e) [0x19caa8e] 2. clickhouse-server() [0x6b7de10] 3. clickhouse-server(DB::CSVRowInputStream::read(std::vector<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn>, std::allocator<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn> > >&)+0x18f) [0x6b7e07f] 4. clickhouse-server(DB::BlockInputStreamFromRowInputStream::readImpl()+0x97) [0x6b7acb7] 5. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x26f) [0x5fe983f] 6. clickhouse-server(DB::OwningBlockInputStream<DB::ShellCommand>::readImpl()+0x26) [0x6b9fcc6] 7. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x26f) [0x5fe983f] 8. clickhouse-server(DB::HashedDictionary::loadData()+0x62) [0x659ab22]

вручную скрипты подергал, CSV выдается корректный

/bin/bash /etc/clickhouse-server/dictionaries/maxmind_geoip/pull_maxmind_geoip.bash | head 1.0.0.0/24,2077456,2077456,,0,0 1.0.1.0/24,1814991,1814991,,0,0 1.0.2.0/23,1814991,1814991,,0,0 1.0.4.0/22,2077456,2077456,,0,0 1.0.8.0/21,1814991,1814991,,0,0

создал ещё одну таблицу с грануляцией 16384 строки, скопировал в нее из новой(32768строк) и потерял ещё ряды: SELECT count(*) FROM graphite32 ┌───count()─┐ │ 489786511 │ └───────────┘ 1 rows in set. Elapsed: 0.105 sec. Processed 489.79 million rows, 979.57 MB (4.68 billion rows/s., 9.36 GB/s.) :) select count(*) from graphite16; SELECT count(*) FROM graphite16 ┌───count()─┐ │ 488059041 │ └───────────┘ 1 rows in set. Elapsed: 0.076 sec. Processed 488.06 million rows, 976.12 MB (6.45 billion rows/s., 12.90 GB/s.)

кто-то может это объяснить?

Поправлю в ближайших версиях -- insert select будет без maxRows

класс!

так, похоже с iptrie все ок, а вот другой hash словарь теперь поломался ?

Такой вопрос Есть какой нибудь менее костыльный вариант проверить наличие значения в Array(Enum8(....)), чем то, что ниже? SELECT ... WHERE has(arrayMap(x -> toUInt8(x), arrColumn), 4)

К вопросу выше добавлю — можно ли найти индекс максимального в массиве?

Коллеги, конфигурация 2 шарды по 2 реплики. Вчера обновили на 2х репликах одной шарды версию до 1.1.54343 На 2 репликах первой шарды версия: 1.1.54292 Cейчас CH начал дико что-то синхронизировать и в таблицах появились дубли записей

Эти события могут быть связанными?

шарды могут быть связаны только если вы в distributed пишите. Вы обновили один шард до новой версии, так? Где данные стали дублироваться? что в select * from system.replication_queue ? Между 54292 и 54343 несовместимый формат репликации

Многие биндинги используют http протокол для подключения. Какие-то есть вообще с этим проблемы? http vs tcp ?

Многие биндинги используют http протокол для подключения. Какие-то есть вообще с этим проблемы? http vs tcp ?

Он чуть более затратен по ресурсам в отличии от нативного протокола поверх tcp

Он чуть более затратен по ресурсам в отличии от нативного протокола поверх tcp

Ну это само собой. Но я смог придумать плюс http подключению. Его не нужно держать keep alive, каждый запрос — подключение. Tcp, как это обычно бывает, нужно отслеживать дисконнекты

если не держать keep alive то каждый раз ждать подключения?

Ну это само собой. Но я смог придумать плюс http подключению. Его не нужно держать keep alive, каждый запрос — подключение. Tcp, как это обычно бывает, нужно отслеживать дисконнекты

Чего за ними следить, не смогли прочитать/записать и вывалились с ошибкой

Ну это само собой. Но я смог придумать плюс http подключению. Его не нужно держать keep alive, каждый запрос — подключение. Tcp, как это обычно бывает, нужно отслеживать дисконнекты

Особенно классно если с ssl

я пришел к ситуации когда держу постоянно открытые 20 подключений

потому что это реально быстрее чем открывать заново

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