Cloud Design Pattern - Index Table Pattern(索引表模式)

1.前言

上一篇我们讨论了云计算设计模式之健康端点监测模式,介绍了如何对云上的App的可用性及性能进行监测,这一篇我们将讨论如何通过优化数据查询来优化云上的App性能.

2.概念

关系数据库中的索引的概念大家都非常熟悉.在SQL Server 数据库中,主键默认就是聚集索引.我们都知道每一个数据表只能由一个聚集索引,但可以建立多个非聚集索引.当查询数据表的时候,不是根据主键进行查询,那么根据非聚集索引进行查询的时候效率更高一些.

然而,在云环境中,有很多的应用使用的是NOSQL这类的数据库,众所皆知,这类数据库并不支持非聚集索引,那么我们该怎么使用非聚集索引来优化我们的应用程序呢?答案就是自己建立非聚集索引,这就是今天我们要讨论的索引表模式.

下面的列表是传统形式下我们采用的数据存储形式:

为了提升效率,我们先建立索引表,通过索引表去查询数据存储表.如下图所示:

这里我们采用的是联合主键形式,在索引表的每条记录对应在具体的数据表的一条记录.数据存储范式中有一条就是不要有冗余数据,那么在这里我们采用的是非冗余形式,其实在某些时候,我们可以适度冗余,如下图的设计：

这时候,索引表中的主键是冗余的,但是这种形式的冗余对于提升数据查询效率还是有益的,所以不可以一味地坚持某个原则,最重要的是要能够提升查询效率.

在采用这种模式的时候,以下几个方面值得权衡:

1）维护索引表的性能损耗需要考虑,否则得不偿失.这个权衡可能在整个过程中会不停变化，开始可能建立索引表并没有大的提升,甚至效率更低,但是面对很大数据量的时候,效果就很明显了,所以这种模式并非在最开始就使用,一般都是中后期使用.

2）索引表中冗余数据可能会占用较多的空间.这时候需要在是独立冗余主键还是组合非冗余主键之间进行权衡.对冗余数据的处理浪费控件且费时.

3）应用在查询数据的时候需要查询两次,第一次返回实际数据的索引,第二次才真正查询实际数据.

4）当索引表的数据量很大的时候,实际上很难去维护索引表和实际数据之间的一致性.这时候就需要一种检查机制来确保这种一致性.通常的做法是在更新实际数据表的时候,我们将需要更新索引表的这个事件发送到消息队列,让效率队列的消费者逐个消费这个Task.详细信息查看:Data Consistency primer.

5）索引表自身也是可以被分区和被当作原始数据再次索引的.

3.Example

Azure Table Storage 就是采用这种方式进行存储的.Azure中的应用通过给定一个key来存储或者获取数据,这个Key会对应多列多行的数据。Azure中的表也是支持分区的,只需要一个分区的Key即可.在Azure Table中存储的数据的样式如下:

这种设计是基于用户查询方式通常都是使用Genre字段来查询的,如果是使用演员的名字来查询的话,我们使用如下设计更为合适.

4.相关阅读

The following patterns and guidance may also be relevant when implementing this pattern:

• Data Consistency Primer. An index table must be maintained as the data that it indexes changes. In the cloud, it may not be possible or appropriate to perform operations that update an index as part of the same transaction that modifies the data—an eventually consistent approach may be more suitable. This primer provides information on the issues surrounding eventual consistency.
• Sharding Pattern. The Index Table pattern is frequently used in conjunction with data partitioned by using shards. The Sharding pattern provides more information on how to divide a data store into a set of shards.
• Materialized View Pattern. Instead of indexing data to support queries that summarize data, it may be more appropriate to create a materialized view of the data. This pattern describes how to support efficient summary queries by generating pre-populated views over data.