[#SERVER-195] AutoIncrement IDs

Core Server

AutoIncrement IDs

Created: Jul 29 2009 07:41 AM UTC Updated: Mar 30 2010 04:48 PM UTC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

features we're not sure of

Description

« Hide

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.

All

Comments

Change History

git Commits

Sort Order:

[ Permalink | « Hide ]

Eliot Horowitz added a comment - Jul 29 2009 08:04 AM UTC

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)?

Eliot Horowitz made changes - Jul 29 2009 09:05 PM UTC

Field	Original Value	New Value
Issue Type	New Feature [ 2 ]	Question [ 6 ]

Eliot Horowitz made changes - Jul 29 2009 09:08 PM UTC

Fix Version/s

features we're not sure of [ 10016 ]

[ Permalink | « Hide ]

Diego Sana added a comment - Jul 29 2009 09:15 PM UTC

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.

[ Permalink | « Hide ]

Eliot Horowitz added a comment - Jul 29 2009 09:18 PM UTC

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?

Eliot Horowitz made changes - Oct 17 2009 10:18 AM UTC

Status	Open [ 1 ]	Closed [ 6 ]
Resolution		Won't Fix [ 2 ]

[ Permalink | « Hide ]

Scott Hernandez added a comment - Mar 30 2010 04:48 PM UTC

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...