背景：
it民工一枚，做过java开发，数据库运维，也搞过hadoop，可能是这些经验的结合吧，最近一年一直有个使用mapreduce计算思想的分布式数据库的想法和实践。
思想：
使用分库分表的思想实现数据存储
使用mapreduce的思想实现计算
架构图：
组件：
客户端 （ client ）
主控机 （ master ）
元信息数据库 （ meta database ）：系统的基本信息，表的信息，等
存储节点 （ store node ）：数据的存储节点，增删改操作的数据都位于存储节点上
计算节点 （ calculate node ）：reduce执行的节点
数据存储过程：
- 当插入数据的时候，根据分表规则将记录插入到对应的数据库节点中。
- 当更新数据的时候，根据分表规则判断源数据库节点和目标数据库节点是否变化，如果没有变化，直接更新；如果有变化，在源数据库节点中删除老数据，在目标数据库节点中插入新数据。
- 当删除数据的时候，根据分表规则在相应的数据库节点中删除。
计算过程：
对于一个job，输入是sql（select），经过解析，集合表结构和数据分布的元信息，生成包含多个阶段( stage )的执行计划（ execution plan ），它是一棵多输入单输出的阶段树（ stage tree ），每个阶段包括三个操作，map 执行 mapsql，数据洗牌 ,reduce 执行 reducesql。
计算的过程就是运行执行计划，如下图所示。
优点和特征：
- 数据存储在数据库中，而不是hdfs中；使用mapreduce大数据的计算思想实现夸数据库节点的计算
- 表的数据根据字段实现分区：如hash，range，hash和range结合
- 支持多节点增删改：通过二阶段提交尽量保证事物一致性，相比hdfs删除和修改一般比较麻烦和低效
- 支持多节点查询：子查询，join，union 等复杂查询
- 线上系统（主系统）和线下的数据分析挖掘（从系统）做成统一的方案，相比使用hadoop而言，避免数据同步的麻烦，保证实现同步的及时性
- 充分利用数据库的索引和缓存机制，加快查询速度，特别是表数据量非常大，只需要返回少量数据的情形
- 相比hdfs来说，数据的分布是有规则的，hdfs需要启动之后执行命令去查询文件具体在什么节点上；在有些地方可以做的更好，在分布式全文索引中可以体现
例子：
