Docs: Updated the explanation about memory usage with parent/child

This commit is contained in:
Clinton Gormley 2014-06-21 16:32:29 +02:00
parent 0e83615496
commit fac724cc99
5 changed files with 78 additions and 17 deletions

View File

@ -75,9 +75,20 @@ is specified.
[float]
==== Memory Considerations
With the current implementation, all `_parent` field values and all `_id`
field values of parent documents are loaded into memory (heap) via field data
in order to support fast lookups, so make sure there is enough memory for it.
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
Additionaly, every child document is mapped to its parent using a long
value (approximately). It is advisable to keep the string parent ID short
in order to reduce memory usage.
You can check how much memory is being used by the ID cache using the
<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------
[float]
==== Caching

View File

@ -46,11 +46,22 @@ The `has_parent` filter also accepts a filter instead of a query:
--------------------------------------------------
[float]
==== Memory considerations
==== Memory Considerations
With the current implementation, all `_parent` field values and all `_id`
field values of parent documents are loaded into memory (heap) via field data
in order to support fast lookups, so make sure there is enough memory for it.
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
Additionaly, every child document is mapped to its parent using a long
value (approximately). It is advisable to keep the string parent ID short
in order to reduce memory usage.
You can check how much memory is being used by the ID cache using the
<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------
[float]
==== Caching

View File

@ -86,6 +86,19 @@ the `score_mode` parameter.
[float]
==== Memory Considerations
With the current implementation, all `_parent` field values and all `_id`
field values of parent documents are loaded into memory (heap) via field data
in order to support fast lookups, so make sure there is enough memory for it.
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
Additionaly, every child document is mapped to its parent using a long
value (approximately). It is advisable to keep the string parent ID short
in order to reduce memory usage.
You can check how much memory is being used by the ID cache using the
<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------

View File

@ -52,6 +52,19 @@ matching parent document. The score type can be specified with the
[float]
==== Memory Considerations
With the current implementation, all `_parent` field values and all `_id`
field values of parent documents are loaded into memory (heap) via field data
in order to support fast lookups, so make sure there is enough memory for it.
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
Additionaly, every child document is mapped to its parent using a long
value (approximately). It is advisable to keep the string parent ID short
in order to reduce memory usage.
You can check how much memory is being used by the ID cache using the
<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------

View File

@ -66,6 +66,19 @@ same scope name that will work against the child documents. For example:
[float]
==== Memory Considerations
With the current implementation, all `_parent` field values and all `_id`
field values of parent documents are loaded into memory (heap) via field data
in order to support fast lookups, so make sure there is enough memory for it.
In order to support parent-child joins, all of the (string) parent IDs
must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
Additionaly, every child document is mapped to its parent using a long
value (approximately). It is advisable to keep the string parent ID short
in order to reduce memory usage.
You can check how much memory is being used by the ID cache using the
<<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
APIS, eg:
[source,js]
--------------------------------------------------
curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
--------------------------------------------------