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 closely
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 pleased to announce a new mem
read latency?
Regards
Sachin
On Tue, Apr 21, 2015 at 9:57 AM, Tyler Hobbs wrote:
>
> On Mon, Apr 20, 2015 at 4:02 PM, Sachin Nikam wrote:
>
>> #1. We have 2 data centers located close by with plans to expand to more
>> data centers which are even further away geographically.
s 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 countries, DataStax i
st 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 countries, DataStax is the
&g
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?
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 be
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 wrote:
> Janne,
> Thanks for continuing to take the time to answer my queries. We noticed
> that write latency (tp99) from Servic
ization 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 wrote:
>
> Thanks Janne...
> To clarify, Service S3 should not run in to any issues and I may choose to
> not fi
measure :-)
>
> /Janne
>
> On 02 Aug 2015, at 02:17 , Sachin Nikam 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
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 java
driver 2.1. S3 also reads data from TableA
nd aren't expecting high contention (which I
> don't think you are). I recommend testing this out with your application
> to see how it performs for you.
>
>
> On Sun, Mar 22, 2015 at 7:02 PM, Sachin Nikam wrote:
>
>> @Eric Stevens
>> Thanks for representi
use case for write timestamps, and
>>>> there are definitely gotchas if you are not careful or misunderstand the
>>>> consequences, as far as I can see the logic behind it is sound but does
>>>> rely on correct conflict resolution in Cassandra. I'm curious
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
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 inpu
15 matches
Mail list logo
