hello

Посмотрим, сможет ли кто-нибудь помочь мне. У меня есть bbdd mongo, и я очистил поля внутри коллекции, а это значит, что у меня больше дискового пространства, но для этого я понимаю, что мне нужно сделать «компактную» коллекцию. Моя коллекция заняла 15 ГБ, а при чистке бинарных полей я уменьшил сбор до 8 ГБ. > показать dbs Mybbdd 19.944GB Но при создании компактного (Джобс - это коллекция из bdd): db.runCommand ({compact: 'Jobs'}) После окончания «компактного», а не перераспределения, доступным является дисковое пространство. Я потерял место! : ((((((( > показать dbs Mybbdd 29.939GB У моего альбома было 16% бесплатно (до компактности), и теперь у меня есть бесплатные 12% (после компактности) Что я делаю неправильно? Большое спасибо заранее

Это бага. Массивы в bson это хеши с ключами, где ключ индекс элемента. Ваш сериализатор при установке нецифрового ключа автоматически привёл массив к хешу, сохранив существующие элементы.

А в реальности должен был кинуть в вас исключением

И это не primary key.

В монге primary key это корневой атрибут _id

спасибо за пояснение!)

А можно ли пользоваться этой багой или лучше это реализовать по человечески?

Определенно не стоит

Посмотрим, сможет ли кто-нибудь помочь мне. У меня есть bbdd mongo, и я очистил поля внутри коллекции, а это значит, что у меня больше дискового пространства, но для этого я понимаю, что мне нужно сделать «компактную» коллекцию. Моя коллекция заняла 15 ГБ, а при чистке бинарных полей я уменьшил сбор до 8 ГБ. > показать dbs Mybbdd 19.944GB Но при создании компактного (Джобс - это коллекция из bdd): db.runCommand ({compact: 'Jobs'}) После окончания «компактного», а не перераспределения, доступным является дисковое пространство. Я потерял место! : ((((((( > показать dbs Mybbdd 29.939GB У моего альбома было 16% бесплатно (до компактности), и теперь у меня есть бесплатные 12% (после компактности) Что я делаю неправильно? Большое спасибо заранее

Javier, could you please ask your question in English. Autotranslate to Russian is disgusting.

We have group for english speaking users: @mongo_db

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

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

db.collection.update({}, {$set { 'field' : 'value' }})

db.collection.update({}, {$set { 'field' : 'value' }})

о, спасибо огромное

db.collection.update({}, {$set { 'field' : 'value' }})

только первому добавило поле, что-то не то WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })

м, пардоньте

db.collection.updateMany(

db.collection.updateMany(

благодарю, сработало

либо db.collection.update({}, {$set { 'field' : 'value' }}, {multi : true})

а подскажите такую штуку, есть Монго модель, там есть поле name: { type: String, required: true, minlength: 1, trim: true, index: true, unique: true }, но оно сохраняет дубликаты без вопросов, хотя раньше ругалось. Сохраняю командой let doc = new Doc(req.body) doc.save();

не очень знаком с моделями, к сожалению. по name есть индекс в коллекции? через db.collection.getIndexes() можно глянуть

не очень знаком с моделями, к сожалению. по name есть индекс в коллекции? через db.collection.getIndexes() можно глянуть

ага, есть. Там в моделе еще такое же поле с требованием уникальности но без индекса, его в индексах закономерно нет.

ага, есть. Там в моделе еще такое же поле с требованием уникальности но без индекса, его в индексах закономерно нет.

а, не, нету, это _id [ { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "dbname.docs" } ]

на стороне бд уникальность значений, насколько знаю, проверяется по индексу. если по полю индекс не построен с {unique : true}, то может и будет пропускать дубли

а, не, нету, это _id [ { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "dbname.docs" } ]

а он-таки не построен, да

а он-таки не построен, да

я даже не совсем понимаю, что такое индекс, я полагал это для быстрого поиска, если по полю часто ищешь

я даже не совсем понимаю, что такое индекс, я полагал это для быстрого поиска, если по полю часто ищешь

Это основное его назначение, да. Суть в том, что документ в монге хранится в bson и достаётся из хранилища при обработке запроса. Если, к примеру, запрос с условием по неиндексированному полю, то каждый документ достаётся и проверяется (так называемый collscan). Если по индексированному, то монга будет не доставать документы сразу, а проверять условие в некоем урезанном общем документе, где хранятся только значения индексируемого поля и _id-шники, по которому движок хранилища сразу лезет за подходящим файлом.

Это основное его назначение, да. Суть в том, что документ в монге хранится в bson и достаётся из хранилища при обработке запроса. Если, к примеру, запрос с условием по неиндексированному полю, то каждый документ достаётся и проверяется (так называемый collscan). Если по индексированному, то монга будет не доставать документы сразу, а проверять условие в некоем урезанном общем документе, где хранятся только значения индексируемого поля и _id-шники, по которому движок хранилища сразу лезет за подходящим файлом.

cпасибо большое, понял, что мне стоит это аккуратно настроить, ибо есть много таких операций, а по поводу сохранения неуникальных значений я кажется не оставил какой-то флаг при объявлении схемы, попробую эти способы: https://stackoverflow.com/questions/9024176/mongoose-duplicates-with-the-schema-key-unique#10167170

cпасибо большое, понял, что мне стоит это аккуратно настроить, ибо есть много таких операций, а по поводу сохранения неуникальных значений я кажется не оставил какой-то флаг при объявлении схемы, попробую эти способы: https://stackoverflow.com/questions/9024176/mongoose-duplicates-with-the-schema-key-unique#10167170

если не свезёт, то попробуйте просто руками индекс создать (: https://docs.mongodb.com/manual/reference/method/db.collection.createIndex/

если не свезёт, то попробуйте просто руками индекс создать (: https://docs.mongodb.com/manual/reference/method/db.collection.createIndex/

можете подсказать такое - часто ищу по полю с булевым значением, чтобы было true, в индексе указать 1 или -1?

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

ещё нюанс: индексы стоит выбирать таким образом, чтобы ваши запросы, попадая в них, сразу сильно ограничивались по числу перебираемых документов взять тот же индекс по дате: если у вас поиск документов с датой в диапазоне одного дня, а во всей коллекции документов за год, то монга оставит для перебора 1/365 всех документов

про булевые индексы: если в коллекции много документов, у которых булевое поле в true, то поиск документов с true будет неэффективен, их же всё равно много. а вот поиск документов с полем в false — да, эффективен, потому что отсекается бóльшая часть

короче, селективность это называется

про булевые индексы: если в коллекции много документов, у которых булевое поле в true, то поиск документов с true будет неэффективен, их же всё равно много. а вот поиск документов с полем в false — да, эффективен, потому что отсекается бóльшая часть

навернео, это как раз то, что мне нужно. У меня много false, а ищу true. Спасибо за ваши объяснения.

всем привет, подскажите пожалйста по монгус populate, не хочет работать

ка кправильно сохранять?

схема _id: Schema.Types.ObjectId, user: { type: Schema.Types.ObjectId, ref: User }

сохранаяю _id: new mongoose.Types.ObjectId(), user: user._id

в ответ приходит пустота Document.find({}).populate('user').exec((err, docs) => { res.send(docs); });

если получаю без populate() то нормально все возвращает

А структура какая документа?

А вижу

Ты уверен что тебе нужен populate? Что ты хочешь сделать?

Выборку без поля _id?

Если да то тебе нужно юзать projection

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

просто не очень понятно, при ref, эта самая ссылка должна быть в обеих моделях?

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

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

чтобы мне возвращался объект, но чтоб в одном из его элементов были доки из другой коллекции

грубо говоря нужна связь на доки в другой коллекции

как описано здесь https://mongoosejs.com/docs/populate.html

но что то повторить не могу

в параметре ref, укзываем коллекцию, как она называется в бд? или все же модель

чтобы мне возвращался объект, но чтоб в одном из его элементов были доки из другой коллекции

Я не в курсе монгуса, но ссылка на другой документ - это $lookup из aggregation фреймворка

спасибо, буду знать, но уже все на монгусе ((

спасибо, буду знать, но уже все на монгусе ((

а разве в могусе нет реализации aggragation фреймворка?

во http://excellencenodejsblog.com/mongoose-aggregation-count-group-match-project/

но это мне кажется выборки из одной коллекции, не?

но это мне кажется выборки из одной коллекции, не?

в этом примре, действительно нет lookup, но если есть аггрегешн, то и lookup есть

уууф, заработала))) всем спасибо! ? оказывается надо было в ref указывать имя коллекции, а я указывал имя модели ))

уууф, заработала))) всем спасибо! ? оказывается надо было в ref указывать имя коллекции, а я указывал имя модели ))

отлично, поздравляю!

Let's see if someone can help me. I do not know what to do. I have a bbdd mongo and I eliminated the fields within the collection, which means that I have more disk space, but I understand that I must make a 'compact' on the collection. My bbdd had 15 GB, and when I cleaned fields from a collection that I have called 'jobs', I reduced the collection to 8 GB. The bbdd really has the following busy: > show dbs Mybbdd 19.944GB Then I launched the 'compact' on my collection called 'Jobs': db.runCommand ({compact: 'Jobs'}) When finishing the 'compact', instead of having reorganized and recovered the cleaned space ... I lost disk space: (((( > show dbs Mybbdd 29.939GB My album had 16% available (before the compact), and now I have 12% available (after the compact) What am I doing wrong? Thank you very much in advance

Всем привет. Есть следующий кейс mongoose.model('stream', new mongoose.Schema({ user: { type: Object, required: true, }, viewers: { type: Array, index: true, }, }, { usePushEach: true, })); при попытке добавить stream.viewers.push({ created_at: Math.floor(Date.now() / 1000), user, }); Получаю ошибку: Error: cyclic dependency detected 0|london | at serializeObject Хотя в базе уже есть две зрителя: viewers: 0|london | [ { user: [Object], created_at: 1536923426 }, 0|london | { user: [Object], created_at: 1536923632 } ],

Как быть

?

Кто сталкивался с подобным в mongodb?

а что не так?

если типа изза ччего cyclic dependency detected, то скорее всего ровно то что написано в ошибке - циклическая зависимость, т.е. юзер сам у себя во вьюерах

Как правильно организовать хранение юзеров, у которых будут интересы и местоположения? Моя задача хорошо описана не мною здесь. В будущем нужно будет вытаскивать из базы юзеров из одного города с похожими интересами. Кто решал подобное? Как реализовывали? MySQL? :D

привет, можео заэмитить событие update без модификации документа, т.е просто чтобы создать ивент. Или может ивен можно создать отдельно?

Нет

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

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

точно, спасибо

Как правильно организовать хранение юзеров, у которых будут интересы и местоположения? Моя задача хорошо описана не мною здесь. В будущем нужно будет вытаскивать из базы юзеров из одного города с похожими интересами. Кто решал подобное? Как реализовывали? MySQL? :D

Если вы планируете какие-то гео-операции, например «ближайшие пользователи», то лучше хранить координату

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

Если вы планируете какие-то гео-операции, например «ближайшие пользователи», то лучше хранить координату

Так и будет.

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

Да, знаю, что в MongoDB есть встроенные функции. Интересует именно сохранение интересов и дальнейший вывод единомышленников юзера исходя из интересов. Нужно еще как-то учитывать язык интересов. Не до конца понимаю, как правильно огранизовать структуру коллекций.