Some of the concepts in Azure Cosmos DB:
Additional insights can be found at How To Design And Query Data In Cosmos DB (c-sharpcorner.com)
Your default choice for new Azure Cosmos DB accounts should be Core (SQL). However, it would help if you also considered the following situations:
If your data is better represented in a graph, the Gremlin (graph) API might be a good choice.
If you already have an existing application or database using one of the other APIs, then the current API might be a better choice for your specific scenario. Using the current API might make it easier to:
You should only use the Azure Table API if you migrate from Azure Table Storage, as Core (SQL) offers far more features and flexibility.
Azure IoT Hub now supports the ability to setup an Azure Cosmos DB account as a custom routing endpoint. This will help route device data from IoT Hub to Azure Cosmos DB directly. The feature also allows the configuration of Synthetic Partition Keys for writing data into Azure Cosmos DB which helps in optimized querying when working with large-scale data.
Many IoT solutions require extensive downstream data analysis and pushing data into hyperscale databases. For example, IoT implementations in manufacturing and intelligent transport systems require hyperscale databases with extremely high throughput to process the continuous stream of data. Traditional SQL based relational databases cannot scale optimally and also become expensive once data scale increases. Azure Cosmos DB is best suited for such cases where the data needs to be analyzed while it is being written.
Materialized view provides the ability to create Apache Cassandra tables with different primary/partition keys. This reduces write latency for your source table since the service handles populating the materialized views automatically and asynchronously. Benefit from low latency point reads directly from the views and overall greater compatibility with native Apache Cassandra.