理想的分布式数据库

听闻阿里巴巴为了省钱，用大量跑着mysql的pc服务器替换了运行在小型机上的oracle。
我私下考虑，如果让我来解决这个问题，该如何设计呢？

首先，我觉得过程是这样的，
起初是一台数据库服务器，里面存放所有的表和数据
然后分解成n台数据库服务器（简称节点），各存放一部分数据。（未必是1/n的数据，应该有冗余才对。）

但是，对于应用开发者来说，应该有一个封装，让他们仍然觉得仿佛在访问一个数据库服务器。
具体的说，可能要自定义一个jdbc驱动，内部进行路由分派。
（理论上也未必非要做jdbc驱动，只要做一个统一的数据库访问接口即可，比如：

interface DistributedDB{
  Recordset executeQuery(String sql, RequestInfo info);
  void executeNonQuery(String sql, RequestInfo info);
}

）

先不细说驱动的事情，先说说常见的数据库操作。
CRUD作为基本的操作，其中CUD一般是单表操作，只有R，即查询才涉及多表操作。
无论怎样，我们可以认为任何一个SQL请求，都有其涉及的表，称之为相关表。
比如，select a.*,b.* from a,b where a.id=b.id的相关表是[a,b]
于是，只有同时拥有这2个表的服务器才能满足这个join查询请求。

再比如，数据库里的表的数据可能不是最新的，因为同步需要时间。
而某个查询可能是允许脏读的，那么我们再给相关表加上一个属性。
还是以上一个查询为例，[a(allow_dirty),b]
这样一来，能满足此请求的服务器可能多了一些。

再考虑分区建表，比如按时间或者某个字段的大小分区，而且是分布在不同的服务器里，
那么相关表还需要加上分区属性，比如
host 1
  table a
    index time from x to y

那么在查询的时候,我们可以指定查询要求，比如[a(time >x),b]

...
以上，我主要考虑了如下几个因素，
1 以表为单位，分拆数据库到不同的服务器。
2 分拆大表，按索引进行拆分，保存到不同的服务器。
3 是否允许脏读。

总之，每个数据库请求应该尽可能的降低要求，以便充分利用上述的参数带来的性能提升。
以taobao这样的电子商务网站为例，产品目录应该是允许脏读的。
比如新产品上架N秒钟以后才出现在买家的搜索结果里是允许的。
比如按地区查询，可以利用分区建表机制，优化查询。


这个方案新增的工作量是要为每一个数据库请求进行分析，得到其相关表的信息，以便分派请求。
这个分析的动作，可以自动和人工结合。

再说一下写操作，无论是增删改，都是首先写入到某一台机器，然后逐步同步到其他服务器。
显然，我们必须为每个节点上的每个表做版本控制，以便知道哪个表是最新版本。

有了这么一套系统以后，应该是允许实时监控，根据请求的负荷，调整节点的数量。
这个调整也应该是允许自动和人工进行。
在对请求统计之后，应该可以合理的调整节点的数量和节点里包含的表的数据。

以上方案纯属外行人虚构，呵呵。

评论

15 楼 ppgunjack 2011-04-06  

对脏读的理解是错的
事务如果都完全放弃了，就谈不上是什么数据库了，纯粹成cache和文件系统了
淘宝能大规模使用这些分布设计应该基于一个原因：交易访问远低于商品浏览访问
交易数据使用的数据库应该不是靠数据库本身主备实时同步就是有多节点日志保护吧

14 楼 sdh5724 2011-03-25  

smildlzj 写道

ali在用Greenplum的。。。

不是为了省钱吧，只是应用场景不同。。。

极少的地方用了这个， 估计要cut掉。 做一些向量计算才引入的－－－－自动化推荐。

13 楼 sdh5724 2011-03-25  

楼主的yy基本连边都没有靠上。而且又不少理解又错误的。 不好意思直接说了：
／／／／／／／／／／／
以taobao这样的电子商务网站为例，产品目录应该是允许脏读的。
比如新产品上架N秒钟以后才出现在买家的搜索结果里是允许的。
比如按地区查询，可以利用分区建表机制，优化查询。
／／／／／／／
不可能再数据库里做你说的事情的， 全世界的db厂商都无法做到。 目录是是通过cache实现的， 商品发布的目录， 和浏览目录是2套完全不同的体系设计，
这是商业要求。 商品上架过程是通过几分钟一次向search engine同步做到的， 所有的查询都是通过搜索引擎完成的， 传统数据库是无法支撑这个访问量的。

你说的透明访问数据库，这是对的。 基本上， 会通过2个技术手段都能做到。 大部分的情况， 我们是基于模拟一个数据库的访问的中间件完成的，硬件／分区数据的调整对应用可以无影响进行， 当然通过数据源机制的改变也能做到(JDBC的5大接口拦截)， 这样的做法会导致配置文件可怕的复杂，非常不利于在线操作。

另外， 对等的数据库服务器直接是不做数据复制的， 脏数据没有那么可怕。 你想，为了提高单机性能， 这么一复制， 几乎是要前功尽弃的。

12 楼 smildlzj 2010-09-24  

ali在用Greenplum的。。。

不是为了省钱吧，只是应用场景不同。。。

11 楼 lishuaibt 2010-09-16  

现在淘宝的应用里边，虽然用的是MySQL（关系型数据库），但是几乎是没有用到关系，甚至在数据库的表设计里边会反范式进行设计，会有一些必要的字段冗余，说白了，我们用MySQL基本上是把MySql作为一个Table的容器罢了。如果在分库分表的情况下要做到支持传统的join等操作的话，不是不可能，是没有必要，或者说是违背了我们分库分表的初衷。数据库中表的数据增长量是不同步的，就这么一个原因已经决定了我们应该摒弃最初的想法。为了将来更方便灵活的容量扩充，摒弃join，反范式设计（冗余字段）。。。

TB还采用了读写分离的方式　Master／Slave模型，确实存在Replication的延迟的问题，这个东西就要看应用场景了，绝对的实时的读取可以指定读Master库，当然了绝大多数应用场景是不需要这么高的实时性的

对于透明的分布式数据访问层，这个很重要，降低了业务开发的难度，目前淘宝在这方面做的很好，通过在JDBC层面上进行了实现，规则方面也是很强大的。至于现在开源的Amoeba这个东西，从层面上来说，跟TB的分布式数据层还是有些差别的。

10 楼 awenhaowenchao 2010-09-15  

hatedance 写道

听闻阿里巴巴为了省钱，用大量跑着mysql的pc服务器替换了运行在小型机上的oracle。
我私下考虑，如果让我来解决这个问题，该如何设计呢？

首先，我觉得过程是这样的，
起初是一台数据库服务器，里面存放所有的表和数据
然后分解成n台数据库服务器（简称节点），各存放一部分数据。（未必是1/n的数据，应该有冗余才对。）

但是，对于应用开发者来说，应该有一个封装，让他们仍然觉得仿佛在访问一个数据库服务器。
具体的说，可能要自定义一个jdbc驱动，内部进行路由分派。
（理论上也未必非要做jdbc驱动，只要做一个统一的数据库访问接口即可，比如：

interface DistributedDB{
  Recordset executeQuery(String sql, RequestInfo info);
  void executeNonQuery(String sql, RequestInfo info);
}

）

先不细说驱动的事情，先说说常见的数据库操作。
CRUD作为基本的操作，其中CUD一般是单表操作，只有R，即查询才涉及多表操作。
无论怎样，我们可以认为任何一个SQL请求，都有其涉及的表，称之为相关表。
比如，select a.*,b.* from a,b where a.id=b.id的相关表是[a,b]
于是，只有同时拥有这2个表的服务器才能满足这个join查询请求。

再比如，数据库里的表的数据可能不是最新的，因为同步需要时间。
而某个查询可能是允许脏读的，那么我们再给相关表加上一个属性。
还是以上一个查询为例，[a(allow_dirty),b]
这样一来，能满足此请求的服务器可能多了一些。

再考虑分区建表，比如按时间或者某个字段的大小分区，而且是分布在不同的服务器里，
那么相关表还需要加上分区属性，比如
host 1
  table a
    index time from x to y

那么在查询的时候,我们可以指定查询要求，比如[a(time >x),b]

...
以上，我主要考虑了如下几个因素，
1 以表为单位，分拆数据库到不同的服务器。
2 分拆大表，按索引进行拆分，保存到不同的服务器。
3 是否允许脏读。

总之，每个数据库请求应该尽可能的降低要求，以便充分利用上述的参数带来的性能提升。
以taobao这样的电子商务网站为例，产品目录应该是允许脏读的。
比如新产品上架N秒钟以后才出现在买家的搜索结果里是允许的。
比如按地区查询，可以利用分区建表机制，优化查询。


这个方案新增的工作量是要为每一个数据库请求进行分析，得到其相关表的信息，以便分派请求。
这个分析的动作，可以自动和人工结合。

再说一下写操作，无论是增删改，都是首先写入到某一台机器，然后逐步同步到其他服务器。
显然，我们必须为每个节点上的每个表做版本控制，以便知道哪个表是最新版本。

有了这么一套系统以后，应该是允许实时监控，根据请求的负荷，调整节点的数量。
这个调整也应该是允许自动和人工进行。
在对请求统计之后，应该可以合理的调整节点的数量和节点里包含的表的数据。

以上方案纯属外行人虚构，呵呵。

再说一下写操作，无论是增删改，都是首先写入到某一台机器，然后逐步同步到其他服务器。
显然，我们必须为每个节点上的每个表做版本控制，以便知道哪个表是最新版本。

不用说了，那你这台机器指定挂了

安全性你得考虑，链接pc很容易挂掉的，容载备份，你必须保证备份和恢复阿

9 楼 hatedance 2010-09-15  

我说的确是一种“理想化”的东西，只经过我饭后的一点不成熟思考就写下来了。目前我没有机会参与分布式数据库的工作，所以LS的兄弟建议我了解的那些国外高级产品，比如：Greenplum，sourceforge，Amoeba，ibm,teradata等等，我估计也没有精力了。

理想能不能成为现实？只要理论上说的通的东西，我觉得迟早会的实现的。
以google的appengine为例，它的数据库就是自动化的分布式，当然，没有普通关系数据库那么灵活，不能任意的join查询。NOSQL也是简化了数据库的功能，换取了高性能。
所以，我觉得我们完全可以牺牲传统关系数据库的部分特性，换取性能。比如事务，复杂的查询等。

8 楼 xlongbuilder 2010-09-15  

理想的分布式数据库
确实很理想或者是幻想

分区的问题，或者说分区键的问题，是没办法做到如此透明的。甚至有的时候反而速度更慢。建议楼主想了解，参考下数据仓库的架构设计思想。ibm,teradata 他们也没做到楼主设计的这样。

ps：最讨厌长篇引用楼主帖子的内容，你不引用别人也知道，你是跟的楼主的帖。。。

7 楼 m7788 2010-09-13  

可以看看Amoeba

6 楼 xieshaohu 2010-09-09  

可以参考wikipedia和sourceforge的数据库架构

5 楼 diggywang 2010-09-09  

spell 写道

楼主的意思其实就是利用数据库实时同步机制，用数据库集群，分散访问压力～，但是如果数据量增加的很快，那这个问题怎么解决呢？

集群和分布式是两码事

4 楼 J-catTeam 2010-09-09  

hatedance 写道

听闻阿里巴巴为了省钱，用大量跑着mysql的pc服务器替换了运行在小型机上的oracle。
我私下考虑，如果让我来解决这个问题，该如何设计呢？

首先，我觉得过程是这样的，
起初是一台数据库服务器，里面存放所有的表和数据
然后分解成n台数据库服务器（简称节点），各存放一部分数据。（未必是1/n的数据，应该有冗余才对。）

但是，对于应用开发者来说，应该有一个封装，让他们仍然觉得仿佛在访问一个数据库服务器。
具体的说，可能要自定义一个jdbc驱动，内部进行路由分派。
（理论上也未必非要做jdbc驱动，只要做一个统一的数据库访问接口即可，比如：

interface DistributedDB{
  Recordset executeQuery(String sql, RequestInfo info);
  void executeNonQuery(String sql, RequestInfo info);
}

）

先不细说驱动的事情，先说说常见的数据库操作。
CRUD作为基本的操作，其中CUD一般是单表操作，只有R，即查询才涉及多表操作。
无论怎样，我们可以认为任何一个SQL请求，都有其涉及的表，称之为相关表。
比如，select a.*,b.* from a,b where a.id=b.id的相关表是[a,b]
于是，只有同时拥有这2个表的服务器才能满足这个join查询请求。

再比如，数据库里的表的数据可能不是最新的，因为同步需要时间。
而某个查询可能是允许脏读的，那么我们再给相关表加上一个属性。
还是以上一个查询为例，[a(allow_dirty),b]
这样一来，能满足此请求的服务器可能多了一些。

再考虑分区建表，比如按时间或者某个字段的大小分区，而且是分布在不同的服务器里，
那么相关表还需要加上分区属性，比如
host 1
  table a
    index time from x to y

那么在查询的时候,我们可以指定查询要求，比如[a(time >x),b]

...
以上，我主要考虑了如下几个因素，
1 以表为单位，分拆数据库到不同的服务器。
2 分拆大表，按索引进行拆分，保存到不同的服务器。
3 是否允许脏读。

总之，每个数据库请求应该尽可能的降低要求，以便充分利用上述的参数带来的性能提升。
以taobao这样的电子商务网站为例，产品目录应该是允许脏读的。
比如新产品上架N秒钟以后才出现在买家的搜索结果里是允许的。
比如按地区查询，可以利用分区建表机制，优化查询。


这个方案新增的工作量是要为每一个数据库请求进行分析，得到其相关表的信息，以便分派请求。
这个分析的动作，可以自动和人工结合。

再说一下写操作，无论是增删改，都是首先写入到某一台机器，然后逐步同步到其他服务器。
显然，我们必须为每个节点上的每个表做版本控制，以便知道哪个表是最新版本。

有了这么一套系统以后，应该是允许实时监控，根据请求的负荷，调整节点的数量。
这个调整也应该是允许自动和人工进行。
在对请求统计之后，应该可以合理的调整节点的数量和节点里包含的表的数据。

以上方案纯属外行人虚构，呵呵。

基本思想是没有问题的，根据具体的应用场景和应用肯定有一定的出入。
你所指的就是分布式数据层，不过这类应用的应用场景是有限的。

3 楼 wormwang 2010-09-07  

你可以看看 Greenplum
在 http://gpn.greenplum.com 可以免费注册下载。

它的架构部分和你设想类似。具体实现，更加有许多细节必须考虑。

Greenplum首先做好的OLAP优化，故做OLAP数据仓库，性能非常好。

Greenplum 的OLTP优化正在开发中。

2 楼 hatedance 2010-09-07  

spell 写道

楼主的意思其实就是利用数据库实时同步机制，用数据库集群，分散访问压力～，但是如果数据量增加的很快，那这个问题怎么解决呢？

其实我是外行。你说的很快到底是多快？
我想说的主要意思是，分布式数据库可以自动化。就像人家说google的服务器都是PC，你可以根据情况加入一些PC来分担负荷，而且基本无需人工干预。

1 楼 spell 2010-09-07  

楼主的意思其实就是利用数据库实时同步机制，用数据库集群，分散访问压力～，但是如果数据量增加的很快，那这个问题怎么解决呢？