17
如何将数亿 MySQL 数据无缝迁移到 MongoDB？
source link: https://www.infoq.cn/article/pXKolrLztDNH6fseKwIe
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
在好大夫在线内部，S3系统负责各业务方操作日志的集中存储、查询和管理。目前，该系统日均查询量数千万次，插入量数十万次。随着日志量的不断累积，主表已经达到数十亿，单表占用磁盘空间400G+。S3是业务早期就存在的系统，当时为了简单快速落地，使用了Mysql来存储，随着业务的不断增长，同时也要兼顾性能和可扩展性，到了必须要重新选型的时候了。
新项目命名为：LogStore。
目标
1、安全性
S3系统在设计之初，没有按业务系统考虑数据隔离，而是直接采用 key(系统 + 类名 + id) + 有限固定字段 + 序列化value 的方式进行存储，这种方式显然不便于后续集群拆分和管理。LogStore系统要在逻辑上进行数据区域划分，业务方在接入时要指定app进行必要的权限验证，以区分不同业务数据，进而再进行插入和查询操作。
2、通用性
S3主要提供一种3层结构，采用MySQL固定字段进行存储，这就不可避免的会造成字段空间的浪费。LogStore系统需要提供一种通用的日志存储格式，由业务方自行规定字段含义，并且保留一定程度的可查询维度。
3、高性能
S3系统的QPS在300+，单条数据最大1KB左右。LogStore系统要支持当前QPS 10倍以上的写入和读取速度。
4、可审计
要满足内部安全审计的要求，LogStore系统不提供对数据的更新，只允许数据的插入和查询。
5、易扩展
LogStore系统以及底层存储要满足可扩展特性，可以在线扩容，满足公司未来5年甚至更长时间的日志存储需求，并且要最大化节省磁盘空间。
方案选型
为了达成改造目标，本次调研了四种存储改造方案，各种方案对比如下：
1、我们不合适—分库分表
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK