Hi, Patricio,
It's hard to comment on your original questions without knowing details of
your own domain specific data model and data processing expectation.
W.R.T. lumping things into one big row, there is a limitation on data model
in Cassandra. You got CF and SCF. That is, you have only 2 leve
2010/7/20 Patricio Echagüe :
> Would it be bad design to store all the data that need to be
> consistent under one big key?
That really depends how unnatural it is from a query perspective. :)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Ca
Hi, regarding the retrying strategy, I understand that it might make
sense assuming that the client can actually perform a retry.
We are trying to build a fault tolerance solution based on Cassandra.
In some scenarios, the client machine can go down during a
transaction.
Would it be bad design to
Hi, Stuart,
If I may paraphrase what Jonathan said, typically your batch_mutate
operation is idempotent.
That is, you can replay / retry the same operation within a short timeframe
without any undesirable side effect.
The assumption behind the "short timeframe" here refers to: there is no
other c
typically you will update both as part of a batch_mutate, and if it
fails, retry the operation. re-writing any part that succeeded will
be harmless.
On Thu, Jul 8, 2010 at 11:13 AM, Stuart Langridge
wrote:
> Hi, Cassandra people!
>
> We're looking at Cassandra as a possible replacement for some
Hi, Cassandra people!
We're looking at Cassandra as a possible replacement for some parts of
our database structures, and on an early look I'm a bit confused about
atomicity guarantees and rollbacks and such, so I wanted to ask what
standard practice is for dealing with the sorts of situation I ou
