Что быстрее SQL или Javascript?

Question

[Ася]

Есть база данных на RDS postgres, и есть сайт на js. Нужно проделать различные вычисления над данными и передать их на фронтенд (найти средние/макс/мин значения по-разному сгруппированных данных из разных таблиц/вьюх и тд).
Как будет лучше относительно скорости загрузки на сайте, проделать эти вычисления на sql или на js? (или на python используя фласк например?)

Comments

[Ипатьев]

Это потянет на лучший вопрос года.

[freeExec]

Что быстрей велосипед или погрузчик, мне надо дом перевести?

[Ася]

Иерокопус Таманский, я привела пример - группировать данные по разным фичам и находить средние и другие значения

тематика этих данных никак не влияет

[Ася]

Rise, все рассчеты на бэкэнде

[Ася]

Rise, да и node.js и js (так как скорее всего сайт будет на Nuxt.js )

[VolgaVolga]

сайт будет на Nuxt.js

Вы же понимаете, что Nuxt - это не бекенд?

[CityCat4]

Ипатьев, Адназначна. Жаль не видел вечером :) Ну да ладно, девочкам мы многое прощаем :)

Answer 1

[Ипатьев]

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

Несомненно, из любого правила есть исключения. И бывают ситуации, когда приходится считать в приложении.
Но на вопрос в общем виде ответ будет совершенно однозначный. Не "может так, может сяк", а только в БД.

Comments

[Ася]

заголовок получился кликбейтный потому что все описание вопроса туда не поместилось бы

на js тоже спокойно можно обрабатывать значительные объемы данных (tensorflow js или чем-то попроще)

поэтому и вопрос что быстрее будет работать

[Ипатьев]

обновил ответ

[Ася]

Ипатьев, спасибо

[d'Ivan]

Ася,
По таким качествам как: количество кода (1-2 запроса SQL против кода на JS), производительность и понятность - будет у СУБД.

[Владимир]

ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там"

Совершенно неочевиден на самом деле. В некоторых случаях архитектура с толстым клиентом предпочтительнее использования тонкого клиента. Например, построение n-мерных кубов данных при n>3 или значительной выборке. Если вы нагрузите этим СУБД, то первые же 1-3 запроса уложат ее наглухо, а если СУБД крутится на том же сервере, что и http, то ляжет все. Поэтому, может быть и так, и сяк, и толстый клиент, и тонкий. Архитектуру надо выбирать исходя из решаемой задачи, а не из религиозных соображений)

ЗЫ
Т.к. стоит задача

найти средние/макс/мин значения по-разному сгруппированных данных из разных таблиц/вьюх и тд

, то речь как раз, походу, идет о кубах данных, так что тут вполне может быть оправдано использование толстого клиента. Выборку делать на сервере, а обработку - в клиенте.

[Ипатьев]

Владимир, про "некоторые случаи" у меня и так написано, спасибо можно не повторяться.
Ваш же пример высосан из пальца. Ваш "куб" прекрасно раскладывается на индексы, которые уже лежат в оперативке и выборка по которым ничего никуда не положит. В отличие от выборки и перекачивания гигов сырых данных.

[Владимир]

Ипатьев, у вас написано

...ответ будет совершенно однозначный. Не "может так, может сяк", а только в БД.

, так что лапшу вешать будете друзьям за пивом. Что касается "высосан из пальца", то прежде чем начинать их растопыривать, демонстрирую свою необразованность, ознакомьтесь хотя бы в общих чертах с OLAP.

[Ипатьев]

Владимир, если вам нужен OLAP, то его опять же надо делать в специализированном хранилище, а не "в JS".
Здесь много бегает любителей демонстрировать всем окружающим размер своей учоности, но неспособных прочитать простой вопрос новичка и ответить на него.

[Владимир]

Ипатьев, идите и учитесь.

Answer 2

[Saboteur]

Вопрос задан как пальцем в небо.
Быстрее будет не отдельно взятый постгрес или сайт на js, а машина, на которой это все будет считаться.
JS где - у пользователя в браузе, или это nodejs на сервере?
постгрес крутится на той же машине, или на другой? Какой там процессор, сколько, сколько памяти?

Не забывать, что если данные лежат в базе, а считать вы будете в JS, то к расчетам еще добавить время на передачу данных, поэтому чисто теоретически наверное выполнить все на постгресе должно быть быстрее.

Но вам никто не ответит на вопрос точно. Гораздо проще провести перформанс тесты и посмотреть живые ответы.

Comments

[Ася]

сайт лежит на EC2 (то есть отдельно от базы данных на RDS), t2.large, количество vCPUs 2, вольюм 100, память 8
подсчеты на sql/js на сервере которые потом будут передаваться на фронт через js

[Saboteur]

ну никто не знает сколько и каких процессоров на сервере, где хостится база. Делайте тесты.

[Wan-Derer]

Присоединюсь к рекомендации провести тесты на типичных для задачи объёмах данных. Дополню: считается что при прочих равных код в БД плохо поддаётся тестированию, управлению версиями, CI/CD и прочим штукам, к которым программисты привыкли и которые сильно помогают. Поэтому если объём данным относительно невелик и предполагается развитие проекта - считать лучше вне БД.
Если задача разовая - то пофиг, пиши на том что знаешь.

Answer 3

[Андрей]

Вопрос в объемах данных.

Если вы хотите найти средний чек по сотне покупок - то вообще без разницы, как именно вы это сделаете.
А если у вас средний чек по сотне тысяч покупок - то считать на nodejs будет довольно проблемно, даже если вы туда никакой ORM-ки не накинете над данными.

А если покупок у вас сотня миллионов - то проблема будет считать и в постгресе.

Answer 4

[mayton2019]

Мужские мужчины уже ответили на основной вопрос.

Я добавлю что чем больше данных мы обрабатываем тем дороже становиться цена передчи
информации из места где оно храниться в блок вычислений. В концепции трехзвенки которая
описана RDS(Postgres)/NodeJS/Python/Web удобнее всего вычилсять прямо в Postgres. Поскольку
данные рядом и сетевых расходов на передачу нет. Если Postgres по каким-то причинам не может
вычислять или не владеет API то в этом случае мы с помощью курсора (SELECT) передаем
нужный датасет на клиента (в данном случае это Python/Node) и там вычисляем. При этом
мы должны понимать что это займет время и сетевой канал да еще и результат вычислений
тоже надо отослать обратно. Тоесть данные будут бегать как рейсовый автобус туда-сюда.

Для однозначного решения что хорошо и что плохо - надо ставить эскперимент. Но предварительно
мне и присуствующим уже очевидно что лучше всего вычислять прямо в хранимых процедурах
Postgres. Единственным доводом против может быть несовершенство языка PL/pgSQL
но я-бы этот факт тоже проверил. Для реляционных задач его обычно хватало.

Данная проблема (рейсовый автобус для данных) еще более сильно выражена в BigData. Там стараются
дизайнить систему так что данные - write-only и после загрузки в хранилище (ETL/ELT) больше никогда
не изменяются и лежат неподвижно (т.н. Bronze Level информации). И джобы которые бегают
по ним - запускаются в вычислительном кластере физически рядом с дисковым хранилищем.

Вот. А на клиента отдаются обычно сводные отчеты и кака-то аналитика. Это то что в 100-10000 раз меньше
по размеру обычно чем основные данные.

Answer 5

[Dimonchik]

(найти средние/макс/мин значения по-разному сгруппированных данных из разных таблиц/вьюх и тд).

это называется OLAP
OLAP DB так и гуглите, есть как надстройки на классик RDBMS так и спроектированные базы

есть конечно и продукты на Питоне но это больше для развлечения, основная проблема - засирание памяти

Answer 6

[hrum]

если исключить ноду на сервере, то на практике данные (консолидированные в соответствии с запросами) берем с сервера из базы данных и передаем их через апач на клиента (пользовательский браузер), а там на JScript делаем с ними что угодно, в смысле вычисления / графическое представление.
Профит: сервер может обслуживать больше запросов и быстрее, обработка на стороне клиента (это уже от его РС-мощностей зависит насколько быстро будет рендерится) но если РС нормальные и это приложение бизнес и основное в браузере, то обычно без проблем.