SQL Server横向扩展方案-SODA

SQL Server横向扩展方案-SODA

每次在提到SQL Server扩展性问题的时候，似乎很多的SQL Server DBA或者使用微软技术开发的朋友心里总是一整痛：SQL Server只能纵向的扩展（Scaling-Up），无法横向的扩展（Scaling-Out）。

每次有人提到Oracle和SQL Server，第一句话就是：SQL Server无法搞负载均衡，而Oracle可以使用RAC。

每次我问其他的SQL Server DBA朋友：SQL Server自带的Mirroring，Replication，Cluster难道不能搞负载均衡吗？很多的人摇摇头。最后不能不选择第三方的方案。

后来，通过不断的实践和思考，我明白了为什么很多的朋友对SQL Server的横向扩展能力不理解。其实SQL Server已经提供了横向扩展所需要的所有技术和工具，但是如果单看每一种工具，可能认为达不到目的，但是如何把这些技术按照适当的设计，和组合，那么，绝对就是满足功能的。

另外，做DBA的朋友，可能在技术上面有一定的局限性。因为很多的DBA是“纯”的DBA，很少懂应用程序的设计，懂架构设计的人DBA就更加的少了。

其中，一个好的高性能的数据架构的做出，需要多方面的知识，需要既懂数据库（知识能力要达到专业的DBA水平），也懂架构的人。这样，就可以将应用和数据很好的结合在一起。

好了，说了这么多，希望对大家有些帮助，不要“盲目的”相信一些传说和谣言，特别是对刚刚踏入技术行业的朋友，很容易让大家望而却步。

言归正传，我们来看看几种实现SQL Server横向扩展的方案：

1.Service Oriented Database Architecture (SODA)

2.Shared Scalable Database (SSD)

3.Peer-to-Peer (P2P) Replication

4.Data Dependent Routing

我们本篇就介绍这些方案以及实现的原理，我们站点后续会根据朋友们的需要给出更多相关的讲解。

数据的分类

在讲述SODA之前，我们先来看看考虑这样一个问题：如何分割数据？

为什么要问这个问题，因为很多的时候，为了使得数据访问的性能更好，合理的分布数据是一个非常好的手段。对于这个问题，这个问题的回答有很多，但是有一点是不变的，要根据数据的特性来分割，那么数据包含哪些特性呢，或者说数据可以分为哪几种。

下面，我们就来看看这个问题。

引用类的数据

顾名思义，引用类的数据就是指代那些被应用程序使用，但是又不被程序所维护和管理的数据。一般而言，引用数据往往是不变的数据，或者是变化非常缓慢的数据。例如，电子商务网站中的产品的分类数据。

活动类的数据

也是见名知意。主要是指与一些特定的活动或者业务处理相关的数据。例如，在订单或者库存的系统中，会随着业务的处理而产生出一些数据，这些的数据的作用范围就是某个活动或者业务流程中，一旦活动或者流程结束，数据就没了，除非处于某些特定的目的，例如作为历史或者跟踪的数据进行存储保留。

资源类的数据

资源类的数据就是系统中的业务处理所依赖的核心数据，例如库存数据，用户用户，订单数据等。如果资源数据丢失，那么我们就无法处理业务，所以资源类的数据是非常重要的，必须保证它的高可用性和完整性。从这里也可以知道，资源类的数据和其他类型的数据的分割和管理方式是不一样的，甚至使用的配套的设备都可以不一样。

另外，因为SODA的引入，出现了另外一种类型的数据：服务交互数据。

服务交互数据

这一类的数据只要用了在是服务进行数据交互的。这类型的数据必须是被其他的服务理解，而且必须保证稳定。例如，如果一个订单的信息在传输的过程中丢失了，那么信息的发送方必须要可以重新的产生和原先一样的数据，然后再次发送。

好，大致的清楚了这些数据类型之后，我们继续往下看。

Service Oriented Database Architecture (SODA)

相信大家对SOA都有所了解，我这里也不长篇大论的讲SOA的细节，但是有点要提的就是：通过采用SOA，像外界隐藏了内部的实现细节，外面看到的都是一个个的服务，不用管服务内部是如何部署，采用什么技术平台，采用什么数据库提供数据等等。

SODA其实就是沿用了SOA的实现，实现基于数据库的SOA。其实，我们可以这样理解，我们的数据库向应用程序或者其他的调用了提供了数据，也就是提供了数据的服务。在很多的应用中，我们都是采用比较直接的方式去访问数据库，但是现在，我们把数据库那一端封装起来，隐藏细节，然后以统一而标准的方式公布数据服务的接口，告诉应用程序：你甭管我是如何实现的，反正你只要调用我的接口，你需要的数据操作就完成了。此时应用程序和数据进行了解耦，使得他们独立的保持变化，极大的提升了灵活性和后续的扩展性。

通过下面的图，我们看看对SODA有个了解：

(29.29 K)

9/5/2012 10:37:13 AM

采用了SODA之后，我们基本上面就已经不知道有数据库这回事了，因为此时我们只知道存在数据服务，它可以满足我们一切的数据需要。

在SQL Server中，实现SODA主要基于Service Broker来进行的，主要依赖下面的技术：SQLCLR，CacheSync，Native Web Service Support，Service Broker。

Native Web Service Support：因为SODA会服务的形式发布数据，所以肯定就需要一些基于web service的支持。在win2003以及以后版本，就为基于SQL Server的SODA提供了支持。可以支持SQL Server将数据用SOAP形式进行交互。

Service Broker：提供了一个强大的基于消息的机制。

CacheSync：缓存同步机制。可以使得依赖底层数据的那么缓存在底层的数据方式变化的时候更新缓存中的数据。

SQLCLR：强化和扩展对数据库的编程，使得相关的逻辑直接驻留在数据库中，从而减少远程数据访问的开销。

很多的朋友可能希望，我们对上面的每一种技术，以及SODA的具体的设计和使用有个详细的讲解，这个我们以后会以视频的方式给出，也会有一些文章发布，但是文字的表述能力确实有限，如果大家企业中需要，我们可以提供专门的培训讲解。

本系列文章主要是给那些已经懂的这些技术，在技术选型上的朋友一些参考。也给那些不太熟悉这些内容的朋友一个感觉，起码知道有这么回事。

我们下篇文章继续讲述。