Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "ArchitectureInternals" page has been changed by RobertColi. The comment on this change is: changed where the reference to Table.Apply appears in the "on the destination node" write path line about RowMutationVerbHandler, for clarity.. http://wiki.apache.org/cassandra/ArchitectureInternals?action=diff&rev1=14&rev2=15 -------------------------------------------------- * !StorageProxy gets the nodes responsible for replicas of the keys from the !ReplicationStrategy, then sends !RowMutation messages to them. * If nodes are changing position on the ring, "pending ranges" are associated with their destinations in !TokenMetadata and these are also written to. * If nodes that should accept the write are down, but the remaining nodes can fulfill the requested !ConsistencyLevel, the writes for the down nodes will be sent to another node instead, with a header (a "hint") saying that data associated with that key should be sent to the replica node when it comes back up. This is called HintedHandoff and reduces the "eventual" in "eventual consistency." Note that HintedHandoff is only an '''optimization'''; ArchitectureAntiEntropy is responsible for restoring consistency more completely. - * on the destination node, !RowMutationVerbHandler hands the write first to !CommitLog.java, then to the Memtable for the appropriate !ColumnFamily (through Table.apply). + * on the destination node, !RowMutationVerbHandler uses Table.Apply to hand the write first to !CommitLog.java, then to the Memtable for the appropriate !ColumnFamily. * When a Memtable is full, it gets sorted and written out as an SSTable asynchronously by !ColumnFamilyStore.switchMemtable * When enough SSTables exist, they are merged by !ColumnFamilyStore.doFileCompaction * Making this concurrency-safe without blocking writes or reads while we remove the old SSTables from the list and add the new one is tricky, because naive approaches require waiting for all readers of the old sstables to finish before deleting them (since we can't know if they have actually started opening the file yet; if they have not and we delete the file first, they will error out). The approach we have settled on is to not actually delete old SSTables synchronously; instead we register a phantom reference with the garbage collector, so when no references to the SSTable exist it will be deleted. (We also write a compaction marker to the file system so if the server is restarted before that happens, we clean out the old SSTables at startup time.)
