используйте SUM () или кеширование

Question

У меня нет большого опыта работы с базами данных, поэтому я не знаю, что лучше для долгосрочной производительности, лучшей практики и т. Д.

Вот мой (гипотетический) случай: представьте, что у вас есть база данных о клиентах и ​​истории заказов на покупку для каждого. Вы хотите отслеживать, сколько покупает каждый клиент. Я могу думать о двух способах вычисления этого:

1) Просто делайте СУММУ () каждый раз, когда это необходимо. Это простое решение, но проблема заключается в том, что этой базе данных может быть 20 лет с десятками тысяч строк для каждого клиента. По мере добавления покупок в базу данных операция SUM () будет рассчитываться дольше.

2) Сохраните сумму, сохраненную в кэше, в таблице информации о клиентах, и каждый раз, когда совершается новая покупка (обновляется, удаляется и т. Д.), Обновляйте этот кэш. Таким образом, независимо от количества заказов на покупку, время расчета не увеличится. Недостатком является то, что это менее гибкое решение (только сумма по всем строкам, как насчет суммы за месяц? Другие интервалы? И т. Д.); это кэшированное значение может как-то не синхронизироваться с фактическим итогом (технически это не должно происходить, но может произойти)

Так что мне делать для этого? Я знаю, что не должен хранить ничего, что я могу рассчитать на основе того, что уже есть в базе данных, но часть меня не любит тот факт, что этот тип вычислений ухудшится со временем, и что есть некоторая элегантность для выбора 2.

Answer 1

С точки зрения базы данных, в варианте 2 нет элегантности - это будет считаться хаком, который вы могли бы использовать в качестве последнего средства, если ваша база данных станет действительно огромной - вряд ли это случится для новичка, настроившего ее для в первый раз (но возможно).

Было бы много работы по поддержанию итогов; и вы навсегда столкнетесь с вопросом: «Почему детали не составляют общую сумму?»

Выбирайте вариант 1, пока не докажете, что не можете. Который в большинстве случаев будет долгим.

Answer 2

То, что вы описываете в варианте №2, является случаем преждевременной оптимизации. Использование суммы () всех покупок будет работать очень долго (годы). Когда (если) вы начнете видеть, что эта функция ухудшается, вы можете добавить индексы или итоговую таблицу в вашу базу данных, чтобы ускорить процесс. Не усложняйте вещи, когда существует простое решение.

Конечно, решение real состоит в том, чтобы попробовать оба решения с 20-летними данными и посмотреть, есть ли какая-то реальная разница. Я подозреваю, что нет.

Answer 3

Я просто добавлю, что есть еще одна возможность - создавать сводные таблицы. Например, при отслеживании посещений страницы не очень полезно знать, что IP-адрес такой-то и такой-то обращался к page1.php в 14:42:04 19.11.2008; но вы можете отслеживать ежедневную статистику для page1.php. В этом случае в конце каждого дня вы можете запускать процедуру суммирования посещений для каждой страницы и создавать запись в сводной таблице, которая, в свою очередь, может быть сильно проиндексирована. Тогда ваши отчеты могут работать с этой таблицей. Помимо ускорения создания отчетов, он также может ускорить запись исходных записей, поскольку вам не нужно беспокоиться о блокировке таблиц или построении индексов.

Тем не менее, хорошие показатели могут иметь большое значение для отчетности; и, как и другие здесь предупреждают, лучше идти с более простым, хотя и менее оптимальным, решением, пока (если вообще) не станет проблемой.

Answer 4

Почти всегда 1.

Как часто вы будете запрашивать общую сумму за 20 лет истории? Если ответ часто, а производительность низкая, тогда вы можете подумать об оптимизации или OLAP.

Я подозреваю, что вы беспокоитесь об оптимизации слишком рано. Это то, для чего предназначены базы данных - пусть они беспокоятся о кешировании.

Answer 5

Используйте опцию 1. Позже, если производительность ухудшается, вы можете определить конкретные узкие места и устранить их с помощью опций, таких как # 2, или материализованных представлений, или нескольких других возможностей.

Answer 6

Подумайте о том, чтобы думать о будущем, но возникает вопрос: ваши данные о продажах останутся в транзакционной базе данных в течение 20 лет?

Наступает момент, когда будет гораздо проще перенести эти данные в хранилище данных и просто поддерживать текущую базу данных на переднем крае.

Если это новый проект, уделите больше внимания тому, чтобы он работал и заставлял людей использовать его. Беспокойство о масштабируемости, когда вы пересекаете эти мосты.