超级干货分享：中小企业使用 OceanBase 实践经验汇总

资源规划

资源上，OB 产品多个版本迭代已经在努力降低部署要求。因此不少客户给 OB 的部署资源都用上虚拟机。就生产环境的虚拟机规格而言，我觉得最少 8C16G 内存，以平替一个生产的 MySQL 数据库。再小就不讲道理了。求稳的话，建议 16C64G 。

计算 OB 替换 MySQL 或 ORACLE 的成本收益，综合多个实例一起看，会更有说服力一些。如果你有多个 4G~8G 的 MySQL 要换 OB,那又是可以的。 OB 以集群形态部署（单节点是特殊的集群），以租户形态提供服务。如果要提供多个租户，这个集群的部署服务器内存资源就要上涨一点。否则小规格集群还搞多个租户，小马拉大车，后期还是会有问题。很朴素的道理：给多少资源，干多少活。

服务器资源预算不高的客户，对租户资源的使用就要斤斤计较，这个对运维的要求会非常的高。而那些大客户，服务器动辄 512G 内存的，在资源分配上就从来不用操这个心。资源的计较考验的是资源的计算、租户资源实际利用率、业务 SQL 的性能。

同样的业务场景，有的应用做的好，4C8G 就能满足要求，而又的应用却要 8C16G 。在资源紧的小租户场景里，业务 SQL 的性能对资源的使用率和需求影响会格外大。而偏偏这类客户还以为资源可以很小。

所以，资源少的场景问题多。而应用解决问题的意愿和能力又有限。为了后期事少，建议资源方面就多给一些。如 16C64G 。

上面资源说的是 CPU 和内存，还有个关键资源就是磁盘。OB 数据库读写模型是 LSM Tree，跟 SSD 顺序写性能好特点天然结合能发挥更大作用。在大客户场景里，都是 NVMe SSD ，中小企业或非核心场景可以选择 SATA SSD。机械盘就不要考虑了。少数客户虚拟化简直就是卡 OB BUG，问 HDD 和 SSD 混合的行不行（用了 SSD 给 HDD 加速技术）。有这样的部署案例，详见：物无弃材 ------ 混闪机型部署 OceanBase 集群的探索。部署肯定是可以的，就是性能方面别要求太多。

应用的数据库设计和性能

这类客户场景的应用通常都会说数据量不大，访问压力不大。应用开发的逻辑只考虑功能，不关心性能。在评估压力的时候，大家都是乐观的，倾向于快点上线。至于上线后的性能，那就推给数据库厂商和运维了。

很多应用开发商，应用迁移到 OB 上会有性能问题。深入分析问题的时候会发现，这类问题在 ORACLE 或 MySQL 里也存在。或者说这类问题就是应用从 ORACLE 或 MySQL 设计里带来的。 ORACLE 都没有用好，OB 语法高度兼容 ORACLE / MySQL，自然也用不好。

比如说表结构的设计。

表都建议要有主键，没有主键就构造一个业务无关的主键。在 MySQL 里，如果是联合主键，那主键列尽可能短小。这个是规范建议，它影响的是一些后期的运维。如数据迁移或逻辑同步的效率，以及部分场景 SQL 的性能。
表的列尽量用 NOT NULL。 ORACLE 和 MySQL 的 NULL 值含义不完全一样，ORACLE 里的 NULL 列如果作为条件列可能还要引入空值判断。如 (col1 is null or col1='xxx'). ORACLE 对这种条件列就不好建索引了。
表里尽量不要存储图像、大文本或文件数据。数据量大的时候，尽量用外部存储去保存这些数据。这种大对象在数据库里非常占用空间，且读写效率很低。

又比如说索引的设计

ORACLE 和 MySQL 的大部分索引的定位功能都遵循最左匹配原则。单列索引和组合索引要考虑这个特点。
数据区分度不高的列，并不适合建单列索引。每个字段都建一个单列索引更是荒谬至极。单列索引太多，数据库也并不一定会将多个索引一起使用。INDEX JOIN 只是 ORACLE 在某些特殊场景下才可能用得上。
组合索引的使用场景是看前导列在 SQL 里条件格式。组合索引太多近似度很高，很容易让数据库选错索引。
索引主要是为了数据定位服务的（查询或带条件的更新），看场景建索引。索引只为重要的场景服务，而不是所有场景。当你想讨好所有的场景的性能的时候，结果往往事与愿违。索引考验的是开发人员对业务数据库设计以及数据库索引原理的掌握程度，考验的是技术人员的大局观。

如果要加一个索引，每个研发都够胆加索引；但是要说拿掉一个索引，就没有人敢出来拍板。因为都不想承担责任。每一个新增的索引，都是对数据库 SQL 生态的搅动。

又如 SQL 的书写

表字段很多的时候，SQL 不要写 SELECT *，特别是表有大字段列的时候。有些 OR Mapping 框架喜欢直接读取表所有字段。这样的 SQL 开发简单，性能上糟糕透了。
SQL 条件里不要对列用函数。不要有类似 month(to_date)=1 或 uppper(c1_str)='HELLO' 这种写法。这个时间条件可以转换为 between... and... 写法，后面这个列可以从数据源头就约定大写或小写。
不要滥用 LEFT JOIN 。如果 LEFT JOIN 的表在 WHERE 后出现了过滤条件，或者 LEFT JOIN 的表紧接着又去 INNER JOIN 其他表，那么这里就不应用 LEFT JOIN 表。很多应用滥用 LEFT JOIN 往往早期是应对脏数据，后面的人往往不明所以，跟着抄。
GROUP BY 的列不要太多，更不要利用 GROUP BY 去去重。去重的语法是 DISTINCT ，当然也不要对很多列去去重。碰到那种场景，先想想 SQL 怎么 JOIN 多表以去重。
少用视图嵌套，更不要基于复杂的视图再去构造复杂的查询。在一些 ERP 场景，二开的人会基于已有视图去开发更复杂的逻辑。这样的 SQL 后期性能优化非常的麻烦，还不如花点时间研究一下视图后面的基表关系，基于基表去开发报表 SQL 。

上面这些问题，都是数据库开发普遍的问题，跟 OB 没有直接关系。不懂 ORACLE 或 MySQL 的人，也不会懂 OB 。管生不管养，是有性能问题的应用的共同品质。不听劝，是第二个品质。

虽然硬件资源有限，但不妨碍在这个上面开发出好性能的应用，只需要遵守一些数据库开发规范和建议，对数据库的使用，要扬长避短。做法就是数据库培训。OB 的数据库开发规范培训内容，大部分内容都是通用的数据库开发规范。不听培训、不重视开发规范的执行，使得应用的性能就跟熵的爆发一样。后面的开发和运维拼命的打补丁。最后成本都转嫁到客户和运维上。

OB 特有的开发和运维规范

OB 数据库兼容 ORACLE 和 MySQL，只是语法兼容，包括 SQL 和事务语法。但是存储引擎、事务引擎的原理不兼容。所以 OB 的开发和运维也有自己独特的地方。

OB 特有的开发规范：

分区表。数据量大的流水表、或者访问量大的交易表，可以选择合适的策略去分区，做分区表。难点是判断分区的时机以及确定一个分区策略。
多个业务表做分区表后，为了尽可能减少跨节点的 SQL 和事务，适当运用表组技术和复制表技术（公众号内搜索实践经验）。
高并发大批量的 INSERT 语句可以利用 JDBC 的 batchInsert 功能，将多个 insert 合并为一个 insert 多个 values 语句。单并发的大批量插入语句（ INSERT INTO B SELECT * FROM A ）可以通过 HINT 启用 OB 的并行 DML 和旁路写入功能来提升性能。
大宽表可以适当考虑用列存表或行列混合。复杂的查询可以考虑使用 OB 的读写分离技术（弱一致性读）。

OB 特有的运维规范：

OB 的 SQL 和事务会有自己的超时机制，根据业务特点设置适当的参数，减少租户慢 SQL 和长事务或大事务的负面影响。
OB 租户多副本部署时，通过设置单一主可用区（PRIMARY_ZONE) 可以避免不必要的跨机分布式请求）和分布式事务。
调整 OB 内存的转储参数和限速参数，提升内存的使用率，进一步提升业务事务的大吞吐写入能力。
调整 OB 合并和转储参数（包括并发），可以优化 OB 合并和转储时对业务性能的抖动影响。部分大批量插入和更新或删除的表，配置适当的 table_mode 参数可以独立进行转储。
复杂的查询 SQL 很多的时候，可以开启租户的自动并行功能，调整租户的慢查阈值和 CPU 分配比例，可以调控慢 SQL 对业务整体 CPU 资源的消耗和性能影响。
关注租户的合并和备份性能（耗时），关注日志备份的延时以及备租户的同步延时。时常抽检备份用于恢复验证。

数据库的可用性和安全性

数据库的可用性指数据库出现故障的时候多久能恢复服务，以及恢复的时候数据丢失多少。如果问客户对可用性的要求，大部分都说我的数据很重要。如果哪个客户说数据也不是那么重要，那他真的很实诚，可以交心。

小编评注：这里戳中了笑点。不过按照庆涛大佬的标准，我也的确遇到过几个"可以交心"的 OceanBase 用户。

就按数据很重要去准备。要恢复的快，数据库就需要一个备库，能快速切换。如果要自动切换且不丢数据，对于 OB 而言就需要一个集群部署。但即使有集群，还是需要一个备库，以防范集群整体故障。类似于 ORACLE RAC 加 Dataguard 。实际中小企业客户场景要么是一个三节点 OB 集群或者就是 OB 单节点主 + 单节点备。这个主到备的切换是需要 DBA 手动操作的。如果是故障切换（ FAILOVER ），是有丢数据的风险。

要数据不丢失，还要有数据库备份。OB 集群的备份方案跟节点规模无关，都建议是 NFS 路径。如果是单节点的 OB ，用本地路径备份也是可以，只是意义不大。如果本机故障了，也拿不到备份。OB 的备份比 ORACLE 和 MySQL 的备份好一点就是 OB 可以做到日志备份的近实时备份，这样一旦数据库集群整体故障或者数据错误，还是可以利用备份还原到需要的时间点上。如果备份用对象存储，特别是第三方备份产品，那建议充分测试，做好应对问题的准备。

OB 的备份有利也有弊。这个实时备份的是日志备份，日志备份的空间跟业务事务的吞吐量有关。有可能日志备份比数据备份还大很多。备份的保留策略对备份空间也有影响。所以，OB 的备份空间预算尽可能给足。如果空间不足，运维就需要额外投入精力去精细化运维这个备份。

备份还要检验才行。要经常性的去恢复备份以验证这个备份的有效性。同时也是对运维紧急处理能力的一个验证。这个是客户里经常忽略的。

OB 数据库要高枕无忧，就要备库加备份。只有备库或备份，也还算过得去。如果二者都没有，那等同于埋雷。就看后面谁踩雷了。

数据库运维的便利性

传统 ORACLE 和 MySQL 的运维命令都比较简单，网上文章也很多，照着做，启停数据库对开发而言，也不是什么难事。OB 数据库的启停更简单，但如果起不来，就很考验 OB 原理。一个 OB 部署环境越规范，后期启停的成功率越高。当资源紧张的时候，OB 部署环境就不是那么规范。所以不少客户，特别是测试环境就出现 OB 运行一段时间后就很卡很慢甚至挂了。这类问题就远超出开发和普通运维的处理能力。

OB 提供了 OCP 平台降低运维的门槛。但是它不能应对环境的不规范。其次，OCP 里自带了一个 OB 元数据库，并且 OCP 的功能强大的代价就是其自身数据库负载很高。16C32G 的虚拟机部署 OCP 只是勉强够用，后期大概率会出问题。如果资源预算有限，不部署 OCP ，那也可以命令行下运维 OB 。这就需要额外学习了。这就不是一两次运维培训可以做到的。

OB 的数据库版本

OB 的企业版本现在分为集中式版本和分布式版本，二者都通过了信创认证。虽然叫两个版本，核心的代码和能力都是一样的。分为两个赛道跟 OB 的技术毫无关系（OB 是单机分布式一体化），完全是国内数据库市场的人为演化导致的。

OB 的分布式版本软件以及相关软件只要是 OB 的客户，通过实名认证的官方账户，都可以在官网下载。OB 的集中式版本软件根据场景规模分为两类：带 OCP 和不带 OCP 的两个。任何人都可以通过 OB 官网软件下载到集中式版本软件，只是需要填一个问卷调查。不过这个下载的软件版本不是最新的版本。正式部署的时候，还是要联系 OB 商务或交付人员。试用版本使用期限是半年（180 天），此后需要正式的许可文件才可以继续使用。

OB 的技术服务资源

OB 的集中式版本商务上据说又细分为专业版和旗舰版，技术上没有区别。旗舰版可能带上一些原厂人天服务，专业版就没有原厂人天服务。 OB 的分布式版本商务上通常都会搭配原厂人天服务。

OB 的生态服务伙伴很多，客户也可以自行选购第三方维保服务。对于大型企业或者核心业务场景的 OB 客户，都有第三方人天服务和原厂人天服务搭配保障。OB 产品自身的缺陷问题通常都超出第三方维保服务的能力。三方最多能做的就是识别到这是产品问题，然后能升级就升级，不能升级就绕过。能解决问题，但不能解释问题。中小企业客户的服务可以参考这个搭配，数量上可以更少一些。

不管是哪种 OB 版本，只要你是 OB 客户，都会有一个技术支持和维保服务，这个指的是 OB 官方在线的 7*24 技术咨询服务以及免费的软件升级服务。这个服务跟 OB 工单账户绑定。OB 客户要在官网注册一个账户并实名认证，这是所有 OB 客户的保命手段，尤其是中小企业 OB 客户。工单的沟通对技术人员的沟通能力要求特别高，要信息描述准确全面，自主推动问题进展。工单能不能解决问题一半取决于提问题的人，问题不解决就不要关闭工单，工单会升级到更高阶技术支持人员手里。

其他能寻求的 OB 技术服务资源就是 OB 的客户成功经理（CSM）和 OB 的售后和交付团队。售后和交付团队提供服务的前提是客户有采购原厂人天服务。否则，只能靠客户关系去刷脸了。

OB 还有一个社区版（或者叫开源版本），软件在 GITHUB 上自由下载，自由使用，主要用来平替 MySQL 或 PostgreSQL 数据库的。如果有 OB 社区版的问题，可以在 OB 官网论坛或者 OB 开源技术钉钉群里咨询沟通。问题的响应通常是 5*8 。

社区版的用户在 OB 版本的使用上往往更加不规范，或者风格更野一些，导致技术风险更高一些。所以，建议 OB 社区版客户多在论坛提问，跟社区团队保持密切沟通。这样，偶尔有个紧急问题说不定还可以刷刷脸解决。

另外，如果你的企业使用 OB 的场景很典型，可以成为行业标杆案例，可以主动告诉社区团队，这样很可能会获得向社区团队刷脸获取更多技术支持的机会。IT 预算有限的情况下，使用 OB 社区版搭配三方运维服务，也是一个不错的方案。

总结

对于中小企业客户，多为 OB 部署争取资源，多学习 OB 开发和运维知识，多跟 OB 官方或第三方服务商保持联系，才是省钱省事的门道。

强烈推荐：庆涛大佬的数据库经验分享系列文章

了解更多

添加社区小助手，加入微信交流群~

作者提示: 个人观点，仅供参考

阅读原文