разработка схемы для огромных таблиц в Oracle

Question

У меня есть пользовательская таблица, таблица транзакций и таблица user_transaction. количество пользователей составляет около 75 000, количество уникальных транзакций, возможных в приложении, составляет около (количество строк в таблице транзакций составляет от 1 до 3 миллионов). user_transaction - это объединение двух вышеуказанных таблиц, в которых хранятся данные о том, какие пользователи транзакций делали в какой день и время. ТАК, что эта таблица будет огромной за 1 год данных (мы собираемся удалить активные данные из таблицы и заархивировать их после год). Мы ожидаем, что количество будет около 50-60 миллионов строк. Это будет окончательный размер данных на конец года.

Я бы сказал, что средний размер составляет около 30 миллионов записей. Кроме того, еженедельное задание на импорт обновляет все эти таблицы, и это единственная часть, когда в эти таблицы производятся вставки, мы получаем доступ только к данным (используем запросы на выборку) из нашего приложения.

Каков наилучший способ создания таблицы соединений для ускорения извлечения из огромной таблицы транзакций? Мы добавили в таблицу множество полей, чтобы ее денормализовать и уменьшить объединения, и чтобы почти все данные были доступны только в транзакции и Таблица user_transaction.

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

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

Другой вариант, о котором мы думали, - это иметь по 7 таблиц на 1 день недели, но это значительно увеличивает сложность запросов, учитывая, что мы используем hibernate.

Как нам спроектировать огромный стол размером около 60 миллионов

Более подробная информация по запросу:
Мне нужно будет составить диаграмму из схемы, вот еще немного информации за это время: отношения не сложны, это около 4 таблиц: пользователи, транзакции, users_transaction, таблица ресурсов. user_transaction - это объединяющая таблица, содержащая все остальные три идентификатора таблицы, и эта таблица будет огромной, так как в ней будут отдельные записи для каждого из этих идентификаторов, а также отдельные записи, основанные на отметке времени.
Количество пользователей приложения сейчас очень меньше, чем <20. (но может расти в будущем). <br> Основными потребителями столов являются:
1) еженедельные отчеты самопроверки , отправленные в виде электронных писем с информацией об активности пользователей за прошедшую неделю из этих таблиц. они будут отправлены (в конечном итоге) 75 000 пользователей, создание отчета и отправка электронного письма для 1 пользователя в настоящее время занимает около 1 минуты (тестирование в пилотной фазе). нам нужно серьезно повысить производительность, чтобы на электронную почту приходилось менее 5 секунд. Это фоновая работа, которая выполняется ночью (должна занимать не более 3-4 часов)
2) Панели инструментов , содержащие диаграммы, которые показывают обобщенный вид транзакции из этих таблиц. Эти запросы запускают и суммируют данные на основе различных полей в диапазоне дат. Следовательно, мы планируем суммировать таблицу user_transactions, хранящую количество для каждого дня (не включая время), если все другие поля одинаковы (идентификатор пользователя, идентификатор ресурса, resource_eventid, местоположение).
И разделите эти сводные таблицы по месяцам. (по одному на каждый месяц)
Важно отметить: решение должно быть подходящим для всех баз данных (MySQL, DB2 и т. Д.), А не только для оракула.

С уважением, Приянк Девуркар

Answer 1

Хорошо, так обо всем по порядку.

1. Таблица с 30 миллионами строк не ОГРОМНА по стандартам Oracle.
2. Сказать, что у вас 75 000 пользователей, означает, что база данных неуправление вашими логинами пользователей, и, возможно, есть несколько ролей, которые имеют дело с базой данных.

Аудит ...

Oracle обладает очень мощными функциями аудита, поэтому стоит рассмотреть их преждевы пытаетесь свернуть свое собственное.

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

Самое простое, что нужно сделать, это иметьлюбой код переднего плана, который вы используете для вставки в эту таблицу, например:

вставка в таблицу аудита (userID, Operation) значений ('fred', 'платежей таблицы с обновлением и изменение какого-либо старого значения столбца на новое значение)');

Я бы сделал составной индекс userID и отметку времени, чтобы можно было запрашивать эти два столбца как одну сущность.Таблица будет выглядеть примерно так:

create table user_audit as 
(
user_id number,
action_timestamp systimestamp,
db_action clob
)

CREATE INDEX idx_user_audit_ia ON  user_audit (user_id,action_timstamp);

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

Эта таблица будет очень быстрой для удаления и вставки.Вы можете сделать это еще быстрее:

• Отсутствует ограничение первичного ключа.
• Отключение ведения журнала для этой таблицы или табличного пространства, в котором она находится.

• Отсутствие FK в таблице пользователей (это действительно бессмысленно).

• Если у вас достаточно оперативной памяти на компьютере базы данных, установите его на буферах кеша, но ТОЛЬКО если у вас достаточно оперативной памяти или вы положите сервер в бак.

• Если вы решите разбить раздел, выберите свой метод только после осторожно чтение и понимание разбиения в Oracle.

• Убедитесь, что уверены Ваше табличное пространство равно BIG TABLE при его определении сэто гарантирует, что вы не превысите ограничение размера (по крайней мере в linux) одного файла.

Что касается остальных баз данных, с которыми вы работаете, будут иметь свои индивидуальныепроблемы настройки, поэтому каждый из них представляет собой набор условий, которые подходят для одной БДно не другое.

Всегда помните девиз Unix, делайте одну вещь и делайте это хорошо .