And everyone has a bias - and I think most people working with any of these
solutions realizes that.
I think it's interesting how many organizations use multiple data storage
solutions versus just using one as they have different capabilities - like the
recent Netflix news about using different
Yeah - no worries - I don't think anyone was thinking you were trying to drink
kool-aid or selling anything. Jonathan was just pointing out thoughtful
replies to his claims.
This past year, Michael Stonebraker with voltdb and other things seems to have
tried to take advantage of momentum behin
Though you are not really implying that, I am not selling anything. I
don't work for VoltDB. I had other issues for my use case with the
software when I was evaluating it (their claim of durability is weak
according to me. Though it does not matter I'd rather they call
themselves NOSQL. they just g
That article is heavily biased by "I am selling a competitor to Cassandra."
First, read Coda's original piece if you haven't:
http://codahale.com/you-cant-sacrifice-partition-tolerance/
Then, Jeff Darcy's response: http://pl.atyp.us/wordpress/?p=3110
On Thu, Feb 24, 2011 at 2:56 PM, A J wrote:
He has a product to sell, so you can expect some advertising. But in
general, Stonebraker's articles are very deep (another one that
challenges general conceptions is
http://voltdb.com/voltdb-webinar-sql-urban-myths ) . He is the creator
of Postgres and considered a guru in databases by many.
And a
Sylvain Lebresne datastax.com> writes:
> However, if that simple conflict detection/resolution mechanism is not good
enough for some of your use case and you need to keep two concurrent updates,
it
is easy enough. Just make sure that the update don't end up in the same column.
This is easily
On Thu, Feb 24, 2011 at 3:56 PM, A J wrote:
> While we are at it, there's more to consider than just CAP in distributed :)
> http://voltdb.com/blog/clarifications-cap-theorem-and-data-related-errors
>
> On Thu, Feb 24, 2011 at 3:31 PM, Edward Capriolo
> wrote:
>> On Thu, Feb 24, 2011 at 3:03 PM,
While we are at it, there's more to consider than just CAP in distributed :)
http://voltdb.com/blog/clarifications-cap-theorem-and-data-related-errors
On Thu, Feb 24, 2011 at 3:31 PM, Edward Capriolo wrote:
> On Thu, Feb 24, 2011 at 3:03 PM, A J wrote:
>> yes, that is difficult to digest and one
On Thu, Feb 24, 2011 at 3:03 PM, A J wrote:
> yes, that is difficult to digest and one has to be sure if the use
> case can afford it.
>
> Some other NOSQL databases deals with it differently (though I don't
> think any of them use atomic 2-phase commit). MongoDB for example will
> ask you to read
yes, that is difficult to digest and one has to be sure if the use
case can afford it.
Some other NOSQL databases deals with it differently (though I don't
think any of them use atomic 2-phase commit). MongoDB for example will
ask you to read from the node you wrote first (primary node) unless
you
The leap of faith here is that an error does not mean a clean backing out to
prior state - as we are used to with databases. It means that the operation
in error could have gone through partially
Again, this is not an absolutely unfamiliar territory and can be dealt with.
-JA
On Thu, Feb 24, 201
>>but could be broken in case of a failed write<<
You can think of a scenario where R + W >N still leads to
inconsistency even for successful writes. Say you keep W=1 and R=N .
Lets say the one node where a write happened with success goes down
before it made to the other N-1 nodes. Lets say it goe
Thanks all for good detail and clarification. I just wanted to get things
clear and understand correctly what is the expected behavior when working
with Cassandra against various failure conditions so that application can be
designed accordingly and provide proper locking/synchronization if require
I see the point - apologies for putting everyone through this!
It was just militating against my mental model.
In summary, here is my take away - simple stuff but - IMO - important to
conclude this thread (I hope):-
1. I was splitting hair over a failed ( partial ) Q Write. Such an event
should b
On Thu, Feb 24, 2011 at 6:33 PM, Anthony John wrote:
> Completely understand!
>
> All that I am quibbling over is whether a CL of quorum guarantees
> consistency or not. That is what the documentation says - right. IF for a CL
> of Q read - it depends on which node returns read first to determine
Completely understand!
All that I am quibbling over is whether a CL of quorum guarantees
consistency or not. That is what the documentation says - right. IF for a CL
of Q read - it depends on which node returns read first to determine the
actual returned result or other more convoluted conditions
On Thu, Feb 24, 2011 at 6:01 PM, Anthony John wrote:
> If you are correct and you are probably closer to the code - then CL of
> Quorum does not guarantee a consistency.
If the operation succeed, it does (for some definition of consistency which
is, following reads at Quorum will be guaranteed
If you are correct and you are probably closer to the code - then CL of
Quorum does not guarantee a consistency.
On Thu, Feb 24, 2011 at 10:54 AM, Sylvain Lebresne wrote:
> On Thu, Feb 24, 2011 at 5:34 PM, Anthony John wrote:
>
>> >>Time stamps are not used for conflict resolution - unless is is
>Time stamps are not used for conflict resolution - unless is is part of the
application logic!!!
This is false. In fact, the main reason Cassandra keeps timestamps is to do
conflict resolution. If there is a conflict between two replicas, when doing
a read or a repair, then the highest timestamp
On Thu, Feb 24, 2011 at 5:34 PM, Anthony John wrote:
> >>Time stamps are not used for conflict resolution - unless is is part of
>> the application logic!!!
>>
>
> >>What is you definition of conflict resolution ? Because if you update
> twice the same column (which
> >>I'll call a conflict), the
>
> >>Time stamps are not used for conflict resolution - unless is is part of
> the application logic!!!
>
>>What is you definition of conflict resolution ? Because if you update
twice the same column (which
>>I'll call a conflict), then the timestamps are used to decide which update
wins (which I
On Thu, Feb 24, 2011 at 3:22 AM, Anthony John wrote:
> Apologies : For some reason my response on the original mail keeps bouncing
> back, thus this new one!
> > From the other hand, the same article says:
> > "For conditional writes to work, the condition must be evaluated at all
> update
> > si
consistency level. So if client chooses R + W > N, then it
> should be possible for Cassandra to detect conflicts.
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/New-Chain-for-Does-Cassandra-use-vector-clocks-tp6058892p6059594.
iew this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/New-Chain-for-Does-Cassandra-use-vector-clocks-tp6058892p6059594.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at
Nabble.com.
On Wed, Feb 23, 2011 at 9:28 PM, Ritesh Tijoriwala
wrote:
> I was about to ask what Anthony's latest post below captures - if we don't
> have vector clocks and no locking, how does cassandra prevent/detect
> conflicts? This is somewhat related to the question I asked in last post
> - http://cassan
I was about to ask what Anthony's latest post below captures - if we don't
have vector clocks and no locking, how does cassandra prevent/detect
conflicts? This is somewhat related to the question I asked in last post -
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/How-does-Cassan
Apologies : For some reason my response on the original mail keeps bouncing
back, thus this new one!
> From the other hand, the same article says:
> "For conditional writes to work, the condition must be evaluated at all
update
> sites before the write can be allowed to succeed."
>
> This means, th
27 matches
Mail list logo
