概述：
NuoDB 是一款新生的面向云的数据库，它支持完整的sql语句，基于MVCC的事务（ACID），同时可以优雅的伸缩性，方便地添加或删除节点。
官网 http://www.nuodb.com/
（在官网可以下载到应用程序和绿皮书，绿皮书在架构方面介绍的很详细）
基本结构拓扑：
NuoDB的核心是 Transaction Engine(TE) 和 Storage Manager(SM)。 NuoDB集群至少需要有1个TE和1个SM。
TE： 负责 parse, compile, optimize, execute 客户的sql语句 （有点类似NDB里面的sql节点）。
SM： 负责数据的持久化，它本身不执行SQL。
TE 和SM 的部署没有任何限制， 可以部署多个，在不同的机器上。
每个部署TE和SM的机器都有个 Agent/Broker 进程。
Agent 负责启动NuoDB集群在该机器的其他进程，如TE/SM， 并且搜集这些进程的统计信息。
Broker 是一个Agent，不同的是它还负责分发客户端的请求到某个TE。
NuoDB的Atom：
Atom是NuoDB的组织架构的基础。 NuoDB中所有的事务管理，数据存储，包括索引等数据库对象都是Atom。
Atom是自治的（不清楚这个自治是怎么弄得，应该不是一个atom一个线程吧，比较可能是有个线程从消息队列中取消息并分发给worker执行这个消息），它通过TE和SM间的消息通信机制与其他Atom交互。
每个Atom都有一个id和1个或多个的copy（自己也是一个copy，所以至少一个）。
Atom的所有copy之间通过异步的消息进行"change replicate"并确保各个copy数据的最终一致性（与NOSQL的最近一致性不同的事，异步replicate并不影响事务所看到的数据视图一致性，个人认为是通过Atom chairman实现的， Atom chairman后面会介绍）。
Atom的copy中会有一个chairman负责id分配和copy间update的冲突处理（后面会介绍它如何进行多版本控制）。
主要的Atom有：
1. Master Catalog Atom
2. Transaction Manager Atom （TMA）
3. Table Atom
4. Table Catalog Atom
5. Record Atom
6. Data Atom
7. Index Atom
NuoDB的事务：
NuoDB是支持 MVCC多版本的，官方说MVCC的实现和PostgreSQL挺像。
在事务的过程中NuoDB不会像INNODB那样在整个事务中持有锁，所有的写冲突都是通过Atom的chairman通过行版本比较来处理。
NuoDB的MVCC实现目前有两个特点：
1. 一个事务只会在一个TE中执行 （据说后面版本会改进）
2. 在一个事务被正式提交的消息广播出去前，该事务的所有变更信息已经发送到相关Atom的所有copy。
下面是一个MVCC中写冲突处理的例子：
假设事务10000 和事务11111想要修改行22222， 行22222所属的Record Atom的chairman为88888.
每个事务首先会修改本地的record atom copy， 然后本地record atom chairman请求修改许可
1. 事务10000所修改的Record Atom向Record Atom 88888发送请求 （我是事务10000，我想修改行22222，我所看到的最后一个提交事务号为10001）
2. Record Atom 88888检查行22222的最新提交事务号，发现确实是10001，并且没有其他正在修改的事务，于是回复事务10000所修改的Record Atom （ok）
3. 事务11111所修改的Record Atom向Record Atom 88888发送请求 （我是事务111111，我想修改行22222，我所看到的最后一个提交事务号为10001）
4. Record Atom 88888检查行22222的最新提交事务号，发现事务10000正在修改，于是回复事务11111所修改的Record Atom （你必须等待事务10000）.
如果最后事务10000提交成功，它通知所有的TMA， 事务11111所在的TMA会告知事务11111（你的修改失败了）。
涉及到事务就涉及到死锁的问题，NuoDB支持 死锁检测：
当一个事务被告知它需要等待另一个事务的时候， 它会向它所等待的事务以及所有等它的事务的TMA发送消息(我是事务xxx，我在等待事务yyy)。 这样每个TMA都会维护一个事务等待拓扑，如果发现有环，就牺牲掉事务号最大的事务，并告知它的用户一个错误消息“dead-lock error”。
数据的持久话策略：
SM保存的数据是key/value对，key是atom的标识，value是atom的序列化。
当Atom的最后一个copy从TE中删除前，SM要确保将该Atom的最新信息写盘。
SM每次接到commit请求时，会通过实时direct IO直接写日志，而commit的数据则是被放入写队列，一批一批地写。
（个人觉得这个持久话策略，有点像一些主内存的NOSQL数据库，比如HBase的sstable的实现方式）
NuoDB 是一款新生的面向云的数据库，它支持完整的sql语句，基于MVCC的事务（ACID），同时可以优雅的伸缩性，方便地添加或删除节点。
官网 http://www.nuodb.com/
（在官网可以下载到应用程序和绿皮书，绿皮书在架构方面介绍的很详细）
基本结构拓扑：
NuoDB的核心是 Transaction Engine(TE) 和 Storage Manager(SM)。 NuoDB集群至少需要有1个TE和1个SM。
TE： 负责 parse, compile, optimize, execute 客户的sql语句 （有点类似NDB里面的sql节点）。
SM： 负责数据的持久化，它本身不执行SQL。
TE 和SM 的部署没有任何限制， 可以部署多个，在不同的机器上。
每个部署TE和SM的机器都有个 Agent/Broker 进程。
Agent 负责启动NuoDB集群在该机器的其他进程，如TE/SM， 并且搜集这些进程的统计信息。
Broker 是一个Agent，不同的是它还负责分发客户端的请求到某个TE。
NuoDB的Atom：
Atom是NuoDB的组织架构的基础。 NuoDB中所有的事务管理，数据存储，包括索引等数据库对象都是Atom。
Atom是自治的（不清楚这个自治是怎么弄得，应该不是一个atom一个线程吧，比较可能是有个线程从消息队列中取消息并分发给worker执行这个消息），它通过TE和SM间的消息通信机制与其他Atom交互。
每个Atom都有一个id和1个或多个的copy（自己也是一个copy，所以至少一个）。
Atom的所有copy之间通过异步的消息进行"change replicate"并确保各个copy数据的最终一致性（与NOSQL的最近一致性不同的事，异步replicate并不影响事务所看到的数据视图一致性，个人认为是通过Atom chairman实现的， Atom chairman后面会介绍）。
Atom的copy中会有一个chairman负责id分配和copy间update的冲突处理（后面会介绍它如何进行多版本控制）。
主要的Atom有：
1. Master Catalog Atom
2. Transaction Manager Atom （TMA）
3. Table Atom
4. Table Catalog Atom
5. Record Atom
6. Data Atom
7. Index Atom
NuoDB的事务：
NuoDB是支持 MVCC多版本的，官方说MVCC的实现和PostgreSQL挺像。
在事务的过程中NuoDB不会像INNODB那样在整个事务中持有锁，所有的写冲突都是通过Atom的chairman通过行版本比较来处理。
NuoDB的MVCC实现目前有两个特点：
1. 一个事务只会在一个TE中执行 （据说后面版本会改进）
2. 在一个事务被正式提交的消息广播出去前，该事务的所有变更信息已经发送到相关Atom的所有copy。
下面是一个MVCC中写冲突处理的例子：
假设事务10000 和事务11111想要修改行22222， 行22222所属的Record Atom的chairman为88888.
每个事务首先会修改本地的record atom copy， 然后本地record atom chairman请求修改许可
1. 事务10000所修改的Record Atom向Record Atom 88888发送请求 （我是事务10000，我想修改行22222，我所看到的最后一个提交事务号为10001）
2. Record Atom 88888检查行22222的最新提交事务号，发现确实是10001，并且没有其他正在修改的事务，于是回复事务10000所修改的Record Atom （ok）
3. 事务11111所修改的Record Atom向Record Atom 88888发送请求 （我是事务111111，我想修改行22222，我所看到的最后一个提交事务号为10001）
4. Record Atom 88888检查行22222的最新提交事务号，发现事务10000正在修改，于是回复事务11111所修改的Record Atom （你必须等待事务10000）.
如果最后事务10000提交成功，它通知所有的TMA， 事务11111所在的TMA会告知事务11111（你的修改失败了）。
涉及到事务就涉及到死锁的问题，NuoDB支持 死锁检测：
当一个事务被告知它需要等待另一个事务的时候， 它会向它所等待的事务以及所有等它的事务的TMA发送消息(我是事务xxx，我在等待事务yyy)。 这样每个TMA都会维护一个事务等待拓扑，如果发现有环，就牺牲掉事务号最大的事务，并告知它的用户一个错误消息“dead-lock error”。
数据的持久话策略：
SM保存的数据是key/value对，key是atom的标识，value是atom的序列化。
当Atom的最后一个copy从TE中删除前，SM要确保将该Atom的最新信息写盘。
SM每次接到commit请求时，会通过实时direct IO直接写日志，而commit的数据则是被放入写队列，一批一批地写。
（个人觉得这个持久话策略，有点像一些主内存的NOSQL数据库，比如HBase的sstable的实现方式）
扫一扫
1001
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
