ВВ
и в итоге в матвью идет 0
Size: a a a
2021 January 18
ВВ
Если без груп бай, то идет, но по том ждать когда оно там решит схлопнуться
ВВ
а тут непонятно - какие-то ограничения чтоли на суммари вью из суммари ендж?
T
Есть ли какие-то рекомендации под ЗК(настройки производительности итд), и использует ли кто-то ЗК как мастер мастер?(если возможно такое) для ускорения обработки транзакций внутри ЗК.
Д
всем доброго времени суток. Подскажите, пожалуйста, такой момент:
я создаю индекс для таблицы db.t_oplogs_info (примерно 1,5 миллиарда строк, количество уникальных значений item_id = 50) на движке MergeTree():
alter table db.t_oplogs_info add index t_oplogs_info_item_id_indx (platform_type, item_id) type set(0) granularity 8192;
alter table db.t_oplogs_info materialize index t_oplogs_info_item_id_indx;
дожидаюсь выполнения мутации, после чего при выполнении запроса:
select count(1)
from
db.t_oplogs_info x
where
x.platform_type = 'p'
and
x.item_id = 'a'
я получаю примерно те же значения по времени выполнения запроса по указанной таблице db.t_oplogs_info до создания в ней индекса t_oplogs_info_item_id_indx.
С чем это может быть связано?
я создаю индекс для таблицы db.t_oplogs_info (примерно 1,5 миллиарда строк, количество уникальных значений item_id = 50) на движке MergeTree():
alter table db.t_oplogs_info add index t_oplogs_info_item_id_indx (platform_type, item_id) type set(0) granularity 8192;
alter table db.t_oplogs_info materialize index t_oplogs_info_item_id_indx;
дожидаюсь выполнения мутации, после чего при выполнении запроса:
select count(1)
from
db.t_oplogs_info x
where
x.platform_type = 'p'
and
x.item_id = 'a'
я получаю примерно те же значения по времени выполнения запроса по указанной таблице db.t_oplogs_info до создания в ней индекса t_oplogs_info_item_id_indx.
С чем это может быть связано?
K
эффективны.
>Насколько замедляет выборку(расчет) по этим полям
очень мало влияет
надо проверять CODEC(ZSTD) vs CODEC(DoubleD, ZSTD)
>Насколько замедляет выборку(расчет) по этим полям
очень мало влияет
надо проверять CODEC(ZSTD) vs CODEC(DoubleD, ZSTD)
Спасибо, буду пробовать!
DC
Вячеслав Владимиров
подскажите - по SummingMergeTree:
Допустим таблица:
create table tr3
(
dt Date,
demand_id UInt32,
imps UInt64
)
engine = SummingMergeTree((imps))
PRIMARY KEY (dt, demand_id)
ORDER BY (dt, demand_id)
Если в нее пихать - то схлопывается и суммируется - все ок
Делаю по ней матвью:
CREATE MATERIALIZED VIEW tv
(
dt Date,
demand_id UInt32,
imps UInt64
)
engine = SummingMergeTree((imps))
PRIMARY KEY (dt, demand_id)
ORDER BY (dt, demand_id)
as Select dt,demand_id, sum(imps) from tr3 group by dt,demand_id;
Допустим таблица:
create table tr3
(
dt Date,
demand_id UInt32,
imps UInt64
)
engine = SummingMergeTree((imps))
PRIMARY KEY (dt, demand_id)
ORDER BY (dt, demand_id)
Если в нее пихать - то схлопывается и суммируется - все ок
Делаю по ней матвью:
CREATE MATERIALIZED VIEW tv
(
dt Date,
demand_id UInt32,
imps UInt64
)
engine = SummingMergeTree((imps))
PRIMARY KEY (dt, demand_id)
ORDER BY (dt, demand_id)
as Select dt,demand_id, sum(imps) from tr3 group by dt,demand_id;
sum(imps) as imps
имена полей в select и MV должны совпадать
имена полей в select и MV должны совпадать
ВВ
sum(imps) as imps
имена полей в select и MV должны совпадать
имена полей в select и MV должны совпадать
Охтыж.... поди догадайся... Спасибо
DC
Есть ли какие-то рекомендации под ЗК(настройки производительности итд), и использует ли кто-то ЗК как мастер мастер?(если возможно такое) для ускорения обработки транзакций внутри ЗК.
ZK по дефолту мастер-мастер, там есть watch ноды , но это отдельная история и с КХ они не нужны.
>ускорения обработки транзакций внутри ЗК
ускорить ZK нельзя. Все ноды ZK делают одно и тоже и весь ZK работает со скоростью самого медленного узла
У вас не должно быть проблем с ZK , 3 нод ZK (один ансамбль) должно хватать на сотню шардов / на 500 нод КХ
>ускорения обработки транзакций внутри ЗК
ускорить ZK нельзя. Все ноды ZK делают одно и тоже и весь ZK работает со скоростью самого медленного узла
У вас не должно быть проблем с ZK , 3 нод ZK (один ансамбль) должно хватать на сотню шардов / на 500 нод КХ
DC
Вячеслав Владимиров
Охтыж.... поди догадайся... Спасибо
ВВ
не вопрос, с удовольствием
T
ZK по дефолту мастер-мастер, там есть watch ноды , но это отдельная история и с КХ они не нужны.
>ускорения обработки транзакций внутри ЗК
ускорить ZK нельзя. Все ноды ZK делают одно и тоже и весь ZK работает со скоростью самого медленного узла
У вас не должно быть проблем с ZK , 3 нод ZK (один ансамбль) должно хватать на сотню шардов / на 500 нод КХ
>ускорения обработки транзакций внутри ЗК
ускорить ZK нельзя. Все ноды ZK делают одно и тоже и весь ZK работает со скоростью самого медленного узла
У вас не должно быть проблем с ZK , 3 нод ZK (один ансамбль) должно хватать на сотню шардов / на 500 нод КХ
благодарю за развёрнутый ответ, есть ли надобность бэкапить как-то ноды ЗК?
DC
благодарю за развёрнутый ответ, есть ли надобность бэкапить как-то ноды ЗК?
бекапить их особого смысла нет. Бекап вряд ли пригодится, нельзя получить последнюю секунду состояния ZK из бекапа.
У вас 3 ноды ZK , они все 3 содержат одинаковые данные / хранят снепшоты + логи.
Любой ноды из 3 достаточно для восстановления ансамбля
У вас 3 ноды ZK , они все 3 содержат одинаковые данные / хранят снепшоты + логи.
Любой ноды из 3 достаточно для восстановления ансамбля
T
я вот читал, что для оптимальной вставки, нужно использовать большой батч(500к-1млн записей в блоке данных), это правило распространяется на один инстанс КХ? если так, то для нод 30 в кластере, можно будет 15млн на каждый батч?
SC
я вот читал, что для оптимальной вставки, нужно использовать большой батч(500к-1млн записей в блоке данных), это правило распространяется на один инстанс КХ? если так, то для нод 30 в кластере, можно будет 15млн на каждый батч?
есть условно простое правило - вставки в одну ноду не должны быть чаще чем раз в 1 сек
T
хочу для себя понять, если в пуле скопится большое кол-во строк(в связи с непредвиденными обстоятельствами), на сколько большой блок данных сможет принять кластер
SC
сколько угодно
SC
сколько на диск влезет
DC
я вот читал, что для оптимальной вставки, нужно использовать большой батч(500к-1млн записей в блоке данных), это правило распространяется на один инстанс КХ? если так, то для нод 30 в кластере, можно будет 15млн на каждый батч?
все сильно зависит от ширины строк, от строк кол-ва за день, от требований к надежности / атомарности.
DC
А есть ли возможность посмотреть статус OPTIMIZE TABLE к ReplicationMergeTree?
вопрос не имеет смысла. Какую проблему решаете?