DT
Sergey Mc
Архитектурно както можно оптимизировать?
Для этого нужно отталкиваться от запросов и от того, что вам нужно.
можно на создавать MAT VIEW и тд
можно на создавать MAT VIEW и тд
Size: a a a
2020 May 28
DT
Sergey Mc
например STRING в UInt перевести
можно, а еще добавить кодеки
DT
Sergey Mc
партиционирование настроить по другому
У вас довольно частое партицирование и 70*20 = 1400 партиции, что многовато
У вас сколько серверов?
У вас сколько серверов?
SM
7 серверов в кластере
SM
я думаю даже более частое партиционирование
SM
70 это почему?
DT
Sergey Mc
70 это почему?
70 дней данных
ну это прикидка конечно
ну это прикидка конечно
SM
PARTITION BY (toDate(END_TIME), RULEBASE)
SM
разве не столько сколько комбинаций?
DT
Sergey Mc
PARTITION BY (toDate(END_TIME), RULEBASE)
70 дней, в каждом по 20 уникальных RULEBASE.
SM
меня вот этот момент смущает, помоему неудобная схема партиционирования выбрана
DT
Sergey Mc
меня вот этот момент смущает, помоему неудобная схема партиционирования выбрана
Как вставляете данные в таблицу?
DT
Sergey Mc
меня вот этот момент смущает, помоему неудобная схема партиционирования выбрана
Ну дневные партиции это необычно, но допустим у вас трлн записей за 70 дней, так что возможно это оправдано.
Но ORDER BY и PARTITION BY сильно зависят от того, какие запросы вам нужны(с какой фильтрацией) и во вторую очередь от того, как компактно уложить можно данные
Но ORDER BY и PARTITION BY сильно зависят от того, какие запросы вам нужны(с какой фильтрацией) и во вторую очередь от того, как компактно уложить можно данные
DC
Sergey Mc
ну , запросы самые разные, от посчитать сумму по колонке и до невообразимых
а можете показать из кх клиента строку со статистикой когда вы считаете sum по колонке
SM
а можете показать из кх клиента строку со статистикой когда вы считаете sum по колонке
я бобром пользуюсь к клиенту нет доступа
DC
Sergey Mc
я бобром пользуюсь к клиенту нет доступа
¯\_(ツ)_/¯
DT
А так в воздух еще можно сказать, что если данные лежат строго по sharding key, то можно сказать не ходить на те шарды, где нужных данных быть не может.
Натравить кодеки(быстрее данные будут считываться с диска)
возможно для некоторых запросов подойдет SAMPLING
Но без запросов особо не помочь
Натравить кодеки(быстрее данные будут считываться с диска)
возможно для некоторых запросов подойдет SAMPLING
Но без запросов особо не помочь
SM
SM
А так в воздух еще можно сказать, что если данные лежат строго по sharding key, то можно сказать не ходить на те шарды, где нужных данных быть не может.
Натравить кодеки(быстрее данные будут считываться с диска)
возможно для некоторых запросов подойдет SAMPLING
Но без запросов особо не помочь
Натравить кодеки(быстрее данные будут считываться с диска)
возможно для некоторых запросов подойдет SAMPLING
Но без запросов особо не помочь
SAMPLING не подойдет, нужны более менее точные расчеты, данные по всему кластеру лежат, можно выделять партиции по суткам например, чтобы обращаться только к одной партиции?
l
Sergey Mc
SAMPLING не подойдет, нужны более менее точные расчеты, данные по всему кластеру лежат, можно выделять партиции по суткам например, чтобы обращаться только к одной партиции?
если ты будешь писать в WHERE условие по partition key сработает partition elimination и он пойдет глядеть только нужные партиции