简介:背景自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,但是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增长,随即产生了非关系型数据
自从五十年前关系型数据模型被发明出来后,凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角,迅速占领市场,成为各行各业的主流数据存储系统。在这五十年内,数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展,但是索引结构的发展相对缓慢了一些,更多的发展是基于现有的索引基础去优化查询优化器。
发展了三十年后进入互联网和移动互联网时代,数据规模呈爆发式增长,随即产生了非关系型数据库(NoSQL),NoSQL?的出现补充了原有数据库在规模上的不足,但是这些?NoSQL?的索引结构原理仍然同传统关系数据库类似,都是基于原有表结构构建二级索引。
无论是关系型数据库的二级索引还是?NoSQL?数据库的二级索引基本都是基于原有表结构的主键列重排,这样都会在索引能力上存在短板:一是最左匹配原则的限制了索引功能,二是需要提前确定好查询列,并且将要查询列组合后构建多个二级索引,如果在查询时出现了无法匹配索引的情况则性能会大幅下降,于是就出现了深恶痛绝的慢查询,慢查询会严重影响用户体验和数据库本身的稳定性。
为了解决上述问题,有一种架构是引入搜索引擎,比如?Elasticsearch?、Solr(衰退期)?或其他云搜索系统等,使用搜索引擎的倒排索引来支持读时索引:任意列的自由组合查询,还能支持地理位置查询、全文检索。由于搜索引擎是专门为查询优化的系统,查询性能会更加稳定一些。但是这种做法也存在一些问题,甚至有些问题很多人都没有意识到:
上面这种架构已经意识到了传统数据库的不足,并且找到了一种解决办法,只是解决办法仍然有很大不足。
这里为什么不更进一步,将搜索引擎的能力引入数据库系统中?如果这个可以,那么上述的问题就会迎刃而解,烟消云散。
基于上述的思路,阿里云历经十年自研的非关系型(NoSQL)结构化数据表存储服务 Tablestore?在三年前成功引入了搜索引擎的核心能力:倒排索引、BKD?索引?等,将搜索引擎的能力完全植入了?NoSQL?数据库中。
这个能力在表格存储(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。
对于重要客户我们会免费提供专家服务群,在群里面会有表格存储各个模块的核心研发专家,会第一时间解决技术或者稳定性上的问题,为客户提供一个绝佳的使用体验。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
前言 Canvas绘制多变形非常简单,只要懂得Canvas路径 + 简单的初中数学知识即可...
1、纯工具操作步骤,懂代码更容易 划线就是不符合国人的审美观念,看着就别扭,...
简介: 6月4日,以“开启分布式云新时代”为主题2021云边协同大会在北京举行,本...
1.先瞧瞧效果: 2.代码是这样的: img src=images/circle.png alt= id=circle/@m...
在默认情况之下,如果在Canvas之中将某个物体(源)绘制在另一个物体(目标)之...
作者:Joe Seifi 译者:前端小智 移动: https://mp.weixin.qq.com/s/p5... 有梦...
折叠式卡片布局在PC版网站中可能不常见,但是在手机版,小屏幕的网页浏览会大发...
本文没有咬文嚼字的地方,只是一个配色技巧的分享,十分简单,简单到流泪,但或...
一、虽然有的属性是boolean类型,但仍旧建议按照XHTML书写(属性名=属性值)格式...
背景 在公司参与一个原生APP和h5混合开发的项目,本人在项目中负责h5部分,现将...