11月 10th, 2007 | |
Posted in 方案
这章讲解释你可以使用的不同的部署模型和配置。
- 复制模型和数据分发 描述sequoia支持的不同的复制模型。
- 控制器复制和水平扩展 解释怎么使用控制器的冗余来提高集群的高可用性和容错性。
- 客户端如何连接sequoia, 解释不同的客户端应用如何通过sequoia中间件来访问数据库。
复制模型和数据分发
sequoia使用RAIDb的概念。
RAIDb的目标：
通过将多个廉价的数据库实例组合到一个数据库阵列，提供比单台数据库更好的性能和容错性。
隐藏分布式数据库的复杂性，提供给数据库客户端一个独立的数据库。
在RAIDb中，一个控制器在其他资源的前面。客户发送他们的请求到RAIDb控制器，这个控制器将他们分发给一组RDBMS后端。
有不同的RAIDb级别或数据分发方案可用，它提供不同的费用，性能，或者容错权衡。
全分割(RAIDb-0)
RAIDb-0 分割数据库表到一个数据库后端节点集。
- 一个表本身不能再分割了。但是不同的表可以分布在不同的后端节点上。
- RAIDb-0 需要至少两个数据库后端。
- RAIDb-0 当前只能和一个控制器配置一起使用。
- RAIDb-0 提供了一定的性能扩展，但不支持容错功能。
注意：
当前的实现不支持分布式join。也就是说如果你想在表t1和t2间进行join操作，你必须确保t1和t2在同一台机器上。
扩展性的提升取决于表的数目和各个表的负载情况：
- 如果你的数据库很大，没有单个节点有足够的容量存放整个数据库，那么RAIDb-0允许你把一个数据库分布存储到到一组节点上。
- 此外，每个数据库引擎处理一个小的数据集可以尽可能的提高缓存利用率，因为总是请求那几个表。
- RAIDb-0存储的使用率是最高的，因为没有重复的信息。
- RAIDb-0需要控制器知道那个表在哪台服务器上，以便把请求导向正确的节点。因为没有重复的表，一直一个后端会执行一个特定的请求。这些信息也可以静态配置到配置文件中，也可以从每个数据库中抓取其schema来动态构建。
全复制 (RAIDb-1)
- RAIDb-1 在一组后端上提供了一个数据库的全镜像。
- RAIDb-1 需要至少两个后端节点，但是理论上后端的数量没有上限的限制。每个后端必须有足够的空间运行整个数据库。
- RAIDb-1 允许在集群配置中使用几个控制器来为关键系统获得高可用性。
全复制
RAIDb-1的扩展能力取决于控制器广播更新所有节点的能力。如果有大量后端数据库，使用复合RAIDb可以获得更好的扩展性。
RAIDb-1提供了对读查询的加速，因为他们可以被均衡到所有后端上。另一方面，它对写操作没有加速（update,insert,delete请求），因为他们必须广播到所有节点。写操作在所有的后端并行执行。所以，在写的角度来看，RAIDb-1可能比不上一个单独的节点，但是从读的角度来看，性能会随着后端节点的增加而线性增长。
RAIDb-1有很好的容错性，因为系统即使只有一个后端可用时也可以保持工作。
不像RAIDb-0，RAIDb-1控制器不需要知道数据库的结构，因为所有的节点都有能力处理任何请求。然后，RAIDb-1提供了一个缓存，它需要数据库结构来维护缓存的一致性。
部分复制 (RAIDb-2)
RAIDb-2可以看作是RAIDb-0 和 RAIDb-1权衡下的一个中庸的解决方案。它支持调整每个数据库表的部分复制程度，以获得一个做好的读写性能。
RAIDb-2:
- 要求至少三个数据库后端；
- 要求每个数据库表在至少两个后端上可用以解决单点故障问题。
- 不要求任何一个节点可以运行整个数据库。
下面是RAIDb-2的典型应用：
没有或者只有少数几个节点运行整个数据库，一组节点各自运行这数据库的一部分。
下图中的例子显示了RAIDb-2的部分复制，数据库包含3个表：x,y,和z.第一个后端包含整个数据库，但是其他节点都只包含一个或两个表。表x 和 y有3份拷贝,表z有两份拷贝。任一节点失败，仍然可以从其他的存活节点中找到数据。
RAIDb-2对于异构数据库非常有用。一个已有的企业数据库使用商业数据库，但是要建立一个全拷贝无论是从存储上还是从增加许可的费用上来说，都太贵了。有了RAIDb-2就好办了，你可以增加几个小型开源数据库来各自运行整个数据库中的某些部分来代替整个数据库，这样也可以获得更好的容错性。在下图这个使用RAIDb-2进行部分复制的案例中，第一个后端节点可以是商业数据库，其他4个节点是小型开源数据库。
RAIDb-2容错性没有RAIDb-1好，但是它有效的改善了写操作的效率。
跟RAIDb-0类似，RAIDb-2也要求控制器知道所有数据库的结构，以便将请求定向到适当的节点。
警告：
在Sequoia中使用RAIDb-2仍然有一些限制。
当前，备份器不支持部分导出：当你要备份一个后端时，你将dump所有的表。类似的，当你restore一个后端时，你也将恢复所有的表。比如节点1有表x,y和z,你把他们全部dump了，如果你想用这个dump恢复节点2时，节点2将得到全部的表（x,y,z）.
当节点在恢复过程中，这就成问题了：recovery log记录了所有的请求（对所有表的），并且尝试去把他们重新走一遍。如果在恢复过程需要的一个表不在当前这个节点上，那么这个节点就不能被重新同步了。因此，这是个需要修复的bug，应该允许只同步当前节点上有的那些表。
另外，RAIDb-2也不支持分布式的join,跟 RAIDb-0 相同。
控制器复制和水平伸缩性
除了数据复制以外，Sequoia 还支持控制器冗余。为了防止Sequoia 控制器成为单点故障，你不惜在Sequoia 的配置中包括两个活更多的控制器节点。
注意：
在单个数据库和RAIDb-0配置中，你只能使用一个单独的控制器：这些控制不支持控制器复制。
Sequoia 包含两个可选的配置来提供水平扩展：
- 搭配控制器配置（collocated controller configuration）-同一台及其既做控制器，又做后端数据库服务器。
- 专用控制器配置（dedicated controller configuration）-控制器和后端数据库服务器被装在专门的机器上。
注意：
每个控制器必须被分配给一组特定的后端：后端坚决不能在多个控制器间共享。
搭配控制器配置适用于高可用系统：
在一个搭配控制器配置中，Sequoia被安装成两个节点的配置，两个节点都作为控制器和后端/数据库服务器。
专用服务器适用于大型生产环境
在规模较大的环境中，Sequoia 控制器安装在专用的服务器上来提升性能。
在控制器后面增加更多的后端，可以让Sequoia为更多的客户端应用请求服务。请求被后端的数据库服务器以他们各自的速度执行，但是控制器后面的服务器越多，可用的资源也就越多。
那么你系统后端需要多少台后端才合适呢？这依赖于你的应用类型：
如果你有一个读操作非常频繁的应用，那么最好在每个控制器后面都放几个后端。
另一方面，如果你的应用写操作非常频繁，那么控制器后面的后端最好稍微少一些。
注意：
写操作不能和读操作用相同的方法来衡量：
写操作需要在每个节点上按照相同的顺序同步执行。
默认的，当所有的后端都执行完这次请求后，写操作的结果会返回给客户端。（这个行为也可以在虚拟数据库的配置文件中配置：你也可以当一台后端执行完这次查询后就马上返回结果，或者当多数后端完成这次请求后返回。）所以，对于写操作来说，这意味着控制器后面增加几个后端，就要多维护几份数据库的拷贝，但它也会增加查询的处理能力。
客户端怎么连接到sequoia
你客户端应用通过Sequoia访问数据库的配置方式，取决于你所使用的客户端应用。
- Java 使用Sequoia提供的JDBC驱动直接访问
- Perl 通过DBD::JDBC Perl module 和 Sequoia JDBC驱动，或者使用Carob项目提供的ibmysequoia MySQL C API。
- C/C++ 使用Carob项目提供的ODBSequoia 驱动或者直接使用 Carob提供的C++ API
- PHP 使用Carob项目提供的ODBSequoia ODBC驱动或者MySQLi扩展和ibmysequoia MySQL C API
- .Net 使用Carob项目提供的ODBSequoia驱动
在配置你的客户端应用时，你必须提供基本的配置信息。这些信息对于所有不同的客户端应用都是一样的。这些必需的信息包括：
你的Sequoia的URL或IP，虚拟数据库的名字；
访问虚拟数据库的用户名密码。
相关文章：
Tags:
sequoia,
数据库负载均衡,
数据库集群,
数据库高可用,
负载均衡,
集群,
高可用 
