Comments on: Cassandra Internals – Writing

By: amalendu

amalendu — Thu, 14 Apr 2011 18:08:27 +0000

Hi MIke,

Thanks for the post .

I have a question :

“Append the mutation to the commit log for transactional purposes”

Is this a Synchronous Disk Operation ?

means, does commit wait for this disk write ?

By: 夏客行 » Cassandra内核介绍–写操作

夏客行 » Cassandra内核介绍–写操作 — Sat, 04 Dec 2010 02:29:45 +0000

[...] Cassandra内核介绍–写操作 by Mike Perham Translated by Jametong [...]

By: Cassandra Write Operation Performance Explained | All in one for social - Blog

Mon, 08 Nov 2010 08:00:03 +0000

[...] Performance, Technology by Nguyễn Bá Khoa — Leave a comment08/11/2010 Number of View: 6An ☞ interesting explanation of how Cassandra write ops are happening:client submits its write request to a single, random [...]

By: Ankit Jhalaria

Ankit Jhalaria — Wed, 22 Sep 2010 23:35:05 +0000

Awesome Post!! Helped me a lot.
Thanks

By: Mike Perham

Mike Perham — Mon, 20 Sep 2010 01:36:02 +0000

Joshua, no it just means that Cassandra does not perform updates internally. Everything is an insert. Old values are “garbage collected” during the compaction operation. To you it looks like an update.

By: Joshua Partogi

Joshua Partogi — Sun, 19 Sep 2010 21:36:35 +0000

Mike, nice write up. One question though, does that mean that we can not update our data in cassandra? Does that mean we have to delete and insert new record if we want to update our data?

Cheers

By: Cassandra内核介绍–写操作 « a db thinker's home

Cassandra内核介绍–写操作 « a db thinker's home — Sun, 30 May 2010 04:03:46 +0000

[...] Cassandra内核介绍–写操作 by Mike Perham Translated by [...]

By: jametong

jametong — Sat, 29 May 2010 06:38:29 +0000

Oracle has use dbwr/lgwr/ckpt systm processes do similar jobs as Cassandra does. I refer it as change sync jobs to async jobs, and change random i/o to sequential i/o. Cassandra does it both in Commit log and SSTable.

By: Steve Lihn

Steve Lihn — Mon, 24 May 2010 01:55:53 +0000

Nice article. Just curious when you said “Unlike a database, Cassandra does not update data in-place on disk, nor update indices, so there’s no intensive synchronous disk operations to block the write.”, which database are you referring to? Oracle can modify data blocks in memory and only write the redo log to disk, then move on. It seems to be Cassandra is similar to what Oracle is doing in this respect, isn’t it?

By: OCTO talks ! » no:sql(eu) et NoSQL : qu’en est il?

OCTO talks ! » no:sql(eu) et NoSQL : qu’en est il? — Thu, 22 Apr 2010 22:00:16 +0000

[...] – NoSQL concerne l’utilisation de la donnée et nous rappelle qu’un point important – et je pense souvent oublié dans nos SIs traditionnels – est de comprendre comment la donnée est utilisée. Un système peut vivre avec de la donnée inconsistante. En fait, c’est déjà le cas si vous utilisez les mécanismes de réplication Master/Slave, du cache ou simplement l’utilisation de messages asynchrones. Juste se demander comment sera utiliser la donnée. Que se passera-t-il du point de vue du métier si mon opération (disons un retrait) est consistant mais que mon solde reste inconsistant pendant quelques secondes ou même quelques minutes? Ma donnée sera-t-elle accéder de manière concurrente? Y aura-t-il une forte probabilité de conflit sur cette donnée? En cas de conflit, de quelle stratégie de « read-repair » aurai-je besoin (un modèle type Vector Clock ou plus simplement l’approche timestamp de Cassandra)? Combien de temps y a t-il entre le moment ou j’écris ma donnée et le moment où elle est lue? Du coup, quelle est la probabilité de « Stale State »? S’il y a un une heure entre les deux opérations, la probabilité est faible… Ma donnée est-elle plutôt utilisée en écriture ou en lecture? Certains de ces systèmes ont été optimisés pour l’écriture. Par exemple, Cassandra réalise plus d’accès disque pour une lecture que pour une écriture. [...]