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

已经有questions in the past关于为NoSQL数据库创建一个抽象层，但是它们有很大的不同，以至于不会错过它们提供的大多数功能。DynamoDb和Azure表抽象层可能存在的问题？

随着亚马逊的DynamoDb的推出，它最近发生了变化，它看起来几乎与微软的Azure Table Storage相同，所以我正在考虑开发一个开源抽象层。每个人都喜欢抽象，因为当我们试图说服雇主接受这些'新'技术时，它给了我们更多的杠杆作用。

至于我可以告诉

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

任何人都可以看到可能出现什么问题，我可以通过创建这个抽象层失去什么功能？

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

我注意到的第一件事是，微软的C＃SDK需要你的类，而亚马逊的C＃对象持久化框架使用的HashKey和RangeKey性能属性从TableServiceEntity派生。

来源

2012-04-13 Tim

你是否开始构建这个抽象层，并且它是否可用开源？ – 2014-02-28 02:31:55

我不认为这是一个好主意，很简单，因为Azure Tables是一个宽列存储，而AWS DynamoDB是一个文档存储。在这种情况下，您应该考虑Azure表与AWS SimpleDB或AWS DynamoDB与Azure DocumentDB。 – 2016-10-01 12:40:50

自2012年以来发生了很多变化。当时Azure DocumentDB甚至不存在！ – Tim 2016-10-06 13:50:41

虽然在这里回顾比较：Comparing Windows Azure Table Storage and Amazon DynamoDB，我问自己究竟是什么你想抽象。
你需要问自己，然后提出你在创建类和限制时选择的折衷方案，以便社区能够很好地了解你想要达到的目标，并希望能帮助你完善它。
话虽如此，从我的头顶我会提出一些问题，你应该弄清楚：
1.你将如何强制对象大小的差异？（1MB/64KB）
2.您将如何抽象DynamoDB的预置吞吐量？
3.您将如何强制限制Azure表存储的256个属性？

祝你好运

来源

2012-05-09 09:59:37

理想情况下，我希望能够部署到Azure或Amazon EC2，而不必重新考虑任何代码。我的雇主将更有可能接受一个解决方案，我们不会被锁定到某个特定的供应商。 – Tim 2012-05-09 14:44:09

在我看来，使用DynamoDB的项目需要大量的应用程序代码才能有效地使用它。数据库层中的抽象似乎有点冗余 – 2012-05-09 17:37:14

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

回答

相关问题