Reading before writing段告诉写入之前的读取对cassandra性能有一点影响。但storage engine告诉cassandra本身在写入场景之前避免读取。
在我的情况下，我需要读取行上的“see”并依赖条件将其写回。那么总的来说cassandra是否适用于这种场景？
答案 0 :(得分：5)
由于一致性问题，Read-before-write通常被认为是Cassandra中的反模式。性能可能也会受到影响，但更重要的是，根据先前的读取修改数据永远不会安全，因为这些值可能会由另一个进程同时更改。 storage engine页面实际上很好地解释了它。
您可以做的是使用CAS操作，或称为“light weight transactions”。每个CAS更新都将基于一个条件，例如：先前的值。这将确保仅在行的相关部分未更改时才应用更新。虽然LWT应该可以正常工作，但可扩展性和性能将比常规更新差很多。
答案 1 :(得分：1)
您的用例没有任何表明Cassandra不是一个好的技术，但它取决于您的读/写比率。
如果您要具有较高的读/写比率（即如果您的条件通常是假的，并且您很少需要回写该行），那么考虑您的压缩策略非常重要。请阅读when to use levelled compaction from DataStax以获取有关使用哪种压缩策略的建议。
术语＆＃34;在写之前阅读＆＃34;在你的存储引擎链接中谈论的是Cassandra必须在磁盘上执行的读操作，这是完成＆＃34;写＆＃34;来自客户端的查询。这并不意味着您的客户端发送读取请求后写入请求的情况。
如果您的读/写比率接近1，如果您可以更改数据模型以避免在写入查询之前执行读取查询的这种模式，那么您将能够从Cassandra获得更好的性能
如果在考虑了同一群集的所有其他用法之后，您将具有较低的读/写比率（写入比读取多得多），那么Cassandra非常擅长这一点而你可能不会这样做需要担心。