这篇文章，包含了一些技术，包含了一些回忆。

今天看了360的有关Cassandra实践的ppt，有一些感想。让我想起了两年前的一些事情，不过那时，我做的不是存储，而主攻的分布式检索。后来一系列变化，我也经历了很多，后来安下心来，做存储优化，优化的对象就是Cassandra，这也有一年多的时间。理论深厚，心得颇丰，可是仍然缺乏一线经验积累。看到360这么大规模的应用Cassandra，我很高兴。尽管，没有一同战斗，但是我很欣慰，很开心。Cassandra终于摆脱阴影，站起来了。

Cassandra在360部署有1500台服务器。国内首屈一指了，还有一家部署规模在这一半左右。不过，单个Cassandra的集群，360是150台，而有一家是256台。从这个数字上看，这两家的用途应该是不一样的：前者主要是随机查询，后者会有较大量的scan之类的操作。360的Cassandra是基于0.7.3改进的，不知道是否可以兼容升级Cassandra1.0之后，因为1.0之后读写的性能，都有较大幅度的提升。而另一家，已经是1.0之后的版本，对一些新特性利用得比较充分。

在采用Cassandra的原因上，我想到了两年前，我们的团队在做人民搜索项目的时候，几乎相同的困境，可能时间更紧，因为我们只有两个月时间。那个时候，Cassandra就更加不成熟，所以，我们选择了Voldemort，相比之下，Voldemort成熟很多，因为Voldemort的后端可以定制，为了性能的考虑，我们做了Mongodb的适配。当时，我们的Voldemort部署规模也在百台服务器以上。支撑着线上的网页搜索、新闻搜索等。历史总是在一幕一幕重演，总是会勾起一些人的回忆。

在使用和改进方面，360也做了一些努力。对于Cassandra本身，360还是基于较早的版本。为了满足线上系统的要求，三分拷贝，quorum一致性。都是比较中规中矩的配置。可是，为了兼顾性能，100%的read repair似乎影响大了一些。因为前边的quorum一致性的保证，可以适当降低read repair的概率。以提升读的性能。看到，360的工程师增加了digest的接口，我不禁想到分布式文档服务器，两年前，我们是基于Voldemort进行修改的，使其支持动态摘要。综合利用服务器的CPU和磁盘。想起那时候，大家为了提高入库速度，一起围着桌子讨论方案。

360关闭了自动的Compaction，这是个比较英明的决定。因为，这样读写会有较明显的提升。我在进行Cassandra优化工作的过程中，考虑最多的也是这个方面。所以，我支持这一操作。不过，由于没有到现场，我并不知道，每天、或者每两个小时的Compaction是增量，还是全量。或者每天的是全量，每两个小时的是增量。Compaction是个讨厌的东西，但是对于更新相对频繁的场景，又不得不做。这里，统计好重复key的分布，定制好Compaction方案即可。大家也可以看我之前的博客，有一些Compaction的讨论。存储文档？存储快照？还是存储实时信息？都要定制不同的Compaction方案。需要实际经验的积累。

总体感觉，360的Cassandra工作，方方面面都做到了，从你们的ppt中，我看到了两年之前，我们奋斗的身影，很怀念那段时光。 另外，同样可以理解，可能也是时间紧、任务重，目前做得不够理想，就Cassandra而言，还是有很大的提升空间的，不知道360的修改，能否适用1.0之后的版本，如果能，强烈建议升级到1.0以后版本。除此之外，我之前博客中提到的一些改进，在实际中，都是很有帮助的。

一个ppt报告，让我很高兴，国内Cassandra的大规模应用越来越好，让我更加舍不得放下这块儿工作；也让我想起，两年前，我和同学们一起奋斗的时光。我要感谢那段日子。感谢那时的同学们：、廖洪申、、、、。感谢那时的老师们：、。我没有写很多，可是我心里有很多的话，这些话，时常在我心里激荡起伏。有一天，会沉淀下来，我会好好写出来。作为我们共同的回忆。