[SERVER-195] AutoIncrement IDs Created: 29/Jul/09  Updated: 20/Dec/22  Resolved: 17/Oct/09

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Diego Sana Assignee: Eliot Horowitz (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Case:

 Description   

I'd like to have an autoincrement functionality that automatically assings sequencial integers as the "_id" when inserting new documents in a collection. This is the only thing stopping me from completely moving away of myql to mongodb.



 Comments   
Comment by Tom Wardrop [ 16/Jul/11 ]

This definitely needs to be looked at again. While not always a requirement, sometimes have an incremental, or otherwise short and human friendly index is a requirement. There are ways to implement Auto-Increment manually, by given how common the requirement is, wouldn't it make sense to build this into MongoDB. Who care's if it's slow, as often custom solutions are pretty damn slow too; but it doesn't matter that much if your collection is read-heavy (such as for a blog, orders on an online shop, products, etc). Also, not everyone uses sharding. Believe it or not, some people use Mongo not because of its performance, but simply because it's document orientated. I do wish tickets like these weren't dismissed without proper reasoning or a fair debate.

Comment by Shimon Doodkin [ 21/Jan/11 ]

it looks like that Auto Increment id could be a type of active index

Comment by Paul Okopny [ 14/Oct/10 ]

To Eliot:
Autoincrement field is really needed to sort the documents easily and to get a human-friendly IDs. Sometimes it can a very important feature. DB-users should decide by themselfs if they do need autoincrement and if they can afford the whole system to be very slow. Thought I do really doubt it would that much affect the speed. I guess there are ways to solve the speed problems.

Comment by Scott Hernandez (Inactive) [ 30/Mar/10 ]

Size matters, but sharding is more important. I'd like auto-incrementing numbers too but not at the cost of sharding.

Also, if size is the real issue it seems like some kinds of optimization with key-names is more important than the difference between 8/12 bytes. For example, if I am storing objects where I might have a millions (or billions) of documents with 15-40 key-value pairs of ints (32bit values) then the overhead of storing the key-name in each document becomes significant. For every key-value pair there may be 3-8 charaters (8-chars (8-bit) = 64bits) + 1 int (32bit) which makes the key-name twice as big as the data. Anyway, you see where I'm going...

Comment by Eliot Horowitz (Inactive) [ 29/Jul/09 ]

so, my general feelings:

  • int auto increment is to small these days
  • long is 8 bytes
  • ObjectId is 12, so not too much bigger
  • with ObjectId you can get sharding, which is more beneficial

What are your thoughts on these?

Comment by Diego Sana [ 29/Jul/09 ]

Eliot: faster lookups and, mainly, data size. Many of my collections contain millions of documents that store basicly a lot of _ids of others documents, so _id size matters a lot.

Comment by Eliot Horowitz (Inactive) [ 29/Jul/09 ]

the problem with auto increment ids is that it doesn't work in a sharded environment. you would have to synchronize across machines, which would make it very slow.

why do you need this rather that a guid (like ObjectId)?

Generated at Thu Feb 08 02:53:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.