OBKV-Table 简介

OBKV-Table 提供了对表模型数据的操作接口。同时，在内部，OBKV-Table 定义了客户端和数据库服务端之间的一组通用的交互协议。本文将对 OBKV-Table 的实现原理进行详细介绍。

OBKV-Table 流程

如图所示，OBKV-Table 由客户端、RPC 框架和服务端三部分组成。本文分别介绍下这三部分的作用。

客户端

OceanBase 是分布式数据库，每个表甚至每个表的不同分区都可能存放在不同的机器上，而想要对表进行读写就必须先要定位到数据所属的表或是分区的位置。

特别的，对于 OBKV-Table，OBServer 节点当前并不会做路由转发，只在本地执行，路由错误会读写非预期的数据。因此每一轮操作，客户端都会先根据 table name、rowkey 算出具体的分区号 partition id，进而根据分区号计算得出执行该指令的 observer 具体位置，然后再把 request 请求发送到对应 observer 节点。

另外，客户端除了要保证基本的读写功能外，还承担着路由计算的重大使命。

RPC 框架

OBKV-Table 使用 OceanBase 数据库自定义的 RPC 协议进行通信，这个协议是标准的 Request-Response 模型。

不同的 Request 之间互相独立，Server 端会并发处理多个请求。同一个客户端和 Server 端之间可以建立多个 TCP 连接。这层模型由 libeasy 封装。

在 libeasy 的包内包含 OceanBase RPC 包的包头和数据。数据经过 RPC 层传递后到服务端后，需要再经过 decode 模块对数据包进行解析，server 最后从 pkg 请求包中解析出消息类型以及数据体。

服务端

OBServer 服务端使用生产者消费者模型来处理客户端的 OBKV-Table 消息请求。客户端并发消息的最大个数取决于队列的长度以及 server 的处理速度。

当服务端接收到客户端请求后，由独立线程把 request 消息放到消息队列中，并且由工作线程从队列中取出消息体并处理。

为了区分不同类型的消息，observer 采用优先级队列，对不同类型的消息（MySQL，RPC 等）进行分层处理，这样可以保证某些优先级比较高的请求不会因为超时而被"饿死"。

另外，OBKV-Table 与 OceanBase SQL 采用相同的事务框架以及存储引擎。存储引擎是两级分区表 + LSM 树，两级分区表支持哈希分区、Range 分区、以及哈希和 Range 的各种组合，能够通过自动 range 分区和自动分区负载均衡来解决分区热点问题和机器热点问题，对用户完全透明。

与 SQL 模式比较

OBKV-Table 提供的表模型 API 可以和 OceanBase SQL 无缝集成，甚至共同使用。下面分别介绍 OBKV-Table 和 SQL 模式相比的优缺点。

优点:

• OBKV-Table 基于分布式存储层设计，数据访问路径短，相同功能时性能更优；因为语义简单，更容易优化，性能预期更可控（Predictable）。
• Batch 操作的语义比 SQL 模式更灵活高效。例如，multi-get 的不同行可以选取不同的列。
• API 接口使用简单，直接提供 entity 语义，不需要复杂的 ER 映射。
• 使用简单的 RPC 协议，没有传统 JDBC/ODBC 接口的重新连接，几乎不受连接数的限制（目前受 RPC 框架的限制）。

缺点：

• OBKV-Table 的查询（Query）功能无法和 SQL 模式同日而语，提供 get、scan、limit 等有限功能。如果您需要使用聚合、排序功能，应该使用 SQL 模式。
• OBKV-Table 也不提供交互式的事务等复杂事务功能。不同于传统关系数据库，OceanBase 数据库本身作为一个 SQL 功能齐全的 NewSQL 关系数据库，高扩展性和高可用性并不是选择使用 OBKV-Table 的考量因素。
• OBKV-Table 不支持全局索引，因而不能操作创建了全局索引相关的表。