Yes I am not thinking to go with MV. I am trying to implement by myself. May be some idea will get about doing cassandra-stress about data generation and all. Thanks Jonathan.
On Tue, Jun 13, 2017 at 10:44 AM, Jonathan Haddad <j...@jonhaddad.com> wrote: > 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, >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >>
