Elasticsearch nested fields


(tmanta7) #1

Hi guys,

I'm currently facing an issue with ES and its integration with Kibana on a
specific subject: nested fields.

My goal was to implement a terms panel using nested fields. I used nested
fields to manage some key/values :

{

"mappings" : { 

    "fkv" : { 

        "properties" : { 

            "kv" : { 

                "type" : "nested", 

                "include_in_parent" : false, 

                "properties" : { 

                    "name" : {"type" : "string"}, 

                    "value" : {"type" : "string"} 

                } 

            } 

        } 

    } 

} 

}

Unfortunately I read somewhere that this integration was not done by Kibana
authors. So I started to wonder if using nested fields was really
necessary..
Ok it's helpful to manage key/value but why shouldn't I use the "column
oriented" mechanism of Elasticsearch? I mean, using simply the key as a
column :

{

"kv" : [ 

    { 

        "key" : "id", 

        "value" : "part1" 

    }, 

    { 

        "key" : "state", 

        "value" : "released" 

    } 

] 

}

Excuse me if my questions is stupid, I'm a beginner with Elasticsearch but
in my simple case (managing key/value) I can't see any advantages of using
nested fields.

Thanks in advance for your help!

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Ivan Brusic) #2

With nested fields, a query will only return document whose nested
documents match all the fields in the query. In your example, a
query/filter on key & value most match the same fields in the same
document. Without nested fields, elasticsearch/Lucene will flatten multiple
values into an array. For example:

key : [ id, state]
value : [part1, released]

Without nested documents, a query for key:id & value:released will return
the above document although they do not match the same sub-object. With
nested documents, your query will not match.

Cheers,

Ivan

On Mon, Nov 4, 2013 at 3:31 PM, tmanta7@gmail.com wrote:

Hi guys,

I'm currently facing an issue with ES and its integration with Kibana on a
specific subject: nested fields.

My goal was to implement a terms panel using nested fields. I used nested
fields to manage some key/values :

{

"mappings" : {

    "fkv" : {

        "properties" : {

            "kv" : {

                "type" : "nested",

                "include_in_parent" : false,

                "properties" : {

                    "name" : {"type" : "string"},

                    "value" : {"type" : "string"}

                }

            }

        }

    }

}

}

Unfortunately I read somewhere that this integration was not done by
Kibana authors. So I started to wonder if using nested fields was really
necessary..
Ok it's helpful to manage key/value but why shouldn't I use the "column
oriented" mechanism of Elasticsearch? I mean, using simply the key as a
column :

{

"kv" : [

    {

        "key" : "id",

        "value" : "part1"

    },

    {

        "key" : "state",

        "value" : "released"

    }

]

}

Excuse me if my questions is stupid, I'm a beginner with Elasticsearch but
in my simple case (managing key/value) I can't see any advantages of using
nested fields.

Thanks in advance for your help!

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #3