0

現在のアプリケーションにコメント セクションを実装しています。コメント セクションは、特定のページに対する一連のユーザー投稿と考えることができます。非リレーショナル データベース (Google App Engine) で最も効果的な設計はどれか考えています。

設計 1: コメントを groupId でグループ化し、それらの結果をフィルター処理する

Comment Entity >> [id, groupId, otherData...]

ページに関するすべてのコメントのクエリは次のようになります。

Select from Comments filter by groupId

設計 2: グループ内のすべてのコメントに対して 1 つのキーを格納し、エントリ数が 5000 エントリを超える場合は自己拡張リストを使用します。

Comment Entity >> [id, SELid]

クエリは単に ID/キー ルックアップを実行します。

インデックスが高価になる可能性があることは理解していますが、最初の設計提案では groupId フィールドのみをインデックス化し、コメントを投稿するために必要な書き込みは 1 回だけです (インデックスを含めると、より多くの書き込みが必要になります)。

2 番目の設計では、コストのかかるインデックス作成を回避できますが、投稿されたコメントごとに読み取り操作と書き込み操作が必要になります。さらに、競合の問題が心配です。これらのコメントで極端に高いスループットが発生することはないはずですが、2 番目の設計がボトルネックになっているようです。

私は非リレーショナル DB を初めて使用するので、これらの提案された設計とそれに関連するトレードオフについて意見をいただければ幸いです。

4

1 に答える 1

1

App Engine と Datastore の場合、採用するアプローチは主に、エンティティに必要な整合性モデル (強いものと最終的なもの) によって異なります。Google Cloud Datastore には、エンティティ グループの概念があります。エンティティ グループ (エンティティとその子孫) は、強力な一貫性、トランザクション性、局所性を備えた単位ですが、いくつかの制限 (1 秒あたり 1 回の書き込み) も課されます。

考慮事項

  1. 強力で一貫した結果が必要ですか?
  2. コメントはページごとにどのくらいの頻度で投稿されますか?
  3. 1 ページあたり何件のコメントを期待していますか?
  4. トランザクション動作を必要とするユースケースはありますか?

どちらのデザイン オプションもエンティティ グループ (ページ -> 投稿) を使用していないため、この方法を使用しないことにしたと思います。

デザイン1

  1. groupId による結果整合性のあるルックアップ
  2. 維持しやすい (5000 エンティティの制限に対処する必要がない)

デザイン 2

  1. entityGroupId による強力な一貫性のあるルックアップ
  2. 維持するのが難しい（5000エンティティの制限に対処する必要があります）
  3. 前述のように、ページのすべての投稿を表す 1 つのエンティティがボトルネックになる可能性があります (Memcache によって削減できます)。

リレーショナル データ モデルに似ている可能性がありますが、おそらく最初のアプローチを使用します。

于 2014-07-12T18:53:57.610 に答える