近十年来互联网技术得到了飞速的发展，越来越多的行业加入到了互联网的矩阵，由此带来了更为丰富且复杂的业务场景需求，这对于数据应用系统的性能无疑是巨大的挑战。关系型数据库 MySQL 是应用系统中最广泛使用的数据库产品，拥有强大的数据查询和强事务处理能力。在如今的云时代，应用系统逐渐演进到基于云原生 Serverless 架构去进行搭建，因为它具有低成本、高弹性的优势。但基于 MySQL 的数据存储在 Serverless 架构体系下仍存在一些明显的不足：弹性扩展能力差。Serverless 场景中一个重要特点是应用负载具有显著的波峰波谷。当面临流量洪峰时，DBA 又需要手动对集群进行扩容以避免集群被打爆；而适逢流量低谷时，则需要对集群进行缩容以节省成本。运维复杂度高。MySQL 搭建需要进行购置集群、安装服务、管理连接。业务上线后还要关注数据安全、服务可用性、响应时间等等，用于集群运维的时间占比会变高，无法把更多的精力专注于业务研发上。成本高。通常 DBA 需要预估业务规模来事先设定数据库初始容量，当业务请求量未达到预估值时，集群中的资源会一直处于闲置状态，造成资源浪费。Serverless DataBaseMySQL 支持的关系模型和其强事务的特性，使其在应用系统中有非常重要的位置，是目前不可完全替代的存储组件之一。但若一味地依赖 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（PrimaryKey）cNamepTypesIdtotal_Price……数据类型STRINGSTRINGSTRINGSTRINGDOUBLE……业务含义订单ID消费者姓名订单商品类型售货员ID订单总金额……创建一张宽表模型的订单表，属性列信息无需定义，只需定义订单表主键 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 1000000Current 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 来进行单行查询。查询一条订单示例：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 具备极致的弹性服务能力和完全零运维的特性，能够给用户带来更丝滑的使用体验。作者 | 李欣原文链接：https://developer.aliyun.com/article/845182?utm_content=g_1000315173本文为阿里云原创内容，未经允许不得转载。