😐ну вот и что тогда брать?

снова хадупы, данные в hdfs и подключаться через 10-15 прослоек?

Каким запросом можно получить список всех view ?

select dependencies_table  from system.tables ?

ну поиск по целому дню не особо нужен, основной use-case по ренджу 15 минут. ну и sql проще lucene

по структуированым логам, типа событий http, упаковывается еще лучше и хорошо решается через matview

select * from system.tables where engine = 'View'

такое имеет смысл ?
SELECT distinct database ||'.'|| name  as value FROM system.tables where engine = 'View'

да, но distinct не нужен

Привет! В каких случаях селект с sample может быть медленней чем без sample? Как то неправильно ключ был задан при создании? Если так, то какое потенциальное значение должно быть в SAMPLE BY $column чтобы работало?

в общем случае sample имеет смысл при .1 и менее

Всмысле SAMLE 0.1? Я ставил самые разные значения, 0.1, 0.5, 0.001 и всё без толку. В моём случае семплирование стоит по полю auction_id, число всегда разное. Надо было его оборачивать в какой нибудь хеш?

хеш нужен что бы результат был правильный.
например auction_id от 1101 до 300000009 , а хеш от auction_id будет от 0 до maxUInt64

если чтение с диска занимает большую часть запроса и sample где-нибудь 5 полем, то не конечно не поможет семплинг.
т.е. надо делать таблицы специально под запросы которые вы будете делать с семплингом.

например https://clickhouse.tech/docs/en/getting-started/tutorial/#create-tables
CREATE TABLE tutorial.visits_v1
...
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)
SAMPLE BY intHash32(UserID)

у CounterID маленькая кардинальнасть, у StartDate тоже

аа всё, я вкурил, спасибо. Придётся пересоздавать таблицу конечно... Там семплирование под обычные запросы с count() и кучей where фильтров. Для графаны в основном нужно, точность не важна

Есть возможность поменять путь в зукипере? Чтобы сделать rename и поменять у таблицы путь в соответствии с новым названием таблицы?

можно сказать, что нет

🙏

Добрый день!

Подскажите, насколько нормально такое поведение Materialized View на AggregatingMergeTree и можно ли что-то с этим сделать?

Я создал пустую таблицу table и материализованное представление view на ней с GROUP BY x. Дальше добавляю данные в table, данные появляются во view, но с небольшим числом повторов строк с одинаковым x, не похоже, что они собираются когда-то слиться, прошел день, а они все там

так и задумано, надо либо в запросе домерживать, либо использовать select final

агрегация происходит во время мержей