Использую монгу в связке с mongoose. Проблема следующая, при извлечении пользователя по _id некоторые пользователи извлекаются быстро , некоторые медленно , подскажите в какую сторону копать?

Заметил что недавно добавленные пользователи находятся быстро, а старые медленно

да вот запрос let user = await User.findOne({_id:user_id}).exec();

пробовал, не помогло

Можно ли шардировать коллекции по элементу в массиве?

я пробовал findById но проблема осталась, старые пользователи ищутся медленней Если недавно добавленный находится за 0,060 с, то старый 1 сек, В базе около 300 записей

Например { _id: '8192471', set: [ { token: '123' }, { token: '345' } ] }, { _id: '8192472', set: [ { token: '789' } ] }

На поле token есть индекс

Можно ли шардировать коллекцию по нему?

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

Использую монгу в связке с mongoose. Проблема следующая, при извлечении пользователя по _id некоторые пользователи извлекаются быстро , некоторые медленно , подскажите в какую сторону копать?

в сторону SSD дисков и увеличения оперативы

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

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

да, но у него всего 300 записей в базе. Не может быть, что б в память не влезло

если они тянутся редко - то легко могут улететь на диск

и мы не знаем еще какая стурктура у юзера, может он 10 метров там весит

опять же индексы так же могут быть свопнуты на диск

и мы не знаем еще какая стурктура у юзера, может он 10 метров там весит

@vosyukov не плохо бы узнать

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

@vosyukov не плохо бы узнать

~ 2 килобайта

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

попробую

ага, точно! хороший тест. Я вот только не могу себе представить, что б запрос к коллекции в 300 документов занимал секунду

если диски выбиты по IO то изи

опять же - дешевый хостинг не честно выделяющий io или вообще подрезающий

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

@vosyukov Всё вам на заметку :)

может в сети дроп пакетов 90% и слава богу что вообще хоть чтото отвечает

может в сети дроп пакетов 90% и слава богу что вообще хоть чтото отвечает

не, иногда же быстро отдаёт

так ведь и не 100% дроп)

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

так ведь и не 100% дроп)

тогда правльнее охарактеризовать дроп не "90%", а "периодически большой"

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

Привет) может кто подскажет в какую сторону смотреть, нужно найти друзей пользователя (их количество), друзей друзей пользователей (их количество) и вернуть в форме друзья: кол-во, друзья друзей: кол-во. Не понимаю как такое сделать, может рекурсией какой? Я представлял что-то вроде aggregate $match: $in: userid, $project: friends: $$root И далее не знаю

В какую сторону смотреть вообще, чтобы выполнить два раза $match и сформировать в ответ типа $match1: results, $match2: results

Хай товарищи монговоды , подскажите по админской части : Есть кубер в нем монга без реплика сета , сделал реплика сет (1 primary 2 secondary ). Реплика сет при старте поднимается чистый, без данных , я с помощью mognorestore раскатываю дамп на primary ноде , насколько я корректно делаю и можно ли обойтись без этого ? У меня не получилось в кубере настроить PVC и реплика сет не видит старых данных или для реплики сета такое поведение нормально ?

и если накатывать дамп то правильно я понимаю что сначало поднимаем primary ноду > накатываем дамп на нее > затем только поднимаем secondary ноды ?

и если накатывать дамп то правильно я понимаю что сначало поднимаем primary ноду > накатываем дамп на нее > затем только поднимаем secondary ноды ?

Здесь последовательность не важна

Хай товарищи монговоды , подскажите по админской части : Есть кубер в нем монга без реплика сета , сделал реплика сет (1 primary 2 secondary ). Реплика сет при старте поднимается чистый, без данных , я с помощью mognorestore раскатываю дамп на primary ноде , насколько я корректно делаю и можно ли обойтись без этого ? У меня не получилось в кубере настроить PVC и реплика сет не видит старых данных или для реплики сета такое поведение нормально ?

Данные не должны теряться Инструкция здесь: https://docs.mongodb.com/manual/tutorial/deploy-replica-set/

Данные не должны теряться Инструкция здесь: https://docs.mongodb.com/manual/tutorial/deploy-replica-set/

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

какой аналог в mongo primary_key Auto increment? собственно не понимаю, как выглядит мало-мальски энтерпрайз БД, не тащятся же записи чисто по текстовым полям?

какой аналог в mongo primary_key Auto increment? собственно не понимаю, как выглядит мало-мальски энтерпрайз БД, не тащятся же записи чисто по текстовым полям?

Никакого. ObjectId оптимален для 99% задач

Можно руками, на атомарном inc, монотонно возрастающий счетчик сделать

ххмммм, окау, запилил я такой таблицу с видами сыров и делаю вывод юзеру: 5ba13f7fc22819d582b15eab | Голландский | 399 руб 5ba13f7fc225454a5211fca11| Российский | 500 руб 5ba13f7fc225454a5211f2222| Российский | 600 руб И тут произошел крах человечества и Российский за шесть драных соток (!!!!!) перестал существовать, и надо его удалить. Я как вижу в SQL: DETELE from cheese where id=5ba13f7fc225454a5211f2222 А в mongo не вижу, направьте То ли этот ужасный oid таскать, то ли в моем чердаке проблемы со структурами устройства мира (что вероятно!!!)

Простите, коллекцию :))

таблицы пусть в mysql живут

Да, таскать object id

Вы можете его с более высокой базой кодировать. Например в base63

Он будет визуально короче.

}{ммм

Хм

Спасибо за ответ)

ххмммм, окау, запилил я такой таблицу с видами сыров и делаю вывод юзеру: 5ba13f7fc22819d582b15eab | Голландский | 399 руб 5ba13f7fc225454a5211fca11| Российский | 500 руб 5ba13f7fc225454a5211f2222| Российский | 600 руб И тут произошел крах человечества и Российский за шесть драных соток (!!!!!) перестал существовать, и надо его удалить. Я как вижу в SQL: DETELE from cheese where id=5ba13f7fc225454a5211f2222 А в mongo не вижу, направьте То ли этот ужасный oid таскать, то ли в моем чердаке проблемы со структурами устройства мира (что вероятно!!!)

В теории, можете и не «таскать». Вы же сами говорите: пропал Российский за 600 рублей, вот и удаляйте {name: "Российский", price: "600 руб"}

В теории, можете и не «таскать». Вы же сами говорите: пропал Российский за 600 рублей, вот и удаляйте {name: "Российский", price: "600 руб"}

Хммм, у меня нет большого опыта, вот родился вопрос: при работе клиентского приложения не произойдет каких косяков?

Хотя в принципе...эти данные достаточно определяют уникальность элемента...

Верно?

Даж если будет два сыра Российских по 600... тогда разные производители... ведь не бывает, что полностью одинаковые сущности с разным oid

?

Бывает и так. Зависит от бизнес логики.

Верно?

Именно. Зачем притягивать синтетический идентификатор, если есть исчерпывающее определение без него?

хахха) у меня крутое ощущение как будто жил до этого дня и не знал а теперь увидел и прозрел

А где-нибудь можно глянуть примеры готовых mongo-баз (используемых в Ынтерпрайзе)

ну или просто в обиходе

Буду у компа, смогу дать несколько линков.

Буду у компа, смогу дать несколько линков.

Буду премного благодарен еще сам погляжу сейчас

Именно. Зачем притягивать синтетический идентификатор, если есть исчерпывающее определение без него?

Синтетический id нужен для того, чтобы при изменении предметной области или бизнес-логики их было проще менять

Синтетический id нужен для того, чтобы при изменении предметной области или бизнес-логики их было проще менять

Ну если архитектура требует, то конечно.

Буду премного благодарен еще сам погляжу сейчас

Не знаю на сколько юзабельная, но реальная: https://s3.amazonaws.com/edu-downloads.10gen.com/enron/enron.zip Описание: Enron was an American corporation that engaged in a widespread accounting fraud and subsequently failed. In this dataset, each document is an email message. Like all Email messages, there is one sender but there can be multiple recipients.

Не знаю на сколько юзабельная, но реальная: https://s3.amazonaws.com/edu-downloads.10gen.com/enron/enron.zip Описание: Enron was an American corporation that engaged in a widespread accounting fraud and subsequently failed. In this dataset, each document is an email message. Like all Email messages, there is one sender but there can be multiple recipients.

Спасибо!

Как происходит апдейт на шардированной коллекции, если в условии не то поле, по которому шардировалась коллекция?

Есть где про это почитать может?

Как происходит апдейт на шардированной коллекции, если в условии не то поле, по которому шардировалась коллекция?

ну тут можно просто логически рассуждать.

Как происходит апдейт на шардированной коллекции, если в условии не то поле, по которому шардировалась коллекция?

Scatter/broadcast query и потом апдейт на том шарде, где нашлись данные

https://docs.mongodb.com/manual/core/distributed-queries/#write-operations-on-sharded-clusters

спасибо