1.8, Аноним (8), 13:03, 22/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
| |
|
2.9, Rock (?), 13:19, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем делать из бд сервер приложений, если можно сделать сервер приложений и подконнектиться к бд?
Двухуровневая архитектура? Типа, если хватает, то зачем платить за разработку трехуровневой.
| |
|
3.11, Аноним (11), 14:30, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.
| |
|
4.16, Аноним (10), 17:41, 22/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ерунду пишешь. На счёт начального вопроса выше, ответ же очевиден - часть логики выносится ближе к данным для ускорения работы. Т.к. реляционная СУБД сама по себе не является графовой и всё это добро реализуется поверх таблиц, то одна логическая операция с графовой СУБД может порождать несколько запросов к реляционной с большим потоком данных. Реализация этой функциональности далеко от данных грузит и сеть ненужным трафиком, и вносит дополнительные существенные задержки на запрос.
| |
4.20, Аноним (20), 19:15, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Если на стороне сервера можно выполнять какую-то логику, то это уже сервер приложений.
В частности, практически все современные СУБД являются таковыми.
Наличие триггеров не является сервером приложений.
| |
|
|
2.12, Аноним (12), 16:44, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это очень удобно. Зачем нужно городить целый сервер приложений ради пары десятков функциий для операций над данными? Пусть живут сразу рядом с данными и в контексте данных выполняются. Тупа БД, которой для лбьоц примитивщины нужен сервер приложений не нужна. Можешь спросить хоть Майкрософт, хоть Оракл, хоть АйБиЭм, они на этом не одну собаку съели.
| |
|
3.15, MaleDog (?), 17:14, 22/04/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
Затем, что производительность реляционных СУБД не заточена на все это. В результате получится нечто в 10 раз более тормозное и жрущее ресурсы как не в себя, не говоря уже о безопасности. Пример, была у меня приложуха которая хранила json в postgres и средствами же postgres с ним работала. Спохватился я когда простой insert временами стал превышать три минуты на 8-гиговой базе. Тогда я добавил кэш на nosql, который собирал данные за минуту и вставлял пачкой, такая актуальность была достаточной. Результат:
1. Нагрузка на процессор снизилась с 200% до 5-10%
2. Память с четырех гигов до гига.
3. Ожидание ответа клиентами с трех минут до 1 секунды.
4. Настройки postgres не менялись - он изначально был оптимизирован.
И это все речь об очень небольшом сервере приложений.
| |
|
4.19, Аноним (12), 18:26, 22/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Из своего единичного случая, в котором ты даже не попытался разобраться, и который не имеет никакого отношения к серверам приложений, ты сделал вывод о том, что «производительность реляционных СУБД не заточена на все это»? Кстати, «все это» — это что именно? У меня в проде с ~5к уникальных пользователей в сутки PostgreSQL крутит вместе с данными часть логики, которая была вынесена из основного приложения именно с целью ускорения обработки некоторых запросов. Бэкэнд на крестах через сеть отрабатывает дольше, чем функция на PL/Python прямо в базе.
А как ты там JSON в PG хранил я не знаю. Может ты его на VARCHAR(255) резал, а может у тебя там FTS индексы по нему строятся, но в любом случае твоя байка про три минуты на восьмигиговой базе либо просто ложь, либо конкретная лажа в программировании, потому что за три минуты можно с HDD 8 гиг считать в память, раскурочить там любой JSON, записать обратно на диск, и ещё время на чай с булочкой останется.
| |
|
5.23, MaleDog (?), 20:01, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Всего три поля. два big int и jsonb. Условие только одно уникальность первых двух(upsert). Вставка 20-30 записей в минуту, до 2000-3000 в минуту в пике. Поиск так же только по первым двум. В среднем раз в две недели сервер прибивал omm killer. И на сервере не было 8 гигов памяти. Да они оказались и не нужны. если те же 2000 записей вставлять не по мере прихода по одной, а пачкой все сразу.
| |
|
6.26, Tron is Whistling (?), 21:45, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Там случайно проблема не в latency между клиентом и сервером БД крылась? Каждая вставка - это в лучшем случае один раундтрип (хз как там у постгрыза в протоколе).
| |
|
7.30, MaleDog (?), 22:55, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Клиент это iot-девайс он выгрузил данные одним запросом и ждет подтверждения. Подтверждение поступит только после того, как последняя запись будет вставлена в таблицу. Если он ждет дольше пяти секунд то сам отвалится, поскольку не для IOT ждать минутами - у него батарейка. Если он выгрузил пачку, то будет вставлена пачка. Если всего одну записть между сеансами наработал, то одна запись. Естественно после подъема сервера все хотят выгрузить, то что накопилось. А еще есть боты, которые норовят пощупать все что можно. В общем может и можно средствами postgres и дополнениями реализовать кэш, firewall, фильтрацию невалидных данных, и проблему 10k, но КМК с этим лучше справится отдельное приложение. А тут, "да здравствует трехзвенка". При этом я не чураюсь возможностями postgres. Например для графаны(запросы которой не оптимальны) есть процедуры выбирающие данные по двум первым столбцам и формирующие временные view на основе json. Временные, поскольку постоянные оказались слишком медленными.
| |
7.31, MaleDog (?), 23:06, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
И да я в курсе, что есть более более подходящие базы и дополнения. Но у influxdb есть на мой взгляд недостатки: если у тебя было "поле" с типом bool, а потом тебе понадобилось преобразовать его в int, то фиг у тебя получится без копирования всей таблицы. TimescaleDB для моих объемов и скромных ресурсов это перебор. Зачем тратить деньги на покупку нового более мощного vps если можно решить проблему вынеся часть логики в "прослойку".
| |
|
6.33, Аноним (33), 08:38, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Поддерживаю. 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 приложений.
| |
|
5.29, Аноним (29), 22:04, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
СУБДд предназначена для выполнения запросов, внезапно, на сервере! Если ты загружал все таблицы для обработки в крестах, то это профнепригодность. Хорошо хоть кто-то тебе по рукам дал.
| |
5.32, YetAnotherOnanym (ok), 21:04, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> «все это» — это что именно?
М.б., в контексте данной новости, это работа с данными, составлящими граф?
| |
|
|
3.28, Аноним (29), 22:00, 22/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Кто мешает написать хранимку, чтобы выполнялась прямо в бд? Нет, надо нагородить челую надстройку, со своми багами, под предлогом, что это быстрее. Это НЕ быстрее.
| |
|
|
|