cassandra百亿级数据库迁移实践

迁移背景

cassandra集群隔段时间出现rt飙高的问题，带来的影响就是请求cassandra短时间内出现大量超时，这个问题发生已经达到了平均两周一次的频率，已经影响到正常业务了。而出现这些问题的原因主要有以下3点：

1. 当初设计表的时候partition key设计的不是很合理，当数据量上去（最大的单表行数达到百亿级）之后，出现了一些数据量比较大的partition。单partition最多的数据量达到了上百万行（cassandra不支持mysql的limit m, n的查询），当查询这个partition的数据时，会带来比较大的压力。
2. cassandra本身的墓碑机制，cassandra的一大特性就是快速写入，如果遇到delete一条记录时，cassandra并不会实时的对这条记录做物理删除，而是在这行记录上添加一个逻辑删除的标志位，而下次查询会load出这些已经删除了的记录，再做过滤。这样就可能带来及时某个partition的查询出的数据量不大，但是墓碑比较多的时候会带来严重的性能问题。
3. 公司dba也不推荐使用cassandra，出现问题的时候，难于定位解决问题。所以决定将cassandra数据库迁移至社区比较成熟的关系型数据库mysql。

迁移方案

整个迁移方案主要分为以下5个步骤：

1. 全量迁移：搬迁当前库中所有的历史数据（该过程会搬掉库中大部分数据）
2. 增量迁移：记录全量迁移开始的时间，搬迁全量迁移过程中变更了的数据
3. 数据比对：通过接口比对cassandra和mysql中的数据，最终数据一致性达到一定99.99%以上
4. 开双写：通过数据比对确保全量迁移和增量迁移没问题以后，打开双写。如果双写有问题，数据比对还可以发现双写中的问题。
5. 切mysql读：确保双写没问题以后，然后根据服务的重要性级别，逐步按服务切mysql读。所有服务切mysql读以后，确保没问题后关闭cassandra写，最终下线cassandra。

mysql的分库分表方案

1. 分多少张表？在DBA的推荐下，单表的数据最好不要超过200w，估算了下最大一张表数据量100亿左右，再考虑到数据未来数据增长的情况，最大的这张表分了8192张表，单表的数据量120w左右，总共分了4个物理库，每个库2048张表。
2. 字段对应的问题？ 这里需要权衡一个问题，cassandra有List、Set、Map等结构，到mysql这边怎么存？这里可以根据自己实际情况选择，
   • 集合结构的转成json之后长度都在1000个字符以内的，可以直接转成json用varchar来保存，优点：处理起来简单。缺点：需要考虑集合的数据增长问题。
   • 转成json之后长度比较长，部分已经达到上万个字符了，用单独的一张表来保存。优点：不用考虑集合的数据增长问题。缺点：处理起来麻烦，需要额外维护新的表。
3. mysql分片键的选择，我们这里直接采用的cassandra的p