Using or Not using auto-increment id

[Projapati]

I have 2 collections shown below:
groups:
{
{ _id: ObjectId(".."), <-- using object ids
name: "Group 1",
owner:"bob"
members:[1,2,3,4,5,6]
}
}

members:
{
{
id:1, <-- need auto increment id
name: "Tom",
email:"tom@..",
phone:
},
{
id:2,
name: "Tim",
email:"tim@..",
phone:"234234234"
}
}
}

I don't need to know the date when a group or member was created.
The contacts are shown in a grid & all contacts of a user read at
once.

I am planning to use auto-increment ids for contacts (by sequence
coll)

Shorter names for contact ids will reduce data goes over the wire and
storage I need for groups collection.

Will this prevent sharding when contacts collection has large entries?
Or there is a workaround for sharding with auto-inc ids?

By work around I meant to have synchronized sequencer or something.

[Sam Millman]

Since Mongo does not have this functionality built in (and for good reason) you are gonna have to make it yourself which would add bloat and weight on your client side code and will require you to house meta collections containing data about other collections in order to keep the speed up.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Scott Hernandez]

You can use your own ids (like an int) and it will not break sharding. The main issue is that if you use constantly incrementing ids (either ascending or descending) then new inserts are only going to one chunk/shard. You can read more about this here: http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

 

By work around I meant to have synchronized sequencer or something.

As Sam mentioned there is a cost to maintaining your own sequence numbers but if that is something you want to do there is no technical reason stopping you. It will limit scalability as you are essentially creating a single point of failure/bottleneck where you are maintaining the sequence values for each collection.

[Projapati]

I get the point. Auto inc ids are almost forbidden in mongo due to
scalability concerns.

[Scott Hernandez]

It is much easier to not have to talk to the db to create ids. There are many ways of doing that.

On Sun, Jun 5, 2011 at 9:55 AM, Projapati <mohamm...@gmail.com> wrote:

I get the point. Auto inc ids are almost forbidden in mongo due to
scalability concerns.

--

[chris anderton]

I may be being dense, but in the usage you've outlined why would you
*need* auto-incrementing id's?

They're not provided in mongo due to synchronisation complexity, but
some people do workaround it (e.g. http://shiflett.org/blog/2010/jul/auto-increment-with-mongodb)

[Projapati]

To reduce the amount or data I need to store and send over the wire.

If I send over 1000 contacts each having 24 chars ids vs each having
6/7 chars (digits) that is saving 1000*15=15K chars per page load.

But it adds headache at later stage.

[chris anderton]

In a way, but neither would be chars

An object id is a Bson value using 12 bytes

You incrementing id would be an integer of 8 bytes on a 64 bit
platform

On a 1000 records you may save 4000 bytes so not really a massive
problem..

[Projapati]

Thanks for pointing out the 64 bit thing.

[Scott Hernandez]

On Sun, Jun 5, 2011 at 4:14 PM, chris anderton <chris.a...@thewebfellas.com> wrote:

In a way, but neither would be chars

An object id is a Bson value using 12 bytes

You incrementing id would be an integer of 8 bytes on a 64 bit
platform

BSON has 32 and 64 bit signed integer values.

On a 1000 records you may save 4000 bytes so not really a massive
problem..

On Jun 5, 11:46 pm, Projapati <mohammad.m...@gmail.com> wrote:
> To reduce the amount or data I need to store and send over the wire.
>
> If I send over 1000 contacts each having 24 chars ids vs each having
> 6/7 chars (digits) that is saving 1000*15=15K chars per page load.
>
> But it adds headache at later stage.