Я всегда был твердо убежден, что крупномасштабная многопользовательская СУБД должна размещаться автономно на выделенном сервере или кластерах, без других ненужных приложений, процессов или служб, которые могли бы красть ресурсы у СУБД. Я также считаю, что СУБД должна быть тесно интегрирована с ОС, которая была специально разработана для обеспечения СУБД максимально возможной производительности! Такие фирменные системы, как Pick, Terradata и другие, были разработаны с этой целью. Попадет ли в эту категорию последняя система Sun/Oracle?.. Имеет ли смысл реализовать такую архитектуру с другими СУБД, такими как INFORMIX?
решение1
В целом, существуют определенные атрибуты СУБД ACID, которые в совокупности обеспечивают полиномиальные характеристики производительности при объединении двух или более компьютеров для обслуживания одной базы данных.
Существует ряд попыток решить эту проблему:
Максимально оптимизируйте базу данных, уменьшив транзакционность, сократив количество соединений и т. д.
Максимально оптимизируйте один компьютер для обслуживания базы данных — например, оптимизируйте поддерживающую операционную систему, оптимизируйте диски и т. д.
Вертикальное масштабирование путем обслуживания базы данных одним необычайно мощным компьютером.
Распределение СУБД путем сегментирования или размещения разных таблиц в разных базах данных.
Использование действительно распределенной базы данных, которая теряет некоторые атрибуты ACID RDBMS, но предлагает истинное распределение и сопутствующую ему производительность. Например, Cassandra и другие. И действительно распределенные базы данных могут работать на обычном оборудовании, поскольку производительность распределенной базы данных основана главным образом на количестве узлов, а не на производительности любого конкретного узла.
Для первых четырех методов существуют жесткие ограничения. Для пятого ограничений нет.
Поскольку потребности базы данных растут во много раз быстрее, чем настройки и оборудование могут за ними поспевать, неизбежным решением станет распределенная база данных. Конечно, многие люди попытаются настроить свои серверы баз данных, а затем будут вынуждены перейти на массивное оборудование, но это всего лишь временная мера, и когда этого станет недостаточно, они будут вынуждены перейти на распределенную базу данных.
решение2
Если у вас есть лишняя четверть миллиона долларов США, вы можете рассмотреть возможность покупки частимашина Oracle Exadata. Это высококонфигурируемое устройство базы данных с тщательно подобранным аппаратным обеспечением и доведенной до совершенства ОС Solaris для оптимизации производительности Oracle.
решение3
Интеграция между Oracle и Solaris теснее большинства. Я не могу подтвердить, что она соответствует вашему списку требований.
решение4
Я предполагаю, что вы хотите обсуждения, а не ответов... но мой ответ в любом случае «Нет»
В большом корпоративном магазине каждая установка Oracle, Sybase и SQL Server может использовать наименьший общий знаменатель: SAN. Это само по себе может быть транзакционно реплицировано за пределы сайта. Спросите любого корпоративного DBA.
В любом магазине качество кода будет более важным фактором, чем сервер/ОС. Никакая оптимизация и интеграция не спасут вас от плохой индексации, например.
Другие моменты:
- Терабайтная БД — это скорее вопрос резервного копирования/восстановления/SLA, IMHO.
- Активный набор данных или ежедневный прирост — вот о чем вам следует беспокоиться с точки зрения производительности.