今天我们来聊聊OB。我也是OB初学者，对OB的内部原理和应用特点了解甚少。我的大部分观点都是基于我对数据库的理解，应用于OB。.另外，对于OB、TIDB等基于LSM-TREE存储引擎的数据库，经常有人会做一些比较，所以我也会在一些分析中和TIDB进行比较。同样，我只了解TIDB的表面，所以这些比较可能会有一些错误。之前也写过一篇文章分析过，TIDB和OCEANBASE虽然底层都使用了LSM-TREE存储引擎，但是架构不同。OB是典型的MPP架构数据库，而TIDB是存储和计算完全分离的架构。不过TIDB5.0也引入了MPP计算框架。如何实现我没有研究过，这里就不展开讨论了。以往TIDB与OB争论的时候，TIDB经常会指出MPP的不足来证明TIDB优于OB，但是TIDB引入MPP计算框架证明了这种指责是不完整的。之前我也说过，目前的分布式数据库大多不具备通用计算能力。它们可能对某些业务负载非常有用，但对其他一些负载却不能令人满意。事实上，任何一家分布式数据库厂商都在努力改进自己的产品，以适应更广泛的应用场景。5.0之前的TIDB没有MPP的shardingkeydeadlock，但是正因为如此，在TIDB层面实现BUFFERCACHE是非常困难的，因为它需要引入bufferfusion机制，并且在a上引入bufferfusion大型分布式计算引擎将是一场灾难。TIDB级别缺少BUFFERCAHCE。如果不能接受稳定的慢，就需要提高硬件配置，使用ssd盘来提高SQL的响应速度。因此，TIDB对硬件的要求很高。TIDB5.0引入了MPP计算模式。我想这也是出发点。这种计算模式的引入可以优化TIDB之前版本对某些场景的支持能力。OB和TIDB的架构不同。OB是一种天然的SHAREDNOTHINGMPP架构。因此，OB不同于其他的LSM-TREE存储引擎数据库，有着非常复杂的缓冲区结构。为什么它是一个非常复杂的缓冲区结构？因为OB是一个多租户的分布式数据库，租户隔离的设计非常完善，buffer可以细粒度到租户级别，每个租户都有独立的内存、CPU等资源隔离。另一方面，Oceanbase是基于谷歌的五分钟原则设计的数据库系统（谷歌认为如果某个数据在5分钟内至少会被访问一次，那么这个数据最好放在内存中）。OB使用LSM-TREE，所以需要大量的内存来存储MEMT。所以操作系统的物理内存可以尽可能交给OBSERVER，由OceanBase自己管理。从上图可以看出OB的内存使用策略。通过memory_limit_percentage参数，可以设置OB可以使用的最大OS内存量。如果服务器内存为384GB，则此参数的推荐设置值为80%，如果服务器内存为512GB或更高，则为90%。从这个策略也可以看出，OB还是比较消耗内存的。为了有更好的性能，建议为OB服务器配置更多的内存。其实除了其他LSM-TREE数据库的通用实现外，OB的buffer也和B-TREE/HEAP存储引擎的数据库一样，设计了BLOCKCACHE。可以看出OB设计了两层CACHE，一层是从SST读取到内存的BLOCKCACHE，这一层CACHE可以用于一般的SQL扫描操作，在BLOCKCACHE之上，还有一层row设计的Cache存储一些热行，用于一些简单的、频繁执行的访问少量行的SQL。这种双层缓存（MEMSTORE的写缓冲区不算）的设计其实很复杂。Oracle数据库也有BLOCKCACHE和ROWCACHE两种缓冲区设计，但ROWCACHE只是用于字典缓冲。其实就是一个application-specificbuffer，是应用级别的。Oracle数据库对数据字典的访问有特殊的业务逻辑，为了提高效率而设计的ROWCACHE是根据固定的业务逻辑设计的。但是通用的业务负载不能使用小而高效的ROWCAHCE，必须使用统一的BLOCKCACHE。OB的行缓存不用于内部计算，而是用于一般的业务场景。如果某行在块缓存中被频繁使用，则将其放入行缓存中。为了避免每次访问都要查询rowcache，导致rowcache的命中率低，影响cache的访问效率，在rowcache中加入了Bloomfilter。第一次看到OB的行缓存结构的时候，感觉这个设计很互联网。这种架构对于一些互联网应用开发者来说可能比较熟悉，很容易想到应用-Bloomfilter-REDIS-数据库应用架构。对于这一层CACHE，我还是很迷茫，因为CACHE的设计原则就是简单高效。应用开发者构建一个与业务紧密结合的行缓存是不是更好？当然，对于应用程序类型来说是非常重要的。对于符合这种架构而无法自己搭建内存缓冲层的用户来说，这一层行缓存确实可以简化应用。OB的rowcache我没有深入研究过。不知道租户层面能不能关掉这层缓存。如果它可以很容易地打开和关闭，这是一个很好的设计。否则，我认为如果遇到一些像这种不适合应用的场景，这种结构很可能会影响整体性能。LSM-TREE存储引擎的BLOCKCACHE性能问题在国外一些论坛上已经讨论过了。主流观点认为效率不如HEAP/B-TREE存储引擎数据库。这可能也是OB要引入行缓存的原因之一。OB官方文档中的解释是，大部分OLTP业务操作都是小查询。OceanBase数据库通过小查询优化，避免了传统数据库解析整个数据块的开销，达到接近内存数据库的性能。这种描述对于某些应用场景可能是准确的，尤其是像支付宝这样的交易系统，但对于ERP、MIS系统等可能就不适用了。大部分传统企业的OLTP系统是无法集成到这种简单的接入场景中的。从我们今天讨论的问题中，我们也可以看到，分布式数据库厂商正在采用一些自己独有的技术，让数据库更适合通用场景，从而具备分布式数据库的高可靠性和强大的横向能力。除了可扩展性，它还可以像通用的中心化数据库一样，对各种通用的计算场景提供很好的支持。
