-
Notifications
You must be signed in to change notification settings - Fork 33
Open
Milestone
Description
MongoDB mandates on having _id as the primary key. It is possible to store any unique keys of the document as _id to get primary index on it. But, if we need a composite key as our primary index key, the following are the options
- Use composite key as an object and
_idwould store the object- For example,
{ _id: {a: "hello", b: "world"}. This scheme allows queries with predicates with bothaandbpresent. But, we can't do queries onaalone. Also, range queries are not possible
- For example,
- Key using
ObjectIDfor_idand create a compound index on the composite key.- This scheme helps with range queries. But, it would be bad for performance as a query on the index would need two hops to get the actual document. And the primary index is a waste as we would never use it directly, only through secondary indexes.
- Serialize the composite key manually and provide serialized bytes as
_idvalue.- This solves all the problems. But, it could get a bit messy on application end, not just for inserts also for queries. Its pretty much what FDB Tuple do.
- Shard keys - This is probably the best way to use composite keys in MongoDB, but it would only work with sharded clusters. Although it is possible to use with Document Layer, semantics could be a bit confusing.
- If we decide to not go with shard keys, we can have our own custom command or custom fields part of
create_collection()to allow cluster key specification.
Metadata
Metadata
Assignees
Labels
No labels