технологии. проекты. события

оперативно. предметно. ответственно
Статьи
Статьи Опубликовано

Выбор подходящего решения в условиях развивающегося рынка баз данных

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

В 2011 году организация 451 Research начала публиковать ставшую популярной схему развития экосистемы баз данных. Эти схемы, графическая часть которых во многом взята со схем лондонского метро, выглядели как карта какого-то безумного парка развлечений.

Схема за этот год стала еще сложнее и теперь включает 386 продуктов.

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

Означает ли это, что вам следует использовать две или три платформы данных? Поэтому ли к вам обращается столько поставщиков? Сколько же баз данных вам в действительности нужно?

 

Выживание наиболее приспособленных

Резкий рост числа поставщиков в любой отрасли позволяет сделать интересные наблюдения. В быстро меняющейся отрасли, такой как платформы данных, любая разработка для решения некоторой проблемы часто устаревает уже к моменту ее выпуска.

С 2010 года в радиусе трех километров от главного офиса нашей компании в городе Кембридж (штат Массачусетс) появилось 15 новых компаний, занимающихся базами данных. И сложно сказать, сколько их еще появится в последующие три года. Немногие из них станут преуспевающими, остальные же просто исчезнут. Постепенно такая схема будет сжиматься — это неизбежное последствие консолидации. Мы неоднократно наблюдали, как технологические компании сменяют друг друга на множестве других рынков, и категория платформ данных здесь не станет исключением.

Что если у вас имеется проект, который будет длиться несколько десятилетий? Вам потребуется платформа, способная выдержать испытание временем. Что вы решите в этом случае?

Вильям Омалейн (William O’Mullane), директор-распорядитель по научным вопросам в миссии Gaia Европейского космического агентства, недавно говорил о потребности в платформе данных для составления карты из миллиарда звезд Млечного Пути. Чтобы  решить эту непростую задачу, специалисту пришлось выбирать из нескольких вариантов баз данных.

«Мой проект продлится от 20 до 30 лет», — заявил он. ЕКА начало с реляционной базы данных, но затем переключилось на многомодельную базу данных, которая поддерживала SQL и имела улучшенную и более производительную модель, требующую меньше аппаратных ресурсов. Она также поддерживала многомерные запросы. Это была не самая новая база данных на рынке, однако она оказалась достаточно отлаженной, надежной и масштабируемой, а также обеспечивала сниженную совокупную стоимость владения.

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

Как вы поступите, если ваш архитектор, разработчик и аналитик говорят, что нужно использовать базу данных X или Y? На каких критериях будет основываться ваше решение? Ключевой вопрос здесь заключается в том, сможет ли технология, которая сейчас является «хитом сезона», просуществовать дольше нескольких лет.

Многие из новых баз данных выглядят как специализированные решения, в частности ориентированные на услуги. Однако если взглянуть на системы в состоявшихся организациях, которые были введены в эксплуатацию 20–30 лет назад, и проанализировать инвестиции в эти системы, становится ясно, что SQL никуда не денется в ближайшее время. После ожесточенной борьбы на рынке останется один-два игрока.

 

Горизонтальное масштабирование, вертикальное масштабирование или все вместе?

После того как поставщики микросхем столкнулись с ограничениями используемых технологий, на рынке стал наблюдаться значительный сдвиг. Потребность в производительности заставляла их умещать все больше и больше ядер в один процессор: в результате сейчас появились уже 128-ядерные системы. Это разительно отличается от распространенного ранее мнения, что 64-ядерные системы нужны исключительно для физических расчетов, но никак не для бизнеса. Сейчас же они становятся обыденностью.

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

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

 

Ситуация с облаком

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

 Сколько будет стоить развертывание в облаке? Кроме того, клиентов заботят аспекты безопасности и ответственности. Однако почти каждое предприятие, с которым мне доводилось работать, использовало облачные технологии хотя бы для одного критически важного приложения. Склонность к риску возрастает по мере того, как соотношение уровня риска и возможных преимуществ становится все более привлекательным

 

Ситуация с DBaaS

При общении с клиентами мы рассматриваем базу данных как независимый архитектурный компонент. Начиная с небольшого количества маленьких, но очень громкоголосых исследователей, и продолжая всеми основными провайдерами услуг, все начинают говорить о тех возможностях, которые даёт подход «База Данных как Услуга» [Database as a service — DBaaS].

Amazon, Google и Oracle предлагают отличные решения. Вы можете получить полный набор возможностей — от аварийного восстановления до исключительно аналитических функций. Следует отметить, что организация 451 Research обнаружила очень медленное изменение в области развертываний баз данных отдельно от развертывания приложений в облаке.

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

Как отметил мой  европейский коллега: «Нельзя поместить данные на американский сервер». Эта проблема вызвана законами местной юрисдикции и связана с разными подходами к выбору платформ данных во многих странах.

 

Что такое следующее поколение?

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

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

Так сколько же баз данных вам в действительности нужно? При ответе на этот вопрос следует задуматься о том, какой платформе данных вы хотите доверить будущее своих самых важных приложений.

Джулия Локнер (Julie Lockner) возглавляет глобальные программы по платформам данных и партнерскому маркетингу для InterSystems. Она обладает более чем 20-летним опытом в сфере управления маркетингом ИТ-продуктов и выработки технологической стратегии и была сотрудником таких компаний, как Informatica и EMC. Вы можете подписаться на ее канал в Twitter — @JulieLockner

Метки