Дублирование данных в другой таблице для повышения производительности

Question

В настоящее время я разрабатываю архитектуру базы данных для продукта, который находится в процессе создания. Я просто рисую все в файле Excel, прежде чем начать создавать все в MySQL.

В настоящее время у меня есть две разные таблицы, которые почти идентичны друг другу.

TABLE A, который содержит самые последние значения каждой точки данных для каждого пользователя.

TABLE B, который содержит ежедневные записи каждой точки данных для каждого пользователя.

Мое обоснование для создания TABLE A вместо того, чтобы полагаться исключительно на TABLE B, заключается в том, что число строк в TABLE B будет ежедневно возрастать в зависимости от количества моих клиентов. Например, скажем, у меня 20 000 клиентов, TABLE B будет расти на 20 000 строк каждый день. Таким образом, создав TABLE A, мне нужно будет только просмотреть 20 000 записей, чтобы найти самые последние значения каждой точки данных для каждого пользователя, так как я буду обновлять эти значения каждый день; тогда как для TABLE B мне пришлось бы искать в постоянно растущем количестве строк самую последнюю вставку для каждого пользователя.

Это приемлемая или хорошая практика?

Или я должен просто забыть о TABLE A, чтобы уменьшить «раздувание» в моей базе данных?

Answer 1

В ситуациях, когда мне нужны как «текущие» данные, так и «история», это то, что я делаю - одна таблица с текущими данными и одна с историей. Возможно, они по-разному индексируются для разного использования и т. Д.

Я бы подумал, что отличается между "историей" и "текущим", а затем сделал бы таблицы разными не идентичными .

Когда появится новая запись (или 20K строк в вашем случае), я, по крайней мере, добавлю ее в Current. Я также могу записать его в History, тем самым сохраняя его полным (за счет небольшой избыточности). Или я могу переместить ряд (ы) в History, когда следующий ряд (ы) войдет в Current.

Я не вижу необходимости в PARTITIONing, если только я не собираюсь удалять «старые» данные. В этом случае я бы использовал PARTITION BY RANGE(TO_DAYS(..)) и выбрал бы еженедельно / ежемесячно / что угодно, чтобы число разделов не превышало 50. (Если вы выберете «ежедневно», History через несколько месяцев замедлится, просто потому, что разбиения.)

20К строк каждый день - многие из них не изменились со вчерашнего дня? Это, вероятно, не правильный способ делать вещи. Пожалуйста, опишите, что происходит каждый день. Вам следует избегать дублирования строк в History (кроме даты).

Answer 2

Это не правильный подход. У вас есть два разумных варианта:

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

Вы можете управлять двумя таблицами, но это большая проблема, и есть встроенные методы для решения этой ситуации.