0

User、Message、MessageFeatures などのエンティティを持つアプリケーションがあります。各 User は多数のメッセージを持つことができ、各メッセージには MessageFeatures エンティティがあります。現在、リレーショナル モデルは次のように表現されます。

User{
  UUID id
  String email
  ...
}
Message{
  UUID id,
  UUID userId
  String text
  ....
}
MessageFeatures{
  UUID id
  UUID messageId
  UUID userId
  PrimitiveObject feature1
  ....
  PrimitiveObject featureN
}

最も重要なクエリは次のとおりです。

  • ユーザーのすべてのメッセージを取得する
  • ユーザーのすべてのメッセージ機能を取得する
  • uuid でメッセージを取得する
  • uuidによるメッセージ取得・更新機能
  • メッセージ uuid によるメッセージ機能の取得

重要度の低い (遅くなる可能性がある) クエリは次のようになります。

  • user_id = someuuid および featureX = value のメッセージ機能を取得します
  • featureX = value のすべて/カウントのユーザー uuid を取得します
  • update message features set featureX = newValue where featureX = oldValue

カウチベースの評価中に、適切なデータ モデルに到達できません。ユーザー向けのすべてのメッセージとメッセージ機能を 1 つのドキュメントにまとめることは良い考えではないと思います。サイズは増え続け、現在のデータに基づくと 2 年間のデータで 4 ~ 5 MB の範囲に簡単に収まるからです。また、一貫性を維持するために、原子性はドキュメントごとにあるため、一度に 1 つのメッセージ機能のみを更新できます。

それらを単一のドキュメントに配置しないと、それらはクラスターの周りに散らばり、ユーザーのすべてのメッセージ/メッセージ機能を取得するようなクエリは、散らばって集まります。

グローバル セカンダリ インデックスと N1QL を確認しましたが、メッセージの user_uuid フィールドにインデックスを付けても、そのユーザーの message_uuids を取得するのに役立つだけで、すべてのメッセージをロードすると分散と収集が発生します...

すべてのメッセージ、user_uuid のメッセージ機能を、redis のハッシュタグのような同じドキュメントに埋め込むことなく、同じ物理ノードにマップすることを強制する方法はありますか?

4

1 に答える 1