У меня есть таблица пользователей, таблица транзакций и таблица user_transaction. количество пользователей составляет около 75 000. Количество уникальных транзакций, возможных в приложении, составляет около (количество строк в таблице транзакций составляет от 1 до 3 миллионов). user_transaction - это объединение двух приведенных выше таблиц, в которых хранятся данные о том, какие транзакции пользователи выполняли, в какой день и время. Итак, эта таблица будет огромной за 1 год данных (мы собираемся удалить активные данные из таблицы и заархивировать их через 1 год). Мы ожидаем, что количество строк будет около 50-60 миллионов. Это будет окончательный объем данных в конце года.
Я бы сказал, что средний размер составляет около 30 миллионов записей. Кроме того, еженощное задание импорта обновляет все эти таблицы, и это единственная часть, когда в эти таблицы выполняются вставки, мы получаем доступ только к данным (используем запросы выбора) из нашего приложения.
Как лучше всего спроектировать таблицу соединений, чтобы ускорить извлечение из огромной таблицы транзакций? Мы добавили много полей в таблицу, чтобы денормализовать ее и уменьшить количество объединений, и почти все данные доступны только в таблице транзакций и user_transaction.
Если мы хотим разбить таблицу на разделы, как нам это сделать? Приложение чаще всего используется для запроса самых свежих данных.
Мы думаем о том, чтобы разделить таблицу транзакций по месяцам, чтобы у нас была 1 таблица на каждый месяц.
Другой вариант, о котором мы думали, - иметь по 7 таблиц на 1 день недели, но это значительно увеличивает сложность запросов, учитывая, что мы используем спящий режим.
Как мы спроектируем огромный стол на 60 миллионов?
Дополнительная информация по запросу:
Мне нужно будет построить диаграмму из схемы, а пока еще немного информации: отношения несложные, это примерно 4 таблицы: пользователи, транзакции. , users_transaction, таблица ресурсов. user_transaction - это объединяемая таблица, содержащая все остальные три идентификатора таблиц, и эта таблица будет огромной, поскольку она будет иметь отдельные записи для каждого из этих идентификаторов, а также отдельные записи на основе метки времени.
Количество пользователей приложения сейчас очень мало ‹20. (но может вырасти в будущем).
Основными потребителями таблиц являются:
1) еженедельные отчеты самооценки, рассылаемые в виде электронных писем, содержащие сведения об активности пользователей за последнюю неделю из этих таблиц. они будут отправлены (в конечном итоге) 75 000 лайкам пользователей, а создание отчета и отправка электронного письма для 1 пользователя в настоящее время занимает около 1 минуты (тестирование на пилотной фазе). нам нужно серьезно улучшить производительность, чтобы лайк составлял менее 5 секунд на одно электронное письмо. Это внутреннее задание, которое выполняется ночью (должно занимать не более 3-4 часов)
2) Панели мониторинга, содержащие диаграммы, которые показывают сводное представление транзакции из этих таблиц. Эти запросы выполняются и суммируют данные на основе различных полей в диапазоне дат. Следовательно, мы планируем суммировать таблицу user_transactions, в которой хранятся счетчики за каждый день (не включая время), если все остальные поля одинаковы (идентификатор пользователя, идентификатор ресурса, resource_eventid, местоположение).
И разделите эти сводные таблицы по месяцам. (по одному на каждый месяц)
На заметку: решение должно подходить для всех баз данных (MySQL, DB2 и т. д.), а не только для Oracle.
С уважением, Приянк Девуркар