Тема импортозамещения и снижения технологической зависимости России бурно обсуждается. Среди прочих высказывается мнение, что надо немедленно заменить все импортное ПО и перейти либо на отечественные аналоги, либо на ПО с открытым кодом. Более того, многим госструктурам советуют не использовать в новых проектах западное ПО и начать перевод существующих систем на альтернативные решения. Однако есть ли такие альтернативы, например, в сфере СУБД? Возможна ли быстрая замена западных программных продуктов и не будет ли от нее больше вреда, чем пользы? Что надо делать, чтобы повысить технологическую независимость? Анализ тридцатилетнего опыта работы с СУБД Oracle позволяет ответить на эти вопросы.

Все используемые сегодня в России СУБД условно можно разделить на коммерческие (Oracle, Microsoft SQL Server, IBM DB2 и др.), некоммерческие (СУБД с открытым кодом) и СУБД отечественного производства. При выборе СУБД заказчики и разработчики приложений обычно оценивают все риски: политические, технологические, финансовые, бизнес-риски и т. д. Однобокая ориентация только на политические риски может принести вред как бизнесу, так и национальной экономике в целом. Котлован при строительстве дома можно копать импортным экскаватором или отечественной лопатой. Второй способ не слишком быстрый, но есть риск, что экскаватор сломается, а запчасти не поставят. Что делать в этой ситуации?

Применительно к СУБД следует исходить из того, что каждая система имеет свою нишу, и это позволяет создавать наиболее эффективные решения. Например, СУБД MySQL широко используется в веб-приложениях, для построения сайтов в связке Linux — Apache — MySQL — PHP; PostgreSQL, «Линтер», BerkeleyDB хорошо себя зарекомендовали на поприще встроенных решений; СУБД SQLite — в качестве портативной СУБД для мобильных устройств. Тем не менее разработчики некоммерческих систем внимательно следят за коммерческими СУБД, реализуя наиболее важные механизмы в своих продуктах и постоянно выступая в роли догоняющих. По сравнению с разработчиками коммерческих СУБД, число разработчиков некоммерческих систем невелико, они разбросаны по миру, финансирование у них ограничено, исследовательских ресурсов фактически нет, поэтому они физически не в состоянии воплощать крупные идеи, хотя хорошо реализуют новые эффективные алгоритмы, новые типы индексирования, новые специфические типы данных и т. д.

Сегодня предлагается забыть о сосуществовании по принципу «от каждой СУБД по возможностям» и использовать только некоммерческое ПО, что вряд ли разумно, хотя бы потому, что большинство разработчиков некоммерческих СУБД живут вне России.

Адекватность замены

СУБД с открытым кодом разрабатываются энтузиастами, что позволяет достичь выдающихся результатов в создании новых алгоритмов, методов тестирования и отладки. Они могут позволить себе сосредоточиться на поиске наилучшего алгоритма работы с новым типом данных и ускорении его работы. Именно поэтому многие коммерческие компании поддерживают сообщества Open Source. Однако открытый код хорош, если в использующей его организации имеется множество квалифицированных программистов, знающих этот код и способных самостоятельно изменять его под свои нужды. Защищенность систем с открытым кодом, вопреки расхожему мнению, также находится обычно на высоком уровне — до сих пор не обнаружено закладок в открытом ПО, а многие из таких продуктов сертифицированы ФСТЭК.

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

Производительность. У большинства некоммерческих систем отсутствуют аналоги следующих механизмов: распределение нагрузки по нескольким физическим компьютерам; грид; развитые оптимизаторы запросов и параллельное выполнение запросов; администрирование без остановки работы; средства тестирования изменений в режиме онлайн и в тестовой среде под реальной нагрузкой; технологии работы в памяти с поколоночным хранением; машины баз данных (архитектура для ускорения работы СУБД за счет распределенной обработки и сокращения операций ввода-вывода); реализация команд СУБД в ядре процессора; мощные средства диагностики, настройки, проактивного мониторинга, самонастройки; материализованные представления и многомерные встроенные кубы; быстрая пакетная загрузка; оптимизация кода для разных платформ. Сегодня наблюдается революция в области производительности СУБД, проходящая через три этапа: несколько лет назад появились специализированные аппаратно-программные комплексы, на порядок ускоряющие выполнение приложений СУБД без их переписывания; сегодня активно разворачивается технология работы в памяти, на порядок ускоряющая выполнение аналитических запросов [2]; ожидается появление команд СУБД, «зашитых» в ядро процессора, что еще на порядок ускорит выполнение. Некоммерческие СУБД еще и не подошли к первому этапу, в них нет оптимизации программного кода и ускорения тех или иных программных компонентов. Выпускать машины баз данных, реализовывать команды СУБД на чипе сегодня умеют только Oracle и IBM, производящие и СУБД, и процессоры, и серверы.

Надежность. В большинстве некоммерческих систем не реализованы: защита от выхода из строя компьютера, автоматический повтор прерванных транзакций; защита от выхода из строя дисков, балансировка нагрузки ввода-вывода; обновление приложений без остановки их работы; изменение параметров и администрирование без остановки работы; управление множеством баз как одной; оперативное восстановление файлов, блоков, объектов; регулярная автоматическая проверка целостности основной базы и резервных баз; удаление резервных узлов на большое расстояние для катастрофоустойчивости и т. д.

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

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

Совокупная стоимость владения. Один из аргументов в пользу ПО с открытым кодом — отсутствие платы за лицензию, однако корректнее говорить не о стоимости ПО, а о стоимости владения. Часто забывают, что на лицензию приходится лишь 10–20% стоимости создаваемой ИТ-системы, основная же часть расходов связана с разработкой, тестированием и сопровождением. Работа со свободным ПО предполагает высокую квалификацию сотрудников, а за техническую поддержку обычно все равно надо платить. В результате использование открытого ПО в сложных корпоративных проектах может привести к высоким дополнительным затратам, превышающим стоимость лицензий.

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

Документация. Документации для некоммерческих СУБД очень мало, а локализованной практически нет.

Что делать?

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

  • Создание отечественных нишевых СУБД и компаний по их поддержке, развитию и продвижению. В этой связи представляются правильными шаги по созданию отечественной компании PostgreSQL Professional, однако желательно иметь не одну, а хотя бы две такие СУБД. Следует учесть, что производитель должен создать мощную профессиональную систему технической поддержки, русскоязычную документацию, организовать систему подготовки специалистов, зафиксировать и сопровождать версию своей СУБД и, главное, оперативно развернуть работы по добавлению в нее важных, но пока отсутствующих механизмов обеспечения безопасности, надежности, управляемости и т. д. Практически это означает, что требуется создать отечественную школу «СУБДстроения» — это большая, амбициозная, дорогая задача, но решать ее надо. В случае усиления политических рисков на такие СУБД можно будет перейти, хотя и с ущербом для функционала приложений.
  • Создание и использование технологий разработки приложений, независимых от СУБД. Такие прикладные системы, как «1С» или SAP R3, сертифицированы для работы с различными СУБД; замена СУБД в них происходит с потерей характеристик надежности и производительности, но достаточно быстро и безболезненно. Современные многозвенные архитектуры приложений позволяют реализовать независимость, и особенно полезен такой подход для госструктур, обычно использующих приложения, не работающие под большой нагрузкой.
  • Разработка и отладка технологий и инструментов для миграции приложений с коммерческих СУБД на собственную СУБД. Миграция данных в реляционных СУБД осуществляется достаточно просто, однако хороших средств для миграции программных компонентов почти нет. Например, имеется инструментарий Postgres Plus Advanced Server компании EnterpriseDB, однако это западный коммерческий продукт, и качество миграции он обеспечивает посредственное. Отечественные компании-разработчики могли бы создать более качественный продукт, генерирующий эффективный код, и развивать его по мере развития поддерживаемых СУБД.

***

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

Литература

  1. Марк Ривкин. Коммерческие СУБД: эволюция или революция? // Открытые системы.СУБД — 2009. — № 2. — С. 30–34. URL: http://www.osp.ru/os/2009/02/7322713 (дата обращения 20.3.2015).
  2. Марк Ривкин, Игорь Мельников. СУБД для облаков // Открытые системы.СУБД. — 2013. — № 6. — С. 30–33. URL: http://www.osp.ru/os/2013/06/13036850 (дата обращения 20.3.2015).

Александр Лашманов (alexander.lashmanov@fors.ru) — генеральный директор, компания «Ай-ФОРС» (Москва).