Document DB discovery

DocDB is ideal for fast appends and reads, but not so good on updates.

(I also found a few weeks ago when if a document is revised several times the change feed will only ever point at the most recent version and not the historical versions! Luckily our Event Store is an append-only store so this is not a problem).

When a document is updated the whole document is replaced as the record is immutable. Fields are not updated in-place. MS recommend if you have large documents doing high volume updates then you break the document down into the immutable section and the updated section. Or if you have high-volume updates have smaller documents. Reduce the indexing.

The fastest and cheapest way to access a document is by its ID rather than querying. The exception is when you don’t know whether you have it – and you do this frequently. In this scenario a missing document results in a 404 Not Found and an SDK exception which is costly to the calling client’s CPU. Frequent 404s will result in reduced client throughput.

The .NET core SDK differs from .NET standard in that it cannot support the Direct TCP mode (for interoperability). You are forced to use HTTP connections and thus it may be 1ms slower in normal use cases compared to direct [and self-managed] TCP connections.

Expensive operations such as querying for a document and not specifying a partition key can result in a fanout operation. The SDK will normally prevent this but you can specify a parameter to override it.