实现一个分布式数据库（0）mydb的架构设想

之所以有自己实现一个分布式数据库的想法，源于组内的任务：在自研INM数据库上加入MongoDB的模块进行性能改善，首先要想清楚下列的问题。

要将MongoDB作为INM的下层数据库需要考虑：

1. MongoDB的沿用、INM的舍弃。
2. 修改后的访问流程。
3. 问题。
4. 尝试实现一个类MongoDB的分布式数据库。
   功能；整体架构；服务器架构；客户端架构；引擎

MongoDB的沿用、INM的舍弃

单纯地将MongoDB作为改善INM性能的一个手段，需要考虑沿用MongoDB哪些部分、舍弃INM本身哪些部分。

首先考虑INM：

为了保留INM的特色部分，直到逻辑层的INM执行接口之前的请求解析部分理应保留，要更改的部分为物理层的存储引擎以及与其相对应的逻辑层请求处理接口（因为请求处理往往是对应存储引擎写的）。

其次考虑MongoDB,两个方案：

1.增加一层INM的请求解析到MongoDB的query language和Data Model之上，也就是定义在MongoDB的逻辑层之上，将请求处理交给MongoDB。
这个方案使得INM更像是MongoDB某种语言的驱动程序。我们要做的就是将INM的模式/实例操作再封装成MongoDB的数据模型。
这样做将事务、存储都交给了MongoDB底层。分布式可以在MongoDB的架构上构想。

2.将INM的逻辑层请求处理与MongoDB的存储引擎相对应。
这个方案,MongoDB的影响就不大了，我们可以考虑其他的存储引擎。需要修改的是INM逻辑层对应存储层的一些请求处理函数。

修改后的访问流程

入口为封装了“INM驱动函数”的INM shell，可以是server，可以是client。
输入例如：query class $x construct $x;

如果采用第一个方案：

1. 首先通过第一层请求解析函数将INM查询语句的内容提取出来，经过第二层请求解析函数整合成MongoDB的查询语句->db.collection.find(）;
2. MongoDB再通过自己的请求处理函数去存储引擎中查找符合的内容；
3. 存储引擎取得匹配文档返回给MongoDB逻辑层；
4. MongoDB逻辑层再通过接口函数转化成INM的语句打印在屏幕上。

如果采用第二个方案：

1. 首先通过INM的请求解析函数将查询的内容提取出来；
2. 通过INM的请求处理函数到新的存储引擎中寻找符合的内容；
3. 存储引擎取得匹配内容返回给INM逻辑层；
4. INM逻辑层再通过接口函数打印在屏幕上。

问题

基于：再封装一次请求解析函数与直接更改存储引擎

1. 分别需要修改哪些内容。
2. 哪个对于性能来说影响更大。
3. 如何进行修改（请求解析；请求处理）。

类MongoDB的分布式数据库-mydb

功能

1. 面向文档，数据格式为JSON，底层存储格式为BSON。
2. 可以对数据进行CRUD，通过_id进行搜索。
3. 客户端支持多节点集群，数据按唯一_id散列至相应节点。

整体架构

服务端架构

请求解析：消息组件（消息协议控制）、进程模型组件（入口main函数、线程调度逻辑）。

请求处理：runtime(从PMD接受被解析好的请求，跟底层的DMS和IXM进行通讯读写数据)。

存储访问：数据管理服务、索引管理组件（散列索引）。

通用组件：操作系统服务、BSON数据结构、监控组件、问题诊断组件。

客户端架构

用户通过在Edb的cmd中输入命令。
命令经过命令工厂得到对应处理函数，进行CRUD。

引擎

工作流程：

1. PMD与OSS协作通过socket函数持续监听TCP的端口；

2. 当收到连接请求包时，会从线程调度池里分配一个线程接受端口的数据；

3. 这些请求数据会被发送到MSG，MSG将它们解析成系统可以懂的结构；

4. PMD会直接调用RTN，RTN会根据请求先调用IXM层，插入或者调用索引；

5. 再调用DMS层对数据进行相应操作。

   （右边的组件在所有模块中都会用到。）