TableStore多元索引，大数据查询的利器

太过爱你忘了你带给我的痛 2022-02-14 13:47 361阅读 0赞

随着互联网发展的深入，互联网开始下沉到各行各业进行互联网改造，比如进入网约车、出租车行业的滴滴，将出租车行业互联网化，改造之前，出租车的分布、订单轨迹、人流热度等交通数据都是直接废弃导致无法利用起来。改造之后，整个城市的出租车的实时分布、订单运行轨迹、人流热度等等这些都能实时观测到的，可以用于交警、行人、出租车提前规划更合理的路线，加快了整个城市的运行效率。在这个互联网改造过程中，最核心的就是出租车的运行和运营数据，比如实时轨迹、订单信息、地理热力图等，这些数据就是一些结构化或半结构化的数据，需要为这些数据寻找一种合适的存储系统。考虑到这些数据的存量和增量非常大，都是以亿为单位，如果要存这些海量的半结构化的数据，最合适的莫过于分布式的结构化或半结构化存储系统。

这种互联网改造的过程不仅仅发生在交通行业，也发生在很多其他传统行业，其他传统行业的这类数据存储需求也是一样的。

目前业界可用的分布式结构化、半结构化存储系统，有开源的HBase，如果使用云服务，那么有Amazon的DynamoDB、阿里云的TableStore和Google cloud的Bigtable，后三种都是Serverless服务化的，用户只需要关注开发，不再需要关注运维等闹心的事情了，更适合如今高效率的开发节奏。

# 现状 #

上一节提到的几种大数据存储系统都是LSM架构的，这些系统虽然专门是为了存储海量的半结构化数据存储而生，但是优点也仅限于此。可以轻轻松存储几PB，甚至几十PB数据，且数据的写入、查询能力不会随着数据增长而下降，也就是说，当系统里面存储1GB或1PB数据的时候，写入、查询性能基本相同，非常适合于存储大规模数据。

但是查询能力就比较弱，只能提供两种查询，一种指定完整PK的单行完全命中查询（GetRow），另一种是指定PK前缀、部分命中的范围查询，归根到底，其实也就只有一种查询，那就是只能按PK来查询，无法根据非PK的属性列查询。如果有属性列查询的需求，就只能通过各种办法缩小PK范围，然后全部扫描出来，再过滤，这样查询性能就比较差了，很多场景下性能会差到根本就无法接受。

更严重的是还有大量的查询场景无法支持，比如模糊查询，多字段自由组合的ad-hoc查询、分词查询、地理位置查询，排序和统计等，最后只能通过限制上层应用的功能解决，但是这部分功能很可能就是用户迫切需要的，比如滴滴的历史订单功能页面，只能通过时间从前往后看，没法按照起点、终点、费用、时间段、乘车类型和评价星级等查看历史订单。

总之，当前这些系统在查询方面的不足，主要体现在下面几点：

*  无法满足任意条件组合查询需求
 *  无法支持地理位置查询
 *  无法支持模糊查询
 *  无法支持分词查询
 *  无法支持多列的排序和翻页
 *  无法支持轻量级的分析，包括统计聚合等。

目前的现状其实就是：解决了存储的问题，但是没解决查询的需求，而数据的价值只能通过查询体现，查询的需求迫在眉睫。

# 多元索引 #

为了解决上述这些不足，也为了充分释放产品的功能潜力，TableStore研发了多元索引功能集。在原有的主键查询方式基础之上，额外提供了下列能力：

*  多条件自由组合查询
 *  模糊、前缀查询
 *  具备分词能力的全文查询
 *  排序和多种翻页功能
 *  地理位置查询
 *  轻量级分析，比如统计、聚合等

具备上述功能后，TableStore在保证写入性能不下降的前提下，查询能力又有了非常大的提升，更加适合存储海量结构化和半结构化数据，数据不仅可以快速存储，还可以方便、快捷的查询分析。

再回到文章开始时例子，如果将出租车的订单存储在TableStore，那么就可以轻松实现按照起点、终点、费用、时间段、乘车类型和评价星级等查看历史订单，也可以按照月份、车型、目的地等生成实时报表，有了这些功能后，用户体验就更好了，也会成为应用的核心竞争力，以前不能实现的功能，现在都可以轻松实现了。

# 使用 #

多元索引是一个强Schema的索引系统，在使用之前，需要先创建Schema，目前支持通过官网控制台和SDK创建SearchIndex。已经在Java、Golang、C\#、Node.js和Python等SDK中支持完整的SearchIndex功能。

如果当前Table中已经有数据，当创建好多元索引后，Table中数据会通过内部的系统自动开始建立索引（build index），建立索引过程中的状态可以在官网控制台或者通过SDK的DescribeSearchIndex接口查询，结果会显示当前阶段（全量、增量）：

*  全量的含义是正在对Table中原有数据建立索引。
 *  增量的含义是正在对创建Index之后新写入的数据建立索引。

如果是增量阶段，则会有一个最新建立index的时间，当前时间减去这个时间就是用户将数据写入Table成功，到可以在SearchIndex中查询到的延迟，一般在秒级别（1~10秒），比如如下图：

![1550719237600-4f160dc6-dafd-426e-82b3-8b][] 上图的含义是：表名是zelda，这张表对应的索引是big\_index，这个索引中有4209350752行数据，当前索引建立状态是增量状态，最新建立索引成功的时间是2019-02-21 11:20:06，后面是控制类的功能。

在控制台上，不仅可以创建多元索引，查询多元索引Schema等外，还支持比较简单的查询功能，比如单字段查询、范围查询、分词匹配查询、前缀查询、多字段组合查询和排序等，其他的较复杂的嵌套查询，地理范围查询等可以通过SDK实现。

TableStore是一个Serverless的服务化产品，用户无需关心“运维”，只需要关注“开发”，提供类Restfull API和SDK，怀着“将复杂留给自己，将简单留给客户”的初心，让用户在使用上尽量简单，同时也不用考虑存储容量、机器水位等多种繁杂的问题。同样的，多元索引也是基于这一目标，用户只需要创建索引，就可以直接通过阿里云官网控制台体验查询，通过SDK的Search接口实现各种查询需求。

如果想对多元索引有更深入的了解，可以阅读下列文章：

1.  《如何用表格存储翻页》。
2.  《TableStore符合类型：Array和Nested介绍》。
3.  《TableStore多元索引路由介绍》。

# 场景 #

TableStore是一款阿里云为结构化、半结构化数据自研的大规模存储系统，适用场景众多，尤其是大规模数据的存储和查询，下面会简单列举几种常见的场景或需求。

## 1. 订单系统 ##

订单系统是各类应用或系统中最常见的一种系统，常见的有：

*  电商网站的历史订单
 *  商场、零售店、超市和酒店等的历史订单
 *  网约车、出租车的历史订单
 *  财务系统中的历史记录

任何一家企业都会至少有一个类似订单系统的系统存在，这一类系统的特点是，数据持续产出，每条数据的属性很多，一般都在10个以上，甚至有些复杂系统可能有上百个，这种数据需要存储时间长，因为有些时候需要通过这些数据调查历史问题。

针对这类系统，最难得地方是查询复杂，所有属性列都需要支持查询，且查询条件不固定，同时数据量又大，一般的解决方法是以下两种其一或者结合：

*  最近1个月的数据存储在MySQL等单机关系型数据库，如果用心观察，很多产品的订单只能查询最近1个月或3个月的，再长就不支持了，原因就是单机容量的限制。同时，由于MySQL只有二级索引，只能查询固定列的组合，如果属性多了后就会不太适合了。
 *  存储在HBase等系统，但是只支持按顺序查询，比如滴滴的历史订单，不支持按任意属性查询。

不管采用哪种方案，都是牺牲产品的用户体验为代价的。

更详细的场景文章介绍，可以参考下面两篇：

1.  《[基于TableStore的海量电商订单元数据管理][TableStore]》。
2.  《[TableStore实战：亿量级订单管理解决方案][TableStore 1]》。

## 2. IM/Feeds ##

常见的社交类应用都是这一类，比如QQ、微信、Line和钉钉属于IM，朋友圈、微博属于Feeds，这一类系统主要包括两部分，一是消息存储和分发，一是消息Meta存储和查询。

消息存储和分发可以采用TableStore专门为IM/Feeds系统量身打造的Timeline模型，不管是写扩散（推模式）还是读扩散（拉模式）都能轻松处理，尤其是TableStore拥有强悍的千万行每秒的写入能力，非常适合于写扩散场景。消息的存储库和同步库都可以使用TableStore来存储，同时还有TTL功能可以用来节省成本。

另一类的消息Meta，包括关注列表、点赞、用户信息等，这些都是Meta类数据，对多种查询需求，尤其多字段组合，模糊查询，统计等强需求，这一类就可以用TableStore的多元索引。一个云产品就能满足你在IM/Feeds系统中的所有数据存储需求。

目前，行业内已经有不少大中小型公司在使用TableStore存储IM/Feeds系统中的所有数据。

## 3. 爬虫数据 ##

随着数据价值越来越被重视，互联网上的大量垂直行业的数据价值也开始凸显，这一类数据的特点是数据规模较大，数据成本敏感，清洗后的数据价值加到，部分字段需要多字段组合查询，有些需要能支持分词查询。

上述的特点对应到存储系统的要求就是：天然分布式、可靠性高、不能丢数据、成本低、支持多种查询方式。适用于这些特点的存储系统，目前也只有TableStore一款产品，其他系统都会有一些地方捉襟见肘或不合适。

更详细的场景文章介绍，可以参考下面这篇：

1.  《TableStore：爬虫数据存储和查询利器》。

## 4. 日志 ##

日志数据类似于订单数据，数据量大，查询量较少，这一类数据也可以用TableStore存储和查询。

还有很多其他数据也非常适合用TableStore，由于篇幅有限，后面会专门写一篇文章介绍TableStore的使用场景以及注意事项，全力赋能用户使用TableStore。

# 展望 #

上面介绍了TableStore的多元索引，以及具备了多元索引能力的TableStore，非常适合存储大规模的结构化、半结构化的数据，尤其是当单机MySQL等关系型系统在容量上容纳不下的时候。

未来，我们会继续优化TableStore的索引能力：

*  提供全局二级索引，继续加强少量固定列范围查询时的性能。
 *  继续优化多元索引的成本，未来有望将成本降低到当前一半，甚至更低，为大规模数据存储提供一个理想的存储平台。
 *  提供备份、容灾等系统功能，再将系统的可靠性和可用性提高几个数量级。

我们的目标是：打造结构化、半结构化数据的在线数据平台，未来会一直持续朝这个目标迈进，为阿里云客户提供理想的在线数据存储系统。

产品页面：[https://www.aliyun.com/product/ots][https_www.aliyun.com_product_ots]

产品文档：[https://help.aliyun.com/document\_detail/91974.html][https_help.aliyun.com_document_detail_91974.html]

[1550719237600-4f160dc6-dafd-426e-82b3-8b]: /images/20220214/7a8bb69300d64d3c96030930a33e2ecb.png
[TableStore]: https://yq.aliyun.com/articles/642913?spm=a2c4e.11153959.0.0.65c047a2cGKduK
[TableStore 1]: https://yq.aliyun.com/articles/656196?spm=a2c4e.11153959.0.0.65c047a2cGKduK
[https_www.aliyun.com_product_ots]: https://www.aliyun.com/product/ots
[https_help.aliyun.com_document_detail_91974.html]: https://help.aliyun.com/document_detail/91974.html