简介:背景自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,可是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增加,随即产生了非关系型数据
自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,可是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。html
发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增加,随即产生了非关系型数据库(NoSQL),NoSQL 的出现补充了原有数据库在规模上的不足,可是这些 NoSQL 的索引结构原理仍然同传统关系数据库相似,都是基于原有表结构构建二级索引。算法
不管是关系型数据库的二级索引仍是 NoSQL 数据库的二级索引基本都是基于原有表结构的主键列重排,这样都会在索引能力上存在短板:一是最左匹配原则的限制了索引功能,二是须要提早肯定好查询列,而且将要查询列组合后构建多个二级索引,若是在查询时出现了没法匹配索引的状况则性能会大幅降低,因而就出现了深恶痛绝的慢查询,慢查询会严重影响用户体验和数据库自己的稳定性。数据库
为了解决上述问题,有一种架构是引入搜索引擎,好比 Elasticsearch 、Solr(衰退期) 或其余云搜索系统等,使用搜索引擎的倒排索引来支持读时索引:任意列的自由组合查询,还能支持地理位置查询、全文检索。因为搜索引擎是专门为查询优化的系统,查询性能会更加稳定一些。可是这种作法也存在一些问题,甚至有些问题不少人都没有意识到:数组
上面这种架构已经意识到了传统数据库的不足,而且找到了一种解决办法,只是解决办法仍然有很大不足。架构
这里为何不更进一步,将搜索引擎的能力引入数据库系统中?若是这个能够,那么上述的问题就会迎刃而解,烟消云散。并发
基于上述的思路,阿里云历经十年自研的非关系型(NoSQL)结构化数据表存储服务 Tablestore 在三年前成功引入了搜索引擎的核心能力:倒排索引、BKD 索引 等,将搜索引擎的能力彻底植入了 NoSQL 数据库中。less
这个能力在表格存储(Tablestore)中称为:多元索引(SearchIndex)。运维
至此,表格存储具有了两大能力:宽表和多元索引,其中宽表引擎相似于 Bigtable,主要面向的是数据的高可靠存储,解决的是数据规模和扩展问题,而多元索引解决的是数据的查询检索的效率和灵活问题。分布式
当前表格存储的完整架构和能力大图以下:高并发
Tablestore 的多元索引相对于传统方案,除了弥补了上述说的数据库加搜索引擎方案中的全部缺点外,还在其余一些方面存在巨大的优点:
表格存储是阿里云重金打造的分布式 NoSQL 产品,核心目标是打造一款海量数据平台,能够支持在线、离线和轻量级分析。但愿能基于 ALL IN ONE 的设计理念实现客户在大规模结构化数据存储和查询方面的一站式需求。
多元索引在表格存储产品中的核心定位是数据价值发现,提供了查询和分析的能力:
当前多元索引在查询方面的能力比较丰富,没有传统数据库和各类其余 NoSQL 的最左匹配原则限制,只要建了索引的列就能任意列组合查询,使用体验上大幅提高。
同时也支持了数组类型(Array)和相似 Json 的嵌套类型,能够更容易适配各类应用层的模型,研发效率会更高一些。
除此以外,还有一个传统数据库不具有的能力,那就是丰富的分词能力和全文检索功能,全文检索功能支持按照相关性分数排序,或者按照任意列排序结果,其中相关性算法使用了 BM25 算法。
在当前移动互联网、物联网和车联网快速发展的时期,很多应用或者业务中都须要地理位置查询,好比查询周围的人或者电子围栏的需求,这个时候就须要使用地理位置查询的功能,这个功能在多元索引中也有提供,在写入时指定列为 GeoPoint类型,而后查询的时候就可使用丰富的地理位置查询,并且地理位置查询能够和其余索引列一块儿查询或过滤,好比和时间结合。
多元索引的查询能力基本具有了目前现存的最完整的查询功能,因为是自研系统,若是有新的业务场景或者新的查询需求,咱们的快速研发能力也能够尽快让新功能推出。
多元索引也为在线场景提供了轻量级的实时分析的能力,主要适用在查询延迟要求毫秒到秒级别的场景中。
咱们的部分轻量级分析功能性能相对于开源系统有 10 倍以上的性能提高。
更重要的是这些轻量级分析相关的请求在内部执行的时候会和其余在线请求隔离开,不会影响在线请求的可用性。
若是某些场景须要查询总数或者分组等等,则能够直接使用多元索引,不用再引入其余系统。
有些场景中须要 SQL 分析能力,可是不太在乎时间,分钟级别返回也能够接受,这个时候可使用多元索引 + 阿里云数据湖分析 DLA 实现完整分析能力。DLA 是一个 Severless 的分析系统,支持标准的 SQL 能力,能够将算子下推到底层的存储系统或者数据库的。当前表格存储的多元索引实现了 DLA SQL 中大部分算子,也是 Limit 、Sort、Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等算子惟一能够下推到存储层的数据存储系统。
多元索引和 DLA 结合的分析功能适用于秒级到分组级延迟的复杂分析请求。而多元索引自身的轻量级分析能力适用于毫秒到秒级延迟的简答分析场景。
更详细的 DLA 和多元索引的使用能够参考这篇文章《Tablestore计算下推》。
在一些场景中,客户须要将知足条件的数据快速的导出到外部系统,作一些其余操做,好比设备数据导出后可能须要为这些设备发送通知,待分析数据导出到外部的计算系统后作更负责的分析处理和报表生成等。若是在导出前,在存储系统中就能过滤掉无用数据,快速筛选出最终的数据集合,那么性能和成本都会更加有优点。
为了知足这类场景的需求,咱们研发了并发导出功能:ParallelScan。该接口具有下列三个基础能力:
上述特征也让 ParallelScan 在下列场景中能够发挥出最大的优点:
除了功能外,咱们在易用性方面也在不断投入,但愿能够大幅简化客户的使用体验和提高研发、运维效率等。客户使用了多元索引后,因为多元索引是强 Schema 的产品,若是后续业务须要变动字段,好比新增、删除、修改类型、修改列名等场景时,须要先新建一个索引,等索引数据都追上后,验证没问题,而后再线上作变动,将线上使用的索引换到新索引上,这个过程虽然能够解决问题,可是存在两个致命的问题:
基本上每个强 Schema 的系统都会面临这样的问题,这个问题虽然看起来是一个小问题,可是对于用户而言则是一个很痛很痛的点,每一个用户每月痛一次,若是有几千个客户,那么每月花费在这件事情上的时间和精力就会很是恐怖。为了真正的让客户用起来舒服,简化使用,解客户之痛,提高使用者的幸福度,咱们推出了动态修改 Schema功能。
当前咱们的动态修改 Schema 功能具有下列三大功能:
上述功能目前已经上线,开始邀测中,短短一个月时间内,已经有几十个客户在使用,大幅简化了客户的使用和下降了风险,好评不断。预计六月份会彻底对外开放。接下来咱们会有一篇专门文章介绍动态修改 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。
对于重要客户咱们会免费提供专家服务群,在群里面会有表格存储各个模块的核心研发专家,会第一时间解决技术或者稳定性上的问题,为客户提供一个绝佳的使用体验。
本文内容由阿里云实名注册用户自发贡献,版权归原做者全部,阿里云开发者社区不拥有其著做权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将马上删除涉嫌侵权内容。