根据Yelp今年第二季度财报，本地广告商数量已经约有12.8万个。Yelp的广告系统每天都要结算上一天广告被查看的次数和点击数，以及对应需要支付的费用。基于这样的结算数据，Yelp要生成账单以及各种各样的报告。

广告系统后台团队最近把底层数据存储从MySQL换成了Cassandra，软件工程师Qui N.和Shafi B.发表文章简单介绍了改变的原因，并分享了一些向Cassandra迁移的经验。

在Yelp公司创立初期，我们把广告数据存储在了MySQL中。伴随着系统规模扩大和广告产品的演进，我们发现Cassandra才是更好的选择。我们并不需要传统关系型数据库的特性，因为我们没有什么事务操作，也不需要对数据表进行联合查询。Cassandra对我们最大的好处就是方便扩展存储、有弹性的模式定义和高写入性能。

具体来说就是：

方便扩展存储：Cassandra是分布式系统，只需要增加节点就可以扩充存储空间； 有弹性的模式定义：业务需求会经常要求改动数据的模式定义，Cassandra很适合做这样的事； 高写入性能：Cassandra写入性能是非常高的，Netflix曾经在一次测试中达到每秒超过100万次的写入；由于Yelp的广告数据越来越多，写入必须保持在有限的时间内完成；

文章重点是与大家分享在使用Cassandra的过程中得到的经验。

1、把查询语句和表的模式定义放在一起综合考虑：Cassandra本质上是结构型的键-值型存储，表的主键选择对后续的查询语句性能影响非常大。Cassandra的表主键包括分区键和集合列，前者决定了数据能否均匀分散到多个节点上，后者决定了相同分区键的数据在同一个分区内如何排序。要根据查询语句决定表的定义，反之也要根据表的定义来改写查询语句，两者综合才能达到最佳性能。

2、数据行定义会影响数据压缩：Cassandra的数据压缩就是合并对数据的更新操作的过程。业务程序更新数据的次数和方式决定着该选择Cassandra的哪种压缩策略。

其根本原因在于在Cassandra底层是把属于每个分区键的数据以宽行存储的。以Yelp的业务举例，以campaign_id为分区键，以day为集合列，那么在底层数据其实是这样存储的：

　　而不是大家想当然的这样：

Cassandra的默认策略size-tiered compaction合并操作并不频繁，而leveled compaction会保证未合并的对相同分区键的更新操作不会超过一定数量，因此虽然在写入时会造成更多的I/O，却对统计查询有比较好的性能，因此更适合Yelp的业务。

3、迁移到Cassandra会增大写入量：使用MySQL会希望表设计遵守范式，可使用Cassandra之类的NoSQL数据库，违反范式反而常常会获得更好的性能。虽然Cassandra出色的写性能在一定程度上可以弥补这一代价，但千万不要对此掉以轻心。

4、Cassandra的批量操作语句很有用：MySQL的批量操作语句常用来提高性能，可是Cassandra的批量操作语句却常常只是用来保证原子性的。因为Yelp选用的cqlengine在底层写入操作是同步的，在写入量大的情况下就性能堪忧，因此他们最终通过批量写入来解决这个问题。批量操作上线后立刻将写入性能提高了一倍。

5、TTL机制可能带来的麻烦更多：Cassandra支持为每个字段设置生命期（Time To Live，TTL），如果某个字段设置了TTL，那么在过期之后就会自动删除，不再需要用户操心。可是对于Yelp的这种分析型业务，由于需求的不确定性，设置这种TTL数据可能还不如定期检查删除一遍对整个系统影响更小。

相对于MySQL，Yelp因为Cassandra的易扩展、有弹性的模式定义和高写入性能等特性而选择了后者。如果你也在构建一个写入量很大的系统，或者在重构系统，那Yelp的经验也许会对你有用。

感谢杜小芳对本文的审校。