The OpenNET Project / Index page

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



"Выпуск реляционно-графовой СУБД EdgeDB 5.0 "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

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

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61041

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


8. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +3 +/
Сообщение от Аноним (8), 22-Апр-24, 13:03 
Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Rock (?), 22-Апр-24, 13:19 
> Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?

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

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (10), 22-Апр-24, 13:53 
Где ты здесь увидел сервер приложений?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

11. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (11), 22-Апр-24, 14:30 
Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.
Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +2 +/
Сообщение от Аноним (10), 22-Апр-24, 17:41 
Ерунду пишешь. На счёт начального вопроса выше, ответ же очевиден - часть логики выносится ближе к данным для ускорения работы. Т.к. реляционная СУБД сама по себе не является графовой и всё это добро реализуется поверх таблиц, то одна логическая операция с графовой СУБД может порождать несколько запросов к реляционной с большим потоком данных. Реализация этой функциональности далеко от данных грузит и сеть ненужным трафиком, и вносит дополнительные существенные задержки на запрос.
Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (20), 22-Апр-24, 19:15 
> Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.

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

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

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (12), 22-Апр-24, 16:44 
Это очень удобно. Зачем нужно городить целый сервер приложений ради пары десятков функциий для операций над данными? Пусть живут сразу рядом с данными и в контексте данных выполняются. Тупа БД, которой для лбьоц примитивщины нужен сервер приложений не нужна. Можешь спросить хоть Майкрософт, хоть Оракл, хоть АйБиЭм, они на этом не одну собаку съели.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

15. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +3 +/
Сообщение от MaleDog (?), 22-Апр-24, 17:14 
Затем, что производительность реляционных СУБД не заточена на все это. В результате получится нечто в 10 раз более тормозное и жрущее ресурсы как не в себя, не говоря уже о безопасности. Пример, была у меня приложуха которая хранила json в postgres и средствами же postgres с ним работала. Спохватился я когда простой insert временами стал превышать три минуты на 8-гиговой базе. Тогда я добавил кэш на nosql, который собирал данные за минуту и вставлял пачкой, такая актуальность была достаточной. Результат:
1. Нагрузка на процессор снизилась с 200% до 5-10%
2. Память с четырех гигов до гига.
3. Ожидание ответа клиентами с трех минут до 1 секунды.
4. Настройки postgres не менялись - он изначально был оптимизирован.

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

Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +2 +/
Сообщение от Аноним (12), 22-Апр-24, 18:26 
Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе.

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

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от MaleDog (?), 22-Апр-24, 20:01 
Всего три поля. два big int и jsonb. Условие только одно уникальность первых двух(upsert). Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике. Поиск так же только по первым двум.  В среднем раз в две недели сервер прибивал omm killer. И на сервере не было 8 гигов памяти. Да они оказались и не нужны. если те же 2000 записей вставлять не по мере прихода по одной, а пачкой все сразу.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Tron is Whistling (?), 22-Апр-24, 21:44 
> Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике

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

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Tron is Whistling (?), 22-Апр-24, 21:45 
Там случайно проблема не в latency между клиентом и сервером БД крылась? Каждая вставка - это в лучшем случае один раундтрип (хз как там у постгрыза в протоколе).
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

30. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от MaleDog (?), 22-Апр-24, 22:55 
Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения. Подтверждение поступит только после того, как последняя запись будет вставлена в таблицу. Если он ждет дольше пяти секунд то сам отвалится, поскольку не для IOT ждать минутами - у него батарейка. Если он выгрузил пачку, то будет вставлена пачка. Если всего одну записть между сеансами наработал, то одна запись. Естественно после подъема сервера все хотят выгрузить, то что накопилось. А еще есть боты, которые норовят пощупать все что можно. В общем может и можно средствами postgres и дополнениями реализовать кэш, firewall, фильтрацию невалидных данных, и проблему 10k, но КМК с этим лучше справится отдельное приложение. А тут, "да здравствует трехзвенка". При этом я не чураюсь возможностями postgres. Например для графаны(запросы которой не оптимальны) есть процедуры выбирающие данные по двум первым столбцам и формирующие временные view на основе json. Временные, поскольку постоянные оказались слишком медленными.
Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от MaleDog (?), 22-Апр-24, 23:06 
И да я в курсе, что есть более более подходящие базы и дополнения. Но у influxdb есть на мой взгляд недостатки: если у тебя было "поле" с типом bool, а потом тебе понадобилось преобразовать его в int, то фиг у тебя получится без копирования всей таблицы. TimescaleDB для моих объемов и скромных ресурсов это перебор. Зачем тратить деньги на покупку нового более мощного vps если можно решить проблему вынеся часть логики в "прослойку".
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

33. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (33), 25-Апр-24, 08:38 
Поддерживаю. 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 приложений.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

24. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от MaleDog (?), 22-Апр-24, 20:07 
И да. Быть медленне HDD можно, если уйти в своп.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

27. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +1 +/
Сообщение от Tron is Whistling (?), 22-Апр-24, 21:46 
Если сервер СУБД ушёл в своп - это почти что профнепригодность :)
Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (29), 22-Апр-24, 22:04 
СУБДд предназначена для выполнения запросов, внезапно, на сервере! Если ты загружал все таблицы для обработки в крестах, то это профнепригодность. Хорошо хоть кто-то тебе по рукам дал.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

32. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от YetAnotherOnanym (ok), 23-Апр-24, 21:04 
> «все это» — это что именно?

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

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

28. "Выпуск реляционно-графовой СУБД EdgeDB 5.0 "  +/
Сообщение от Аноним (29), 22-Апр-24, 22:00 
Кто мешает написать хранимку, чтобы выполнялась прямо в бд? Нет, надо нагородить челую надстройку, со своми багами, под предлогом, что это быстрее. Это НЕ быстрее.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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