为何更新数据存于Memtable时，读操作仍会访问SSTable？

我的数据格式为(id, data)，例如(1, "someDataS")。初始插入数据时，数据存储在Memtable中，读操作直接从Memtable获取；插入更多数据后，数据刷新至SSTable，此时读操作从SSTable获取，这符合预期。但更新已在SSTable中的旧数据后，我认为新版本数据存于Memtable，旧版本仍在SSTable，但执行读操作时仍会检查SSTable，而非直接返回Memtable中的最新版本。我使用查询追踪功能调试，发现相关代码位于SinglePartitionReadCommand.java文件的queryMemtableAndSSTablesInTimestampOrder方法中，该方法似乎总会检查SSTable。请问为何读操作不直接从存储最新版本的Memtable返回更新后的数据？是否存在仍需检查SSTable的原因？

• 处理墓碑与删除逻辑：Cassandra里的删除操作会生成「墓碑」标记，这些墓碑可能存在于SSTable中。如果只读取Memtable，可能会忽略SSTable里的墓碑逻辑——比如先在SSTable里标记某条数据删除（时间戳T1），之后在Memtable里写入同一条数据（时间戳T2>T1），这时候没问题；但如果Memtable里的写入时间戳意外比SSTable的墓碑早（比如节点时钟偏差），直接返回Memtable数据就会导致已删除的数据“复活”，必须检查SSTable才能正确合并这些版本。
• 支持部分列更新：如果更新只修改了行里的部分列，Memtable里只会存储更新的列数据，其他列的数据仍在SSTable中。这时候读操作必须同时读取Memtable和SSTable，把所有列的数据合并后，才能返回完整的行结果。
• 时间戳全局一致性校验：虽然正常情况下Memtable里的新数据时间戳更大，但分布式环境下可能存在节点时钟偏移的极端情况。读取时检查SSTable可以确保不会漏掉任何时间戳更大的版本——毕竟SSTable里也可能存在其他节点同步过来的、时间戳比当前Memtable数据更新的记录。
• 读修复机制的需要：Cassandra的读修复会在读取时对比不同副本的数据，确保数据一致性。这个过程需要读取SSTable中的数据来做校验，不能只依赖Memtable，否则无法完成副本间的数据同步修正。

内容的提问来源于stack exchange，提问作者Raj Pandey