随着互联网发展的深入,互联网开始下沉到各行各业进行互联网改造,比如进入网约车、出租车行业的滴滴,将出租车行业互联网化,改造之前,出租车的分布、订单轨迹、人流热度等交通数据都是直接废弃导致无法利用起来。改造之后,整个城市的出租车的实时分布、订单运行轨迹、人流热度等等这些都能实时观测到的,可以用于交警、行人、出租车提前规划更合理的路线,加快了整个城市的运行效率。在这个互联网改造过程中,最核心的就是出租车的运行和运营数据,比如实时轨迹、订单信息、地理热力图等,这些数据就是一些结构化或半结构化的数据,需要为这些数据寻找一种合适的存储系统。考虑到这些数据的存量和增量非常大,都是以亿为单位,如果要存这些海量的半结构化的数据,最合适的莫过于分布式的结构化或半结构化存储系统。
这种互联网改造的过程不仅仅发生在交通行业,也发生在很多其他传统行业,其他传统行业的这类数据存储需求也是一样的。
目前业界可用的分布式结构化、半结构化存储系统,有开源的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秒),比如如下图:
在控制台上,不仅可以创建多元索引,查询多元索引Schema等外,还支持比较简单的查询功能,比如单字段查询、范围查询、分词匹配查询、前缀查询、多字段组合查询和排序等,其他的较复杂的嵌套查询,地理范围查询等可以通过SDK实现。
TableStore是一个Serverless的服务化产品,用户无需关心“运维”,只需要关注“开发”,提供类Restfull API和SDK,怀着“将复杂留给自己,将简单留给客户”的初心,让用户在使用上尽量简单,同时也不用考虑存储容量、机器水位等多种繁杂的问题。同样的,多元索引也是基于这一目标,用户只需要创建索引,就可以直接通过阿里云官网控制台体验查询,通过SDK的Search接口实现各种查询需求。
如果想对多元索引有更深入的了解,可以阅读下列文章:
- 《如何用表格存储翻页》。
- 《TableStore符合类型:Array和Nested介绍》。
- 《TableStore多元索引路由介绍》。
场景
TableStore是一款阿里云为结构化、半结构化数据自研的大规模存储系统,适用场景众多,尤其是大规模数据的存储和查询,下面会简单列举几种常见的场景或需求。
1. 订单系统
订单系统是各类应用或系统中最常见的一种系统,常见的有:
- 电商网站的历史订单
- 商场、零售店、超市和酒店等的历史订单
- 网约车、出租车的历史订单
- 财务系统中的历史记录
任何一家企业都会至少有一个类似订单系统的系统存在,这一类系统的特点是,数据持续产出,每条数据的属性很多,一般都在10个以上,甚至有些复杂系统可能有上百个,这种数据需要存储时间长,因为有些时候需要通过这些数据调查历史问题。
针对这类系统,最难得地方是查询复杂,所有属性列都需要支持查询,且查询条件不固定,同时数据量又大,一般的解决方法是以下两种其一或者结合:
- 最近1个月的数据存储在MySQL等单机关系型数据库,如果用心观察,很多产品的订单只能查询最近1个月或3个月的,再长就不支持了,原因就是单机容量的限制。同时,由于MySQL只有二级索引,只能查询固定列的组合,如果属性多了后就会不太适合了。
- 存储在HBase等系统,但是只支持按顺序查询,比如滴滴的历史订单,不支持按任意属性查询。
不管采用哪种方案,都是牺牲产品的用户体验为代价的。
更详细的场景文章介绍,可以参考下面两篇:
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一款产品,其他系统都会有一些地方捉襟见肘或不合适。
更详细的场景文章介绍,可以参考下面这篇:
- 《TableStore:爬虫数据存储和查询利器》。
4. 日志
日志数据类似于订单数据,数据量大,查询量较少,这一类数据也可以用TableStore存储和查询。
还有很多其他数据也非常适合用TableStore,由于篇幅有限,后面会专门写一篇文章介绍TableStore的使用场景以及注意事项,全力赋能用户使用TableStore。
展望
上面介绍了TableStore的多元索引,以及具备了多元索引能力的TableStore,非常适合存储大规模的结构化、半结构化的数据,尤其是当单机MySQL等关系型系统在容量上容纳不下的时候。
未来,我们会继续优化TableStore的索引能力:
- 提供全局二级索引,继续加强少量固定列范围查询时的性能。
- 继续优化多元索引的成本,未来有望将成本降低到当前一半,甚至更低,为大规模数据存储提供一个理想的存储平台。
- 提供备份、容灾等系统功能,再将系统的可靠性和可用性提高几个数量级。
我们的目标是:打造结构化、半结构化数据的在线数据平台,未来会一直持续朝这个目标迈进,为阿里云客户提供理想的在线数据存储系统。
产品页面:https://www.aliyun.com/product/ots
产品文档:https://help.aliyun.com/document_detail/91974.html