DynamoDb 和 Azure 表抽象层可能存在的问题？答案

【问题标题】：DynamoDb and Azure Table Abstraction layer possible issues?DynamoDb 和 Azure 表抽象层可能存在的问题？
【发布时间】：2012-04-13 14:48:45
【问题描述】：

questions in the past 关于为 NoSQL 数据库创建一个抽象层，但它们之间的差异如此之大，以至于如果不遗漏它们提供的大部分功能，这实际上是不可能的。

随着亚马逊 DynamoDb 的推出，这种情况最近发生了变化，它看起来几乎与微软的 Azure 表存储相同，所以我正在考虑制作一个开源抽象层。每个人都喜欢抽象，因为当我们试图说服我们的雇主接受这些“新技术”时，它为我们提供了更多的筹码。

据我所知

AzureTable.RowKey == DynamoDB.HashKey
AzureTable.PartitionKey == DynamoDB.RangeKey

谁能看到创建这个抽象层可能会出现什么问题以及我可能会失去什么功能？

两者似乎都以相同的方式对数据进行分区，并且它们的查询看起来相似。

我注意到的第一件事是，Microsoft 的 c# SDK 要求您的类从 TableServiceEntity 派生，而 Amazon 的 c# 对象持久性框架使用 HashKey 和 RangeKey 属性上的属性。

【问题讨论】：

你有没有着手构建这个抽象层，它是开源的吗？
我认为这不是一个好主意，很简单，因为 Azure Tables 是一个宽列存储，而 AWS DynamoDB 是一个文档存储。在这种情况下，您应该考虑 Azure Tables 与 AWS SimpleDB，或 AWS DynamoDB 与 Azure DocumentDB。
自 2012 年以来发生了很多变化。当时甚至不存在 Azure DocumentDB！

标签： c# nosql azure-table-storage amazon-dynamodb

【解决方案1】：

在查看这里的比较时：Comparing Windows Azure Table Storage and Amazon DynamoDB，我问自己你到底想抽象什么。
您需要问自己，然后展示您在创建类和限制时选择的权衡，以便社区对您想要实现的目标有一个很好的了解，并希望能帮助您完善它。
话虽如此，但我还是想提出几个问题，你应该弄清楚：
1. 你将如何强制改变对象大小？ (1MB / 64KB)
2. 您将如何抽象 DynamoDB 的预置吞吐量？
3. 你打算如何强制 Azure 表存储的 256 属性限制？

祝你好运

【讨论】：

理想情况下，我希望能够部署到 Azure 或 Amazon EC2 而无需重构任何代码。我的雇主更有可能接受我们不局限于特定供应商的解决方案。
在我看来，使用 DynamoDB 的项目需要大量的应用程序代码才能有效地使用它。DB 层中的抽象似乎有点多余