ЛА
вопрос - насколько быстро вам надо
Она постоянно растет. На данный момент это 80 млн, но прирост по 20 млн в месяц.
Size: a a a
2020 July 22
АП
и вам надо по всему обьему бахать?
ЛА
из личного опыта: иногда делают шардинг, иногда - просто перенос холодных данных в другую базу
Спасибо, шардирование решает часть проблемы. Нет ли рецепта как при этом оптимально выполнять селекты, которые размазаны по шардам?
ЛА
и вам надо по всему обьему бахать?
Мне надо решить с хранением, пока я могу ещё менять структуру на меньших объемах. В любом случае чем больше бд , тем дольше все запросы на ней.
ВС
а какой там может быть рецепт? разве что как-то минимизировать количество шардов, которые надо обойти
DP
коллега, ну какие тут могут быть рецепты?
ЛА
коллега, ну какие тут могут быть рецепты?
Мб есть какие-то облачные решения под ключ? Которые поделят таблицу на куски по определенному ключу, и также самостоятельно обеспечат обход всех шардов в случае агрегирующего запроса?
ЛА
Или вообще любые другие решения. Я не могу знать того, что не знаю) в моём арсенале только шардирование
ВГ
Мб есть какие-то облачные решения под ключ? Которые поделят таблицу на куски по определенному ключу, и также самостоятельно обеспечат обход всех шардов в случае агрегирующего запроса?
Citus? Timescale?
ЛА
Citus? Timescale?
Спс, пошел читать. Ранее не слышал
ВГ
это пг, наверное, в MySQL тоже что-то есть
ЛА
это пг, наверное, в MySQL тоже что-то есть
Мне pg и надо
VL
Мб есть какие-то облачные решения под ключ? Которые поделят таблицу на куски по определенному ключу, и также самостоятельно обеспечат обход всех шардов в случае агрегирующего запроса?
возможно вам поменять хранилище данных под то, что лучше работает с тем поведением данных и операциям над данными типом данных, что вы используете?
ЛА
возможно вам поменять хранилище данных под то, что лучше работает с тем поведением данных и операциям над данными типом данных, что вы используете?
Posgresql
VL
Posgresql
Вот возможно стоит подумать над другими вариантами, если универсальность уже создает проблемы?
ЛА
Вот возможно стоит подумать над другими вариантами, если универсальность уже создает проблемы?
Например, какие могут быть решения?
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
DP
Например, какие могут быть решения?
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
масса вариантов, но они все по месту
VL
Например, какие могут быть решения?
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
Я не могу полностью уйти в nosql тк есть агреригующий запрос (запрос по многим фильтрам).
Для начала определитесь с характером данных и требуемыми операциями. Возможно у вас данные только добавляются, но не редактируются.
ЕО
У меня есть таблица на десятки миллионов записей. При росте данных в ней, тайминги увеличились. Запросы - а основном селекты по уникальному ключу. намного реже есть агреригующие запросы.Если сделать шардирование - те несколько инстансов бд и там хранить порции данных, то для запросов по уникальному ключу все становится лучше, но больше и сложнее становится агрегирующий запрос, ТК с ним приходится обходить все шарды, потом собирать все данные в кучу.
Вот такую картину я имею.
Вот такую картину я имею.
Выглядит так будто у вас аналитическая база данных