1 поддержка схемы оракула большой запрос в день, это безопасно?

Question

Я дизайнер системы Java. Поскольку у нас есть большой проект, чтобы сделать плотно,
Эти проекты Java API без веб-страницы.

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

Они все почти завершены. Но команда DBA обеспокоена тем, что ему приходится поддерживать очень большой запрос к 1 схеме.

1 причина в том, что если есть проблема, это какая-то таблица. Он должен отключить табличное пространство, чтобы исправить. Это проблема, потому что будет затронут весь проект.

Я пытаюсь убедить, разделив данные каждой таблицы, разделить на код проекта и «номер месяца для удаления».

Eaxmple раздел:

PROJ1_05 PROJ1_06 PROJ1_07
PROJ2_05 PROJ2_06 PROJ2_07

и вся таблица транзакций будет храниться в своем разделе.

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

Транзакция в день должна составлять около 10 миллионов записей в день.

Это хорошая идея?
Если я должен использовать одну схему, что такое стратегия?
Есть ли у вас какие-либо комментарии?

Answer 1

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

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

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

Я бы использовал 1 схему / 1 таблицу для каждого типа дизайна данных лично, если бы не было действительно веской причины дублировать структуру и выделять ее в другие схемы (юридические или контрактные требования).

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