背景
Snapshot 字面意思是“快照”，在数据库中，指的就是数据库在某个时刻全体数据的状态。假定我们在 T1 时刻创建了一个快照 A，那么通过快照 A 就只能看到 T1 时刻之前的数据，看不到 T1 时刻之后的。
MyTopling 与 ToplingDB
MyTopling 是基于 ToplingDB 的 MySQL，分叉自 MyRocks，ToplingDB 则分叉自 RocksDB，兼容 RocksDB 接口，从而 MyTopling 可以复用 MyRocks 的大部分成果。
ToplingDB 早已开源，MyTopling 也会于近期开源，目前我们正处于紧张的内部开发中
RocksDB 的快照
RocksDB 实现了 MVCC，在内部存储中，每条 KV 都附带一个 SeqNum。概念上，在 RocksDB 中，快照本质上就是一个 SeqNum，通过快照访问 RocksDB，只要丢弃大于 SeqNum 的数据，仅保留小于等于 SeqNum 的数据就可以了。
问题
我们开始用 sysbench 测试 MyTopling，prepare 的数据量很大时，对于每个表，插完数据之后，就是创建索引的阶段，这个阶段会花费很长时间，花很长时间这个问题我们已经通过 MyTopling 的 AutoSort SST 解决。
但其实这里还有另一个问题：创建索引时，需要遍历 Table，这是通过 RocksDB 的 Iterator 实现的，而 Iterator 通过其直接持有的 Version 对象，间接持有了一组 MemTable 和 SST。创建索引时，我们的数据插入仍在进行，这时就出问题了，MemTable 满了会 Flush 到 SST，Iterator (间接)持有了 MemTable，从而即便 MemTable 已经 Flush 到 SST 了，但因为 Iterator 的(间接)引用，这些 MemTable 却无法释放。
不像 SST，MemTable 要占用内存，如果 MemTable 无法释放，相应的内存就无法释放，如果时间继续加长，无法释放的 MemTable 就越多，最终就 OOM 了。
一边创建索引，一边持续高负载写入，这样的应用场景不多，这是好事，也是坏事，说它是好事，是因为避免了致命问题，说它是坏事，是因为只要不出事，这个问题就一直被掩盖着，从 MyRocks 诞生一直掩盖至今！
好在问题的解决并不难：我们只需要周期性地 Refresh Iterator 就可以了，最简单的方案就是，记住当前 Key，释放旧的 Iterator，用(跟旧Iterator相同的快照)创建一个新的 Iterator（但是会绑定新的 Version 对象），再 Seek 到记下的 Key 中，然后一切继续。
这个简单的方案为什么能解决问题？释放旧 Iterator 的时候，这个 Iterator 持有的 Version 对象就会被 Unref，从而相应的 MemTable 和 SST 就被释放了。
