As you probably know Table storage is basic NoSQL db option available in Azure. It is very cheap and used in many Azure components internally (e.g. in Azure functions or bots). From other side CosmosDB is powerful NoSQL db engine available in Azure which support several different APIs. You need to select this API when create CosmosDB instance and it can't be changed after that:
- Core (SQL)
- MondoDB
- Cassandra
- Azure Table
- Gremlin
I.e. if you have existing application which already uses Table storage - you may create CosmosDB with Azure Table API and switch to it without rewriting application code (although this is in theory. E.g. if you app targets .Net Framework you will most probably need to retarget it to .Net Standard or .Net Core. But this is topic of different post).
In our product we use Table storage and decided to compare performance of CosmosDB (with Azure table API) and native Table storage. For testing the following data was used:
- table with about 100K rows
- query against system PartitionKey field: PartitionKey eq {guid} (this is fast query itself because PartitionKey is indexed field)
- each query returned about 300 rows from overall 100K rows
- execution time was measured
Same test had been ran 10 times in order to get average execution time - for CosmosDB and Table storage separately. Here are results:
| Test run# | CosmosDB (msec) | Table storage (msec) |
| 1 | 3639 | 2825 |
| 2 | 3249 | 2008 |
| 3 | 3626 | 1613 |
| 4 | 3016 | 1813 |
| 5 | 2764 | 1942 |
| 6 | 2840 | 1713 |
| 7 | 4704 | 1776 |
| 8 | 2975 | 2036 |
| 9 | 3353 | 1808 |
| 10 | 2833 | 1699 |
| Avg (msec) | 3299.9 | 1923.3 |
I.e. average execution time for native Table storage was less than for CosmosDB with Azure Table API.
No comments:
Post a Comment