如何在千亿行规模的表中快速检索数据

简介:背景自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,可是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增加,随即产生了非关系型数据

背景

自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,可是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。html

发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增加,随即产生了非关系型数据库(NoSQL),NoSQL 的出现补充了原有数据库在规模上的不足,可是这些 NoSQL 的索引结构原理仍然同传统关系数据库相似,都是基于原有表结构构建二级索引。算法

不管是关系型数据库的二级索引仍是 NoSQL 数据库的二级索引基本都是基于原有表结构的主键列重排,这样都会在索引能力上存在短板:一是最左匹配原则的限制了索引功能,二是须要提早肯定好查询列,而且将要查询列组合后构建多个二级索引,若是在查询时出现了没法匹配索引的状况则性能会大幅降低,因而就出现了深恶痛绝的慢查询,慢查询会严重影响用户体验和数据库自己的稳定性。数据库

为了解决上述问题,有一种架构是引入搜索引擎,好比 Elasticsearch 、Solr(衰退期) 或其余云搜索系统等,使用搜索引擎的倒排索引来支持读时索引:任意列的自由组合查询,还能支持地理位置查询、全文检索。因为搜索引擎是专门为查询优化的系统,查询性能会更加稳定一些。可是这种作法也存在一些问题,甚至有些问题不少人都没有意识到:数组

  • 数据的可靠性:对于数据库而言,保证数据不丢是最核心的要求,可是对于搜索引擎则不是,大部分搜索引擎都存在丢数据的问题。
  • 查询结果的完整度:搜索引擎的核心目标是查询性能,因此会优先保证查询性能,而非数据完整度,因此部分搜索引擎存在为了保证延时而提早停止查询请求的状况。
  • 功能的稳定性隐患:大部分开源产品或者商业产品,为了吸引客户因此最热衷的是不停出新功能,部分功能在小数据量级上没问题,可是数据量增多后,可能会有很严重的稳定性隐患,好比打爆内存,打爆CPU或者让整个集群卡死等等问题,最关键的是若是不是很是专业的专家,很难提早预估到这些隐患,最终都是在一次次的故障中慢慢摸索了解,更棘手的是永远都不知道还有多少坑未踩过。
  • 运维的复杂度:搜索领域是一个专业性很强的领域,虽然部分产品的易用性很好,可是对于运维人员的专业性要求很高,不少人摸索了几年还仅仅是入门,当遇到问题时仍然没法快速定位而且解决,甚至都不知道哪一个环节出了问题(根本看不到更细粒度的监控指标也就没法知道到底哪一个环节出了问题),并且也很难在业务上线前提早发现风险,最终的结果多是两败俱伤:运维人员很累,业务的问题仍然不少。
  • 架构的复杂度:为了让数据从数据库同步到搜索引擎,须要引入一个同步系统,这样至少须要管理三个系统,并且须要管理同步的状态和时效性,这个复杂度和费用都会增长很多。另外一种方案是双写数据库和搜索引擎,可是这个里面要处理比较复杂的一致性问题。同时,研发须要读写两个不一样的系统。

上面这种架构已经意识到了传统数据库的不足,而且找到了一种解决办法,只是解决办法仍然有很大不足。架构

这里为何不更进一步,将搜索引擎的能力引入数据库系统中?若是这个能够,那么上述的问题就会迎刃而解,烟消云散。并发

基于上述的思路,阿里云历经十年自研的非关系型(NoSQL)结构化数据表存储服务 Tablestore 在三年前成功引入了搜索引擎的核心能力:倒排索引、BKD 索引 等,将搜索引擎的能力彻底植入了 NoSQL 数据库中。less

这个能力在表格存储(Tablestore)中称为:多元索引(SearchIndex)。运维

至此,表格存储具有了两大能力:宽表和多元索引,其中宽表引擎相似于 Bigtable,主要面向的是数据的高可靠存储,解决的是数据规模和扩展问题,而多元索引解决的是数据的查询检索的效率和灵活问题。分布式

当前表格存储的完整架构和能力大图以下:高并发

价值

Tablestore 的多元索引相对于传统方案,除了弥补了上述说的数据库加搜索引擎方案中的全部缺点外,还在其余一些方面存在巨大的优点:

  • 一个系统,多种能力支持:既能提供数据库级别的数据可靠性,又能提供搜索引擎具有的丰富查询能力。
  • 应用层架构更简单:数据存储和查询只须要一个系统便可,运维、研发甚至是财务的工做都会更加简单。
  • 查询能力丰富:支持很是丰富的查询功能、排序和统计聚合等。能够知足绝大部分的在线查询和轻量级分析场景的需求。
  • 性能更好:无论是存储仍是查询性能,都要比业界开源产品更优,好比 Count 性能比业界最好的 Elasticsearch 还要快 10 倍以上。
  • 和 DLA 结合提供复杂分析能力:阿里云数据湖分析产品 DLA 目前能够将大部分 SQL 的算子下推到多元索引中,能够大幅提高 DLA 中分析 SQL 的性能,当前 Tablestore 是 DLA 惟一能够下推 limit、agg、sort 等算子的数据系统,结合 DLA 就能够提供更加复杂的分析能力。
  • ALL IN ONE 的价值:一份数据同时支持了在线写入查询、离线导入导出、轻量级分析和基于 DLA 的完整 SQL 分析能力。这些能力在 Tablestore 中会作多重相应隔离,避免相互影响。因为是一个系统,客户研发、运维和财务管理上都会更加简单。
  • 研发效率提高:除了上面这些比较明显的优点外,还有一个很大的优点是能够大幅提升研发效率:再也不须要额外部署系统,再也不须要学习多种不一样系统的接口和行为,不在须要关注同步链路的延迟,不在须要考虑运维等等。从客户的反馈来看,使用多元索引后,一个基础功能的研发周期能够从一个月减小到一周时间,大幅提升产品上线的速度。

功能和能力

表格存储是阿里云重金打造的分布式 NoSQL 产品,核心目标是打造一款海量数据平台,能够支持在线、离线和轻量级分析。但愿能基于 ALL IN ONE 的设计理念实现客户在大规模结构化数据存储和查询方面的一站式需求。

多元索引在表格存储产品中的核心定位是数据价值发现,提供了查询和分析的能力:

查询能力

当前多元索引在查询方面的能力比较丰富,没有传统数据库和各类其余 NoSQL 的最左匹配原则限制,只要建了索引的列就能任意列组合查询,使用体验上大幅提高。

同时也支持了数组类型(Array)和相似 Json 的嵌套类型,能够更容易适配各类应用层的模型,研发效率会更高一些。

除此以外,还有一个传统数据库不具有的能力,那就是丰富的分词能力和全文检索功能,全文检索功能支持按照相关性分数排序,或者按照任意列排序结果,其中相关性算法使用了 BM25 算法。

在当前移动互联网、物联网和车联网快速发展的时期,很多应用或者业务中都须要地理位置查询,好比查询周围的人或者电子围栏的需求,这个时候就须要使用地理位置查询的功能,这个功能在多元索引中也有提供,在写入时指定列为 GeoPoint类型,而后查询的时候就可使用丰富的地理位置查询,并且地理位置查询能够和其余索引列一块儿查询或过滤,好比和时间结合。

多元索引的查询能力基本具有了目前现存的最完整的查询功能,因为是自研系统,若是有新的业务场景或者新的查询需求,咱们的快速研发能力也能够尽快让新功能推出。

实时分析能力

多元索引也为在线场景提供了轻量级的实时分析的能力,主要适用在查询延迟要求毫秒到秒级别的场景中。

  • 支持基础统计聚合:Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等。
  • 支持高级统计聚合:直方图统计、百分位统计等。

咱们的部分轻量级分析功能性能相对于开源系统有 10 倍以上的性能提高。

更重要的是这些轻量级分析相关的请求在内部执行的时候会和其余在线请求隔离开,不会影响在线请求的可用性。

若是某些场景须要查询总数或者分组等等,则能够直接使用多元索引,不用再引入其余系统。

SQL 分析能力

有些场景中须要 SQL 分析能力,可是不太在乎时间,分钟级别返回也能够接受,这个时候可使用多元索引 + 阿里云数据湖分析 DLA 实现完整分析能力。DLA 是一个 Severless 的分析系统,支持标准的 SQL 能力,能够将算子下推到底层的存储系统或者数据库的。当前表格存储的多元索引实现了 DLA SQL 中大部分算子,也是 Limit 、Sort、Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等算子惟一能够下推到存储层的数据存储系统。

多元索引和 DLA 结合的分析功能适用于秒级到分组级延迟的复杂分析请求。而多元索引自身的轻量级分析能力适用于毫秒到秒级延迟的简答分析场景。

更详细的 DLA 和多元索引的使用能够参考这篇文章《Tablestore计算下推》。

高并发导出能力

在一些场景中,客户须要将知足条件的数据快速的导出到外部系统,作一些其余操做,好比设备数据导出后可能须要为这些设备发送通知,待分析数据导出到外部的计算系统后作更负责的分析处理和报表生成等。若是在导出前,在存储系统中就能过滤掉无用数据,快速筛选出最终的数据集合,那么性能和成本都会更加有优点。

为了知足这类场景的需求,咱们研发了并发导出功能:ParallelScan。该接口具有下列三个基础能力:

  • 支持完整的查询功能:包括 Search 接口支持的全部 Query 功能。能够将无用的数据提早在存储层过滤掉,减小要传输的数据量和成本,提供性能。
  • 高吞吐:线上最高能够支持 1000万行/秒的筛选导出。
  • 断点续传:若是在读取过程当中出现错误,此时能够支持从出错的位置从新读取,具有断点续传能力。

上述特征也让 ParallelScan 在下列场景中能够发挥出最大的优点:

  • 设备中心: 有时候应用须要挑选出知足某些条件的设备或者App,为他们推送一些通知或者升级信息,这个时候系统须要支持任意条件的自由组合,也要支持快速的从数据库中拉取出大量设备。
  • 计算系统:好比 Spark、Presto、DLA 等计算系统若是出现复杂的 SQL 查询,可使用 ParallelScan 下推部分算子,将算子过滤后的剩余结果快速的拉取到计算系统内存中作二次计算,大幅下降成本和提高性能。

动态修改 Schema 和 A/B Test

除了功能外,咱们在易用性方面也在不断投入,但愿能够大幅简化客户的使用体验和提高研发、运维效率等。客户使用了多元索引后,因为多元索引是强 Schema 的产品,若是后续业务须要变动字段,好比新增、删除、修改类型、修改列名等场景时,须要先新建一个索引,等索引数据都追上后,验证没问题,而后再线上作变动,将线上使用的索引换到新索引上,这个过程虽然能够解决问题,可是存在两个致命的问题:

  • 容易引起故障:可能切换的时候切换错了索引,也有可能新索引有问题,这些均可以致使线上服务出现问题,引起故障,产生损失。
  • 效率极低:这个过程所有要靠人力去作,持续时间长,并且由于是线上变动,每一步都要认认真真,稍一不注意可能会搞错,须要重来。

基本上每个强 Schema 的系统都会面临这样的问题,这个问题虽然看起来是一个小问题,可是对于用户而言则是一个很痛很痛的点,每一个用户每月痛一次,若是有几千个客户,那么每月花费在这件事情上的时间和精力就会很是恐怖。为了真正的让客户用起来舒服,简化使用,解客户之痛,提高使用者的幸福度,咱们推出了动态修改 Schema功能。

当前咱们的动态修改 Schema 功能具有下列三大功能:

  • 支持新增列、删除列、修改列类型、修改类名字、修改路由键等功能。
  • 支持新旧索引的 A/B Test。能够将原索引的流量切部分到新索引上,用于验证新索引的可用性和延迟状况。
  • 新索引切换时智能提醒能力,避免客户提早切换致使的数据回退问题。

上述功能目前已经上线,开始邀测中,短短一个月时间内,已经有几十个客户在使用,大幅简化了客户的使用和下降了风险,好评不断。预计六月份会彻底对外开放。接下来咱们会有一篇专门文章介绍动态修改 schema 的能力和使用。

场景

增长了多元索引后,表格存储在一些场景中的适配度变得很是高。

订单

对于小数据量的订单,好比小于 2000 万行的能够直接用 MySQL,若是更大量的数据量,甚至几十亿、几百亿行的订单数据使用表格存储的多元索引会更好。

某互联网公司当前拥有上百亿条历史订单数据,将来随着业务增加订单量预计每一年会翻倍,当前架构是基于 MySQL 的分库分表来实现的,可是存在一些痛点:1)分库分表愈来愈复杂,带来的运维压力也愈来愈大;2)慢请求愈来愈多,用户的投诉不间断。3)大客户的查询常常超时。为了解决这些痛点,客户将最新一天的订单存储在 MySQL,将全量订单数据经过 DTS 实时同步到表格存储,查询使用多元索引功能,带来了超出预期的好处:一是再也不须要考虑将来的扩容问题;二是再也不须要运维,主须要关注业务研发便可,效率大幅提高;三是查询性能最大提高了55倍;四是完全消除了慢请求,用户的投诉也再也不有了;五是能够直接结合 DLA 或者 MaxCompute 作更复杂的分析。

更详细的订单场景介绍:《大规模订单系统解读-架构篇》。

设备元数据

表格存储的多元索引在去年新推出了并发导出功能,结合以前的特性,使表格存储在设备元数据管理方面具有了很大的竞争力。

某公司拥有几百亿设备 APP 信息,这些设备信息会实时更新,每秒更新最大会达到 50万行/s,当有活动或者突发事件时,须要快速圈选出目标APP进行消息推送,圈选的时候须要 具有 1 分钟内从几百亿设备中圈选出 2 亿台设备的能力。当前架构中多套系统组合使用,存在一些痛点:1)系统众多,包括了多套存储和查询系统、大数据计算系统等,管理复杂,成本高昂。2)时效性查,大规模圈选都是小时级别,知足不了日益增加的运营需求。3)随着业务增加更新量愈来愈大,原有系统瓶颈愈来愈大。客户通过半年调研后,将整个系统搬迁到了表格存储,利用多元索引的查询和导出能力作实时查询和在线圈选,带来了超出预期的效果:1)系统数量减小到一个系统,研发和运维复杂度大幅下降,稳定性更高;2)圈选时效性从小时级别下降到分钟级别。3)更新速率能够线性扩展,不在成为瓶颈。

消息

消息类型存储(IM、Feed流、通知等)是表格存储上客户量最多的的场景之一,表格存储的高可靠存储、实时扩展能力、自增列功能能够大幅简化存储库、同步库架构以及多元索引提供全方位查询能力让消息数据能够一站式解决存储、同步和搜索的全部需求。

基于上述优点,阿里巴巴集团内部的大部分 IM 系统的存储、同步和搜索系统都基于表格存储,好比内部的钉钉,外部的众多互联网和物联网客户等。

下图是一个经典的消息架构图:

最后

多元索引当前支持阿里云官网控制台或者SDK建立,若是是首次使用,能够参考多元索引快手入门文章,即将发布。

咱们有一个钉钉公开交流群,你们能够加入保持一个更好的沟通交流,钉钉群号:23307953。

对于重要客户咱们会免费提供专家服务群,在群里面会有表格存储各个模块的核心研发专家,会第一时间解决技术或者稳定性上的问题,为客户提供一个绝佳的使用体验。

本文内容由阿里云实名注册用户自发贡献,版权归原做者全部,阿里云开发者社区不拥有其著做权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将马上删除涉嫌侵权内容。
相关文章
相关标签/搜索