Size: a a a

Node.js — русскоговорящее сообщество

2020 March 19

AS

Artem Soroka in Node.js — русскоговорящее сообщество
Igor Bond
не это у разраба реляционное мышление было, структуру данных же сам строил
Если такой задачи нет, то оставьте рабочий код
Если хочется заморочиться, то попробуйте переделать под вложенные объекты, но если данные тесно связаны и часто меняются - реляционные БД справятся лучше
источник

VP

Vladislav Plotnikov in Node.js — русскоговорящее сообщество
Как сделать, чтобы на сервере  под каждую сессию выделялось ограниченное число ресурсов и в этой сессии запускалось консольное приложении и вывод этого приложения уходил клиенту
источник

AS

Artem Soroka in Node.js — русскоговорящее сообщество
Vladislav Plotnikov
Как сделать, чтобы на сервере  под каждую сессию выделялось ограниченное число ресурсов и в этой сессии запускалось консольное приложении и вывод этого приложения уходил клиенту
Docker, LXC, jaws, zones, rkt
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
Artem Soroka
Если такой задачи нет, то оставьте рабочий код
Если хочется заморочиться, то попробуйте переделать под вложенные объекты, но если данные тесно связаны и часто меняются - реляционные БД справятся лучше
тут просто нужно понять на сколько критично будет падение производительности при увеличении заказов при такой конструкции. На 1000  заказов то работает норм, но что будет если количество заказов увеличится до 100К или больше.
А вложенные объекты это вместо ссылки по айди копировать нужные данные из другой коллекции?
Вот к примеру на заказ назначается перевозчик - сейчас это делается как в sql - берется id выбранного перевозчика и добавляется в коллекцию заказа. А по монго это выходит надо копировать нужные данные перевозчика сразу в коллекцию заказа что бы было без "join"?
источник

IK

Iliya Kobaliya in Node.js — русскоговорящее сообщество
Ребят,есть ли возможность в стриме,что бы при добавлении в файл , каждой записи добавлять время? const serverStream = fs.createWriteStream(${logPath}/server.log, {
 flags: "a"
});
источник

AS

Artem Soroka in Node.js — русскоговорящее сообщество
Igor Bond
тут просто нужно понять на сколько критично будет падение производительности при увеличении заказов при такой конструкции. На 1000  заказов то работает норм, но что будет если количество заказов увеличится до 100К или больше.
А вложенные объекты это вместо ссылки по айди копировать нужные данные из другой коллекции?
Вот к примеру на заказ назначается перевозчик - сейчас это делается как в sql - берется id выбранного перевозчика и добавляется в коллекцию заказа. А по монго это выходит надо копировать нужные данные перевозчика сразу в коллекцию заказа что бы было без "join"?
А что делать, когда у перевозчика изменятся контактные данные, например? Обходить все заказы?
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
Artem Soroka
А что делать, когда у перевозчика изменятся контактные данные, например? Обходить все заказы?
ну это как раз при существующей структуре не проблема так как через populate всегда выводятся актуальные данные
это при вложенных объектах выходит косяк с актуальностью данных
источник

AS

Artem Soroka in Node.js — русскоговорящее сообщество
Igor Bond
ну это как раз при существующей структуре не проблема так как через populate всегда выводятся актуальные данные
это при вложенных объектах выходит косяк с актуальностью данных
Так может тогда монга не подходит под задачу?
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
Artem Soroka
Так может тогда монга не подходит под задачу?
Получается что без populate не подходит - но этот косяк только в одном месте - в выводе заказов
во всем остальном проекте все гуд. Только из-за этого переходить на sql тоже как бы лажа. Вот и хочу понять на сколько критично будет оставить как есть в плане производительности.
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
или тогда придется менять структуру вывода заказов на попроще
источник

SS

S S in Node.js — русскоговорящее сообщество
Igor Bond
Получается что без populate не подходит - но этот косяк только в одном месте - в выводе заказов
во всем остальном проекте все гуд. Только из-за этого переходить на sql тоже как бы лажа. Вот и хочу понять на сколько критично будет оставить как есть в плане производительности.
В следующем проекте переходи на postgresql пока не поздно
источник

SS

S S in Node.js — русскоговорящее сообщество
Я перешел после монго, любая проблема гуглится и легко решается
источник

SS

S S in Node.js — русскоговорящее сообщество
Эти костыли будете делать постоянно на монго и терять в производительности
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
S S
В следующем проекте переходи на postgresql пока не поздно
да уж, PostgreSQL впечатляет на первый взгляд. в следующий раз заюзаю полюбому
источник

PS

Pavel Shakhov (pongo) in Node.js — русскоговорящее сообщество
Igor Bond
ВСем привет
У меня вопрос к знатокам mongoDB.
есть некоторый проект на ноде и монге но некоторые части реализованы на монге но в стиле реляционных БД.
К примеру есть заказ со своими данными - у заказа есть заказчик данные которого находятся в отдельной коллекции (таблице) - и сделано это как в sql - то есть по ссылке на id заказчика, также реализован перевозчик и водитель и при выводе списка заказчиков все эти данные выводятся через populate - то есть также как в sql через join. Но такая конструкция как бы не камильфо для Монги.
Вопрос следующий - во первых чем это грозит если выборка будет из 100К заказов, или ляма? Будет ли существенное падение скорости чтения? И как правильно это реализовать по заветам Монги?
да просто локально у себя нагенерь для теста кучу случайных заказов и сравни скорость. я думаю тебя всё устроит.
источник

B

Bat in Node.js — русскоговорящее сообщество
Igor Bond
ВСем привет
У меня вопрос к знатокам mongoDB.
есть некоторый проект на ноде и монге но некоторые части реализованы на монге но в стиле реляционных БД.
К примеру есть заказ со своими данными - у заказа есть заказчик данные которого находятся в отдельной коллекции (таблице) - и сделано это как в sql - то есть по ссылке на id заказчика, также реализован перевозчик и водитель и при выводе списка заказчиков все эти данные выводятся через populate - то есть также как в sql через join. Но такая конструкция как бы не камильфо для Монги.
Вопрос следующий - во первых чем это грозит если выборка будет из 100К заказов, или ляма? Будет ли существенное падение скорости чтения? И как правильно это реализовать по заветам Монги?
По своему горькому опыту могу сказать что если связей очень много - то выборка будет медленная, как бы хорошо вы не расставили индексы. Лучше использовтаь реляционные базы (там как минимум есть проверка целостности данных, которая очень важна если в базе хранятся данные о заказах и впринципе чем-то что связано с деньгами)
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
Bat
По своему горькому опыту могу сказать что если связей очень много - то выборка будет медленная, как бы хорошо вы не расставили индексы. Лучше использовтаь реляционные базы (там как минимум есть проверка целостности данных, которая очень важна если в базе хранятся данные о заказах и впринципе чем-то что связано с деньгами)
там 4 поля связаны + фильтр но не по связанным полям, + пагинация (по 20 доков за раз) + сортировка
источник

IB

Igor Bond in Node.js — русскоговорящее сообщество
а заказы не связаны с деньгами или платежами непосредственно приложуха юзер
это ведется список заказов выполненных офлайн для учета и статистики
источник

АХ

Алексей Хмилевой in Node.js — русскоговорящее сообщество
Привет
подскажите пожалуйста, как сделать так, чтобы в одном тесте (jest) замокать модуль, а в остальных оставить тот, который есть.
источник

RB

Random Balance in Node.js — русскоговорящее сообщество
Igor Bond
ВСем привет
У меня вопрос к знатокам mongoDB.
есть некоторый проект на ноде и монге но некоторые части реализованы на монге но в стиле реляционных БД.
К примеру есть заказ со своими данными - у заказа есть заказчик данные которого находятся в отдельной коллекции (таблице) - и сделано это как в sql - то есть по ссылке на id заказчика, также реализован перевозчик и водитель и при выводе списка заказчиков все эти данные выводятся через populate - то есть также как в sql через join. Но такая конструкция как бы не камильфо для Монги.
Вопрос следующий - во первых чем это грозит если выборка будет из 100К заказов, или ляма? Будет ли существенное падение скорости чтения? И как правильно это реализовать по заветам Монги?
Как уже посоветовали выше - это нагрузочное тестирование. Создаёшь данные в нужном объёме, генерируешь нагрузку требуемую и смотришь на поведение. По другому тут не узнаешь точно. Так как тут много "если" (объём трафика, интенсивность, нагрузка на CPU, на диск и т.д.).
источник