背景

在前面的文章中，我们提到了KV + Protobuf的组合解决方案，它是一个实用性非常强的组合，它主要面对的是读多写少、Schema复杂的业务场景，value采用Protobuf编码存储，不仅可以支持非常复杂的schema，如string、int基本类似、primitive list类型、message list类型、map等，同时编解码效率也非常高，对于业务非常友好。由于读取时读取整个value，对于一些需要整个value读取的业务场景而言，读取效率非常高。

虽然KV + Protobuf的解决方案，在某些特定业务场景下有许多优点，但它却存在许多固有的不足，无法适用于所有业务场景，存在一定的局限性和不足。举个例子，如果我们需要对value中内容更新，则业务需要Get + Decode + Update + Encode + Put的繁琐和低效操作才能实现，再比如，为了降低资源开销，业务需要读取value中一部分内容操作，可以发现，面对这些业务场景，KV + Protobuf的处理对业务而言就又变成了低效的方案。

在我们的工作中，我们创新性的基于KV存储支持了Protobuf的Schema，使得它变成一个支持复杂数据数据结构、通用性强的高效Nosql存储服务，在本文中，我们主要对它的设计和实现做一个总结。

架构和设计

上图所示，它整体的架构上采用的是Nubase的架构设计，不过为了支持Protobuf的Schema操作，我们的Dataserver包含了Storage Layer和Computer Layer，Computer Layer负责Protobuf的Schema相关操作，Storage Layer负责实际的数据存储。

业务交互流程

如上所示，业务与系统的整体交互流程主要包括两个步骤，注册表和操作表，提供给业务的是可读性好的操作接口，支持对Protobuf Schema字段级的操作。

1. Nubase存储支持Namespace隔离，不同数据存储在不同的Namespace，业务数据使用前，需要创建table，并且注册table的Schema。
2. 业务调用API可读的操作接口，比如update(table, key, name, "xx")，接口表示对table中的key，修改它的Schema中的name字段的value值为"xx"，API内部会获取table注册的Schema，然后通过编译Schema，得到Schema中字段名和字段ID的对应关系，实际发送给数据存储节点的请求为update(ns, key, 2, "xx")，存储节点收到请求后，对物理表ns中的key的Schema中字段ID=2的value修改为"xx"。

Protobuf编解码

Protobuf的编码本质上是由多个<tag, value>或<tag, length, value> ... 的pair组成，下面以一个实际的Schema为例来介绍Protobuf具体是如何编码的。

以如上所示的Schema为例，包含三个字段，类型分别int32、string、repeated message，可以看到tag的编码方式为field number << 3 | wire_type，其中wire_type有4种，对应多种数据类型的编码，我们可以看到上面的Schema编码后对应多个tag, value的pair，其中number的filed number=1，wire_type=0，所以最终tag-value的tag为0x1 << 3 | 0，value为int32经过varint编码后的值，varint编码的具体细节这里不做详细介绍，其他字段的编码类似于number字段的编码，不同的地方在于，对于字符串或者message类型，它的编码存储为tag + length + value，下面以一个具体的数据编码为例说明：

可以看到，如上的对象编码后的数据为：<0x1 << 3 | 0, 1000> <0x2 << 3 | 2, "apple">, <0x3 << 3 | 2, { 123, "size 1"}>, ... ...，我们可以进一步根据它的二进制数据理解它的编码方式：

存储处理

前面提到我们的存储处理包含Storage Layer和Computer Layer，Compute Layer主要完成Protobuf相关字段的更新、读取、排序计算等操作，Storage Layer完成数据的实际读写，当前的Storage Layer主要是KV的存储，可以支持内存型的KV，也可以支持磁盘型的KV。

如上所以，以一个实际Protobuf对象的字段级更新为例，当字段number的值增加30，更新字段name的值为orange时，存储端会先获取key对应的二进制数据，然后根据对应的字段ID找到对应的二进制数据段，最后递增或者更新对应二进制段的value，最终将修改后的二进制数据写回存储引擎。

性能

由于将Protobuf相关的更新和计算逻辑处理下沉到了存储服务，相比较业务侧的Decode + Update + Encode，存储侧直接通过二进制寻址更新实现，因此，整个的更新或者计算效率更高，根据实际的测试结果观察，无论对于primitive类型字段还是repeated message字段，相比较业务侧的更新方式，直接在存储侧的二进制寻址更新方式，整体计算时耗下降60% ~ 80%，计算效率大大提升。

由于大量的计算操作下沉到了底层存储，业务侧所需的计算资源大大减少，业务侧观察的RT降低了约70%，业务占用的Flink计算资源减少了约60%。

总结

通过将KV + Protobuf在存储侧的结合，非常好的实现了两者的互补，在可以保证KV读取性能的同时，也能够获得友好且高效的更新性能，同时，能够支持Protobuf的Schema，与Protobuf是完全兼容的，而Protobuf在行业的广泛应用，可以让这套方案具备一定的推广潜力。不过受限于时间和资源，我们当前只为部门内部提供了一些较为通用和定制的操作方式，通用性方面还需要完善，如果需要让它成为一套通用性非常强的分布式Nosql存储服务，还有一定的工作需要完成。