Modeling question: lists of items


(Maarten Roosendaal) #1

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79bd1fc0-770a-4545-a02b-dccd6764daf5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Thomas) #2

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b733d3e8-a138-4df9-a555-86fce8cbf3ec%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Maarten Roosendaal) #3

Hi,

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3cf8a182-2c66-4b48-90d3-3c234f319818%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Thomas) #4

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/07e3188f-3a3e-43e3-a689-c0749fd0f9c9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Sang Dang) #5

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f7c037ed-7630-4735-b204-c3cdee511249%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Maarten Roosendaal) #6

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/8588146e-d836-4865-bfc9-398a0a5ad9ce%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Maarten Roosendaal) #7

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.

Example:
listid 1
custId: 1
listmetainformation
itemId 123, itemdescription: aaa
itemId 456, itemdescription: bbb
itemId 789, itemdescription: ccc

Hope someone can give me some pointers or an example.

Thanks,
Maarten

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/bf71ee46-8e89-440d-a8f5-e198d2a44412%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #8