数据库服务器选型分析
如何规划和选择数据库服务器rperf和TPCC
如何规划和选择数据库服务器rperf和TPC-C如何规划和选择数据库服务器?当一个新的业务系统开发完成后，需要在一个区域乃至全国推广此应用软件，如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽，是一件复杂的事情。
一个最真实的评估，是建立一个接近真实业务应用的操作环境，进行各种压力测试，测算出不同的用户数量下，系统的响应时间和吞吐量，并得出当时服务器的各种资源的利用率情况，对硬件资源的完整评估，需要考虑下列三个方面:服务器性能的评估客户端工作站或前端桌面的评估通讯网卡和网络带宽的评估如果不能建立准确的压力测试环境，需要根据工业界的Benchmark对服务器进行评估，推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗，对重要资源要考虑为将来留下升级和可扩展的余地，下列是一些通用的原则:处理器:要考虑高峰时的处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。
如果要保持快速的响应能力，应当为CPU保留20%至40%的富余量。
内存:要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。
磁盘:评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备(如磁带机)。
IO槽:尽量保留更多的IO槽，防止将来插更多的PCI卡。
网络:选择合适的网卡，保证网络不是系统的瓶颈。
在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。
理想情况下，应考虑下列要素:交易的复杂性交易率数据读/写比例并发连接数目并发交易数目数据库最大表的大小性能度量的目标根据各种Benchmark测试结果和对各种生产系统的检测，下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利用率，可看出一个服务器如果其利用率保持在Good 所标示的范围内时，是一种理想的模式。
数据库选型
SQL数据库选型指南SQL数据库选型指南选择一款合适的SQL数据库对于每一个IT主管来说都是一项艰巨的任务，因为他们可选的产品很多。
这既有好的一面也有不利的一面，选项增加意味着做出错误选择的概率也在增加。
DBA必须谨慎对比每家厂商技术的优缺点，通过衡量自身需求以便做出最佳选择。
为此，在本次的数据库技术手册中，我们将针对市场上的几款主流SQL数据库进行全方位的对比，并为读者提供如何进行需求分析方面的内容。
SQL数据库选型准备工作想要正常运行最繁重的客户服务器与Web应用，在后端你需要有一个SQL数据库。
对于大多数业务来说，部署一个数据库服务器的过程要经历许多的选择与考虑，而对许多IT 部门主管来说就像一场冒险的旅程。
他们要权衡每一家厂商的数据库有哪些功能，这些功能能否满足不同业务的差异化需求。
如何通过需求分析来选择SQL数据库SQL数据库选型：主流产品对比主流SQL数据库详细对比尽管价格因素是每个IT主管不得不考虑的因素，但是选型最终的考验，还是评估每个产品的特性与功能以及对部署所造成的影响。
SQL数据库选型：性能因素的影响深入探讨主流SQL数据库特性SQL数据库选型：优缺点对比选型之开源数据库诸如MySQL这样的开源数据库，目前越来越受到企业级用户的青睐，究其原因其实很简单：它们是免费的。
免费意味着没有购买成本，免费意味着没有复杂的许可需求，免费还意味着良好的扩展能力。
SQL数据库选型：开源数据库如何通过需求分析来选择SQL数据库在数据库世界里，SQL才是王道。
想要正常运行最繁重的客户服务器与Web应用，在后端你需要有一个SQL数据库。
对于大多数业务来说，部署一个数据库服务器的过程要经历许多的选择与考虑，而对许多IT 部门主管来说就像一场冒险的旅程。
他们要权衡每一家厂商的数据库有哪些功能，这些功能能否满足不同业务的差异化需求。
这的确是一项非常复杂的任务，现在的主流数据库已经给我们提供了品种繁多的功能与选项。
浅谈数据库服务器的选型
１ 硬 件 选 型
数据库服务 器的硬件选 型主要看 重 Ｃ Ｕ、 Ｐ 内存 、 总线 Ｉ ／ Ｏ带宽 、 硬 盘和网卡这几个参数 ｃｕ Ｐ —— Ｃ Ｕ和 内存 Ｃ Ｕ的类型 、主频和数量在相 当程度上决 Ｐ Ｐ 定着服务 器的性能 它与其他服务器 的不 同在于计算需求强 ． 浮点运 算和大规模数据库时数据交换频 率高等 当 Ｃ Ｕ选型不当时． Ｐ 往往会 造成瓶 颈 ． Ｃ Ｕ饱和 Ｐ 饱 和常常发生在数据库软件使用 的数据 即 Ｐ ＣＵ 能被装入 内存 ． 或者能够尽快根据需要从磁盘上读取 的时候 。因此在 进行数据库服务器 Ｃ Ｕ选择 时．一般可 以根据经验公式计算 出所需 Ｐ 的服务器 Ｔ ｍ 值 ． ｐ Ｃ 然后比较各服务器厂商和 Ｔ Ｃ组织公布 的 Ｔ ｍ Ｐ ｐＣ 值， 选择相应的机型 。同时 ， 用服务器的市场价， 报价除去计算 出来 的 Ｔ ｍＣ值得 出单位 Ｔ ｍＣ值的价格 ． ｐ ｐ 进而选择高性能价格比的服务器 （） １ 内存 数据库服务器 中． Ｐ Ｃ Ｕ读取数据时 ． 一般先从高速缓存 中索取 ， 如 果搜索到相关数据就可 以很快返回给 Ｃ Ｕ 且数据库应用往往还需要 Ｐ 多核处理器在互联上 以及 内存访问上拥有较 高的带 宽． 因为其数据吞 吐量大 ． 计算随机性 和突发性大 因此在数据库 服务器 的内存 应选择 大 内存的策略。
据库 系统软件为例 ， 对数据库服务 器的特点， 针 从服务 器的硬件、 操作 系统及数据库软件版本 三个方 面分析并 阐述 了对数据库服务器的选型。
【 关键词 】 ｓ ； ＭｙＱＬ数据库 ； 服务器 ； 选型 ０ 引 言
数据库服务器作 为业务 系统的核心 ． 具有 业务量大 、 存储数据量 大等特点 。它承担着业务数据 的存储和处理任 务 因此 数据库 服务器 的选型就显得尤为重要 。服务器 的可靠性和可用性是 首要 的需求 ． 其 次是数据处理能力和安全性 ， 然后是可扩展性和可管理性 。
数据库服务器选型原则及实例解说
数据库服务器选型原则及实例解说数据库服务器选型原则及实例解说数据库服务器作为业务系统的核心，具有业务量大、存储数据量大等特点。
它承担着业务数据的存储和处理任务，因此关键数据库服务器的选择就显得尤为重要。
服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。
根据应用类型和规模的不同，数据库对于服务器的性能要求也不一样。
如对于大型数据库(ERP, OLTP, data mart)来说，服务器往往仅用来运行数据库，或仅运行单一的应用。
数据库的容量在1TB以上，需要有较高的CPU处理能力，大容量内存为数据缓存服务，并需要很好的IO性能，使用这类应用时，通常需要有较高的CPU主频。
那么，具体到某个行业甚至某个项目，数据库服务器该如何选择呢?数据库服务器选型五个原则首先，数据库服务器选型应该遵循以下几个原则：1)高性能原则保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期的业务量增长的需要。
一般可以根据经验公式计算出所需的服务器TpmC值，然后比较各服务器厂商和TPC组织公布的TpmC值，选择相应的机型。
同时，用服务器的市场价/报价除去计算出来的TpmC值得出单位TpmC 值的价格，进而选择高性能价格比的服务器。
2)可靠性原则可靠性原则是所有选择设备和系统中首要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。
考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如：网络系统、安全系统、远程打印系统等。
在必要时，还应考虑对关键服务器采用集群技术，如：双机热备份或集群并行访问技术，甚至采用可能的完全容错机。
比如，要保证系统(硬件和操作系统)在99.98%的时间内都能够正常运作(包括维修时间)，则故障停机时间六个月不得超过0.5个小时。
服务器需7×24小时连续运行，因而要求其具有很高的安全可靠性。
数据库的选型
数据库的选型⽬录影响数据库选择的因素数据量：是否海量数据，单表数据量太⼤会考验数据库的性能数据结构：结构化 (每条记录的结构都⼀样) 还是⾮结构化的 (不同记录的结构可以不⼀样)是否宽表：⼀条记录是 10 个域，还是成百上千个域数据属性：是基本数据 (⽐如⽤户信息)、业务数据 (⽐如⽤户⾏为)、辅助数据 (⽐如⽇志)、缓存数据是否要求事务性：⼀个事务由多个操作组成，必须全部成功或全部回滚，不允许部分成功实时性：对写延迟，或读延迟有没有要求，⽐如有的业务允许写延迟⾼但要求读延迟低查询量：⽐如有的业务要求查询⼤量记录的少数列，有的要求查询少数记录的所有列排序要求：⽐如有的业务是针对时间序列操作的可靠性要求：对数据丢失的容忍度⼀致性要求：是否要求读到的⼀定是最新写⼊的数据对增删查改的要求：有的业务要能快速的对单条数据做增删查改 (⽐如⽤户信息)，有的要求批量导⼊，有的不需要修改删除单条记录(⽐如⽇志、⽤户⾏为)，有的要求检索少量数据 (⽐如⽇志)，有的要求快速读取⼤量数据 (⽐如展⽰报表)，有的要求⼤量读取并计算数据 (⽐如分析⽤户⾏为)是否需要⽀持多表操作不同的业务对数据库有不同的要求SQL 数据库 & NoSQL 数据库SQL 数据库就是传统的关系型数据库⾏列式表存储结构化数据需要预定义数据类型数据量和查询量都不⼤，如果数据量⼤要做分表对数据⼀致性、完整性约束、事务性、可靠性要求⽐较⾼⽀持多表 Join 操作⽀持多表间的完整性，要删除 A 表的某条数据，可能需要先删除 B 表的某些数据SQL 的增删改查功能强较为通⽤，技术⽐较成熟⼤数据量性能不⾜⾼并发性能不⾜⽆法应⽤于⾮结构化数据扩展困难常⽤的 SQL 数据库⽐如 Oracle、MySQL、PostgreSQL、SQLiteNoSQL 泛指⾮关系型数据库表结构较灵活，⽐如列存储，键值对存储，⽂档存储，图形存储⽀持⾮结构化数据有的不需要预定义数据类型，有的甚⾄不需要预定义表⽀持⼤数据量多数都⽀持分布式扩展性好基本查询能⼒，⾼并发能⼒⽐较强 (因为采⽤⾮结构化、分布式，并牺牲⼀致性、完整性、事务性等功能)对数据⼀致性要求⽐较低通常不⽀持事务性，或是有限⽀持通常不⽀持完整性，复杂业务场景⽀持较差通常不⽀持多表 Join，或是有限⽀持⾮ SQL 查询语⾔，或类 SQL 查询语⾔，但功能都⽐较弱，有的甚⾄不⽀持修改删除数据不是很通⽤，技术多样，市场变化⽐较⼤常⽤的 NoSQL 数据库⽐如列式：HBase、Cassandra、ClickHouse键值：Redis、Memcached⽂档：MongoDB时序：InfluxDB、Prometheus搜索：ElasticsearchSQL 和 NoSQL 是⼀个互补的关系，应⽤在不同的场景中OLTP & OLAPOLTP (On-Line Transaction Processing)主要做实时事务处理⽐如处理⽤户基本信息、处理订单合同、处理银⾏转账业务、企业的 ERP 系统和 OA 系统，等等频繁地，对少量数据，甚⾄是单条数据，做实时的增删改查数据库经常更新通常对规范化、实时性、稳定性、事务性、⼀致性、完整性等有要求操作较为固定，⽐如订单业务，可能永远就那⼏个固定的操作数据库主要模型是 3NF 或 BCNF 模型OLAP (On-Line Analytical Processing)数据仓库，主要做历史数据分析，为商业决策提供⽀持⽐如对⼤量的⽤户⾏为做分析，对设备的状态、使⽤率、性能做分析频率较低地，对⼤量数据，做读取、聚合、计算、分析，实时性要求不⾼，对吞吐能⼒要求较⾼通常列的数量⽐较多，但每次分析的时候只取少部分列的数据通常是批量导⼊数据通常数据导⼊后不会修改，主要是读取操作，写少读多通常对规范化、事务性、⼀致性、完整性等要求较低，甚⾄⼀个查询操作失败了也不会有什么影响操作较为灵活，⽐如⼀个海量⽤户⾏为数据表，可以想出许多不同的⽅法，从不同的⾓度对⽤户做分析数据库主要是星型、雪花模型不使⽤⾼性能的 OLAP 之前，更传统的做法是通过离线业务构建 T+1 的离线数据，⽐较滞后OLTP 通常⽤传统的关系数据库，如果数据量⼤要分表，对事务性、⼀致性、完整性等要求不⾼的话也可以⽤ NoSQLOLAP 通常⽤ NoSQL，数据量不⼤的话也可以⽤传统的关系数据库关系型数据库 Oracle、SQL Server、MySQL、PostgreSQL、SQLiteOracle：甲⾻⽂开发的商业数据库，不开源，⽀持所有主流平台，性能好，功能强，稳定性好，安全性好，⽀持⼤数据量，⽐较复杂，收费昂贵SQL Server：微软开发的商业数据库，只能在 Windows 运⾏MySQL：甲⾻⽂拥有的开源数据库，⽀持多种操作系统，体积⼩，功能弱些，简单的操作性能好，复杂的操作性能差些PostgreSQL：使⽤ BSD 协议的完全开源免费的项⽬，⽀持多种操作系统，功能更强⼤，可以和多种开源⼯具配合SQLite：开源、轻型、⽆服务器、零配置，⼀个数据库就只是⼀个⽂件，在应⽤程序内执⾏操作，占⽤资源⼩，可⽤于嵌⼊式或⼩型应⽤Oracle 多⽤于银⾏等⾼要求的领域，要求不⾼的⽐如互联⽹⾏业多⽤ MySQL 和 PostgreSQL，⽽ SQLite ⽤于嵌⼊式或作为应⽤程序内的数据库使⽤，SQL Server ⽤于 Window 服务器HBase (宽表、列式存储、键值对存储、NoSQL、OLTP)基于 Hadoop 的 HDFS 分布式⽂件系统分布式数据库，需要 ZooKeeper 作为节点间的协调器⽀持宽表，⽀持⾮结构化数据，不需要预定义列和数据类型列式存储，每个 HFile ⽂件只存储⼀个列族的数据，⼀个列族可以有多个 HFile，⽽ HFile 内部按 Key-Value 格式存储，其中 Key 是rowkey, column family, column, timestamp 的组合并且按 rowkey 在 HFile 中按序存储，⽽ value 就是 Column Cell 的值⽀持海量数据 (千亿级数据表)数据先写⼊内存，达到阀值再写⼊磁盘，性能好，占⽤内存⼤不⽀持 SQL，不⽀持 Join，有⾃⼰专⽤的语句，⽀持增删改查⾃动分区、负载均衡、可线性扩展⾃动故障迁移强⼀致性 (每个分区 Region 只由⼀个 Region Server 负责，容易实现强⼀致性)CP 模型 (不保证可⽤性，每个 Region 只由⼀个 Region Server 负责，Server 挂了得做迁移导致暂时不可⽤)不⽀持事务、⼆级索引组件⽐较多，⽐较重，适⽤于已有的 Hadoop 平台，适⽤于海量宽表数据、需要增删改查、OLTP 的场景Phoenix (基于 HBase 的数据库引擎、关系型、OLTP)嵌⼊到 HBase 的 Region Server 的数据库引擎⽀持 SQL⽀持 Join⽀持事务 (需要在定义表的时候配置)⽀持⼆级索引⽀持撒盐⽀持 JDBC⽤于强化 HBase，主要作为 OLTP，查询性能要求不⾼的话也可作为 OLAP，多⽤于 HDP (HDP 有集成 Phoenix)Cassandra (宽表、键值对存储、NoSQL、OLTP)⽆单点故障：Cassandra 节点按环形排列，没有中⼼节点，每个节点独⽴互联地扮演相同⾓⾊，每个节点都可以接受读写请求，数据可以有多个副本存储在多个节点，节点之间通过 Gossip (P2P) 协议交换状态信息，集群中有若⼲节点配为种⼦节点，⽤于新加⼊的节点获取集群拓扑结构并启动 Gossip 协议提供类 SQL 语⾔ CQL适合结构化、⾮结构化数据Table 需要定义 Partition Key、Clustering Key、以及普通列，其中 Partition Key ⽤于分区和排序，即按照 Partition Key 的 Hash Token 决定了数据被分配到哪个节点，并且在节点内也是按该 Hash Token 按序存储的，有相同 Partition Key 的数据会存在⼀起，并且按照 Clustering Key 排序存储，有点类似于 HBase 的 RowKey、ColumnFamily、Column，不过 HBase 是相同 CF 存⼀起，内部再按 RowKey 排序存储，再取 Column 值 (Column 值不排序)，⽽ Cassandra 是先按 Partition Key 的 Token 排序存储，内部再按Clustering 排序存储，再取普通 Column 的值 (Column 值不排序)⾼度可扩展，允许添加硬件、节点以提⾼数据容量，同时保持快速的响应时间通过 Consistency 命令可以配置⼀致性级别，主要是通知客户端操作前，必须确保的 replica 的成功数量Cassandra 采⽤的是最终⼀致性，是 CAP 理论⾥的 APCassandra 不⽀持 Join 和⼦查询主要⽤于 OLTP，要求不⾼的话也可以作为 OLAP 使⽤，和 HBase ⽐需要的组件⽐较少，维护⽐较容易Redis (基于内存的 Key-Value 的 NoSQL 数据库，OLTP)由 C 语⾔编写⽀持多种数据类型如 strings，hashes，lists，sets，sorted sets，bitmaps，hyperloglogs，geospatial 等操作原⼦性，保证了两个客户端同时访问服务器将获得更新后的值数据存储在内存中可以配置持久化，周期性的把更新数据写⼊磁盘，或周期性地把修改操作写⼊追加记录⽂件，也可以关闭持久化功能，将 Redis 作为⼀个⾼效的⽹络缓存数据功能使⽤⽀持主从同步，数据可以从主服务器向任意数量的从服务器同步，从服务器可以是关联其他从服务器的主服务器，这使得 Redis 可执⾏单层树复制，存盘可以有意⽆意的对数据进⾏写操作，由于完全实现了发布/订阅机制，使得从数据库在任何地⽅同步树时，可订阅⼀个频道并接收主服务器完整的消息发布记录，同步对读取操作的可扩展性和数据冗余很有帮助⽀持消息的发布/订阅（Pub/Sub）模式单线程模式，即⽹络 IO、数据读写，都由⼀个线程完成，正因为如此保证了原⼦性、稳定性、代码容易维护，之所以单线程不影响性能，是因为数据都在内存，操作本来就⾼效，当然这⾥的单线程指⽹络 IO、数据读写这个主功能，实际上还有其他线程，⽐如周期性写⼊硬盘的线程⾼版本在⽹络 IO 这块使⽤了多线程 (因为在⾼并发操作时，⽹络 IO 成为了瓶颈)，但读写操作还是单线程 (操作内存数据性能还是⾮常⾼的，能应付⾼并发场景)通常作为⾼性能内存数据库、缓存、消息中间件等使⽤memcached (基于内存的 Key-Value 的 NoSQL 数据库，OLTP)开源、⾼性能、分布式的基于内存的 Key-Value 数据存储，作⽤类似于 Redis存储 String/RawData，不定义数据结构 (Redis 有 hash、list、set 等多种结构)数据通常由 key，flags，expire time，bytes，value 组成服务端基本上只能简单的读写数据，服务端能⽀持的操作⽐较少包含 Server 组件和 Client 组件，可以有多个 server 但 server 之间是独⽴的，没有同步⼴播等机制，需要选择哪个 server 由 client 的API 决定的数据只在内存，不会落到硬盘没有安全机制协议简单性能⾼效memcached ⽐较简单，作为纯粹的 Key-Value 缓存性能会⽐ Redis 好些，但功能没有 Redis 强⼤MongoDB (⽂档数据库，NoSQL，OLTP)之所以说是⽂档数据库，是因为它的数据是以 JSON ⽂档的形式存储MongoDB 的概念和很多数据库不⼀样，它的 collection 相当于表，document 相当于⾏，field 相当于列⽐如er.insert({"name": "Lin","age": 30"address": {"street": "Zhongshan Road","city": "Guangzhou","zip": 510000},"hobbies": ["surfing", "coding"]})这是⼀条插⼊语句，这⾥的 db 是指当前数据库，user 就是 collection 相当于表，insert 语句⾥⾯的 JSON 就是 document 相当于其他数据库的⾏，name，age，street 这些就是 field 相当于列相同的⽂档可以插⼊多次⽽不会被覆盖，实际上 mongodb 会⾃动创建 _id 字段作为 primary key，并分配不同的数值，所以不会重复，也可以 insert 的时候指定 _id，但如果 _id 已经存在则会报错可以看到，mongodb 是⾮结构化数据，不需要预定义 collection，也不需要预定义数据结构提供丰富的查询表达式⽀持⼆级索引，⾃动负载平衡，读效率⽐写⾼⽀持分布式、⽀持故障恢复、数据冗余、分⽚、⽔平扩展可以配置存储引擎，WiredTiger Storage Engine (默认) 会做内存到⽂件的映射以提⾼性能，但内存消耗⼤，In-Memory Storage Engine (企业版⽀持) 只存在内存，不会落盘⾼版本⽀持 Join，⽀持事务⽀持安全认证功能提供扩展，⽐如实现可视化的⼯具，实现 BI 集成的⼯具mongodb 更适⽤于⾼度⾮结构化，或者源数据就是 JSON，每条数据⽐较⼤，以 OLTP 为主的场景，不适合于事务要求⽐较⾼，或⽐较复杂的⼤数据量的查询的场景，另外由于 mongodb 的语法和其他数据库差异⽐较⼤，需要⼀定的学习成本Hive (基于 HDFS 的数据库引擎、关系型、OLAP)Hive 是基于 Hadoop 的⼀个数据仓库⼯具数据存储在 HDFS，创建表的时候要通过 STORED AS 命令指定存储格式⽐如 TEXTFILE、ORCFILE、PARQUET，也可以通过STORED BY 命令指定为 HBase，可以创建新表也可以创建已有 HBase 表的映射查询通过 MapReduce、Spark 等作业完成提供了类 SQL 查询语⾔ HQL (HiveQL)，⽀持⽤户定义函数 (UDF)⾼版本⽀持事务 (需要创建表时指定)⽀持海量数据结构化数据⽀持增删改查不适合于 OLTP，主要作为 OLAP ⽤于⼤数据批量查询使⽤，需要有 Hadoop 平台Impala (基于 HDFS、HBase、Kudu 存储，并⾏计算，关系型，OLAP)Cloudera 开发的基于内存的分布式并⾏计算的数据库查询引擎主要由 C++ 实现，和 Hadoop 的交互使⽤ JNIImpala 使⽤和 Hive ⼀样的 metadata、SQL、ODBC driver、UI，这样在提⾼了 HDFS 的 SQL 查询性能的同时，⼜提供了相似的⽤户使⽤体验和 Hive ⼀样可以通过 STORED AS 指定 HDFS 的存储格式⽐如 TEXTFILE、ORCFILE、PARQUET通过 Hive 操作的表，需要⼿动同步到 ImpalaImpala 不仅 SQL 和 Hive ⼀样，实际上元数据也存在 Hive 中表数据除了 HDFS，也可以存储到 HBase，但需要在 HBase 建表，然后在 Hive 通过 STORED BY 建⽴映射表，由于 Impala 和 Hive 使⽤⼀样的 metadata，在 Hive 建好表后，只要在 Impala 执⾏刷新命令 INVALIDATE METADATA，就可以看到对应的 HBase 表⽀持 Join、Aggregate 等功能⽀持 JDBC、ODBC和 Hive 不同，Impala 不依赖于 MapReduce，⽽是在每个 HDFS DataNode 上运⾏⾃⼰的引擎实现并⾏处理Impala 的并⾏处理引擎主要由 state store、catalog service、多个 impala daemon 组成每个 impala daemon 都可以接收 client 的请求，impala daemon 由 query planner、query coordinator、query executor 组成，planner 接收 client 的 SQL 查询，然后分解为多个⼦查询，由 coordinator 将⼦查询分发到各个 daemon 的 executor 执⾏，daemon 获取HDFS、HBase 数据、计算、然后返回给 coordinator，然后由 coordinator 聚合后将最终结果返回给 clientImpala 是⽆中⼼结构，每个 daemon 都可以接受连接查询，可以通过 HA Proxy 实现多个 daemon 的负载均衡state store ⽤于收集监控各个 daemon 的状态catalog service 将 SQL 做出的元数据变化通知给集群中所有的 impala daemonImpala 的计算都在内存进⾏，对内存要求⽐较⾼Impala 在 2.8 以后才⽀持 update 操作，但是只限于 Kudu 存储，需要安装 Kudu，并通过 STORED AS 指定 Kudu 作为数据库的存储，Kudu 是 Cloudera 开发的列式存储管理器，⽬的是做 OLAP，并且平衡 HDFS 和 HBase 的性能，Kude 的随机读写性能⽐HDFS（⽐如 Parquet）好，但是⽐ HBase 差，⽽⼤数据量查询性能⽐ HDFS（⽐如 Parquet）差，但⽐ HBase 好，Kude 和 Impala ⾼度集成，也可以和 MapReduce/Spark 集成，⽤ Kudu 替换 HDFS/HBase 这样 Impala 就可以做 update，兼顾 OLAP 和改数据的需求，适合于以 OLAP 为主⼜有⼀定的 Update 需求的场景，Kudu 可以配置⼀致性，采⽤结构化表数据模型，需要定义主键，不使⽤HDFS ⽽是有⾃⼰的组件存储和管理数据, 采⽤ c++ 没有 full gc 风险Impala 不适合于 OLTP，主要作为 OLAP ⽤于⼤数据批量查询使⽤需要有 Hadoop 平台和 Hive性能⽐ Hive 好很多作为 OLAP 的性能⽐ Phoenix 之类的好主要是 CDH 在推，CDH 有集成 ImpalaPresto (基于多种数据源，并⾏计算，关系型，OLAP)Facebook 推出的基于内存的分布式并⾏计算的数据库查询引擎由 coordinator server、discovery server (通常集成在 coordinator ⾥，也可以独⽴)、多个 worker server 组成coordinator 负责与 client 交互，负责管理 worker，负责解析 statement、规划 query、创建⼀系列的 stage、再转换成⼀系列的 task 分发到不同 worker 并发执⾏worker 负责执⾏ task 和处理数据，会通过 connector 获取数据，和其他 worker 交互中间数据，最终结果会由 coordinator 返回给clientconnector 是适配器，使得 Presto 可以访问不同的数据库内建的 connector 主要是 Hive，此外有很多三⽅开发的 connector ⽐如 cassandra、es、kafka、kudu、redis、mysql、postgresql 等等需要在配置⽂件配置 catalog，这⾥ catalog 维护 schema 并通过 connector 指向⼀个数据源，定位 presto 表都是从 catalog 开始的，⽐如 hive.test_data.test 指的是 hive catalog 下的 test_data schema 下⾯的 test 表，⽽ schema 的概念则依赖于具体的 connector，⽐如对于 mysql ⽽⾔，presto 的 schema 就是 mysql 的 schema，⽽对于 cassandra ⽽⾔，presto 的 schema 就是 cassandra 的keyspace，可以建⽴多个 catalog 关联同⼀个 connector ⽐如环境⾥有多个 kafka 集群那可以有 kafka1 和 kafka2 两个 catalog statement 可以认为就是 presto 收到的 sql 语句，然后会解析成 query plan，然后 query ⼜被分为多个 stages，这些 stages 组成⼀个树的结构，每个 stage 会聚合计算它下⾯的其他 stages 的结果，每个 stage ⼜分为⼀个或多个 tasks，这些 task 会分发到不同的worker 并⾏执⾏，每个 task 处理不同的数据分⽚，每个 task ⼜有⼀个或多个 driver 并发处理数据Presto ⽀持 JDBC 接⼝，JDBC 的 URL 格式为 jdbc:presto://host:port/catalog/schema 或 jdbc:presto://host:port/catalog 或jdbc:presto://host:port⽀持 Join 查询，并且⽀持多数据源的 join 查询 (多张⼤表的 join 可能会影响性能)，跨数据源查询的时候需要指定完整的表名即[catalog].[schema].[table]，并且使⽤ presto://host:port 连接 JDBC，不指定 catalog 和 schema有限⽀持⼦查询不⽀持 update 操作⽀持安全机制⽀持标准的 ANSI SQL扩展性好可以和 Tableau 集成⽀持 Spark适合有多种数据源的⼤数据量的 OLAP 查询性能和 Impala 可能差不多，但⽀持多种数据源，不依赖 HadoopGreenplum (基于多个 PostgreSQL，并⾏计算，关系型，OLAP)基于多个 PostgreSQL 的分布式并⾏计算的数据库查询引擎内部的 PostgreSQL 有做改动以适应并⾏分布式计算主要由⼀个 master、多个 segments、⼀个 interconnect 组成master 维护元数据，接收并认证 client 的链接，接收 SQL 请求，解析 SQL，⽣成 query plan，并将任务分发到 segments，协调聚合segments 的返回结果，并将最终结果返回给 client，可以设置 master 为主从配置每个 segment 有个独⽴的 PostgreSQL 数据库，每个 segment 负责存储部分数据，并执⾏相应的查询计算，segment 也可以配置备份机制Interconnect 是 Greenplum 的⽹络层，负责 master 和 segment 的链接，以及各个 segment 之间的链接链接和 SQL 语法都和 PostgreSQL 兼容，⽀持 JDBC、ODBC创建表时可以指定是⽤列存储、⾏存储、外部表 (数据在其他系统⽐如 HDFS ⽽ GP 只存储元数据)操作外部数据，需要安装 PXF (Platform Extension Framework)，有了 PXF 可以⽀持 Hive、HBase、Parquet、S3、MySQL、ORACLE 等等⽀持安全、权限配置⽀持分布式事务，⽀持 ACID，保证数据的强⼀致性，不是使⽤锁，⽽是使⽤ MVCC (Multi-Version Concurrency Control) 来保证数据⼀致性shared-nothing 架构和 Impala、Presto 类似都是并⾏内存计算，但 Greenplum 性能可能稍差⼀点点，并且 Greenplum 还分开源版和商业版，有的功能只有商业版才⽀持Kylin (基于 Hive、HBase，并⾏计算，关系型，多维度、预计算 OLAP)传统 OLAP 根据数据存储⽅式的不同分为 ROLAP（Relational OLAP）以及 MOLAP（Multi-Dimension OLAP），ROLAP 以关系模型的⽅式存储数据，优点在于体积⼩，查询⽅式灵活，缺点是每次查询都需要对数据进⾏聚合计算，⽽ Kylin 属于 MOLAPKylin 将数据按维度的不同组合，提前计算好结果，形成 Cube (⽴⽅体) 结构，这样查询速度快，缺点是数据量不容易控制，N 个维度可以有 2**N 种组合，可能会出现维度爆炸的问题，⽽且数据有改动的话需要重新计算⽐如有 Phone 和 Country 两张维度表，以及 Sale 事实表 (明细表)，取⼿机品牌、国家、⽇期作为三个维度，有 (null)、(品牌)、(国家)、(⽇期)、(品牌、国家)、(品牌、⽇期)、(国家、⽇期)、(品牌、国家、⽇期) 共 8 种组合，可以提前计算好这 8 种 group by 组合的 sale 的各种汇总信息 (sum、count 等)，⼀个维度组合的⼀个汇总信息称为⼀个 cuboid，所有的 cuboid 合起来就被称为⼀个 CubeKylin 的数据源可以是 Hive 或 Kafka (Json 格式消息，key 就是列名)Kylin 的预计算结果存到 HBase，RowKey 就是各种维度的组合，相应的明细汇总存在 Column 中，这样 SQL 就变成对 RowKey 的扫描，并进⼀步的对 Column 计算 (如果需要的话)，这样查询性能⾃然就提升了，可以⽀持亚秒级查询Kylin ⽀持 ODBC，JDBC，RESTful API 等接⼝Kylin 可以和 Tableau、PowerBI 等 BI ⼯具集成使⽤步骤如下创建 Project同步 Hive 表或 Kafka 表创建 Data Model创建并命名 Model选择 Fact Table (事实表) 和 Lookup Table (查找表，主要是维度信息)，以及 Join 字段从 Fact Table 和 Lookup Table 中挑选维度列 (可以被 Cube 做 group by)从 Fact Table 选择指标列 (可以被 Cube 做 aggregation)从 Fact Table 选择⽤于⽇期分区的列，不需要就留空添加 Filter (可以被 Cube ⽤来做 Where 操作)创建 Cube创建并命名 Cube，并选择要关联的 Data Model添加维度列 (必须从 Data Model 配置的维度列中选择)添加指标列 (必须从 Data Model 配置的指标列中选择)共有 8 种 aggregation 操作可以配置给指标列：SUM, MAX, MIN, COUNT, COUNT_DISTINCT, TOP_N,EXTENDED_COLUMN and PERCENTILE (如果要查 avg 实际上就是⽤ sum 除以 count 得出，所以这⾥不需要配置 avg 等可以通过预计算结果进⼀步计算出的操作)build Cube，实际是通过 MapReduce/Spark 计算，任务完成后结果会写⼊ HBasebuild 成功后即可直接⽤ SQL 查询了，实际是根据维度查 RowKey，然后把 Column 存的聚合结果取出，如果必要的话再做进⼀步计算如果数据源有改动，需要重新 build Cube可以看到 Kylin 是⼀个纯粹的 OLAP ⼯具，通过预计算提升查询性能，但⽆法及时反应出数据源的改变，预计算可能很耗时并且可能会占⽤⼤量空间，且需要和 Hadoop 集成基于预计算的 OLAP 数据查询引擎还有 DruidClickHouse (列存储，向量化计算，并⾏计算，OLAP)俄罗斯企业 Yandex 开发的 OLAP 数据库列存储对于 OLAP 的好处由于 OLAP 经常是在⼤量数据列中检索少量列，如果采⽤⾏存储，意味着要逐⾏扫描，并且每⾏都很⼤，⽽采⽤列存储只需要扫描要检索的列，能减少 IO假设有的记录并没有存储要检索的列，⾏存储依然要扫描该记录才知道，⽽对于列存储则不存在这样的问题，因为没存储，⾃热⽽然就不会扫描到因为同⼀列的数据类型、⼤⼩⽐较⼀致，列存储更容易压缩，效率更⾼，进⼀步减少 IOIO 的减少还意味着有更多数据可以被缓存到内存向量化计算SIMD (Single Instruction，Multiple Data，单指令流多数据流)，现在的 CPU ⽀持这样的功能，通过⼀条指令即可利⽤多核对⼀组数据 (也就是向量) 进⾏ CPU 层⾯的并发计算，适⽤于纯基础计算的场景，如果有判断、跳转、分⽀的场景则不合适ClickHouse 有⼀个向量计算引擎，尽可能地使⽤ SMID 指令，批量并⾏地处理数据，⼤⼤提升了处理能⼒主要由 C++ 实现⽆中⼼化结构，由⼀个集群的 server 组成，并且每个 server 都可以接受客户端的链接查询，server 收到请求后会和其他 server 协调做并⾏计算，每个 server 都是多线程的，server 之间通过 ZooKeeper 协调同步⽀持分⽚（shard），数据可以跨节点存储在不同分⽚中，⼀个分⽚就是⼀个节点，或者多个节点组成⼀个有副本备份的分⽚，由配置⽂件配置⽀持分区，通过 Partition By 命令创建表分⽚和分区有时候不好区分，分⽚更多指的是表的数据分布在不同节点，⽽且⼀个节点可以存储多个数据库、多个表的数据，⽽分区更多指的是按某列数据将⼀个⼤表分成多个⼩表，⽐如按⽇期列分区，每天⼀个分区表，既可以查分区表，也可以查⼤表⽀持副本备份、⽀持数据完整性表引擎（Table Engine）创建表的时候要通过 Engine 命令指定要⽤的表引擎，决定如何存储数据最常⽤的是 MergeTree 系列引擎，⽐如ENGINE = MergeTree()ENGINE = AggregatingMergeTree()⽐较轻量级的 Log 系列引擎ENGINE = Log;ENGINE = TinyLog;允许从其他数据源查询，⽐如ENGINE = ODBC(connection_settings, external_database, external_table)ENGINE = JDBC(dbms_uri, external_database, external_table)ENGINE = MySQL('host:port', 'database', 'table', 'user', 'password')ENGINE = PostgreSQL('host:port', 'database', 'table', 'user', 'password')ENGINE = MongoDB(host:port, database, collection, user, password)ENGINE = HDFS(URI, format)ENGINE = Kafka() SETTINGS kafka_broker_list = 'host:port', kafka_topic_list = 'topic1'特殊类型，⽐如ENGINE = Memory 数据存在内存分布式在某个 server 创建的表只是该 server 的本地表，不是分布式的，如果要创建分布式表，需要在每个 server 创建相同名字的表，再在其中⼀台 server 上创建分布式表（会⾃动在所有 server 上都创建），这个分布式表是个逻辑表，不真正存储数据，⽽是映射到各个 server 的本地表，会⾃动做并⾏计算ENGINE = Distributed(cluster_name, database, table, [sharding_key])cluster_name 是在配置⽂件⾥配置的通常使⽤ MergeTree 存储，数据可以快速地按序 append 到⼀颗 MergeTree 的后⾯，后台会做合并和压缩操作，这样提升了数据插⼊的性能主索引，数据按 Primary Key 排序也可以在创建表时通过 Order By 指定排序的字段⽀持⼆级索引，也叫跳数索引 data skipping index，⽐如 minmax 索引，会统计每⼀段数据内某列数据（或是某个表达式）的最⼤值和最⼩值，检索的时候可以依据 minmax 决定是否跳过这段数据（感觉⽐较怪，性能应该⽐重建⼀张索引表的做法要差吧）⽀持 TTL，包括列级别、⾏级别、分区级别的 TTL⽀持 HTTP、TCP 接⼝⽀持 JDBC、ODBC有三⽅⼯具⽀持将其他数据库如 PG 的数据导⼊ ClickHouse有三⽅⼯具⽀持和⼀些可视化⼯具如 Grafana、DBeaver、Tabix 集成有三⽅⼯具⽀持 Kafka、Flink、Spark 等⽀持 SQL，⽀持 group by、order by、join、部分⼦查询等功能⽀持 array、json、tuple、set 等复杂数据类型⽀持近似计算，⽐如计算平均值，可以取部分数据计算，这样提升了性能，但降低了准度⾃适应 Join 算法，⽐如优先使⽤ Hash-Join，如果有多张⼤表则⾃动改⽤ Merge-Join安全机制、基于 Role 的权限控制⽀持错误恢复、扩展性好不⾜的地⽅对⾼并发的⽀持不⾜没有成熟的事务功能修改、删除数据的性能⽐较差，并且仅提供有限⽀持Primary Key 是采⽤稀疏索引，即索引只能指向⼀段数据，具体的数据还得⼀条条查，所以如果是查少量数据，或者查询单条数据，性能会⽐较差不依赖 Hadoop、列存储、向量化、并⾏、多线程、多存储引擎单表查询性能极好，⽐ Impala、Presto 之类的要好很多多表查询性能差些，⽐ Impala、Presto 之类的要差Elasticsearch (倒索引、分词、搜索引擎)Elastic Stack 是⼀组组件包括 Elasticsearch、Logstash、Filebeat、Kibana 等Elasticsearch 是基于 Apache Lucene 开发的搜索引擎，主要由 Java 开发Elasticsearch 集群主要由 master、data、ingest、coordinating 节点组成每个节点可以同时配置多种⾓⾊，⽐如即是 master ⼜是 data，但在⼤型集群中，通常每个节点只负担⼀种功能coordinating 是每个节点都会有的功能，不需要配置，即⽆论 master 还是 data 都会有 coordinating 功能，⽤于接收 client 的读写请求，然后将请求转发给相应节点处理，然后将处理结果合并后返回给 client，在⼤型集群中为了不对 master/data 等节点造成太⼤压⼒，可以配置多个专门的 coordinating，通过将 role 配置为空或是将 master、data、ingest 设置为 false (取决于不同版本) 即可，这样这些 coordinating 节点就只负责接收响应 client 请求不做其他⼯作，就像是⼀个反向代理的负载均衡⼀样，能提⾼并发性能master 负责管理整个集群，负责对 index 的创建删除等管理操作，决定数据要分⽚到哪个节点，管理其他节点的状态等等，可以配置多个 master 做 HA，需要单数个，⾄少要 3 个，系统实际上⾃动选举其中⼀个做 master，如果该 master 挂了，会从其他配置为master 的节点中重新选举⼀个，master 的配置可以低⼀些data 负责存储、计算、处理数据，对资源要求⽐较⾼，data 还可以进⼀步配置，指定节点⽤于存储 hot data、warm data、cold data 等等。
数据库服务器性能计算需求分析
数据库服务器性能计算需求分析1.数据量估算：首先需要估算数据库的数据量。
通常使用的指标是数据库的大小、记录数和表的数量等。
通过对现有数据量和未来增长率的分析，可以预测数据库的数据量，并根据数据量来确定服务器的存储容量。
2.访问模式分析：数据库的访问模式会对性能产生重要影响。
访问模式涉及到读写比例、并发访问数和事务处理等。
通过分析这些访问模式，可以确定需要的处理能力和性能需求。
例如，读取密集型的应用程序可能需要更多的内存和高速缓存，而写入密集型的应用程序则可能需要更多的处理器资源。
3.响应时间要求：根据业务需求确定数据库的响应时间要求。
根据不同的业务场景，可在服务级别协议（SLA）中定义响应时间目标。
通过分析响应时间要求，可以确定所需的硬件和软件资源。
例如，较短的响应时间要求可能需要更高的处理能力和更低的延迟。
4.数据处理需求：数据库服务器的性能还与数据处理需求有关。
一些数据库操作，如表连接、索引操作等，对处理能力有较高的要求。
通过分析具体的数据处理需求，可以确定需要的处理能力和存储需求。
5.可用性和容错性要求：根据业务需求确定数据库的可用性和容错性要求。
可用性指系统在一定时间内处于可操作状态的能力，容错性指系统对组件故障的容忍能力。
通过分析可用性和容错性要求，可以确定需要的硬件和软件资源。
例如，需要具备高可用性和容错性的数据库服务器可能需要使用冗余硬件和软件配置。
通过以上需求分析，可以得到数据库服务器的性能需求概况，进而根据具体的性能指标，如并发连接数、每秒事务数、吞吐量等，来计算数据库服务器所需的硬件和软件资源。
总之，数据库服务器的性能计算需求分析是一个综合考虑数据库数据量、访问模式、响应时间要求、数据处理需求和可用性容错性等因素的过程，通过分析这些需求，可以得到服务器的性能需求概况，并进一步确定所需的硬件和软件资源配置。
怎样使用TPC-C进行服务器的评估
.1、如何使用TPC-C进行服务器的评估由上可知，TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值（Transaction Per Minute，即每分钟处理的交易比数）。
TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。
因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。
以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求：TPM=TASK x 80% x S x F / (T x C)其中：TASK：为每日业务统计峰值交易量T：为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成：T=240。
S：为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。
由于实际的金融业务交易的复杂程度与TPC-C标准测试中的交易存在较大的差异，须设定一个合理的对应值。
以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多；根据科学的统计结果，每笔交易操作相比较于TPC 标准测试中的每笔交易的复杂度此值可设定为10~20。
C：为主机CPU处理余量。
实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。
因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。
F：为系统未来3~5年的业务量发展冗余预留。
综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。
数据库技术选型的原则与技巧
数据库技术选型的原则与技巧在现代信息技术的高速发展中，数据库技术成为了企业信息化建设不可缺少的一部分。
而在选型过程中，负责技术选型的人员需要考虑到各种不同的因素，如性能、安全性、可用性、成本等因素。
本文将从数据库技术选型的基本原则、常见的数据库架构以及不同类型数据库的适用场景等方面进行探讨，希望能够帮助读者更好地理解数据库技术选型并能够更加准确地选择适合企业的数据库技术。
一、数据库技术选型的基本原则在数据库技术选型的过程中，需要考虑多个方面的因素。
以下是一些基本原则：1.数据库技术必须符合企业的业务需求技术与业务的关系不可忽视。
如果技术选型不符合企业的业务需求，则数据库无论如何优秀，也无法带来更多的价值。
因此，首要的任务是了解企业的业务需求，以便选择适合的数据库技术。
例如，如果企业需要处理复杂的数据分析任务，则需要选择支持复杂查询和分析的数据库。
2.数据库技术必须具有高可用性和可靠性在企业的信息系统中，数据库往往是最重要的一环，也是最容易出现问题的一环。
因此，数据库技术必须具有高可用性和可靠性，能够保证数据的安全和稳定运行。
当数据库故障时，必须能够快速恢复数据，并且能适应数据增长。
3.数据库技术必须具有良好的性能企业的生产系统需要在高速运行的同时保证高质量的服务。
因此，数据库技术必须具有良好的性能，以确保数据的快速访问和高效处理。
4.数据库技术选型必须合理经济虽然数据库技术在企业的信息化建设中扮演着重要的角色，但不应过分消耗企业的经济和资源。
因此，在选择数据库技术时，需要根据企业的实际情况考虑成本和收益，并选择适合的技术和版本。
二、数据库架构的常见类型及其选择在数据库选型中，架构是一个非常重要的因素。
不同的架构可提供不同的功能和特性，但也存在一些限制和约束。
以下是几种常见的数据库架构类型：1.单机数据库单机数据库是指运行在单个计算机上的数据库管理系统。
这种架构的最大优点是管理和维护比较简单。
但是，在数据量较大的情况下，单台服务器可能会无法满足业务需求，同时，并发操作容易导致数据库性能下降。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库服务器选型分析
功用：数据的对象定义、存储备份、访问更新、统计分析、安全保护、数据库运行管理
主流数据库：Oracle,DB2,SqlServer,Sybase
对服务器要求
高强度密集计算能力
高速在线事务处理能力
可靠、大容量数据存储能力
系统资源占用
•处理器：数据的查询和修改操作耗费大量CPU资源
•内存：对数据大量的调用需要大量的内存来缓存数据
•磁盘：简单查询对磁盘要求不高•网卡：网络带宽占用较少
选型关注事项
•超强计算能力
–MP版本至强处理器（更大的cache）
–64位安腾处理器（浪潮SP3000)
–更高的系统总线带宽
–更大的内存容量，更高的内存总线带宽（双路、四路交叉存取）
–磁盘I/O带宽（ULtra320）
–网络I/O不是关注重点
选型注意事项
•完善的可靠性设计
–RAID、双电源等可靠性技术
–系统高可用设计（双机、集群）
•先进的存储方案
–单机RAID技术
–外挂磁盘阵列柜、存储区域网络(SAN)
数据库选配
负载单个操作占用资源
CPU X3.0 1031 0.097%
X3.0*2 2251 0.044%
内存（2G） 1150 1.74M
作为ERP的硬件支撑平台，服务器的选择依赖于ERP实现功能的强弱和多寡。
但是，作为企业提高企业管理和工作效率的ERP系统，其功能肯定是在不断的扩充和增强。
因此，在选择ERP服务器时，我们不仅要考虑到满足现阶段的应用，更重要的是考虑到它满足未来应用的扩展性是否足够强大，不需要届时不得不更换服务器，增加企业不必要的投资。
ERP应用，是一项颇耗费服务器CPU、内存、存储和网络带宽资源的企业应用。
因此，我们在此推荐浪潮英信NL380D，以满足选型的苛刻条件。
浪潮英信服务器：NL380D（或以上）
配置：
CPU：Xeon 3.2G*2/L2 2*2M/FSB 1066MHz
内存：2G ECC DDR2 FBD
硬盘：Ultra320 SAS RAID 5，73GSAS*3热插拔硬盘
网卡：双1000M。