Comment on query performance

Hi All, I have a table like this: CREATE TABLE IF NOT EXISTS Posts ( idObject int, objectType text, idParent int, id int, idResolution int, PRIMARY KEY ((idObject, objectType, idParent), id) ); Now have a look at the following query: SELECT * FROM POSTS WHERE idobject =

Re: Comment on query performance

No full table scan because you specify all the partition key columns in your WHERE clause. On Thu, Dec 29, 2016 at 11:02 AM, Ashutosh Dhundhara < ashutoshdhundh...@yahoo.com> wrote: > Thanks DuyHai. > > One more thing, is it going to be a full table scan across all the nodes > in cluster? > > On

Re: Comment on query performance

Thanks DuyHai once again :-) On Thu, Dec 29, 2016 at 3:35 PM, DuyHai Doan wrote: > No full table scan because you specify all the partition key columns in > your WHERE clause. > > On Thu, Dec 29, 2016 at 11:02 AM, Ashutosh Dhundhara < > ashutoshdhundh...@yahoo.com> wrote:

How to change Replication Strategy and RF

Hi all, We have mistakenly setup c*-2.0.17 cluster (with 1 DC , 3 racks , 2 nodes in each rack with SimpleStrategy & *RF=1)*. Now data on each node is nearly 1.4 GB+ . Now we would like to change Replication Strategy to NetworkTopologyStrategy and RF=3 and also add a new Data Center to this

Re: Comment on query performance

In your case, ALLOW FILTERING will require Cassandra to scan linearly on disk and fetch all the partition data into memory so the performance depends on how "large" your partition is. For small partitions it should be fine. On Thu, Dec 29, 2016 at 10:00 AM, Ashutosh Dhundhara <

Re: Comment on query performance

Thanks DuyHai. One more thing, is it going to be a full table scan across all the nodes in cluster? On Thu, Dec 29, 2016 at 3:30 PM, DuyHai Doan wrote: > In your case, ALLOW FILTERING will require Cassandra to scan linearly on > disk and fetch all the partition data into

Query

Hi, I'm exploring Cassandra for handling large data sets for mobile app, but i'm not clear where it stands. If we use MySQL as underlying database and Gizzard for building custom distributed databases (with arbitrary storage technology) and Memcached for highly queried data, then where lies

Re: How to change Replication Strategy and RF

​If you're already using the cluster in production and require no downtime you should perform a datacenter migration first to change the RF to 3. Rough process would be as follows: 1. Change keyspace to NetworkTopologyStrategy with RF=1. You shouldn't increase RF here as you will receive

Re: Query

I am not that familiar with gizzard but with gizzard + mysql , you have multiple moving parts in the system that need to managed separately. You'll need the mysql expert for mysql and the gizzard expert to manage the distributed part. It can be argued that long term this will have higher

Re: Query

You should start with understanding your needs. Once you understand your need you can pick the software that fits your need. Staring with a software stack is backwards. On Thu, Dec 29, 2016 at 11:34 PM, Ben Slater wrote: > I wasn’t familiar with Gizzard either so I

Re: Query

I wasn’t familiar with Gizzard either so I thought I’d take a look. The first things on their github readme is: *NB: This project is currently not recommended as a base for new consumers.* (And no commits since 2013) So, Cassandra definitely looks like a better choice as your datastore for a new