4

自分で作成したアプリケーションがあります。すべてがうまくいけば、大量のデータが生成される可能性があります。現在、MySQLデータベースを使用して情報を格納しており、クエリでINNER結合とLEFT結合を使用してデータをフィルタリングしています。とにかくdynamodbを試してみるつもりでしたが、次のデータ構造に適していると思われるのか、リレーショナルデータベースを使うべきなのかを聞いてみようと思いました。

たとえば、主キーとしてproject_idを持つプロジェクトテーブルがあるとします。これで、各「プロジェクト」に多数のユーザーを関連付けることができます。マネージャーAがログインすると、チームメンバーが持っているすべてのプロジェクトを確認したい場合があります。RDSモデルでは、これは次のように構成されている可能性があります。

  **project**                      **project_to_user**
  project_id PK                    project_id
  project_title                    user_id

  select p.project_id,p.project_title from project as p inner join project_to_user as pto on p.project_id = pto.user_id WHERE pto.user_id IN( 1,2,3,4);

これで、理論的にはdynamodbの同様の構造を維持できますが、user_idがuser_idのセットである場合は、最初に、user_idごとにproject_to_userからすべてのproject_idを選択する必要があります（多くの読み取り）。次に、返されたIDに基づいてすべてのプロジェクトを選択できます（コードを介して重複を削除する可能性があります）。または、project_to_userテーブルを破棄し、プロジェクトにuser_ids属性を設定して、そのテーブルでスキャンを実行できると思いました。スキャンがdynamodbを使用する最善の方法ではないことは承知していますが、これを行う最初の方法はとにかく大量の読み取りである可能性があるという顔によって、これを相殺できますか？

私のアプリには多くのテーブルがないため、Amazon dynamodbの候補として適していると理解していますが、リレーショナルモデルに固執する必要がありますか？

これは非常にオープンエンドに見えるかもしれませんが、DynamoDBが提供するスケールの見通しに興奮していますが、この種のものに最適かどうか疑問に思っています。ただし、リレーションシップモデルに固執すると、DB管理が将来的に大きな頭痛の種になることがわかります。私はすでにdynamodbモデルに合うようにDBを再設計しましたが、ジャンプすることを躊躇しているのはこれらの「JOIN」ポイントだけであり、人々が持つ可能性のある洞察に感謝します。

私はNoSQLに慣れるという点でMongoDBを少し遊んでいますが、私が理解しているように、Amazon DynamoDB（Amazonのプロ）よりもそのセットアップを管理する必要があります。

どうもありがとう

*編集* user_idクエリの検索は、project_idの検索と同じくらい多くなる可能性がありますが、各プロジェクトも個別に識別する必要があります。

4

1 に答える 1

1

サムルールは次のとおりです-DynamoDBを使用してクエリを実行できる場合は、これが適しています。結合に関しては、アプリケーションレベルでコードでこれを行う必要があります。

クエリを満たすためにDynamoでテーブルを設計できる場合、完全に管理された（ゼロ管理）および無限スケールのDBの利点が利点です。

最近、彼らはGSIをサポートしました。これにより、クエリがより柔軟になります。

于 2014-02-11T13:47:27.967 に答える