「タイプ」とはElasticsearchの意味ですか？

Question

私は、Elasticsearchの文書によって完全に混乱しています。 Basic Concepts: Typeで

、「タイプ」のMongoDB内のコレクションのように何とかしている：このインデックスで

は、ユーザー・データのタイプ、ブログのデータのための別のタイプ、およびコメントデータのためのさらに別のタイプを定義することがあります。

しかしTypes and Mappings: Type Takeawaysで、それは言う：

タイプは、同様にデータの完全に異なるタイプのために適していません。 2つのタイプに相互に排他的なフィールドセットがある場合、インデックスの半分が「空の」値を含むことになり（フィールドはまばらになります）、結果的にパフォーマンスの問題が発生します。

上記の「ユーザー」と「ブログ」には、相互に排他的なフィールドがありますか？ たとえば、「ユーザー」の「名前」、「年齢」、「ブログ」の「createdAt」、「コンテンツ」があります。

私はElasticsearchとMongoDBの間のマッピング関係を信じるように慣れては次のとおりです。

インデックス< =>データベース

タイプ< =>コレクション

それは右ではないでしょうか？ そうでない場合は、それらの間で推奨されるマッピングスタイルは何ですか？

Answer 1

あなたは正しいですが、index ==データベースとtype == elasticsearchのコレクションです。 RDBMS用語では、indexはデータベースであり、typeは、多くの行（elasticsearchにdocument）を含むテーブルにすることができます。

「名前」、「年齢」などのフィールドは一般的に人物に属し、「createdAt」、「コンテンツ」などのブログでは別のフィールドがユーザー情報を管理する別のインデックスを持つことができます。しかし、あなたが投稿した人物を特定できるようにするためには、各ブログ文書の中に「ユーザ」フィールドがあることが必要な場合があります。後で必要に応じてapplication-side joinsを適用することができます。

Answer 2

タイプは全く異なるタイプのデータにはあまり適していません。 2つのタイプに相互に排他的なフィールドセットがある場合、インデックスの半分が「空の」値を含むことになり（フィールドはまばらになります）、結果的にパフォーマンスの問題が発生します。

typeは、非常に基本的なレベルのElasticsearchの別のフィールドです。 GET /my_index/my_type/_search ESは、フィールド_typeのmy_type値のプレフィルタを実行します。これは自動フィルタのようなものです。

インデックスではないので、インデックスと型はSQL世界のデータベースとテーブルとして考える必要はありません。

あなたは、インデックス内のフィールドf1とf3とフィールドf1とf2とtype2とtype1をお持ちの場合はフィールドf1、f2、f3との文書が存在します。なぜこれが重要 - ドキュメントのスコアは、あなたがtype1からf1にいくつかの値を検索するので、もしフィールドf1における用語の頻度がグローバル（両方type1とtype2）になり、フィールドf1で値を検索クエリで計算される時あなたが戻った得点はf1の値によって少しでも影響され、type2になります。

また、ESで親子関係を定義する主キー/外部キーの方法に従うだけで、一連のSQLテーブルをESに変換しないでください。