2

私は現在、小さなプロジェクトを設計しており、将来の保証を強化するための最善の方法についてアドバイスが必要でした.

基本的なオブジェクト Activity とその拡張機能があります。単純なデータベースの世界では、アクティビティ用のテーブル、各拡張機能用のテーブル、およびアクティビティと拡張機能の結合テーブルがあるとします。

次に、適切なテーブルを結合して情報を検索します。

私の計画は、CXF を使用してそれを Web サービスとして開き、Java 中間層をビジネス ロジックに使用し、elasticsearch を背後で使用してデータを保存およびクエリすることです。

私の質問は、elasticsearch を正しい方法で考えているのか、それともアプローチ (異なるテーブルと結合) が完全に間違っているのかということです。正しい場合、ElasticSearch 用語で異なる「テーブル」を表す最良の方法は何でしょうか。

また、elasticsearch の場合、オブジェクトの ID 情報を処理する最良の方法は何ですか。_id を各オブジェクトの id フィールドにマップするか、独自の id フィールドを保存するのが最善ですか?

乾杯、ロブ

4

1 に答える 1

1

ElasticSearch では、インデックスはデータベースに匹敵し、テーブルは型に匹敵するという比較を見てきました。

基本的に2つの異なる方法でそれを行うことができると思います。

オプション 1: 1 つのインデックスと 1 つのタイプ。Activity の各サブタイプは ES で 1 つのタイプにインデックス化され、一部のドキュメントにはフィールドがありません。
これにより、

  • サポートする 1 つのタイプ マッピング。デフォルトが十分でない場合は、すべてのサブタイプのすべてのフィールドを取得できます。
  • 共通フィールドは同じように分析する必要があります。
  • ドキュメントはすべて、タイプごとにフィールドのサブセットのみを持っています (実際には問題ではなく、奇妙なだけです)


オプション 2: 1 つのインデックスと複数のタイプ。Activity の各拡張は、ElasticSearch のタイプです。

  • サポートする多くのタイプ マッピング。
  • 共通のフィールドは別の方法で分析できます。
  • 理論的には、各ドキュメントにはマッピングのすべてのフィールドがあります。

どちらのアプローチでも、すべてのサブタイプを検索できます。検索リクエストの複雑さはアプリケーションに依存すると思います。

ほとんどのアプリケーションでは、オプション 2 を好むと思います。各サブタイプは、ElasticSearch で独自の「タイプ」にする必要があります。必要に応じて、タイプを超えてファセットを使用できます。サブタイプが比較的単純な場合は、ケース オプション 1 を作成できると思います。

あなたがそれを実装するとき、私はそれがどのように機能したかを聞きたいです.

于 2011-11-17T23:02:57.790 に答える