理想的分布式数据库

听闻阿里巴巴为了省钱，用大量跑着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秒钟以后才出现在买家的搜索结果里是允许的。
比如按地区查询，可以利用分区建表机制，优化查询。


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

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

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

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

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

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

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

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

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

Greenplum 的OLTP优化正在开发中。

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

集群和分布式是两码事

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

可以看看Amoeba

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

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

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

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

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