《表格存储Tablestore威信指南》。值得一提的是，Tablestore可以支撑海量的数据规模，也供应了多种索引来支持丰富的查询模式，同时作为一个多模型数据库，供应了多种模型的抽象和特有接口。本文紧张对Tablestore的存储和索引引擎进行先容和解读，让大家对Tablestore引擎层的事理和能力，索引的浸染和利用办法等有一个认识。
基本架构Tablestore是一款云上的Serverless的分布式NoSQL多模型数据库，供应了丰富的功能。假设用户可以采取各种开源组件搭建一套类似做事，可以说是本钱非常高昂，而利用Tablestore仅需在掌握台上创建一个实例即可享受全部功能，而且是完备按量计费，可以说是0门槛。
整体架构如下图所示，本文不展开阐述每个模块的功能。
在做事端引擎层中，存在两个引擎：存储引擎和索引引擎。这两个引擎的数据构造和事理不同，为了方便读者理解，本文将这两个引擎称为表引擎(Table)和多元索引引擎(Searchindex)。整体来说，引擎层是基于LSM架构和共享存储(盘古)，支持自动的Sharding和存储打算分离。
表引擎表引擎的整体架构类似于Google的BigTable，在开源领域的实现有HBase等。
数据模型可以定义为宽行模型，如下图所示。个中不同的分区可以加载到不同的机器上，实现水平扩展：
首先解释一下为什么Tablestore的主键可以包含多个主键列，而像HBase只有一个RowKey。这里有几点：
多列主键列按照顺序共同构成一个主键，类似MySQL的联合主键。如果利用过HBase，可以把这里的多列主键列，拼接起来看作一个RowKey，每一列实在都只是整体主键的一部分。第一列主键列是分区键，利用分区键的范围进行分区划分，担保了分区键相同的行，一定在同一个分区(Partition)上。一些功能依赖这一特性，比如分区内事务(Transection)，本地二级索引(LocalIndex, 待发布)，分区内自增列等。业务上常须要多个字段来构成主键，如果只支持一个主键列，业务须要进行拼接，多列主键列避免了业务层做主键拼接和拆解。许多用户第一次看到多列主键列时，常会有误解，认为主键的范围查询(GetRange接口)可以针对每一列单独进行，实际上这里的主键范围指的是整体主键的范围，而非单独某一列的范围。这个模型具有这样的一些上风：
完备水平扩展，因此可支撑的读写并发和数据规模险些无上限。Tablestore线上也有一些业务在几千万级的tps/qps，以及10PB级的存储量。可以说一样平常业务达不到这样的上限，实际的上限仅取决于集群目前的机器资源，当业务数据量大量上涨时，只要增加机器资源即可。同时，基于共享存储的架构也很方便的实现了动态负载均衡，不须要数据库层进行副本数据复制。供应了表模型，比较纯粹的KeyValue数据库而言，具有列和多版本的观点，可以单独对某列进行读写。表模型也是一种比较通用的模型，可以方便与其他系统进行数据模型映射。表模型中，按照主键有序存储，而非Hash映射，因此支持主键的范围扫描。类似于HashMap与SortedMap的差异，这个模型中为SortedMap。Schema Free, 即每行可以有不同的属性列，数据列个数也不限定。这很适宜存储半构造化的数据，同时业务在运行过程中，也可以进行任意的属性列变更。支持数据自动过期和多版本。每列都可以存储多个版本的值，每个值会有一个版本号，同时也是一个韶光戳，如果设置了数据自动过期，就会按照这个韶光戳来判断数据是否过期，后台对过期数据自动清理。这个模型也有一些劣势：
数据查询依赖主键。可以把这个数据模型理解为SortedMap，大家知道，在SortedMap上只能做点查和顺/逆序扫描，比如以下查询办法：主键点查：通过已知主键，精确读取表上的一行。主键范围查：按照顺序从开始主键(StartPrimaryKey)扫描到结束主键(EndPrimaryKey)，或者逆序扫描。即对Table进行顺序或逆序遍历，支持指定起始位置和结束位置。主键前缀范围查：实在等价于主键范围查，这里只是解释，主键前缀的一个范围，实在可以转换成主键的一个范围，在表上进行顺序扫描即可。针对属性列的查询须要利用Filter，Filter模式在过滤大量数据时效率不高，乃至变成全表扫描。常日来说，数据查询的效率与底层扫描的数据量正干系，而底层扫描的数据量取决于数据分布和构造。数据默认仅按照主键有序存储，那么要按照某一属性列查询，符合条件的数据一定分布于全表的范围内，须要扫描后筛选。全表数据越多，扫描的数据量也就越大，效率也就越低。那么在实际业务中，主键查询常常不能知足需求，而利用Filter在数据规模大的情形下效率很低，怎么办理这一问题呢？
上面提到，数据查询的效率与底层扫描的数据量正干系，而Filter模式慢在符合条件的数据太分散，必须扫描大量的数据并从中筛选。那么办理这一问题也就有两种思路：
让符合条件的数据不再分散分布：利用全局二级索引，将某列或某几列作为二级索引的主键。相称于通过数据冗余，直接把符合条件的数据预先排在一起，查询时直接精确定位和扫描，效率极高。加快筛选的速率： 利用多元索引，多元索引底层供应了倒排索引，BKD-Tree等数据构造。以上面查询某属性列值为例，我们给这一列建立多元索引后，就会给这一列的值建立倒排索引，倒排索引实际上记录了某个值对应的所有主键的凑集，即Value -> List, 那么要查询属性列为某个Value的所有记录时，直接通过倒排索引获取所有符合条件的主键，进行读取即可。实质上是加快了从海量数据中筛选数据的效率。全局二级索引全局二级索引采取的仍旧是表引擎，给主表建立了全局二级索引后，相称于多了一张索引表。这张索引表相称于给主表供应了其余一种排序的办法，即针对查询条件预先设计了一种数据分布，来加快数据查询的效率。索引的利用办法与主表类似，紧张的查询办法仍旧是上面讲的主键点查，主键范围查，主键前缀范围查。常见的关系型数据库的二级索引也是类似的事理。
列举一个最大略的例子，比如我们有一张表存储文件的MD5和SHA1值，表构造如下：
通过这张表，我们可以查询文件对应的MD5和SHA1值，但是通过MD5或SHA1反查文件名却不随意马虎。我们可以给这张表建立两张全局二级索引表，表构造分别为：
索引1:
索引2:
为了确保主键的唯一性，全局二级索引中，会将原主键的主键列也放到主键列中，比如上面的FilePath列。有了上面两张索引表，就可以通过主键前缀范围查的办法里精确定位某个MD5/SHA1对应的文件名了。
多元索引引擎多元索引引擎比较于表引擎，底层增加了倒排索引，多维空间索引等，支持多条件组合查询、模糊查询、地理空间查询，以及全文索引等，还供应一些统计聚合能力(统计聚合功能待发布)。由于功能较纯挚的二级索引更加丰富，而且一个索引就可以知足多种维度的查询，因此命名为多元索引。
上面在讲解决Filter模式查询慢的问题时，提到倒排索引加快了数据筛选的速率，由于记录了某列的Value到符合条件的行的映射，Value -> List 。实际上，倒排索引这一办法，不仅可以办理单列值的检索问题，也可以办理多条件组合查询的问题。
我们举一个订单场景的例子，比如下表为一个订单记录：
上面一共16个字段，我们希望按照任意多个字段组合查询，比如查询某一售货员、某一产品类型、单价在xx元之上的所有记录。可以想到，这样的排列组合会有非常多种，因此我们不太可能预先将任何一种查询条件的数据放到一起，来加快查询的效率，这须要建立很多的全局二级索引。而如果采取Filter模型，又很可能须要扫描全表，效率不高。折中的办法是，可以先对某个字段建立二级索引，缩小数据范围，再对个中数据进行Filter。那么有没有更好的办法呢？
多元索引可以很好的办理这一问题，而且只须要建立一个多元索引，将所有可能查询的列加入到这个多元索引中即可，加入的顺序也没有哀求。多元索引中的每一列默认都会建立倒排，倒排就记录了Value到List的映射。针对多列的多个条件，在每列的倒排表中找到对应的List，这个称为一个倒排链，而筛选符合多个条件的数据即为打算多个倒排链的交并集，这里底层有着大量的优化，可以高效的实现这一操作。因此多元索引在处理多条件组合查询方面效率很高。
此外，多元索引还支持全文索引、模糊查询、地理空间查询等，以地理空间查询为例，多元索引通过底层的BKD-Tree构造，支持高效的查询一个地理多边形内的点，也支持按照地理位置排序、聚合统计等。
索引选择不是一定须要索引
如果基于主键和主键范围查询的功能已经可以知足业务需求，那么不须要建立索引。如果对某个范围内进行筛选，范围内数据量不大或者查询频率不高，可以利用Filter，不须要建立索引。如果是某种繁芜查询，实行频率较低，对延迟不敏感，可以考虑通过DLA(数据湖剖析)做事访问Tablestore，利用SQL进行查询。全局二级索引还是多元索引
一个全局二级索引是一个索引表，类似于主表，其供应了另一种数据分布办法，或者认为是另一种主键排序办法。一个索引对应一种查询条件，预先将符合查询条件的数据排列在一起，查询效率很高。索引表可支撑的数据规模与主表相同，另一方面，全局二级索引的主键设计也同样须要考虑散列问题。一个多元索引是一系列数据构造的组合，个中的每一列都支持建立倒排索引等构造，查询时可以按照个中任意一列进行排序。一个多元索引可以支持多种查询条件，不须要对不同查询条件建立多个多元索引。比较全局二级索引，也支持多条件组合查询、模糊查询、全文索引、地理位置查询等。多元索引实质上是通过各种数据构造加快了数据的筛选过程，功能非常丰富，但在数据按照某种固定顺序读取这种场景上，效率不如全局二级索引。多元索引的查询效率与倒排链长度等成分干系，即查询性能与全体表的全量数据规模有关，在数据规模达到百亿行以上时，建议利用RoutingKey对数据进行分片，查询时也通过指定RoutingKey查询来减少查询涉及到的数据量。简而言之，查询灵巧度和数据规模不可兼得。关于利用多元索引还是全局二级索引，也有其余一篇文章描述：《Tablestore索引功能详解》。
除了全局二级索引之外，后续还会推出本地二级索引(LocalIndex)，推出后再进行详细先容。
常见组合方案丰富的查询功能当然是业务都希望具备的，但是在数据规模很大的情形下，灵巧的查询意味着本钱。比如万亿行数据的规模，对付表引擎来说，由于水平扩展能力很强，本钱也很低，问题不大，但是建立多元索引，用度就会非常高昂。全局二级索引本钱较低，但是只适宜固定维度的查询。
常见的超大规模数据，都带有一些韶光属性，比如大量设备产生的数据(监控数据)，或者人产生的数据(、行为数据等)，这类数据非常适宜采取Tablestore存储。对这类数据建立索引，会有一些组合方案：
对元数据表建立多元索引，全量数据表不建立索引或采取全局二级索引。元数据表可以是产生数据的主体表，比如设备信息表，用户信息表等。在时序模型中，产生数据的主体也可以认为是一个韶光线，这条线会不断的产生新的点。Tablestore的时序数据模型(Timestream)采取的也是类似的办法，对时序数据中的韶光线建立一张表，专门用来记录韶光线的元数据，每个韶光线一行。韶光线表建立多元索引，用来做韶光线检索，而全量数据则不建立索引。在检索到韶光线后，对某个韶光线下的数据进行范围扫描，来读取这个韶光线的数据。热数据建立多元索引，老数据不建立索引或者采取全局二级索引：很多情形下仅须要对非常热的数据进行多种维度查询，对冷数据采纳固定维度查询即可。因此冷热分离可以给业务供应更高的性价比。目前多元索引还不支持TTL(后续会支持)，须要业务层区分热数据和冷数据。总结本文对Tablestore的存储和索引引擎进行了先容和解读，并在如何选择和运用索引方面给了一些参考，目的是加深大家对Tablestore的认识和理解，更好的运用Tablestore来办理业务需求。
本文作者：亦征
