Доступен релиз СУБД EdgeDB 5.0, реализующей реляционно-графовую модель данных и язык запросов EdgeQL, оптимизированные для работы со сложными иерархическими данными. Проект развивается в форме надстройки над PostgreSQL, код которой написан на языках Python и Rust (парсер и критичные к производительности части), и распространяется под лицензией Apache 2.0. Клиентские библиотеки подготовлены для языков Python, Go, Rust. .NET, Elixir и TypeScript/Javascript. Предоставляется инструментарий командной строки для управления СУБД и интерактивного выполнения запросов (REPL)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61041
Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
> Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?Двухуровневая архитектура? Типа, если хватает, то зачем платить за разработку трехуровневой.
Где ты здесь увидел сервер приложений?
Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.
Ерунду пишешь. На счёт начального вопроса выше, ответ же очевиден - часть логики выносится ближе к данным для ускорения работы. Т.к. реляционная СУБД сама по себе не является графовой и всё это добро реализуется поверх таблиц, то одна логическая операция с графовой СУБД может порождать несколько запросов к реляционной с большим потоком данных. Реализация этой функциональности далеко от данных грузит и сеть ненужным трафиком, и вносит дополнительные существенные задержки на запрос.
> Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.В частности, практически все современные СУБД являются таковыми.
Наличие триггеров не является сервером приложений.
Это очень удобно. Зачем нужно городить целый сервер приложений ради пары десятков функциий для операций над данными? Пусть живут сразу рядом с данными и в контексте данных выполняются. Тупа БД, которой для лбьоц примитивщины нужен сервер приложений не нужна. Можешь спросить хоть Майкрософт, хоть Оракл, хоть АйБиЭм, они на этом не одну собаку съели.
Затем, что производительность реляционных СУБД не заточена на все это. В результате получится нечто в 10 раз более тормозное и жрущее ресурсы как не в себя, не говоря уже о безопасности. Пример, была у меня приложуха которая хранила json в postgres и средствами же postgres с ним работала. Спохватился я когда простой insert временами стал превышать три минуты на 8-гиговой базе. Тогда я добавил кэш на nosql, который собирал данные за минуту и вставлял пачкой, такая актуальность была достаточной. Результат:
1. Нагрузка на процессор снизилась с 200% до 5-10%
2. Память с четырех гигов до гига.
3. Ожидание ответа клиентами с трех минут до 1 секунды.
4. Настройки postgres не менялись - он изначально был оптимизирован.И это все речь об очень небольшом сервере приложений.
Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе.А как ты там JSON в PG хранил я не знаю. Может ты его на VARCHAR(255) резал, а может у тебя там FTS индексы по нему строятся, но в любом случае твоя байка про три минуты на восьмигиговой базе либо просто ложь, либо конкретная лажа в программировании, потому что за три минуты можно с HDD 8 гиг считать в память, раскурочить там любой JSON, записать обратно на диск, и ещё время на чай с булочкой останется.
Всего три поля. два big int и jsonb. Условие только одно уникальность первых двух(upsert). Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике. Поиск так же только по первым двум. В среднем раз в две недели сервер прибивал omm killer. И на сервере не было 8 гигов памяти. Да они оказались и не нужны. если те же 2000 записей вставлять не по мере прихода по одной, а пачкой все сразу.
> Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пикеЭто вообще ни о чём.
Там случайно проблема не в latency между клиентом и сервером БД крылась? Каждая вставка - это в лучшем случае один раундтрип (хз как там у постгрыза в протоколе).
Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения. Подтверждение поступит только после того, как последняя запись будет вставлена в таблицу. Если он ждет дольше пяти секунд то сам отвалится, поскольку не для IOT ждать минутами - у него батарейка. Если он выгрузил пачку, то будет вставлена пачка. Если всего одну записть между сеансами наработал, то одна запись. Естественно после подъема сервера все хотят выгрузить, то что накопилось. А еще есть боты, которые норовят пощупать все что можно. В общем может и можно средствами postgres и дополнениями реализовать кэш, firewall, фильтрацию невалидных данных, и проблему 10k, но КМК с этим лучше справится отдельное приложение. А тут, "да здравствует трехзвенка". При этом я не чураюсь возможностями postgres. Например для графаны(запросы которой не оптимальны) есть процедуры выбирающие данные по двум первым столбцам и формирующие временные view на основе json. Временные, поскольку постоянные оказались слишком медленными.
И да я в курсе, что есть более более подходящие базы и дополнения. Но у influxdb есть на мой взгляд недостатки: если у тебя было "поле" с типом bool, а потом тебе понадобилось преобразовать его в int, то фиг у тебя получится без копирования всей таблицы. TimescaleDB для моих объемов и скромных ресурсов это перебор. Зачем тратить деньги на покупку нового более мощного vps если можно решить проблему вынеся часть логики в "прослойку".
Поддерживаю. 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 приложений.
И да. Быть медленне HDD можно, если уйти в своп.
Если сервер СУБД ушёл в своп - это почти что профнепригодность :)
СУБДд предназначена для выполнения запросов, внезапно, на сервере! Если ты загружал все таблицы для обработки в крестах, то это профнепригодность. Хорошо хоть кто-то тебе по рукам дал.
> «все это» — это что именно?М.б., в контексте данной новости, это работа с данными, составлящими граф?
Кто мешает написать хранимку, чтобы выполнялась прямо в бд? Нет, надо нагородить челую надстройку, со своми багами, под предлогом, что это быстрее. Это НЕ быстрее.