Re: Efficient model for a sorting

I started off with 3.0.6 and for my personal use case(s) they had the same bugs as tick tock. 2016-10-04 19:03 GMT+02:00 Jonathan Haddad : > I strongly recommend avoiding tick tock. You'll be one of the only people > putting it in prod and will likely hit a number of weird

Re: Efficient model for a sorting

I strongly recommend avoiding tick tock. You'll be one of the only people putting it in prod and will likely hit a number of weird issues nobody will be able to help you with. On Tue, Oct 4, 2016 at 12:40 PM Benjamin Roth wrote: > I have the impression, that not the

Re: Efficient model for a sorting

I have the impression, that not the tick-tock is the real problem but MVs are not really battle-tested yet. Depending on the model, they put much more complexity on a cluster and it's behaviour under heavy load. Especially if you are going to create an MV with a different partition key than the

Re: Efficient model for a sorting

Would you consider 3.0.x to be more stable than 3.x? I guess yes, but there are some discussion on this list: (C)* stable version after 3.5 Upgrade from 3.0.6 to 3.7. It seems to be eternal topic till tick-tock approach stabilizes. Best regards, Vladimir Yudovin, Winguzone Inc - Hosted

Re: Efficient model for a sorting

I use the self-compiled master (3.10, ticktock). I had to fix a severe bug on my own and decided to go with the latest code. Would you consider 3.0.x to be more stable than 3.x? 2016-10-04 18:14 GMT+02:00 Vladimir Yudovin : > Hi Benjamin! > > >we now use CS 3.x and have

Re: Efficient model for a sorting

Hi Benjamin! we now use CS 3.x and have been advised that 3.x is still not considered really production ready. Did you consider using of 3.0.9? Actually it's 3.0 with almost an year fixes. Best regards, Vladimir Yudovin, Winguzone Inc - Hosted Cloud Cassandra on Azure and SoftLayer. Launch

Re: Efficient model for a sorting

MV build is also async. In the end it's MV maintenance cost vs Lucene index maintenance cost. I don't have clear figure to judge which one is better. Maybe you should benchmark yourself. Anyway I'll be interested by the results On Tue, Oct 4, 2016 at 3:05 PM, Dorian Hoxha

Re: Efficient model for a sorting

On lucene you can query+filter+sort on a single shard, so it should be better than MV/sasi. The index building is a little async though. On Tue, Oct 4, 2016 at 2:29 PM, Benjamin Roth wrote: > Thanks guys! > > Good to know, that my approach is basically right, but I will

Re: Efficient model for a sorting

Thanks guys! Good to know, that my approach is basically right, but I will check that lucene indices by time. 2016-10-04 14:22 GMT+02:00 DuyHai Doan : > "What scatter/gather? " > > http://www.slideshare.net/doanduyhai/sasi-cassandra-on- >

Re: Efficient model for a sorting

"What scatter/gather? " http://www.slideshare.net/doanduyhai/sasi-cassandra-on-the-full-text-search-ride-voxxed-daybelgrade-2016/23 "If you partition your data by user_id then you query only 1 shard to get sorted by time visitors for a user" Exact, but in this case, you're using a 2nd index

Re: Efficient model for a sorting

@DuyHai What scatter/gather? If you partition your data by user_id then you query only 1 shard to get sorted by time visitors for a user. On Tue, Oct 4, 2016 at 2:09 PM, DuyHai Doan wrote: > MV is right now your best choice for this kind of sorting behavior. > > Secondary

Re: Efficient model for a sorting

MV is right now your best choice for this kind of sorting behavior. Secondary index (whatever the impl, SASI or Lucene) has a cost of scatter-gather if your cluster scale out. With MV you're at least guaranteed to hit a single node everytime On Tue, Oct 4, 2016 at 1:56 PM, Dorian Hoxha

Re: Efficient model for a sorting

Can you use the lucene index https://github.com/Stratio/cassandra-lucene-index ? On Tue, Oct 4, 2016 at 1:27 PM, Benjamin Roth wrote: > Hi! > > I have a frequently used pattern which seems to be quite costly in CS. The > pattern is always the same: I have a unique key

Efficient model for a sorting

Hi! I have a frequently used pattern which seems to be quite costly in CS. The pattern is always the same: I have a unique key and a sorting by a different field. To give an example, here a real life example from our model: CREATE TABLE visits.visits_in ( user_id int, user_id_visitor