AG
Может можно как-нибудь аккуратно это обрабатывать
Size: a a a
2020 April 17
AG
да, но тогда размер таблицы вечно растёт, хотя количество актуальных записей меняется несильно.
можно попробовать горизонтальный шардинг, если данных овермного и это влияет на перформанс
SS
архивить бд, кромсать, если нужно чего то из истории, поднимать на деве
QH
можно попробовать горизонтальный шардинг, если данных овермного и это влияет на перформанс
да блин 😐
У меня нет никакой распределёнки, всё на одной тачке. Проблем со скоростью пока нет, но количество данных будет неумолимо расти.
Я хочу выбрать такой способ хранения, который в первую очередь обеспечит быстрый (не замедляющийся со временем) доступ к свежим данным.
У меня нет никакой распределёнки, всё на одной тачке. Проблем со скоростью пока нет, но количество данных будет неумолимо расти.
Я хочу выбрать такой способ хранения, который в первую очередь обеспечит быстрый (не замедляющийся со временем) доступ к свежим данным.
QH
Sergey Shevelev
архивить бд, кромсать, если нужно чего то из истории, поднимать на деве
спасибо, кажется, я придумал себе запрос в гугл)
AG
шардинг можно сделать в рамках одной тачки)
простой вариант – как только количество записей в таблице > N, создавай новую такую же и пиши новые данные туда
простой вариант – как только количество записей в таблице > N, создавай новую такую же и пиши новые данные туда
QH
шардинг можно сделать в рамках одной тачки)
простой вариант – как только количество записей в таблице > N, создавай новую такую же и пиши новые данные туда
простой вариант – как только количество записей в таблице > N, создавай новую такую же и пиши новые данные туда
А какой в этом смысл?
SS
а какая БД?
AG
А какой в этом смысл?
> Я хочу выбрать такой способ хранения, который в первую очередь обеспечит быстрый (не замедляющийся со временем) доступ к свежим данным
QH
Sergey Shevelev
а какая БД?
Postgres
SS
у меня на mssql архивация настроена по квартально, раз в квартал данные уходят в архив, вообще в другую БД на этой же машине, в текущей БД заносятся данные, что такой-то период перешел в архив, ну и часть отчетов, которые данные дергают, смотрят в эту таблицу, если промежуток архивный, то данные берут из архивной БД, если нет, то из текущей, ну и индексы решают
SS
большая часть евентовых вещей вообще удаляются каждые 10 дней, которые не нужны и логовые таблицы
SP
ты кажется не так готовишь
возможно что-то про тайм сириес больше под задачу подойдет, если нужно трогать свежее, а старое ну чтобы было
возможно что-то про тайм сириес больше под задачу подойдет, если нужно трогать свежее, а старое ну чтобы было
AG
> ну и индексы решают
+
+
SP
кстати есть вот такая штука https://github.com/timescale/timescaledb может там что-то полезное будет
SP
но мы например делаем что одна очень толстая таблица с кучей инсертов уезжает в кликхаус, а все остальное продолжает жить в постгре
да, джойны руками в коде делаются
да, джойны руками в коде делаются
QH
кстати есть вот такая штука https://github.com/timescale/timescaledb может там что-то полезное будет
прикольно, спасибо
DP
да блин 😐
У меня нет никакой распределёнки, всё на одной тачке. Проблем со скоростью пока нет, но количество данных будет неумолимо расти.
Я хочу выбрать такой способ хранения, который в первую очередь обеспечит быстрый (не замедляющийся со временем) доступ к свежим данным.
У меня нет никакой распределёнки, всё на одной тачке. Проблем со скоростью пока нет, но количество данных будет неумолимо расти.
Я хочу выбрать такой способ хранения, который в первую очередь обеспечит быстрый (не замедляющийся со временем) доступ к свежим данным.
Привет 👋 Чтобы помочь с ответом, я хотел бы немного разобраться с проблемой:
- Что есть “свежие данные” у тебя в системе: те, что были созданы недавно, или обновлены недавно?
- Нужно ли тебе искать периодически и старые, и новые данные? А джойнить и старые и новые с другими таблицами?
- Есть ли у этой таблицы внешние ключи на другие сущности?
- Что есть “свежие данные” у тебя в системе: те, что были созданы недавно, или обновлены недавно?
- Нужно ли тебе искать периодически и старые, и новые данные? А джойнить и старые и новые с другими таблицами?
- Есть ли у этой таблицы внешние ключи на другие сущности?
QH
Привет 👋 Чтобы помочь с ответом, я хотел бы немного разобраться с проблемой:
- Что есть “свежие данные” у тебя в системе: те, что были созданы недавно, или обновлены недавно?
- Нужно ли тебе искать периодически и старые, и новые данные? А джойнить и старые и новые с другими таблицами?
- Есть ли у этой таблицы внешние ключи на другие сущности?
- Что есть “свежие данные” у тебя в системе: те, что были созданы недавно, или обновлены недавно?
- Нужно ли тебе искать периодически и старые, и новые данные? А джойнить и старые и новые с другими таблицами?
- Есть ли у этой таблицы внешние ключи на другие сущности?
Созданы недавно. Всё старше недели можно архивировать.
Сейчас они вообще не вытаскиваются, тупо мёртвый груз. Мне кажется, что можно иногда захотеть вытаскивать их по айди.
Есть, старые
Сейчас они вообще не вытаскиваются, тупо мёртвый груз. Мне кажется, что можно иногда захотеть вытаскивать их по айди.
Есть, старые
заявки ссылаются на город отправления и город назначения.SS
можно из заявок делать агрегированные важные данные, которые могут потом понадобиться, а старое в утиль