CODEWITHSUNDEEP
azure-cosmosdbazure-cosmosdb-sqlapi
andrew
andrew

Reputation: 1260

Modeling document data and query performance

I have an aggerate data model (think a Customer entity with Widgets that belong to them as a list of embedded entities).

When I search for customers (e.g DocumentDBRepository.GetItemsAsync) That will be hydrating the customer data model along with the widgets for each. For efficiency reasons, I don’t really need the customer search to consider the widgets.

Are there any strategies for this in document dbs (such as a “LiteCustomer” entity)? I suspect not as that is just the nature of the “schema-less” data I’ve told it to store in the first place, but interested to hear thoughts.

Is this simply a ‘non issue’?

Upvotes: 0

Views: 52

Answers (1)

Imre Pühvel
Imre Pühvel

Reputation: 4994

First, disclaimer: data modeling is hard. There are many nuances and a SO question can never cover entire business and everything left unsaid in both Q and A. There's no silver bullets. Regardless..

"LiteCustomer"

Perfectly fine to have such model in your client code. Your main Customer model may and will have many representations, most of them simple subsets of full model. Similarly to relational sql, select only what you need. Don't fetch data to client which you don't need.

The SQL API provides quite cool SQL tools to compose json for return documents for you.

physical storage model may differ from domain model

Consider your usage scenarios. If many scenarios happen to work with customer without widgets (or vice versa) then consider having widgets as separate document(s) in storage model.

In DocDB, the question is often not so much in querying logic but what your application expects on modification logic. Querying which is indexed is fast and every sql query can easily do transformations (though cross-doc joining is troublesome). For C(R)UD - you have less options - it's always by full document. Having too large documents will end up with higher RU costs and complex code.

Questions to consider:

  • How often customer changes without widget count/details changing?
  • How often widgets change without customer changing?
  • Do widgets on customer change independently or always as a set?
  • When do you need transactional updates on customer+widget changes?
  • How would queries look like? Can they be indexed?

Test.

True, changing model later is cumbersome in DocDB, but don't try to fix something before you know it's broken. If you are not sure you have an issue or not, then most likely fixing the maybe-issue is costlier than not fixing it.

If in doubt, generate loads of data and test it out.

Upvotes: 2

Related Questions