| 词条 | Tombstone (data store) |
| 释义 |
A tombstone is a deleted record in a replica of a distributed data store.[1] The tombstone is necessary, as distributed data stores use eventual consistency, where only a subset of nodes where the data is stored must respond before an operation is considered to be successful. MotivationIf information is deleted in an eventually-consistent distributed data store, the "eventual" part of the eventual consistency causes the information to ooze through the node structure, where some nodes may be unavailable at time of deletion. But a feature of eventual consistency causes a problem in case of deletion, as a node that was unavailable at that time will try to "update" the other nodes that no longer have the deleted entry, assuming that they have missed an insert of information. Therefore, instead of deleting the information, the distributed data store creates a (usually temporary) tombstone record, which is not returned in response to requests.[1] Removal of tombstonesIn order not to fill the data store with trash information, there is a policy to remove tombstones completely. For this, the system checks the age of the tombstone and will remove it after a prescribed time has elapsed. In Apache Cassandra, this elapsed time is set with the ConsequencesBecause of the delayed removal, the deleted information will appear as empty, after the content of some columns of a number of records has been deleted. After a compaction, the unused columns will be removed from these records.[2] {{database-stub}}References1. ^1 2 {{cite web| accessdate = 2011-04-13| location = http://wiki.apache.org/cassandra/FrontPage| publisher = CassandraWiki| title = DistributedDeletes | quote = Thus, the "eventual" in eventual consistency: if a client reads from a replica that did not get the update with a low enough ConsistencyLevel, it will potentially see old data. [...] There's one more piece to the problem: how do we know when it's safe to remove tombstones? [...] [It] defined a constant, GCGraceSeconds, and had each node track tombstone age locally. Once it has aged past the constant, it can be GC'd during compaction (see MemtableSSTable).| url = http://wiki.apache.org/cassandra/DistributedDeletes}} 2. ^{{cite web| accessdate = 2011-04-13| location = https://github.com/| publisher = github SOCIAL CODING| title = User Guide: Dealing with Tombstones| quote = To put this in the context of an example, say we have just created 10 rows of data with three columns each. If half the columns are later deleted, and a compaction has not yet occurred, these columns will show up in get_range_slices queries as empty. Using RangeSlicesQuery as described in the previous section, we would have 10 results returned, but only five of them will have values. More importantly, calls to get (via ColumnQuery) by design assume the Column you are retrieving exists in the store. Therefore if you call get on tombstoned data, null is returned (note: this is different than previous versions of Hector where the underlying NotFoundException was propagated up the stack).| url = https://github.com/rantav/hector/wiki/User-Guide}} External links
1 : Distributed data stores |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。