http://www.grqsh.com/solution.asp
高效可持续发展的架构
伴随着企业的发展，企业的数据量和访问量也会迅猛增加（如一些电子商务企业或网站），而这个时候数据库就会面临很大的负载和压力，意味着数据库会成为提升整个信息系统的瓶颈，这个时候大家常常会有两种解决的办法：
向上扩展：向单一节点添加硬件设备或将其升级为一个大型节点。
向外扩展：添加更多节点并将数据及工作负载分布于这些节点当中。
传统集群扩展的思路
微软所提供的集群解决方案基本上都是采用向上扩展的思路，在实际使用中表现出如下特性：
1.升级到综合性能更强大的硬件，带来的问题是硬件的浪费，一次性的投资增加。
2.单节点体系结构最终会达到一个瓶颈并无法实现进一步的有效扩展。具体表现为逐渐缩小的回报率或 者价格惊人的昂贵硬件设备。系统得不到可持续的扩展，不能从根本上解决问题。
微软以其简单易用等优点占据了很大一部分客户，但是同时也不得不面临这样尴尬的局面：用户在实际中遇到这样的问题时，没有合适的集群方案解决，好多用户就面临着要移植到其他平台上，如Oracle，采用RAC来解决。大家都知道，这将是一个即费财力、物力、人力，同时还要面临很大风险的一个艰难过程。但是又不得不走这条路，没有办法。
Moebius的解决思路
Moebius For SQL Server就是在这样背景诞生的，集群采用“向外扩展”的思路，它的出现解决了SQL Server数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。
很多企业在开始创建的时候往往忽略了企业数据库的长远规划，如果选用传统的路线一边走一边更换性能更高的服务器，淘汰以前的服务器，这样做不但不能从根本上解决由于访问用户增加所导致的数据库压力增大的问题，反而会走很多的弯路，给企业带来极大的损失和浪费。
格瑞趋势可以为您提供了系统从小发展到大平滑过渡的一整套完整解决方案。使您的数据库系统达到可持续发展，为您解决了后顾之忧。在需要更高数据库处理速度的时候，只需简单增加数据库服务器就可以了，而且这些服务器的性能可以要求不一致，系统会按照服务器的能力自动分配压力。
http://www.grqsh.com/solution_01.asp
Moebius集群解决方案
在数据库上采用向外扩展的架构并不是没有难度的，如何在数据库上构建负载均衡集群，如何用低消耗保证集群中各节点数据的实时同步？能否解决这一个问题成为集群应用成功的关键。
Moebius 核心理念和价值恰恰就在此处，核心程序宿主在SQL Server内部，监测数据的变化，同时还要解析引起数据变化的SQL语句的类型及其特点，经智能分析后，以最经济的方式完成与其他节点的数据同步。
解决方案一：
如果您正在使用或者将要安装使用SQL Server Cluster 、SQL Server2005 Mirror或第三方的HA集群软件实现失败转移，保证数据库的可用性。推荐您阅读解决方案一。
SQL Server Cluster
相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，Microsoft称之为故障转移集群。
从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份：
1. 因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。
2. 当现有的机器不能满足应用的负载时只能更换更高配置的机器。
3. 对于一个小型的应用来说，使用一个共享设备和一个在正常情况下用不到的机器，
总体成本的浪费还是很严重的。
从细节上讲，当一个节点出现故障的时候，另一个节点接管业务又是需要一定的步骤和时间。
SQL Server2005 Mirror
镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性。每个数据库镜像配置均包含一个主体服务器（包含主体数据库）、一个镜像服务器（包含镜像数据库）和一个见证服务器（可选）。主体服务器和镜像服务器要求是独立的服务器实例。见证服务器监视主体服务器和镜像服务器，确保在给定的时间内这两个故障转移服务器中有且只有一个作为主体服务器，从而支持自动故障转移。
SQL Server2005 Mirror在可用性方面有了一些保证，但仍然是单点工作；在扩展和性能的提升上依旧没有什么帮助。
Moebius集群解决方案:
采用Moebius For SQL Server 标准版搭建集群，集群中两个数据库是同等地位的，中间件驻留在每个机器的数据库中，监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。
该方案能给您带来以下的益处：
1.在SQL Server Cluster中闲置的那台机器被利用上了，不仅能失败转移还能负载均衡，提高了性能。
2.使用无共享磁盘架构，数据存储在每台机器的硬盘中，因此可以节省投资。
3.无共享磁盘架构在日常的维护以及故障时的修复等管理成本比SQL Server Cluster要低。
4.可持续发展的架构，方便扩展，随着系统压力的增长只需要添加进新的机器就可以了，不需要升级现
有系统的硬件配置，不需要改动应用程序。
解决方案二：
如果您现在使用的是基于 SQL Server复制/订阅的方案。推荐您阅读解决方案二。
如图，所有的写操作都提交到中心数据库上，然后通过 SQL Server 的复制/订阅功能把数据复制到其
他几个只读的数据库中，这样可以做到读写的分离，并且读可以做到负载均衡。
SQL Server复制/订阅对于性能的提升还是很大的，但是在实际应用中存在以下不足：
1. 数据同步的实时性得不到保障，中心数据库在正常的压力下10秒左右。当访问负荷很高或者中心数
据库在整理数据时，将出现大量DML操作时延迟时间比较长或者出现堵塞的情况；
2. 某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服务，规模越大的应
用停止的时间越长，严重影响了数据库的可用性。 另外中心数据库所采用的结构还是MSCS，只是提
供了一种故障转移的机制，当有一个节点出现问题后把负载转移到另一个节点上；
3. 复制/订阅的管理维护的成本比较高。
Moebius集群解决方案:
采用Moebius企业版搭建横向多节点的集群（若数据量大也可采用Moebius高级版搭建网格分布式数据集群）， 这种冗余的结构不但保证了数据库的可用性，而且可以提供高性能，随着压力的增加，只需增加节点就可以保证系统的服务。
1.操作是并发的，整个操作的响应时间和更新一个数据库的响应时间基本相同；
2.数据同步是基于ＳＱＬ语句的，在同步的过程中，中间件会智能的分析，采用数据压缩等手段来减少
网络的消耗。
3.整个操作是在事务的环境下完成的，是一个同步的过程，保障了多个数据库中的数据是一致的、
实时的。
Moebius应用程序读取数据时，可以任意从多个数据库中的一个中查找，进而很容易实现集群各节点间负载均衡。
该方案能给您带来以下的益处：
1．解决了数据实时性的问题。
2．在复制/订阅结构中的中心数据库Cluster中闲置的一台机器被利用起来提高了整个系统的使用率。
3．节省了维护复制/订阅的管理成本。
4．系统支持无共享的架构，数据可以存储在各自机器自己的硬盘中，因此可以节省下共享的存储设备。
5．数据库结构修改时不需要重新初始化复制/订阅，提高了数据库的可用性。
6．当系统出现性能问题时，只需简单增加节点就可以，方便扩展。
解决方案三：
如果您的数据库规模很大， 正在考虑使用分区表，分区视图或者自己拆分业务逻辑做一些库表散列，推荐您阅读解决方案三。
分区表
SQL Server 2005引入的分区表技术，让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器，不能从根本上解决问题。理想的解决办法是把数据分散到不同的机器中，通过多个机器上的CPU,I/O的并行处理来提高性能。
分布式分区视图
分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数据完整性约束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。另外经过实际测试，对于符合分区规则的查询性能还可以，对于全局查询并不像我们预期的那样，是并行计算，有时还不如不分区的响应快。
库表散列
一些大公司也在自己开发基于库表散列的数据库架构，比如My Space经过数次数据库升级，最终采用按照用户进行的库表散列，微软为MSN/Hotmail和纳斯达克开发的数据依赖型路由(Data-Dependent Routing，DDR）。但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。
Moebius集群解决方案:
采用Moebius高级版搭建网格分布式数据库集群，利用一群廉价的PC服务器，构建综合性能超强的数据库集群，集群充分发挥每个机器的CPU、IO等资源。
该方案能给您带来以下的益处：
1.通过分区把数据放到不同的机器中，每次查询可以由多个机器上的CPU,I/O来共同负载，通过各节点并
行处理数据来提高性能。
2.冗余的数据结构（矩阵列）消除了单点故障，任何一个机器出现故障后都不会影响系统的正常
运行，数据库集群能提供不中断的服务。
3.无共享磁盘架构节省了硬件，利用中小型的服务器取代大型服务器大幅降低了硬件的成本。
4.系统中不再有闲置的资源，降低了系统TCO（总体拥有成本）。
5.分区把数据分成更小的部分提高了数据库的可用性和可管理性。
6.根据业务的需要，访问层和数据层都可以增加，Moebius集群具有良好的扩展性。
7.中间件宿主在数据库中的创新使集群变得更透明，数据库的管理成本，以及面向数据库的开发成本都
最小化。
http://www.grqsh.com/soft_03.asp
Moebius集群的架构
Moebius集群采用无共享磁盘架构
Moebius集群由一组数据库服务器组成，每个服务器上安装相同的数据库，集群支持无共享磁盘架构，各机器可以不连接一个共享设备，数据可以存储在每个机器自己的存储介质中。
无共享磁盘架构，使得存储不再是单点，系统可用性提高，同时还可以充分利用集群中每个机器的CPU、I/O等硬件来实现集群的高性能。
无需价格高昂的共享磁盘柜，只要使用2台服务器即可轻松构筑低成本的集群。
Moebius集群架构的分类
依据数据是否分区，Moebius集群架构分为标准架构和高级架构：
标准架构：每个节点中具有完全相同的数据，每个节点都拥有数据全集。
高级架构：每个节点中数据是不同的，每个节点只拥有数据全集的一部分。
Moebius For SQL Server标准架构
Moebius集群是一组相互独立的服务器，通过相互协作形成一个统一的整体。集群中多个节点相互连接，这样冗余的硬件架构不但可以避免单点故障而且提供了杰出的故障恢复能力。一旦发生系统失败，Moebius集群对用户保证最高的可用性，保障关键是业务数据不丢失。
Moebius 集群标准架构
一个集群数据库可以看作是一个被多个应用实例访问的单一数据库。在Moebius集群中，每个SQL Server实例在各自的服务器上运行。随着应用的增加，当需要添加额外的资源时，可以在不停机的情况下很容易地增加节点。
标准架构中间件工作原理
中间件驻留在每个机器的数据库中，监测数据库内数据的变化,并将变化的数据同步到其它数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，因此同步到多个数据库和同步到一个数据库的时间基本相等；另外同步过程是在事务环境下完成的，保证了多份数据的数据一致性。
正因为中间件宿主在数据库中，所以中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能地采取不同的数据同步策略以保证数据同步成本的最小化：
1. 数据条数很少，数据内容也不大，则直接同步数据。
2. 数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等， 则先对数据进行压缩然后再
同步，从而减少网络带宽的占用和传输所用的时间。
3. 数据条数很多，此时中间件会获取造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其
执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。在对表结构进行调整
或者批量更改数据的时候，这种同步策略非常有用。
Moebius For SQL Server高级架构
在高级架构中，采用数据分区技术，依据某种规则把数据分散到多个数据库中。
数据为什么分区？
1.当数据量很大的时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影
响最终用户的体验。
2.在大数据量下对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服
务或者高负荷运转很长时间，影响数据库的可用性和易管理性。
3.面对这样的应用环境，仅仅依靠提升服务器的硬件配置是起不到作用的，比较好的办法是通过数据分
区，把数据分成更小的部分来提高数据库的可用性和易管理性。
4.分区把各部分数据放到不同的机器中，每次查询可以由多个机器上的CPU、I/O来共同负载，通过
各节点并行处理数据来提高性能。
系统结构
Moebius For SQL Server高级架构在结构上分访问层数据库和数据层数据库两部分。
访问层：访问层数据库只有原来数据库的结构没有数据，处理提交上来的SQL语句并调度执行。访问层数
据库可以由多个机器来负载均衡。
数据层：数据层数据库就是原来的数据库，但是可以有多个冗余对查询进行负载均衡，以提高整个系统
的性能，Moebius For SQL Server保证多个数据库的一致性；数据层数据库不暴露给用户和业
务程序，用户和业务程序面对的是访问层数据库。
通过访问层和数据层构建出一个网格集群来实现集群的高可用性和负载均衡，访问层和数据层的数据库是可以扩展的。(每列中各节点的数据是相同的，每行构成数据的全集；图中数据数据层设计为5×2矩阵，在实际应用中要依据业务的特点来划分)。
如何分区？
Moebius For SQL Server支持两种分区方式：Hash分区和线性分区。
Hash分区：是将表按某一字段的值均匀地分布到若干个指定分区中的一种分区方法。
优点：每个分区内分配的数据比较平均，承载的压力也就比较平均，机器能够得到充分的利用。
缺点：不易扩展，如果扩展新的分区会涉及到数据的重新分配，因此在设计的时候要提前规划好。
Moebius For SQL Server支持把多个分区数据放在一个机器上然后再根据压力逐个的拆到新机器中去，这样既可以保证了分区的规划又不浪费机器，实现了线性扩展。
线性分区：即范围分区，将表按某一字段的取值范围进行分区，如按时间，每个月的数据在一个分区中。
优点：扩展性能比较好，因为数据的增长是有一定规律的。
缺点：每个分区内数据的压力不是很平均，大部分业务都存在这种现象，越老的数据被访问的频率越低，从而导致各机器面临的压力也不同，因此使机器的利用率不高。
Moebius For SQL Server支持把多个分区数据放在一个机器上，所以可以通过新老分区的交替使用来提高机器的利用率。
分区操作在管理工具中很容易配置，首先设置分区，接下来给每个表选择分区并设置分区字段。（如下图）
这样中间件在解析、处理SQL语句的时候就会根据配置把数据分配到相应分区所在的机器中去或者从相应分区中读取数据。和其他一些集群不同的是Moebius For SQL Server的分区是经过抽象的，是完全透明的。
高级架构中间件工作原理
1.中间件解析到查询的SQL语句后，首先分析该语句要查找的表，根据所要查找表的分区配置和SQL语句的WHERE条件计算出要从一个分区中还是多个分区中去取数据，取完数据后在访问层合并后再返回给应用程序。这里要重点说明的是中间件通过分析SQL语句，能够对分区范围进行动态缩小或者放大。SELECT * FROM dbo.UserInfo WHERE UserID = 1，因为UserID是分区字段，所以中间件只会从一个分区中查找；SELECT * FROM dbo.UserInfo WHERE UserID IN(3, 4)则会从两个分区中查找；SELECT * FROM dbo.UserInfo WHERE Username = ‘wangzhongtao’，没有使用分区字段作为查询的条件，中间件就会从每个分区列数据库进行查找。对于多个分区列数据进行查询的操作是并行的从而保证总体响应时间的最小化。
2.中间件解析到更新的SQL语句后，首先分析要更新的表，根据要更新表的分区配置和更新语句的SQL语法来计算出要更新一个或者多个分区中的数据。例如INSERT dbo.UserInfo(UserID, Username) VALUES(1, ‘wangzhongtao’)，中间件会解析到UserID = 1，然后根据表的分区配置把数据插入到第一个分区中去。中间件解析到一个更新的SQL语句后，会同时更新同一列中的数据库。第一：更新操作是并行的，整个操作的响应时间和更新一个数据库的响应时间基本相同；第二：整个操作是在事务的环境下完成的，保证了多个数据库中数据是一致的，实现了真正的冗余。
3.中间件解析到一个更新数据库结构的DDL语句，会把该语句同步到其他访问层数据库和所有的数据层数据库中。这样用户就像在使用一个数据库去维护表、索引、存储过程等等，大大降低了用户的管理成本，也降低了出错的机率。这是Moebius For SQL Server 的亮点。