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
alright to return failure to the client. However, if not,
then it is difficult to program as after every failure, you as an client are
not sure if failure is a pseudo failure with some side effects or real
failure.
Thanks,
Ritesh
quote author='Dave Revell'
Ritesh,
There is no commit
Ritesh,
There don't seem to be any common best practices to do this. I think the
reason is that by adding transaction semantics on top of Cassandra you're
throwing away the most important properties of Cassandra. The effects of a
transaction/locking layer:
- A centralized performance bottleneck
Re Anthony's statement:
So it can be done and frameworks like CAGES are showing a way forward. At
the heart of it, there will need to be a Two-Phase commit type protocol
coordinator that sits in front of Cassandra. Of which - one can be sure -
there
will be many implementations / best
Indexes have another important advantage over multiple denormalized column
families. If you make the copies yourself, eventually the copies will
diverge from the base true column family due to routine occasional
failures. You'll probably want to find and fix these inconsistencies.
If you're using
Yes, this works well for me. I have no SCFs but many columns contain JSON.
Depending on your time/space/compatibility tradeoffs you can obviously pick
you own serialization method.
Best,
Dave
On Feb 8, 2011 4:33 AM, buddhasystem potek...@bnl.gov wrote:
Seeing that discussion here about indexes
Under heavy load, this could be the result of the server not accept()ing
fast enough, causing the number of pending connections to exceed the listen
backlog size in the kernel.
I believe Cassandra uses the default of 50 backlogged connections.
This is one of the reasons why a persistent
