Как ускорить работу метода в js или как сделать массовое обращение к бд?

Question

[Adel Khalitov]

Вопрос очень простой. Есть метод, который выполняет простую задачу. К примеру.
Есть товар который хранится в таблице good, есть остатки товаров хранятся в таблице balances, есть еще 200 необходимых параметров который относятся к товару.

Пример реализации

async some(id) {
let good = await goods.findOne(id);
let balance = await balances.findOne(some);
.... итп так 200 раз
}

Выполнение этой функции займет примерно 300 дней, условно. Вариант не подходит тк долго

Видел реализацию такую

let goodsObj = {};
let promises = [goods.findOne(id, goodsObj), balances.findOne(some, goodsObj) ...200 обращений в бд];
Promise.all(promises);

Скорост быстрее, нагрузка на базу хорошечная, в данном случае каждый метод в массиве promises просто добавляет новый ключ с каким то значением в объект goodsObj.

Вариант имеет место быть, но я пытался отладить подобный проект на 6 сервисов в такой реализации, после этого в своем паспорте гражданина РФ ручкой написал, что так никогда реализовывать не буду.

Я уверен что есть 3й вариант, самый правельный как это реализовать.
БД совершенно любая монга, мускул итп. Дайте пж направление

Comments

[Somewhere Intech]

Наверное логику выборки перекинуть на базу? Я имею ввиду, что если свойства поиска одинаковые и разница лишь в значениях, то можно описать запрос в виде выборки всех 200 сразу?

[Adel Khalitov]

Johnny Lowhunter, А может быть второй вариант хорош собой, возможно так будет явно.

let goodObj = {
   good: goods.findOne(id),
   balance: balances.findOne(id),
...
}
Promise.all(Object.values(goodsObj))

Меня интересует правильная практика в коммерческих проектах. Если переложить логику, то как это гуглить?)

[ThunderCat]

Параметр функции id товара.
let good = await goods.findOne(id);
let balance = await balances.findOne(id);

Похоже про джоины и все что сложнее оболочек над бд вам никто не сказал... Я правильно понимаю что у вас есть группа id, по которой вы циклом делаете запросы в бд?

[Adel Khalitov]

ThunderCat, Извиняюсь, я поправил задачу. Нет акцента на параметры функций. Иными словами для формирования конечного объекта почти в каждом методе я делаю 2-10(200) разных запросов в разные таблицы бд.
И по сути это выглядит так
ждать пока найдем товары (время выполнения 1 секунда),
ждать пока нейдем остатки (время выполнения 1 секунда)
итп...

То есть мы ждем пока поочередно добудится информация из бд для того чтобы продлжить работать с объектами дальше.
Можно сказать да, делаю запрос циклом. Можно сделать запрос как в комменратии над вашим, думаю это хорошее решение. Но на сколько это хорошая практика?

[Kovalsky]

Adel Khalitov, всю всю всю эту вашу логику перенесите в бд

[Adel Khalitov]

Kovalsky, Я видимно немного не понимаю каким образом) Подскажите пж хоть один механизм приминимый к любой бд, чтобы я смог хотябы нащупать направление?

[Somewhere Intech]

Adel Khalitov, он имел ввиду что джоинами (и т.п.) можно снизить нагрузку с бд и вашей логики. Это вопрос к архитектуре бд, возможно реорганизовав её вы оптимизируете затраты. Возможно что хэширование Вам поможет. В любом случае Вам снизит затраты на мощность перевод логики ниже уровнем (go,rust......) Да и кластеризацию никто не отменял( promise all к кластеризированной бд кажется тут логичным). Но всё мною сказанное не даст вам гарантий, т.к. в коммерции у меня нет опыта и уж тем более в высоконагруженных проектах :)
P.S. MIT license owner (answers taken as-is)

[ThunderCat]

Adel Khalitov,

Но на сколько это хорошая практика?

По сути это самое кошмарное решение из всех возможных. БД имеет механизмы выборки массивов данных по определенным параметрам, собственно смысл всех бд в том чтобы получать большие выборки быстро. Иначе проще было бы все хранить в файликах. По этому вам предлагают написать нормальный запрос на SQL (ну или с помощью goods.find() или как там у вас построитель запросов в вашем фреймворке работает), который выберет весь список строк одним запросом, не издеваясь над подключением 100 раз, и это займет не 100 секунд, а примерно 1 секунду (в зависимости от правильности таблиц/индексов и запроса), получите массив строк и дальше итерируете как нравится.

[Adel Khalitov]

ThunderCat, Johnny Lowhunter, Kovalsky, Да я понял основную идею. Спасибо

Answer 1

[Romaboy]

Метод Promise.all не только лишь ждет, а и возвращает результаты, по этому объект не нужен:
const [a, b] = await Promise.all([query1, query2])
Если их реально 200, то объект конечно лучше будет) В жизни такого не видел, 10+ запросов на странице - уже тянет отрефакторить, да разные бывают кейсы, это наверняка очень необычная задача.

Дальше относится к postgres, монгу не знаю:

Чтобы не оптимизировать ни базу, ни сами запросы можно использовать пул соединений.
Одно соединение с базой (один сокет) может одновременно ожидать только один ответ, то есть от промисов толку будет ровно 0.

К базе можно одновременно послать множество запросов через одно соединение:
SELECT 1; SELECT 2; SELECT 3
Базы понимают точку с запятой, умеют распараллеливать, но вот беда! Скорее всего js библиотека так не умеет. Окей, на самом деле не уверен что это параллельно выполнятся, но базы точно умеют на такой соединенный запрос отвечать и это быстрее работало бы чем 3 отдельных.

Ещё postgres умеет превращать строку в json и можно писать что-то вроде

SELECT
  (SELECT row_to_json(table.*) FROM table LIMIT 1) AS one_result,
  (SELECT json_agg(row_to_json(table.*)) FROM table LIMIT 1) AS second_result

Такая конструкция в one_result вернет json одной записи, в second_result массив, эти два запроса никак не связаны между собой, выполняются в одном обращении, база у себя из распараллеливает, все круто и здорово, но для разработчиков это слишком сложно и я нигде почти такого не видел, когда писал - ловил косые взгляды, библиотеки сами такое генерировать не умеют. (как раз пишу одну чтобы умела, осталось самое сложное - дока)

В монге аналог join называется lookup, goods.findOne(id) похоже на монгу