AS
нет, совсем нет
Size: a a a
2020 July 15
AS
это просто селект и несколько фильтров к нему
DT
Ну тогда вполне ок будет, но возможно jdbc не самый оптимальный драйвером будет в таком случае, но тут разве что свой драйвер писать.
AS
ок, понятно, спасибо
D
Согласен, уже подумал и завтра попробую реализовать на стороне приложения, там есть на вскидку не приятные вопросы - такие как гарантированная запись. Пока не могу понять почему движек Buffer нужно менять на чтото свое
вот ещё одна причина, на митапе только что нашептали, что скоро будет in-memory parts и буфер скоро выпилят =)
A
вот ещё одна причина, на митапе только что нашептали, что скоро будет in-memory parts и буфер скоро выпилят =)
Сегодня уже через очередь у себя сделали )) а то через три дня уже в пред прадакшене должно быть
2020 July 16
O
Привет всем! Хочу сделать словарь range_hashed. Вопрос такой: Границы дат будут включаться в поиск? То есть вот так будет работать range_min<=Date<=range_max?
AR
Удалил ReplicatedMergeTree таблицу. Пытаюсь создать такую же в другой базе. Получаю такое сообщение.
Code: 57, e.displayText() = DB::Exception: Directory for table data data/data_warehouse/users_report_v_0_1/ already exists (version 20.4.5.36 (official build))Подскажите, как можно вылечить?
NB
Ты удалил на одной реплике или на всех ?
AR
на одной
NB
а у тебя наверняка больше нод в кластере, да?
AR
но когда удалил на всех репликах, то ошибка осталась
q
Привет ребят а как обстоят дела для работы клика с удаленной базой через баунсер? Использую odbc для конекта в базу, когда стоит напрямую в базу никаких проблем, а когда через баунсер пятисотит при селекте и пишет ошибку unsupported startup parameter:geqo
DS
Всем привет!
Подскажите, будет ли корректно работать вьюха, в которой таблица джойнится на себя саму?
В таблице есть три уровня грануляции: дата, наименование события и id сессии. Для агрегации даты используется minState, событий -- CountState.
Таблица будет джойнится с агрегатом, где высчитывается дата начала сессии minMerge. Потом объединенная таблица агрегируется по названию события и дате начала сессии. Считается кол-во событий при помощи countMerge.
Или лучше все это грузить в array, группировать по сессиям, сортировать и выводить первое значение в качестве даты начала сессии?
Подскажите, будет ли корректно работать вьюха, в которой таблица джойнится на себя саму?
В таблице есть три уровня грануляции: дата, наименование события и id сессии. Для агрегации даты используется minState, событий -- CountState.
Таблица будет джойнится с агрегатом, где высчитывается дата начала сессии minMerge. Потом объединенная таблица агрегируется по названию события и дате начала сессии. Считается кол-во событий при помощи countMerge.
Или лучше все это грузить в array, группировать по сессиям, сортировать и выводить первое значение в качестве даты начала сессии?
Всем привет! Может быть есть какая-либо стандартная практика для таких задач?
Сейчас идея создать две таблицы, два MV (AMT) и две вьюхи. В первую таблицу лить инфо по сессиям, где дата старта сессии будет рассчитываться при помощи minState. На эту таблицу будет создаваться вьюха, где происходит minMerge и выводится дата начала сессии.
Во вторую таблицу писать инфо сессии countState, uniqExactState.
Потом во вьюхе делать join с той вьюхой, где есть дата начала сессии, потом агрегировать countMerge, uniqExactMerge по событиям и дате начала сессии.
Сейчас идея создать две таблицы, два MV (AMT) и две вьюхи. В первую таблицу лить инфо по сессиям, где дата старта сессии будет рассчитываться при помощи minState. На эту таблицу будет создаваться вьюха, где происходит minMerge и выводится дата начала сессии.
Во вторую таблицу писать инфо сессии countState, uniqExactState.
Потом во вьюхе делать join с той вьюхой, где есть дата начала сессии, потом агрегировать countMerge, uniqExactMerge по событиям и дате начала сессии.
D
Всем привет! Может быть есть какая-либо стандартная практика для таких задач?
Сейчас идея создать две таблицы, два MV (AMT) и две вьюхи. В первую таблицу лить инфо по сессиям, где дата старта сессии будет рассчитываться при помощи minState. На эту таблицу будет создаваться вьюха, где происходит minMerge и выводится дата начала сессии.
Во вторую таблицу писать инфо сессии countState, uniqExactState.
Потом во вьюхе делать join с той вьюхой, где есть дата начала сессии, потом агрегировать countMerge, uniqExactMerge по событиям и дате начала сессии.
Сейчас идея создать две таблицы, два MV (AMT) и две вьюхи. В первую таблицу лить инфо по сессиям, где дата старта сессии будет рассчитываться при помощи minState. На эту таблицу будет создаваться вьюха, где происходит minMerge и выводится дата начала сессии.
Во вторую таблицу писать инфо сессии countState, uniqExactState.
Потом во вьюхе делать join с той вьюхой, где есть дата начала сессии, потом агрегировать countMerge, uniqExactMerge по событиям и дате начала сессии.
"Потом во вьюхе делать join с той вьюхой,"
https://github.com/ClickHouse/ClickHouse/pull/11513
pushdown условий во вьюхи только подвозят и думаю там будет достаточно много работы ещё... я бы не стал, лучше делать логику с xxxMerge в запросо-генераторе... но в простых случаях можно и как у вас
https://github.com/ClickHouse/ClickHouse/pull/11513
pushdown условий во вьюхи только подвозят и думаю там будет достаточно много работы ещё... я бы не стал, лучше делать логику с xxxMerge в запросо-генераторе... но в простых случаях можно и как у вас
DV
привет!
а как правильно сделать MODIFY PRIMARY KEY? только через переналивку данных? есть какие-то инструменты-хитрости чтобы можно было съкономить место?
а как правильно сделать MODIFY PRIMARY KEY? только через переналивку данных? есть какие-то инструменты-хитрости чтобы можно было съкономить место?
DS
"Потом во вьюхе делать join с той вьюхой,"
https://github.com/ClickHouse/ClickHouse/pull/11513
pushdown условий во вьюхи только подвозят и думаю там будет достаточно много работы ещё... я бы не стал, лучше делать логику с xxxMerge в запросо-генераторе... но в простых случаях можно и как у вас
https://github.com/ClickHouse/ClickHouse/pull/11513
pushdown условий во вьюхи только подвозят и думаю там будет достаточно много работы ещё... я бы не стал, лучше делать логику с xxxMerge в запросо-генераторе... но в простых случаях можно и как у вас
Понял, большое спасибо!
D
привет!
а как правильно сделать MODIFY PRIMARY KEY? только через переналивку данных? есть какие-то инструменты-хитрости чтобы можно было съкономить место?
а как правильно сделать MODIFY PRIMARY KEY? только через переналивку данных? есть какие-то инструменты-хитрости чтобы можно было съкономить место?
В документации есть - только через наливку.
Без наливки можно добавлять доп. поля только в ORDER BY, но это редко когда надо бывает (fixed)
Без наливки можно добавлять доп. поля только в ORDER BY, но это редко когда надо бывает (fixed)
DC
Добавлять поля можно в orderby, а не в primarykey
V
Привет! Делаю
optimise table final. Идут мержи. Потом из system.processes пропадает. В system.merges мержей на таблицу нет. Но если еще раз делаю optimise table final, то мержи появляются. Как все-таки добиться этого FINAL, т.е. чтобы мержи перестали появляться и процесс был завершен? Я пытаюсь свернуть AggregatinMergeTree