Привет. Почему может не работать получение значения для материализованной колонки из словаря?

ga_source       │ String  │ MATERIALIZED │ dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')

При чем такое наблюдается не для всех  и если в запрос добаить отдельно получения значения для словаря все ок

SELECT 
    bill_id, 
    ga_source, 
    dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')
FROM ds.billitems_log
WHERE bill_id = 95059357

┌──bill_id─┬─ga_source─┬─dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')─┐
│ 95059357 │           │ yandex                                                                            │
└──────────┴───────────┴───────────────────────────────────────────────────────────────────────────────────┘

<yandex>
 <remote_servers>
      <shard>
        <internal_replication>true</internal_replication>
        <replica>

после remote_servers нужно указать еще имя кластера

<yandex>
    <remote_servers>
        <{CLUSTER_NAME}>
            <shard>
            ...
        </{CLUSTER_NAME}>
    </remote_servers>
</yandex>

<yandex>
    <remote_servers>
        <{CLUSTER_NAME}>
            <shard>
            ...
        </{CLUSTER_NAME}>
    </remote_servers>
</yandex>

ах, семён-семёныч, спасибо!

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

Спасибо за исчерпывающий ответ

SELECT t.id, t.cnt, total.total_cnt FROM (
 SELECT 1 AS join_key, id, count()  AS cnt FROM table GROUP BY id
) AS t
INNER JOIN
(
SELECT 1 AS join_key count() FROM table
) AS total
ON t.join_key=total.join_key

просто в инсерте написать список колонок? Или впрос про native format?

Добрый день,

Может кто-то подсказать в случае с storage policy c 2мя volumes - как CH выбирает какие парты переместить на 2ой volume? Самый старый парт? самый большой? случайный?

И все будет хорошо, пока этот главный дц не умрет

Я бы сказал надо моделировать свои аварии и их импакт и действовать исходя из этого. Нужен живой сервис при -1дц - надо делать так, не нужен - эдак

Всем привет. Чтобы пользователь default мог создавать пользователей я разкомментировал в файле users.xml эту строку
<!-- User can create other users and grant rights to them. -->
           <access_management>1</access_management>
но все равно не дает создать пользователя
Code: 497. DB::Exception: Received from localhost:9000. DB::Exception: default: Not enough privileges. To execute this query it's necessary to have grant CREATE USER ON *.*.

В чем проблема?

ga_source       │ String  │ MATERIALIZED │ dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')

SELECT 
    bill_id, 
    ga_source, 
    dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')
FROM ds.billitems_log
WHERE bill_id = 95059357

┌──bill_id─┬─ga_source─┬─dictGetOrDefault('dictionary.sources', 'ga_source', tuple(toString(bill_id)), '')─┐
│ 95059357 │           │ yandex                                                                            │
└──────────┴───────────┴───────────────────────────────────────────────────────────────────────────────────┘

никто не сталкивался? Версия КХ 20.4.9.110, в словаре 12M записей, по логам ошибок не видно

странно. Должно работать. У меня с таким конфигом работает

    <users>
        <default>
            <password></password>
            <networks incl="networks" replace="replace">
                <ip>127.0.0.1</ip>
            </networks>
            <access_management>1</access_management>
            <profile>default</profile>
            <quota>default</quota>
        </default>
    </users>

и еще, почему могут не работать SHOW USERS, SHOW ACCESS? таблицы system.users не существует, хотя пользователи через sql в кластере нормально создаются и работают

SHOW USERS

Syntax error: failed at position 6:

SHOW USERS

Expected one of: TABLES, GRANTS, CREATE, QUOTA USAGE, POLICIES, ROW POLICIES, PROCESSLIST, CREATE, QUOTAS, DICTIONARIES

https://clickhouse.tech/docs/en/operations/system-tables/storage_policies/
move_factor (Float64) — Ratio of free disk space. When the ratio exceeds the value of configuration parameter, ClickHouse start to move data to the next volume in order.
prefer_not_to_merge (UInt8) — Value of the prefer_not_to_merge setting. When this setting is enabled, merging data on this volume is not allowed. This allows controlling how ClickHouse works with slow disks.

если TTL TO DISK \ TO VOLUME не указывать
то тогда что-то странное
типа заполнили основной диск начинаем переносить на следующий...
но да, какие именно парты будут на следующий диск переноситься ид документации не ясно

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-multiple-volumes_configure

вот тут подробнее сказано
If there are different kinds of disks available in the system, moving_from_ssd_to_hdd policy can be used instead. The volume hot consists of an SSD disk (fast_ssd), and the maximum size of a part that can be stored on this volume is 1GB. All the parts with the size larger than 1GB will be stored directly on the cold volume, which contains an HDD disk disk1.
Also, once the disk fast_ssd gets filled by more than 80%, data will be transferred to the disk1 by a background process.

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

спасибо
я уже пришел к мысли что TTL TO VOLUME придется использовать в любом случае
но все еще надеюсь что CH будет  по дате переносить :)

Есть быстрый запрос, который позволяет узнать что сделал пользователь после логина:
argMinIf(action,time,action!='login')
А есть какие нибудь идеи как так же быстро и просто получить третье по времени действие пользователя?

https://clickhouse.tech/docs/ru/sql-reference/functions/other-functions/#neighbor
может быть это поможет ?

возможно. но непонятно что там с ORDER...
Потому что если пытаться решать через ...ORDER BY time LIMIT 3 BY ...,  то отрабатывает за минуты....
argMinIf за секунды...

потому что ORDER BY .. LIMIT BY это фильтрация во время сортировки в памяти
сортировка финальная стадия после того как данные выбраны

а argMinIf
это фильтрация с аггрегацией на этапе выборки