当前位置:企业应用软件行业动态 → 正文

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

责任编辑:editor004 作者:足下 |来源:企业网D1Net  2016-08-19 12:02:34 本文摘自:INFOQ

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

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

关键字:Cassandra Yelp

本文摘自:INFOQ

Yelp的广告分析系统从MySQL迁移到了Cassandra上 扫一扫
分享本文到朋友圈

关于我们联系我们版权声明友情链接广告服务会员服务投稿中心招贤纳士

企业网版权所有©2010-2021 京ICP备09108050号-6

^