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

高可扩展性数据库架构设计方法时宜 雅迅网络股份有限公司摘要：软件系统的规模化运作对数据库存取性能提出了越来越苛刻的要求，本文在目前流行数据库软件自身尚不能提供包含分布式管理、存储、负载均衡的综合解决方案的条件下，研究如何从应用层面解决目前用户群体庞大的软件系统在数据库存取性能方面的瓶颈问题。本文分析了仅仅依赖数据库软件本身解决性能瓶颈问题的困难和局限性，利用分而治之的思想，在应用层引入了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 公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。 成本 节点服务器对 RAM 的需求很大，与数据库大小呈线性比例 最好使用千兆以太网络 还需要使用 Dolphin 公司提供的昂贵的 SCI 卡 优点 可用于负载均衡场合 可用于高可靠性场合 高伸缩性 真正的数据库冗余 容易维护 缺点 随着数据库的变大，对 RAM 的需求变得更大，因此成本很高 速度 几乎比典型的单独服务器（无千兆以太网，无 SCI 卡，存储引擎相关的限制少）慢 10 倍 应用场合 冗余，高可靠性，负载均衡MySQL 官方网站推荐的 HA 方案是结合 DRBD(共享硬盘)和 Replication(复制-读写分离)。假如再加上 Linux Heartbeat 还可实现 Auto-failover 功能，在此种情况下，我们会发现，down 机时间会大大减少。虽然上述方案解决了集群问题，但对于 Mysql 服务器之间的负载均衡还是存在问题的。2) 其他集群方案a) MySQL Proxy + HSCALE一套比较有潜力的方案。其中 MySQL Proxy (http:/forge.mysql.com/wiki/MySQL_Proxy) 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy 的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用 Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE 各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。 b) Hibernate Shards 这是 Google 技术团队贡献的项目（http:/www.hibernate.org/414.html），该项目是在对 Google 财务系统数据 Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能应用，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。c) Spock Proxy这也是在实际需求中产生的一个开源项目。Spock（http:/www.spock.com/）是一个人员查找的 Web 2.0 网站。通过对自己的单一 DB 进行有效 Sharding 化 而产生了 Spock Proxy(http:/spockproxy.sourceforge.net/ ) 项目，Spock Proxy 算得上 MySQL Proxy 的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以 Spock Proxy 也是基于 Rails 构建。d) HiveDB上面介绍了 RoR 的实现，HiveDB (http:/www.hivedb.org/)则是基于Java 的实现，另外，稍有不同的是，这个项目背后有商业公司支持。4. PostgreSQL1) 常见的一种方案 PostgreSQL 和 Slony-I、PL/Proxy、Pgbouncer 已经可以为我们提供一套比较完整的企业级数据库存储解决方案Slony-I 是一种基于 postgresql 的异步通知机制做的复制技术， 其同步速度非常快。 采用这个复制技术来做备份。当然作为主、从架构的数据库而言，作为同步的一个手段还是合适的。不过，配置复杂了一点。PL/Proxy 可以为 PostgreSQL 提供横向扩展能力，PL/Proxy 的设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发，示意图如下：PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 P