В этой статье мы поговорим о трех свежих технологиях в сфере баз данных, которые нас заинтересовали:
Во второй статье расскажем еще про три:
А третья статья будет посвящена выводам.
Примечание: речь пойдёт исключительно о базовых технологиях, а такие функции, как корпоративные фичи, будут по большей части игнорироваться (там, где это уместно).
TileDB представляет собой базу данных, построенную вокруг многомерных массивов. Она позволяет упростить работу с типами данных, которые не вполне вписываются в существующие системы управления реляционными базами данных (RDBMS), например, плотные и разреженные массивы, кадры данных. TileDB специально заточена под такие сценарии использования, как геномика и геопространственные данные.
Нам нравятся такие «узкоспециализированные» БД, заточенные под конкретный набор типов данных и задач. Традиционные RDBMS, конечно, хороши своей относительной универсальностью, позволяющей охватить чрезвычайно широкий спектр сценариев использования (без шуток). Но иногда возникают крайние случаи, когда на самом последнем этапе (а) возможностей «обычных» систем не хватает, и (б) задача очень важна для вашего бизнеса.
Мы ожидаем появления других подобных систем по мере роста специализации сценариев использования баз данных и возникновения новых предметных областей. Старые добрые RDBMS, конечно, никуда не денутся, но при этом хотелось бы увидеть, как TileDB и другие подобные системы развиваются и расширяют границы возможного. Надеемся, что появятся очень «хакабельные», не монолитные БД, у которых будет интерфейс для подключения плагинов, чтобы можно было работать с очень специфичными для конкретных сценариев использования типами данных. Но об этом позже.
Materialize позиционируется как «первая настоящая поточная база данных SQL», и, возможно, это действительно не преувеличение! По сути, это реляционная база данных, обладающая «проводной совместимостью» с PostgreSQL, но с одним важным отличием: она предлагает материализованные представления, обновляемые в режиме реального времени.
Встречается такое определение Materialize, как «хранилище поточных данных», что, похоже, для нее подходит.
В стандартном Postgres, например, приходится обновлять материализованные представления вручную:
Это можно делать с какой угодно периодичностью, например, с помощью скрипта или задачи планировщика. Чего мы пока не увидели (хотя всегда очень хотели увидеть), так это базы данных, изначально поддерживающей инкрементные обновления материализованных представлений. Да, действительно: Materialize следит за изменениями в задаваемых источниках данных и обновляет представления в зависимости от изменений в этих источниках.
Даже если Materialize не «победит» или не останется на рынке достаточно долго, возможности, которые она предлагает, должны сохраниться и будут почти наверняка воспроизведены в других БД.
Materialize потенциально может много что заменить. Самое очевидное: система позволяет задействовать весь имеющийся у вас арсенал процессов для поступательного обновления ваших материализованных представлений. Но это не такой уж большой выигрыш.
Гораздо важнее для нас то, что Materialize позволяет делать неактивными те части стека данных, которые выделены под отслеживание изменений в источниках данных. Это можно делать нативно:
Теперь ваша БД «знает» об источнике данных, который она может использовать для построения автоматически обновляемых материализованных представлений. Такая родная «конвейеризация» кажется мне даже более волшебной, чем автоматическое обновление представлений. Если вы запустите, например, безсерверные функции, либо задания Heron, либо конвейеры данных Flink, которые занимаются только отслеживанием, и добавите туда оператор
Prisma представляет собой скорее не базу данных, а набор инструментов для максимального абстрагирования вашей базы данных. В настоящее время система совместима с PostgreSQL, MySQL и SQLite на стороне БД, и с JavaScript и TypeScript с точки зрения языка (с перспективой поддержки других БД и языков в будущем). Она заявлена как «уровень данных для современных приложений», что в целом верно.
«Золотой способ» использования Prisma примерно следующий:
Мы понимаем сомнения некоторых людей в отношении таких инструментов, как Prisma. Среди разработчиков существует большая группа противников абстрагирования базы данных. Им не нужны умные DSL и GUI. Они хотят писать простые SQL и создавать весь код взаимодействия с БД вручную. Нам вполне понятно желание сохранить такую степень контроля, но всё же советуем потратить 20–30 минут на то, чтобы попробовать Prisma. Нам кажется, она очень неплохо справляется с задачей поиска «золотой середины» между «явным перебором» и сырым SQL.
DSL схемы Prisma позволяет не только задавать типы данных, необходимые для вашего приложения, но и определять, какой генератор кода вы хотите использовать, а также информацию о подключении для БД, к которой вы подключаетесь.
Дополнительно обеспечиваются перечисляемые типы (enums), удобные аннотации, например,
Очень бы хотелось увидеть адаптацию SDL схем Prisma или чего-то подобного в качестве языконезависимого стандарта (подходящего для библиотек, специфичных для определенного языка). Статус-кво предполагает, что каждый язык программирования заново изобретает колесо. Нам кажется, полезно было бы иметь языконезависимый способ задания тех типов, которые определяют взаимодействие между приложением и БД.
Кстати, отдельная благодарность Prisma за прекрасную документацию. Мы однозначно считаем это важным отличием, и если ваша документация не попадает в раздел типа «Что мне особенно понравилось» какого-нибудь поста в блоге, значит, вам следует вкладывать больше ресурсов в создание технических описаний.
Будет ли Prisma также полезна в языках, уже имеющих широко используемые объектно-реляционные отображения (ORM)? Если пользоваться ActiveRecord для Ruby или Ecto для Elixir, каков стимул для перехода?
Во второй статье расскажем еще про три:
А третья статья будет посвящена выводам.
Примечание: речь пойдёт исключительно о базовых технологиях, а такие функции, как корпоративные фичи, будут по большей части игнорироваться (там, где это уместно).
TileD B
TileDB представляет собой базу данных, построенную вокруг многомерных массивов. Она позволяет упростить работу с типами данных, которые не вполне вписываются в существующие системы управления реляционными базами данных (RDBMS), например, плотные и разреженные массивы, кадры данных. TileDB специально заточена под такие сценарии использования, как геномика и геопространственные данные.
Примечательные особенности
- Переключаемые бэкенды данных с поддержкой Amazon S3, MinIO и др.
- Интеграции хранилищ для HDFS, PrestoDB, Apache Spark, Dask и др.
- Привязка языка для C/C++, Python, R, Java и Go.
Что особенно понравилось
Нам нравятся такие «узкоспециализированные» БД, заточенные под конкретный набор типов данных и задач. Традиционные RDBMS, конечно, хороши своей относительной универсальностью, позволяющей охватить чрезвычайно широкий спектр сценариев использования (без шуток). Но иногда возникают крайние случаи, когда на самом последнем этапе (а) возможностей «обычных» систем не хватает, и (б) задача очень важна для вашего бизнеса.
Мы ожидаем появления других подобных систем по мере роста специализации сценариев использования баз данных и возникновения новых предметных областей. Старые добрые RDBMS, конечно, никуда не денутся, но при этом хотелось бы увидеть, как TileDB и другие подобные системы развиваются и расширяют границы возможного. Надеемся, что появятся очень «хакабельные», не монолитные БД, у которых будет интерфейс для подключения плагинов, чтобы можно было работать с очень специфичными для конкретных сценариев использования типами данных. Но об этом позже.
Вопросы к проекту
- Каково соотношение между количеством работы на стороне клиентских библиотек и на стороне базы данных? Являются ли клиенты TileDB по существу математическими библиотеками под конкретный язык для локального манипулирования сложными типами данных и периодического сохранения результатов нужный бэкэнд, или же они, как другие клиентские библиотеки БД, по большей части просто передают команды в базу данных? Из документации это не вполне ясно.
- Каков практический смысл в обеспечении хранилища ключ-значение при избытке имеющихся видов таких хранилищ? В документации даже говорится, что «TileDB не рассчитана на работу в качестве специализированного хранилища ключ-значение». В чем тогда выгода от развития подобной функции?
Materialize
Materialize позиционируется как «первая настоящая поточная база данных SQL», и, возможно, это действительно не преувеличение! По сути, это реляционная база данных, обладающая «проводной совместимостью» с PostgreSQL, но с одним важным отличием: она предлагает материализованные представления, обновляемые в режиме реального времени.
Встречается такое определение Materialize, как «хранилище поточных данных», что, похоже, для нее подходит.
В стандартном Postgres, например, приходится обновлять материализованные представления вручную:
CREATE MATERIALIZED VIEW my_view (/* ... */);
REFRESH MATERIALIZED VIEW my_view;
/* The underlying tables change */
REFRESH MATERIALIZED VIEW my_view;
/* More stuff happens */
REFRESH MATERIALIZED VIEW my_view;
Это можно делать с какой угодно периодичностью, например, с помощью скрипта или задачи планировщика. Чего мы пока не увидели (хотя всегда очень хотели увидеть), так это базы данных, изначально поддерживающей инкрементные обновления материализованных представлений. Да, действительно: Materialize следит за изменениями в задаваемых источниках данных и обновляет представления в зависимости от изменений в этих источниках.
Даже если Materialize не «победит» или не останется на рынке достаточно долго, возможности, которые она предлагает, должны сохраниться и будут почти наверняка воспроизведены в других БД.
Примечательные особенности
- Разнообразный спектр источников данных, включая другие таблицы (как в стандартной Postgres), JSON, CSV и другие файлы, темы Kafka и Kinesis, к которым в будущем вполне могут добавиться и другие.
- Ядро построено на двух действительно мощных конструктах: «оперативный» поток данных (timely dataflow) и «дифференциальный» поток данных (differential dataflow). Не будем сейчас углубляться в подробности по поводу каждого из них, но настоятельно рекомендуем тщательно изучить эти концепции самостоятельно. В разработке обоих проектов активно участвовали сами создатели Materialize, придерживающиеся научного подхода, так что вы можете быть уверены, что Materialize — это не продукт «в хакерском духе», а результат очень тщательного, скрупулезного процесса разработки.
- Поскольку Materialize имеет «проводную» совместимость с Postgres, сохраняется возможность использования psql и всех остальных привычных инструментов Postgres.
Что особенно понравилось
Materialize потенциально может много что заменить. Самое очевидное: система позволяет задействовать весь имеющийся у вас арсенал процессов для поступательного обновления ваших материализованных представлений. Но это не такой уж большой выигрыш.
Гораздо важнее для нас то, что Materialize позволяет делать неактивными те части стека данных, которые выделены под отслеживание изменений в источниках данных. Это можно делать нативно:
CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';
Теперь ваша БД «знает» об источнике данных, который она может использовать для построения автоматически обновляемых материализованных представлений. Такая родная «конвейеризация» кажется мне даже более волшебной, чем автоматическое обновление представлений. Если вы запустите, например, безсерверные функции, либо задания Heron, либо конвейеры данных Flink, которые занимаются только отслеживанием, и добавите туда оператор
INSERT, то Materialize позволит вам просто вырезать эту часть стека. Вопросы к проекту
- Почему отдельная БД, а не расширение Postgres? Уверены, что существуют веские причины архитектурного плана, по которым расширение не будет здесь так работать, но хотелось бы узнать, почему именно.
- Насколько просто построить расширения для других источников данных? Как можно написать, например, расширение для Apache Pulsar? Планируется ли открыть разработчикам API для этой цели?
Prisma
Prisma представляет собой скорее не базу данных, а набор инструментов для максимального абстрагирования вашей базы данных. В настоящее время система совместима с PostgreSQL, MySQL и SQLite на стороне БД, и с JavaScript и TypeScript с точки зрения языка (с перспективой поддержки других БД и языков в будущем). Она заявлена как «уровень данных для современных приложений», что в целом верно.
«Золотой способ» использования Prisma примерно следующий:
- Определите ваши типы данных на уровне приложений с помощью SDL схемы Prisma.
- На основе созданной схемы сформируйте высокоидиоматический код для выбранного вами языка.
- Займитесь созданием API REST, API GraphQL и всего остального, что вы хотите создать.
Мы понимаем сомнения некоторых людей в отношении таких инструментов, как Prisma. Среди разработчиков существует большая группа противников абстрагирования базы данных. Им не нужны умные DSL и GUI. Они хотят писать простые SQL и создавать весь код взаимодействия с БД вручную. Нам вполне понятно желание сохранить такую степень контроля, но всё же советуем потратить 20–30 минут на то, чтобы попробовать Prisma. Нам кажется, она очень неплохо справляется с задачей поиска «золотой середины» между «явным перебором» и сырым SQL.
Примечательные особенности
- Клиент Prisma позволяет задать нужные вам типы данных с помощью специализированного SDL схемы, генерирующего для вас код. Даже информация о подключении для вашей базы данных исчезает из вашего кода приложения и переходит в генерируемый код.
- Функциональность Prisma Migrate позволяет задавать миграции БД декларативно (а не императивно, как в SQL). Лишние подробности того, как БД переходит из состояния A в состояние Б, скрываются.
- Prisma Studio — визуальный редактор, главным образом обеспечивающий графический интерфейс пользователя для взаимодействия с другими инструментами Prisma.
Что особенно понравилось
DSL схемы Prisma позволяет не только задавать типы данных, необходимые для вашего приложения, но и определять, какой генератор кода вы хотите использовать, а также информацию о подключении для БД, к которой вы подключаетесь.
Дополнительно обеспечиваются перечисляемые типы (enums), удобные аннотации, например,
@id, @relation и @default. Напоминает DSL миграции БД из ActiveRecord и Ecto, а также IDL, подобные используемым в Protocol Buffers и Thrift. Очень бы хотелось увидеть адаптацию SDL схем Prisma или чего-то подобного в качестве языконезависимого стандарта (подходящего для библиотек, специфичных для определенного языка). Статус-кво предполагает, что каждый язык программирования заново изобретает колесо. Нам кажется, полезно было бы иметь языконезависимый способ задания тех типов, которые определяют взаимодействие между приложением и БД.
Кстати, отдельная благодарность Prisma за прекрасную документацию. Мы однозначно считаем это важным отличием, и если ваша документация не попадает в раздел типа «Что мне особенно понравилось» какого-нибудь поста в блоге, значит, вам следует вкладывать больше ресурсов в создание технических описаний.
Вопросы к проекту
Будет ли Prisma также полезна в языках, уже имеющих широко используемые объектно-реляционные отображения (ORM)? Если пользоваться ActiveRecord для Ruby или Ecto для Elixir, каков стимул для перехода?
