8 月 26 日，OceanBase 社区联合知乎举办了第 22 期 Meetup，邀请了北京银行、58 同城、知名短视频平台、OceanBase 技术专家，以“原生分布式数据库实战”为主题，围绕新型技术栈、数据库架构和运维等最佳实践展开技术交流。
知乎的数据库选型思考
知乎数据库负责人 代晓磊
数据库的选型一直是一个困扰着 DBA 的问题，既需要立足于当下，又需要着眼于未来。一般来说，数据库选型涉及的关键点包括以下几个方面：
是否经过大厂的流量验证
是否有完善的生态建设
运维复杂度评估
迁移改造成本评估
SQL兼容性评估
系统稳定性评估
除此之外，数据库的 ACID 属性、云原生能力、并发能力、平台化能力、性能等因素也都是数据库选型过程中要考虑的重要因素。
衡量数据库的适用性，业务场景是首要因素。偏交易的 OLTP 业务、偏在线分析的 OLAP 业务，以及混合事务处理的 HTAP 业务，不同场景对数据库特性的需求不同。
知乎是中文互联网最高质量的问答社区和创作者聚集的原创内容平台，每天面对百亿级请求。它有四条重要业务线，包括社区业务、会员和教育、商业化广告以及搜索和安全。在数据库选型中，知乎选择非关系型数据库 Redis 分片集群、MongoDB sharding 和单机分布式一体化架构的 OceanBase 数据库。
其中 ，OceanBase 的分布式事务能力、稳定可靠、分区级操作等特点，以及原生的多租户与资源隔离能力带来的高可用性，极大地满足了知乎的业务场景需求。知乎使用和实践了 OceanBase 社区版，从验证基本功能到逐渐试用再到落地，体验了 OceanBase 的多云多活和国产自主可控性能，未来还将持续落地平台化建设和场景化能力，参与 OceanBase 的共建。
北京银行的数据库替换实践
北京银行数据库负责人 王新宇
目前，许多企业用户和个人开发者参与 OceanBase 的项目共建，北京银行就是其中之一。北京银行自 2022 年底完成首套 OceanBase 生产集群的搭建，现已上线 6 套 OceanBase 集群，共计投产 40 套应用系统，在此过程中持续为 OceanBase 贡献代码。
北京银行数据库系统从 Oracle 切换至 OceanBase，完成了业务系统的优化，也充分验证了 OceanBase 的高可用和备份恢复能力。经过测试和验证，结果证明，北京银行在生产环境的 OceanBase 集群发生单节点故障时，在不进行任何人为恢复操作的情况下，仍可继续对外提供服务，满足高可用性，且保证数据一致性。
在日常业务中，北京银行的数据库优化过程包括以下几个方面：
日志：为更加合理使用 OceanBase 服务器存储空间，日志平台对 OceanBase 日志进行了深度对接。截至目前，日志平台已完成 OceanBase 数据库黄金集群的日志对接工作。
监控：为更好展示现有的数据库业务系统信息，便于监控，建设北京银行数据库驾驶舱，通过可视化展示所需内容，根据租户性能模块，可做租户监控使用，在 PC 端可根据所需查看，在移动端可快速定位数据库异常、判断问题来源。
运维：通过自动化运维平台实现 Oracle 租户和 MySQL 租户自动化创建、租户基线参数自动化配置、数据库用户（读写用户、只读用户）自动化创建、数据库用户权限自动化等功能，节省大量时间和精力，同时降低因手动操作而引入的风险。这将使工作更加高效、准确，并能够更好地应对变化的需求。
管理：为保证生产操作的安全性，使用数据库管理平台对人为登录数据库进行统一纳管。落地行内数据库设计、运行规范 122 条；结合流程引擎完成一键上线 OceanBase SQL 脚本；收口数据库管理平台作为生产环境 OceanBase 数据库唯一入口；实现存量数据库合规性检查，形成检测报告推进整改。
OceanBase 因其单机分布式一体化的架构及其优势，在北京银行发挥着不可替代的作用。北京银行还将持续加深与 OceanBase 的合作，与 OceanBase 深化源码级共创，深入推进数据库转型，实现安装部署简单化、应急处理自动修复、日志全链路追踪、运维标准化，保证数据库高可用、易操作，为北京银行业务稳定运行保驾护航。
某知名短视频平台的数据库降本实践
知名短视频平台 研发专家
如今短视频已经成为许多人日常的娱乐方式，一款日均超过千万人访问的短视频 App，如何及时有效地处理用户请求？
国内某知名短视频 App，采用传统的 MySQL 分库分表方案，通过在后端配置多套 MySQL 集群来支撑高流量访问，以解决大数据量存储和性能问题。该方案一定程度上缓解了存储问题，带来了性能上的提升，但同时运维复杂性和不可持续性也成为亟待解决的问题。
最开始，该短视频平台基于传统的 MySQL 方案承担线上的业务流量。但随着业务的增长，数据量和用户流量与日俱增，传统方案的缺点在一些业务场景中越来越明显。
面对业务对单表 50TB 数据的不断写入，单机 MySQL 的存储和性能挑战很大，不得已采用分库分表方案，虽然问题得到缓解，但是引入的运维成本随之增加；
部分业务 QPS 峰值达到上百万，通过传统的 MySQL 方案无法做到在业务高峰期保证业务请求及时返回；
在一些伴随着复杂的 AP 请求的业务中，采用 MySQL 结合 ElasticSearch 的方案，意味着更高的硬件和业务成本。
经过多方调研和对比，该短视频平台最终选择了 OceanBase 方案来支撑业务。在实际生产环境中过，通过一套 OceanBase 集群替代上百套 MySQL 分片，最大单集群数据量已超 400TB。使用 OceanBase 自带的 OCP 工具可以管理多套集群，在实际生产环境中一套 OCP 管理 8 套集群，数据量近 PB 级的两百台物理机，并且自动完成集群扩缩容、监控、告警，非常方便。此外，ODC 工具也提供了许多便捷功能，业务方通过界面操作即可完成日常的业务访问。
在业务实际使用中，成本收益非常明显。经过业务改造以及综合优化，部分业务场景通过 OceanBase 提供服务，替换原来使用 ES+MySQL 架构，机器成本大概节省 50% 左右，同时一并省去了 ElasticSearch 服务；将其中一套 OceanBase 环境从 OceanBase 3.1 版本升级到 4.1 版本后，机器数量从 30 台缩减至 21 台，大幅降低硬件成本。
该研发专家表示，平台后续将持续深化和 OceanBase 的合作，统一 OceanBase 应用版本，发挥更明显的存储和性能优势；随着 OceanBase 兼容 MySQL Binlog 格式，可以更方便地将丰富的下游生态对接到更多的业务中。除此之外，平台还计划加入 OceanBase 源码贡献，深度参与社区共建中。
58 同城的数据库评测与落地思考
58 同城数据库架构师 刘春雷
58 同城作为中国领先的一站式生活服务平台，业务覆盖招聘、房产、汽车、二手、本地生活服务及金融等各个领域，数据处理需求达到数十 TB。OceanBase 作为单机分布式一体化架构的 HTAP 数据库，具备高可靠、高性能、多租户的能力，可以解决数据处理需求的同时实现降本增效。
OceanBase 是分布式数据库，兼容 MySQL 语法，具备优秀的交易处理和分析处理能力，具备分布式、可扩展、可靠性高、多租户、资源隔离等特性，适合日志、报表、监控、数据存储需求量大、以及有资源隔离需求的业务。58 同城基于现阶段业务需求，通过学习 OceanBase 文档，参考业界用户的应用实践经验，对 OceanBase 基本功能、性能与其他分布式数据库进行了对比。
结果显示，OceanBase 的部署、扩缩容、故障处理、账号、建库、监控、报警、空间及存活日常检查、常用拓扑工具、单机多实例部署等运维自动化可以满足 58 同城业务需求。除了在产品力方面优异的表现之外，OceanBase 社区的及时响应和支持，也给了 58 同城在生产环境大规模使用 OceanBase 的信心。
未来，58 同城将继续强化运维规范与业务引入规范，积极建设 OceanBase 的落地相关自动化，引入线上业务评测，与 OceanBase 共同成长。
OceanBase 单机分布式一体化的特性解读
OceanBase 高级技术专家 余璜
2022 年，OceanBase 4.0 版本发布，奠定了单机分布式一体化架构的底座。同时，在 4.1 版本中 OceanBase 升级了物理备库、分区能力、超大事务、易用性等诸多能力。
OceanBase 的部署形态可以在单机和分布式之间进行动态转换：既可以单机部署，提供和单机数据库相当的能力，又可以由一个单机的部署形态转变成分布式的部署形态。OceanBase 在分布式部署场景下，相较于其他分层的分布式数据库，性能会有较大优势。在 OceanBase 4.x 版本的分布式部署形态下，事务执行效率可以做到和单机数据库相当。
得益于单机分布式一体化架构，存储、性能、隔离能力等都比分布式架构的产品更强。为了解决 OceanBase 3.x 分区数量过多，导致 CPU 占用过高的问题，将单机下同一个租户的分区日志合并到一个日志流中，在减少分布式事务从而提升单机性能的同时，也能大幅降低选举开销和资源占用。
在 4.x 版本中，OceanBase 优化了内存和存储原数据加载，降低 CPU 占用，这样一来，在同等硬件下，存储成本更低。同时，增加旁路导入功能，解决内存爆满和并发问题，提高大批量数据导入的性能。此外，为了解决 SaaS 场景大小商户在一张表中的流量问题，OceanBase 4.x 提供 SQL 隔离能力，对大商户资源进行隔离，避免挤占小商户的 CPU 资源，进一步提升了系统稳定性。
OceanBase 在 4.x 版本中做了许多工程优化：
在内存方面，存储层元数据按需加载，大数据结构内存按需扩张；
在 CPU 方面，减少不必要的后台线程数量，按需降低后台线程扫描频率；
在 SQL 优化方面，增强自动改写，优化执行引擎，提升执行效率。
无论是对大规格 TPC-C 测试中上千台机器下性能最大化的追逐，还是在小规格 4C16G 单台机器测试环境中降低资源使用率，背后始终不变的是 OceanBase 的初心和每一位 OceanBase 工程师的信念：让数据管理和使用更简单，把复杂留给自己，把简单留给用户。
OceanBase 希望通过 4.x 版本架构的变化，使 OceanBase 可以从原来支持大型企业为主，真正走向中小型企业，让用户可以在企业或业务发展的不同阶段，避免数据库重新选型和架构调整重构带来的巨大难度和成本，通过 OceanBase 单机与分布式的双重技术优势，让用户在数据库选型时 “一次选择，终身受用”。
写在最后
在第 22 期 OceanBase Meetup 的分享中，几位数据库专家与大家分享了在数据库选型、评测、落地、降本增效等方面的经验，并在现场与大家密切交流了产品能力、解决方案、转型实践等方面的技术疑问。
OceanBase 开源生态资深技术总监封仲淹希望 OceanBase 能够帮助大家突破架构的升级瓶颈，解决业务的增长问题，同时实现降本增效。另外，也希望用户与开发者能够积极参与 OceanBase 的社区活动与项目共建，持续对 OceanBase 提出建议。
