Cassandra 不删除的逻辑删除单元

我在运行卡桑德拉集群

Software version: 2.0.9
Nodes: 3
Replication factor: 2

我有一个非常简单的表，在其中插入和更新数据

CREATE TABLE link_list (
      url text,
      visited boolean,
      PRIMARY KEY ((url))
    );

行上没有过期，我不执行任何删除操作。当我运行应用程序时，由于墓碑形单元格的数量不断增加，其速度会迅速减慢：

Read 3 live and 535 tombstoned cells

它在几分钟内达到数千个

我的问题是，如果我没有进行任何删除，是什么负责生成这些细胞

//更新

这是我用来与Cassandra通过com.datasax.driver对话的实现

public class LinkListDAOCassandra implements DAO {


    public void save(Link link) {
        save(new VisitedLink(link.getUrl(), false));
    }

    @Override
    public void save(Model model) {
        save((Link) model);
    }

    public void update(VisitedLink link) {
        String cql = "UPDATE link_list SET visited = ? WHERE url = ?";
        Cassandra.DB.execute(cql, ConsistencyLevel.QUORUM, link.getVisited(), link.getUrl());
    }

    public void save(VisitedLink link) {
        String cql = "SELECT url FROM link_list_inserted WHERE url = ?";

        if(Cassandra.DB.execute(cql, ConsistencyLevel.QUORUM, link.getUrl()).all().size() == 0) {
            cql = "INSERT INTO link_list_inserted (url) VALUES (?)";
            Cassandra.DB.execute(cql, ConsistencyLevel.QUORUM, link.getUrl());

            cql = "INSERT INTO link_list (url, visited) VALUES (?,?)";
            Cassandra.DB.execute(cql, ConsistencyLevel.QUORUM, link.getUrl(), link.getVisited());
        }
    }

    public VisitedLink getByUrl(String url) {
        String cql = "SELECT * FROM link_list WHERE url = ?";

        for(Row row : Cassandra.DB.execute(cql, url)) {
            return new VisitedLink(row.getString("url"), row.getBool("visited"));
        }

        return null;
    }

    public List<Link> getLinks(int limit) {
        List<Link> links = new ArrayList();
        ResultSet results;

        String cql = "SELECT * FROM link_list WHERE visited = False LIMIT ?";

        for(Row row : Cassandra.DB.execute(cql, ConsistencyLevel.QUORUM, limit)) {
            try {
                links.add(new Link(new URL(row.getString("url"))));
            }
            catch(MalformedURLException e) { }
        }

        return links;
    }
}

//更新2

从cfstats中有一个有趣的发现，只有一个表有墓碑。它是

link\u list\u访问的

。这是否意味着使用二级索引更新列将创建墓碑

Table (index): link_list.link_list_visited
                SSTable count: 2
                Space used (live), bytes: 5055920
                Space used (total), bytes: 5055991
                SSTable Compression Ratio: 0.3491883995187955
                Number of keys (estimate): 256
                Memtable cell count: 15799
                Memtable data size, bytes: 1771427
                Memtable switch count: 1
                Local read count: 85703
                Local read latency: 2.805 ms
                Local write count: 484690
                Local write latency: 0.028 ms
                Pending tasks: 0
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used, bytes: 32
                Compacted partition minimum bytes: 8240
                Compacted partition maximum bytes: 7007506
                Compacted partition mean bytes: 3703162
                Average live cells per slice (last five minutes): 3.0
                Average tombstones per slice (last five minutes): 674.0

---

辅助索引与手动保存索引的额外列族之间唯一的主要区别在于，辅助索引仅包含有关当前节点的信息（即，它不包含有关其他节点数据的信息）主表更新后对次索引的操作是原子操作。除此之外，您可以将其视为具有相同弱点的常规列族，主列族上的大量更新将导致索引表上的大量删除，因为主表上的更新将转换为索引表上的删除/插入操作。索引表中所说的删除是墓碑的来源。Cassandra删除是逻辑删除，直到下一个修复过程（删除墓碑时）

---

希望有帮助

你用的是什么客户机？发布用于插入数据的代码。。。如果您使用cqlsh来放置数据，这种情况还会发生吗？com.datastax.driver-我在描述中添加了我的代码。我想到的唯一一件事是表是使用默认ttl创建的。。。您能打印一份表格输出吗？如果您使用cqlsh放置数据，它们会消失吗？请查看我的第二次更新。看起来用二级索引更新列将生成墓碑。不知道该怎么做。是的，我经常用二级索引更新这个列。每个记录都将以“visted=False”开头，目的是将它们全部转换为“visted=True”。我得出的结论是，我使用卡桑德拉的方式不正确。我知道不鼓励排队，但我认为如果我不运行删除，就有可能逃脱惩罚。

Table (index): link_list.link_list_visited
                SSTable count: 2
                Space used (live), bytes: 5055920
                Space used (total), bytes: 5055991
                SSTable Compression Ratio: 0.3491883995187955
                Number of keys (estimate): 256
                Memtable cell count: 15799
                Memtable data size, bytes: 1771427
                Memtable switch count: 1
                Local read count: 85703
                Local read latency: 2.805 ms
                Local write count: 484690
                Local write latency: 0.028 ms
                Pending tasks: 0
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used, bytes: 32
                Compacted partition minimum bytes: 8240
                Compacted partition maximum bytes: 7007506
                Compacted partition mean bytes: 3703162
                Average live cells per slice (last five minutes): 3.0
                Average tombstones per slice (last five minutes): 674.0