[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: | (copied to CRM) |
| 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: |
| 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:
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)? |