共计 6510 个字符，预计需要花费 17 分钟才能阅读完成。
简介： 背景自从五十年前关系型数据模型被创造进去后，凭借优良的表达能力和清晰易懂的个性让其很快在数据库市场中锋芒毕露，迅速占领市场，成为各行各业的支流数据存储系统。在这五十年内，数据库架构、表达方式、存储构造、优化器等方面都有了长足的倒退，然而索引构造的倒退绝对迟缓了一些，更多的倒退是基于现有的索引根底去优化查问优化器。倒退了三十年后进入互联网和挪动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据
背景
自从五十年前关系型数据模型被创造进去后，凭借优良的表达能力和清晰易懂的个性让其很快在数据库市场中锋芒毕露，迅速占领市场，成为各行各业的支流数据存储系统。在这五十年内，数据库架构、表达方式、存储构造、优化器等方面都有了长足的倒退，然而索引构造的倒退绝对迟缓了一些，更多的倒退是基于现有的索引根底去优化查问优化器。
倒退了三十年后进入互联网和挪动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据库（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。
对于重要客户咱们会收费提供专家服务群，在群外面会有表格存储各个模块的外围研发专家，会第一工夫解决技术或者稳定性上的问题，为客户提供一个绝佳的应用体验。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
