Open
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
_id
would store the object- For example,
{ _id: {a: "hello", b: "world"}
. This scheme allows queries with predicates with botha
andb
present. But, we can't do queries ona
alone. Also, range queries are not possible
- For example,
- Key using
ObjectID
for_id
and 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
_id
value.- 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