Web、GIS、数据服务器选型依据

数据库服务器选型五个原则

对于大型数据库(ERP, OLTP, data mart)来说，服务器往往仅用来运行数据库，或仅运行单一的应用。数据库的容量在1TB以上，需要有较高的CPU处理能力，大容量内存为数据缓存服务，并需要很好的IO性能，使用这类应用时，通常需要有较高的CPU主频。那么，具体到某个行业甚至某个项目，数据库服务器该如何选择呢?

　　首先，数据库服务器选型应该遵循以下几个原则：

　　1)高性能原则

　　保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期的业务量增长的需要。一般可以根据经验公式计算出所需的服务器TpmC值，然后比较各服务器厂商和TPC组织公布的TpmC值，选择相应的机型。同时，用服务器的市场价/报价除去计算出来的TpmC值得出单位TpmC值的价格，进而选择高性能价格比的服务器。

　　2)可靠性原则

　　可靠性原则是所有选择设备和系统中首要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如：网络系统、安全系统、远程打印系统等。在必要时，还应考虑对关键服务器采用集群技术，如：双机热备份或集群并行访问技术，甚至采用可能的完全容错机。

　　比如，要保证系统(硬件和操作系统)在99.98%的时间内都能够正常运作(包括维修时间)，则故障停机时间六个月不得超过0.5个小时。服务器需7×24小时连续运行，因而要求其具有很高的安全可靠性。系统整机平均无故障时间(MTBF)不低于80000小时。服务器如出现CPU损坏或其它机械故障，都能在20分钟内由备用的CPU和机器自动代替工作，无须人员操作，保证数据完整。

　　3)可扩展性原则

　　保证所选购的服务器具有优秀的可扩展性原则。因为服务器是所有系统处理的核心，要求具有大数据吞吐速率，包括：I/O速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如：CPU型号升级、内存扩大、硬盘扩大、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。这都需要所选购的服务器在整体上具有一个良好的可扩充余地。一般数据库和计费应用服务器在大型计费系统的设计中就会采用集群方式来增加可靠性，其中挂接的磁盘存储系统，根据数据量和投资考虑，可以采用DAS、NAS或SAN等实现技术。

　　4)安全性原则

　　服务器处理的大都是相关系统的核心数据，其上存放和运行着关键的交易和重要的数据。这些交易和数据对于拥有者来说是一笔重要的资产，他们的安全性就非常敏感。服务器的安全性与系统的整体安全性密不可分，如：网络系统的安全、数据加密、密码体制等。服务器需要在其自身，包括软硬件，都应该从安全的角度上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。

　　5)可管理性原则

　　服务器既是核心又是系统整体中的一个节点部分，就像网络系统需要进行管理维护一样，也需要对服务器进行有效的管理。这需要服务器的软硬件对标准的管理系统支持，尤其是其上的操作系统，也包括一些重要的系统部件。

　　实例解说数据库服务器选型

　　为了让大家对上述原则有更清晰的认识，下面我们以金保工程某省级数据中心交换区数据层服务器为例，来详细阐述其数据库服务器选型的方法。

　　省级数据中心交换区数据层服务器中作为社会保险关系异地转移、离退休人员异地数据交换和异地就医数据交换的数据库服务器，支持在职人员社会保险关系跨市转移的信息交换，以及异地领取养老金相关信息(如人员的基本状况、支付标准、生存状况等)的交换，同时保存死亡信息和公共服务信息、临时缓存宏观决策上报数据和基金监管信息。考虑其作为中央、省、市三级数据中心信息交换的枢纽，所支撑应用的关键性，应采用高端服务器系统，具体配置要求如下：

　　1)服务器处理能力

　　为支持本省的异地转移、异地就医和异地领取养老金等业务，需要较高的交易数据处理能力。TPC计算如下：

　　假设全省参保总人数C=980万，交易日平均交易人数比例a1=1‰，每笔交易对应数据库事务数a2=5，则： 每日实际交易量M= C×a1×a2;交易日集中交易时间T=120分钟;交易日集中期内交易量比例Ct=80%;基准TPC指标值对应实际交易值的比例M0=6:1;CPU处理能力余量M1=30%-45%，取35%;3年内每年处理能力增长率P=30%。

　　根据经验公式计算得出TPC=(M×M0×Ct/(T×(1-M1)) ×(1+30%)3=89,435。也就是说，服务器选型应该考虑采用TPC值不低于100,000的高端服务器系统配置。

　　2)内存容量

　　根据经验和类似业务量和环境，内存容量应为1G/CPU×CPU数，从目前主流硬件厂商的指标来看，TPC值要达到100，000，一般需要配置8个CPU，因此内存建议配置8GB。

　　3)总线I/O带宽

　　在高CPU、大容量内存的配置下，必须要求主机系统总线带宽、I/O总线带宽都达到很高，否则，系统性能将形成瓶颈。

　　4)存储容量

　　交换区平均数据量为164.8GB，峰值数据量为164.8GB×1.5，考虑0.2倍的数据库索引和系统占用空间;作RAID保护后60%存储利用率;以后数据增长，需提供30%的数据扩充能力等因素，总存储容量约为：164.8×1.5×1.2/60%/70%=706GB，采用SAN中的光纤通道阵列作为数据存储。

　　5)可靠性、扩展性等

　　由于作为生产型数据库服务器，支持异地经办业务，属于实时性服务，该服务器系统在可靠性方面要求较高，可靠性必须达到99.99%以上，提供全年7×24的可用性，配置为双机集群方式。系统采用多部件的冗余结构设计，具有高速差错校验和纠错的存储器，并有监控和诊断功能。

　　因此，对于服务器的选型，首先需对其业务系统的业务类型、业务复杂度等方面做系统的需求分析，其后根据需求在数据容量、数据处理的强度等方面进行估算，并兼顾服务器的可靠性、扩展性、安全性、可管理性等方面综合考虑，完成最终的产品选型。

----------------------

在大型网站不仅在信息量上非常大，而且对交互性的要求也非常高。在与用户的交互过程中，使用最多的就是查询，数据库服务器需求根据用户的需求进行查询，然后将结果返回给用户。如果查询请求非常多，如大量用户同时使用查询的时候，如果服务器的处理能力不够强，无法处理大量的查询请求作出应答，服务器就可能会出现反应缓慢甘于宕机的情况。所以数据库服务器对处理器的性能要求是比较高的。对于流量不大的网站来说，需要的并行操作不是特别多，好采用单颗处理器的数据库服务器也是可以满足的，但对于需要处理大量用户交互信息的大型网站来说，数据库服务器通常需要采用双路甚至多路处理器，确保用户在进行查询时反应迅速，能够稳定的运行。

在扩展性方面，数据库服务器也有较高的要求，由于需要处理大量的用户请求，高速大容量内存可以有效的节省处理器访问硬盘的时间，提高服务器的性能，进而提高需求的响应速度。在存储方面，由于数据库服务器通常存储的都是整个网站的信息，因此硬盘不能出现任何一点差错，如果硬盘出现故障，轻则网站部分功能不能用，重则整个网站将会陷入瘫痪，另外在与用户的交互过程中，需要对硬盘进行频繁的读写操作，因此也要求硬盘具备快速的反应能力。归结这两点要求，数据库服务器最好采用10000或15000转的SAS硬盘或SCSI硬盘等。为了以防硬盘出现故障时能及时恢复，数据库服务器除了日常的备份操作之外，RAID阵列技术不仅能缩短对硬盘的访问时间，提高响应速度，同时还可以提高数据的安全性，因此，数据库服务器最好具备RAID 1/10/5/6等阵列功能。

数据库服务器上存储着整个网站的大量信息，基本上用户对网站的操作都会涉及到数据库，因此数据库服务器需求长时间稳定的运行。为了让服务器能够实现7X24X365不间断工作，服务器的软硬件都需求具备良好的稳定性能。当然，服务器能否稳定运行也不能只看软硬件，其他如应用环境、整体系统设计以及散热等都需要考虑。在选择的时候需要多方面考虑。

----------------------

目前主流的应用模式是采用2台服务器，一台为前端的Web服务器，另一台作为后台的数据库服务器，Web服务器可置于防火墙的DMZ区，而后台的数据库服务器则可置于防火墙保护中的内部网络。前端Web服务器承载实现Web应用的软件及中间件，数据库服务器主要承载后端的数据库应用，实现访问时的数据库调用。

Web服务器一般分为动态或静态两种。静态网页通常是指有文本和图片共同组合存储在服务器中，通常变化不大，使用两个CPU和一个千兆的网卡就可以非常轻松的满足极高的点击率。当使用双路处理器的服务器时，可以完全满足每秒钟千次的点击。对于大规模网站也可以使用四路处理器并额外添加内存与网卡。 

Web动态服务器通过存储在服务器中的网页可以构建网络空间，例如使用ASP.NET, JSP, PHP 等。与静态网页相比，这种应用需要更高的CPU处理能力，高速的网络通讯能力也是必不可少的。 

Apache、IIS（2012年推荐配置）
塔式：
1-400个用户/分钟 HP ProLiant ML350 
400-1000个用户/分钟 HP ProLiant ML370 
机架式：
1-400个用户/分钟 HP ProLiant DL360 
400-1000个用户/分钟 HP ProLiant DL385 
刀片式：
1-400个用户/分钟 HP ProLiant BL465c 
400-1000个用户/分钟 HP ProLiant BL465c

----------------------

国外大型IT网站的成功之道  
MySpace  
    今天，MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素，但是本节中我们却抛弃这一点，而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。  
第一代架构—添置更多的Web服务器(可行)  
    MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。

第二代架构—增加数据库服务器（按功能分割数据库；出故障后很麻烦）  
    与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下让多个数据库分担压力。

    MySpace运行在三个SQL Server数据库服务器上—一个为主，所有的新数据都向它提交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。

    这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（存储区域网络）—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策略也变得难以维持下去。

第三代架构—转到分布式计算架构（按用户分割数据库；不利于统计分析）  
    几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。

    既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。

第四代架构—求助于微软方案（软硬件提升，可行）  
    2005年早期，账户达到九百万，MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET。  
    账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。

第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 2005  
    2005年春天，MySpace账户达到一千七百万，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。

    2005年中期，服务账户数达到两千六百万时，MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。

    事实上，MySpace的Web服务器和数据库仍然经常发生超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨不停……

    MySpace正是在这样不断重构站点软件、数据库和存储系统中，才一步步走到今天。事实上，MySpace已经成功解决了很多系统扩展性问题，其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。

二、 国内大型网站开发时的几点建议  
    我们将结合国内外大型IT网站在技术扩展方面的沉痛教训和成功经验，探讨在如今刚刚开始的Web 2.0时代如何应对国内网站即将面临的数据访问量增加（甚至是急剧膨胀）的问题，并提出一些供参考的策略和建议。

(1) 搭建科学的系统架构  
    构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就，需要从严格的软件工程管理的角度进行认真规划，有步骤有逻辑地进行开发。对于大型网站来说，所采用的技术涉及面极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。以著名的Yahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。

(2) 页面静态化  
    可不要小看纯静态化的HTML页面！其实在很多情况下，HTML往往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网站上的页面采用静态页面来实现。但是，对于大量内容并且频繁更新的网站，我们无法全部手动实现，因此可以开发相应的自动化更新工具，例如我们常见的信息发布系统CMS。像我们经常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

(3) 存储问题  
    存储也是一个大问题，一种是小文件的存储，比如图片这类；另一种是大文件的存储，比如搜索引擎的索引。  
大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更高的系统消耗和执行效率。

(4) 数据库技术—集群和库表散列  
    对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访问的时候，数据库的瓶颈仍然会显现出来，这时一台数据库将很快无法满足应用，于是我们需要借助于数据库集群或者库表散列技术。

    在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQL Server等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案。因此，你使用了什么样的数据库，就参考相应的解决方案来实施即可。

    上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。在这一方面一个现成的例子就是搜狐。它的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

(5) 缓存策略  
    这绝对不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服务器、数据库服务器的各层级的缓冲策略，最后才是低级的缓冲技术的编程。不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面，SQL Serve 2005中的主动式缓存机制，Oracle数据的cache group技术，Hibernate的缓存包括Session的缓存和SessionFactory的缓存；Web服务器方面，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力，IIS缓冲器技术；至于web开发语言，所用缓存技术更存在很大不同，例如ASP.NET 2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pear的Cache模块，等等。

(6) 镜像  
    镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

(7) 负载均衡  
    负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年，基于LAMP解决方案的Lighttped+Squid是相当不错的解决负载均衡和加速系统的有效方式。

(8) 硬件四层交换  
    第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

    在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

(9) 软件四层交换  
    大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的。

    一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

(10) 软件投资问题  
    据报导，目前国内除了一些上市企业和特别大知名大公司以外，很少有企业在成本中考虑正版软件的购置费用。这种思维极有可能给中国互联网带来噩梦。如果一些公司真正面临软件资金方面的困难，完全可以考虑使用开源世界的LAMP解决方案（Linux＋Apache＋MySQL＋Perl、PHP或者Python Web编程语言）；否则，随着我国加入WTO范围的不断扩大，盗版打击必然越来越严。因此，“苟且偷生”必将自食其果。

1. Raid：充分发挥出多块硬盘的优势，实现远远超出任何一块单独硬盘的速度和吞吐量。提供良好的容错能力，目前经常使用的是 RAID5和RAID（0+1）。
2. SAN：应用数据块(Block)的数据库应用和大数据块(Block)的I/O操作则以SAN为优先。
3. NAS：对于文件级的服务有 着更高效和快速的性能。

扩展阅读：

1. SAN NAS Raid 的区别与应用
   
2.