Если документов не так много, вы можете попробовать собрать их массив поддокументов и дальше использовать $position

про это прочитал, но изменение позиции документов так реализовать будет невозможно

спасибо!

у документа нет позиции в коллекции

подскажите еще такой вопрос: как можно изменить поле с помощью $set, если заранее название поля неизвестно, но передается в функцию аргументов ?

Categories.update({ _id: id }, { $set: { field: value, }, }); то есть тут нужно изменить не поле field, а поле с названием из переменной field

судя по всему вот так: const setObject = {}; setObject[field] = value; Categories.update({ _id: id }, { $set: setObject, });

судя по всему вот так: const setObject = {}; setObject[field] = value; Categories.update({ _id: id }, { $set: setObject, });

Да, можно так, но нетипичная зада,а какая-то. Архитектуру не хотите сменить?

Да, можно так, но нетипичная зада,а какая-то. Архитектуру не хотите сменить?

А какой ещё выход, если нужно написать методы для изменения каждого поля (name, desc, path, color, size, owner)? Писать по методу на каждое поле это получается большое количество однотипных методов

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

А какой ещё выход, если нужно написать методы для изменения каждого поля (name, desc, path, color, size, owner)? Писать по методу на каждое поле это получается большое количество однотипных методов

Про методы не скажу, про вашу архитектуру мне ничего не известно. Но менять назания полей - нетипичично. Можно же сделать название нейтральное и менять валью.

Ребят, всем привет! А что за ересь, mongoose ругается в последней версии на: findAndModify, remove, update — что методы deprecated, и будт удалены. Есть предпосылки со стороны MongoDB?

Ребят, всем привет! А что за ересь, mongoose ругается в последней версии на: findAndModify, remove, update — что методы deprecated, и будт удалены. Есть предпосылки со стороны MongoDB?

Нашел: https://github.com/mongodb/specifications/blob/master/source/crud/crud.rst#motivation и https://github.com/Automattic/mongoose/issues/6880

Нашел: https://github.com/mongodb/specifications/blob/master/source/crud/crud.rst#motivation и https://github.com/Automattic/mongoose/issues/6880

Так ы итоге как у вас в js правильно теперь?

Ну ещё не правильно

Монгус раньше времени панику поднял. Пока в драйвере официальном не сделали все изменения. Как сделают да, все будет как по новой спеке, и старые методы отомрут

Так ы итоге как у вас в js правильно теперь?

updateOne и updateMany, например, вместо update deleteOne и deleteMany вместо remove

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

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

Дело

Про методы не скажу, про вашу архитектуру мне ничего не известно. Но менять назания полей - нетипичично. Можно же сделать название нейтральное и менять валью.

Я имею в виду, что нужно менять разные поля у документа. И то есть можно написать отдельный метод для изменения каждого поля и передавать ему значение поля, а можно написать единый метод для изменения документа и передавать ему как аргумент поле и значение. Для этого нужно уметь подставлять данные из аргумента в поле внутри $set

Или где я туплю?

Названия полей остаются неизменными

Я имею в виду, что нужно менять разные поля у документа. И то есть можно написать отдельный метод для изменения каждого поля и передавать ему значение поля, а можно написать единый метод для изменения документа и передавать ему как аргумент поле и значение. Для этого нужно уметь подставлять данные из аргумента в поле внутри $set

А если вам несколько полей поменять нужно, вы несколько update будете делать?

судя по всему вот так: const setObject = {}; setObject[field] = value; Categories.update({ _id: id }, { $set: setObject, });

Ну и всегда можно inplace синтаксис для es2015 объектов использовать, если вам хочется. Model.update({ _id }, { $set: { [field]: value } });

Ну и всегда можно inplace синтаксис для es2015 объектов использовать, если вам хочется. Model.update({ _id }, { $set: { [field]: value } });

Спасибо, то что искал

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

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

Чудес не бывает....

ну как то странно с чудесами. я вижу что упирается примерно в ядро.

а это довольно не то что я ожидаю увидеть

я конечно понимаю оплог и там всё такое но почему нельзя тащить коллекции в паралель тут логика пасует

лучший ответ — потому что не написали

Подскажите пожалуйста почему на такой коннект к монге const MongoClient = require('mongodb').MongoClient; const assert = require('assert'); // Connection URL const url = 'mongodb://localhost:27017'; MongoClient.connect(url, function(err, client) { if(!err) { console.log('connect'); } }); выдает такую ошибку, хотя по доке это вроде бы стандартный коннект DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect заранее спасибо

Монгус раньше времени панику поднял. Пока в драйвере официальном не сделали все изменения. Как сделают да, все будет как по новой спеке, и старые методы отомрут

Это и есть deprecation. Т.е. всех заранее предупреждают о грядущих изменениях.

я конечно понимаю оплог и там всё такое но почему нельзя тащить коллекции в паралель тут логика пасует

В 3.6 побыстрее стало

Но если хочется прямо очень быстро, то быстрее переноса снепшотов ничего не придумали

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

Подскажите пожалуйста почему на такой коннект к монге const MongoClient = require('mongodb').MongoClient; const assert = require('assert'); // Connection URL const url = 'mongodb://localhost:27017'; MongoClient.connect(url, function(err, client) { if(!err) { console.log('connect'); } }); выдает такую ошибку, хотя по доке это вроде бы стандартный коннект DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect заранее спасибо

Передайте объект опций и укажите что он хочет

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

Можно, например через нативный коннект и получить его из объекта mongoose. Можно Mixed тип использовать для отдельных полей документа и писать дичь туда. Вроде ещё можно через опции схемы сделать, но это не точно.

Можно, например через нативный коннект и получить его из объекта mongoose. Можно Mixed тип использовать для отдельных полей документа и писать дичь туда. Вроде ещё можно через опции схемы сделать, но это не точно.

Что-то типа нативного варианта и хочется. Спасибо, поищу в том направлении.

Передайте объект опций и укажите что он хочет

Делал, по таймауту падает через несколько секунд, хотя монга запущена в соседней вкладке

Делал, по таймауту падает через несколько секунд, хотя монга запущена в соседней вкладке

Ну то, что падает к предупреждению отношения не имеет

Почему падает сказать не могу

Все равно спасибо)

Делал, по таймауту падает через несколько секунд, хотя монга запущена в соседней вкладке

если по таймауту, то значит адрес не верно указан

првоеряйте корректность адреса

Подскажите пожалуйста почему на такой коннект к монге const MongoClient = require('mongodb').MongoClient; const assert = require('assert'); // Connection URL const url = 'mongodb://localhost:27017'; MongoClient.connect(url, function(err, client) { if(!err) { console.log('connect'); } }); выдает такую ошибку, хотя по доке это вроде бы стандартный коннект DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect заранее спасибо

гугл говорит что нужно просто доабвить опцию, как и писали выше MongoClient.connect(url, {useNewUrlParser: true}, function(err, client) {

Приветы Можете подсказать, есть ли человечий способ профайлингом найти не самые медленные запросы, а самые частые?

Приветы Можете подсказать, есть ли человечий способ профайлингом найти не самые медленные запросы, а самые частые?

https://www.vividcortex.com

В new relic тоже что-то на эту тему есть

New Relic очень сильно дорогой. Но классный, да

Можно на коленке, включив slowms: 0 и читать system.profile через tailable cursor

За вивид спасибо - гляну

вивид дороже ньюрелика

Можно на коленке, включив slowms: 0 и читать system.profile через tailable cursor

Да, я так и собирался делать, но надеялся что есть что-то вроде человечьего профайлера с распределением частоты запросов.

Ладно, и на том спасибо ?

https://github.com/mrsarm/mongotail

https://github.com/mrsarm/mongotail

интересная штука. Спасибо, гляну

https://github.com/mrsarm/mongotail

Спасибо, интересно глянуть :)

и вот https://github.com/heewa/mongotime

но у mongotime кажется нет возможности показать запрос

и ещё такой момент: из запроса желательно отфильтровывать значения, оставляя только ключи. очень часто бывает, что есть запросы, например «последние сообщения», которые не такие медленные чтоб попасть в профайлер, но их очень много и у них постоянно меняется ключ в запросе converstations.find({user_id: xyz}).sort({last_message_at: -1})

в таких запроса значения xyz или -1 лучше отбросить, ключи отсорировать и считать статистику по таким вот нормализованным отпечаткам, например сразу в нотации команд: {find: ‘conversations’, filter: {user_id: nil}, sort: {last_message_at: nil}}. очень часто, такие запросы и надо оптимизировать

ERROR: S client not available

Ну вот в общем да. У меня сейчас затык в том, что инстанс (он один, не бейте ногами), фризится иногда. Профайлер показывает что медленных запросов нет. Значит либо проблема ниже с дисковым IO (это потом будем изучать), либо летит жирная пачка мелких и коротких запросов. И исходя из того, как работает приложение, которое базу использует, скорее второе чем первое

начните с https://www.percona.com/software/database-tools/percona-monitoring-and-management

а, туда и query analytics завезли

ну вот и решение :)

https://pmmdemo.percona.com/graph/d/1Xwy8CKmz/_pmm-query-analytics?from=now-12h&to=now&orgId=1&var-host=mongocnf1wt&queryID=adcdc4d03a8376dc3c71f9079b7c3df1&type=mongo

Оно еще и бесплатное, чтоли ?)

начните с https://www.percona.com/software/database-tools/percona-monitoring-and-management

оооооооооооооо, сколько графичков!!! беру!!

Оно еще и бесплатное, чтоли ?)

да

оооооооооооооо, сколько графичков!!! беру!!

много графиков это _очень_ плохо

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

как кардиограмма

да

огонь ?

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

да я шучу :)

А существуют какие-то "нормальные" значения для количества одновременных команд в монге?

нет

Понятно, что от железа зависит.

вам стоит начать с понимания что такое «фриз»

это очень абстрактный симптом

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

вам стоит начать с понимания что такое «фриз»

а вот я и пытаюсь понять. api-сервер иногда залипает на минуты. Я по нему прошёлся профайлером - с ним всё в относительном порядке. Глянул после этого в бесплатный new relic - он говорит, что база отвечает очень долго в моменты залипания. Вот теперь пытаюсь понять, что в такие моменты происходит с базой. Печаль в том, что это происходит в разное время и в разных местах. Рабочие версии следующие: - приложение иногда извлекает больше данных чем нужно, но быстрыми маленькими запросам по id. Однако в некоторых случаях их может быть очень много. Соответственно если это так, то хотелось бы увидеть, что в базу ушла условная тысяча запросов вот такого "сорта". Ну и соответственно обратно идти в приложение, и делать так, чтобы запросов было меньше. Сразу идти нельзя, потому что таких потенциальных мест довольно много, и все их не поправить за раз. - что-то не так с дисковым IO. Такое уже было на амазоне у нас, но правда на инстансе поменьше. Но тогда всё было характерно видно на графиках. Сейчас - нет. А tls для хендшейка с базой не используется - база с приложением на одном инстансе стоят.

а вот я и пытаюсь понять. api-сервер иногда залипает на минуты. Я по нему прошёлся профайлером - с ним всё в относительном порядке. Глянул после этого в бесплатный new relic - он говорит, что база отвечает очень долго в моменты залипания. Вот теперь пытаюсь понять, что в такие моменты происходит с базой. Печаль в том, что это происходит в разное время и в разных местах. Рабочие версии следующие: - приложение иногда извлекает больше данных чем нужно, но быстрыми маленькими запросам по id. Однако в некоторых случаях их может быть очень много. Соответственно если это так, то хотелось бы увидеть, что в базу ушла условная тысяча запросов вот такого "сорта". Ну и соответственно обратно идти в приложение, и делать так, чтобы запросов было меньше. Сразу идти нельзя, потому что таких потенциальных мест довольно много, и все их не поправить за раз. - что-то не так с дисковым IO. Такое уже было на амазоне у нас, но правда на инстансе поменьше. Но тогда всё было характерно видно на графиках. Сейчас - нет. А tls для хендшейка с базой не используется - база с приложением на одном инстансе стоят.

У вас репликасет?

а вот я и пытаюсь понять. api-сервер иногда залипает на минуты. Я по нему прошёлся профайлером - с ним всё в относительном порядке. Глянул после этого в бесплатный new relic - он говорит, что база отвечает очень долго в моменты залипания. Вот теперь пытаюсь понять, что в такие моменты происходит с базой. Печаль в том, что это происходит в разное время и в разных местах. Рабочие версии следующие: - приложение иногда извлекает больше данных чем нужно, но быстрыми маленькими запросам по id. Однако в некоторых случаях их может быть очень много. Соответственно если это так, то хотелось бы увидеть, что в базу ушла условная тысяча запросов вот такого "сорта". Ну и соответственно обратно идти в приложение, и делать так, чтобы запросов было меньше. Сразу идти нельзя, потому что таких потенциальных мест довольно много, и все их не поправить за раз. - что-то не так с дисковым IO. Такое уже было на амазоне у нас, но правда на инстансе поменьше. Но тогда всё было характерно видно на графиках. Сейчас - нет. А tls для хендшейка с базой не используется - база с приложением на одном инстансе стоят.

начините с observability. это всё гадание на кофейной гуще, которое вас никуда не приведёт

собирайте метрики с инстанса и с сервера базы

смотрите что происходит в момент отказа

У вас репликасет?

Нет. Дело происходит на предрелизной платформе - там всё живёт в одном AWS инстансе

Нет. Дело происходит на предрелизной платформе - там всё живёт в одном AWS инстансе

Я бы еще посмотрел на пул коннекшенов, иногда фризится на стороне приложения — когда пропускной способности открытых коннектоы не хватает.

начините с observability. это всё гадание на кофейной гуще, которое вас никуда не приведёт

Есть хороший гайд с чего начать?

Я бы еще посмотрел на пул коннекшенов, иногда фризится на стороне приложения — когда пропускной способности открытых коннектоы не хватает.

да по идее тоже нет. Но как правильно заметил yopp , без метрик это и в самом деле гадание на кофейной гущи.

Есть хороший гайд с чего начать?

нет, нету