Я всегда был твердо убежден, что крупномасштабная многопользовательская СУБД должна располагаться автономно на выделенном сервере или в кластерах, без других ненужных приложений, процессов или служб, которые могут украсть ресурсы СУБД. Я также считаю, что СУБД должна быть тесно интегрирована с ОС, которая была адаптирована для обеспечения максимально возможной производительности СУБД! С этой целью были разработаны проприетарные системы, такие как Pick, Terradata и другие. Попадёт ли последняя система Sun / Oracle в эту категорию? .. Имеет ли смысл реализовать такую архитектуру с другими СУБД, такими как INFORMIX?
Если у вас есть нечетная четверть миллиона долларов, которую можно потратить, вы можете подумать о покупке части машина Oracle Exadata. Это тщательно сконфигурированное устройство базы данных с выбранным высокоспециализированным оборудованием и настройками Solaris до тех пор, пока он не начнет работать, чтобы оптимизировать производительность Oracle.
Я предполагаю, что вам нужно обсуждение, а не ответы ... но в любом случае мой ответ "Нет"
В большом корпоративном магазине каждая установка Oracle, Sybase и SQL Server может использовать наименьший общий знаменатель: SAN. Это само может быть реплицировано транзакциями за пределами сайта. Спросите любого корпоративного администратора базы данных.
В любом магазине качество кода будет более важным фактором, чем сервер / ОС. Никакая оптимизация и интеграция не спасут вас, например, от плохой индексации.
Прочие моменты:
Очень субъективно.
Во-первых, хотя SQL Server может быть выделен для ОС Windows на оборудовании x86, ни оборудование, ни программное обеспечение не предназначены специально для запуска платформы базы данных. Более того, хотя SQL Server был разработан для того, чтобы максимально использовать возможности Windows, не следует, что он в первую очередь предназначен для повышения производительности. В случае с SQL Server я бы сказал, что вместо оптимизации производительности он был оптимизирован для администрирования и интеграции.
Во-вторых, производительность оборудования быстро увеличивается с течением времени, поэтому то, что вы покупаете в качестве оптимального оборудования в этом году, перестанет достигать своего пика через год и значительно устареет через три года. Немногие покупатели будут обновлять свое оборудование так часто, поэтому покупка платформы базы данных для повышения производительности оборудования кажется недальновидной.
В-третьих, если компания, занимающаяся базами данных, создает ОС, предназначенную для своей базы данных, сможет ли она привлечь лучших специалистов по ОС? Если нет, то это вопрос суждения, будет ли программное обеспечение баз данных работать быстрее на общей ОС, созданной лучшими специалистами по ОС, или на специальной ОС, созданной «низшим подразделением».
Наконец, в некоторой степени вы часто можете улучшить производительность, добавив больше (или более дорогое) оборудования в узкие места. При заданном бюджете вы можете получить более выгодную сделку, если потратите деньги на компоненты «A» в общей сборке, чем на оценку «B» от специалиста. Дженерик будет дешевле, потому что чем больше клиентская база, тем больше могут быть распределены базовые затраты (и тем больше ценовая конкуренция вступает в игру между поставщиками).
PS. Очевидно, что производительность - не единственный критерий для покупки. Время безотказной работы, наличие навыков и т. Д. - все это имеет значение. Как и финансовая безопасность поставщика / направления бизнеса. Я работал в компании, которая в начале 90-х решила, что Mac - лучший настольный компьютер. Они застряли с кучей машин без возможности обновления.
Интеграция между Oracle и Solaris более тесная, чем у большинства. Однако я не могу подтвердить, что он соответствует вашему списку требований.
В общем, существуют определенные атрибуты СУБД ACID, которые в совокупности дают характеристики производительности за полиномиальное время, когда вы объединяете два или более компьютеров для обслуживания одной базы данных.
Есть несколько попыток решить эту проблему:
Максимально оптимизируйте базу данных, уменьшив транзакционность, уменьшив количество соединений и т. Д.
Максимально оптимизируйте один компьютер для обслуживания базы данных - например, оптимизируйте поддерживающую операционную систему, оптимизируйте диски и т. Д.
Вертикальное масштабирование за счет обслуживания базы данных одним чрезвычайно мощным компьютером.
Распространение СУБД путем сегментирования или помещения разных таблиц в разные базы данных.
Использование действительно распределенной базы данных, в которой отсутствуют некоторые атрибуты СУБД ACID, но при этом обеспечивается истинное распределение и сопутствующая производительность. Например, Кассандра и другие. По-настоящему распределенные базы данных могут работать на стандартном оборудовании, поскольку производительность распределенной базы данных зависит главным образом от количества узлов, а не от производительности любого конкретного узла.
Первые четыре метода имеют жесткие ограничения. Пятому нет предела.
Поскольку база данных должна расширяться во много раз быстрее, чем могут поддерживать настройки и оборудование, неизбежным решением будет распределенная база данных. Конечно, многие люди попытаются настроить свои серверы баз данных, а затем будут вынуждены перейти на массивное оборудование, но это всего лишь временный промежуток, и когда этого перестанет быть достаточно, они будут вынуждены перейти на распределенную базу данных.
Вы должны проверить IBM System i Платформа. Он поддерживает DB2 для i, который не совсем совместим с DB2 UDB, но достаточно близок.
База данных очень тесно интегрирована с ОС. Мне сказали, что эта платформа обеспечивает уровень эффективности и производительности, превосходящий самые смелые мечты пользователей любой из «основных» архитектур Windows / Linux / Solaris / и т. Д.
У меня лично нет опыта работы с ним, но многие пользователи платформы System i им доверяют, и, похоже, это отвечает вашему стремлению к тесной интеграции.