作者
朱建平，TEG/云架构渠道部/块与表格存储中心副总监。08年参加腾讯后，承担过目标存储、键值存储，先后负责过KV存储-TSSD、目标存储-TFS等多个存储渠道。
NoSQL 技能和职业背景
NoSQL 是对不同于传统联系型数据库的一个统称，提出 NoSQL 的初衷是针对某些场景简化联系型数据库的规划，更简单水平扩展存储和核算，更侧重于完成高并发、高可用和高弹性性。
NoSQL vs 联系型数据库
其实早几年咱们看两者的区别是明晰的，联系型数据库便是用 SQL 语句操作，具有行列结构和预定义 scheme 的二维表；NoSQL 是 Key-Value 存储，它是一个散布式的 Hash Map 的存储。但最近几年却有些不明晰了？首要是呈现 NoSQL 的部分产品也开始增强在SQL的接口和事务等方面的才能，比如 Cassandra 支撑 CQL，DynamoDB 支撑 PartiQL，InfluxDB 也支撑 InfuxQL 等。这儿我的看法是，NoSQL vs 联系型数据库的关键差异：联系型数据库具有强壮的 ACID 事务、杂乱 SQL 检索、数据完整性绑缚等才能，这给它带来很好的易用性，但一同也是它完成高并发、高可用和高弹性性的绑缚；NoSQL 在工程完成上做了个取舍平衡，弱化乃至舍弃了在跨分区事务、散布式JOIN等维度的才能，增强其在高并发、高可用和高弹性性方面的才能。
多模型 NoSQL 的数据模型
多模型 NoSQL 中的多模型是指这儿包括多个数据模型：键值模型 Key-Value、宽表模型 Wide-column、文档模型 Document、时序模型 Time-series、图模型 Graph 和内存模型 in-memory 等。咱们能够简单理解，Key-Value 是个哈希表，Wide-column 是个多维的哈希表即 Key-Key-Value 结构，文档 Document 是类似于 Json 结构的一个嵌套树结构，Graph 是以顶点和边组成的杂乱图结构，Time-series 是按时刻有序的一个检索表。
数据模型运用和展开能够从受欢迎程度和添加速度两个指标来看。受欢迎程度反映着应用推广的累积效应，排名前三的依次为 文档>键值>宽表；添加速度代表着未来需求的反应，排名前三依次 时序>键值>图，其中时序和图得益于物联网LoT以及实时核算等方面需求现在添加较为迅速，国外 NoSQL 的一些创业公司，近期较多集中在时序和图存储相关范畴。
NoSQL 存储范畴的业界玩家
首要分为三类：笔直范畴的开源社区、多模型 NoSQL 公司 和公有云厂商。
笔直范畴的开源社区，包括键值存储范畴的 Redis，文档存储的 MongoDB，时序存储范畴的 InfluxDB、图存储的 Neo4j 等，这些公司都是从笔直开源社区多年的竞赛中包围出来的赢家，把握了笔直范畴的生态和接口的规范，依据公有云展开支撑多云的企业服务。
多模型NoSQL公司，如YugabyteDB、Aerospike等，尽管也是开源，也是依据公有云展开支撑多云的企业服务，但并不把握笔直范畴生态和接口规范，更多地兼容Redis、Cassandra、PG（PostgreSQL）等接口规范去融入已有的生态。
公有云厂商，如微软 Azure CosmosDB、亚马逊 AWS DynamoDB 等，供给了云原生的托管存储服务，在接口上选用自定义或许直接兼容开源社区的 Redis 和 Cassandra 等笔直范畴的接口。
而咱们的 NoSQL 属于这儿的第三类玩家。
据商场揭露数据显现，最近几年这三类厂商都有比较好的商场增速，但也存在着笔直范畴、开源社区和公有云厂商的一些对立和竞赛。
NoSQL 存储的展开方向与趋势
公司内部自研的 NoSQL，源于早些年结合事务场景的定制开发。比如咱们 oTeam 中的 CKV+、TSSD、PCG 的 BDB 、Grocery 等。可是面向云原生的场景下、新的软硬件基础设施升级以及新场景的扩展支撑也面对着新的挑战，以及无法一同兼顾内部自用与云上外部客户的一些诉求。
首要，云原生场景下客户对自研提出了更高的要求。例如要求免除云厂商的绑定，便是选用业界 API 的接口规范，支撑多可用区和地域的散布，弹性弹性，按需付费容器化和散布式云等方式布置。
其次，持续提高的基础设施才能对底层存储提出更高要求。曩昔几年，公司机房、网络环境、微服务结构、体系、软件等基础设施方面的才能都得到极大的提高，如 SSD 单盘容量，以及单台存储服务器装备的磁盘数量都有了较显着的添加，新 TRPC 结构、新网络和新的磁盘 IO 通道，如 RDMA/DPDK、SPDK/IO_URING 等才能的推出，均要求底层的存储架构进行不断地适配，以获取更高的性价比。
最终，个性化内容推荐和物联网监控等新生场景呈现。相较于以往咱们在交际网络中的键值存储场景，近年来也呈现了诸如个性化内容推荐中的特征存储、物联网/监控中的时序存储等新生场景，而它们在 API 接口、功用、存储引擎等方面跟以往的键值存储运用是有所差异，需要能复用渠道的大部分才能，一同也需要能定制部分组件。
为了应对新的机遇和挑战，咱们联合了 PCG、CSIG、WXG 和 IEG 相关团队，在2021年组建了多模型 NoSQL 的 Oteam，支撑新的事务场景。经过 oTeam 各方的一同努力，从零研发出多模型 NoSQL 渠道(X-Stor)，现在已完成了渠道技能才能和规模化运营才能的初步建设。
从头再造–多模型 NoSQL 体系架构
多模型 NoSQL 架构和方针
多模型 NoSQL 两个中心方针：一是要供给稳定强壮的渠道底座，供不同的扩展完成复用；二是供给快速适配的才能，供事务定制化开发或许是新的场景的扩展。
渠道底座，包括在线拜访相关和管控相关。一 在线拜访相关部分，供给高度可扩展的数据处理结构，具体包括支撑多种数据共同性，数据分区与多 AZ/Region 的数据副本复制、数据分层以及索引和事务等方面的才能。二 管控相关的部分，供给工作流引擎 WorkFlow，并依据这个工作流引擎完成了资源办理、数据搬迁、数据备份和定点回档、数据巡检等运营管控才能。
快速适配，包括可扩展多模型API和存储引擎结构。可扩展多模型 API，便利协同方依据事务场景需求定制拜访协议。现在的 API 接口已支撑TSSD/BDB/Grocery 等存量键值存储渠道的接口和功用，一同也支撑了部分 Redis 的接口。存储引擎的结构，便利依据事务场景定制自己的存储引擎，在内存占用和磁盘 IO 资源方面进行取舍和平衡。现在已经支撑的 LSM-Tree 的 RocksDB 存储引擎，依据Hash的 FasterKV 引擎和依据 TSM-Tree 的时序 TSDB 存储引擎。
多模型 NoSQL 资源概念
多模型 NoSQL 资源概念，咱们分为用户资源和物理资源。
用户资源是用户创建的逻辑资源，首要有 Account、Keyspace、Collection、Partition、Replica。这儿咱们比较生疏的可能是 Account 这个概念。多模型 NoSQL 的 Account 首要不是为了计费规划的，它跟腾讯云的账户或许公司内计费的 OBS 体系的账户不相同，首要目的是便利客户装备 Collection 的公共特点，以及底层依据 Collection 的相关性做资源的共享，比如接入机相关的北极星的进口，乃至同账户下的 Replica 副本将他们调度到一同，便利在资源层面进行多租户隔离和复用。
物理资源是办理的服务器资源，现在咱们申请的存储服务器和接入/逻辑类的TKE容器。关于存储服务器进行容器化，比如对一个装备了12块SSD 的存储服务器，咱们创建了12个 TKE 的容器，让每个容器相关到一块 SSD 盘，咱们称之为一个 Pod，相应地这台存储服务器咱们称之为一个 Node。依据硬件的物理散布，咱们给每个 PoD 的相关地域特点 Region，集群特点 Cluster，子集群的特点Subcluster Group，咱们称为 SCG，子集群特点Subcluster Region、Subcluster Group 和 Subcluster 之间是逐层包括的一个联系。SCG将指定数量的Node组成一个节点组，而 Subcluster 的是加 SCG 的部分盘组成的一个盘组。经过将一个Partition多个副本散布在这些Group的内部，便利有效地办理一同多个节点或许磁盘毛病带来的危险，一同也能操控咱们在毛病产生时的爆破半径，影响半径。有爱好的同学能够在网上 google 下 CopySet 的论文，对其原理做进一步的了解。
多模型 NoSQL 模块结构
多模型 NoSQL 的模块架构中，咱们分为数据面和操控面。数据面首要是指事务在线增/删/改/查恳求途径上的模块；操控面是事务的操控台、运维体系，或许内部的定时使命保护处理所触及的模块。
数据面模块架构，为便利长尾延时的管控和本钱的操控，选用两层规划，服务一个恳求后端最多经过两跳，事务场景需求规划三类恳求处理。
常规途径（标①），恳求抵达接入层 gateway，其查询本地缓存的元信息，并将恳求转发给底层的存储模块cell，独立gateway布置便利于收敛前端网络连接数，以及事务前端不支撑定制SDK的场景。
缓存途径（标②），恳求抵达接入层 cache，其查询本地的内存缓存，假如射中就直接返回，假如不射中，拜访底层存储模块 cell 查询获取并通知 cache 主节点，由 cache 主节点依据预装备的缓存战略更新缓存并依据共同性协议同步更新给一切 cache 从节点。便于降低有显着热点效应的事务恳求，降低拜访本钱。
定制途径（标③），经过定制的 sdk 答应客户端直连存储节点，完成一跳拜访，一同也能够将部分核算功用卸载到客户端上履行，有利于降低拜访延时，减少核算本钱。
操控面模块结构，操控面对外的拜访进口有两个拜访网关和三个内部部分。拜访网关为 userAdmin 和 sysAdmin，userAdmin 是供客户操控台API拜访的网关，sysAdmin 是供运维体系拜访的网关。内部三个部分分别是元数据的存储和分发、工作流 Workflow 和监控。
元数据存储和分发，首要是资源办理服务，包括资源办理服务(RM)和资源办理缓存服务(RMC)。元数据选用散布式的强共同存储，现在是五副本存储在 CMongo 中，未来会考虑闭环存储于本身体系里边。RMC是为了便利于元数据分发而规划的，数据面的 gateway 和 cache 服务发动后会注册到RMC，便利 RMC 做元数据的增量、推送、分发和一次性校验，经过 userAdmin 和 sysAdmin 网关拜访 RM，完成元数据的更新，RMC 经过更新流感知到这个数据的变动，并推知元数据的更新给注册到自己的 gateway 和 cache 容器。
工作流 Workflow，以往存储管控的实践中，通常是依据微服务架构规划数据搬迁服务、数据巡检服务、数据调度服务、容量收集服务、数据冷备服务、资源上下架服务等很多的独立模块上来完成存储管控。尽管完成了较好的弹性性，但模块多会添加开发、保护、运营、办理方面的本钱。在 X-Stor 中，咱们规划的是 Workflow 结构，搭积木的方式装备拼装处理流程，完成可重入的履行。经过 Workflow 结构，结合容器化布置，共用一个 Workflow 服务来完成上述的一切功用，一同自动弹性和容错，对一切的 Workflow 履行、日志存档和审计等才能也非常简单完成。
监控，经过在每个服务器 Node 的上面本地布置 NodeAgent，实时汇集本 Node 上的各个容器的状况信息，而且推送给集群的 Monitor 服务。 Monitor 服务对接到 Prometheus 的存储、集群调度服务、监控报警组件如 TEG 智研监控宝等，能够便利地按集群完成实时调度和依据 Grafana 定制一个自己的可视化 Dashboard。
云原生才能规划与考虑
可扩展和云原生是咱们规划多模型 NoSQL 时考虑的两个方针。前面介绍了完成扩展性的相关的架构内容，体系助于扩展性，支撑多种数据拜访、API 和存储引擎来完成多模型存储。接下来我想共享下在云原生上的规划考虑。
云原生这个词是最近几年咱们常常听到的概念，但当你百度这个概念时却发现很难比较明晰的理解。我个人的理解，云原生中心有两个概念，云原生产品和云原生技能。云原生产品是在公有云遍及的大背景下，站在客户的视角，对云端供给服务的产品提出的才能和要求，比如弹性弹性、可观测性等。云原生技能是协助完成云原生产品的技能手段，如容器、服务网格、微服务、不可变的基础设施和声明式 api 等。多模型 NoSQL 从规划之初，咱们就与相关的原生技能进行紧密结合，考虑了依据云原生的才能。咱们云原生的特性要点体现在敞开性、弹性弹性、按需付费、多 AZ 和 Region 数据散布四个方面。
01 敞开性
多模型 NoSQL 的敞开性首要在下面三个维度进行体现。
首要，接口和功用的敞开。客户出于本钱、容错等方面的考虑提出了多云的诉求，要求对云端产品打破厂商绑定（Vendor Lockin），需要产品能够完成在不同的云厂商间搬迁。云原生产品需要尊重这个考虑，咱们放弃了锁定自定义私有协议和接口，转向全面兼容笔直社区软件接口和功用，如 Redis、InfluxDB 等，未来还会在数据搬迁 DTS 才能方面进一步补齐。
其次，支撑扩展、敞开互联的连接器（Connector）。不断丰富跟公有云上的其他的云原生产品完成互联互通，如现在咱们已经支撑的数据镜像、备份和更新流水存放于目标存储产品 COS 或许其他兼容 S3 接口的产品，更新流能够导入到咱们 Kafka 队列中，未来可能会推出更多的连接器，能连接到相关的云端产品。
最终，在资源层面，布置产品时不锁定特定的硬件资源。咱们率先在公司内完成了从接入到存储完全架构在 K8S 的容器化化环境中，从才能上能够支撑多云和散布式云的布置。
02 弹性弹性
弹性弹性，是云原生产品非常重要的才能，处理以往自行开发在软件架构层面或许在资源层面上面对的一些瓶颈。多模型 NoSQL 从客户资源、服务器或许容器资源方面完成了弹性弹性。
首要，经过散布式强共同存储和分发的架构，供给强壮的元数据存储和拜访才能，支撑用户的库表数量和单个库表容量的弹性才能；经过水平弹性的架构和底层的调度才能，支撑单个表在存储和拜访容量上无限横向弹性。
其次，经过对资源的容器化和规范化，完成了从公司大的资源池中实时申请和开释容器资源，便于咱们快速地满足事务在资源标准、资源数量和资源在机房散布等方面的要求。
最终，在弹性的速度和功率方面，凭借前面说到的数据副本的散布战略和数据的实时收集调度，完成了极速地扩容和自动化弹性，笔直弹性小于10秒，4TB 水平弹性小于5分钟。
03 按需付费
按需付费，是云原生产品协助客户完成低本钱运营的关键才能。在这方面咱们首要完成了两个方面的才能。
一是存储和核算的分隔计费。不需要客户从几个预定标准的容器中去做选择，客户仅需要重视于存储容量和核算容量，底层经过集约化办理给各个库表预留的 Buffer Pool，经过多租户技能和装箱调度，提高资源的整体利用率，经过咱们的资源池办理和资源利用率提高达到协助客户去节省运营本钱。
其次，灵敏选择。经过在客户操控台/API 中便利灵敏选择，而不是刚性地绑缚/锚定，完成贴合事务场景需求来完成最高的性价比。如咱们在于数据的共同性，数据的副本数，多 Region 的散布，数据生命周期，乃至存储介质方面灵敏地装备。在资源独享方面，平衡本钱和性能，在存储机和接入机方面独享和混用，能够独立装备。
04 多 AZ 和 Region 散布
多 AZ 和 Region 散布，是云原生产品完成高可用性、数据高可靠性方面的基础要求。
公有云中的 AZ 和 Region 跟咱们常见的机房和城市的概念不完全相同。好像 Region 下的多个 AZ 要求相距30到100千米，RTT 一般在0.5到2毫秒以内。不同 Region 间的物理距离一般在100千米以上。X-Stor 经过对资源构建 AZ 和 Region 的特点，并结合集群调度、数据同步等方面的支撑，完成了多 AZ 和 Region 数据散布的才能，可结合事务本身关于数据的共同性需求完成就近拜访；一同也计划在多 Region 散布的基础上，支撑异地多活（Multi-Master）。关于多 Region 散布的 Collection，能够在恣意的 Region 中就近写入，内部咱们关于 Region 间的数据进行复制，并处理并发冲突的问题，进一步优化写延时的体会。
关于咱们
更多关于云原生的案例和知识，可重视同名【腾讯云原生】大众号~
福利：
①大众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~
②大众号后台回复【系列】，可获得《15个系列100+篇超有用云原生原创干货合集》，包括Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。
③大众号后台回复【白皮书】，可获得《腾讯云容器安全白皮书》&《降本之源-云原生本钱办理白皮书v1.0》
④大众号后台回复【光速入门】，可获得腾讯云专家5万字精华教程，光速入门Prometheus和Grafana。
