Skip to content

Provide a way to define composite keys #153

Open
@apkar

Description

@apkar

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 both a and b present. But, we can't do queries on a alone. Also, range queries are not possible
  • 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions