問題
ブール値をelasticsearchに保存しようとしていますが、NULLであることは特に有効です。この場合、一種のドントケアです。
いくつかのオプションがあるようですが、どれが最適かは完全には明らかではありません。
ElasticSearch バージョン 5.0.2 を使用しています
オプション1
些細なことは、NULL 値を持つブール値として保存することです。これらは、ES によって「欠落」していると見なされます。
PUT my_index
{
"mappings": {
"my_type": {
"properties": {
"my_boolean": { "type": "boolean"}
}
}
}
}
PUT my_index/my_type/1
{"my_boolean": true}
PUT my_index/my_type/2
{"my_boolean": false}
PUT my_index/my_type/3
{"my_boolean": null}
これにはいくつかの問題があり、そのうちの 1 つは集約です。true
値を取得する簡単な方法はないようです。集計でfalse
。NULL
このmissing
機能は私が知っているので、次のことができることを知っています。
GET my_index/_search
{
"size":0,
"aggregations": {
"my_boolean": {
"terms": {
"field": "my_boolean"
}
},
"missing_fields": {
"missing" : {
"field": "my_boolean"
}
}
}
}
ただし、これにより、2 つの値 (true/false) を持つバケットと、欠落しているドキュメントの個別のカウントが得られます。それは問題を引き起こすように見えます。
オプション 2
別のオプションは、マニュアルで説明されているように、実際に NULL に値を与えること です。問題は、値が正しい型である必要があり、ブール値として true と false しかないことです。
null_value は、フィールドと同じデータ型である必要があります。たとえば、長いフィールドに文字列 null_value を含めることはできません。
これは、2 つ以上の値 (整数など) をサポートする別の型を使用できることを意味しますが、それは私の頭の中で言うのと同じです: 整数としてマップし、1 を true、2 を false、3 を null として定義します。これは機能しますが、すべての人が知っておくべき暗黙のマッピングがあります。(すべての生産者/消費者/whatyamahaveits)。
オプション 3
最終的なバージョンは、この問題を解決するためのスクリプトを作成することです。
GET my_index/_search
{
"size":0,
"aggregations": {
"my_boolean": {
"terms": {
"script" : {
"inline": "if(doc['my_boolean'].length === 1) { if(doc['my_boolean'].value === true){ return 1;} else {return 2;} } else { return 3;}"
}
}
}
}
}
これで、ある程度健全なバケットで適切な結果が得られます。
"aggregations": {
"my_boolean": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "1",
"doc_count": 1
},
{
"key": "2",
"doc_count": 1
},
{
"key": "3",
"doc_count": 1
}
]
}
}
ここでもキーとの暗黙的なマッピングがあることに注意してください。したがって、これには、整数としてマッピングする場合と同じ問題がいくつかあるようです。それでも、あなたのデータ型は本来あるべきものなので、それは何かかもしれません. キーとして「null」を持つバケットを持つことはできないことに注意してください。もちろん、それらを「true」、「false」、「null」(文字列)と呼ぶこともできますが、これは同じ状況ですが、さらに隠されています。
質問
このヌル問題に対処する最善の方法は何ですか? (または、「トライステート ブール問題」と呼ぶべきでしょうか?)
明確にするために、後で「非標準」の値が問題を引き起こす可能性があることを恐れています。最初に見たのは、上記のスクリプト ソリューションで修正できる可能性のあるバケット化でしたが、後で他の問題に遭遇する可能性があります。そのため、特定の問題に対する迅速な解決策ではなく、この種のデータを保存するためのベスト プラクティスを探しています。