Cassandra: atomic eller eventual

[kongen]

Er Cassandra en database som utfører "atomic transactions" eller bruker den "eventual transactions"?

 

[adeneo]

Cassandra er som Ole Brum, ja takk begge deler ?

Cassandra er ikke "ACID compliant" som det heter så fint, men cassandra skriver fremdeles atomisk til databasen per rad, altså dersom en innsetting feiler, så feiler hele innsettingen for den raden, men ikke nødvendigvis hele spørringen.

Fra dokumentasjonen :

Atomicity in Cassandra

In Cassandra, a write is atomic at the row-level, meaning inserting or updating columns for a given row key will be treated as one write operation. Cassandra does not support transactions in the sense of bundling multiple row updates into one all-or-nothing operation. Nor does it roll back when a write succeeds on one replica, but fails on other replicas. It is possible in Cassandra to have a write operation report a failure to the client, but still actually persist the write to a replica.

For example, if using a write consistency level of QUORUM with a replication factor of 3, Cassandra will send the write to 2 replicas. If the write fails on one of the replicas but succeeds on the other, Cassandra will report a write failure to the client. However, the write is not automatically rolled back on the other replica.

Cassandra uses timestamps to determine the most recent update to a column. The timestamp is provided by the client application. The latest timestamp always wins when requesting data, so if multiple client sessions update the same columns in a row concurrently, the most recent update is the one that will eventually persist

Så er det altså noe som kalles BASE (Basically Available, Soft state, Eventual consistency, legg også merke til ordspillet, BASE vs ACID (base vs syre)).

Både Netflix og Ebay bruker i dag Cassandra, og driver med en del testing, og her er en video hvor Netflix forklarer noe vedrørene eventual consistency

og igjen noe fra dokumentasjonen for Cassandra

Cassandra does not use RDBMS ACID transactions with rollback or locking mechanisms, but instead offers atomic, isolated, and durable transactions with eventual/tunable consistency that lets the user decide how strong or eventual they want each transaction’s consistency to be.

 

[kongen]

Cassandra er ikke "ACID compliant" som det heter så fint, men cassandra skriver fremdeles atomisk til databasen per rad, altså dersom en innsetting feiler, så feiler hele innsettingen for den raden, men ikke nødvendigvis hele spørringen.

Kan ikke dette ødelegge mye av systemet når det er avhengig av riktig data?

Hvis man har 5 filmer og 5 bøker til salgs, og kun én bestillingsside hvor kunder kan krysse av for hvilke filmer og bøker de ønsker å kjøpe, taste inn leverigsadresse og kredittkortopplysninger. Alt på samme side. Kan man risikere at kunder som betaler for 5 filmer og 5 bøker får registrert kun 3 filmer i bestillingen når hvert produkt i ordren registreres i egen rad?

Passer RDBMS best til bestillingsdata og Cassandra til ikke-kritisk data slik som adfersdata etc?

Så er det altså noe som kalles BASE (Basically Available, Soft state, Eventual consistency, legg også merke til ordspillet, BASE vs ACID (base vs syre)).

Skal lese meg opp på dette.

 

[kongen]

Hva med disse NewSQL databasene, disse skal visst være full ACID kompatibel. Vil ikke disse danke ut de fleste av NoSQL databasene når man risikerer å miste data med NoSQL?

http://en.wikipedia.org/wiki/NewSQL

 

[Hashead]

Har testet nuodb, som er så vidt jeg er kjent den ledende newsql databasen. En elastisk sql-server om du vil.
Virka helt rått på papiret, men når jeg testet det for ca et år siden var det for meg ganske tydelig at den ikke er moden nok til at jeg er villig til å gi slipp på postgres/mysql.

Jeg mener at kan få det beste fra begge verdener ved å kjøre nosql sammen med sql.