Долой старый чудак SQL. По-новому использовать базу данных.

Большой новостью несколько недель назад стало то, что SurrealDB достигла относительно стабильной версии 1.0 и общедоступной бета-версии. На момент написания это все еще находится в стадии бета-тестирования, и некоторые функции и документация отсутствуют, но, учитывая то, что обещали (и сделали) ребята из SurrealDB, похоже, что эпоха традиционных баз данных SQL подходит к концу.

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

В то время как все поддерживает SQL, тонкая настройка и управление также являются кошмаром. Невозможно или сложнее, чем кажется, подключиться к базе данных с помощью Javascript, не говоря уже о том, чтобы открыть ее для дикого Интернета. Вот что SurrealDB хочет изменить.

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

Беглый взгляд на документацию все объясняет: SurrealDB — это база данных, ориентированная на NoSQL, написанная на Rust, но она может стать строгой базой данных и даже жить только в системной памяти.

Разница между другими решениями? Больше никаких проприетарных протоколов или системных драйверов, HTTP и WebSockets — это все, что вам нужно.

Отодвиньте SQL!

SurrealDB производит впечатление мастера на все руки. Хотя основное внимание уделяется базе данных без схемы по умолчанию, ее язык напоминает классический SQL с добавлением собственного синтаксиса. По сравнению с традиционным стандартом, кажется более современным и прямым, и менее громоздким для изучения.

Еще одна интересная вещь по сравнению со старыми базами данных SQL заключается в том, что она может сделать таблицы без схемы до полной схемы. Есть поддержка индексов, уникальных индексов и обещания внедрить полнотекстовое индексирование в будущем — даже тогда я все еще думаю, что Mailisearch здесь победитель. Если это не ваша чашка чая, SurrealDB по-прежнему может работать как хранилище ключей и значений, подобно memcached или Redis, располагаясь в памяти и ограничиваясь тем, что предоставляет хост.

$> surreal start memory

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

  • Авторизация может быть привязана к записям в базе данных и может быть ограничена таблицами, строками и полями, а также действиями (такими как обновления или удаления).
  • Он предоставляет конечную точку HTTP REST и WebSockets (в настоящее время не документировано, но тем не менее я могу сделать вывод, как это работает).
  • Объедините это с внешним приложением, и браузер сможет напрямую запрашивать базу данных без риска.
  • Вы можете определить «события» в таблицах, которые могут видеть значение до и после изменения строки, когда оно вызывается условием.
  • Во время запроса доступно множество функций, от простого время и валидация до геолокации и HTTP-запросов для простых вебхуков. Вы даже можете встроить функции Javascript внутрь любого оператора.
  • Позвольте мне повторить: Вы даже можете встроить функции Javascript в любой оператор.

Одна вещь, которой не хватает, но над которой работает версия SurrealDB для Rust, — это подписка на живые запросы. Они работают как обычные публикации/подписки, но вы получаете все записи, соответствующие запросу.

В качестве альтернативы обещают реализовать Подписки на GraphQL.

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

Тем не менее, помимо SurrealDB есть еще четыре проблемы, которые омрачают его будущее широкого внедрения.

1. Это не проверено в бою

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

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

Кроме того, изменить базу данных с традиционного SQL на SurrealDB за одну ночь невозможно, что открывает следующий пункт.

2. Нет пути миграции

К настоящему времени все основные проекты выполняются на базе традиционной базы данных SQL или тесно связаны с другими механизмами баз данных, такими как MongoDB. Не существует четкого конвейера «миграции» для перемещения данных из любой из этих систем баз данных в SurrealDB.

Для большинства проектов изменение необработанных запросов непозволительно, и если база данных SQL работает, то трудно добиться изменения чего-то относительно нового в пространстве данных.

3. Нет показателей производительности

Вы можете сказать, что SurrealDB кажется пощечиной другим SQL-движкам, но, несмотря на синтаксис и удобство, речь не идет о производительности.

Поскольку сравнений производительности нет, довольно сложно принимать решения по серьезным проектам, если нет гарантий, что он не будет работать лучше или хуже. Что делать, если отношения запроса работают медленнее? Что, если индексы не повышают производительность? Что делать, если RPC медленнее, чем REST? Как он обрабатывает транзакции? И так далее…

Также есть большой вопрос тюнинга. Например, известно, что РСУБД может изменять механизмы для сценариев с большим количеством операций записи, таких как доска объявлений, или сценариев с большим количеством операций чтения, таких как рынок.

4. Инструментов пока нет

Большинство разработчиков не хотят напрямую взаимодействовать с базой данных и тратить часы на управление данными, и поэтому в первую очередь существуют ORM: Doctrine, Eloquent, Sequelize, Diesel, GORM, среди того, что я могу вспомнить.

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

SurrealDB интересен, но все еще впереди

SurrealDB далеко не настоящее, но может быть будущим для проектов, которые хотят начать прямо сейчас с гибкой базы данных. Чтобы это стало «следующей вещью», должны произойти три вещи:

  • Инструменты для распространенных фреймворков
  • Пути миграции из старых баз данных SQL
  • Такая же или более высокая производительность, чем у стандартных механизмов SQL.

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

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