#23. Судьба NoSQL в современном стеке данных
Во всём что касается современного стека технологий по работе с данными особенна интересна судьба NoSQL продуктов вроде MongoDB, ElasticSearch, Redis, Neo4J и других.
Проблема в том что большая часть инструментов в Modern data stack ориентированы на наличие у баз данных двух характеристик:
плоских таблиц
поддержки SQL запросов
Проблема эта не нова, ещё когда только-только NoSQL продукты появлялись это было известно и было достоинство. Когда хотелось обойти ограничения SQL, можно было развернуть MongoDB, к примеру, грузить туда сразу коллекции из JSON со сложными вложенными объектами, а с данными работать встроенным языком запросов или с помощью Javascript, опять же встроенного в СУБД.
Это очень удобный подход когда продукт охватывает самостоятельно большую часть задач и нет необходимости его интегрировать или интеграция идёт в первую очередь по самым очевидным операционным, а не аналитическим сценариям.
Подход при Modern data stack отличается тем что практически все интегрировано и есть несколько ключевых инструментов взаимосвязанных если не со всем, то со многим. Это оркестратор, трансформатор и наблюдатель (обсервер) процессов работы с данными. Эта модель была описана в работе Emerging Architectures for Modern Data Infrastructure [1] которую уже больше года цитируют практически все представители сервисов обработки и сбора данных получающих венчурное финансирование.
Так вот вижу большую проблему в том что если не все то многие инструменты в этой области не работают с NoSQL базами.
Обработка данных
Самый яркий пример dbt, это сейчас чуть ли не универсальный стандарт ELT трансформации данных. Многие продукты в которых есть свои инструменты обработки данных, всё равно подключают dbt потому что пользователи активно испольуют dbt, им нравится dbt и в целом идея dbt оказалась успешной. А идея в том что спроектировать модели данных и обрабатывать данные прямо в хранилище, обрабатывать SQL запросами. Как оказывается вполне очевидным у большей части NoSQL баз данных нет поддержки SQL или эта поддержка очень сильно обрезанная сводя на нет все плюсы движка NoSQL.
В dbt поддержка NoSQL даже не в ближних планах и вполне возможно вообще реализована не будет вообще. А зачем? Когда продукт востребован и становится отраслевым стандартом, то скорее другим придётся подстраиваться под него.
Оркестрация и трубы данных
NoSQL базы такие как MongoDB и ElasticSearch поддерживаются рядом оркестраторов данных, например, Airflow, но в целом поддерживаются довольно мало. Например, Meltano, активно развивающийся продукт для задач управления потоками данных поддерживает MongoDB как источник данных, но не умеет загружать в него данные. А ElasticSearch он не поддерживает ни в какой форме. Другие инструменты такие как Prefect или Dagster вообще не поддерживают даже MongoDB.
В принципе, складывается ощущение что как адрес загрузки данных MongoDB разработчиками инструментов для работы с data pipelines по даже не рассматривается, при том что из NoSQL продуктов MongoDB самый популярный.
Каталоги данных
Продуктов каталогов данных сейчас много, многие с открытым кодом и даже есть попытки стандартизировать схемы собираемых данных в проекте Open Metadata, но эти каталоги поддерживают в первую очередь только SQL базы данных. Из известных мне движков каталогов, я знаю только Datahub от LinkedIn который поддерживает MongoDB. Все остальные работают только с SQL. Даже тот самый Open Metadata, где даже в стандарте описана модель плоской таблицы данных. Всё это при том что, в принципе, получить структуру данных в коллекциях MongoDB не так сложно, но требуется учитывать вложенные объекты, а это то чего (почти) нет в реляционных базах данных.
Сейчас видно что корпоративные каталоги данных активно развиваются в сторону отслеживания зависимостей между базами данных, моделями данных, задачах преобразования, дашбордами, трубами данных и тд., но расширение на NoSQL базы данных за пределами приоритетов разработчиков.
—
Всё вместе это делает перспективы использования NoSQL продуктов не очень то радужными. Пока ты оперирующих небольшой инфраструктурой, то нет проблем. Но как только ты создаешь хотя бы что-то чуть более сложное и формируешь свой modern data stack, то NoSQL продукты оказываются наименее подготовленным к такой задаче.
Почему так происходит?
Я вижу две основные причины:
1. Низкая популярность NoSQL продуктов [2]. Только MongoDB имеет более-менее ощутимую популярность, все остальные имеют в основном нишевое применение.
2. Мощный маркетинг облачных SQL баз данных таких как Snowflake, Redshift, Google BigQuery и тд. Маркетинг в том числе и в том что новым стартапам по работе с данными денег дают часто под готовность интеграции с облачными платформами. Быть может потому что те же самые инвесторы вложили и в них денег?
Что делать?
Из всего вышенаписанного можно сделать много выводов. Любая проблема это ещё и возможность. Возможно аналог dbt с поддержкой NoSQL запросов - это то что нужно рынку и в это надо вложиться, возможно разработка SQL коннекторов к NoSQL базам данных может быть коммерчески успешной. А может быть услуги и продукты модернизации и миграции систем на базе NoSQL в SQL базы данных будет на подъеме.
Ссылки:
[1] https://future.a16z.com/emerging-architectures-modern-data-infrastructure/
[2] https://db-engines.com/en/ranking
#databases #nosql #sql dbt #moderndatastack