Автор: Curt Monash
Дата публикации оригинала: 2008-08-20
Перевод: Олег Кузьменко
Источник: Блог Курта Монаша

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

Многие новые приложения строятся поверх уже существующих баз данных путем добавления новых функций или опций к уже работающим системам. Но другие создаются вместе с новыми базами данных. И в таких случаях редко бывает, чтобы одна из ведущих СУБД служила бы лучшим выбором. СУБД среднего уровня (для задач OLTP) или специализированные системы хранилищ данных обычно предоставляют все те же самые возможности и являются гораздо более эффективными с точки зрения затрат. Исключения из вышесказанного появляются, главным образом, в следующих трех случаях:

  • Маленькие предприятия с очень ограниченным числом сотрудников
  • Большие предприятия, которые получили большие скидки у поставщиков ведущих СУБД
  • Сверхпроизводительные приложения OLTP, для которых требуется наивысшая производительность СУБД (или сертификация по безопасности и т.д.)

Во всех остальных случаях менее дорогие продукты обычно являются более разумным выбором.

В области аналитических приложений комплексы (data warehouse appliance) и другие специализированные продукты для хранилищ данных имеют громадное преимущество по критерию «цена/производительность» по сравнению с системами общего назначения. Более того, их более высокая производительность позволяет им обходиться гораздо более простыми индексами, что сильно уменьшает затраты на администрирование. Если у вас есть хранилище или лишь коллекция витрин данных, которые работают на Oracle или Sybase Adaptive Server или Microsoft SQL Server, то, скорее всего, вы бы оказали самому себе большую услугу, если бы вы переключились на использование специализированного решения.

Если вы – независимый поставщик ПО, который продает один и тот же софт разным покупателям, то вам не следует замыкаться на дорогие СУБД верхнего уровня. Какими бы не были пока неустраненные недостатки систем среднего уровня, по меньшей мере одна из этих систем несомненно подойдет для вашего софта, причем затраты на перенос на новую платформу будут вполне приемлемыми. (Во многих случаях, СУБД Postgres Plus Advanced Server компании EnterpriseDB будет иметь преимущество из-за своей совместимости с Oracle, а также благодаря богатому набору функциональных возможностей). Более того, помимо достижения экономии на стоимости лицензий и сопровождения, вашим клиентам будет проще управляться с СУБД среднего уровня, чем с их сложными собратьями верхнего уровня.

OLTP-приложения собственной разработки являются единственным случаем, когда отказ от СУБД-лидеров может оказаться опрометчивым. Первое правило для OLTP-приложений гласит: «OLTP-приложения не должны ломаться». И поэтому если они не сломаны, то очень часто не рекомендуется пытаться чинить их. В некоторых случаях, тем не менее, перенос на другую СУБД будет хорошей идеей, но чаще вы найдете какое-нибудь другое приложение на вашем предприятии, которое будет проще и безопаснее портировать, чем OLTP-систему.

Как можно себе представить, этот пост содержит только совсем небольшую часть анализа по выбору СУБД. В самом деле, это является главной темой нашего блога DBMS2. Вот рекомендуемые ссылки на эту тему:

Ссылки на статьи Курта по следующим категориям (на английском языке): Database diversity


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: