从特性上说，OceanBase具备线性扩展、高可用、高性能、低成本，以及和主流关系数据库产品高度兼容等特点。
1集群架构特点
从1.0版本开始，OceanBase架构就进化成为全对等节点，无共享存储方式。这个架构特点消除了单点，每个节点都具有完备处理能力，能够管理本节点上的数据。在节点角色上，有几个节点（root service）负责管理集群拓扑结构等全局信息，相对特殊一点，但每个节点都具备承担这个角色的能力，如果当前承担该角色的节点发生故障，集群会自动选举出新的节点承担这个角色。
百万级QPS前端代理
在OceanBase集群之上，我们提供一个反向代理OBProxy。看到这个，大家可能会联想到基于中间件构建的MySQL集群，但这两者是有本质区别的：简单地说，没有OBProxy，OceanBase集群一样能够工作，具备完整处理能力。
那我们为什么要有OBProxy呢？主要出于两方面的考虑：
- 一个是性能，通过OBProxy的路由功能，可以比较准确地将语句路由到合适的节点处理，减少集群内部转发；
- 另外一个是容错能力，在网络发生闪断情况下，OBProxy可以重建连接，让业务无感知。
分布式架构对业务透明
对业务来说，OceanBase分布式架构能做到的最好状态是什么呢？我认为是对业务透明。通过分布式架构，我们做到高可用、做到可扩展，但是对业务系统，要做到透明，表现为一个单节点数据库，体现在如下几点：
- 业务无需关心数据库对象的物理位置。业务连上OBProxy或者任何一个OB节点，就能看到完整的视图，能访问所有它有权限访问的数据。
- 集群SQL功能集等同于单节点SQL功能集。采用标准SQL语法，并且不因为数据分布影响SQL功能。当前版本大部分功能都做到了数据位置无关，但还有少数功能受位置影响，比如我们不支持在一条DML语句中修改多个节点的数据。在即将发布的2.0版本中，这些问题都会得到解决。
- 完整支持事务ACID特性，统一事务操作接口。业务无需区分分布式事务和单机事务，数据库内部会对不同的场景进行区分并做相应的优化。
- 自动处理分布式环境故障、做到业务无感知。通过OBServer 和OBProxy的重试机制，可以做到大多数环境故障对业务透明，但相对于之前建立在高可靠硬件上的单机系统，还有一些差异，个别场景异常需要业务处理。
2线性拓展
在满足业务高速发展的过程中，OceanBase数据库要解决的首要问题就是扩展性问题。
通过全对等节点架构，我们消除了之前版本单点写入瓶颈。业务对数据库的要求是不停服务，永远在线，为此所有的操作都要是在线的。传统的垂直扩展的方式不行了，只能采用水平扩容的方式。这从方法上看也很直观，怎么做呢？分三步走：
在集群中增加节点→让新节点具备服务能力→将一部分负载分发到新节点上
看起来，似乎和将大象装进冰箱一样，步骤明确。但每一步都不是那么好做的。
因为OceanBase是无共享存储的，要想新增加的节点能够分担负载，新节点上先要有数据。最难的是此过程中既要保证数据一致性，又要不影响业务。无论是机房扩容（机房内新增机器）还是扩展到新机房（很有可能是异地或公有云场景），我们都必须做到在线。在OceanBase的实现中，主要依赖如下几点：
- 多副本机制。多副本不仅是高可用的基础，也是在线扩容的基础。从本质上来看，扩容无外乎两种：一种是将新数据写入到新节点，后续对该部分数据的读写也在新节点；另一种是将现节点上的部分数据移动到新节点并在新节点提供服务。
第一种情况容易处理；第二种情况就需要利用多副本机制，简单地理解就是把其中的一个副本从原节点迁移到新节点，说起来简单，做起来有很多的细节要考虑，比如在异地增加一个副本，怎么样做到既能高效地迁移数据同时又不影响现有服务。
3高可用
高可用是OceanBase数据库安身立命的根本，正祥老师的三篇文章对此进行了详细的描述：
- 传统关系数据库高可用的缺失
- 如何在非可靠硬件上实现金融级高可用？
- 基于Raft分布式一致性协议实现的局限及其对数据库的风险
- 4高性能
- 高性能不仅仅意味着服务能力强，也意味着成本降低，在相同硬件条件下可以支撑规模更大的业务。OceanBase通过读写分离架构（LSM tree），将更新暂存在内存中，并且在内存中维护两种类型的索引：Hash索引和B＋树索引，分别用来加速主键查询和索引范围查询，达到准内存数据库的性能。
5低成本
OceanBase一方面需要满足业务对数据库的要求，另一方面也要节约成本，不仅仅是运营成本，还包括业务迁移和人员学习成本。
OceanBase的成本优势主要来自以下三点：
- 通过执行路径性能提升降低计算成本；
- 通过读写分离架构优势降低存储成本，一个真实的案例是某内部业务从Oracle迁移到OceanBase，原先的100TB缩小到30几个TB。因为OceanBase中可以采用压缩比更高的压缩算法，而在Oracle中，由于是原地更新要兼顾性能，没法采用消耗CPU过多的高压缩比压缩算法；
- 通过多租户架构，不同负载类型的业务通过多租户方式混合部署，能更加充分地利用了机器资源（可参考：多租户机制概述）。从实际应用来看，采用OceanBase数据库的金融业务，单账户成本只有原先的1/5到1/10。
- 6兼容性
