解决海量数据的新思路——分布式数据库

先说一下产生这个分布式数据库的初衷吧，其实这是一个垂直搜索引擎中的一个基础组件，因为是一个摸索性的产品，不可能马上上马价值上百万的服务器，而单个数据节点显然又不能满足数据处理的需要，所以根据Map/Reduce的概念实现了这个东西。

下面是这个组件所使用的场景：

1、爬虫URL库：数据量目前接近千万，每天更新量应该3万~5万之间，有一定的频率需要进行扫表操作，例如选择下载时间段在某一天的URL，或者选择某个网站所有的URL，还有对URL字段进行like操作。

2、数据清理模块：需要读取整个数据库的所有数据，主要需要大规模读取，写入的能力。

3、网站访问：因为是垂直搜索引擎，经常需要select * from table where province='广东' 之类的语句，此时分布式的速度优势非常明显。另外，对于论坛，内容类网站这种简单的SQL语句的应用非常有效，甚至对于数据量不是很大的交易类网站都可以试试。


在设计这个组件的时候，想达到的效果是能够像mysql,mssql一样简单易用，使程序员在使用时并不需要知道如何进行分布式，让数据库自己完成这些工作，可惜由于SQL文法识别的问题，这一目的还无法完全实现，不过个人认为分布式的方式是一种可行的道路。

看了下图，我的设计和它非常像，呵呵……程序还没看，有空再研究下。

多表问题必须通过改造内核，在那个例子中，我想到的解决方法就是先归并所有的产品ID，用户ID，然后将归并后的数据copy到每个数据节点上，然后每个节点根据归并后的数据进行选择，这样就能得到正确的结果。但是，这样会消耗极大的内存，网络资源，分布式的优势荡然无存……这个问题我一直没有想到合理的解决方案，希望能得到大家的指点。

这个分布式数据库的精髓在于使用每一个节点的运算能力，对结果进行运算量不大的归并，排序，移除就能获得N个节点的运算能力。优势主要在于成本，速度，对于复杂的应用，目前来看还真是无法应用。

antlr我看了下，可以用上，多谢了，我用的是.NET，所以很多Java下的好东西都不知道……不得不感慨下开源的力量啊。

amoeba for mysql 采用java写得，但是它是分析mysql 协议得，对mysql得任何客户端都能够使用。

对不是用java写得应用也不会太大得影响的。

建议先去看看Oracle的发家史，从中看看“传统的”大型关系型数据库是怎么干掉网络数据库／对象数据库／分布式数据库成为市场上的主流的。

分布式数据库在计算机科学的领域早不是什么新鲜的东西，其年头跟关系数据库差不多。90年代以后，市场上关系型数据库一路高歌猛进，剩下的那些数据库在应用领域大多处于蛰伏状态。我对各种数据库技术并无偏见，只是建议楼主要是准备往这条路子上走的话，先了解一下前人成功失败的经验比较好。

垂直搜索引擎为什么要把数据存入数据库中呢？搜索引擎对数据存储的要求跟数据库有很大差别，用数据库会死得很难看。例如没有人会把倒排表存到数据库里，在这种前提下，实际上你所要做的是个分布式存储系统，建立这样一个系统，你的考虑是对的，但不需要对SQL之类的东西进行编译处理。只需要有个高性能的Broker能够转发其客户的查询请求到不同节点，并将各节点的返回结果做一个归并也就是reduce操作即可。由于reduce操作因此Broker需要等待，为了增加吞吐量，必须引入线程池，这样的Broker设计并不困难。 此外，为了提高性能，建议将cache考虑进去，关于这点有一篇非常有意思的paper: multiple range query optimization with distributed cache indexing， 里边用到了多维tree来实现分布式缓存。

大家都已否定方案为乐，否定当然有否定的理由，但我觉得这个做法没什么问题。

假如mysql数据很大，千万级别或者以上，需要横向保存在n台服务器，那我们就要面对跨服务器查询的。目前也没有非常成熟的方案，一般都是自己程序解决。

我以前也做个类似实现，已经在大型的系统中跑了很久了，没碰到什么问题。
http://hi.baidu.com/jabber/blog/item/adc442ed647adad4b31cb11e.html

目前还有一种类似实现叫HSCALE，可参考我的介绍。
http://hi.baidu.com/jabber/blog/item/978e9125c668f76534a80fab.html

呵呵，我觉得楼上各位说的对我都是有帮助的，算不上否定吧。

这个方案运行到现在，感觉还算是可以用的，好用就说不上了，最大的优点就是易用性和速度，缺点就是SQL解析那一块所产生的一系列问题。目前来看，最适用的场景就是高访问量的应用，例如登陆，论坛之类的，访问量大，语句简单，对速度要求高的场合。应用这个组件的好处就在于不需要编程人员有高超的技巧，因为组件已经提供了同正常SQL访问接口完全一致的CONNECTION类，ResultSet类，Statement类等，只要简单的应用便可以享受到分布式数据库的性能，而不需要对这些表都进行特殊的架构，降低了整个系统的复杂性。

恩，我也看过一些传统的分布式数据库理论，感觉想法是可行的，但是实际运用到工程中，很难。就我所看过的几本书上所描叙的分布式数据库，跨越的层面多，有很多理论致力于解决如何在这种复杂的环境下实现数据的安全，事物处理等问题上。我认为这些问题牵涉到的层面太多了，不仅仅是数据库一门学科，还有其他方面也要跟得上才行，例如网络的稳定性，传输速度，安全性等因素，都大大限制了分布式数据库的应用和发展。

这个组件没有考虑太多的阻碍因素，因为这个组件的运行环境是在网络环境非常好的局域网中，这样就规避了传统分布式数据库所遇到的一系列难题，注意力只要集中在各个节点数据交互的逻辑上。目前来看这个系统并没可能颠覆关系型数据库，它就是给关系型数据库提供了一层分布式的包装，让其享受到分布式的可扩展性，并行运算，低成本的好处。

可以看看www.kooxoo.com，这是一个很典型的垂直搜索引擎，但是用Lucene处理那样的问题，性能上并不一定会比关系型数据库好。例如，如果我想找上海酒店，价格在300~500之间。用Lucene处理，它会在内部形成类似这样的查询项：

地点：上海酒店
价格：300

地点：上海酒店
价格：301

…………

地点：上海酒店
价格：500

总共要生成200个这样的查询项，这是倒排索引的机制所限定的。这还算好，如果客户来个100~10000，Lucene就直接挂掉了，因为生成的查询项太多。这时候反而是关系型数据库处理会好些，如果数据量很大，那么就必须进行分布式来提高其反应速度。