The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск реляционно-графовой СУБД EdgeDB 5.0

22.04.2024 10:36

Доступен релиз СУБД EdgeDB 5.0, реализующей реляционно-графовую модель данных и язык запросов EdgeQL, оптимизированные для работы со сложными иерархическими данными. Проект развивается в форме надстройки над PostgreSQL, код которой написан на языках Python и Rust (парсер и критичные к производительности части), и распространяется под лицензией Apache 2.0. Клиентские библиотеки подготовлены для языков Python, Go, Rust. .NET, Elixir и TypeScript/Javascript. Предоставляется инструментарий командной строки для управления СУБД и интерактивного выполнения запросов (REPL).

Вместо модели данных на основе таблиц в EdgeDB применяется декларативная система на основе объектных типов. Вместо внешних ключей (foreign key) для определения связи между типами применяется связывание ссылками (один объект может использоваться как свойство другого объекта).


   type Person {
     required name: str;
   }
   type Movie {
     required title: str;
     multi actors: Person;
   }

Поддерживаются такие возможности как строгая типизация свойств, ограничения значений свойств, вычисляемые свойства и хранимые процедуры. Из особенностей объектной схемы хранения EdgeDB, которая чем-то напоминает ORM, отмечается возможность смешивания схем, связывания свойств из разных объектов и интегрированная поддержка JSON. Для ускорения обработки запросов могут применяться индексы.

Предоставляются встроенные инструменты для миграции схемы хранения - после изменения схемы, задаваемой в отдельном esdl-файле, достаточно выполнить команду "edgedb migration create" и СУБД проанализирует различия в схеме и в интерактивном режиме сгенерирует скрипт для перехода на новую схему. Автоматически отслеживается история изменения схемы.

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


   select Movie {
     title,
     actors: {
       name
     }
   }
   filter .title = "The Matrix"

   insert Movie {
     title := "The Matrix Resurrections",
     actors := (
       select Person
       filter .name in {
         'Keanu Reeves',
         'Carrie-Anne Moss',
         'Laurence Fishburne'
       }
     )
   }

В новой версии:

  • Добавлена поддержка ветвления ("branching"), позволяющая использовать при работе с данными и схемами концепцию веток, применяемую в системах управления версиями. Вместо термина "база данных" в новом выпуске предложено понятие "ветка" (branch), а команды "create database" и "drop database" объявлены устаревшими и вместо них рекомендовано использовать новые команды "create empty branch" и "drop branch". Помимо пустых веток при помощи команд "create schema branch" и "create data branch" можно создавать ответвления от существующих веток и БД, копируя из них схему хранения и данные.

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

  • В расширение pgvector, применяемое для эффективного хранения и запроса векторов, добавлен новый тип индексов HNSW (Hierarchical Navigable Small Worlds), который, по аналогии с индексом IVFFlat, доступен в трёх вариантах: ext::pgvector::hnsw_euclidean, ext::pgvector::hnsw_ip и ext::pgvector::hnsw_cosine. Кроме того, в pgvector расширены возможности по тонкой настройке индексов через объект ext::pgvector::Config.
  • Добавлены дополнительные возможности аутентификации. В расширении auth реализована поддержка беспарольных схем аутентификации WebAuthn (Passkeys) и "magic links" (на базе email). Добавлена поддержка использования платформ Slack и Discord в качестве OAuth-провайдеров.
  • Внесены оптимизации производительности. В реализации кэша с результатами компиляции запросов обеспечено сохранение состояния между перезапусками и добавлена автоматическая перекомпиляция после миграции. Повышена скорость работы с большими схемами хранения.
  • В языке запросов EdgeQL​ в выражении "for" разрешено не указывать ключевое слово "union" в базовых запросах, в которых используются выражения insert, update или delete.
  • Добавлена команда vacuum() для чистки, оптимизации и упаковки содержимого БД.
  • Разрешено преобразование данных между типом bytes и типами int16, int32, int64 и uuid, используя функции to_bytes(), to_uuid() и to_int*().
  • Добавлена возможность закрытия всех соединений к БД после выполнения операции "drop database".


  1. Главная ссылка к новости (https://github.com/edgedb/edge...)
  2. OpenNews: Релиз СУБД Neo4j 1.3, ориентированной на хранение графов
  3. OpenNews: Выпуск СУБД OrientDB 2.2
  4. OpenNews: На конференции Google I/O представлена открытая графо-ориентированная СУБД Cayley
  5. OpenNews: Выпуск графо-ориентированной СУБД Nebula Graph 3.2
  6. OpenNews: Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61041-edgedb
Ключевые слова: edgedb, graph, database, postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (20) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.8, Аноним (8), 13:03, 22/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
     
     
  • 2.9, Rock (?), 13:19, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?

    Двухуровневая архитектура? Типа, если хватает, то зачем платить за разработку трехуровневой.

     
  • 2.10, Аноним (10), 13:53, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Где ты здесь увидел сервер приложений?
     
     
  • 3.11, Аноним (11), 14:30, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
    В частности, практически все современные СУБД являются таковыми.
     
     
  • 4.16, Аноним (10), 17:41, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ерунду пишешь. На счёт начального вопроса выше, ответ же очевиден - часть логики выносится ближе к данным для ускорения работы. Т.к. реляционная СУБД сама по себе не является графовой и всё это добро реализуется поверх таблиц, то одна логическая операция с графовой СУБД может порождать несколько запросов к реляционной с большим потоком данных. Реализация этой функциональности далеко от данных грузит и сеть ненужным трафиком, и вносит дополнительные существенные задержки на запрос.
     
  • 4.20, Аноним (20), 19:15, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.

    В частности, практически все современные СУБД являются таковыми.

    Наличие триггеров не является сервером приложений.

     
  • 2.12, Аноним (12), 16:44, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это очень удобно. Зачем нужно городить целый сервер приложений ради пары десятков функциий для операций над данными? Пусть живут сразу рядом с данными и в контексте данных выполняются. Тупа БД, которой для лбьоц примитивщины нужен сервер приложений не нужна. Можешь спросить хоть Майкрософт, хоть Оракл, хоть АйБиЭм, они на этом не одну собаку съели.
     
     
  • 3.15, MaleDog (?), 17:14, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Затем, что производительность реляционных СУБД не заточена на все это. В результате получится нечто в 10 раз более тормозное и жрущее ресурсы как не в себя, не говоря уже о безопасности. Пример, была у меня приложуха которая хранила json в postgres и средствами же postgres с ним работала. Спохватился я когда простой insert временами стал превышать три минуты на 8-гиговой базе. Тогда я добавил кэш на nosql, который собирал данные за минуту и вставлял пачкой, такая актуальность была достаточной. Результат:
    1. Нагрузка на процессор снизилась с 200% до 5-10%
    2. Память с четырех гигов до гига.
    3. Ожидание ответа клиентами с трех минут до 1 секунды.
    4. Настройки postgres не менялись - он изначально был оптимизирован.

    И это все речь об очень небольшом сервере приложений.

     
     
  • 4.19, Аноним (12), 18:26, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе.

    А как ты там JSON в PG хранил я не знаю. Может ты его на VARCHAR(255) резал, а может у тебя там FTS индексы по нему строятся, но в любом случае твоя байка про три минуты на восьмигиговой базе либо просто ложь, либо конкретная лажа в программировании, потому что за три минуты можно с HDD 8 гиг считать в память, раскурочить там любой JSON, записать обратно на диск, и ещё время на чай с булочкой останется.

     
     
  • 5.23, MaleDog (?), 20:01, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Всего три поля. два big int и jsonb. Условие только одно уникальность первых двух(upsert). Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике. Поиск так же только по первым двум.  В среднем раз в две недели сервер прибивал omm killer. И на сервере не было 8 гигов памяти. Да они оказались и не нужны. если те же 2000 записей вставлять не по мере прихода по одной, а пачкой все сразу.
     
     
  • 6.25, Tron is Whistling (?), 21:44, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике

    Это вообще ни о чём.

     
  • 6.26, Tron is Whistling (?), 21:45, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там случайно проблема не в latency между клиентом и сервером БД крылась? Каждая вставка - это в лучшем случае один раундтрип (хз как там у постгрыза в протоколе).
     
     
  • 7.30, MaleDog (?), 22:55, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения. Подтверждение поступит только после того, как последняя запись будет вставлена в таблицу. Если он ждет дольше пяти секунд то сам отвалится, поскольку не для IOT ждать минутами - у него батарейка. Если он выгрузил пачку, то будет вставлена пачка. Если всего одну записть между сеансами наработал, то одна запись. Естественно после подъема сервера все хотят выгрузить, то что накопилось. А еще есть боты, которые норовят пощупать все что можно. В общем может и можно средствами postgres и дополнениями реализовать кэш, firewall, фильтрацию невалидных данных, и проблему 10k, но КМК с этим лучше справится отдельное приложение. А тут, "да здравствует трехзвенка". При этом я не чураюсь возможностями postgres. Например для графаны(запросы которой не оптимальны) есть процедуры выбирающие данные по двум первым столбцам и формирующие временные view на основе json. Временные, поскольку постоянные оказались слишком медленными.
     
  • 7.31, MaleDog (?), 23:06, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И да я в курсе, что есть более более подходящие базы и дополнения. Но у influxdb есть на мой взгляд недостатки: если у тебя было "поле" с типом bool, а потом тебе понадобилось преобразовать его в int, то фиг у тебя получится без копирования всей таблицы. TimescaleDB для моих объемов и скромных ресурсов это перебор. Зачем тратить деньги на покупку нового более мощного vps если можно решить проблему вынеся часть логики в "прослойку".
     
  • 6.33, Аноним (33), 08:38, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поддерживаю. JSON, XML - не место в реляционной БД. Примерно такой же случай у меня был с Oracle DB c XML. Средствами PL/SQL пакетов Oracle (который были обертками то ли Java то ли С++ кода) я собирал XML код - обвязку для реляционных данных таблиц, который потом выгружал в виде файла на диск. Так вот когда я сам просто с использованием пакета dbms_file брал в курсоре данные из запроса и прибаылял к ним XML-тэги, типа <cust_name> || a_table.cust)name || </cust_name> и выгружал на диск, то это было раз в 10 быстрее. И это простые функции. А если XML и JSON хранить в таблицах в виде данных или в бинаром виде, то здесь засада будет еще толше.

    Вывод - каждым данным свой инструмент. Реляционные БД должны работать с Реляционной моделью (то бишь нормализованными Таблицами) и применяться в основном для OLTP приложений.

     
  • 5.24, MaleDog (?), 20:07, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И да. Быть медленне HDD можно, если уйти в своп.

     
     
  • 6.27, Tron is Whistling (?), 21:46, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если сервер СУБД ушёл в своп - это почти что профнепригодность :)
     
  • 5.29, Аноним (29), 22:04, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    СУБДд предназначена для выполнения запросов, внезапно, на сервере! Если ты загружал все таблицы для обработки в крестах, то это профнепригодность. Хорошо хоть кто-то тебе по рукам дал.
     
  • 5.32, YetAnotherOnanym (ok), 21:04, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > «все это» — это что именно?

    М.б., в контексте данной новости, это работа с данными, составлящими граф?

     
  • 3.28, Аноним (29), 22:00, 22/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Кто мешает написать хранимку, чтобы выполнялась прямо в бд? Нет, надо нагородить челую надстройку, со своми багами, под предлогом, что это быстрее. Это НЕ быстрее.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру