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

https://clickhouse.tech/docs/en/sql-reference/aggregate-functions/parametric-functions/#function-sequencematch

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

Каких например? Просто интересно.

может не совсем в тему вопрос

у metabse есть такая возможность или какие то аналогичные?
1. Задаем параметр, он привязан к пользователю метабейс.
Когда пользователь логинится то он видит инфу всегда с этим фильтром. Грубо говоря чтобы владелец сайта А из общего объема всегда видел данные только сайта А.

БД у нас click

не знаю что такое metabase, а фильтры возможно надо вписывать сюда https://clickhouse.tech/docs/en/operations/settings/settings-users/#user-namedatabases

спасибо, тоже полезно

Коллеги, подскажите, могули я как-то ограничить память выделяемую на создание мат представления с директивой POPULATE?

Кто-то подскажет?

всем привет, подскажите, есть таблица

CREATE TABLE test_test.test
(
    `uuid` UUID,
    `status` Enum8('approved' = 1, 'in_progress' = 2, 'canceled' = 3),
    `cost` UInt64,
    `currency` Enum8('USD' = 1, 'RUB' = 2),
    `EventDate` Date,
    `EventDateTime` DateTime
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(EventDate)
ORDER BY (uuid, EventDate)
SETTINGS index_granularity = 8192

пробую добавить

ALTER TABLE test
    MODIFY TTL EventDate + toIntervalMonth(6) TO DISK 'hdd'

SETTINGS storage_policy = 'ssd_only'


Exception on client:
Code: 115. DB::Exception: Unknown setting storage_policy: in attempt to set the value of setting 'storage_policy' to 'ssd_only'

если создаю новую таблицу, то все ок

CREATE TABLE test1
(
    `uuid` UUID,
    `status` Enum8('approved' = 1, 'in_progress' = 2, 'canceled' = 3),
    `cost` UInt64,
    `currency` Enum8('USD' = 1, 'RUB' = 2),
    `EventDate` Date,
    `EventDateTime` DateTime
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(EventDate)
ORDER BY (uuid, EventDate)
TTL EventDate + toIntervalWeek(2) TO DISK 'hdd'
SETTINGS storage_policy = 'ssd_only'

Ok.

0 rows in set. Elapsed: 0.002 sec.

как добавить в существуюущую таблицу TTL и storage_policy?

Нельзя менять storage_policy после создания

Потому такой альтер не проходит
UPD: Можете создать новую таблицу, начать в неё запись, перелить необходимый объём данных из старой, дропнуть старую

Даже если я storage_policy не указывал для таблицы?

Да, поскольку в этом случае просто используется политика хранения по-умолчанию, а её изменить тоже нельзя

я думал что нельзя указывать, если уже была добавлена storage_policy, тогда понятно
Спасибо

Всем привет. Хочу попробовать для себя CH, нашел интересную задачу, которую не вывозит PostgreSQL:
каждый день создаются и удаляются множество доменных имён в интернете (есть выгрузки некоторых доменных зон в сыром виде), хочу попробовать поделать какую-нибудь аналитику на основе этой BigData 🙂

Для начала думал что закину в PgSQL 150 млн доменов и всё будет окей, но упираюсь в производительность как вставки, так и апдейта данных (хотя уже накрутил и вставку через COPY и вынес проверяемые данные в Redis, что получить O(1)). Сейчас понимаю что нужно взять кликхаус и пробовать его, но опыта - совсем нету.

Дайте, пожалуйста, какие-нибудь советы совсем новичку, чтоб больно не спотыкаться? 🙂

Структура БД в PgSQL прикладываю ниже в скрине, коротко суть:
1. Табличка tld: в ней я храню доменную зону (ru, net, org и тд), чтобы в главной таблице domain поле было типа Integer.
2. Табличка nameserver: в ней хранятся все неймсервера для домена (минимум 2 и максимум что я встречал вроде бы 25).
3. Главная таблица domain:
   - tld_id (integer) - связь с таблицей tld
   - letter (varchar(1)) - первая буква домена для ключа партиционирования (чтобы при обновлении домена = удалении/смене ns серверов искать не по всей таблице целиком)
   - name_servers (array[integer]) - массив id неймсерверов для текущего домена
   - created_at (date) - дата, когда домен попал первый раз в базу (в выгрузке нет дат, поэтому берем дату когда парсили эту выгрузку)
   - updated_at (date) - дата, когда было последнее обновление неймсерверов для домена
   - deleted_at (data) - дата, когда домен пропал из выгрузки (не продлили, домен свободен к регистрации)
   - domain (varchar) - соответственно сам домен без доменной зоны (example.com => example)

Как лучше подстроить текущую структуру под CH? Скорее всего нет смысла создавать столько таблиц, внутренняя магия столбцовой БД должна (?) переварить если я буду хранить tld текстом, а не id, а неймсервера тоже массивом строк?

В будущем как минимум хочется делать выборки в духе "Какие домены были удалены/обновлены вчера с доменной зоной = ru".

Ещё пару важных вещей, которые не понимаю:
1. Как мне быть с обновлением полей updated_at/deleted_at? Писать ещё одну строку в базу, где уже будут эти поля заполнены, но как тогда старое потом удалять, чтоб оно не захламляло?
2. При последующих парсингах выгрузок (когда первично база уже наполнена) - нужно проверять есть ли такой домен в базе, нормально ли для CH, если я буду делать запрос, где будет возвращаться 1 строка и это будет что-то в духе "select exists(id) from domain where domain_name = 'example.com'"? Просто вроде вся мощь CH (на сколько я понимаю) как раз в агрегации данных, а не запросам где нужно получить всего 1 строку?

несколько таблиц если и надо, то других. тлд можно инлайнить в домены, низкокардинальные строки пожмутся нормально. запросы за одним ключом не будут масштабироваьтся, exists id делать не надо, раз таблица про домены, делайте ключом домен, сортируте по нему и всё. хранить логи изменений это нормально, с обновлением записей возможна разного вида печаль.

а как вот классически по-кликхаусовски делать обновления, чтоб это были не обновления в привычном понимании, а добавление новой строки или как-то вот так?

Replacing merge tree