什么是NoSQL
“NoSQL”一词最早出现在1998年，距今刚好二十年。站在今天回头看的话，很少有人能想到在关系型数据库成熟发展了三十年，已经在数据存储领域占据了不可动摇的的地位后，NoSQL数据库尽然还可以快速地异军突起，并且以多点开花、多路并进的方式高速发展。“NoSQL”最早的意思是“non-relational”，后来又升级为了“Not Only SQL”，不管如何定义，“NoSQL”都代表了一种不同于关系型数据库的全新的思维方式。虽然在最近几年也出现了一些新颖的单机数据存储系统，也被划归为NoSQL，但在本文中，“NoSQL”仅指传统的分布式NoSQL数据库。
NoSQL最近二十年，尤其是最近十年可以说异军突起，主要得益于互联网的高速发展，对数据库有了更多更高的要求：
- 高达TB，PB级的海量数据存储需求：不管是二十年前起步的搜索，十年前起步的社交，还是今天开始发展的物联网，都需要存储、处理海量的数据，而且场景越来越多，规模越来越大、
- 低延迟的读写速度：无论是随着互联网的发展，还是移动时代的到来，越来越多的应用需要直接面对用户的访问，延迟直接影响了用户的体验感受，同时随着网民数量的激增和技术的深入，需要处理的数据极速增大，存储系统的延迟直接影响了整个数据处理的耗时，低延迟会使数据处理更快，用户更早看到结果，体验更好，在同产品竞争中优势会更大，这些都要求存储系统能有更低的读写延迟。
- 低成本的需求：数据量增大了，速度也提高了，成本应该会更高，但是高昂的技术成本支出如果没法在产品营收中同比例的赚回，那么这项技术是没价值的。基于此，更低的成本成了技术发展、普及的核心要求。
上述三个需求，在传统数据库中很难实现，就算是优化改进，只要不改变思维方式，不改变系统架构，很难彻底的满足上述的需求，只是继续一个个的打补丁。基于此现状，“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”领域，在海量存储领域，用户真正希望的产品其实是可以存储海量数据、数据可靠、性能稳定、成本低、数据可见，目前能较好满足这五个条件的NoSQL产品是没有的。在小数据量级上用关系型数据库就能满足需求了，但是在大数据集上是空缺的。比如TableStore，满足前4项：存储海量数据，单表可到10PB级；数据可靠，提供11个9的可靠性保障；性能稳定，不管是1GB还是1PB的存储都不影响读写性能，目前有线上业务单表写入速度达到3500万行每秒，性能仍然很稳定；成本低，才适合存储海量数据；数据可见，只能通过单Key或者Key前缀范围扫描两种方式，其他的非主键查询、模糊、排序、统计都不支持，用户的数据存储后，很难高效的被使用，数据可见能力比较弱，其他类似分布式NoSQL数据库有同样的问题。
那么问题来了，作为一个分布式NoSQL云产品为什么必须要有很强大的查询能力呢？这个要从两方面来看：
- 首先，从分布式NoSQL软件来看，目前这类软件大多数基于“LSM”架构，写入性能极好，但是查询能力弱，结果就是用户只愿意存储价值较低的海量数据，因为数据价值低也只愿意付最低的价格，而对于用户愿意支付更高价格的价值较高的数据没法存储，就算存储进来后，也很难比较容易的被查询到数据，数据价值就不容易发挥出来。用户最终只能权衡后，通过降低要求将头部的少量高价值数据存储在关系型数据库中，其他数据放弃掉，结果是用户想花钱还花不出去。但是如果哪一天，分布式NoSQL数据库支持丰富的查询能力后，这部分用户就可以有地方存储更高价值的数据，且可以存储更多数据，也就能对用户业务产生更大的价值。
- 其次，云计算时代的云产品和开源软件不一样。当某个开源软件比较成熟和稳定，或者功能不能满足新需求时，更多的思路是热衷于新开启一个开源项目，在新项目中将新需求更好的实现，这样新项目也更容易积累影响力，但是原有的开源产品就会发展缓慢甚至停滞。简单说就是单功能系统的迭代速度快，生命周期短，带来的后果是用户需要每隔几年更新换代一次系统。而云产品不一样，云产品发布后就会有用户使用，用户使用了，那么就不能轻易的下线，必须不停的基于当前云产品去迭代，将云产品做的更好。云产品的生命周期一般都要比开源软件的生命周期更长。所以，作为一个云产品，我们考虑的是如何满足用户存储海量在线数据时的需求，为了满足这些基本业务需求，查询能力是最基本的要求，否则很难说是一个完整的云产品。
为了解决上述的矛盾或者预期差距，需要提供更高效、易用的数据可见途径，将用户的数据价值发挥出来，实现客户和云产品的双赢。为了实现上述目标，为了满足用户期望，甚至是希望能给用户惊喜感，我们一直以来的思路是提供“一个在线数据平台”：一份可靠高效的数据存储，多种模型的高效访问。我们正在打造的“在线数据平台”具有以下特点：
- 超大规模数据的高可靠存储：单表10PB级以上的存储能力；11个9的数据可靠性保障能力。
- 低成本：在保证性能的前提下，平衡成本，将成本做到最低。产品的目标是海量数据，只有低成本，才能发挥出海量数据的价值，低成本是最核心的诉求。
- 高写入性能：基于LSM架构和用户态的协议栈，写入性能极佳；架构的优化可以使不管是高性能的SSD，还是SATA存储，都能保证一样的写入性能。
- 多种模型的高效访问：通过多种模型的高效访问，可以将海量数据的黑盒状态变成白盒状态，将数据的真面目展现出来，数据的价值才能被用户利用起来，为用户产生价值。
如果将云计算的发展和社会的发展做一个类比的话，那么：
- 原始时代：单产品单功能时代，每个产品提供一个最主要功能，比如存储A提供一个功能，存储B提供一个功能，计算A提供一个功能，计算B提供一功能，用户用的时候就是在上层写应用层，通过双写或多写将多种产品组合起来。
- 工业时代：开始出现管道和辅助产品，开始基于多个单功能产品和一些管道提供完整解决方案，用户只需要一步一步按照步骤就能搭建起来一个系统。
- 智能时代：用户想存储海量数据，需要在线实时访问，那么只用一款产品就够了；如果想计算，那么同样一款产品就够了。用户通过这些“在线大数据存储平台”和“在线计算平台”的统一接口可以实现绝大部分的需求。
我们做的“在线数据平台”就是一个为“智能时代”产品而做的探索，希望对外只展现一套读写API接口，通过这套统一的接口，用户可以实时高效地存储、访问海量数据。
如何实现
在线数据平台”是一个比较庞大的工程，为了完成我们“在线数据平台”的目标，我们从顶往下一层一层分解开来看。
顶层：需求层
需求是实现一站式的易用的、低成本在线海量数据的存储和访问。归纳后的特点就是：低成本、易用性、海量数据、高效写、高效丰富的访问能力。目前在TableStore中已经实现的有：低成本，海量数据、高效写和部分易用性，缺乏的是高效丰富的访问能力和更佳的易用性。
第二层：模型层
为了实现丰富的访问能力和易用性这两个特点，我们将不同场景、访问方式抽象成一个个的“模型”，用户只要将需求匹配到模型上，那么后续的开发复杂度会大幅降低，经过半年多的实践，也证实了我们去年的猜想，效果非常好。这样我们就会有一个模型层，目前已经提供了下列模型：
- Wide Column Model：宽表模型，支持任意多的列，且每一行的列名可以不一样，为存储半结构化和结构化数据提供极大的方便。同时在数据操作层面，提供两类数据访问API：Data API和Stream API，通过Stream API可以将增量数据的能力发挥出来。在宽表模型上，我们提供了两套访问接口，一套是HBase Client，如果用户之前使用HBase Client，想要切换到TableStore，不需要修改代码，只需要增加对TableStore Hbase Client的依赖，以及增加阿里云AccessKey的配置项后即可一键切换。另一套是原有的OTS接口，易用性和性能更佳。不同于现有的其他的宽表系统，我们的宽表系统里面会提供非主键列查询、模糊查询和多字段查询等更丰富的查询能力支持。
- Timeline Model：这是我们年初推出的一个新模型，抽象了无限Topic队列的场景，基于表格存储独有的主键列自增功能可以保证消息不乱序、不丢失。适用于IM、Feed流和其他消息下推等场景。零基础的用户基于此模型，可以在1到2周时间内快速上线自己的IM或Feed流系统。在阿里巴巴集团内部以及阿里云公有云用户中已经被广泛使用和好评，不仅将IM，Feed流和物联网的控制命令下发等系统的开发周期大大的缩短，更关键的是将该类系统的可靠性、稳定性，性能、准确性（消息的可达性）大幅的提高。该模型的架构在业界处于领先地位，业界同类型的著名IM们还在使用我们已经淘汰的落后技术架构。同时Timeline模型中也提供元数据和消息内容的检索能力。
除了上述两个已经发布，并且被广泛使用的模型外，今年我们会继续扩展多模型的边界：
- Graph Model：提供图数据库的读写模式，图数据是一种比较经典的数据模型，在很多场景中都有广泛使用。图的查询也是一种更加自然、友好的方式。
- Time Series Model：时序模型，我们会提供一种不同于现有产品的新时序模型，在功能和扩展性上会有很大的提高。
第三层：引擎层
在上面的模型中，目前已经支持了Wide Column和Timeline模型，但是这两种模型都只是部分支持，比如Wide Column模型中目前还不支持非主键列查询、多列组合查询、模糊查询、排序、时空、统计聚合等功能。Timeline模型中目前还不支持元信息查询和消息内容查询。Graph模型和TimeSeries模型中也都需要多字段的检索能力，否则性能和功能上都会有重大缺陷。为了弥补这个缺陷，我们还需要一个查询引擎，有了这个查询引擎后上述的非主键列查询、多列组合查询、模糊查询、排序、时空、统计聚合等功能就能比较容易的实现了，这样才能实现一个个完整的模型，才能打造出一个满意的“在线数据平台”。
为什么做多元索引（SearchIndex）
在上一节的“引擎层”部分，我们得出结论，除了存储引擎外，我们还需要一个查询引擎，这个查询引擎需要提供下列功能：
- 极强的索引能力：需要支持多字段组合查询，模糊查询，时空等多维查询等，这些需求只能通过倒排索引和其他类似索引解决。
- 轻量级分析能力：需要支持排序、统计、聚合等轻量级分析能力，这些能力在众多场景下都有大量的需求，目前很多产品的这部分能力诉求都没能得到很好地满足。
上述说的查询引擎，就是我们的多元索引（SearchIndex）。
存储引擎和查询引擎的侧重点不同，架构方式也是有多种方式，一种是将存储和查询引擎揉捏在一起，在功能和性能上做一些取舍，往往会有致命性的问题无法解决。另一种是独立引擎，中间通过异步同步的方式传输数据，写请求数据先进入存储引擎，成功后直接返回，然后异步通过队列的方式将数据传输给查询引擎后建立索引。
上述两种架构方式，在目前业界是怎么处理的？业界的发展现状是怎么样的？下一章节，我们一起看一下目前业界的比较领先的解决方案。
业界领先方案
Cloudera Search
Cloudera是一家位于美国的软件公司，向企业客户提供改造后的商业版本的Apache Hadoop体系的软件和服务，该公司为了让分布式NoSQL数据库HBase支持多列组合查询、模糊查询和轻量级分析能力，将开源搜索引擎Solr引入HBase中。最终通过Lily HBase Indexer Service将写入HBase的数据异步同步给Solr，架构如下图：
- 数据同步路径依赖HBase Replication。
- Lily Indexer通过监听HBase Replication的日志异步推送实时获取增量数据，然后写入Solr。
- Lily Indexer的全量rebuild通过HbaseMapReduceIndexerTool进行全量拉取。
- HBase提供持久化和Replication能力。
- 查询直接使用Solr进行查询，Solr提供了更丰富的查询能力。
- 存储引擎是HBase，查询引擎是Solr，中间是使用Replication同步，查询接口独立。
基于HBase和Solr的Lily Indexer开源框架，可以使用户实现数据持久化和丰富查询能力，架构上复用HBase的Replication的监听推送数据能力，相对来说架构对HBase的改动侵入较少。但是有一些方面存在问题，甚至很严重的数据丢失问题：
- 需要依赖HBase开启Replication功能，不能灵活的主动拉取增量，或者局部补数据。
- Lily Indexer开源项目2016年以后活跃度降低，逐渐沉寂，如果没有商业支持，运维成本非常高。
- HBase的日志顺序通过数据上的时间戳决定，在写入Solr前需要重新排序，这种方式在时间回退或者写solr超时时很容易出现新数据被老数据覆盖的情况，很难保证做到数据一致性的，会导致索引数据丢失，结果就是数据存在，但是查询不到。
- 查询直接使用Solr Client，虽然有丰富的查询语义，这意味着如果Solr中没有的字段还需要用户自己反查HBase，易用性大幅降低。同时solr的活跃度、影响力和生命力都在下跌，未来存在项目死亡的潜在风险。
多元索引功能
TableStore作为阿里云首款多模型数据库，基于强大的分布式能力，目标是打造一个__在线数据平台__。在此之前，TableStore已经可以提供大规模数据存储、高效的读写访问和较低的成本，不足的地方是查询能力。现在我们新推出的多元索引能力就是专门解决查询能力不足的问题。接下来，我们看一下多元索引能为大数据平台提供哪些功能。
索引能力
不管是关系型数据库，还是NoSQL数据库，最基础的查询方式都是基于主键去查询，如果需要通过其他属性列去查询，就需要创建二级索引，如果需要多字段自由组合的ad-hoc查询，那么二级索引就会很吃力，另一种支持属性列查询的索引是检索引擎系统使用的倒排索引。为了使阿里云在线数据平台的功能更丰富，我们直接支持了倒排索引以及其他一些索引：
- 倒排索引：是搜索系统中多种查询能力的基础结构，可以极大优化查询功能。基于此，TableStore提供了倒排索引能力，用户为某些属性列建立了倒排索引后，可以基于这些倒排索引实现多字段自由组合的ad-hoc查询，同时也不用担心性别，年龄，枚举等选择性较差的字段的问题了。
- 多维空间索引：是一种用于地理位置等多维空间查询的数据结构，一般都用于时空数据场景，可以极大提高空间查询的性能。TableStore也提供了多维空间索引，目前基于多维空间索引提供了地理位置的查询能力，包括“附近的人”、“矩形、多边形等范围内的点”等常见的地理查询，为大数据筛选、车联网和移动应用提供更丰富的一站式数据查询能力。
排序
排序也是在线数据的一个很常见的强需求，比如选择最多、最大、最小和最新等条件的数据。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有了多元索引能力后，原有的一些场景会变得更加丰富，比如在元数据、消息数据、时序和时空数据等，接下来我们详细看一下多元索引能力在这些场景中发挥价值。
1. 元数据
传统的解决方案中，通常使用MySQL来存储元数据，优点是利用MySQL提供的强大的事务能力来处理元数据的强一致写。但当元数据的规模到一定量级，受限于MySQL的规模上限，会采用MySQL + NoSQL分层的解决方案，将一些不会再更新的历史数据写入NoSQL做一个冷数据保存，比较典型的是淘宝历史交易订单方案。而有些元数据场景，对数据写入没有复杂的事务需求，例如物联网设备状态数据或者是图片元数据等，这类场景会直接使用NoSQL数据库存储数据。
元数据存储后，需要提供丰富的在线查询功能，这点是NoSQL数据库的软肋，也是MySQL的软肋。元数据通常来说以个体为单位，包含多维属性。查询通常是多维属性的一个条件组合查询。MySQL的二级索引很难满足这类查询需求，需要定制大量索引。业界有采用了MySQL+Elasticsearch的方案，通过MySQL的binlog将数据实时增量同步至Elasticsearch，通过Elasticsearch内部的倒排索引实现高效的多维属性检索。
TableStore在推出多元索引之后，同时提供海量数据存储以及高效数据检索，很好的满足元数据场景的需求。
2. 消息数据
Timeline是TableStore今年年初推出的一个新的数据模型，适用于消息数据场景，例如IM/Feeds流的消息系统，或者是物联网的设备下推消息系统。原理是基于底层的分布式KV引擎，模拟了一个类似队列但提供无限轻量级Topic的数据模型，能提供消息数据的保序存储及实时随机定位和范围查询。更丰富的内容可以查看下列文章：《现代IM系统中消息推送和存储架构的实现》，《TableStore Timeline：轻松构建千万级IM和Feed流系统》。
自Timeline推出后，在阿里巴巴集团内部和公有云上都已经得到广泛使用。
在我们的规划中，Timeline基于多元索引会提供更强大的功能。首先是对Timeline元数据的检索，在即时通讯系统中Timeline是一个会话，在物联网消息系统中Timeline是一个设备，不管是会话还是设备，都具备一些元数据且需要能够通过元数据来对Timeline进行检索。其次是对消息数据的检索，提供消息的全文检索或者是多维检索。
3. 时序和时空数据
随着近几年物联网的发展，时序数据迎来了一个不小的爆发。TableStore在存储模型、数据规模以及写入和查询能力上，都能比较好的满足时序数据场景的需求。在《TableStore时序数据存储 - 架构篇》中，我们对时序数据做了一个比较详细的模型定义，以及给了一个基于TableStore的时序数据存储方案。也阐述了开源时序数据库存在的一些问题，例如对时间线元数据的索引，而基于多元索引，我们能提供对于时间线元数据的倒排索引和时空索引。
未来规划
目前TableStore在支持了多元索引后，在功能上补齐了NoSQL系统的部分短板，但是还有一些不足，我们将在接下来几个月继续演进，比如：
- 功能：目前只是提供了最基本的功能，接下来会继续根据业务场景需求增加更丰富的功能，比如统计、聚合能力。
- 易用性：在语法上会继续优化查询部分的难度，进一步降低用户在使用TableStore查询功能时的学习成本和复杂度。
TableStore已经于09月20日开始多元索引邀测，有兴趣的用户可以登陆TableStore控制台，根据指引申请邀测。邀测阶段的多元索引费用免收。
对TableStore有兴趣的用户也可以加入钉钉群：
