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

"Выпуск реляционно-графовой СУБД 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 | Индекс форумов | Темы | Пред. тема | След. тема