本文共 9427 字,大约阅读时间需要 31 分钟。
“NoSQL”一词最早出现在1998年,距今刚好二十年。站在今天回头看的话,很少有人能想到在关系型数据库成熟发展了三十年,已经在数据存储领域占据了不可动摇的的地位后,NoSQL数据库尽然还可以快速地异军突起,并且以多点开花、多路并进的方式高速发展。“NoSQL”最早的意思是“non-relational”,后来又升级为了“Not Only SQL”,不管如何定义,“NoSQL”都代表了一种不同于关系型数据库的全新的思维方式。虽然在最近几年也出现了一些新颖的单机数据存储系统,也被划归为NoSQL,但在本文中,“NoSQL”仅指传统的分布式NoSQL数据库。
NoSQL最近二十年,尤其是最近十年可以说异军突起,主要得益于互联网的高速发展,对数据库有了更多更高的要求:
上述三个需求,在传统数据库中很难实现,就算是优化改进,只要不改变思维方式,不改变系统架构,很难彻底的满足上述的需求,只是继续一个个的打补丁。基于此现状,“NoSQL”依赖分布式系统架构,在功能上做出一定取舍后,带着互联网时代的使命诞生。
从最早的“Bigtable”,到后来的Dynamodb、HBase、Cassandra、Redis、MongoDB、Janus Graph等,发展出了不同类型,适用于不同场景的多种NoSQL数据库,每一种NoSQL数据库都有各自适合的场景,不管是适应于何种场景,这批相继前后诞生的“NoSQL 兄妹”都在快速成长。从下面最新的DBEngine的趋势图上也能看出一些端倪:
从图中可以明显看到,各种NoSQL系统的影响力基本都是在大幅增长。
在这场“NoSQL”的革命中,阿里云也是放眼未来,在成立之初就投入资源研发,历经9年的打磨和多轮迭代演变成了今天的TableStore,在2014年正式商业化面向公有云提供服务。目前已在阿里巴巴集团、阿里云公有云以及专有云内得到广泛应用,涵盖电商、金融风控、物联网、人工智能、大数据、社交媒体等不同业务领域,不间断的为成千上万的订单、日志、风控、IM、Feeds、无限Topic队列、时序、气象、轨迹溯源等产品存储着海量的数据。为互联网,为国计民生默默的贡献着自己的力量。
“NoSQL”等大数据的软件出来没多久后,很快就到了云计算时代,2012年Aliyun开始在国内售卖云计算产品,经过多年的市场培育,大众也开始逐渐接受和信赖云计算,越来越多的用户把整个系统架构在阿里云产品之上。随着用户越来越多,场景也越来越复杂,用户感受到云计算的价值后,对云计算的要求也变得越来越高,用户日益增长的功能、易用性需求在当前地云产品上不一定能得到满足。
我们回到“NoSQL”领域,在海量存储领域,用户真正希望的产品其实是可以存储海量数据、数据可靠、性能稳定、成本低、数据可见,目前能较好满足这五个条件的NoSQL产品是没有的。在小数据量级上用关系型数据库就能满足需求了,但是在大数据集上是空缺的。比如TableStore,满足前4项:存储海量数据,单表可到10PB级;数据可靠,提供11个9的可靠性保障;性能稳定,不管是1GB还是1PB的存储都不影响读写性能,目前有线上业务单表写入速度达到3500万行每秒,性能仍然很稳定;成本低,才适合存储海量数据;数据可见,只能通过单Key或者Key前缀范围扫描两种方式,其他的非主键查询、模糊、排序、统计都不支持,用户的数据存储后,很难高效的被使用,数据可见能力比较弱,其他类似分布式NoSQL数据库有同样的问题。
那么问题来了,作为一个分布式NoSQL云产品为什么必须要有很强大的查询能力呢?这个要从两方面来看:
为了解决上述的矛盾或者预期差距,需要提供更高效、易用的数据可见途径,将用户的数据价值发挥出来,实现客户和云产品的双赢。为了实现上述目标,为了满足用户期望,甚至是希望能给用户惊喜感,我们一直以来的思路是提供“一个在线数据平台”:一份可靠高效的数据存储,多种模型的高效访问。我们正在打造的“在线数据平台”具有以下特点:
如果将云计算的发展和社会的发展做一个类比的话,那么:
我们做的“在线数据平台”就是一个为“智能时代”产品而做的探索,希望对外只展现一套读写API接口,通过这套统一的接口,用户可以实时高效地存储、访问海量数据。
在线数据平台”是一个比较庞大的工程,为了完成我们“在线数据平台”的目标,我们从顶往下一层一层分解开来看。
需求是实现一站式的易用的、低成本在线海量数据的存储和访问。归纳后的特点就是:低成本、易用性、海量数据、高效写、高效丰富的访问能力。目前在TableStore中已经实现的有:低成本,海量数据、高效写和部分易用性,缺乏的是高效丰富的访问能力和更佳的易用性。
为了实现丰富的访问能力和易用性这两个特点,我们将不同场景、访问方式抽象成一个个的“模型”,用户只要将需求匹配到模型上,那么后续的开发复杂度会大幅降低,经过半年多的实践,也证实了我们去年的猜想,效果非常好。这样我们就会有一个模型层,目前已经提供了下列模型:
除了上述两个已经发布,并且被广泛使用的模型外,今年我们会继续扩展多模型的边界:
在上面的模型中,目前已经支持了Wide Column和Timeline模型,但是这两种模型都只是部分支持,比如Wide Column模型中目前还不支持非主键列查询、多列组合查询、模糊查询、排序、时空、统计聚合等功能。Timeline模型中目前还不支持元信息查询和消息内容查询。Graph模型和TimeSeries模型中也都需要多字段的检索能力,否则性能和功能上都会有重大缺陷。为了弥补这个缺陷,我们还需要一个查询引擎,有了这个查询引擎后上述的非主键列查询、多列组合查询、模糊查询、排序、时空、统计聚合等功能就能比较容易的实现了,这样才能实现一个个完整的模型,才能打造出一个满意的“在线数据平台”。
在上一节的“引擎层”部分,我们得出结论,除了存储引擎外,我们还需要一个查询引擎,这个查询引擎需要提供下列功能:
上述说的查询引擎,就是我们的多元索引(SearchIndex)。
存储引擎和查询引擎的侧重点不同,架构方式也是有多种方式,一种是将存储和查询引擎揉捏在一起,在功能和性能上做一些取舍,往往会有致命性的问题无法解决。另一种是独立引擎,中间通过异步同步的方式传输数据,写请求数据先进入存储引擎,成功后直接返回,然后异步通过队列的方式将数据传输给查询引擎后建立索引。
上述两种架构方式,在目前业界是怎么处理的?业界的发展现状是怎么样的?下一章节,我们一起看一下目前业界的比较领先的解决方案。
Cloudera是一家位于美国的软件公司,向企业客户提供改造后的商业版本的Apache Hadoop体系的软件和服务,该公司为了让分布式NoSQL数据库HBase支持多列组合查询、模糊查询和轻量级分析能力,将开源搜索引擎Solr引入HBase中。最终通过Lily HBase Indexer Service将写入HBase的数据异步同步给Solr,架构如下图:
基于HBase和Solr的Lily Indexer开源框架,可以使用户实现数据持久化和丰富查询能力,架构上复用HBase的Replication的监听推送数据能力,相对来说架构对HBase的改动侵入较少。但是有一些方面存在问题,甚至很严重的数据丢失问题:
TableStore作为阿里云首款多模型数据库,基于强大的分布式能力,目标是打造一个__在线数据平台__。在此之前,TableStore已经可以提供大规模数据存储、高效的读写访问和较低的成本,不足的地方是查询能力。现在我们新推出的多元索引能力就是专门解决查询能力不足的问题。接下来,我们看一下多元索引能为大数据平台提供哪些功能。
不管是关系型数据库,还是NoSQL数据库,最基础的查询方式都是基于主键去查询,如果需要通过其他属性列去查询,就需要创建二级索引,如果需要多字段自由组合的ad-hoc查询,那么二级索引就会很吃力,另一种支持属性列查询的索引是检索引擎系统使用的倒排索引。为了使阿里云在线数据平台的功能更丰富,我们直接支持了倒排索引以及其他一些索引:
排序也是在线数据的一个很常见的强需求,比如选择最多、最大、最小和最新等条件的数据。TableStore同样提供了强大的排序能力,包括正序、逆序;单条件、多条件等排序功能。用户存储在TableStore中的数据就可以拥有全局的多种排序能力。
有了倒排索引后,TableStore也提供了分词能力,基于这些,用户就可以实现全文检索能力,目前只有数据召回能力,不提供相关性能力。
模糊查询时关系型数据库的一个强大功能,基于like语法可以实现很多易用性极高的功能,但是在分布式数据库中的时候,比如HBase,这个能力没法提供。现在TableStore提供了模糊查询能力,只要为该属性列创建倒排索引,该字段就可以被模糊查询。
有了模糊查询能力后,TableStore也提供了前缀查询功能。
在线数据中,除了扁平化的一层结构外,还存在一些更复杂的多层结构场景,比如图片标签:某个系统中存储了大量图片,每个图片都有多个实体,比如有房子,有轿车,有人。在每个图片中,这些实体占的位置,空间大小都不同,所以每个实体的价值(score)也不一样,这样相当于每个图片都有多个标签,每个标签有一个名字和一个权重分。这种数据其实就是一个两层的数据结构:
{ "image_url": "http://img.com/20180901/cn/zj/hz/yq1002.jpg", "image_size": 10240, "created_timestamp": 1537261379 "tags": [ { "name" : "house", "socre": 0.47 }, { "name" : "car", "score": 0.24 } ]}
如果要根据Tags中的条件查询,这时候就需要使用到嵌套查询,嵌套查询功能为复杂数据的建模提供了极大的便利性。
基于以上的查询功能查询到结构后,有可能某个属性的数据非常多,结果多样性比较差,有了去重能力后,可以限制某个属性在一次结果中的最多个数,这样就能提供更好的结果多样性能力。
SearchIndex每次查询时都会返回这次请求命中的数据行数,如果指定一个空查询条件,这个时候所有创建了索引的数据都符合条件,这个时候返回的数据总行数就是表中已创建了索引的数据总行数。如果用户停止写入,且数据都已经创建了索引,则此时返回的数据总行数就是数据表中的总行数。这个功能可以用于数据校验,运营等场景。
说完功能点后,我们再来看一下有了SearchIndex后,现有的场景会发生哪些变化,场景如何变得更丰富。
当NoSQL数据库TableStore有了多元索引能力后,原有的一些场景会变得更加丰富,比如在元数据、消息数据、时序和时空数据等,接下来我们详细看一下多元索引能力在这些场景中发挥价值。
传统的解决方案中,通常使用MySQL来存储元数据,优点是利用MySQL提供的强大的事务能力来处理元数据的强一致写。但当元数据的规模到一定量级,受限于MySQL的规模上限,会采用MySQL + NoSQL分层的解决方案,将一些不会再更新的历史数据写入NoSQL做一个冷数据保存,比较典型的是淘宝历史交易订单方案。而有些元数据场景,对数据写入没有复杂的事务需求,例如物联网设备状态数据或者是图片元数据等,这类场景会直接使用NoSQL数据库存储数据。
元数据存储后,需要提供丰富的在线查询功能,这点是NoSQL数据库的软肋,也是MySQL的软肋。元数据通常来说以个体为单位,包含多维属性。查询通常是多维属性的一个条件组合查询。MySQL的二级索引很难满足这类查询需求,需要定制大量索引。业界有采用了MySQL+Elasticsearch的方案,通过MySQL的binlog将数据实时增量同步至Elasticsearch,通过Elasticsearch内部的倒排索引实现高效的多维属性检索。TableStore在推出多元索引之后,同时提供海量数据存储以及高效数据检索,很好的满足元数据场景的需求。Timeline是TableStore今年年初推出的一个新的数据模型,适用于消息数据场景,例如IM/Feeds流的消息系统,或者是物联网的设备下推消息系统。原理是基于底层的分布式KV引擎,模拟了一个类似队列但提供无限轻量级Topic的数据模型,能提供消息数据的保序存储及实时随机定位和范围查询。更丰富的内容可以查看下列文章:《》,《》。
自Timeline推出后,在阿里巴巴集团内部和公有云上都已经得到广泛使用。在我们的规划中,Timeline基于多元索引会提供更强大的功能。首先是对Timeline元数据的检索,在即时通讯系统中Timeline是一个会话,在物联网消息系统中Timeline是一个设备,不管是会话还是设备,都具备一些元数据且需要能够通过元数据来对Timeline进行检索。其次是对消息数据的检索,提供消息的全文检索或者是多维检索。随着近几年物联网的发展,时序数据迎来了一个不小的爆发。TableStore在存储模型、数据规模以及写入和查询能力上,都能比较好的满足时序数据场景的需求。在《》中,我们对时序数据做了一个比较详细的模型定义,以及给了一个基于TableStore的时序数据存储方案。也阐述了开源时序数据库存在的一些问题,例如对时间线元数据的索引,而基于多元索引,我们能提供对于时间线元数据的倒排索引和时空索引。
目前TableStore在支持了多元索引后,在功能上补齐了NoSQL系统的部分短板,但是还有一些不足,我们将在接下来几个月继续演进,比如:
TableStore已经于09月20日开始多元索引邀测,有兴趣的用户可以登陆TableStore控制台,根据指引申请邀测。邀测阶段的多元索引费用免收。
对TableStore有兴趣的用户也可以加入钉钉群:
转载地址:http://itzjx.baihongyu.com/