Доступен первый стабильный релиз СУБД EdgeDB, представляющую собой надстройку над PostgreSQL с реализацией реляционно-графовой модели данных и языка запросов EdgeQL, оптимизированных для работы со сложными иерархическими данными. Код написан на языках Python и Rust и распространяется под лицензией Apache 2.0. Клиентские библиотеки подготовлены для языков Python, Go, Rust и TypeScript/Javascript. Предоставляется инструментарий командной стоки для управления СУБД и интерактивного выполнения запросов (REPL)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56682
годно. с релизом!
>годноа бенчмарки постеснялись сделать? сколько графовых поделок не тестил, никто даже близко не догоняет neo4j (на чуть более сложных примерах, чем shortestpath или match)
Лишь бы написать...
Открыл, запустил, проверил подходит или нет https://github.com/edgedb/webapp-bench
>Открыл, запустил, проверил подходит или нетКлоунский подход. В официальных бенчмарках всегда натягивают сову на глобус, а на твоих задачах потестить - надо убить неделю минимум.
А зачем ты тогда нужен? Погонщик скажет и будешь за зарплату тестить, никуда не денешься. И тикеты не забудь закрыть, висят тебе уже два дня.
Жалко времени - занесите денег тестерам, вместе с постановкой задачи. Или вам и денег жалко?!
Читать научитесь, комментаторы. Где официальные бенчмарки? А их нет => скорее всего это поделие даже в искуственных примерах не может обогнать конкурентов...Нафиг оно нужно время на него тратить?
Взять тех же arangoDB, они поднатужились и родили статейку как они якобы порвали всех конкурентов лохматых версий и монго и нео4ж. Статейка разумеется не обновляется годами, и разумеется на чуть более других тестах всё становится сильно наоборот... но хоть в чём-то арангутанги лучше или наравне с нео4ж. А тут вообще молчок... просто поделие в вакууме для фанатов постгреса?
Вы еще сравните с голым ISAM, что лежит под SQL.
За любой шаг навстречу программисту приходится платить пользователю потерей функционала, синжением производительности и уменьшением памяти, доступной для выделения из кучи, что опять же приводит к снижению призводительности, но уже на порядок. Хотя, если в составе есть приложение, позволяющее графически строить схему данных без писанины кода, типа, как в кларионе, для эскизного проектирования, в принципе, годно.
а где я могу сделать
select Movie {
title,
actors: {
name
}
}
filter .title = "The Matrix"???
про инъекции не слышали, поди?
Доку бы открыл https://www.edgedb.com/docs/edgeql/parameters.
Ну так как теперь модно, через curl ставим. В зависимостях ржавый, ради cli, при этом полноценная клиентская библиотека на ржавом так и не дописана. Клиента для "your favorite language" ставим отдельно через npm/pip. Классика...
Графы это хорошо, но nosql выбирают из-за эффективного горизонтального масштабирования из коробки. Для нагруженных проектов отпадает автоматом.
> Графы это хорошо, но nosql выбирают из-за эффективного горизонтального масштабирования
> из коробки. Для нагруженных проектов отпадает автоматом."Эвона, как"(C) И как масштабируются K-V горизонтально?
Шардированием K ессно. Вопрос то в чём?
> Шардированием K ессно. Вопрос то в чём?Это не вопрос, наверное. Про CAP-теорему не все только лишь слышали, все применяют :) Только не все понимают, что делаю это.
Те кто применяют CAP теорему весьма посредственные личности и не вдупляют, что она не работает. Читайте авторов.
> Те кто применяют CAP теорему весьма посредственные личности и не вдупляют, что
> она не работает. Читайте авторов.Точно. Просьба как можно шире свое мнение распространть.
>но nosql выбирают из-за эффективного горизонтальногов том же neo4j кластера только за деньги... но я уверен, что даже 1нодовая neo4j на голову быстрее надстройки над древним постгресом. хотя у neo4j тоже со скоростью плохо когда хочешь дейкстру на 500меганодах
По факту графы реализуются поверх любой бд. Это лишь абстракция. И на aws и на azure есть такие прослойки поверх соответственно dynamodb и cosmosdb.
DynamoDB это key-value, поверх неё ты графы не построишь.Ты построишь только поверх реляционной БД. И ничего лучше пока не придумали.
Я не спрашиваю, а утверждаю. Зайди на aws или azure и убедись. Графы это предельно примитивная конструкция и key-value более чем достаточно. Скорее вопрос в том, а нужны ли они вообще. И почти всегда ответ - не нужны.
У нас была основная "база данных" на DynamoDB. Я её знаю вдоль и поперек.Либо вы очень плохо знаете и понимаете DynamoDB, либо совсем не разбираетесь что такое реляционная база данных.
Начать надо с самого простого - ACID и транзакций. Которых у DynamoDB нет.
Это даже не обычная БД, а кусок овна.
Рассчитана на лохов и менеджеров.
Угу, 10 лет ежедневной разработки и продакшена на mssql. Тысячи STP, сотни баз. Конечно не знаю, куда нам. Для энтерпрайза и финтеха да, безусловно. Но для массовых продуктов все эти рассказы про целостность перестают кого-то интересовать на моменте, когда производительности не хватает, а вертикально масштабироваться становится слишком дорого.
То что вы там 10 лет мусор производите не делает вас профессионалом.Берёте key-value хранилище (а ни какая не база данных) - отказываетесь практически от всего что делает БД отличным от записи в файл.
А я уверен у вас обычные приложения с транзакциями (нет), агрегационными запросами (нет), надёжностью (нет), индексами (есть).
Объясняю на пальцах. Что такое key-value? Это обычная 1 табличка с индексами по Primary Key.
И что же мешает делать шардинг для обычной БД? Ничего.
И таких баз данных полно. Тот же Yugabyte делает именно это.
Ну да, нас не делает, а вас безусловно делает. Смешно. Давайте подобную ахинею будете нести каким-нибудь бомжам из перехода.
А я кому несу?)))
Когда не хватает производительности - значит OLAP запросы и надо брать column-oriented базу данных.Какой-нибудь Duck DB. Их куча сейчас.
А key-value выбросьте, она очень мало кому нужна. Это обычный dictionary.
>По факту графы реализуются поверх любой бддашотынесёшь.жпг
ты на своей "надстройке над любой дб" сможешь allshortestpaths на глубину 50 шагов просчитывать за милисекунды?
p.s. на базе хотя бы в десятки-сотни миллионов узлов
Тут профи с 100 сделанных проектов. 10 лет опыта. Тяп-ляп и готово. Какие транзакции и гарантии? Да кому они нужны!А то что любой запрос в key-value это практически 100% полный full scan базы данных...
Зато быстро (!) На самом деле нет.
SSD терабайтник поставить за 10к и уже будет летать.Это может быть "медленно" только если терабайты / петабайты на каждый (!) запрос дергать.
Наконец то отличная бд на расте.
бд там postgres, писана на c++. читать научись
> бд там postgres, писана на c++. читать научисьАнониму тож не помешает почитать на чём Postgres написан.
Эксперт экспертом погоняет
Так ты и есть тот эксперт, который все на раст переписывает и всё никак не перепишет. Даже сабж не на расте.
PostgreSQL написан на C. Плюсами там даже и не пахнет.
> Наконец то отличная бд на расте.лол, гитхаб даж проценты пишет
О да вставили какую-то библиотечку 2.6% от общего объема кода. Все теперь проект на раст. А то что 94.3% написано на питоне это всем пофиг. Растофанатики не наделены умственными способностями.
Там на ржавом парсер для cli в виде питоновского модуля, а ржавый даже не входит в "First-party clients for your favorite languages" O_o
Ой, я упустил там ещё есть graphql на питоне и graphql-rewrite на ржавом. То есть в команде одни пишут код, вторые стали переписывать на ржавом и бросили этим заниматься полтора года назад.
Ржавому тут не место
Самое крутая их инновация - это язык запросов и то что база данных объектно-ориентированная.SQL такого не могёт.
Ну, защищенность не забывай, которая обеспечивается использованием раста. Это тоже круто.
Если там и есть какая-та безопасность то только от языка питон, которого в проекте 94.3%
Не обязательно. Можно использовать раст только в самых уязвимых местах, а во все остальные пустить питон. Тогда будет и быстро, и безопасно. Можно быстро писать софт, и деплоить его в производство.
Ну Python и быстро... С другой стороны её писали очень крутые ребята, которые асинхронный стек Python и пушили. Те будет нормально.
> Ну Python и быстро... С другой стороны её писали очень крутые ребята,
> которые асинхронный стек Python и пушили. Те будет нормально.Про скорость исполнения в 2к22... лол. Ретрогады должны страдать.
Ну да, в БД, где считают миллисекунды скорость не имеет значения.Ну, я весь во внимании...
Помните откровения Грэхэма в начале нулевых, про лисп?! Сейчас что-то изменилось?! Важен не язык, а "экосистема". А "экосистема" - это такой лубрикант, благодаря которому "идеальный код" входит в продакшн. Цель этого "ойти" -- продать пользовательскую базу какой-нибудь рыбе покрупнее, а успех "проданной ручки" продать еще кому-то, и желательно пару раз. А рыба перепишет с лиспа на ту уберэкосистему, где у нее побольше инженегров. Потому что юзер сожрет всё что ему скормят. Подождет если надо. Половит баги новой версии. Новый интерфейс. Новые функции. Отсутствие прежних. Может даже другой продукт вообще выкатят. Пофиг, это же планктон, оно даже не придет в сознание по большей части. Малость отсеется канеш, остальную подоят. Скорость? Шта? Подождут, если надо, пока наши инженегры "работают над этим". Схема отработает своё и в утиль: спасибо этому дому.
Базы данных должны быть быстрыми, очень быстрыми. Они это продают.Это значит можно ещё более дерьмовый код писать, вообще забить на алгоритмы и оптимизацию, и всё равно будет работать достойно (всё делает, как и сейчас, БД, остальное это бизнес логика).
Путь хотя бы хоть кто-то делает качественный и быстрый код и заботится о миллисекундах.
ООП головного мозга в базах. Оба пользователя психушки будут рады.
Им тоже надо развлекаться
Ну-ка, расскажи как ты моделируешь JSON или объекты языка с помощью табличек?
чего это "оба"? У нас тут их тыщи!
> Код написан на языках Python и RustPython 94.3%
Cython 3.0%
Rust 2.6%Админ, с тебя жир течет по всему сайту
Ух ты, предмет поддерживает множественное наследование (англ. multiple inheritance) и полиморфные запросы (англ. polimorphic queries) =))
Если это надстройка над psql и если под капотом она использует либо обычные таблицы и join-ы (кажется так, иначе, зачем ей схема и миграция схемы?), либо jsonb + jsonb_path_query, то зачем ей быть клиент-серверной? Почему ей не быть библиотекой, встраиваемой в приложение, например на Go или на питоне?
Что за извращенцы кладут графы в реляционные БД? Может оно там еще и на рекурсивных CTE работает?
А как их ещё класть?
Ну я не знаю даже, посмотрите что ли как в Neo4j это реализовано. Там индексированный поиск в списках смежности, без попытки натянуть графы на реляционную алгебру с джоинами, нормальными формами и прочим. То, что в РСУБД можно при желании запихать иерархические структуры данных, не значит, что так нужно делать. Кроме каких-то совсем простых классических случаев, когда в базе нужно хранить дерево (и наличие цикла считается аномалией, а не фичей, на которой завязана бизнес-логика). Тогда Materialized Path в помощью. Во всех остальных случаях попытка использовать РСУБД для графовых задач - натягивание совы на глобус.
Феерическое ненужно с системой типов устаревшей ещё во времена появления оригинального sql