8.4.5　单点性能

OceanBase架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。当然，这个架构也有一个明显的缺陷：UpdateServer单点，这个问题限制了OceanBase集群的整体读写性能。

下面从内存容量、网络、磁盘等几个方面分析UpdateServer的读写性能。其实大部分数据库每天的修改次数相当有限，只有少数修改比较频繁的数据库才有每天几亿次的修改次数。另外，数据库平均每次修改涉及的数据量很少，很多时候只有几十个字节到几百个字节。假设数据库每天更新1亿次，平均每次需要消耗100字节，每天插入1000万次，平均每次需要消耗1000字节，那么，一天的修改量为：1亿×100+1000万×1000=20GB，如果内存数据结构膨胀2倍，占用内存只有40GB。而当前主流的服务器都可以配置96GB内存，一些高档的服务器甚至可以配置192GB、384GB乃至更多内存。

从上面的分析可以看出，UpdateServer的内存容量一般不会成为瓶颈。然而，服务器的内存毕竟有限，实际应用中仍然可能出现修改量超出内存的情况。例如，淘宝双11网购节数据库修改量暴涨，某些特殊应用每天的修改次数特别多或者每次修改的数据量特别大，DBA数据订正时一次性写入大量数据。为此，UpdateServer设计实现了几种方式解决内存容量问题，UpdateServer的内存表达到一定大小时，可自动或者手工冻结并转储到SSD中，另外，OceanBase支持通过定期合并或者数据分发的方式将UpdateServer的数据分散到集群中所有的ChunkServer机器中，这样不仅避免了UpdateServer单机数据容量问题，还能够使得读取操作往往只需要访问UpdateServer内存中的数据，避免访问SSD磁盘，提高了读取性能。

从网络角度看，假设每秒的读取次数为20万次，每次需要从UpdateServer中获取100字节，那么，读取操作占用的UpdateServer出口带宽为：20万×100=20MB，远远没有达到千兆网卡带宽上限。另外，UpdateServer还可以配置多块千兆网卡或者万兆网卡，例如，OceanBase线上集群一般给UpdateServer配置4块千兆网卡。当然，如果软件层面没有做好，硬件特性将得不到充分发挥。针对UpdateServer全内存、收发的网络包一般比较小的特点，开发团队对UpdateServer的网络框架做了专门的优化，大大提高了每秒收发网络包的个数，使得网络不会成为瓶颈。

从磁盘的角度看，数据库事务需要首先将操作日志写入磁盘。如果每次写入都需要将数据刷入磁盘，而一块SAS磁盘每秒支持的IOPS很难超过300，磁盘将很快成为瓶颈。为了解决这个问题，UpdateServer在硬件上会配置一块带有缓存模块的RAID卡，UpdateServer写操作日志只需要写入到RAID卡的缓存模块即可，延时可以控制在1毫秒之内。RAID卡带电池，如果UpdateServer发生故障，比如机器突然停电，RAID卡能够确保将缓存中的数据刷入磁盘，不会出现丢数据的情况。另外，UpdateServer还实现了写事务的成组提交机制，将多个用户写操作凑成一批一次性提交，进一步减少磁盘IO次数。