С появлением виртуализации баз данных (database virtualization, DBV) на арену вышла новая методология, которая обещает избавить технологии хранения данных от привязки к поставщикам (вендорлок). Майк Ваас, основатель и генеральный директор Datometry, рассказывает на портале eWeek об особенностях этой технологии и как ИТ-руководители могут ее применять.

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

О вендорлоке в области БД ходят легенды. Ни один другой сектор не имеет такого влияния на своих пользователей. Естественно, вендорлок делает клиентов привязанными к существующей технологии. А также сдерживает конкурентов и новаторов. Генеральный директор Snowflake ранее сетовал на то, как трудно пробиться на этот рынок: «Teradata сделала чертовски трудным переход со своей платформы».

С появлением DBV — виртуализации именно БД, а не данных — на арену вышла новая методология, которая обещает избавить от привязки к поставщикам технологий хранения данных. Ниже приводятся пять вещей, которые нужно знать об этой технологии.

1. Как работает DBV

Платформа DBV находится между БД и приложениями. Она позволяет приложениям, написанным для одной БД, работать на другой БД. Все запросы и обмен данными осуществляются в режиме реального времени. Например, приложения, написанные для Teradata, могут работать непосредственно на Microsoft Azure Synapse и даже не будут «знать», что они больше не работают на Teradata.

DBV является полностью прозрачной. Замысел состоит в том, чтобы приложения не требовали корректировки или она была минимальной. Это касается не только стандартного SQL, но и проприетарных расширений. А для успешного применения на практике необходимо также поддерживать загрузчики, драйверы и утилиты.

Поскольку системы DBV осуществляют трансляцию запросов и данных, они не требуют больших ресурсов. Фактическая обработка данных всегда выполняется в самом хранилище данных и использует возможности массивно-параллельной обработки (MPP) этой системы.

2. Когда стоит использовать DBV вместо обычной миграции

При обычной миграции весь существующий SQL-код, драйверы, инструменты и утилиты заменяются их аналогами из новой системы назначения. Для компактных СХД с небольшим количеством приложений такой подход может быть предпочтительным. Пример: витрины данных с ограниченным числом пользователей. Однако в случае сложных корпоративных хранилищ данных (Enterprise Data Warehouses, EDW) DBV может значительно превзойти обычную миграцию, поскольку обеспечивает миграцию рабочих нагрузок с меньшими затратами времени, расходами и рисками.

3. Может ли DBV покрыть потребности предприятия в рабочей нагрузке

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

Однако это не должно быть препятствием для внедрения DBV. Поскольку внедрение такой платформы характеризуется низким риском, это очень эффективный способ опробования концепций (proof-of-concept, POC). Клиентам не нужно изменять свои приложения, чтобы использовать DBV. Они могут тестировать свои реальные приложения непосредственно в рамках POC.

POC, в свою очередь, позволяет быстро выявить недостающий охват. Важно понимать, что хотя 100%-ное покрытие кажется желательным, обычно достаточно 90%. Устранение оставшихся проблем часто требует лишь незначительных усилий.

4. Чем DBV отличается от виртуализации данных

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

В отличие от виртуализации данных, DBV разрушает вендорлок. Эта технология оставляет приложения «как есть». Со временем это может привести к появлению разнообразного ассортимента различных прикладных технологий. Однако это не должно вызывать особого беспокойства и вполне компенсируется внедрением новых технологий работы с данными.

5. Может ли DBV переплатформировать EDW на любую технологию

Каждые несколько лет новая технология бросает вызов главенству систем EDW. Часто новинка превосходит существующий стек по одному заметному параметру. Например, одна новая технология может быть более масштабируемой, другая — позволяет упростить обмен данными, а третья обладает большей привлекательностью для Open Source-разработчиков. Как правило, команды экспертов могут создавать специализированные решения для переноса рабочих нагрузок с EDW на большинство новых технологий. Однако чем больше разрыв в функциональности, тем больше программной инженерии требуется для работы этих систем. Например, перевод EDW на систему NoSQL может быть технически возможен, но экономически не всегда целесообразен.

Чтобы реализация DBV была успешной, источник и целевая система назначения должны быть в значительной степени похожи. Однако это не требует эквивалентной функциональности. DBV может компенсировать отсутствие наиболее продвинутых функций, таких как хранимые процедуры, макросы или даже неподдерживаемые типы данных. В настоящее время наиболее успешными в контексте DBV являются нативные облачные PaaS-решения.

Выбор правильного подхода к миграции

При выборе новой целевой системы для существующей EDW необходимо учитывать множество факторов. Один из них часто упускается из виду — это подход к миграции. DBV очень эффективна в устранении привязки к поставщикам унаследованных хранилищ данных. Учитывая при выборе целевой системы подход к миграции, ИТ-лидеры могут оптимизировать процесс для быстрого внедрения, контролируя риски и затраты.