We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
Since you will not change the list data in the document then it would be ok
to put them as nested documents, nested documents are afaik actually child
documents ensuring to be in the same block of data with the parent. If you
do changes in the list then you should probably choose to go with the
parent/child association. Hope that helps
Thomas
Τη Τρίτη, 17 Δεκεμβρίου 2013 2:03:07 μ.μ. UTC+2, ο χρήστης Maarten
Roosendaal έγραψε:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
Thanks for the response. The data actually will change because people will
remove or add items, but it won't happen that often.
The parent child has the challenge that it you want to filter/sort/search
on both the parent and the child, you can't do this in 1 call. With nested
document you can). I could be wrong, which would be a good outcome as
well:-)
Op dinsdag 17 december 2013 16:16:52 UTC+1 schreef Thomas:
Hi,
Since you will not change the list data in the document then it would be
ok to put them as nested documents, nested documents are afaik actually
child documents ensuring to be in the same block of data with the parent.
If you do changes in the list then you should probably choose to go with
the parent/child association. Hope that helps
Thomas
Τη Τρίτη, 17 Δεκεμβρίου 2013 2:03:07 μ.μ. UTC+2, ο χρήστης Maarten
Roosendaal έγραψε:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
If you choose to go with nested documents then on an update you will have
as a result reindexing the parent with all of its children, on the other
hand parent/child does not have such a behavior
On Tuesday, December 17, 2013 2:03:07 PM UTC+2, Maarten Roosendaal wrote:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
It also depends on how you search:
With your data:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc
if you perform search with condition: itemId=123 & itemdescription=ccc it
will match although item 123 has desc=aaa.
Just think carefully how you will search & filter then choose your right
type.
On Tuesday, December 17, 2013 4:03:07 AM UTC-8, Maarten Roosendaal wrote:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
Hi, this would be okay, since they are small documents and not related to
other documents. But this adds complexity which for now seem not needed so
nested documents would do fine.
Thanks,
Maarten
Op dinsdag 17 december 2013 16:55:40 UTC+1 schreef Thomas:
If you choose to go with nested documents then on an update you will have
as a result reindexing the parent with all of its children, on the other
hand parent/child does not have such a behavior
On Tuesday, December 17, 2013 2:03:07 PM UTC+2, Maarten Roosendaal wrote:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
Hi, the main priority now is search based on the listmetainformation. Not
yet on the children, but i can see that happening.
I don't quite get your example, is this when using nested documents?
Thanks for the response
Op woensdag 18 december 2013 04:24:30 UTC+1 schreef kidkid:
It also depends on how you search:
With your data:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc
if you perform search with condition: itemId=123 & itemdescription=ccc it
will match although item 123 has desc=aaa.
Just think carefully how you will search & filter then choose your right
type.
On Tuesday, December 17, 2013 4:03:07 AM UTC-8, Maarten Roosendaal wrote:
Hi,
We are looking into using elasticsearch and one of the use cases is
customerlists, for example a wishlist. So i can create a list (X-mas
shopping list) with a description, tags and some other metainformation. I
can then add items (with an identifier) to that list and also a custom
description for each item.
We would like to be able to :
search through description, tags, etc...,
sort on creating/mutationdate, and
navigate on tags or other metainformation.
Conceptually you have a ListObject and it can contain 0 or many
ItemObjects. In a database this would probably mean 2 or more tables but
elasticsearch likes it's data flattened.
How would you model this in elasticsearch? Is it better to use nested or
parent-child relations, or simply flatten the data. The data isn't often
mutated and lists are usually very small.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.