高可扩展性数据库架构设计方法.doc

高可扩展性数据库架构设计方法时宜 雅迅网络股份有限公司摘要：软件系统的规模化运作对数据库存取性能提出了越来越苛刻的要求，本文在目前流行数据库软件自身尚不能提供包含分布式管理、存储、负载均衡的综合解决方案的条件下，研究如何从应用层面解决目前用户群体庞大的软件系统在数据库存取性能方面的瓶颈问题。本文分析了仅仅依赖数据库软件本身解决性能瓶颈问题的困难和局限性，利用分而治之的思想，在应用层引入了Sharding的概念，切实地分析解决了数据库的扩展问题。本文认为横向向外扩展方案优于垂直向上扩展，隐含“分而治之”思想的水平分割、垂直分割能有效解决数据库性能扩展问题，从而为大规模用户容量、高并发访问的软件系统的建设提供了一种切实可行的性能扩展方法。关键词：数据库、性能扩展、Sharding、水平分割、垂直分割一、 引言不管是通过终端零售，抑或是通过与实力雄厚的中间运营商进行合作，面向社会大众的个人消费类IT产品，想要形成利润，必须通过规模化运作才能完成。掌握着能够从单宗商品交易中获取高额利润的高端、重量级IT解决方案的厂商实在是为数不多。而规模化运作对IT技术提出了越来越苛刻的要求。虽然，在这个时代，已经有许多人提出了NoSQL数据库的概念，就是所谓的“去SQL化”。如Google提出的BigTable等技术。但对于许多系统而言，旧式的关系型数据库软件，依然是不可或缺的重要法宝。可是，数据库不是银弹！简单地使用数据库软件，无法满足百万级、千万级用户的快速响应需求。许多声称精通数据库编程的人们，他们所能做的只是：1、 在一台物理服务器上安装一个数据库软件2、 按照数据库理论设计一些符合范式要求的数据表3、 更进一步可能他们还会建立一些索引、存储过程、视图4、 使用ADO、ADO.NET、JDBC或更高级的技术去读写这个数据库只是这些，受过正规训练的IT工作者在12年内应该能彻底掌握这些技术，他们可以用它来完成许多功能，但是这是最初级的层次。对于正式的商用系统的架构设计者，千百万级的用户对系统性能的要求会迫使他们在数据库软件的使用方式上思考更多。二、 设计理念(一) 向上扩展和向外扩展在计算机的世纪里，如果谈到软件运行缓慢，性能不足，最容易联想到的方法是增加投入，提高硬件的配置，似乎性能问题便可得到解决。业内，我们把这个解决方法叫做“向上扩展”。向上扩展即扩展到更大更强、也更昂贵的服务器上。需要特别指出的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。向上扩展的成本非常高，同时它仍然无法回避下面这个问题。中国有句古语云：“人力有时而穷”。事实上，“机”力也有时而穷。按照目前的技术，无法不计成本、无止境地提高单台服务器的性能。就像Intel在冲击4GHz主频后，选择了转向“多核”技术一样。一般来说，大型系统倾向于向外扩展，因为从长期来看，即便是巨型数据库，最后也会不堪重负，向外扩展将让它们得以保留通过增加服务器以提升系统能力的后路，就像多核一样。向外扩展即部署大量相对便宜的服务器来分担数据库压力。最后用一句话来总结，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。(二) 分而治之数据库的向外扩展，其本质是“分而治之”的思想。对于大型问题的求解，往往是将其分解为多个小问题，从而保证每个小问题都是更容易解决的，并且是可以同时解决的。这一点容易在传统行业中得到验证，这就像建造一座50层楼高的摩天大厦，工作量自然是相当大的。如何完成这个任务，我们需要的是一支分工明确的建筑队伍，而不是一个超人。在数据库的使用上，一样的，这里的大用户容量和高并发相当于一座50层楼高的摩天大厦，每一个数据库服务器就相当于一个建筑工人，我们需要的是分工明确的数据库集群，而不是一个超级、巨型的数据库。三、 数据库集群技术(一) 常见数据库产品的集群技术1. SQL Server系列1) 官方集群技术严格地说来，微软的SQL Server系列有个非常大的弱点，它的集群技术主要是针对高可用性的，对负载均衡没有太大的作用。用户在实际中遇到性能问题时，如果向上扩展不能解决问题，没有合适的集群方案解决，就意味着要移植到其他平台上，如Oracle，采用RAC来解决。这将是一个即费财力、物力、人力，同时还要面临很大风险的一个艰难过程。但是又不得不走这条路，没有办法。SQL Server Cluster相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，Microsoft称之为故障转移集群。 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份： 因为始终只有一个节点在运行，在性能上也得不到提升，系统也就不具备扩展的能力。 当现有的机器不能满足应用的负载时只能更换更高配置的机器。 对于一个小型的应用来说，使用一个共享设备和一个在正常情况下用不到的机器，总体成本的浪费还是很严重的。从细节上讲，当一个节点出现故障的时候，另一个节点接管业务又是需要一定的步骤和时间。2) 第三方集群软件a) 数据库路由软件-ICXICX数据库路由器，现在又叫DBCluster，现又改名叫DBTWINS。其软件的功能宣传非常动人，但实际情况是，没有看到真正成功的应用案例，失败的案例倒有不少。而且从2004年开始应用开始，时至今日也没有完善到可用地步。b) Moebius for SQL Server该软件由北京格瑞趋势科技有限公司开发，格瑞趋势是一家专注于数据库集群领域的行业解决方案供应商，致力于无共享磁盘架构数据库集群及分布式数据库集群技术的研发和推广。截至到SQL Server 2008，微软还是没有推出负载均衡组件，只能靠第三方软件来实现。这个第三方软件利用SQL Server的一些内部接口把集群做的非常透明， 无论是应用程序的调用还是开发/管理人员的使用都和面对一个数据库一样。其实现原理是这样的：和SQL Server镜像一样，每个数据库节点都有自己的数据，也就是无共享磁盘架构。被称之为“中间件”的程序宿主在数据库的内部，每个节点数据库上写入数据导致数据变化时，SQL Server会激活“中间件”，“中间件”把变化的数据同步到其他的节点上。其他节点发生变化也是一样。因为“中间件”宿主在数据库内， 所以它能够把每个同步的Session和SQL Server的Session绑定到一起，也就是使用户的执行和数据的同步成为一个原子操作，从而保证数据在每时每刻都是一致的。因此查询可以随便到每个机器上去查，从而做到了真正的负载均衡。2. Oracle1) 官方集群技术Oracle数据库用于解决负载均衡问题的技术叫做RAC。Oracle RAC 主要架构可以这么来概括：基于一个高性能的共享存储设备，建立多个 Oracle 实例服务器，多个 Oracle 实例服务器通过集群软件来访问共享存储设备。Oracle RAC 与 Mysql NDB、DB2 集群最大的不同是，前者采取 share storage方式，而后者采取 share nothing方式2) 第三方集群软件在Oracle中，使用第三方集群软件主要还是配合RAC来使用的。自从oracle 10g开始，第三方集群软件的需求减少了，除非要求使用文件系统。3. MySQL1) 官方集群技术MySQL数据库实现集群的官方技术是MySQL Clustering(ndb-cluster stogare)。MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。 成本n 节点服务器对RAM的需求很大，与数据库大小呈线性比例n 最好使用千兆以太网络n 还需要使用Dolphin公司提供的昂贵的SCI卡 优点n 可用于负载均衡场合n 可用于高可靠性场合n 高伸缩性n 真正的数据库冗余n 容易维护 缺点n 随着数据库的变大，对RAM的需求变得更大，因此成本很高 速度n 几乎比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍 应用场合n 冗余，高可靠性，负载均衡MySQL官方网站推荐的HA方案是结合DRBD(共享硬盘)和Replication(复制-读写分离)。假如再加上Linux Heartbeat还可实现Auto-failover功能，在此种情况下，我们会发现，down机时间会大大减少。虽然上述方案解决了集群问题，但对于Mysql服务器之间的负载均衡还是存在问题的。2) 其他集群方案a) MySQL Proxy + HSCALE一套比较有潜力的方案。其中 MySQL Proxy (/wiki/MySQL_Proxy) 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy 的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用 Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE 各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。 b) Hibernate Shards 这是 Google 技术团队贡献的项目（/414.html），该项目是在对 Google 财务系统数据 Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能应用，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。c) Spock Proxy这也是在实际需求中产生的一个开源项目。Spock（/）是一个人员查找的 Web 2.0 网站。通过对自己的单一 DB 进行有效 Sharding化 而产生了Spock Proxy(/ ) 项目，Spock Proxy 算得上 MySQL Proxy 的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以Spock Proxy 也是基于 Rails 构建。d) HiveDB上面介绍了 RoR 的实现，HiveDB (/)则是基于Java 的实现，另外，稍有不同的是，这个项目背后有商业公司支持。4. PostgreSQL1) 常见的一种方案 PostgreSQL和Slony-I、PL/Proxy、Pgbouncer已经可以为我们提供一套比较完整的企业级数据库存储解决方案Slony-I是一种基于postgresql的异步通知机制做的复制技术， 其同步速度非常快。采用这个复制技术来做备份。当然作为主、从架构的数据库而言，作为同步的一个手段还是合适的。不过，配置复杂了一点。PL/Proxy可以为PostgreSQL提供横向扩展能力，PL/Proxy 的设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发，示意图如下：PL/Proxy 的设计初衷就是在这一层充当数据总线的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。（虽然随着服务器越多，通信的开销越大，但只要不大于某个规模，似乎还不足以成为比较大的问题)。随着数据总线层的水平扩展，连接池的问题就凸显出来。Skype 在连接池上的解决方案是采用 PgBouncer，PgBouncer 极大地增强了 PostgreSQL 的连接数扩展能力。这个多线程的连接池允许单个PostgreSQL数据库服务器支持最多100,000个应用程序连接。2) pgpool-IIpgpool-II的优点在于能进行并发查询。并发查询（Parallel query）根据预定义的规则将特定范围的数据分布到各个节点。为了能够启用pgpool-II的并发查询功能，必须设置另外一个叫做“System Database”的数据库（我们称之为SystemDB）。SystemDB保存决定数据如何在各节点中保存的用户定义规则，另一个用途是合并使用数据库链（dblink）从数据库节点返回的结果。3) PGClusterPGCluster是一个为PostgreSQL设计的多主机数据同步备份系统。从PGCluster的官方介绍来看，它最大的两个特点就是：多主机和同步备份PGCluster实质上是一种Master-Master备份方案，其数据备份方案有normal mode 和 reliable mode两种，并能保证事务的一致性。它的亮点是做到了数据的实时同步性，但是换来的却是牺牲了性能。(二) 现有数据库集群技术总结1. 差异点上述的多种数据库软件下的多种数据库集群搭建方案，大致列举了目前较为多用的一些数据库集群解决方案。稍稍留意一下各种集群的实现方式，可以发现数据库集群方法主要在以下方面会存在着差别： 共享存储的使用 数据同步复制分发2. 问题的解决效果1) 不够理想的负载均衡Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。 而其他许多数据库集群则是使用了镜像、同步复制技术，实现了数据库读操作的负载均衡，从而解决了读的性能问题。典型的有，SQL Server和MySQL的主从模式，它们引入了负载均衡概念，可以对集群中的主服务器写入，然后同步到多个从服务器上，由于所有的服务器上的数据宏观上看是一致的，一次读取可以从多台服务器中任意选择一台进行数据读取。显然由于可用于读的数据库服务器增加了，因此，读性能得到了提高。但这种方式，由于只有一台服务器可写入，写性能无法得到提高。更进一步，MySQL Proxy还可以做到前端提供一个虚拟IP，后端连接多个MySQL数据库服务器，向虚拟IP上写入时，可以随即选择负载较轻的服务器进行写入，看起来似乎有了多个服务器可以写入，写性能应该可以得到提高。但实际上，由于为了保证多个服务器数据一致，保证读操作，对隐藏在虚拟IP后的任何一台实际MySQL服务器的写入都要同步到其他服务器上。从宏观上看，由于同步的存在，每台服务器的写入I/O的量没有真正地下降，是解决不了问题的。这也是Moebius for SQL Server和MySQL Proxy不能实现真正意义上的负载均衡的重要原因，写性能无法扩展。2) 思路正确的负载均衡留意PL/Proxy 的设计思想中提到的 Hash 机制，以及pgpool-II并发查询中提到的“根据预定义的规则将特定范围的数据分布到各个节点”的概念。它们都有将满足不同条件的数据进行跨服务器存储的味道，注意这里没有同步。所谓，满足不同条件，即指部分字段的取值在不同的、特定的范围内。按照字段取值范围的不同，将行记录存放在不同的物理服务器上。由于数据库写操作可以在不同的物理服务器上进行，并且不需要进行服务器间的同步，在随即写入的情况下，可以近似保证写入是被平均分配到多个服务器上的。如此，无需进一步提高单台服务器的写入性能，而是降低了在单台服务器上需要写入的量。在持续增加物理服务器的基础上，可以不断提高数据库系统的整体写入能力。(三) 向外扩展与Sharding目标很明确： 需要使用多台物理数据库向外扩展 消除同步复制带来的隐性IO操作这里我们正式引入一个新的概念，”Sharding”。Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的具体解决方案，是“分而治之”思想的实际体现。其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。Sharding的中文含义即“分片”。传统上，我们需要按照数据库设计范式，将满足相同关系的数据行记录保存到同一张数据表中，在没有分区功能时，这些数据将停留在同一个存储介质上。在数据库支持分区时，可将数据分散到物理上不同的存储介质上。但有一点不会发生变化，管理这些数据的数据库服务程序仍然只有一个。随着用户的增多，时间的推移，数据库服务程序需要管理的数据集将会越来越大，直至数据库服务难以有效运行，因为要运行的数据量太多，需要大量的内存和更高的IO性能，即便这样，当需要缓存数据的时候，内存的容量也不一定够。因此，我们需要单台物理数据库库服务器保持小数据库规模。必然地，需要将满足相同关系的数据记录按照某种规则分解为小的shards，分散存储在多个物理上完全不同一个的服务器中，这样，更有可能直接从缓存中访问数据，从而加快访问速度。并且小数据集更容易备份，恢复和管理。VS数据表 数据表(四) 理想的数据库集群模型上文中，已经列举了多种数据库集群的实现及提出Sharding的概念。从数据库编程使用的用户角度来看，Sharding如果由数据库软件内部来实现，对于开发者而言是最轻松的。 理想的方式，看起来应该这样：服务接入层数据存储层客户程序数据库包含两个部分：一部分专管接收客户程序的接入请求服务，一部分专管数据的实际存储。并具备以下特性： 允许任意增加管理节点和存储节点 从任意管理节点进入，均可完整地操作整个数据库系统 管理节点和存储节点间采用多对多的方式进行连接 任一管理节点都可以在任一存储节点上放置数据 当管理节点接收到写入请求时，可按某种规则决定将数据具体存放在哪些存储节点上 当管理节点接收到查询请求时，可按某种规则了解从哪些存储节点获取数据 当管理节点接收到更新请求时，可按某种规则获知更新哪些存储节点上的数据 不同的存储节点不需要将数据存储同步成一样的状态，即不需要进行大量同步操作 出于可用性的考虑，可以将一个数据块在一定量的存储节点上进行冗余存储对于这种理想模型，由于存储可以无限增加，数据管理能力也可无限增加，并且不需要大量多余的同步，从概念上它可以真正解决性能向外横向扩展的问题。(五) 现实的尴尬上文中提到的理想模型，对于开发者和网管而言是最为轻松的一种方案，但是非常遗憾，各种数据库软件，包括商业的数据库产品，目前都没有真正实现这一特性。（关于这一点，我们曾经向Oracle的一位资深专家请教，对方已经说明了这一点，并表示出于特别的性能考虑，在应用层决定将实际数据存储在不同的物理服务器是一种很正常的行为）这可以说明两点： 数据库软件原生支持这种完美的集群，从技术上而言是困难的，至少暂时无法实现n 从业界的最新动态来看，真正实现了这种集群的都是NoSql（反SQL运动）的分布式存储，如Google的 BigTable 和Amazon 的Dynamon 数据库软件目前对负载均衡集群的支持，基本上是通过数据同步（主从架构）或扩展插件技术（如Moebius for SQL Server、PL/Proxy、pgpool）来实现的n 目前真正实现了数据Sharding的插件，在运行形式上，不能说是优美的，甚至可以说有些恶心。Moebius for SQL Server插件实现的不是真正的Sharding，这里不去说它。对于PL/Proxy和pgpool都会要求对数据分片的规则进行特殊的定义，并且访问数据库也不能简单通过直接操作sql语句完成，而是要封装隐含分布规则的操作二次分发函数来完成 很显然，我们无法从各种数据库软件得到完美的解决方案了，必须自己做些什么四、 设计方案(一) 值得辩明的误区关系型数据库从出生开始，已经在IT届纵横多年，获得了极为成功的应用，也切实解决了许多实际问题。但，数据库不是银弹，并不能解决所有问题。实质上，将数据置于数据库软件的统一管理下，带来的最大的好处是： 减少数据的重复，使数据具有最小的冗余度，重复的数据可以集中存在一起，被索引引用 由于数据被集中管理，一定程度保证了数据的完整性和一致性，想想数据库中的各种约束 提供了事务的支持，这对于金融这类严肃的行业是必须的其次才是： 对于开发者而言无需编写实现特定的索引，就能得到一定的查询性能随着时间的推移，目前对数据库的使用有些泛滥和盲目。更多的开发者把数据库的次要优点-“无须自行编写特定的索引，就能轻松获得一定的查询性能”，并由此带来的开发简便性放在了首要位置，对数据库中日益膨胀高达几千万甚至上亿、几十亿的数据量带来的数据重新组织存放需求视而不见，选择将性能问题完全推给数据库本身去解决。本文认为，这样的观点不妥当的。在“寻求开发简便性”和“解决问题”之间，应该优先保证“解决问题”。本文的观点是，在数据库软件没有带来完美的集群模型之前，要解决目前运作超大型规模系统带来的性能向外扩展问题，我们可能不得不采用一些从编程的角度看起来比较“恶心”的解决方案。实际上，从一个开发者的角度来看问题，PostgreSQL的PL/Proxy、pgpool-II技术可真的不优雅，也是那种为了解决特定的性能问题而提出的“非主流”方法。按：主流的解决方案是那种既可以保证性能及性能扩展，又让开发者觉得很自然轻松的解决方案，因为这是大家的期望，大势所趋。从编程的发展看，面向对象和面向服务是比较符合开发者胃口的，但面向对象和面向服务基本上都是以性能损失为代价的，想想C到C+到.NET、Java这类语言的过程，Webservice糟糕的性能表现，它们对于性能问题的解决都是寄望于硬件性能的提升。而这一次不灵了，我们需要的是向外横向扩展。(二) 设计的基调不管其他解决方案怎么做，本文对高可扩展性数据库架构设计的基调非常清晰，即“Sharding”。这个不是数据库层面的表分区，而是业务层面的分区，其核心特征在于： 在用户名字或者 ID 上做文章 应用程序控制查找机制带来DB瓶颈的根本性原因是用户太多了和时间太久了，既然单个数据库服务器不能应付如此之多的用户数据，一个实在的说法就是只让它应付一部分用户、一部分功能、一部分时间内的数据。(三) 垂直Sharding垂直拆分，即让单个服务器只处理系统的某一部分功能相关的数据。微博数据交友数据用户基本信息DAL层(四) 水平Sharding垂直拆分，只能部分缓解数据库的压力。用户量、运行时间存在无限增长的趋势。因此，水平拆分才是彻底解决单台数据库运行压力问题的“终极法门”。水平拆分的本质，前面已反复阐述过多次，此处不再赘述。本文仍然通过一个实际的做法来具体体现。假设目前系统内已拥有用户量为1千万，单一的数据库服务器已不能提供一个正常性能反应的访问时，我们可以这样做。将这1千万用户按照用户注册在系统的ID平均划分成20组，一组包含50万用户。同一组用户相关的数据存储在同一个数据库上。至此，我们需要20台数据库服务器。第1组50万用户相关数据第2组50万用户相关数据第20组50万用户相关数据DAL层(五) 继续引入主从技术除了垂直拆分、水平拆分外，注意到一个系统对数据库的使用往往具有以下的特征：读多写少(一般业务数据库的写读比约为3:7或者2:8)。基于这个事实，还可以在更小的粒度上继续追加主从架构技术，将垂直拆分、水平拆分后的单个数据库服务器节点进一步扩展成数据库组。现在开始考虑一个对拆分后处理指定的业务功能、指定用户相关的数据库存储。可以对写入设计一个具有双击热备特性的数据库服务器作为指定的业务功能、指定用户相关的数据库存储的主设备，同时增加几台从设备（也是数据库服务器），使用数据库软件的一些同步、复制技术，保证在一个可预期的短暂时延内，保证从设备上的数据始终与主设备上一致。如此，对指定的业务功能、指定用户相关的数据库存储，写入性能不变，但对于查询、读取，可以在主设备和从设备之间再建立一个负载均衡机制，是的读操作可以从多个设备中的任意一个进行，可供读取的设备增加后，显然总体上，单位时间内可接纳的读操作的总量被放大了，便可进一步提高读操作的性能。这也符合读操作比写操作来得多的需要。(六) 为何需要DAL层在上文的设计中，图示中出现了DAL层的概念。这与普通概念上的认识的DAL层是不大一样的。DAL，全称Data Access Layer，中文意即，数据访问层。普通概念中认为，数据访问层主要指访问各类数据库所使用的具体技术，如MS的ODBC、DAO、ADO、ADO.NET，Java的JDBC、CRM等，与业务无关。但此处，则大不相同，此处的DAL主要以业务为核心来设计各种接口。可以说传统的DAL以具体技术为核心，主要是面向异种数据库软件的，不同的数据库软件存在不同表现形式的DAL接口。而此处的DAL以业务为核心，主要是面向数据的组织存储方式的，不管使用哪一类数据库软件，不管数据如何组织，其接口的表现形式是固定的。VS业务需要DAL接口1DAL接口2DAL接口3 数据库访问技术DAL接口也许部分人觉得这是不必要的，实质上将DAL层中再度增加了一层。业务层面向业务的DAL层面向技术的DAL层实际存储层多出来的一层实际上，面向业务的DAL层中接口的设计短期内来看也是繁琐的。但是它可以消除底层数据库架构方式变动对业务层的剧烈影响。从长远来看，随着系统的运行、发展，数据库架构方式、数据的实际组织存储方式的变化是必然的。如果省去这个看似复杂的接口层设计，直接接触实际的数据库实现进行编程，则业务层与数据存储的耦合度将会变得高起来。带来的结果是，不能轻松地对数据库实现做出修改，因为要照顾到业务层的编程实现，在后续的维护和改进中将会出现大量协调工作。在这一点上，本文比较认同Amzon的网站架构方案：数据库被分成很多个小部分，围绕每个部分都会创建一个服务接口(API)，并且该接口是访问数据库的唯一途径，围绕着服务进行构建。面向服务的架构可以提供给隔离特性，一个服务可能有很多台数据库服务器，他们之间的数据是相通的，而对外接口只有一个，外界是无法知道这个服务后面的数据组织是如何搭建的。这给改进服务后面的数据组织带来了充足的余地。新的DAL封装了sharding的规则，使用业务应用的编写者无需人人了解数据在数据库中的具体存放方式和位置，他们只需要了解是否有一个接口可以提供他们想要的数据。DAL接口则由数据组织存储的实现者们来提供，这对于开发而言是一件有利的事情。每个人都去关注数据库怎么做才能得到高性能，会让他们无法集中精力处理业务交互控制逻辑。这还要要求他们都很自觉地注意到性能这一问题，似乎不太可靠。(七) 本文架构的整体形态微博业务DAL层第1组50万用户相关数据第20组50万用户相关数据微博数据第1组50万用户相关数据第20组50万用户相关数据导航数据导航业务DAL层五、 进一步扩展的关键技术(一) 分布式缓存按目前的技术水平来看，存在这样一个事实，即网络互联（光网络）、内存级访问的性能要高于磁盘机的IO。如果将多台拥有较大内存配置的机器，使用高性能互联技术将它们联系起来，可以提供一个内存总量很大，可以缓存非常多数据的分布式缓存。对于更新频度不高，但访问及其频繁的数据，可以通过一次访问，将其从数据库磁盘IO的级别提升到内存种缓存起来，并辅以更新时缓存失效通知机制，可以在数据库的磁盘IO上获得客观的节省。此类分布式缓存仅能缓存简单的键值对信息，但是也就够了。(二) 高端共享存储相对于普通的磁盘IO、磁盘阵列，专业的共享存储SAN，可以轻易提供2Gbps的IO吞吐能力，这对于提升数据库读写性能的效果是显而易见的，但是成本稍高。(三) 64位技术提升数据库软件的性能，除了提升磁盘IO能力外，还可以加大数据库软件所需要的缓存量，即增加机器的内存。对于32位机而言，虽然Windows 2003 server可以加装超过4GB的内存，但对于任何一个应用程序，受限于寻址空间，仅能有4GB的空间可供使用，并且其中尚有2GB需要被操作系统使用，数据库软件也不例外，意味着可有效使用2GB的内存空间，这对于数据库所需要的缓存而言并不能算大。因此，升级到64位机，使数据库软件能将更大的内存用于缓存，也会有效提升数据库软件的性能。六、 其他值得关注的事情(一) 性能监视和排错工具Shardin