作者 | 李欣

近十年来互联网技术失去了飞速的倒退，越来越多的行业退出到了互联网的矩阵，由此带来了更为丰盛且简单的业务场景需要，这对于数据利用零碎的性能无疑是微小的挑战。​

关系型数据库 MySQL 是利用零碎中最宽泛应用的数据库产品，领有弱小的数据查问和强事务处理能力。在现在的云时代，利用零碎逐步演进到基于云原生 Serverless 架构去进行搭建，因为它具备 低成本、高弹性的劣势。但基于 MySQL 的数据存储在 Serverless 架构体系下仍存在一些显著的有余：

1. 弹性扩大能力差。Serverless 场景中一个重要特点是利用负载具备显著的波峰波谷。当面临流量洪峰时，DBA 又须要手动对集群进行扩容以防止集群被打爆；而适逢流量低谷时，则须要对集群进行缩容以节省成本。
2. 运维复杂度高。MySQL 搭建须要进行购买集群、装置服务、治理连贯。业务上线后还要关注数据安全、服务可用性、响应工夫等等，用于集群运维的工夫占比会变高，无奈把更多的精力专一于业务研发上。

3. 老本高。通常 DBA 须要预估业务规模来当时设定数据库初始容量，当业务申请量未达到预估值时，集群中的资源会始终处于闲置状态，造成资源节约。​

   Serverless DataBase

   ​

MySQL 反对的关系模型和其强事务的个性，使其在利用零碎中有十分重要的地位，是目前不可齐全代替的存储组件之一。但若一味地依赖 MySQL 又会使得利用零碎无奈齐全 Serverless 化，不能享受 Serverless 带来的极致弹性。
​

在阿里外部咱们有一些新的架构实际，那些须要强事务处理的数据仍旧应用关系表存储，而对于非强事务表数据存储，咱们则设计出了一款领有极致弹性的 Serverless 表存储。

对于 Serverless 数据库产品，咱们的设计要求是必须具备以下几个特色：
​

• 齐全弹性。可依据利用负载主动弹性扩缩容，这一个性可为用户带来更经济的计费模式和更丝滑的体验。
• 按量计费。Serverless 数据库的应用老本次要来自于计算成本和存储老本。用户只需为业务理论产生的存储单元和响应单元付费，节省成本。
• 零运维。即开即用，无需治理容量、水位、软件降级、内核优化等运维事项，真正让研发专一于业务开发。

​

Serverless 架构在诸多业务场景中都有宽泛的利用实际。例如世纪联华团体在其外围的电商业务中，针对自建 IDC 机房遇到的资源难以估算、零碎部署艰难等痛点问题，将业务实现全面上云并逐渐革新为全 Serverless 架构的中台模式。

世纪联华团体采纳了函数计算 + API 网关 + Tablestore 计划，轻松撑持起了 6.18、双 11 等大促流动。其中，表格存储 Tablestore 作为世纪联华电商零碎的云上 Serverlesss 架构中的外围存储，具备极致弹性、免运维、成本低等劣势。

表格存储 Tablestore 简介

​

表格存储 Tablestore 于 2009 年阿里云成立之初便立项研发，基于底层飞天平台从零开始构建，是一款多模型、多引擎的 Serverless 表存储。在公共云上输入了国内外 30 多个区域，领有 1.5 万服务器规模和 200PB 存储规模，是阿里云泛滥商业化产品的底层外围存储。
​

同时在线下已输入到金融、能源、电力、物流、医疗、政企等行业，服务于公共云 1000+ 企业客户和 500+ 线下我的项目。
​

表格存储 Tablestore 具备 HBase 和 ElasticSearch 的交融性能，领有极致弹性体验、免运维、即开即用的个性，反对 GB 到 PB 的弹性存储和 十万级 TPS 服务能力的无感知扩大。撑持海量的表数据的同时，提供丰盛的数据检索与剖析能力，是集存储、搜寻和剖析多功能一体的一站式结构化数据存储平台。
​

表格存储 Tablestore 的整体架构如下图所示：

Tablestore 架构图

表格存储提供了多种数据模型，次要包含宽表模型（Widecolumn）、音讯模型（Timeline）和时序模型（Timeseries）。

• 宽表模型次要承载表构造数据存储，例如电商订单数据。
• 音讯模型次要承载音讯数据存储，例如 IM/Feeds 音讯。
• 时序模型次要承载时序数据存储，例如物联网设施时序数据。

上面咱们将以电商订单场景为例子，带大家体验基于 Tablestore 的宽表模型构建一个 Serverless 的订单存储系统。​

Tablestore 体验

1、筹备工作

​

在体验 Tablestore 带来的极致弹性之前，须要筹备如下几个步骤：
​

（1）创立一个阿里云账号，并获取到阿里云账号的 AK。_（云账号 AK 是拜访所有云服务包含 Tablestore 的密钥，后续须要通过 AK 来拜访 Tablestore 服务）。_

​

（2）下载并启动 Tablestore 提供的命令行工具 Tablestore CLI，命令行工具提供一些简略的指令来治理表格存储服务。
​

首先通过 config 命令配置连贯密钥并通过 enable_service 命令开明 Tablestore 服务：
​

config –id accessKeyID –key accessKeySecretenable_service
​

（3）通过 create_instance 命令创立一个实例：

​

create_instance -d “order storage” -n serverless-db -r cn-hangzhou
​

实例相当于 MySQL 数据库的概念，实例创立后无需思虑实例所在物理机集群的水位，只需专一开发业务逻辑即可。同时实例上的读写和存储均为按量计费，若无读写无存储，理论则不会产生任何费用。

至此，一个可能反对 GB 到 PB 存储的、无并发限度、零运维、齐全弹性的 Serverless DataBase 就创立实现了。
​

2、创立表

​

宽表模型是（Widecolumn）是 Schema-free 的一种数据表，与关系型数据库 MySQL 不同的是，创立一张表 Widecolumn 模型的数据表仅须要定义主键构造，并不需要定义属性列构造。
​

例如一张订单表 order 的表构造如下图表格所示：

|

创立一张宽表模型的订单表，属性列信息无需定义，只需定义订单表主键 id，命令如下：

​

create_instance -d “order storage” -n serverless-db -r cn-hangzhou
​

执行 create 命令后胜利创立一张订单宽表，刚创立的订单宽表会被初始化 1 个数据分区。

随着订单数据量的减少或访问量的减少，宽表模型会依据第一主键的散布范畴_（上述数据模型中即是订单 ID）_决裂扩大成多个数据分区均匀散布到多台物理机上以反对更大的数据规模_（TB 甚至 PB）_和读写吞吐_（十万 TPS 以上）_，整个扩大过程齐全由服务端主动实现，无需人工干预。
​

3、数据导入

​

模仿生成了 100 万条样例订单数据，并通过 import 命令批量导入到 order 表中。单数据分区的写入速度能够达到几万行 /s，随着分区扩大，写入吞吐还能够进一步提高。

import -i orderDataFile -l 1000000
Current speed is: 10000 rows/s. Total succeed count 10000, failed count 0.Current speed is: 12600 rows/s. Total succeed count 22600, failed count 0…….Current speed is: 9200 rows/s. Total succeed count 1000000, failed count 0.Import finished, total count is 1000000, failed 0 rows.

4、订单查问

应用 get 命令依照订单号（id）单行查问宽表模型，失去一条订单数据。get 命令只可能基于 rowKey 来进行单行查问。
​

查问一条订单示例：
id = “0000005be2b43dd134eae18ebe079774”

get –pk ‘[“0000005be2b43dd134eae18ebe079774”]’
+———————————-+——-+——–+———+————-+—————+——–+——–+———-+——–+———+——-+——-+——–+————+| order_id | cId | cName | hasPaid | oId | orderTime | pBrand | pCount | pId | pName | pPrice | pType | sId | sName | totalPrice |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+——–+———+——-+——-+——–+————+| 0000005be2b43dd134eae18ebe079774 | c0015 | 消周五 | false | o0035062633 | 1507519847532 | 小米 | 3 | p0005003 | 小米 6 | 2299.21 | 手机 | s0017 | 售郑七 | 6897.63 |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+——–+———+——-+——-+——–+————+

5、订单检索与统计

​

订单场景中常常会呈现依赖多条件组合筛选，这种状况下须要依赖 Tablestore 的多元索引个性。多元索引是 Tablestore 提供的相似 Elasticsearch 的表数据索引，反对丰盛的查问形式和数据聚合能力，可在多个列上别离建设索引。和 MySQL 中的联结索引不同的是，多元索引可依据任意字段组合查问，不会依照多列的最左前缀来匹配。

例如咱们在 id、pName、totalPrice 等字段上别离建设索引，采纳倒排索引、分词、BKDTree 等数据结构，提供了准确查问、全文检索、范畴查问等查问能力。另外，多元索引也反对按字段分组、多字段排序以及统计聚合能力。

应用 create_search_index 命令在宽表上建设多元索引，起到查问减速的作用。

create_search_index -t order -n order_index{“IndexSetting”: null, “FieldSchemas”: [{ “FieldName”: “id”, “FieldType”: “KEYWORD”, “Index”: true, “EnableSortAndAgg”: true, “Store”: true},{“FieldName”: “pName”, “FieldType”: “TEXT”, “Index”: true, “EnableSortAndAgg”: false, “Store”: true},{“FieldName”: “totalPrice”, “FieldType”: “DOUBLE”, “Index”: true, “EnableSortAndAgg”: true, “Store”: true} …_// 其余字段_ ] }​

Tablestore 反对 SQL 查问能力，兼容了 MySQL 的查问语法，并且尽量保留了关系型数据库的应用习惯。SQL 可能主动抉择索引并进行查问减速，通过多元索引的查问减速，在百亿数据规模下也具备了毫秒级提早查问的能力。
​

依据 sName、pBrand、pName 三个字段条件进行订单检索：

select * from order where sName = “ 售周五 ” and pBrand = “ 小米 ” and pName like “ 红米 %”limit 3;
+———————————-+——-+——–+———+————-+—————+——–+——–+———-+———+——–+——-+—————+——-+——–+————+| id | cId | cName | hasPaid | oId | orderTime | pBrand | pCount | pId | pName | pPrice | pType | payTime | sId | sName | totalPrice |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+———+——–+——-+—————+——-+——–+————+| 00001c760c04126da067e90409467c4e | c0022 | 消赵一 | true | o0009999792 | 1494976931954 | 小米 | 3 | p0005004 | 红米 5s | 499.01 | 手机 | 1494977189780 | s0005 | 售周五 | 1497.03 |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+———+——–+——-+—————+——-+——–+————+| 0000d89f46952ac03da71a33c8e83eef | c0012 | 消钱二 | false | o0024862442 | 1502415559707 | 小米 | 2 | p0005004 | 红米 5s | 499.01 | 手机 | null | s0015 | 售周五 | 998.02 |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+———+——–+——-+—————+——-+——–+————+| 0000f560b62779285e86947f8e8d0e4c | c0008 | 消冯八 | false | o0000826505 | 1490386088808 | 小米 | 1 | p0005004 | 红米 5s | 499.01 | 手机 | null | s0015 | 售周五 | 499.01 |+———————————-+——-+——–+———+————-+—————+——–+——–+———-+———+——–+——-+—————+——-+——–+————+

​

统计所有订单中每个商品品牌的订单数：

select pBrand,count(*) from order group bypBrand;
+——–+———-+| pBrand | count(*) |+——–+———-+| vivo | 162539 |+——–+———-+| 联想 | 304252 |+——–+———-+| oppo | 242513 |+——–+———-+| 苹果 | 96153 |+——–+———-+| 小米 | 194543 |+——–+———-+

总结
​

表格存储 Tablestore 作为一款广泛应用 Serverless DataBase，提供了经济的计费模式，能大幅缩减业务老本。以上文订单场景为例子，在一亿订单数据量级和均匀 2000TPS 的读写量下，采纳表格存储 Tablestore 仅需不到 400 元 / 月 的应用老本。与此同时，Tablestore 具备极致的弹性服务能力和齐全零运维的个性，可能给用户带来更丝滑的应用体验。

如对本文中所述有疑难或者心愿进一步理解表格存储，能够钉钉搜寻群号：“23307953”，群内提供收费的在线专家服务，欢送退出。

更多内容关注 Serverless 微信公众号（ID：serverlessdevs），会集 Serverless 技术最全内容，定期举办 Serverless 流动、直播，用户最佳实际。