Currently the sole database backend service implementation is Azure Cosmos DB. This has some implications on the design of other components:
- Partition Keys: Cosmos DB uses a partition key (a secondary non-unique identification component) which azure's servers use to scope queries to smaller sections of the database.
- For most tables these partition keys are just a hash of the primary key.
- The message table is scoped by Channel Id as it allows scoping queries of messages constrained to a channel to be cheaper in RUs (and presumably also quicker).
- A custom attribute is used to mark properties on model types as the partition key
- Document Database: CosmosDB is a document database, which means it is designed to store unstructured data in the form of Json documents. This option has been used to some extent:
- Rather than having a table describing media embeds these descriptions are part of the references instead, forming an object
- The Form and Form Response tables store generic json in one of their fields
- Queries: CosmosDBs SQL dialect (Transact SQL) has some unique filters. Some queries would have to be rewritten for other database implementations.
Any resource maintained by the server at this time is referred to by a unique Id, which is a sequence of 64 bits. This Id can be spotted in the Clients user interface at various locations, formatted as a hexadecimal byte array in brackets (example [90105aaa8e3fb656]). This scheme was chosen for being just long enough to make collisions mathematically very unlikely, yet remain easily equatable and identifiable by a human reader. At this time, Ids are generated by C#'s default random number generator. The limits article has some further notes on the consequences of the id scheme chosen.