1

過去にNoSQLデータベースの抽象化レイヤーの作成について質問がありましたが、それらは非常に異なるため、提供される機能のほとんどを見逃さずに実際に実現することはできませんでした。

これは最近、MicrosoftのAzure Table Storageとほぼ同じに見えるAmazonのDynamoDbの導入によって変更されたため、オープンソースの抽象化レイヤーを作成することを検討しています。抽象化は、雇用主にこれらの「新しい」テクノロジーを採用するように説得しようとするときに、より多くの力を与えるので、誰もが抽象化を愛しています。

私の知る限り

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

この抽象化レイヤーを作成することで、どのような問題が発生し、どのような機能が失われる可能性があるかを誰かが知ることができますか？

どちらも同じようにデータを分割しているように見え、クエリは似ています。

私が最初に気付いたのは、Microsoftのc＃SDKではクラスの派生元が必要でTableServiceEntityあるのに対し、Amazonのc＃オブジェクト永続化フレームワークではプロパティの属性が使用されているHashKeyことRangeKeyです。

4

1 に答える 1

1

Windows Azure テーブル ストレージと Amazon DynamoDBの比較 で比較を検討しているときに、正確に何を抽象化しようとしているのかを自問しました。
それを自問し、クラスと制限を作成するときに選択したトレードオフを提示して、コミュニティが何を達成しようとしているのかをよく理解し、うまくいけばそれを完成させるのに役立つようにする必要があります.
そうは言っても、頭のてっぺんから、理解すべきいくつかの質問を提起します
。 1. オブジェクトのサイズの違いをどのように強制しますか? (1MB / 64KB)
2. DynamoDB のプロビジョニングされたスループットをどのように抽象化しますか?
3. Azure Table Storage の 256 属性制限をどのように強制しますか?

幸運を

于 2012-05-09T09:59:37.887 に答える