MongoDb: Benefit of using ObjectID vs a string con

问题:

Is there any benefit to storing an id to a related document as an ObjectId versus storing it as a string literal?

Using ObjectID:

{
   "_id": ObjectId("522bb79455449d881b004d27"),
   "username": "admin",
   "folder": ObjectId("522bb79455449d881b004d23")
}

versus a string:

{
   "_id": ObjectId("522bb79455449d881b004d27"),
   "username": "admin",
   "folder": "522bb79455449d881b004d23"
}

For my API where I'm sending data back to a client... using the string means I don't have to "cleanup" the data... and as we have to do a second query to get the folder document anyway... is it worth using ObjectId? (and if so why?)

Thanks

回答1:

The biggest reason is that ObjectIDs are 12 bytes, whereas an equivalent string is 24 bytes. Over a large enough collection, those 12 bytes saved per ID really add up! Those IDs also mean fewer bytes transferred over the wire when reading or writing the document, as well.

Additionally, some ODMs expect ObjectIDs for external document references, and may be confused by string versions of the ID. I am not familiar enough with PHP ODMs to say if this might affect you specifically, though.

Regarding the API stuff, though, you should probably be doing normalization of the data before sending it to the client anyhow, because since Mongo doesn't enforce a schema, you can have literally any sort of data in a given field, so you might have some documents that have string IDs, and others that have BSON IDs, and your API would happily send them both through to the client, but one or the other might cause breakage. In this particular case, you should use BSON ObjectIDs in your documents, and then should cast them to strings in your API output.

回答2:

Briefly, for example, if you shorten the filed named last_name to lname , you could save 9 bytes per document. This really makes a difference if you have millions of documents in your collection.