Sebastian
Вам не хватает "е"?
{date: {$ ne: {$ elemMatch: {"$ gt": новая дата ()}}}}
Aleksey
Slava
yopp
https://marmelab.com/blog/2018/04/03/how-to-track-and-fix-memory-leak-with-nodejs.html#accessing-nodejs-memory-using-v8-inspector--chrome-dev-tools
yopp
ищите где у вас текут объекты
Aleksey
Спасибо
Timofey
db.collection.insert принимает вторым аргументом коллбек:
(err, result) => {}
и вот в result есть массив result.ops. Что в нем храниться и как найти это в документации?
yopp
Подозреваю что https://docs.mongodb.com/manual/reference/command/insert/#output
yopp
Ой, https://docs.mongodb.com/manual/reference/command/insert/#insert.writeErrors
VSH
yopp
VSH
yopp
Tsikhan
Всем привет! подскажите пожалуйста, как увеличить время таймаута хелсчеков участников репликации друг другом? по дефолту стоит 10 секунд.
проблема заключается в том, что когда есть небольшая задержка сети (12-14 секунд) мастер отдает роль PRIMARY слейву
Denis 災 nobody
"небольшая"...
Tsikhan
это бывает раз 5 в день, и не хочется видеть эти качели
Denis 災 nobody
настроить сеть? Или хотя бы QoS? )
yopp
это бывает раз 5 в день, и не хочется видеть эти качели
https://docs.mongodb.com/manual/reference/replica-configuration/#rsconf.settings.heartbeatTimeoutSecs
Tsikhan
@dd_bb Спасибо большое!
Tsikhan
уже проверено, точно сеть
Андрей
подскажите как правильно надо записать запрос
Андрей
Андрей
Андрей
попробовал по другому
Андрей
теперь другая ошибка
Gopneg
пасанчики, а можно в одном квери сделать insert и find сразу? чтобы заинсертило и курсор вернуло
yopp
нет
yopp
можно сделать findAndModify
yopp
с upsert
yopp
но он тоже не вернёт курсор, но может вернуть получившийся в результате документ
Gopneg
спасибо
Denis 災 nobody
/report
Dezmunt
Может ли монго чекать поле с датой, и при наступлении конкретного времени оповещать слушателей? Или только долбить каждую секунду БД чтобы проверять время?
Vladimir
Может ли монго чекать поле с датой, и при наступлении конкретного времени оповещать слушателей? Или только долбить каждую секунду БД чтобы проверять время?
монга так не может емнип.
Но и долбить каждую секунду поле не нужно - один раз запросить и потом подписаться на change streams
Vladimir
точнее лучше наоборот, чначала подписаться, а потом запросить, на случай если она изменится в этот промежуток
Dezmunt
Так поле меняться не будет
Dezmunt
точнее лучше наоборот, чначала подписаться, а потом запросить, на случай если она изменится в этот промежуток
Я хотел сверять время в поле с временем сервера
Vladimir
если можно со своим сверять
Dezmunt
Уведомление по времени из бд
Dezmunt
Типа напоминалки
Назар
если нода то можно использовать node-schedule или другой cron
Vladimir
нет, зачем сверять с временем сервера БД, если можно просто сверять со своим временем. Ну или просто подождать <Время в базе> - <Текущее время>
Dezmunt
нет, зачем сверять с временем сервера БД, если можно просто сверять со своим временем. Ну или просто подождать <Время в базе> - <Текущее время>
Опишу чуть логики. Пользователь указал дату и время когда ему напомнить информацию. Эта запись попала в БД. Запись не изменится. Приложение будет крутиться на сервере с UTC временем, и вот мне надо как то это время, сверять с записью в БД, чтобы когда наступило соответствие, например когда серверное время больше либо равное времени из поля БД я мог запустить соответствующую логику
Vladimir
Опишу чуть логики. Пользователь указал дату и время когда ему напомнить информацию. Эта запись попала в БД. Запись не изменится. Приложение будет крутиться на сервере с UTC временем, и вот мне надо как то это время, сверять с записью в БД, чтобы когда наступило соответствие, например когда серверное время больше либо равное времени из поля БД я мог запустить соответствующую логику
ну вот, один раз получаешь время. делаешь поправку на часовой пояс, если нужно, сохраняешь себе где-то и ждешь нужного момента удобным тебе способом. для этого не нужно постоянно долбить базу, только один запрос
Dezmunt
yopp
Опишу чуть логики. Пользователь указал дату и время когда ему напомнить информацию. Эта запись попала в БД. Запись не изменится. Приложение будет крутиться на сервере с UTC временем, и вот мне надо как то это время, сверять с записью в БД, чтобы когда наступило соответствие, например когда серверное время больше либо равное времени из поля БД я мог запустить соответствующую логику
Нет, в монге нет механизмов для подобного. Возможно, можно попробовать соорудить что-то на change stream и ttl индексах, но это не надежно.
Быстрее и надёжнее сделать периодическую фоновую задачу, которая будет выбирать документы у которых какой-то атрибут с датой стал меньше чем текущее время и дальше по этим документам совершать какие-то действия
yopp
Скорее всего для вашего языка уже есть уже какой-то готовый инструмент, который эту задачу решает.
Ilya
Всем привет, делаю некий аналог трекера задач
Имею коллекцию юзеров, коллекцию проектов и коллекцию самих задач с привязкой к юзеру и проекту
Сейчас хочу добавить функционал добавления времени к задаче (при этом время может внести любой пользователь)
Хотел сначала хранить время прямо в модели задачи, но потом подумал что скорее всего сбор статистики (время по проекту, время по юзеру ) будет слишком медленным.
Поэтому сделал ещё одну коллекцию где есть привязка к проекту, задаче, юзеру и соответственно время. Но это похоже на подход который используется в реляцилнных бд.
Вопрос собственно вот в чем: этот вариант имеет право на жизнь? Или все таки хранить время лучше прямо в задаче?
Александр
А почему медленно должно быть если время рядом с задачей?
Ilya
если бы у задачи нельзя было бы менять исполнителя, и кроме него никто бы не писал туда время то да - идеальный вариант, а тут мне нужно будет для отчетов лезть во все задачи и смотреть есть ли время юзера там
yopp
сделайте индекс
Александр
не успел )
yopp
у вас есть натуральные бакеты, это очень хорошо
Веселый Роджер
Ilya
@dd_bb а индекс по какому полю?
yopp
условно time_logs.user_id
Ilya
тоесть примерно будет выглядеть вот так:
{
projectId: ,
userId: ,
times: [{userId: , comment: , time}, {userId: , comment: , time}]
}
Ilya
правильно понимаю?
yopp
если у вас time_logs: [{_id: OID, user_id: OID, started_at: Date, finished_at: Date, duration_seconds: Number}]
Ilya
круто, спасибо
Ilya
а вариант с отдельной коллекцией получается совсем неверный?
yopp
нет «верный» или «не верный» :)
Ilya
блин, мне просто казалось что если я буду лезть внутрь массива, то это будет долго
yopp
искать документ дольше чем его обрабатывать
yopp
единственный момент: вам потребуется фильтровать массив, когда будете строить статистику
Ilya
блин не укладывается у меня в голове:)
если у меня будет 1000 задач и в ней будет по 10 записей о времени, это будет реально работать быстрее чем 10000 записей без вложенностей?
yopp
так как вам в большинстве случаев время нужно вместе с задачей, то да
yopp
в случаях когда вам надо будет строить статистику, вы экономите на размере индекса
yopp
т.е. вместо 10к записей, у вас будет 1000
yopp
точнее не 1000, а по числу пользователей
yopp
минус, что когда вы будете строить статистику, вы будете читать какое-то количество лишних данных, которые уберёте фильтром
Ilya
черт, не понимаю :D туповат я :) не понимаю как я могу отфильтровать их
Ilya
если они будут в отдельной коллекции - типо все просто
Александр
в агрегации $match, $unwind, $match
Ilya
если бы фильтровать задачи у который userId совпадает с текущим - да
но если чел поставил в задаче время и перевел на другого чела, то блин не понимаю как это работает
Александр
ИД того кто поставил Вы же тоже записываете?