forum.opennet.ru - "Выпуск реляционно-графовой СУБД EdgeDB 5.0 " (20)

"Выпуск реляционно-графовой СУБД 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.ru/opennews/art.shtml?num=61041
Ответить \| Правка \| Cообщить модератору

Оглавление

Зачем делать из бд сервер приложений, если можно сделать сервер приложений и под, Аноним (8), 13:03 , 22-Апр-24, (8) +3

Двухуровневая архитектура Типа, если хватает, то зачем платить за разработку тр, Rock (?), 13:19 , 22-Апр-24, (9)
Где ты здесь увидел сервер приложений , Аноним (10), 13:53 , 22-Апр-24, (10)

Если на стороне сервера можно выполнять какую-то логику, то это уже сервер прило, Аноним (11), 14:30 , 22-Апр-24, (11)

Ерунду пишешь На счёт начального вопроса выше, ответ же очевиден - часть логики, Аноним (10), 17:41 , 22-Апр-24, (16) +2
В частности, практически все современные СУБД являются таковыми Наличие триггеро, Аноним (20), 19:15 , 22-Апр-24, (20)

Это очень удобно Зачем нужно городить целый сервер приложений ради пары десятко, Аноним (12), 16:44 , 22-Апр-24, (12)

Затем, что производительность реляционных СУБД не заточена на все это В результ, MaleDog (?), 17:14 , 22-Апр-24, (15) +3

Из своего единичного случая, в котором ты даже не попытался разобраться, и котор, Аноним (12), 18:26 , 22-Апр-24, (19) +2

Всего три поля два big int и jsonb Условие только одно уникальность первых дву, MaleDog (?), 20:01 , 22-Апр-24, (23)

Это вообще ни о чём , Tron is Whistling (?), 21:44 , 22-Апр-24, (25)
Там случайно проблема не в latency между клиентом и сервером БД крылась Каждая , Tron is Whistling (?), 21:45 , 22-Апр-24, (26)

Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения По, MaleDog (?), 22:55 , 22-Апр-24, (30)
И да я в курсе, что есть более более подходящие базы и дополнения Но у influxdb, MaleDog (?), 23:06 , 22-Апр-24, (31)

Поддерживаю JSON, XML - не место в реляционной БД Примерно такой же случай у м, Аноним (33), 08:38 , 25-Апр-24, (33)

И да Быть медленне HDD можно, если уйти в своп , MaleDog (?), 20:07 , 22-Апр-24, (24)

Если сервер СУБД ушёл в своп - это почти что профнепригодность , Tron is Whistling (?), 21:46 , 22-Апр-24, (27) +1

СУБДд предназначена для выполнения запросов, внезапно, на сервере Если ты загру, Аноним (29), 22:04 , 22-Апр-24, (29)
М б , в контексте данной новости, это работа с данными, составлящими граф , YetAnotherOnanym (ok), 21:04 , 23-Апр-24, (32)

Кто мешает написать хранимку, чтобы выполнялась прямо в бд Нет, надо нагородить, Аноним (29), 22:00 , 22-Апр-24, (28)

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

8. Сообщение от Аноним (8), 22-Апр-24, 13:03 +3 +/–

Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #10, #12

9. Сообщение от Rock (?), 22-Апр-24, 13:19 +/–

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

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

10. Сообщение от Аноним (10), 22-Апр-24, 13:53 +/–

Где ты здесь увидел сервер приложений?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #11

11. Сообщение от Аноним (11), 22-Апр-24, 14:30 +/–

Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16, #20

12. Сообщение от Аноним (12), 22-Апр-24, 16:44 +/–

Это очень удобно. Зачем нужно городить целый сервер приложений ради пары десятков функциий для операций над данными? Пусть живут сразу рядом с данными и в контексте данных выполняются. Тупа БД, которой для лбьоц примитивщины нужен сервер приложений не нужна. Можешь спросить хоть Майкрософт, хоть Оракл, хоть АйБиЭм, они на этом не одну собаку съели.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15, #28

15. Сообщение от MaleDog (?), 22-Апр-24, 17:14 +3 +/–

Затем, что производительность реляционных СУБД не заточена на все это. В результате получится нечто в 10 раз более тормозное и жрущее ресурсы как не в себя, не говоря уже о безопасности. Пример, была у меня приложуха которая хранила json в postgres и средствами же postgres с ним работала. Спохватился я когда простой insert временами стал превышать три минуты на 8-гиговой базе. Тогда я добавил кэш на nosql, который собирал данные за минуту и вставлял пачкой, такая актуальность была достаточной. Результат:
1. Нагрузка на процессор снизилась с 200% до 5-10%
2. Память с четырех гигов до гига.
3. Ожидание ответа клиентами с трех минут до 1 секунды.
4. Настройки postgres не менялись - он изначально был оптимизирован.
И это все речь об очень небольшом сервере приложений.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #19

16. Сообщение от Аноним (10), 22-Апр-24, 17:41 +2 +/–

Ерунду пишешь. На счёт начального вопроса выше, ответ же очевиден - часть логики выносится ближе к данным для ускорения работы. Т.к. реляционная СУБД сама по себе не является графовой и всё это добро реализуется поверх таблиц, то одна логическая операция с графовой СУБД может порождать несколько запросов к реляционной с большим потоком данных. Реализация этой функциональности далеко от данных грузит и сеть ненужным трафиком, и вносит дополнительные существенные задержки на запрос.

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

19. Сообщение от Аноним (12), 22-Апр-24, 18:26 +2 +/–

Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе.
А как ты там JSON в PG хранил я не знаю. Может ты его на VARCHAR(255) резал, а может у тебя там FTS индексы по нему строятся, но в любом случае твоя байка про три минуты на восьмигиговой базе либо просто ложь, либо конкретная лажа в программировании, потому что за три минуты можно с HDD 8 гиг считать в память, раскурочить там любой JSON, записать обратно на диск, и ещё время на чай с булочкой останется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #23, #24, #29, #32

20. Сообщение от Аноним (20), 22-Апр-24, 19:15 +/–

> Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.
Наличие триггеров не является сервером приложений.

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

23. Сообщение от MaleDog (?), 22-Апр-24, 20:01 +/–

Всего три поля. два big int и jsonb. Условие только одно уникальность первых двух(upsert). Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике. Поиск так же только по первым двум. В среднем раз в две недели сервер прибивал omm killer. И на сервере не было 8 гигов памяти. Да они оказались и не нужны. если те же 2000 записей вставлять не по мере прихода по одной, а пачкой все сразу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #25, #26, #33

24. Сообщение от MaleDog (?), 22-Апр-24, 20:07 +/–

И да. Быть медленне HDD можно, если уйти в своп.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27

25. Сообщение от Tron is Whistling (?), 22-Апр-24, 21:44 +/–

> Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике
Это вообще ни о чём.

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

26. Сообщение от Tron is Whistling (?), 22-Апр-24, 21:45 +/–

Там случайно проблема не в latency между клиентом и сервером БД крылась? Каждая вставка - это в лучшем случае один раундтрип (хз как там у постгрыза в протоколе).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #30, #31

27. Сообщение от Tron is Whistling (?), 22-Апр-24, 21:46 +1 +/–

Если сервер СУБД ушёл в своп - это почти что профнепригодность :)

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

28. Сообщение от Аноним (29), 22-Апр-24, 22:00 +/–

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

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

29. Сообщение от Аноним (29), 22-Апр-24, 22:04 +/–

СУБДд предназначена для выполнения запросов, внезапно, на сервере! Если ты загружал все таблицы для обработки в крестах, то это профнепригодность. Хорошо хоть кто-то тебе по рукам дал.

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

30. Сообщение от MaleDog (?), 22-Апр-24, 22:55 +/–

Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения. Подтверждение поступит только после того, как последняя запись будет вставлена в таблицу. Если он ждет дольше пяти секунд то сам отвалится, поскольку не для IOT ждать минутами - у него батарейка. Если он выгрузил пачку, то будет вставлена пачка. Если всего одну записть между сеансами наработал, то одна запись. Естественно после подъема сервера все хотят выгрузить, то что накопилось. А еще есть боты, которые норовят пощупать все что можно. В общем может и можно средствами postgres и дополнениями реализовать кэш, firewall, фильтрацию невалидных данных, и проблему 10k, но КМК с этим лучше справится отдельное приложение. А тут, "да здравствует трехзвенка". При этом я не чураюсь возможностями postgres. Например для графаны(запросы которой не оптимальны) есть процедуры выбирающие данные по двум первым столбцам и формирующие временные view на основе json. Временные, поскольку постоянные оказались слишком медленными.

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

31. Сообщение от MaleDog (?), 22-Апр-24, 23:06 +/–

И да я в курсе, что есть более более подходящие базы и дополнения. Но у influxdb есть на мой взгляд недостатки: если у тебя было "поле" с типом bool, а потом тебе понадобилось преобразовать его в int, то фиг у тебя получится без копирования всей таблицы. TimescaleDB для моих объемов и скромных ресурсов это перебор. Зачем тратить деньги на покупку нового более мощного vps если можно решить проблему вынеся часть логики в "прослойку".

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

32. Сообщение от YetAnotherOnanym (ok), 23-Апр-24, 21:04 +/–

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

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

33. Сообщение от Аноним (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 приложений.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

8. Сообщение от Аноним (8), 22-Апр-24, 13:03	+3 +/–
Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #9, #10, #12

9. Сообщение от Rock (?), 22-Апр-24, 13:19	+/–
> Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд? Двухуровневая архитектура? Типа, если хватает, то зачем платить за разработку трехуровневой.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

10. Сообщение от Аноним (10), 22-Апр-24, 13:53	+/–
Где ты здесь увидел сервер приложений?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #11

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

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

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

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

19. Сообщение от Аноним (12), 22-Апр-24, 18:26	+2 +/–
Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе. А как ты там JSON в PG хранил я не знаю. Может ты его на VARCHAR(255) резал, а может у тебя там FTS индексы по нему строятся, но в любом случае твоя байка про три минуты на восьмигиговой базе либо просто ложь, либо конкретная лажа в программировании, потому что за три минуты можно с HDD 8 гиг считать в память, раскурочить там любой JSON, записать обратно на диск, и ещё время на чай с булочкой останется.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #23, #24, #29, #32

20. Сообщение от Аноним (20), 22-Апр-24, 19:15	+/–
> Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений. В частности, практически все современные СУБД являются таковыми. Наличие триггеров не является сервером приложений.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

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

24. Сообщение от MaleDog (?), 22-Апр-24, 20:07	+/–
И да. Быть медленне HDD можно, если уйти в своп.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19 Ответы: #27

25. Сообщение от Tron is Whistling (?), 22-Апр-24, 21:44	+/–
> Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике Это вообще ни о чём.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23

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

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

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

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

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

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

32. Сообщение от YetAnotherOnanym (ok), 23-Апр-24, 21:04	+/–
> «все это» — это что именно? М.б., в контексте данной новости, это работа с данными, составлящими граф?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

33. Сообщение от Аноним (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 приложений.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23