стоит улучшать железо?
есть таблица, которая сейчас занимает 30 миллионов строк и растет на ~10 миллионов в сутки на сервере с 4 ядрами и 8 гб оперативки и банальный count там выполняется 3 секунды
primary key - uuidv4
это нормальная производительность или что то можно затюнить?
count невозможно ускорить, так как требует полный скан таблицы
его и не нужно считать
биллинг свой делаете?
нет, реакции пользователей собираем грубо говоря лайки
еще не пробовали это то что нужно для больших таблиц?
И как ему поможет партиционирование в подсчёте всех?
У вас count с условиями? Или на всю таблицу? Почему не кешируете?
Нормальная производительность или нет — зависит в первую очередь от бизнес-требований. Если та, что есть всех устраивает — то нормальная. Если на этом вы теряете клиентов или деньги — то, возможно, надо её улучшыть. Возможно и нет, если улучшать ещё дорожэ.
Возможно. Есть сэмплинг, есть другие оцэнки, есть предварительные подсчёты.
Количество лайков лучшэ просто хранить.
если бы такое было возможно - просто хранили бы а так они влияют на дальнейшее поведение сервиса для пользователя
ЯННП. (И да, неоднозначно выразился. Просто — в смысле хранить количество рядом с записью, а не в смысле — хранить только количество, а не клики).
При росте 10млн в сутки — давно пора, скоро прямо-таки в лимиты таблиц стукаться будет.
Большинство с моим предложением не согласны 🙂
И вробще, тот слуяай, когда можно попробовать citus. Довольно разрозненные данные, но их очень много.
Далее — всегда полезно самому чётко определить, что система делает при запросе. И что ты в идеале хотел бы, чтобы она делала. И чем одно от другого отоичается. Если всё и так по минимуму — то вздохнуть и забить. Если действия близки к идеальным, но затраты postgres на них велики — то подумать, что его задержывает, почитать код. Если действия неблизки к идеальным — то оптимизировать запросы, чтобы работал как хочется.
Обсуждают сегодня