Azure Table Storage(一) : 简单介绍 (2)

GPS的设备Id作为PartitionKey, 然后时间是RowKey, 那么我要查这个GPS信息时候大概率可以通过 “对PartitionKey进行点查询(where =)然后对RowKey进行范围查询(where <>)”的模式进行快速查找.


Table Storage怎么用:

我觉得作为一个软系的程序员, 每当问到软家产品怎么用的时候,我总是会说出: docs.microsoft.com

别人写的比绝大多数人写的都更加的专业.

我就不赘述了.

传送门: .Net SDK使用Table Storage 


另:

后面微软出的CosmosDb里也包含了一个Table Api

这个是和Azure Storage里的Table是兼容的, 两者的关系官方上有对比.

使用 Azure 表存储 API 和 Azure Cosmos DB 进行开发

image

简单挑几个我认为重点的区别说下:

CosmosDB的更贵,(每GB存储成本到2块多了),但是能保证性能(也有更快的性能)而且不再像Table那样只有PartitionKey和RowKey是索引, 它是全表索引.

反正就更隔壁家其他云的mongdb之类的差不多了, 只是API用的是同一套而已.

怎么选择看自己场景, 比如我前面说的日志是属于量大但是每个数据的价值相对较低的, 那么应该用Table, 但是如果你数据价值较高且对性能敏感的那么应该要用CosmosDb的.

还是那句话: 专业的地方找专业的解决方案, 每个地方尽量用上最合适的存储技术.

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wppgwz.html