TableStore多元索引，大数据查询的利器 -CSDN博客

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

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

目前业界可用的分布式结构化、半结构化存储系统，有开源的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接口实现各种查询需求。

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

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

场景

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

1. 订单系统

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

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

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

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

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

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

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

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

2. IM/Feeds

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

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

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

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