The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.9.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source an
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.11.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source a
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.17.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source a
Ok, thanks Matija.
On Tue, Feb 21, 2017, at 11:43 AM, Matija Gobec wrote:
> They appear for each repair run and disappear when repair run
> finishes.
>
> On Tue, Feb 21, 2017 at 11:14 AM, Vincent Rischmann
> wrote:
>> __
>> Hi,
>>
>> I upgraded to Cassandra 2.2.8 and noticed something
It looks like there is ordering within one client (ordering based on
timestamp) and looks like this *order is preserved across all replicas*
however the benefits of async given the ordering restriction are slightly
blur for me.
On Tue, Feb 21, 2017 at 2:35 AM, Kant Kodali wrote:
> Agreed with m
They appear for each repair run and disappear when repair run finishes.
On Tue, Feb 21, 2017 at 11:14 AM, Vincent Rischmann
wrote:
> Hi,
>
> I upgraded to Cassandra 2.2.8 and noticed something weird in nodetool
> tpstats:
>
> Pool NameActive Pending Completed Blocked
Agreed with multiple clients one cannot guarantee the order however with
multiple clients the client side timestamps will overlap as well. so even
in the case of LWT's and multiple clients the order is not guaranteed
right. By multiple clients I mean multiple C* sessions on the driver side.
if mult
Hi,
I upgraded to Cassandra 2.2.8 and noticed something weird in
nodetool tpstats:
Pool NameActive Pending Completed Blocked
All time blocked
MutationStage 0 0 116265693
0 0
ReadStage 1
For eventual consistency, it does not matter if it is sync or async. LWW
always works as long as clocks are synchronized.
Thats a design pattern of CS or EC databases in general. Every write has a
timestamp and no matter at what time it arrives, the last write will win
even if a "sooner" write arri
@Benjamin I am more looking for how C* replication works underneath. There
are few things here that I would need some clarification.
1. Does C* uses sync replication or async replication? If it is async
replication how can one get performance especially when there is an
ordering constraint among r
To me that sounds like a completely different design pattern and a
different use case.
CS was not designed to guarantee order. It was build to be linear scalable,
highly concurrent and eventual consistent.
To me it sounds like a ACID DB better serves what you are asking for.
2017-02-21 10:17 GMT+0
Agreed that async performs better than sync in general but the catch here
to me is the "order".
The whole point of async is to do out of order processing by which I mean
say if a request 1 comes in at time t1 and a request 2 comes in at time t2
where t1 < t2 and say now that t1 is taking longer to
12 matches
Mail list logo
