01
X-Stor 介绍
X-Stor 是腾讯内部根据目前 NoSQL 领域不同业务有不同的数据模型、成本、性能的需求而研发的多模存储系统，目前支持 KV、时序、特征存储等多种模态的存储。X-Stor 的目标是基于同一个存储底座为不同协议和存储引擎提供相同的底层能力，一致性上，支持强一致/最终一致/有界一致性等多种一致性协议；存储介质上，支持数据分层、支持内存、SSD，COS 等不同介质满足用户不同需求；在容灾上，支持多 AZ、异地分布、流水备份、秒级回档等能力。
目前 X-Stor 在腾讯内部承载了包括 QQ/Qzone、微信 C2C、微信支付、广告特征、监控系统等大量关键基础业务。对外承载了多家头部车企的传感器数据监控业务。
下文主要介绍这篇论文以及 X-Stor 的多模型架构和对多租户的支持。
02
论文背景
NoSQL（Not Only SQL）是一个泛指非关系型数据库的概念，它通过对关系数据库一些特性进行简化和取舍，从而换取一些全新的优势，例如，灵活多样的数据模型，高性能，高可扩展性以及多种一致性选择。如果按照数据模型对 NoSQL 进行划分，目前主流的 NoSQL 模态大致可以分为以下几种类型：键值，文档，宽表，图以及时序。它们有着各不相同的特性，能够适配不同的业务场景，以腾讯为例，我们的社交业务可以使用图数据库来构建用户关系图谱，我们的推荐业务可以使用键值存储来换取极低的延时，我们的软件监控平台则可以使用时序存储来满足大量时间查询的需要。
使用不同的完全不同 NoSQL 来存储和管理不同的业务数据给我们带来极大的便利，然而，这种做法也存在一些问题：
- 开发一个支持全新数据模型的 NoSQL 并将其融入我们现有的系统中是困难且繁杂的，其中存在着许多重复，冗余的开发。
- 同时运维多个系统意味着复杂度非线性的增加，不同系统有着不同的数据模型和访问接口，需要运维人员去理解。
- 不同的系统独立部署，独立管控，需要额外的物理资源来搭建集群，存在着资源的浪费。
为了解决上述问题，我们开发了一款名为 X-Stor 的 NoSQL 存储产品。X-Stor 是云原生，支持多种数据模型，多租户的 NoSQL 存储系统。首先，云原生是 X-Stor 的基本属性，X-Stor 基于 TKE（Tencent Kubernetes Engine）完全容器化部署，有着优秀的弹性伸缩能力和可扩展性，还具有高可用性和多种 SLA 质量保障。其次，X-Stor 的一大特点就是它能够支持多种 NoSQL 数据模型，对于用户而言，他们可以根据自身业务的需求选择不同的数据模型、访问 API 和存储介质，并且，经过测试，集成多种模型后 X-Stor 的性能仍然能够媲美对应的单模型 NoSQL 系统，对于开发者而言，X-Stor 的多模架构使我们能够快速对新数据模型进行扩展，并支持其完整的功能。最后，X-Stor 采用了 process-level 级别的多租户设计，租户能够在一个 DBMS 进程中共享资源，进一步降低了运营的成本。
03
系统架构
下图为 X-Stor 一个标准集群的系统架构，可以看到它由控制面和数据面两个部分构成。其中，在一个集群中存在多个数据面，每个数据面提供一个特定数据模型的服务。控制面的作用是对集群中所有数据面资源进行统一管理，提供资源分配、资源调度、弹性伸缩和数据巡检等功能。这样做确保了所有数据模型都使用同一个面板进行管控，大大降低了运维复杂度和部署成本。
图片图 1X-Stor 架构图（来源于论文）
X-Stor 服务和资源管理能力的解耦以及存储层 share-nothing 架构使其能够在云上轻松进行大规模的部署，为了进一步降低部署的成本，我们还引入了混部的设计，包括利用存储节点空余 CPU 和内存资源部署无状态 Gateway service 的服务混部以及在存储节点上混合部署内存模型（In-memory model）Pod 和其他数据模型 Pod 的数据模型混部。
04
多模型设计
近年来，多模型数据库的热度与日俱增，许多现有的 NoSQL 开始支持多种数据模型，例如，MongoDB 在原有的文档模型上扩展了图模型和时序模型的支持，Redis 通过 RedisMoudle 扩展出了时序，文档等模型，还有像 ArangoDB，OrientDB 这种原生的多模型数据库。
无论是哪种多模，目前大多数现有的 NoSQL 都是在单一存储引擎上去进行新数据模型的扩展，这种设计的优点在于能够减少数据的冗余，降低存储成本，同时有助于跨模型查询的实现，然而，这种设计也存在着一些缺陷，首先，单模扩展多模的方式在扩展能力上有限，有些模型之间很难进行互通，并且缺乏对未来新数据模型的适应能力，其次，在原模型上扩展出来的数据模型的性能往往无法媲美对应的单模型数据库，最后，在原模型上扩展出来的数据模型在功能上存在一定的缺失，例如 MongoDB 扩展的图模型就缺乏了许多有特色的图查询功能。
因此，X-Stor 在多模型的设计思想就是：上层统一，底层通过插件化的多个存储引擎来支持不同的数据模型。如下图为 X-Stor 多模型支持的示意图，可以看到，在最底层 X-Stor 设计了多个插件化的存储引擎来支持不同的数据模型，这里“插件化”的含义是我们尽可能地简化了单个存储引擎的功能，只保留最基本的数据访问接口，其余的功能作为存储层中单独的组件部署（WAL，Replicator...），这样，我们在扩展一个新的数据模型的时候只需要开发对应的插件存储引擎，极大地减少了开发成本，此外，我们还可以针对单个存储引擎进行性能的优化和完整功能的实现。在上层，我们设计了统一的数据结构和接口，具体可阅读论文。
图片图 2X-Stor 多模支持示意图（来源于论文）
05
多租户支持
多租户，即通过共享资源来整合租户，从而降低成本。整合粒度越细，能够节省的资源就越多，但同时性能和安全的隔离就越困难。X-Stor 做到了 process-level 级别的多租户，也就是多个租户在一个 DBMS 进程内共享资源，实现这种多租户级别的挑战在于：
- 进程内资源完全共用，诸如 Kubernetes 资源隔离和 CGroup 等机制无效。
- 请求具有多样性，不同请求根据数据模型、访问 API 存在不同的瓶颈资源，使用如 QPS，流量等方法衡量负载不够准确。
对此，X-Stor 提出了一个全新的度量指标 Request Unit（RU）标准化来自不同数据模型租户的请求。RU 是一个抽象概念，反映了一个请求在 CPU，Memory，磁盘 IOPS 以及网络带宽四个维度上在资源消耗，其主要具有三个特性，首先，RU 能够反映请求的瓶颈资源，这意味着它可被用于进行多租户的隔离和云上的 Serverless 计费，其次，RU 是和硬件无关的，RU 的测量不会受到存储节点资源配置改变或者软件性能优化的影响，最后，RU 能够实时地去计算，它的计算方式以表格的形式提前存储在系统中，请求来临时我们只需进行查表操作就可得到其 RU 的消耗。
基于 RU 的定义和特性，我们可以对 X-Stor 进行更细粒度的资源管理。X-Stor 接入层的流量控制，存储层租户间的隔离，副本的放置策略，负载均衡机制都纳入了对 RU 的考量，具体设计可阅读论文。
06
实验评估
我们首先对 X-Stor 的性能进行了广泛的实验，主要评估的了 X-Stor 目前对外支持的三个插件化存储引擎，包括：一个基于 LSM-tree 的存储引擎，一个内存存储引擎以及一个时序存储引擎，分别采用了 db_bench，YCSB，TSBS 作为 benchmark，和 LevelDB，Redis，InfluxDB 三个较为知名的 NoSQL 进行对比，下图仅展示部分实验结果，可以看到，X-Stor 在性能上要普遍优于对应的单模型数据库。
图片
图片
图片
图片图3 性能测试实验结果（来源于论文）
接下来，我们评估了 X-Stor 基于 RU 的多租户隔离机制，如下图所示，我们分别测试了键值模型和时序模型，在引入 RU 多租户隔离后，随着 Pod 内部资源竞争的逐渐激烈，租户的延时相比没有隔离的情况要显著更低，可见通过 RU 多租户隔离可以有效防止某些激进租户占用大量的资源导致其他租户的性能受到影响，并且可适用于不同的数据模型。
图片图4 租户隔离实验结果（来源于论文）
最后，我们评估了 X-Stor 基于 RU 的负载均衡策略，我们在一个线上集群观察了 RU 负载均衡的效果，如下图，可以直观看到，触发负载均衡的迁移后，集群内高负载 Pod 被显著消除，从具体数值可以看到，负载均衡之后集群的过载现象显著减少，并且负载在 Pod 之间更为均衡（标准差降低），此外，集群的访问延时也出现了一定程度的下降。
图片
图片图5 负载均衡实验结果（来源于论文）
-End-
原创作者｜腾讯云X-Stor团队
