Позвольте мне предположить, что вы хотите сделать слишком большое количество вставок, так что вы просто хотите просто игнорировать все другие виды операций, просто чтобы эти вставки завершались без проблем.
Во-первых, вы полностью исключили другие типы баз данных? Существуют такие системы, как промышленные базы данных, которые очень хорошо справляются с огромным количеством вставок, обычно используемых для получения и хранения данных от оборудования, которое измеряет что-то в заводской среде. Oracle - это реляционная база данных, которая может не подходить для ваших нужд.
Сказав это, давайте предположим, что вы можете, или будете, или должны, использовать Oracle. Самое первое, что вам нужно сделать, это рассмотреть все различные типы данных, которые вам нужны, чтобы сделать это предположение. Если они все относятся к одному и тому же типу данных, вам нужна 1 таблица, и она должна быть скудной и средней по вставкам.
Оптимальный способ сделать это - сделать следующее:
- вообще не добавляйте индексы в эту таблицу, если вам нужен первичный ключ, это единственный индекс, который вам нужен
- если вам нужно выполнить чтение по этой таблице, подумайте о том, чтобы иметь теневую таблицу с индексами, по которым вы выполняете чтение, поиск и агрегирование. Если это не нужно обновлять с точностью до миллисекунды, рассмотрите периодическое пакетное задание, чтобы обновить его данными из главной таблицы. Это будет как можно меньше мешать главной таблице с блокировками чтения
- Убедитесь, что на вашем сервере установлены быстрые диски. Транзакционные операции записи обычно связаны с диском в какой-то момент, поэтому убедитесь, что это небольшое узкое место, которое вы можете получить.
- Если ваше приложение собирает данные из многих входящих источников, рассмотрите возможность добавления слоя перед базой данных, который будет сводить к минимуму количество одновременных соединений и, следовательно, транзакций в эту таблицу. Если вы получите большое количество блокировок записи на одну и ту же страницу для базы данных Oracle, в конечном итоге ваша производительность пострадает.
Если вы можете разделить данные, рассмотрите возможность их разделения таким образом, чтобы они сохранялись на разных физических дисках. Таким образом, проблемы с дисковым вводом / выводом не будут относиться к разным типам данных и затрагивают только один тип данных.
На другом конце спектра у вас есть денормализованная таблица с большим количеством индексов, оптимизированных для баланса между поисками и обновлениями, и вам нужно найти какой-то средний путь, который обеспечит вам желаемую производительность.