分布式系统架构设计.docx
《分布式系统架构设计.docx》由会员分享，可在线阅读，更多相关《分布式系统架构设计.docx（19页珍藏版）》请在冰豆网上搜索。
分布式系统架构设计
本文作者KateMatsudaira是一位美丽的女工程副总裁，曾在SunMicrosystems、微软、亚马逊这些一流的IT公司任职。
她有着非常丰富的工作经历和团队管理经历，当过程序员、工程经理、产品经理以及人事经理。
专注于构建和操作大型Web应用程序/，目前她的主要研究方向是SaaS〔软件即效劳〕应用程序和云计算〔如大家所说的大数据〕。
本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的容，在此翻译并分享给大家。
开源软件已经成为许多大型的根本组成局部，随着这些的逐步壮大，他们的架构和一些指导原那么也开放在开发者们的面前，给予大家切实有用的指导和帮助。
这篇文章主要侧重于Web系统，并且也适用于其他分布式系统。
Web分布式系统设计的原那么
构建并运营一个可伸缩的Web站点或应用程序到底是指什么？
在最初，仅是通过互联网连接用户和访问远程资源。
和大多数事情一样，当构建一个Web效劳时，需要提前抽出时间进展规划。
了解大型创立背后的考前须知以及学会权衡，会给你带来更加明智的决策。
下面是设计大型Web系统时，需要注意的一些核心原那么：
∙可用性
∙性能
∙可靠性
∙可扩展
∙易管理
∙本钱
上面的这些原那么给设计分布式Web架构提供了一定的根底和理论指导。
然而，它们也可能彼此相左，例如实现这个目标的代价是牺牲本钱。
一个简单的例子：
选择地址容量，仅通过添加更多的效劳器〔可伸缩性〕，这个可能以易管理〔你不得不操作额外的效劳器〕和本钱作为代价〔效劳器价格〕。
无论你想设计哪种类型的Web应用程序，这些原那么都是非常重要的，甚至这些原那么之间也会互相羁绊，做好它们之间的权衡也非常重要。
根底
当涉及到系统架构问题时，这几件事情是必须要考虑清楚的：
什么样的模块比拟适宜？
如何把它们组合在一起？
如何进展恰当地权衡？
在扩大投资之前，它通常需要的并不是一个精明的商业命题，然而，一些深谋远虑的设计可以帮你在未来节省大量的时间和资源。
本文讨论的重点几乎是构建所有大型Web应用程序的核心：
效劳、冗余、分区和故障处理能力。
这里的每个因素都会涉及到选择和妥协，特别是前面所讨论的那些原那么。
解释这些核心的最正确方法就是举例子。
图片托管应用程序
有时，你会在线上传图片，而一些大型需要托管和传送大量的图片，这对于构建一个具有本钱效益、高可用性并具有低延时〔快速检索〕的架构是一项挑战。
在一个图片系统中，用户可以上传图片到一个中央效劳器里，通过网络连接或API对这些图片进展请求，就像Flickr或者Picasa。
简单点，我们就假设这个应用程序只包含两个核心局部：
上传〔写〕图片和检索图片。
图片上传时最好能够做到高效，传输速度也是我们最关心的，当有人向图片发出请求时〔例如是一个Web页面或其他应用程序〕。
这是非常相似的功能，提供Web效劳或容分发网络〔一个CDN效劳器可以在许多地方存储容，所以无论是在地理上还是物理上都更加接近用户，从而导致更快的性能〕边缘效劳器。
该系统需要考虑的其他重要方面：
∙图片存储的数量是没有限制的，所以存储应具备可伸缩，另外图片计算也需要考虑
∙下载/请求需要做到低延迟
∙用户上传一图片，那么图片就应该始终在那里〔图片数据的可靠性〕
∙系统应该易于维护〔易管理〕
∙由于图片托管不会有太高的利润空间，所以系统需要具备本钱效益
图1是个简化的功能图
图1图片托管系统的简化构造图
在这个例子中，系统必须具备快速、数据存储必须做到可靠和高度可扩展。
构建一个小型的应用程序就微缺乏道了，一台效劳器即可实现托管。
如果这样，这篇文章就毫无兴趣和吸引力了。
假设我们要做的应用程序会逐渐成长成Flickr那么大。
效劳
当我们考虑构建可伸缩的系统时，它应有助于解耦功能，系统的每个局部都可以作为自己的效劳并且拥有清晰的接口定义。
在实践中，这种系统设计被称作面向效劳的体系构造〔SOA〕。
对于此类系统，每个效劳都有它自己的独特功能，通过一个抽象接口可以与外面的任何容进展互动，通常是面向公众的另一个效劳API。
把系统分解成一组互补性的效劳，在互相解耦这些操作块。
这种抽象有助于在效劳、根本环境和消费者效劳之间建立非常清晰的关系。
这种分解可以有效地隔离问题，每个块也可以互相伸缩。
这种面向效劳的系统设计与面向对象设计非常相似。
在我们的例子中，所有上传和检索请求都在同一台效劳器上处理。
然而，因为系统需要具备可伸缩性，所以把这两个功能打破并集成到自己的效劳中是有意义的。
快进并假设效劳正在大量使用；在这种情况下，很容易看到写图片的时间对读图片时间会产生多大影响〔他们两个功能在彼此竞争共享资源〕。
根据各自体系，这种影响会是巨大的。
即使上传和下载速度一样〔这是不可能的，对于大多数的IP网络来说，下载速度：
上传速度至少是3:
1〕，通常，文件可以从缓存中读取，而写入，最终是写到磁盘中〔也许在最终一致的情况下，可以被多写几次〕。
即使是从缓存或者磁盘〔类似SSD〕中读取，数据写入都会比读慢〔PolePosition，一个开源DB基准的开源工具和结果〕。
这种设计的另一个潜在问题是像Apache或者Ligd这些Web效劳器通常都会有一个并发连接数上限〔默认是500，但也可以更多〕，这可能会花费高流量，写可能会迅速消掉所有。
既然读可以异步或利用其他性能优化，比方gzip压缩或分块传输代码，Web效劳可以快速切换读取和客户端来效劳于更多的请求，超过每秒的最接数〔Apache的最接数设置为500，这种情况并不常见，每秒可以效劳几千个读取请求〕。
另一方面，写通常倾向于保持一个开放的进展持续上传，所以，使用家庭网络上传一个1MB的文件花费的时间可能会超过1秒，所以，这样的效劳器只能同时满足500个写请求。
图2：
读取别离
规划这种瓶颈的一个非常好的做法是把读和写进展别离，如图2所示。
这样我们就可以对它们单独进展扩展〔一直以来读都比写多〕但也有助于弄明白每个点的意思。
这种别离更易于排除故障和解决规模方面问题，如慢读。
这种方法的优点就是我们能够彼此独立解决问题——在同种情况下，无需写入和检索操作。
这两种效劳仍然利用全球语料库的图像，但是他们可以自由地优化性能和效劳方法〔例如排队请求或者缓存流行图片——下面会介绍更多〕。
从维护和本钱角度来看，每一个效劳都可以根据需要独立进展扩展，但如果把它们进展合并或交织在一起，那么有可能无意中就会对另一个性能产生影响，如上面讨论的情景。
当然，如果你有两个不同的端点，上面的例子可能会运行的很好〔事实上，这非常类似于几个云存储供给商之间的实现和容分发网络〕。
虽然有很多种方法可以解决这些瓶颈，但每个人都会有不同的权衡，所以采用适合你的方法才是最重要的。
例如，Flickr解决这个读/写问题是通过分发用户跨越不同的碎片，每个碎片只能处理一组用户，但是随着用户数的增加，更多的碎片也会相应的添加到群集里〔请参阅Flickr的扩展介绍〕。
在第一个例子中，它更容易基于硬件的实际用量进展扩展〔在整个系统中的读/写数量〕，而Flickr是基于其用户群进展扩展（butforcestheassumptionofequalusageacrossuserssotherecanbeextracapacity）。
而前面的那个例子，任何一个中断或者问题都会降低整个系统功能〔例如任何人都没方法执行写操作〕，而Flickr的一个中断只会影响到其所在碎片的用户数。
在第一个例子中，它更容易通过整个数据集进展操作——例如，更新写效劳，包括新的元数据或者通过所有的图片元数据进展搜索——而Flickr架构的每个碎片都需要被更新或搜索〔或者需要创立一个搜索效劳来收集元数据——事实上，他们就是这样做的〕。
当谈到这些系统时，其实并没有非常正确的答案，但有助于我们回到文章开场处的原那么上看问题。
确定系统需求〔大量的读或写或者两个都进展、级别并发、跨数据查询、围、种类等等〕，选择不同的基准、理解系统是如何出错的并且对以后的故障发生情况做些扎实的方案。
冗余
为了可以正确处理错误，一个Web架构的效劳和数据必须具备适当的冗余。
例如，如果只有一个副本文件存储在这台单独的效劳器上，那么如果这台效劳器出现问题或丧失，那么该文件也随即一起丧失。
丧失数据并不是什么好事情，防止数据丧失的常用方法就是多创立几个文件或副本或冗余。
同样也适用于效劳器。
如果一个应用程序有个核心功能，应确保有多个副本或版本在同时运行，这样可以防止单节点失败。
在系统中创立冗余，当系统发生危机时，如果需要，可以消除单点故障并提供备份或备用功能。
例如，这里有两个一样的效劳例如在生产环境中运行，如果其中一个发生故障或者降低，那么该系统容错转移至那个安康的副本上。
容错转移可以自动发生也可以手动干预。
效劳冗余的另一重要组成局部是创立一个无共享架构。
在这种体系构造中，每个节点都能相互独立运行，并且没有所谓的中央“大脑〞管理状态或协调活动其他节点。
这对系统的可扩展帮助很大，因为新节点在没有特殊要求或知识的前提下被添加。
然而，最重要的是，这些系统是没有单点故障的，所以失败的弹性就更大。
例如在我们的图片效劳器应用程序中，所有的图片在另一个硬件上都有冗余副本〔理想情况下是在不同的地理位置，防止在数据中心发生一些火灾、地震等自然事故〕，效劳去访问图片将被冗余，所有潜在的效劳请求。
〔参见图3：
采用负载均衡是实现这点的最好方法，在下面还会介绍更多方法〕
图3图片托管应用程序冗余
分区
数据集有可能非常大，无法安装在一台效劳器上。
也有可能这样，某操作需要太多的计算资源、性能降低并且有必要增加容量。
在这两种情况下，你有两种选择：
纵向扩展或横向扩展。
纵向扩展意味着在单个效劳器上添加更多的资源。
所以，对于一个非常大的数据集来说，这可能意味着添加更多〔或更大〕的硬件设备，来使一台效劳器能容下整个数据集。
在计算操作下，这可能意味着移动计算到一个更大的效劳器上，拥有更快的CPU或更大的存。
在各种情况下，纵向扩展可以通过提升单个资源的处理能力来完成。
横向扩展在另一方面是添加更多的节点，在大数据集下，这可能会使用第二效劳器来存储局部数据集，对于计算资源来说，这意味着分割操作或跨节点加载。
为了充分利用横向扩展，它应作为一种在的系统架构设计原那么，否那么修改或拆分操作将会非常麻烦。
当谈到横向扩展时，最常见的做法是把效劳进展分区或碎片。
分区可以被派发，这样每个逻辑组的功能就是独立的。
可以通过地理界限或其他标准，如非付费与付费用户来完成分区。
这些方案的优点是他们会随着容量的增加提供一个效劳或数据存储。
在我们的图片效劳器案例中，用来存储图片的单个文件效劳器可能被多个文件效劳器取代，每个里面都会包含一套自己独特的图像。
〔见图4〕这种架构将允许系统来填充每一个文件/图片效劳器，当磁盘填满时会添加额外的效劳器。
这样的设计需要一个命名方案，用来捆绑图片文件名到其相应的效劳器上。
图像名字可以形成一个一致的哈希方案并映射到整个效劳器上；或者给每图片分配一个增量ID，当客户端对图片发出请求时，图片检索效劳只需要检索映射到每个效劳器上〔例如索引〕的ID。
图4图片托管应用程序冗余和分区
当然，跨越多个效劳器对数据或功能进展分区还是有许多挑战的。
其中的关键问题是数据本地化。
在分布式系统中，数据操作或计算点越接近，系统性能就会越好。
因此，它也可能是个潜在问题，当数据分散在多个效劳器上时。
有时数据不是在本地，那么就要迫使效劳器通过网络来获取所需的信息，这个获取的过程就会设计到本钱。
另一潜在问题是不一致。
当这里有多个效劳对一个共享资源执行读写操作时，潜在可能会有另一个效劳器或数据存储参与进来，作为竞选条件——一些数据需要更新，但是读的优先级高于更新——在这种情况下，数据就是不一致的。
例如在图片托管方案中，有可能出现的不一致是：
如果一个客户端发送更新“狗〞图片请求，进展重新命名，把“Dog〞改成“Gizmo〞，但同时，另一个客户端正在读这图片。
在这种情况下，标题就是不清楚的。
“Dog〞或“Gizmo〞应该被第二个客户端接收。
当然，在进展数据分区时会产生一些障碍，但是分区允许把每个问题拆分到管理群里——通过数据、负载、使用模式等。
这样对可扩展和易管理都是有帮助的，但也不是没有风险的。
这里有很多方式来降低风险和故障处理；然而，为了简便起见，并未在本文中详细说明，如果你有兴趣，可以访问我的博客。
总结
以上介绍的都是设计分布式系统需要考虑的核心要素。
可用性、性能、可靠性、可扩展、易管理、本钱这几个原那么非常重要，但在实际应用中可能会以牺牲某个原那么来实现另外一个原那么，在这个过程中就要做好权衡工作，做到因时制宜。
在下面的构建分布式系统实战中，我们将会深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。
摘要：
在上一篇?
构建高可扩Web架构和分布式系统实战?
中，我们举例讨论了设计分布式系统需要考虑的核心要素：
可用性、性能、可靠性、可扩展、易管理、本钱。
而在这篇文章中，我们将深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。
本文作者KateMatsudaira是一位美丽的女工程副总裁，曾在SunMicrosystems、微软、亚马逊这些一流的IT公司任职。
她有着非常丰富的工作经历和团队管理经历，当过程序员、工程经理、产品经理以及人事经理。
专注于构建和操作大型Web应用程序/，目前她的主要研究方向是SaaS〔软件即效劳〕应用程序和云计算〔如大家所说的大数据〕。
本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的容，我们进展了翻译并分为上下两篇分布分享给大家。
在上一篇?
构建高可扩Web架构和分布式系统实战?
中，我们举例讨论了设计分布式系统需要考虑的核心要素：
可用性、性能、可靠性、可扩展、易管理、本钱。
而在这篇文章中，我们将深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。
构建快速可伸缩的数据访问块
在讨论完设计分布式系统的核心考虑因素后，下面让我们再一起讨论难点局部：
可扩展的数据访问。
大多数简单的Web应用程序，例如LAMP堆栈应用程序，看起来如图5所示：
图5：
简单的Web应用程序
随着系统渐渐扩大，他们将面临两大主要挑战：
构建可扩展的应用程序效劳器和数据访问机制。
在一个高可扩的应用程序设计中，通常最小化的应用程序〔或Web〕效劳往往能表达一种无共享的架构。
这就使得应用程序效劳器层要进展横向扩展，这种设计的结果就是把繁重的工作转移到堆栈下层的数据库效劳和配置效劳上，这才是这一层上真正的可扩展和性能挑战。
本文的剩余局部专门讨论一些常见策略和方法来使这些效劳可以快速和可扩展，提升数据的访问速度。
图6过于简化的的Web应用程序
大多数系统可能会简化成图6那样，这是个非常不错的起点。
如果你有大量的数据，想要快速便捷地访问，就好比在你书桌抽屉的最上面有一堆糖果。
虽然过于简化，但也暗示了两个难题：
可扩展存储和快速的数据访问。
为了这个例子，让我们假设有许多太字节〔TB〕数据，并且允许用户随机访问一小局部数据〔见图7〕。
这与本文图片应用程序里的在文件效劳器上定位一个图片文件非常相似。
图7访问特定数据
这也是个非常大的挑战，把TB级数据加载到存中的本钱比拟昂贵，这可以直接转化到磁盘上进展IO。
从磁盘上读取要比存慢的多——存访问和ChuckNorris一样快，而磁盘的访问速度要比在DMV上慢。
这个速度不同于大数据集上的合计，实数存访问大概要比顺序访问快6倍，或者比随机从磁盘上读取快10万倍〔参考ThePathologiesofBigData〕。
此外，即使是uniqueID，想要在较少的数据中查找确切的位置也是一项艰巨的任务。
幸运的是，能找到许多方法让这个问题变的简单，这里提供4个非常重要的方法：
缓存、代理、索引和负载均衡器。
在下面将会详细讨论这4个容来提升数据访问速度。
缓存
缓存就是利用本地参考原那么：
当CPU要读取一个数据时，首先从缓存中查找，找到就立即读取并送给CPU处理；没有找到，就用相对慢的速率从存中读取并送给CPU处理，同时把这个数据所在的数据块调入缓存中，可以使得以后对整块数据的读取都从缓存中进展，不必再调用存。
它们几乎被用在每一个计算层上：
硬件、操作系统、Web浏览器、Web应用程序等。
一个缓存就相当于是一个临时存：
它有一个有限的空间量，但访问它比访问原始数据速度要快。
缓存也可以存在于各个层的架构中，但经常在离前端最近的那个层上发现，在那里可以快速实现并返回数据，无需占用下游层数据。
那么如何在我们的API例子里利用缓存使数据访问更快呢？
在这种情况下，有许多地方可以插入缓存。
一种是在请求层节点上插入缓存，如图8所示。
图8在请求层节点插入缓存
在请求层节点上放置一个缓存，即可响应本地的存储数据。
当对效劳器发送一个请求时，如果本地存在所请求数据，那么该节点即会快速返回本地缓存数据。
如果本地不存在，那么请求节点将会查询磁盘上的数据。
请求层节点缓存即可以存在于存中〔这个非常快速〕也可以位于该节点的本地磁盘上〔比访问网络存储要快〕。
图9多个缓存
当扩展到许多节点的时候，会发生什么呢？
如图9所示，如果请求层被扩展为多个节点，它仍然有可能访问每个节点所在的主机缓存。
然而，如果你的负载均衡器随机分布节点之间的请求，那么请求将会访问各个不同的节点，因此缓存遗漏将会增加。
这里有两种方法可以克制这个问题：
全局缓存和分布式缓存。
全局缓存
顾名思义，全局缓存是指所有节点都使用同一个缓存空间。
这包含添加一台效劳器或某种类型的文件存储，所有请求层节点访问该存储要比原始存储快。
每个请求节点会以同种方式查询缓存，这种缓存方案可能有点复杂，随着客户机和请求数量的增加，单个缓存〔Cache〕很容易溢出，但在某些构造中却是非常有效的〔特别是那些特定的硬件，专门用来提升全局缓存速度，或者是需要被缓存的特定数据集〕。
在图10中描述了全局缓存常见的两种方式。
当一个Cache响应在高速缓存中没有发现时，Cache自己会从底层存储中检索缺少的那块数据。
如图11所示，请求节点去检索那些在高速缓存中没有发现的数据。
图10负责检索数据的全局缓存
图11全局缓存里负责检索的请求节点
大多使用全局缓存的应用程序都倾向于使用第一种类型，利用Cache本身来驱逐和获取数据以防止来自客户端的同一个数据区发出大量的请求。
然而，在某些情况下，使用第二种实现反而更有意义。
例如，如果该缓存用于存储大量的文件，低缓存的命中率会导致高速缓冲区不堪重负和缓存遗漏，在这种情况下，ithelpstohavealargepercentageofthetotaldataset（orhotdataset）inthecache.
分布式缓存
分布式缓存即缓存在分布式系统各节点存中的缓存数据。
如图12所示，每个节点都有自己的缓存数据，所以如果冰箱扮演着缓存杂货店的角色，那么分布式缓存就是把食物放置在不同的地方——冰箱、橱柜和饭盒——当索取的时候，方便拿哪个就拿哪个，而无需特地往商店跑一趟。
通常情况下，会使用一致性哈希函数对缓存进展划分，例如，一个请求节点正在寻找一个特定块的数据，在分布式缓存中，它很快就会知道去哪里找，并确保这些数据是可用的。
这种情况下，每个节点都会有一小块缓存，然后在向另一个节点发送数据请求。
因此分布式缓存的优点之一就是只需向请求池添加节点即可增加缓存空间，减少对数据库的访问负载量。
当然，分布式缓存也存在缺点，例如单点实效，当该节点出现故障或宕机，那么该节点保存的数据就会丧失。
图12分布式缓存
分布式缓存的突出优点是提高运行速度〔前提当然是正确实现〕。
选择不同的方法也会有不一样的效果，如果方确，即使请求数很多，也不会对速度有所影响。
然而，缓存的维护需要额外的存储空间，这些通常需要购置存储器实现，但价格都很昂贵。
其中一个非常流行的开源缓存产品：
Memcached〔即可以在本地缓存上工作也可以在分布式缓存上工作〕；然而，这里还有许多其他选项〔包括许多语言——或者是框架——特定选项〕。
Memcached用于许多大型Web站点，其非常强大。
Memcached基于一个存储键/值对的hashmap，优化数据存储和实现快速搜索〔O
（1）〕。
Facebook采用不同类型的缓存技术来提升他们的性能〔参考“Facebookcachingandperformance〞〕。
在语言层面上使用$GLOBALS和APC〔在PHP里提供函数调用〕，这有助于使中间函数调用更快〔大多数语言都使用这些类型库来提升页面性能〕。
Facebook使用全局缓存并且通过多台效劳器对缓存进展分布〔参考“ScalingmemcachedatFacebook〞〕，这就允许他们通过配置用户文件数据来获得更好的性能和吞吐量，并且还可以有一个中心位置更新数据〔这是非常重要的，当运行成千上万台效劳器时，缓存实效和一致性维护都是非常大的挑战〕。
下面让我们谈谈当数据不在缓存中时，我们该做什么……
代理
简单点讲，代理效劳器就是硬件/软件的中间件，承受客户端请求并且将他们转发到后端的源效劳器上。
通常，代理效劳器用于过滤请求、记录请求日志或有时转换请求〔通过添加/删除头结点、加密/解密或压缩〕。
图13代理效劳器
代理可以优化请求，并且从整个系统的角度来优化请求通信量。
一方面，使用代理可以加速数据访问，可以把一样〔或相似的〕请求重叠压缩成一个请求，然后返回单个结果到请求客户端，这就是压缩转发〔collapsedforwarding〕。
在一个局域网代理中，例如，客户端无需使用它们自己的IP去连接互联网，对于一样的容，局域网将压缩来自客户端的请求。
它很容易造成混淆，因为很多代理同样也是缓存〔它是一个非常符合逻辑放置缓存的地方〕，但并非所有缓存都扮演代理这一角色。
图14使用一个代理效劳器压缩请求
使用代理效劳器的另一伟大方式是通过压缩请求对空间数据进展加密。
采用这种策略最大化数据本地化的请求会导致减少请求的延迟。
例如这里有一大串的节点请求B：
partB1、partB2等等。
我们可以设置代理来识别个人空间的位置请求，把它们压缩成单一的请求并只返回bigB，大大减少了从数据源处读取数据次数〔如图15所示〕。
在高负载的情况下，代理也特别有用，或者当你具有有限的缓存时，它们根本上可以把多个请求批处理成一个。
图15使用代理对空间数据请求进展压缩
如果你正在为系统寻找代理，这里提供几个供你选择：
Squid和Varnish，它们都做过非常全面的测试并且被广泛用在许多大型上。
这些代理解决方案对客户端——效劳器端通信提供了许多优化方案。
在Web效劳器层作为反向代理安装可以大大提高Web效劳性能，减少处理传入客户机请求所需的工作量。
索引
使用索引来快速访问和优化数据是一个众所周知的策略，最有名的莫过于数据库索引。
图16索引
一个索引就是数据库表的目录，表中数据和相应的存储位置的列表。
好比是一篇文章的目录，可以加快数据表的。
例如让我们来查找一块数据，B中的第二局部——如何发现它的位置？
如果你通过数据类型存储了一个索引——例如数据A、B、C——它将告诉你数据B的原始位置。
然后你只需去查看B并且根据需要阅读B的数据即可〔参考图16〕。
这些索引通常存储在存或者是传入客户端请求的本地中。
BerkeleyDBs〔BDBs〕和树数据构造常常被用在有序列表中存储数据，这是访问索引的理想选择。
通常，会把许多层索引作为一个映射，从一个位置移到下一个，以此类推，直到你得到想要的特定块数据〔参照图17〕。
图17多层索引
索引也可以对一样的数据创立多个不同的视图。
对大型数据集来说，这种方法是非常好的，无需创
升级会员 