Implementing an amazon/ebay like search

Elastic Stack Elasticsearch
1

Hi,
I'm working on a web application which is focused around products;
Currently all of our data is contained in RDBMS (mysql) and is searchable
via joins and such.
The performance and relevance are, as expected, horrible and that's why we
want to employ ES as a search engine for that part of the application.
Currently we have several entities in our model which include, amongst
other, Product, Brand and TargetCustomer.
In our UI we have the ability to search via a simple textbox and the
ability to filter according to the meta-properties (Brand,
TargetCustomer...).
I've been reading here a lot trying to understand how I can build
associations between different documents when I stumbled on this discussionhttps://groups.google.com/forum/?hl=en#!topicsearchin/elasticsearch/many-to-many/elasticsearch/LJ-cW4_-4BIwhich made me think I may be at fault and that I should maybe revisit how
to map my model to ES documents.
My product entity is related in one-to-one to 3 other entities which change
quite frequently and to 4 other entities via many-to-many but these change
infrequently.
I think that having the frequently changed entities nested is very
problematic for me with respect to data maintenance, but I'm not sure if ES
provides a good alternative solution?
I remember seeing an example on the site, when I started looking into ES,
about documents referencing one another via IDs (some example with A's and
B's where B doesn't have to be nested) but I can't seem to find it to see
if it does actually correlate to my problem.
In any case I'd be very grateful for any pointers about the possible leads
I should follow up on as it seems there isn't one simple solution in the
NoSQL world (CAP and all...)

P.S. I'm also thinking of maybe trying to pick one of the 3 related
entities which changes the most (or that I care about it's changes the
most) and artificially have that as the parent of the products and just pay
the price of multiple queries for the other two entities. Would appreciate
feedback about that approach too.
Thanks

2

probably you meant the parent/child feature?

But I think if you explain your requirements (e.g. the kind of queries

  • concrete data example):

My product entity is related in one-to-one to 3 other entities which change quite frequently and
to 4 other entities via many-to-many but these change infrequently.

a bit more there could be different / faster solutions.

Peter.

On 12 Jan., 12:27, Ittai Zeidman it...@fashion-traffic.com wrote:

Hi,
I'm working on a web application which is focused around products;
Currently all of our data is contained in RDBMS (mysql) and is searchable
via joins and such.
The performance and relevance are, as expected, horrible and that's why we
want to employ ES as a search engine for that part of the application.
Currently we have several entities in our model which include, amongst
other, Product, Brand and TargetCustomer.
In our UI we have the ability to search via a simple textbox and the
ability to filter according to the meta-properties (Brand,
TargetCustomer...).
I've been reading here a lot trying to understand how I can build
associations between different documents when I stumbled on this discussionhttps://groups.google.com/forum/?hl=en#!topicsearchin/elasticsearch...which made me think I may be at fault and that I should maybe revisit how
to map my model to ES documents.
My product entity is related in one-to-one to 3 other entities which change
quite frequently and to 4 other entities via many-to-many but these change
infrequently.
I think that having the frequently changed entities nested is very
problematic for me with respect to data maintenance, but I'm not sure if ES
provides a good alternative solution?
I remember seeing an example on the site, when I started looking into ES,
about documents referencing one another via IDs (some example with A's and
B's where B doesn't have to be nested) but I can't seem to find it to see
if it does actually correlate to my problem.
In any case I'd be very grateful for any pointers about the possible leads
I should follow up on as it seems there isn't one simple solution in the
NoSQL world (CAP and all...)

P.S. I'm also thinking of maybe trying to pick one of the 3 related
entities which changes the most (or that I care about it's changes the
most) and artificially have that as the parent of the products and just pay
the price of multiple queries for the other two entities. Would appreciate
feedback about that approach too.
Thanks