Можливість створення двох копій Mongo ObjectId у двох різних колекціях?

Чи можливо для одного і того ж точного Mongo ObjectId генеруватися для документа у двох різних колекціях? Я усвідомлюю, що це, безумовно, дуже малоймовірно, але чи можливо це?

Не надто конкретно, тому я прошу, що за допомогою програми, над якою я працюю, ми показуємо загальнодоступні профілі обраних чиновників, яких ми сподіваємося перетворити на повноправних користувачів нашого сайту. У нас є окремі колекції для користувачів та обраних посадових осіб, які наразі не є членами нашого сайту. Існують різні інші документи, що містять різні відомості про обраних посадових осіб, які всі відображають особу, використовуючи обраний офіційний ObjectId.

Після створення облікового запису ми все ще виділяємо дані, пов’язані з обраним чиновником, але вони також є частиною колекції користувачів з відповідними користувачами ObjectId, щоб відобразити їх профіль на взаємодію з нашим додатком.

Ми почали конвертувати наш додаток з MySql в Монго кілька місяців тому, і поки ми переходимо, ми зберігаємо спадковий MySql id для обох цих типів даних, і ми також починаємо зберігати обраний офіційний Mongo ObjectId у користувачах документ для відображення обраних офіційних даних.

Я розмірковував, просто вказуючи нового користувача ObjectId як попереднього обраного офіційного ObjectId, щоб зробити його простішим, але хотів переконатися, що не вдалося зіткнутись з будь-яким наявним користувачем ObjectId.

Дякуємо за ваше розуміння.

Редагувати: Незабаром після публікації цього питання я зрозумів, що запропоноване нами рішення не дуже вдала ідея. Було б краще просто зберегти поточну схему, яку ми маємо, і просто посилання на обрану посадову особу '_id' в документі користувачів.

Коротка відповідь

Просто для додання прямої відповіді на ваше початкове запитання: Так, якщо ви використовуєте BSON Object ID-генерацію, то для більшості драйверів ідентифікатори майже напевно будуть унікальними для колекцій. Дивіться нижче, що означає «майже напевно».

Довга відповідь

Ідентифікатор об'єкта BSON, сформований драйверами DB Mongo, є великою ймовірністю бути унікальним у колекціях. Це головним чином через останні 3 байти ідентифікатора, які для більшості драйверів генеруються за допомогою статичного збільшення лічильника. Цей лічильник не залежить від колекції; це глобально. Наприклад, драйвер Java використовує випадково ініціалізований статичний AtomicInteger.

То чому, в документах Mongo, вони кажуть, що ідентифікатори "з великою ймовірністю" будуть унікальними, а не прямо говорять, що вони будуть унікальними? Три можливості можуть виникнути там, де ви не отримаєте унікальний ідентифікатор (будь ласка, повідомте мене, якщо їх більше):

Перед цим обговоренням нагадайте, що BSON Object ID складається з:

[4 байти секунди з епохи, 3 байти машинного хешу, 2 байти ідентифікатора процесу, 3 байтового лічильника]

Ось три можливості, тож ви самі судіть, наскільки ймовірно отримати дупа:

1) Переповнення лічильника: у лічильнику є 3 байти. Якщо вам вдається вставити понад 16 777 216 (2 ^ 24) документів за одну секунду, на тій же машині, в одному і тому ж процесі, ви можете переповнити байти збільшення лічильника і в кінцевому підсумку з двома ідентифікаторами об'єктів, які поділяють той самий час, машина , обробляти та лічити значення.

2) Лічильник непримноження: деякі водії Монго використовують випадкові числа замість збільшення чисел для лічильників байтів. У цих випадках є 1 / 16,777,216 шанс генерувати не унікальний ідентифікатор, але лише в тому випадку, якщо ці два ідентифікатори генеруються в одну і ту ж секунду (тобто до того, як розділ часу ідентифікатора оновиться на наступну секунду), на ту ж саму машина, в тому ж процесі.

3) Машина та обробка хеша до однакових значень. Значення ідентифікатора машини та ідентифікатора процесу можуть у деяких дуже малоймовірних сценаріях відображати однакові значення для двох різних машин. Якщо це відбувається, і в той же час два лічильника на двох різних машинах протягом однієї секунди генерують одне і те ж значення, тоді ви отримаєте повторюваний ідентифікатор.

Це три сценарії, на які слід стежити. Сценарії 1 та 3 здаються малоймовірними, а сценарій 2 цілком уникнути, якщо ви використовуєте правильний драйвер. Вам доведеться точно перевірити джерело драйвера.

ObjectIds генеруються на стороні клієнта таким чином, як у UUID, але з деякими приємнішими властивостями для зберігання в базі даних, наприклад, приблизно збільшуючи порядок та безкоштовно кодуючи час їх створення. Ключовим для вашого випадку використання є те, що вони створені для того, щоб гарантувати унікальність з високою ймовірністю, навіть якщо вони створюються на різних машинах.

Тепер якщо ви посилалися на поле _id взагалі, нам не потрібна унікальність для колекцій, тому безпечно повторно використовувати старий _id. Як конкретний приклад, якщо у вас є дві колекції, colorsі fruitsобидві можуть одночасно мати такий предмет {_id: 'orange'}.

Якщо ви хочете дізнатися більше про те, як створюються ObjectIds, ось специфікація: http://www.mongodb.org/display/DOCS/Object+IDs#ObjectIDs-BSONObjectIDSpecification

Якщо у когось виникають проблеми з дублікатами Mongo ObjectID, ви повинні знати, що незважаючи на ймовірність того, що дупи відбудуться в самому Монго, можливо, з дублікатом _id генерується з PHP в Монго.

Випадок використання, коли це сталося з регулярністю для мене, - це коли я перебираю набір даних і намагаюся ввести дані в колекцію.

Масив, який містить дані ін'єкції, повинен бути явно скинутий під час кожної ітерації - навіть якщо ви не вказуєте значення _id. З певних причин процес INSERT додає до масиву Mongo _id так, ніби це глобальна змінна (навіть якщо масив не має глобальної області застосування). Це може вплинути на вас, навіть якщо ви викликаєте вставку в окремому виклику функції, де зазвичай очікуєте, що значення масиву не зберігатимуться до функції виклику.

Для цього є три рішення:

1. unset()Поле _id можна використовувати з масиву
2. Ви можете повторно ініціалізувати весь масив array()кожного разу, коли ви перебираєте свій набір даних
3. Ви можете чітко визначити значення _id самостійно (подбаючи про те, щоб визначити його таким чином, щоб ви самі не створювали дублі).

Я здогадуюсь, що це помилка в інтерфейсі PHP, і це не стільки проблема з Mongo, але якщо ви зіткнулися з цією проблемою, просто вимкніть _id і вам слід добре.

Про унікальність ObjectId у колекціях немає жодної гарантії. Навіть якщо це ймовірно дуже малоймовірно, це був би дуже поганий дизайн програми, який спирався на унікальність _id у колекціях.

Можна легко перевірити це в оболонці монго:

MongoDB shell version: 1.6.5
connecting to: test
> db.foo.insert({_id: 'abc'})
> db.bar.insert({_id: 'abc'})
> db.foo.find({_id: 'abc'})
{ "_id" : "abc" }
> db.bar.find({_id: 'abc'})
{ "_id" : "abc" }
> db.foo.insert({_id: 'abc', data:'xyz'})
E11000 duplicate key error index: test.foo.$_id_  dup key: { : "abc" }

Отже, абсолютно не покладайтеся на унікальність _id у колекціях, а оскільки ви не контролюєте функцію генерації ObjectId, не покладайтеся на неї.

Можна створити щось, що більше схоже на uuid, і якщо ви це зробите вручну, ви могли б отримати кращу гарантію унікальності.

Пам'ятайте, що ви можете розмістити предмети різних "типів" в одній колекції, так чому б просто не помістити свої дві "таблиці" в одну колекцію. Вони поділять той самий простір _id, і, таким чином, гарантується унікальність. Перехід від "перспективного" до "зареєстрованого" був би простим гортанням поля ...