Help with design choice: join or multiValued field

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with design choice: join or multiValued field

Karl Kildén
Hello!

I have Items and I have Shops. This is a e-commerce system with items from
thousands of shops all though the inventory is often similar between shops.
Some users can shop from any shop and some only from their default one.


One item can exist in about 10000 shops.


   - When a user logs in they may have a shop pre selected so when they
   search for items we need to get all matching documents but if it's' found
   in their pre selected shop we should mark it out in the UI.
   - They need to be able to filter out only items in their current shop
   - Items found in their shop should always be boosted heavily



TLDR:

Either we just have a multiValued field on the item document with all
shops. This would be a multivalued field with 10000 rows

Or

Could we have a new document ShopItem that has the shopId and the itemId
(think join table). Then we join this document instead... But we still need
to get the Item document back, and we need bq boosting on item?
Reply | Threaded
Open this post in threaded view
|

Re: Help with design choice: join or multiValued field

Fuad Efendi
Correct: multivalued field with 10000 shop IDs. Use case: shopping network
in U.S. for example for a big brand such as Walmart, when user implicitly
provides IP address or explicitly Postal Code, so that we can find items in
his/her neighbourhood.


You basically provide “join” information via this 10,000-sized collection
of IDs per document. It almost doesn’t have any impact on index size. User
query needs to provide list of preferred IDs (if for example we know user’s
geo location). And for this “Walmart” use case you may also need “Available
Online Only” option, etc.


From: Karl Kildén <[hidden email]> <[hidden email]>
Reply: [hidden email] <[hidden email]>
<[hidden email]>
Date: February 6, 2017 at 5:57:41 AM
To: [hidden email] <[hidden email]>
<[hidden email]>
Subject:  Help with design choice: join or multiValued field

Hello!

I have Items and I have Shops. This is a e-commerce system with items from
thousands of shops all though the inventory is often similar between shops.
Some users can shop from any shop and some only from their default one.


One item can exist in about 10000 shops.


- When a user logs in they may have a shop pre selected so when they
search for items we need to get all matching documents but if it's' found
in their pre selected shop we should mark it out in the UI.
- They need to be able to filter out only items in their current shop
- Items found in their shop should always be boosted heavily



TLDR:

Either we just have a multiValued field on the item document with all
shops. This would be a multivalued field with 10000 rows

Or

Could we have a new document ShopItem that has the shopId and the itemId
(think join table). Then we join this document instead... But we still need
to get the Item document back, and we need bq boosting on item?
Reply | Threaded
Open this post in threaded view
|

Re: Help with design choice: join or multiValued field

Karl Kildén
Thanks for the reply! We did it this way and it's seems to turn out really
well

On 6 February 2017 at 22:57, Fuad Efendi <[hidden email]> wrote:

> Correct: multivalued field with 10000 shop IDs. Use case: shopping network
> in U.S. for example for a big brand such as Walmart, when user implicitly
> provides IP address or explicitly Postal Code, so that we can find items in
> his/her neighbourhood.
>
>
> You basically provide “join” information via this 10,000-sized collection
> of IDs per document. It almost doesn’t have any impact on index size. User
> query needs to provide list of preferred IDs (if for example we know user’s
> geo location). And for this “Walmart” use case you may also need “Available
> Online Only” option, etc.
>
>
> From: Karl Kildén <[hidden email]> <[hidden email]>
> Reply: [hidden email] <[hidden email]>
> <[hidden email]>
> Date: February 6, 2017 at 5:57:41 AM
> To: [hidden email] <[hidden email]>
> <[hidden email]>
> Subject:  Help with design choice: join or multiValued field
>
> Hello!
>
> I have Items and I have Shops. This is a e-commerce system with items from
> thousands of shops all though the inventory is often similar between shops.
> Some users can shop from any shop and some only from their default one.
>
>
> One item can exist in about 10000 shops.
>
>
> - When a user logs in they may have a shop pre selected so when they
> search for items we need to get all matching documents but if it's' found
> in their pre selected shop we should mark it out in the UI.
> - They need to be able to filter out only items in their current shop
> - Items found in their shop should always be boosted heavily
>
>
>
> TLDR:
>
> Either we just have a multiValued field on the item document with all
> shops. This would be a multivalued field with 10000 rows
>
> Or
>
> Could we have a new document ShopItem that has the shopId and the itemId
> (think join table). Then we join this document instead... But we still need
> to get the Item document back, and we need bq boosting on item?
>