For all those promoting ES as a PRIMARY datastore, please read this before:

https://discuss.elastic.co/t/elasticsearch-as-a-primary-database/85733/13

There are a lot of warning before recommending ES as a datastore.

The answer from Pilato, ES official evangelist:


   - You absolutely care about your data and you want to be able to reindex
   in all cases. You need for that a datastore. A datastore can be a
   filesystem where you store JSON, HDFS, and/or a database you prefer and you
   are confident with. About how to inject data in it, you may want to read:
   http://david.pilato.fr/blog/2015/05/09/advanced-search-for-your-legacy-
   application/7
   
<http://david.pilato.fr/blog/2015/05/09/advanced-search-for-your-legacy-application/>
   .




On Mon, Jun 12, 2017 at 5:08 PM, Michael Mior <mm...@uwaterloo.ca> wrote:

> For queries 1-5 this seems like a potentially good use case for
> materialized views. Create one table with the videos stored by ID and the
> materialized views for each of the queries.
>
> --
> Michael Mior
> mm...@apache.org
>
>
> 2017-06-11 22:40 GMT-04:00 @Nandan@ <nandanpriyadarshi...@gmail.com>:
>
>> Hi,
>>
>> Currently, I am working on data modeling for Video Company in which we
>> have different types of users as well as different user functionality.
>> But currently, my concern is about Search video module based on different
>> fields.
>>
>> Query patterns are as below:-
>> 1) Select video by actor.
>> 2) select video by producer.
>> 3) select video by music.
>> 4) select video by actor and producer.
>> 5) select video by actor and music.
>>
>> Note: - In short, We want to establish an advanced search module by which
>> we can search by anyway and get the desired results.
>>
>> During a search , we need partial search also such that if any user can
>> search "Harry" title, then we are able to give them result as all videos
>> whose
>>  title contains "Harry" at any location.
>>
>> As per my ideas, I have to create separate tables such as video_by_actor,
>> video_by_producer etc.. and implement solr query on all tables. Otherwise,
>> is there any others way by which we can implement this search module
>> effectively.
>>
>> Please suggest.
>>
>> Best regards,
>>
>
>

Reply via email to