Unless you're willing to put in a lot of time fixing bugs, I'd recommend avoiding 3.0's materialized views and manage them yourself.
On Mon, Jun 12, 2017 at 6:11 PM @Nandan@ <nandanpriyadarshi...@gmail.com> wrote: > Correct, Our first concern is to store huge READ and WRITE, for that > Cassandra is our First and Best Choice. But according to Use Case, we need > to implement Advance search like Partial text, Phrase search etc.. So we > are thinking the best way, that how to implement data model. > > > On Tue, Jun 13, 2017 at 3:35 AM, Oskar Kjellin <oskar.kjel...@gmail.com> > wrote: > >> Agree, I meant as Jonathan said to use C* for primary key and as a >> primary storage and ES as an indexed version of what you have in cassandra. >> >> 2017-06-12 19:19 GMT+02:00 DuyHai Doan <doanduy...@gmail.com>: >> >>> Sorry, I misread some reply I had the impression that people recommend >>> ES as primary datastore >>> >>> On Mon, Jun 12, 2017 at 7:12 PM, Jonathan Haddad <j...@jonhaddad.com> >>> wrote: >>> >>>> Nobody is promoting ES as a primary datastore in this thread. Every >>>> mention of it is to accompany C*. >>>> >>>> >>>> >>>> On Mon, Jun 12, 2017 at 10:03 AM DuyHai Doan <doanduy...@gmail.com> >>>> wrote: >>>> >>>>> 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, >>>>>>> >>>>>> >>>>>> >>>>> >>> >> >
