Yelp 的广告分析系统从 MySQL 迁移到了 Cassandra 上

  • 足下

2016 年 8 月 18 日

话题:MySQL语言 & 开发架构

根据 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 的经验也许会对你有用。


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

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

MySQL语言 & 开发架构