OceanBase的一体化架构，为什么能同时做到可扩展和高性能？

作为基础软件领域的三驾马车之一，数据库一直是技术开发中重要的领域，并延伸出诸多细分的类别：关系型数据库、非关系型数据库、分布式数据库、文档型数据库等等。而在众多数据库类别中，以OceanBase为代表的单机分布式一体化数据库因融合了集中式和分布式的双重技术优势，受到了市场的高度关注。

从OceanBase的技术性能来看，其不但具备分布式数据库的可扩展性，又兼容集中式数据库的单机性能，在业务需求上兼具可扩展性、高可用性以及可调度性，能高度适配小微企业、中型企业、大型企业在不同发展阶段、不同具体场景当中对于数据库的不同要求。尤其是4.0 版本的发布，更是极大地降低了分布式数据库的使用门槛，为广大用户和开发者提供了更便捷的使用体验。

但其实在OceanBase 早期的版本中，也存着被用户诟病的问题……

最早的时候，很多开发者会反馈OceanBase 比较重，因为最早期的版本一台机器要求 128G 内存。而之所以会要求这么高配的服务器，最本质的原因在于分布式数据库早期的架构里面每台机器需要使用大量的 CPU 和内存用于处理分布式相关的 overhead。

为了解决这个问题，4.0 版本通过一体化架构避免了每台机器上的分布式 overhead，从而提升性能，并把门槛降低下来。看到这里可能很多人会好奇：为什么一体化架构能同时做到可扩展和高性能？

对此，OceanBase CTO杨传辉表示，其实可扩展和单机高性能以及整个系统的高性能，这里面有一些设计的假设。最根本的假设就在于对于所有的 OLTP 场景，虽然背后可能因为数据量很大，会是分布式数据库，但是大部分的读写操作都是单机操作，只有少部分的读写操作才是跨机操作。

比如大家都有自己的银行账户，而假设所有的银行帐户存在一个银行的数据库里面，相信大部分时间你是在读写自己的账户，少部分时间才会给别人转帐，而且给别人转帐之前应该会反复确认。对于这样基于账户的数据库，假设按照账户做了 Sharding，意味着大部分时间用户都是读写自己账户是本地单机操作，少部分时间是远程分布式操作。

基于此，一个分布式数据库要做的首先是保证80% 以上的单机操作性能不会因为分布式架构有额外的 overhead，其次才是优化另外 20% 的性能，使得这 20% 的分布式操作虽然因为网络有一定的 overhead，但尽可能做到足够低，最终使得整个系统不管单机还是多机层面都能够保持高性能。

而OceanBase  1.x 版本到 3.x 版本，采取是预先分区的方案，每个分区相当于是一个 mini 数据库，有自己单独的 redo 日志，通过这样的模式也能解决一部分分布式数据库的问题，但是带来的影响就是每台机器要服务很多分区，服务很多 mini 数据库，有很多额外的 overhead，单机要求高配的 CPU 和内存。

于是，相关人员在4.x 版本做了重构，实现单机一体化架构，每个单机有很多数据分区，但是只有一个数据流，使得单机读写没有分布式相关的 overhead，与原来的单机可以站在同一水平线上 PK 性能。

也就是说，4.x 版本做到了所谓的一体化，当增加新的服务器的时候，增加新的日志流，原来的分区从老的日志流里面摘出来迁移/转移到新的服务器新的日志流里面，既能保证单机的高性能，又保证可扩展。

与此同时，单机分布式一体化架构还大幅度降低了开发者的使用门槛。早期的 OceanBase 版本确实因为架构设计的问题，需要单机用很高配的内存，但随着不断优化，从 128G 优化到 64G、32G、16G、8G，不断降低，现在已经能在树莓派上直接运行OceanBase 4.x 版本。

当然，OceanBase还有很大的优化空间，也期待之后其会把更好的产品带给各位开发者。