Cassandra 2.0 Batch Statement for timeseries schema

I currently have a keyspace with table definition that looks like this. CREATE TABLE *orders*( order-id long PRIMARY KEY, order-blob text ); This table will have a write load of ~40-100 tps and a read load of ~200-400 tps. We are now considering adding another table definition which

Re: ScyllaDB, a new open source, Cassandra-compatible NoSQL

Tzach, Can you point to any documentation on scylladb site which talks about how/why scylla db performs better than Cassandra while using the same architecture? Regards Sachin On Tue, Sep 22, 2015 at 9:18 AM, Tzach Livyatan wrote: > Hello Cassandra users, > > We are

Re: CQL 3.x Update ...USING TIMESTAMP...

read latency? Regards Sachin On Tue, Apr 21, 2015 at 9:57 AM, Tyler Hobbs <ty...@datastax.com> wrote: > > On Mon, Apr 20, 2015 at 4:02 PM, Sachin Nikam <skni...@gmail.com> wrote: > >> #1. We have 2 data centers located close by with plans to expand to more >> da

Re: Adding New Nodes/Data Center to an existing Cluster.

gt;> >> DataStax is the fastest, most scalable distributed database technology, >> delivering Apache Cassandra to the world’s most innovative enterprises. >> Datastax is built to be agile, always-on, and predictably scalable to any >> size. With more than 500 customers in 45 countrie

Data Size on each node

We currently have a Cassandra Cluster spread over 2 DC. The data size on each node of the cluster is 1.2TB with spinning disk. Minor and Major compactions are slowing down our Read queries. It has been suggested that replacing Spinning disks with SSD might help. Has anybody done something similar?

Re: Adding New Nodes/Data Center to an existing Cluster.

t;>> DataStax is the fastest, most scalable distributed database technology, >>> delivering Apache Cassandra to the world’s most innovative enterprises. >>> Datastax is built to be agile, always-on, and predictably scalable to any >>> size. With more than 500 customers in

Adding New Nodes/Data Center to an existing Cluster.

Here is the situation. We have 3 nodes in Data Center A with Replication Factor of 2. We want to add 3 more nodes in Data Center B with Replication Factor of 2. Each node in Data Center A has about 150GB of data. When we add 3 more nodes in Data Center B, the repair tool starts syncing the data

Re: Cassandra Data Stax java driver Snappy Compression library

Janne, A little clarification i found snappy-java-1.0.4.1.jar on class path. But other questions still remain. On Tue, Aug 4, 2015 at 8:24 PM, Sachin Nikam skni...@gmail.com wrote: Janne, Thanks for continuing to take the time to answer my queries. We noticed that write latency (tp99) from

Re: Cassandra Data Stax java driver Snappy Compression library

optimization to keep in mind though for production environments, if you choose not to enable compression now. /Janne On 3 Aug 2015, at 08:40, Sachin Nikam skni...@gmail.com wrote: Thanks Janne... To clarify, Service S3 should not run in to any issues and I may choose to not fix the issue

Re: Cassandra Data Stax java driver Snappy Compression library

, Sachin Nikam skni...@gmail.com wrote: I am currently running a Cassandra 1.2 cluster. This cluster has 2 tables i.e. TableA and TableB. TableA is read and written to by Services S1 and S2 which use Astyanax client library. TableB is read and written by Service S3 which uses the datastax

Re: CQL 3.x Update ...USING TIMESTAMP...

, Mar 22, 2015 at 7:02 PM, Sachin Nikam skni...@gmail.com wrote: @Eric Stevens Thanks for representing my position while I came back to this thread. @Tyler With your recommendation, won't I end up saving all the version(s) of the document. In my case the document is pretty huge (~5mb

Re: CQL 3.x Update ...USING TIMESTAMP...

: SELECT * FROM document_store WHERE document_id = ? LIMIT 1; Another option is to use lightweight transactions (i.e. UPDATE ... SET docuement = ?, version = ? WHERE document_id = ? IF version ?), but that's going to make writes much more expensive. On Wed, Mar 11, 2015 at 12:45 AM, Sachin Nikam

CQL 3.x Update ...USING TIMESTAMP...

I am planning to use the Update...USING TIMESTAMP... statement to make sure that I do not overwrite fresh data with stale data while having to avoid doing at least LOCAL_QUORUM writes. Here is my table structure. Table=DocumentStore DocumentID (primaryKey, bigint) Document(text) Version(int) If

error building cassandra trunk

I synced up cassandra-trunk and trying ant build. getting the following error. Any ideas? [java] error(208): /home/sknikam/cassandra/dev/cassandra-trunk/src/java/org/apache/cassandra/cql/Cql.g:568:1: The following token definitions can never be matched because prior tokens match the same