Автоматическое приращение в MongoDB для хранения последовательности уникального идентификатора пользователя

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

Мне нужно дать каждому уникальному идентификатору пользователя автоматический идентификатор приращения, чтобы отметить точку данных аналитики в bitarray / bitset. Таким образом, первые встречи пользователей будут соответствовать первому биту bitarray, второй пользователь будет вторым битом в bitarray и т. д.

Итак, есть надежный и быстрый способ генерировать инкрементные уникальные идентификаторы пользователей в В MongoDB?

4 ответов


вы можете, но вы не должны http://www.mongodb.org/display/DOCS/How + to + Make+an + Auto + Incrementing + поле

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


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

но я категорически не согласен с мнением, что вы не должны этого делать. Все зависит от потребностей вашего бизнеса. Наличие 12-байтового идентификатора может быть очень ресурсоемким и вызвать значительные проблемы масштабируемости в будущем.

У меня есть подробный ответ здесь.


создать счетчики коллекция, которая будет отслеживать последнее значение последовательности для всех полей последовательности.

        db.createCollection("counters")

использовать следующий код, чтобы вставить этот документ последовательности в коллекцию -

    db.counters.insert({_id:"tid",sequence_value:0})

Создание Функции Javascript:

    function getNextSequenceValue(sequenceName){
        var sequenceDocument = db.counters.findAndModify({
        query:{_id: sequenceName },
        update: {$inc:{sequence_value:1}},
        new:true
          });
      return sequenceDocument.sequence_value;
      }

вставить два документа :

            db.products.insert({
           "_id":getNextSequenceValue("tid"),
           "product":"Samsung",
           "category":"mobiles"
             })


           db.products.insert({
            "_id":getNextSequenceValue("tid"),
            "product":"Samsung S3",
            "category":"mobiles"
              })

Вставляешь Документы:

            db.prodcuts.find()

выход

{ "параметр _id" : 1, "товар": "Samsung", "категория": "мобильные телефоны"}

{"_id": 2, "продукт": "Samsung S3", "категория":" мобильные телефоны"}


Это зависит от системы, которую вы строите, и конкретных бизнес-правил на месте.

Я создаю от умеренного до крупномасштабного CRM в MongoDb, C# (Backend API) и Angular (Frontend web app) и нашел ObjectId совершенно ужасным для использования в угловой маршрутизации для выбора конкретных объектов. То же самое с маршрутизацией контроллера API.

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

db.contacts.insert({
 "id":db.contacts.find().Count()+1,
 "name":"John Doe",
 "emails":[
    "john@doe.com",
    "john.doe@business.com"
 ],
 "phone":"555111322",
 "status":"Active"
});

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

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

следовательно, db.коллекция.находить.)(Count ()+1-идеальное решение для меня...

Он не будет работать для всех, но если вы не будете удалять данных, он отлично работает.