Привет. такой возможности нет, но можно генерить id на клиенте, что-то вроде bson.NewObjectId()

Спасибо, именно так я и делаю

а вот кстати в драйвере от монги(компании), id таки будет возвращаться https://github.com/mongodb/mongo-go-driver/blob/f172d2723583a272b0b928134b79f5551e3129f5/mongo/results.go#L22

Привет. такой возможности нет, но можно генерить id на клиенте, что-то вроде bson.NewObjectId()

Дич! Иногда go поражает своими "особенностями"

Дич! Иногда go поражает своими "особенностями"

почему "дич"? я ничего плохого в генерации id на клиенте не вижу

почему "дич"? я ничего плохого в генерации id на клиенте не вижу

Особенно, учитывая,что upsert его возвращает ( https://godoc.org/launchpad.net/mgo/v2#Collection.Upsert ) А дич, потому что на мой взгляд логично, что БД возвращает итог операции. Для инсерта критические данные - это id, поэтому и сказал. Но возможно ошибаюсь...

почему "дич"? я ничего плохого в генерации id на клиенте не вижу

Если _id генерируется на клиенте, то клиент несёт ответственность за его уникальность. И это имеет значение в шардированных кластерах, если _id не является ключом шардирования.

В шардированной не по _id коллекции можно запросто получить несколько документов с одинаковым _id в разных шардах.

Особенно, учитывая,что upsert его возвращает ( https://godoc.org/launchpad.net/mgo/v2#Collection.Upsert ) А дич, потому что на мой взгляд логично, что БД возвращает итог операции. Для инсерта критические данные - это id, поэтому и сказал. Но возможно ошибаюсь...

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

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

Это накладывает требование генерации _id на стороне клиента, а не монги. Собственно клиентом является драйвер, и генерирует _id по-сути он

Это накладывает требование генерации _id на стороне клиента, а не монги. Собственно клиентом является драйвер, и генерирует _id по-сути он

Немного ошибся, монга просит, чтобы _id генерился клиентом, если его нет сгенерирует его сама

Вот из документации «MongoDB clients should add an _id field with a unique ObjectId» ObjectIds are small, likely unique, fast to generate, and ordered. ObjectId values consist of 12 bytes, where the first four bytes are a timestamp that reflect the ObjectId’s creation. Specifically: a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value.

Если _id генерируется на клиенте, то клиент несёт ответственность за его уникальность. И это имеет значение в шардированных кластерах, если _id не является ключом шардирования.

Никакой разницы в механизме генерации ObjectId нет. Никаких дополнительных проверок не производится. Вероятность коллизий в обоих случаях будет одинаковой.

Монга гарантирует порядок id. На клиенте, если у вас распределенная система - этого не добиться. Так что, про генерацию на клиенте - глупость.

Монга гарантирует порядок id. На клиенте, если у вас распределенная система - этого не добиться. Так что, про генерацию на клиенте - глупость.

Вы ошибаетесь. Монга гарантирует уникальность _id, исключительно потому по этому полю всегда создаётся уникальный индекс. Уникальность индекса никак не зависит от способа его генерации. Всё что делает монга, проверяет наличие атрибута _id и при его отсутствии генерирует ObjectId https://github.com/mongodb/mongo/blob/d337da259248c785f4014b565742300eb08ecd4f/src/mongo/db/ops/insert.cpp#L161

Всем привет! Была монга в stand alone, врубил репликацию и добавил инстанс rs.add(). Прикол в чем, на мастере и на слэйве одна и та же коллекция, в которую ничего нового не записывается, имеет разное число документов, если верить db.collName.count()

Это вообще законно?

подскажите кто работает с монгой на уии2 есть задача нужно выбрать из коллекции записи с максимальной датой сгруппированых по ид парента и потом отсеять записи с ненужным статусом делаю вот так $data = $collection->aggregate([ [ '$match' => ['user_id' => $owner], ], [ '$group' => [ '_id' => ['dialogue_id' => '$dialogue_id'], 'max' => ['$max' => '$created_at'] ], ], ]); получаю [ { "_id": { "dialogue_id": { "$oid": "5b5ff2c86784e9000772901a" } }, "max": { "$date": { "$numberLong": "1533041728000" } } }, ... }] собствено вопрос: как откинуть данные с ненужным статусом и как получить данные коллекции а не непонятно че)))??

Всем привет. Подскажите пожалуйста как можно получить колличество документов в коллекции.

db.collName.count()

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

db.collName.count()

Спасибо.

@ya_kostya ...монга просит, чтобы _id генерился клиентом, если его нет сгенерирует его сама Ну это меняет дело, тогда это не баг, а фича :) Да вот только, если БД сгенерила id сама, то почему бы его и не отдать в результате операции?

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

Если речь про агрегацию, то можно использовать стейдж project https://docs.mongodb.com/manual/reference/operator/aggregation/project/

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

Всем привет! Была монга в stand alone, врубил репликацию и добавил инстанс rs.add(). Прикол в чем, на мастере и на слэйве одна и та же коллекция, в которую ничего нового не записывается, имеет разное число документов, если верить db.collName.count()

А что говорит rs.status() ?https://docs.mongodb.com/manual/reference/method/rs.status/

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

и у меня на выходе 2 поля всего

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

я имею ввиду добавьте ещё один стейдж после группировки

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

я имею ввиду добавьте ещё один стейдж после группировки

еще раз project?

еще раз project?

да, он может повторяться

jy hf,jnftn njkmrj c ntvb gjkzvb rjnjhst dthyekf uheggbhjdrf

он работает с теми полями которые вернула группировка

он работает с теми полями которые вернула группировка

да, через группировку это поле нужно "протащить"

но тогда будут лишние записи

да, через группировку это поле нужно "протащить"

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

но тогда будут лишние записи

Лишние не берите, только те, которые вам нужны. Вот здесь подобную проблему решают https://stackoverflow.com/a/35177196/2733113

"parentId": { "$first": "$parentId"}

во возможно это то что мне нужно

спасибо большое

пойду пробовать

во возможно это то что мне нужно

да не за что :) только я б проверил сначала $push-ем какие именно поля вы отбрасываете, уместно ли применение $first

хорошо спасибо! щас почитаю что такое пуш) после sql както тяжковато для понимания)

Никакой разницы в механизме генерации ObjectId нет. Никаких дополнительных проверок не производится. Вероятность коллизий в обоих случаях будет одинаковой.

В теории, да, никакой разницы. Однако на практике, есть несколько "но". Во-первых, каждый драйвер может, в силу багов или ограниченности сознания разработчика, иметь своё видение уникальных ObjectId. Во-вторых, любой разработчик может сам формировать ObjectId для своих документов, минуя монгу и драйвер. Это про ответственность клиента за уникальность. В-третьих, кластер монги имеет больше технических возможностей из коробки, чтобы засинхронизировать machineId в ObjectId, реально гарантировав уникальность ObjectId в кластере. Никаких механизмов сейчас на стороне сервера нет. Есть некоторое подобие, _checkOIDs в балансере, но он может помочь только с теми ObjectId, которые генерируются на mongod, а не на mongos. Есть обещание уникальности в спеке: https://docs.mongodb.com/manual/reference/glossary/#term-id. С одинаковой вероятностью коллизий не соглашусь. Вероятность коллизий возрастает с ростом количества процессов, генерирующих _id. В больших кластерах процессов mongod и mongos обычно поменьше, чем клиентских процессов.

Вы ошибаетесь. Монга гарантирует уникальность _id, исключительно потому по этому полю всегда создаётся уникальный индекс. Уникальность индекса никак не зависит от способа его генерации. Всё что делает монга, проверяет наличие атрибута _id и при его отсутствии генерирует ObjectId https://github.com/mongodb/mongo/blob/d337da259248c785f4014b565742300eb08ecd4f/src/mongo/db/ops/insert.cpp#L161

Допишу еще к предыдущему оратору. Тут вот же еще какое дело. Если генерить на стороне клиента, то timestamp в ObjectId завернется клиентский. На разных тачках время может отличаться на несколько секунд. Можно начать записывать новые документы в прошлое. И это не редкий кейс, когда нужно гарантировать порядок id-шек. Разумеется, для этих целей можно использовать дополнительные поля с серверным (монго) timestamp. Но если порядок не важен и вообще пофигу какой тип у id, то тогда можно использовать какой-нибудь UUID и без проблем генерить на клиенте. Поправьте меня, если я ошибаюсь - в монге нет кластерных индексов, поэтому UUID с эффективным распределение порядка не нужен.

Всем привет. Коллеги случайно сделали db.orders.deleteMany({}), а бэкапов конечно же нет. Есть ли какая возможность восстановить данные?

хорошо спасибо! щас почитаю что такое пуш) после sql както тяжковато для понимания)

в пуше ничего сложного: он берёт все значения определённого поля из группы и делает из них список, который и возвращает. То есть предположим вы группируете по полю product. У вас получилось 3 продукта по 10 строк в каждом. Ещё вам нужно понять, какие страны у этих продуктов. Тогда делаете пуш и получаете список из стран каждого из 3 продуктов. Надеюсь, понятно :)

в пуше ничего сложного: он берёт все значения определённого поля из группы и делает из них список, который и возвращает. То есть предположим вы группируете по полю product. У вас получилось 3 продукта по 10 строк в каждом. Ещё вам нужно понять, какие страны у этих продуктов. Тогда делаете пуш и получаете список из стран каждого из 3 продуктов. Надеюсь, понятно :)

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

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

Да не за что. first - это странная штука. Если значения разные, он только введёт в заблуждения, если одинаковые - смысла в нём нет. Разве что сценарий "отсортировать о взять первый элемент"

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

в самой группировки сортировки я не нашел. поэтому сортирнул до

надеюсь это корректно будет

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

вроде бы да. В любом случае, использовать группировки, сортировки и т.п. в любом порядке и количестве - это нормально. Ещё посоветовал бы вам почитать про unwind https://docs.mongodb.com/manual/reference/operator/aggregation/unwind/ Он часто нужен в задачах, подобных вашей.

я читал но не оч понял что он делает))

Условно говоря превращает один документ с массивом в несколько документов равных количеству элементов в массиве

я читал но не оч понял что он делает))

тут опять же всё просто: из одного документа со списком делает несколько документов с каждым из элементов списка. Другие поля при этом повторяются

Типа каждый с каждым элементом массива

Точно :)

а ну у меня там списков вроде небыло)

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

вообщем это нужно пробывать чтобы понять))

а ну у меня там списков вроде небыло)

Список создастся пушем. Не в отдельные множества, а в отдельные элементы.

а ну да

впринципе понятно

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

вот тут пример наглядный https://docs.mongodb.com/manual/reference/operator/aggregation/unwind/#examples

вот тут вроде норм расписано https://habr.com/post/139643/

впринципе понятно

Ну и отлично!

спасибо вам большое)

вот тут вроде норм расписано https://habr.com/post/139643/

Спасибо. Хорошее описание.

@ya_kostya ...монга просит, чтобы _id генерился клиентом, если его нет сгенерирует его сама Ну это меняет дело, тогда это не баг, а фича :) Да вот только, если БД сгенерила id сама, то почему бы его и не отдать в результате операции?

Потому что она работает по принципу выстрелил и забыл

Вы сейчас на 880 человек транслируете свои ошибочные рассуждения. 0) Совершенно не важно что используется как значение _id. Есть сколько ограничений накладываемых уникальным индексом. Но кроме ObjectId может использоваться всё что угодно. Это никак не влияет на гарантии. 1) Нет никакого «видения уникальности». Есть спецификация генерации OID. Да, не все реализации соблюдают спецификации. Но см. п 0 2) Нет никакой отвественности клиента за уникальность. Уникальный индекс даёт одинаковые гарантии уникальности вне зависимости от того, какое значение и где оно появилось. 3) Никаких дополнительных «технических возможностей» в кластере нет. Есть архитектурные ограничения. Например в шардированном окружении может не быть гарантии уникальности _id. 4) Вероятность коллизии никак не меняется о того где и как генерируются идентификаторы

Допишу еще к предыдущему оратору. Тут вот же еще какое дело. Если генерить на стороне клиента, то timestamp в ObjectId завернется клиентский. На разных тачках время может отличаться на несколько секунд. Можно начать записывать новые документы в прошлое. И это не редкий кейс, когда нужно гарантировать порядок id-шек. Разумеется, для этих целей можно использовать дополнительные поля с серверным (монго) timestamp. Но если порядок не важен и вообще пофигу какой тип у id, то тогда можно использовать какой-нибудь UUID и без проблем генерить на клиенте. Поправьте меня, если я ошибаюсь - в монге нет кластерных индексов, поэтому UUID с эффективным распределение порядка не нужен.

Я вас на неделю в RO отправил.

Допишу еще к предыдущему оратору. Тут вот же еще какое дело. Если генерить на стороне клиента, то timestamp в ObjectId завернется клиентский. На разных тачках время может отличаться на несколько секунд. Можно начать записывать новые документы в прошлое. И это не редкий кейс, когда нужно гарантировать порядок id-шек. Разумеется, для этих целей можно использовать дополнительные поля с серверным (монго) timestamp. Но если порядок не важен и вообще пофигу какой тип у id, то тогда можно использовать какой-нибудь UUID и без проблем генерить на клиенте. Поправьте меня, если я ошибаюсь - в монге нет кластерных индексов, поэтому UUID с эффективным распределение порядка не нужен.

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

Привет! Не подскажите ли, как можно решить проблему, с ошибкой "can't take a write lock while out of disk space" не даёт ни удалять документы, ни апдейтить ни дропать. только поиск работает. админских прав к удалённому серверу нет. Наружу торчит только монга.

Всё, справились. Но если есть способ решить это из оболочки, то поделитесь)

Всё, справились. Но если есть способ решить это из оболочки, то поделитесь)

Никак, к сожалению.

добрый день коллеги, смотрите такой вопрос я делаю db.name.drop() удаляются ли также построенные индексы ?

или индексы остаются?

или индексы остаются?

Удаляются

Удаляются

да уже посмотрел

спасибо большое

А что говорит rs.status() ?https://docs.mongodb.com/manual/reference/method/rs.status/

/ 1 / { "set" : "mongodb", "date" : ISODate("2018-08-01T14:59:30.808+03:00"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "172.0.0.1:27019", "health" : 1.0, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 2345125, "optime" : Timestamp(1533124770, 492), "optimeDate" : ISODate("2018-08-01T14:59:30.000+03:00"), "electionTime" : Timestamp(1530779646, 1), "electionDate" : ISODate("2018-07-05T11:34:06.000+03:00"), "configVersion" : 3, "self" : true }, { "_id" : 1, "name" : "172.0.0.2:27019", "health" : 1.0, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 85714, "optime" : Timestamp(1533124769, 278), "optimeDate" : ISODate("2018-08-01T14:59:29.000+03:00"), "lastHeartbeat" : ISODate("2018-08-01T14:59:29.520+03:00"), "lastHeartbeatRecv" : ISODate("2018-08-01T14:59:29.094+03:00"), "pingMs" : 2, "syncingTo" : "172.0.0.1:27019", "configVersion" : 3 } ], "ok" : 1.0 }

Некоторые коллекции вроде среплицировались нормально, а в одной разница на 4к документов. Несколько сот миллионов всего

Может count() какие-то погрешности даёт, или реально на одной банке документов больше...

Может count() какие-то погрешности даёт, или реально на одной банке документов больше...

а можешь выполнить на мастере rs.printSlaveReplicationInfo() ?

а можешь выполнить на мастере rs.printSlaveReplicationInfo() ?

source: 172.0.0.1:27019 syncedTo: Wed Aug 01 2018 18:39:48 GMT+0300 (RTZ 2 (ceia)) 2 secs (0 hrs) behind the primary