从容应对游戏应用的海量数据高并发场景

尽管网易游戏已拥有比较全面的数据库产品矩阵，但每种数据库产品在特定业务场景下都有其明显的优势和局限性，鉴于网易内部涵盖的业务场景多样且复杂，希望根据具体的业务场景需求灵活选择适合的数据库产品。

网易游戏某游戏业务平台当前使用 MySQL 的数据库架构，随着系统承接的业务数据量及请求数的不断增加，该架构逐渐演化为 MySQL 经典的一主多从架构，通过主备库接了十余个从库来负责业务读请求。

1. 并发量高，对延迟敏感
   1. 在高峰期，主库请求量达到接近十万 QPS，单个从库读的请求也在几万左右，所有从库的总 QPS 在高峰期接近百万，整体并发量高，我们的业务对延迟极为敏感，不能容忍波动。
2. 单库存储空间压力大
   1. 单节点的存储空间已经超过十几 TB 以上，对于处理高并发 TP 业务的 MySQL 来说，这样的压力是非常巨大的。
3. 从库数据实时性要求
   1. 从库数据实时性要求很高，一旦从库出现慢查询或其他情况影响到从库延迟，会对业务造成极大影响。
4. 运维困难
   1. 运维工作也面临很大的挑战，在突发流量的情况下，即使使用顶级配置的 MySQL 只能通过增加实例的方式来缓解压力。另外，如果单个只读从库出现故障，就需要进行实例重建的操作。由于 MySQL 实例的数据量很大，扩容从库、备份恢复都需要耗费大量时间，这对业务来说是难以接受的。

1. OLTP、OLAP 高性能
   1. OLTP 性能方面，在小规模数据量（10 张表，每张表 2000 万）时，OceanBase 4.0 版本的性能表现几乎与 MySQL 持平，OceanBase 4.1 版本的性能表现优于单机 MySQL；在数据量较大时（1 亿以上）OceanBase 扩容节点后的性能优势远超单机 MySQL；
      1. OLAP 性能方面，在多个大表关联或聚合分析的情况下（1 亿以上）， OceanBase 4.x 版本整体表现相对平稳，并没有出现较大波动，查询耗时也远低于 MySQL
2. 高级压缩技术
   1. 关于存储数据压缩能力，从上游 MySQL 导出 5TB 数据到 OceanBase，三个副本总存储才 2.1TB，单个副本 700GB。以单份数据计算，数据压缩率接近 86%
3. OMS 同步方案
   1. OMS 的逻辑复制方式读取 MySQL Binlog 操作，回放到 OceanBase 集群中，不会出现 MySQL 常见的主从延迟问题。如果出现数据同步延迟、慢查询，OceanBase 都有对应的监控报告。
4. 运维简便
   1. 出现突发流量时，可以通过动态调整租户、集群资源的方式临时应急。出现突发流量或业务上线 SQL 出现慢 SQL 时，可以使用白屏化的 SQL 限流功能。如果需要水平扩容，整个扩容操作对应用无感。同时，在故障场景下，集群的 Paxos 高可用模式基本保障对应用无感。