On Wed, Jun 22, 2011 at 10:19 AM, Oleg Anastastasyev wrote:
> >
> > Is C* suitable for storing customer account (financial) data, as well as
> > billing, payroll, etc? This is a new company so migration is not an
> > issue... starting from scratch.
>
> If you need only store them - then yes, but
but you can store the -details- of a transaction as json data and do
some sanity checks to validate that the data you currently have stored
aligns with the recorded transactions. maybe a batch job run every 24
hours ...
On Wed, Jun 22, 2011 at 4:19 PM, Oleg Anastastasyev wrote:
>>
>> Is C* suita
>
> Is C* suitable for storing customer account (financial) data, as well as
> billing, payroll, etc? This is a new company so migration is not an
> issue... starting from scratch.
If you need only store them - then yes, but if you require transactions spanning
multiple rows or column families
On Tue, Jun 21, 2011 at 10:58 PM, AJ wrote:
> **
> On 6/21/2011 3:36 PM, Stephen Connolly wrote:
>
> writes are not atomic.
>
> the first side can succeed at quorum, and the second side can fail
> completely... you'll know it failed, but now what... you retry, still
> failed... erh I'll store it
On 6/21/2011 3:36 PM, Stephen Connolly wrote:
writes are not atomic.
the first side can succeed at quorum, and the second side can fail
completely... you'll know it failed, but now what... you retry, still
failed... erh I'll store it somewhere and retry it later... where do I
store it?
the
On 6/21/2011 3:14 PM, Anand Somani wrote:
Not sure if it is that simple, a quorum can fail with writes happening
on some nodes (there is no rollback). Also there is no concept of
atomic compare-and-swap.
Good points. I suppose what I need is for the client to implement the
part of ACID tha
And I was thinking of using JTA for transaction processing. I have no
experience with it but on the surface it looks like it should work.
On 6/21/2011 3:31 PM, AJ wrote:
What's the best accepted way to handle that 100% in the client? Retries?
On 6/21/2011 3:14 PM, Anand Somani wrote:
Not sur
writes are not atomic.
the first side can succeed at quorum, and the second side can fail
completely... you'll know it failed, but now what... you retry, still
failed... erh I'll store it somewhere and retry it later... where do I store
it?
the consistency level is about tuning whether reads and
What's the best accepted way to handle that 100% in the client? Retries?
On 6/21/2011 3:14 PM, Anand Somani wrote:
Not sure if it is that simple, a quorum can fail with writes happening
on some nodes (there is no rollback). Also there is no concept of
atomic compare-and-swap.
On Tue, Jun 21,
Not sure if it is that simple, a quorum can fail with writes happening on
some nodes (there is no rollback). Also there is no concept of atomic
compare-and-swap.
On Tue, Jun 21, 2011 at 2:03 PM, AJ wrote:
> **
> On 6/21/2011 2:50 PM, Stephen Connolly wrote:
>
> how important are things like tran
On 6/21/2011 2:50 PM, Stephen Connolly wrote:
how important are things like transactional consistency for you?
would you have issues if only one side of a transfer was recorded?
Right. Both of those questions are about consistency. Isn't the simple
solution is to use QUORUM read/writes?
how important are things like transactional consistency for you?
would you have issues if only one side of a transfer was recorded?
cassandra, out of the box, on it's own, would not be ideal if the above two
things are important for you.
you can add components to a system to help address these t
Is C* suitable for storing customer account (financial) data, as well as
billing, payroll, etc? This is a new company so migration is not an
issue... starting from scratch.
Thanks!
13 matches
Mail list logo
