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

解决海量数据的新思路——分布式数据库 作者构思了一种分布式数据库的架构，并实现了其雏形，现在将其基本思路写出来，希望能起到抛砖引玉的作用。 目前，分布式的概念越来越流行，但是在数据库领域里，分布式的应用相对较少。在参阅了Google的Map/Reduce概念后，我构思了一种分布式数据库的架构，并实现了其雏形，现在将其基本思路写出来，希望能起到抛砖引玉的作用。 设计这个分布式数据库的目的在于快速的处理海量数据。基本思路其实很简单，将数据分布到多个数据节点中，在执行SQL语句时，分析SQL语句的语义，对一个或多个数据库进行操作。这样就可以使查询的压力分散到每一个节点上面，面对海量数据时的处理时间大大缩短。 先拿几个简单的SQL语句做分析，看看在分布式的环境下和平常有何不同。假设我们现在有两个数据节点A和B，表名为Table，其中ID为1~100的数据保存在节点A，ID为101~200的数据保存在节点B。以下的SQL语句都是同时对2个数据库执行。 Select * from Table where ID=1 这样A数据库将返回ID为1的数据，数据库B返回为空。这时简单的合并A和B的数据，就可以得到正确的结果。 Select top 10 * from Table 这时A数据库将返回10条数据，B数据库返回10条数据，这时如果合并A和B，将返回20条结果。这时必须移除多余的10条数据才是正确的结果。 Select * from Table order by ID 这时A，B数据库将返回所有的数据，但是要使得数据符合order by的条件，很显然应该进行一次排序操作。 Select top 10 * from Table order by ID 这时A，B数据库都返回10条数据，经过合并后，还要经过排序，移除的操作，才能确保结果正确。 SQL语句中需要处理的关键字还有max，min，count，sum，avg等，这里就不写出来了。经过这几个例子我们可以看到，其实只要经过一些处理，分别对不同数据节点上的查询，可以转化成对单一数据库查询等效的结果。而这些处理归纳起来，只有合并，排序，移除这三种情况，其实这和Map/Reduce思想非常的类似，无论什么复杂的动作，最终归结都可以通过几个简单操作来完成。这些处理当然需要一定的时间，但是在面对海量数据时，很多情况下，处理所需要的时间可以小到忽略不计。 上面只是一些简单的SQL语句，面对一些复杂的SQL语句，要在SQL语句处理的过程中，进行数据节点之间的数据交换才能完成的（例子在文末会给出）。因此要实现一个完全能够处理SQL语句的分布式数据库，需要在数据库的内核部分进行改动。在实现这个组件时，时间是有限的，进行内核部分的改造不现实，所以我采取了中间件的方式，来实现了这个分布式数据库的雏形，采用的数据库是MSSQL2000，下图是我设计的分布式数据库的概念图（参见附件1）： 如图所示，数据根据一定规则分布（一般可以直接Hash主键）到每一个数据节点中，由分布式数据库服务器对每个数据节点进行访问，进行归并/排序/移除操作，然后通过数据接口，返回给程序。 其中几个数据接口所适用的场景为： Reader：提供对数据库的查询结果，逐条进行读取的接口。在海量数据下，有时候需要读取大量数据进行处理，如果一次读取到内存中显然不现实。此时可以使用Reader模式逐条读取，进行分批处理。 DataFiller：提供对数据的XML包装，适用于小数据量的读取，主要是给Web应用提供一个方便的接口。 Command：执行delete，update，insert等不返回数据的SQL语句。 BulkCopy：批量插入接口。主要是为大数据量的导入提供高速接口。 实现这个中间件，难点应该是在SQL语句的语义分析上。这块应该使用编译原理来实现，但是在我的实现中，并没有用到，原因一个是时间问题，另外一个是因为基于中间件的方式，对一些复杂的SQL语句无法得到正确的结果。所以使用了正则表达式和一些方法来对SQL语句进行分析，分析出应该如何对执行结果进行处理，以及SQL语句应该发送到单个节点还是多个节点。以下是处理的流程示意图（参见附件2）： 在实现时需要注意的地方是，一定要让SQL语句从发送到执行，到返回结果之间没有任何延迟，否则每秒能够执行的SQL语句最多只有几十条。一开始我使用的模型是很常见的查询线程模型（参见附件3）： 每个语句执行完毕之后，在HashMap中将执行状态设置为执行完毕。使用一个查询线程，不断的遍历HashMap，发现有执行完毕的语句，便将其发往结果处理模块。为了避免CPU占用率100%，查询线程必须要有Sleep语句，但是windows下线程轮切的最小时间段为15ms，并且在