DynamoDb 和 Azure 表抽象层可能存在的问题
本文关键字:存在 问题 Azure 抽象 DynamoDb | 更新日期: 2023-09-27 18:31:06
过去一直存在关于为NoSQL数据库创建抽象层的问题,但它们的差异如此之大,以至于如果不错过它们提供的大多数功能,就不可能真正实现。
最近随着亚马逊的DynamoDb的推出,这种情况发生了变化,它看起来与Microsoft的Azure表存储几乎相同,所以我正在考虑制作一个开源抽象层。每个人都喜欢抽象,因为它在试图说服我们的雇主接受这些"新"技术时给了我们更多的筹码。
据我所知
AzureTable.RowKey == DynamoDB.HashKey
AzureTable.PartitionKey == DynamoDB.RangeKey
任何人都可以看到创建此抽象层可能出现的问题以及我可能会失去哪些功能吗?
两者似乎以相同的方式对数据进行分区,并且它们的查询看起来相似。
我注意到的第一件事是,Microsoft的 c# SDK 要求你的类从TableServiceEntity
派生,而 Amazon 的 c# 对象持久性框架使用 HashKey
和 RangeKey
属性的属性。
在回顾这里的比较:比较Windows Azure Table Storage和Amazon DynamoDB时,我问自己,你到底想抽象什么。
你需要问问自己,然后提出你在创建类和约束时选择的权衡,以便社区对你想要实现的目标有一个很好的了解,并希望帮助你完善它。
话虽如此,我将从我的头顶上提出几个你应该弄清楚的问题:
1. 您将如何强制区分物体尺寸?(1MB/64KB)
2. 您将如何抽象 DynamoDB 的预置吞吐量?
3. 你将如何强制实施 Azure 表存储具有的 256 个属性限制?
祝你好运