СУБД с открытым кодом. Зачем платить больше?

Головна Огляди СУБД с открытым кодом. Зачем платить больше?

09.07.2015

Огляди

Отказ от коммерческого программного обеспечения – не самая эффективная стратегия. При выборе СУБД заказчики и разработчики приложений должны оценивать возникающие риски в комплексе.

В сложившейся экономической ситуации компании ищут возможность сократить затраты. Часто, в первую очередь «под нож» идет бюджет на ИТ. Для оптимизации затратных статей рассматривают внедрение или полный переход на ПО с открытым кодом. Рассмотрим на примере систем управления базами данных возможна ли такая замена и не будет ли от нее больше вреда, чем пользы.

СУБД можно разделить на коммерческие – это Oracle, MS SQL Server, DB2 и др.; СУБД с открытым кодом, которые можно свободно скачивать и модифицировать, и СУБД локальных производителей. Т.к. свободно распространяемые и СУБД локальных производителей не предлагают многих характеристик, необходимых для реализации систем с высокими требованиями к надежности, безопасности, производительности – объединим их в некоммерческих СУБД.

Коммерческие СУБД создавали десятками тысяч людей десятки лет, их создание требует промышленной технологии разработки, тестирования, сопровождения, развития, исследовательских лабораторий. Новые сложные технологии в СУБД развиваются и ”шлифуются” многие годы. Например, одна из сложнейших технологий Oracle Real Application Clusters совершенствуется уже более 10 лет. Производители некоммерческих СУБД следят за характеристиками и новыми возможностями коммерческих систем и постепенно реализовывают наиболее важные механизмы в своих продуктах. Этим разработкам приходится догонять. Зато они хорошо реализуют новые эффективные алгоритмы, новые типы индексирования, новые специфические типы данных и т.д.

СУБД с открытым кодом имеют много достоинств. Такие системы разрабатываются энтузиастами. Разработчики открытого ПО могут экспериментировать, они не связаны жесткой дисциплиной больших корпораций. К тому же многие компании поддерживают сообщества таких разработчиков финансами и продуктами, даже сами часто помогают в разработке. Известен вклад Oracle, IBM, HP в эти сообщества. Так Oracle поддерживает открытый код для СУБД MySQL, InnoDB и Berkeley DB, гипервизора Oracle VM, OC Oracle Linux, платформы и компиляторов Java, сервера приложений GlassFish и т.д. Открытый код хорош, для организаций с множеством программистов, которые знают этот код и способны изменить его под свои требования без задействования основных разработчиков. Обратная сторона технологии открытого кода – сильное отставание некоммерческих систем по своим характеристикам от коммерческих СУБД из-за нехватки ресурсов. Например, согласно Wikipedia, в сообществе разработчиков PostgreSQL около 1000 человек, большая часть работает время от времени.

Большинству некоммерческих СУБД недоступны отлаженные важные функции коммерческих систем. Real Application Clusters – разделение нагрузки между несколькими физическими компьютерам, которые работают как один. GRID - переброс вычислительных мощностей и компьютеров для обслуживания критичных в данный момент приложений. Мощный Oracle Рatitioning (кроме MySQL) - возможность работы с частями больших таблиц. Онлайн администрирование на лету. Средства тестирования изменений в онлайн и в тестовой среде под реальной нагрузкой. Технологии Oracle Database In-Memory - работа в памяти с поколоночным хранением. Машины баз данных и реализация команд СУБД в ядре процессора и т.д. Часть некоммерческих систем предлагает менее мощные оптимизаторы запросов. Из-за низкой производительности такие СУБД не участвуют в независимых тестах производительности.

Возможно, для небольших систем этот арсенал архитектуры максимальной доступности не остро необходим. Но всем неприятен отказ мобильной связи или систем принятия решений в самый важный момент. Например, из-за неудачных изменений или регламентных работ. А потеря данных при сбое обработки заказа или повторная оплата уже оплаченного товара – совсем неприемлемы.

Безусловно некоммерческие СУБД не стоят на месте, и со временем получат новые возможности (кроме RAC), коммерческие СУБД к этому моменту уйдут очень далеко. Несколько лет назад появились специализированные программно-аппаратные комплексы Exadata Database Machine, которые на порядок ускоряют выполнение приложений СУБД благодаря новой вычислительной архитектуре. Активно развивается технология Іn-Memory, которая еще на порядок ускоряет выполнение аналитических запросов, при помощи новых алгоритмов. Команды СУБД в этом году были зашиты в ядро процессора Oracle SPARC М7 и выполняются еще на порядок быстрее. Сейчас идет тестирование этих процессоров.

Для того, чтобы делать машины баз данных и реализовать команды СУБД в чипе необходимо производить СУБД, процессоры и серверы. В то время, как некоммерческие СУБД все еще занимаются оптимизацией программного кода и ускорением в 2-4 раза некоторых программных компонентов.


Ускорение 5-10 раз	Ускорение 10 – 100+ раз	Ускорение 10++ раз

Большинство решений с открытым кодом не имеет мощных средств администрирования, диагностики, настройки, самонастройки. Такие СУБД не поддерживают работу с очень большими базами данных, обычно это несколько терабайт. Сейчас уже широко распространены БД в десятки и сотни терабайт и их объемы продолжают расти. Разработчики советуют не хранить много лишних данных или заменить одну СУБД на несколько. Но если баз становится много, управление ими превращается в кошмар. У Oracle для решения этих проблем есть опция Oracle Multitenant, Oracle Enterprise Manager, Cloud Control, Oracle Diagnostics & Tuning Packs. О таких тенденциях как частные облака, мобильные вычисления, Интернет вещей, которые будут актуальны, уже ближайшие несколько лет, СУБД с открытым кодом пока даже не думают.

Не бывает программ без ошибок. Работоспособность СУБД гарантирована только при наличии мощной системы технической поддержки, которая работает круглосуточно и оперативно решает проблемы. Oracle обеспечивает пользователям своих продуктов такую систему поддержки с анализом проблем, контролем ответственности, работой 24x7, возможностью моделирования сбоев и т.д. Сообщества некоммерческих решений могут предложить направить информацию об ошибке в англоговорящее сообщество, и специалист по этой части кода, по мере своих возможностей, отреагирует на обращение. Количество пользователей у Oracle на порядок больше, потому ошибки выявляются раньше и исправляются быстрее.

Миграция с существующими СУБД с открытым кодом также потребует значительного вложения средств и может занять гораздо больше времени. Даже для небольших приложений это огромный проект, часто дороже, чем переписывание приложения с нуля. Хороших средств автоматизации процесса миграции либо нет, либо это дорогие решения международных корпораций. Полученный в результате миграции код, будет хуже по производительности, надежности и потребует последующей сложной настройки. Часто стоимость миграции соизмерима со стоимостью новой разработки.

И наконец, полная стоимость владения (ТСО). Один из сильнейших аргументов ПО с открытым кодом – отсутствие платы за лицензию. Следует говорить не о стоимости ПО, а о стоимости владения. При учете только стоимости покупки ПО часто забывают, что стоимость лицензий лишь малая часть стоимости IT системы (10-20%). Основная часть расходов связана с разработкой, тестированием, сопровождением систем. Администрирование, настройка, диагностика, установка обновлений, отлаженные алгоритмы внутреннего тестирования заметно сильнее у коммерческого ПО. Для сложных проектов использование открытого ПО может привести к более высоким затратам. Часто эти дополнительные расходы намного превышают стоимость исходного ПО СУБД.

Широко известен Мюнхенский проект замены коммерческого ПО на программное обеспечение с открытым открытым кодом. Предполагалось, что использование свободно распространяемого программного обеспечения, позволит сэкономить $16 млн. Проект длился 10 лет, чиновников мэрии переводили на открытое ПО. Инициаторы проекта получили награды и повышения по службе. Сейчас рассматривается вопрос возврата на коммерческое ПО. На доработку отсутствующих функций, устранение несовместимости с оборудованием, интеграцию с другими системами уже потрачено в разы больше сэкономленных $16 млн. Добавьте сюда затраты времени на обучение и простои, связанные с адаптацией пользователей к работе с новыми продуктами.

Некоммерческие СУБД, можно рассматривать, как нишевые, приемлемые для небольших систем без требований по надежности и безопасности. Так SQLite – маленькая СУБД для работы на мобильных устройствах. А вот для «живой» IT-системы, которая дополняется и изменяется согласно новых требований, менее затратно работать надежных коммерческих решениях. Отказ от коммерческих СУБД – не самая эффективная стратегия. При выборе СУБД заказчикам и разработчикам приложений следует оценивать возникающие риски в комплексе (технологические, финансовые, бизнес риски и т.д.).

По материалам А. Лашманова «Открытые системы»