本文将介绍六棱镜关于企业分布式数据库的选型实践，希望帮助有相似应用场景的企业用户高效的进行数据库选型。
作者：白云龙
六棱镜运维负责人，负责业务平台、政务云及项目环境部署维护相关技术支撑工作、多年系统运维架构及数据库维护经验、专注开源领域。
六棱镜（杭州）科技有限公司是一家聚焦大科创领域多维数据融合应用与AI算法研发的数字科技公司，公司关联融合了产业、企业、知识产权、投资并购、科技文献、人才等多维数据资源，打造了大科创数字底座 TIbse，自主开发了全球产业科技情报分析系统（PatNavi）、AI 知识产权官（AIPO)及智树（DITree），面向产业分析、企业研发、政府招商、投资尽调及知识产权资产经营管理等场景需求提供 saas 与定制开发服务。
遇到了哪些问题及挑战
随着当前数据量的不断增长，数据在经过大数据集群清洗处理后写入在 MySQL 环境时，写入时间随着数据量增大，并发增多，耗时越来越长，频繁出现超时、任务中断等性能瓶颈，同时数据出仓入仓转存也变得缓慢、效率低下
1）数据量增长快，单机 MySQL 性能低下的同时 DDL 异常缓慢
对于知识产权型公司的六棱镜来说，数据是至关重要的核心资产且具有一定的特殊性，目前业务数据总量已接近30T，数据处理还要经过大数据集群，单机 MySQL 性能低下，无法很好地支持业务发展
2）业务特殊性，数据不适合拆分提升性能
六棱镜的业务及数据特殊性决定了很多数据不适合拆分，主要表现在：业务数据在大数据平台不方便进行分库分表处理，测试发现在经过业务改造和适配之后，尝试通过分库分表模式通过 MyCAT 在后端提供多个数据存储节点，但测试结果并不理想，速度虽然稍有提升，但效果并不明显，且需要维护多个节点，极大增加运维复杂度，同时分表后项目不能使用表空间还原的方式。基于以上考虑，放弃使用分库分表方案
3）资源弹性伸缩能力差
正常情况下各项目需要很小的资源即可运行，但项目数据的周更新及月更新需要大量写入，导致默认资源不足，需临时扩容 CPU 和内存容量提供合适的计算资源。同时在数据批量更新结束后为避免资源浪费，需通过降配操作把资源提供给其他需要的服务进行动态扩容。但降配需关机调整实例（CPU、内存、空间），这将会大大增加运维工作复杂度，服务器频繁重启的同时也导致了服务可用性的降低。
4）多项目多 MySQL 实例，规模与日俱增，运维复杂度和故障处理风险增加
此外，特殊业务对应的特殊数据库需要单独维护，每个实例单独维护成本也偏高。基于上述问题，需要探索新的技术方案来解决业务遇到的痛点问题，经过多次数据库产品调研和测试，最终选择原生分布式数据库 OceanBase 社区版解决方案。
为什么选择 OceanBase
在进行产品选型时，我们认为一个好的解决方案需满足五点：可扩展、高性能、高可用、多租户以及兼容性。
高性能及高可用是我们选择数据库产品的关键因素，可扩展对我们来说也至关重要，要求数据库资源不足时，通过扩展节点把资源池强化。另外，可拓展还意味着资源的可扩展， CPU 及内存资源可按需动态升降配且无需开机关机操作。兼容性对六棱镜来说，也是重要的考虑因素，要求不同类型数据库之间的传输、数据的出入仓都保持兼容，OceanBase 社区版完全满足我们的要求，体现在：
01 高性能
在实际测试过程中，同等条件下，相比 MySQL 环境，OceanBase 数据删除速度比 MySQL 快 3 倍，同时在业务进行 DDL 建表时，OceanBase 速度提升将近 300 倍
02 高可用
OceanBase 三副本部署方式，在删掉或者人为干预下一个节点异常时，数据可以正常访问，单服务器故障能够自愈，整个过程不需要人工干预，这确实是一个亮点
03 MySQL 高度兼容
OceanBase 与 MySQL 高度兼容，那么在进行 MySQL业务和数据迁移时，可以平滑迁移至 OceanBase，对应用和业务的侵入性降至最低。六棱镜内部有 MySQL 5.6、MySQL 5.7、MySQL 8等版本，经测试所有业务数据可直接用到 OceanBase 上，降低了迁移成本
04 高压缩比
根据公司的实际情况做了测试及对比分析，MySQL 数据迁移至 OceanBase 后，磁盘空间利用率可节省70%左右
05 多租户
多租户能力是我们迫切需要的功能。六棱镜现有业务涉及到众多政务云项目，在使用 OceanBase 前，每一个业务的每一个项目都需要有 MySQL 实例单独维护，资源单独分配，操作和维护都比较麻烦。OceanBase 多租户的概念，类似于我们的容器可以部署在同一台服务器，但资源是完全相互隔离且互不影响彼此业务，集群租户之间完全隔离，运维非常方便
06 实例隔离及扩容集群
这些也很方便去调配，OceanBase 可以基于资源池为租户按需分配资源。在使用过程中资源可随时动态调配，单节点维护、数据迁移、故障重建不影响 OceanBase 持续提供服务，真正实现全程高可用
经过大量综合测试，我们惊喜地发现，OceanBase 完全满足公司现有业务的全部需求。
OceanBase 部署及平滑迁移
OceanBase 兼容 MySQL 周边生态，因此 MySQL 周边的很多工具可以访问 OceanBase 环境，包括 Navicat、DBeaver 以及 MySQL 客户端，OceanBase 自带的 OBClient。部署也十分便捷，OceanBase 集群支持一键部署，下图为集群部署完毕后的状态查看：
图1：OceanBase 集群拓扑
当前六棱镜部署 OceanBase 架构为三个 observer 节点+一个代理节点。每个节点配置为 22C/256G，官方推荐使用 SSD 作为存储设备。官方建议生产环境至少部署两个代理节点。
众所周知，数据库的平滑迁移一直以来都是非常大的挑战。当前线上环境以 MySQL 为主，因此需要一套数据迁移方案实现数据从 MySQL 到 OceanBase 的平滑迁移。经过技术团队盘点，MySQL 数据库的备份迁移目前业内主要有三种方式：
- 整库复制，适合全量迁移的数据。
- 表空间还原，推荐使用还原方式，备份还原等同于复制粘贴。
- Myload，速度次于表空间还原，推荐用于本地数据还原云端RDS数据库。
我们使用 DataX 完成全量数据迁移至 OceanBase 集群，相关参考链接如下：
📌 DataX参考链接：
https://github.com/alibaba/DataX/blob/master/introduction.md
📌 DataX WEB 参考链接：
https://github.com/WeiYe-Jing/datax-web
我们现有数据约2T，涉及1700多张表，目前已经全部迁移，迁移速度超出预期。
图2：DATAX JSON示例配制
上图展示的是 DATAX JSON 示例配制，该文件也很简单，只要将数据源、目标数据源，改一些配置即可使用。
图3：迁移效果展示
从本地到云上的迁移展示详见上图，该数据总共为8亿逾条，采用的带宽为 200M，迁移时间从 13:43 开始到 15:21 结束，即迁移时间仅花费了1小时40分左右，速度相当可观。
图4：Tsar 采集工具
上图是 淘宝自己开发的一个采集工具，主要用来收集服务器的系统信息（如Tsar，CPU，IO，Mem，TCP 等），以及应用数据（如 squid haproxy nginx 等），非常好用，分享给大家。该工具主要功能在于实时数据呈现，如果服务器当前有任何性能上的问题需要排查可使用此工具。
上线后带来了什么价值和收益
经过一系列测试验证，OceanBase 在线上稳定运行两个月，相比 MySQL 方案，OceanBase 带来收益巨大，有以下5点：
1）性能非常可观
在处理各种数据的时间上，MySQL 比 OceanBase 时间长很多，详见下图“任务运行时长对比分析”。
图5：任务运行时长对比分析
当删除1万条时，OceanBase 的速度非常可观，但 MySQL 处理速度业务无法接受，即使处理起来速度也非常慢，耗时很长。由上图可知，从总用时来看，提升也很明显，原先 MySQL 需要花费3184.813秒，现在只用了1003.633秒，效率是原来的近三倍。
尤其值得称赞的是，我们在处理创建表操作时，发现速度非常惊人，原先我们用MySQL 耗时长达2206.197秒，而用了OceanBase缩小到了7.112秒，速度提升将近 300 倍。处理包含从创建到筛选的过程，详见代码：
create table 专利外观设计3333 select /*+ parallel(16) */ * from ipi_patent where publish_type='S' limit 50000
如果有和我们一样正在用 MySQL，也遇到了各种问题的公司可以来试试。
2）存储空间使用率大幅度下降
OceanBase 官方结论为节省70%的磁盘空间（仅作参考），我们实际测试发现，原先使用 MySQL 需要3.8T的空间，使用 OceanBase 只需822G，节省空间超过70%，使用成本大大降低。
图6：磁盘空间使用
3）运维更加便捷
多个项目数据放在一套 OceanBase 环境运维，通过不同租户管理不同的业务数据，保证了业务的资源隔离和数据安全，同时一套环境承担多套业务访问，方便管理。目前两套 MySQL 环境已经迁移至 OceanBase 环境并持续迁移中。
4）资源利用率提高
OceanBase 高扩展性使得集群随时可以进行扩缩容，同时通过租实例规格随时调整资源配置，资源分配灵活，使得资源利用率得到了很大的提升。
5）高可用性得到保障
OceanBase 的物理备份+逻辑备份，可以确保数据安全万无一失。同时多副本模式保障在满足多数节点可用时 down 机数据不丢失、不影响使用，在线修复或替换即可。
六棱镜在数据库选型时调研了许多产品，耗费了大量人力和物力，也踩了不少坑，遇到很多操作类问题，在此期间，OceanBase 社区工程师第一时间响应并帮助我们解决遇到的各种技术问题。
经过多方对比，我们最终选择了最匹配我们业务需求的 OceanBase 社区版，在此我们也非常感谢 OceanBase 社区和工程师提供的专业技术支持！未来六棱镜也会深度参与社区建设，输出更多优秀的实践案例，帮助社区用户探索更多的业务场景。
