简介：背景自从五十年前关系型数据模型被发明出来后，凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角，迅速占领市场，成为各行各业的主流数据存储系统。在这五十年内，数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展，但是索引结构的发展相对缓慢了一些，更多的发展是基于现有的索引基础去优化查询优化器。发展了三十年后进入互联网和移动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据
背景
自从五十年前关系型数据模型被发明出来后，凭借优秀的表达能力和清晰易懂的特性让其很快在数据库市场中崭露头角，迅速占领市场，成为各行各业的主流数据存储系统。在这五十年内，数据库架构、表达方式、存储结构、优化器等方面都有了长足的发展，但是索引结构的发展相对缓慢了一些，更多的发展是基于现有的索引基础去优化查询优化器。
发展了三十年后进入互联网和移动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据库（NoSQL），NoSQL 的出现补充了原有数据库在规模上的不足，但是这些 NoSQL 的索引结构原理仍然同传统关系数据库类似，都是基于原有表结构构建二级索引。
无论是关系型数据库的二级索引还是 NoSQL 数据库的二级索引基本都是基于原有表结构的主键列重排，这样都会在索引能力上存在短板：一是最左匹配原则的限制了索引功能，二是需要提前确定好查询列，并且将要查询列组合后构建多个二级索引，如果在查询时出现了无法匹配索引的情况则性能会大幅下降，于是就出现了深恶痛绝的慢查询，慢查询会严重影响用户体验和数据库本身的稳定性。
为了解决上述问题，有一种架构是引入搜索引擎，比如 Elasticsearch 、Solr（衰退期） 或其他云搜索系统等，使用搜索引擎的倒排索引来支持读时索引：任意列的自由组合查询，还能支持地理位置查询、全文检索。由于搜索引擎是专门为查询优化的系统，查询性能会更加稳定一些。但是这种做法也存在一些问题，甚至有些问题很多人都没有意识到：
- 数据的可靠性：对于数据库而言，保证数据不丢是最核心的要求，但是对于搜索引擎则不是，大部分搜索引擎都存在丢数据的问题。
- 查询结果的完整度：搜索引擎的核心目标是查询性能，所以会优先保证查询性能，而非数据完整度，所以部分搜索引擎存在为了保证延时而提前中止查询请求的情况。
- 功能的稳定性隐患：大部分开源产品或者商业产品，为了吸引客户所以最热衷的是不停出新功能，部分功能在小数据量级上没问题，但是数据量增多后，可能会有很严重的稳定性隐患，比如打爆内存，打爆CPU或者让整个集群卡死等等问题，最关键的是如果不是非常专业的专家，很难提前预估到这些隐患，最终都是在一次次的故障中慢慢摸索了解，更棘手的是永远都不知道还有多少坑未踩过。
- 运维的复杂度：搜索领域是一个专业性很强的领域，虽然部分产品的易用性很好，但是对于运维人员的专业性要求很高，很多人摸索了几年还仅仅是入门，当遇到问题时仍然无法快速定位并且解决，甚至都不知道哪个环节出了问题（根本看不到更细粒度的监控指标也就无法知道到底哪个环节出了问题），而且也很难在业务上线前提前发现风险，最终的结果可能是两败俱伤：运维人员很累，业务的问题仍然很多。
- 架构的复杂度：为了让数据从数据库同步到搜索引擎，需要引入一个同步系统，这样至少需要管理三个系统，而且需要管理同步的状态和时效性，这个复杂度和费用都会增加不少。另一种方案是双写数据库和搜索引擎，但是这个里面要处理比较复杂的一致性问题。同时，研发需要读写两个不同的系统。
上面这种架构已经意识到了传统数据库的不足，并且找到了一种解决办法，只是解决办法仍然有很大不足。
这里为什么不更进一步，将搜索引擎的能力引入数据库系统中？如果这个可以，那么上述的问题就会迎刃而解，烟消云散。
基于上述的思路，阿里云历经十年自研的非关系型（NoSQL）结构化数据表存储服务 Tablestore 在三年前成功引入了搜索引擎的核心能力：倒排索引、BKD 索引 等，将搜索引擎的能力完全植入了 NoSQL 数据库中。
这个能力在表格存储（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。
对于重要客户我们会免费提供专家服务群，在群里面会有表格存储各个模块的核心研发专家，会第一时间解决技术或者稳定性上的问题，为客户提供一个绝佳的使用体验。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。