Ⅰ 数据库的事务处理必须满足ACID原则，ACID分别是指什么
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
Ⅱ 数据库中的事务（Transaction）的ACID指的是什么
事务是由一组sql语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。
ACID是Atomic（原子性）
Consistency（一致性）
Isolation（隔离性）
Durability（持久性）的英文缩写。
Atomic（原子性）：指整个数据库事务是不可分割的工作单位。只有使据库中所有的操作执行成功，才算整个事务成功；事务中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。
Consistency（一致性）：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。
Isolation（隔离性）：指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。
Durability（持久性）：指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
Ⅲ 如何自己实现一个关系型数据库
对外数据模型为关系型数据库，内部的实现主要分成两大类，一类是disk-based，比如mysql，postgres，一类是memory based，后者包括MemSQL，SAP HAHA，OceanBase。看题目的意思指的是前者。这里说一个disk-based的关系型数据库涉及多少东西。
上世纪70/80年代内存不大，数据不能都放在内存里，大部分数据都存在磁盘上，读数据也需要从磁盘读，然而读写磁盘太慢了，所以就在内存里做了一个buffer pool，将已经读过的数据缓存到buffer pool中，写的时候也是写到buffer pool中就返回，buffer pool的功能就是管理数据在磁盘和内存的移动。在buffer pool中数据的管理单位是page。page大小一般几十KB。一般都可以配置。如果buffer pool中没有空闲的page，就需要将某一个page提出buffer pool，如果它是dirty page，就需要flush到磁盘，这里又需要一个LRU算法。一个page包含多条记录，page的格式需要设计用来支持变长字段。如果这时宕机了，buffer pool中的数据就丢了。这就需要REDO log，将对数据的修改先写到redo log中，然后写buffer pool，然后返回给客户端，随后，buffer pool中的dirty page会被刷到数据文件中(NO FORCE)。那么重启的时候，数据就能从redo log中恢复。REDO log还没刷完就刷数据到磁盘可以加快写入速度，缺点就是恢复的时候需要回放UNDO log，回滚一些还没有提交的事务的修改。写log又分为逻辑log和物理log，还有物理逻辑log。简单说逻辑log就是记录操作，比如将某个值从1改成2.而物理log记录具体到record的位置，例如某个page的某个record的某个field，原来的值是多少，新值是多少等。逻辑log的问题是并发情况下不太好恢复成一致。物理log对于某些操作比如create table又过于琐碎，所以一般数据库都采用混合的方式。为了跟踪系统中各种操作的顺序，这就需要为log分配id，记做LSN(log sequence number)。系统中记录各种LSN，比如pageLSN, flushedLSN等等。为了加快宕机恢复速度，需要定期写checkpoint，checkpoint就是一个LSN。
以上ACID里的C和D有关。下面说A和I，即原子性和隔离性。
这两个性质通过concurrency control来保证。隔离级别有很多种，最开始有4种，从低到高read uncommitted, read committed, repeatable read, serializable。serializable就是多个事务并发执行的结果和某种顺序执行事务的结果相同。除了serializable，其他都有各种问题。比如repeatable read有幻读问题(phantom)，避免幻读需要gap lock。read committed有幻读和不可重复读问题。后来又多了一些隔离级别，比如snapshot isolation，snapshot isolation也有write skew问题。早期，并发控制协议大多是基于两阶段锁来做的(2PL)，所以早期只有前面提到的四种隔离级别，后来，又出现一类并发控制协议，统称为Timestamp Ordering，所以又多了snapshot isolation等隔离级别。关于隔离级别，可以看看这篇论文 http://research.microsoft.com/pubs/69541/tr-95-51.pdf。2PL需要处理deadlock的问题。
Timestamp Ordering大体的思想就是认为事务之间冲突不大，不需要加锁，只在commit的时候check是否有冲突。属于一种乐观锁。
Timestamp Ordering具体来说包括多种，最常见的MVCC就是这类，还有一类叫做OCC(optimistic concurrency control)。MVCC就是对于事务的每次更新都产生新的版本，使用时间戳做版本号。读的时候可以读指定版本或者读最新的版本。几乎主流数据库都支持MVCC，因为MVCC读写互相不阻塞，读性能高。MySQL的回滚段就是用来保存老的版本。MVCC需要有后台线程来做不再需要的版本的回收工作。Postgres的vacuum就是做这事的。OCC和MVCC的区别是，OCC协议中，事务的修改保存在私有空间(比如客户端)，commit的时候再去检测冲突，通常的做法是事务开始时看一下自己要修改的数据的最后一次修改的时间戳，提交的时候去check是否这个时间戳变大了，如果是，说明被别人改过了，冲突。冲突后可以回滚或者重试。
上面这些搞定了就实现了数据库的核心，然后为了性能，需要index，通常有两种，一种支持顺序扫描B+Tree,还有一种是Hash Index。单条读适合用Hash Index,O(1)时间复杂度，顺序扫描只适合用B+Tree，O(logN)复杂度。然后，有些查询只需要扫描索引就能得到结果，有些查询直接扫描数据表就能得到结果，有些查询可以走二级索引，通过二级索引找到数据表然后得到结果。。具体用哪种方式就是优化器的事了。
再外围一些，关系型数据库自然需要支持SQL了，由SQL变成最后可以执行的物理执行计划中间又有很多步，首先SQL通过词法语法分析生成抽象语法树，然后planner基于这棵树生成逻辑执行计划，逻辑执行计划的生成通常涉及到等价谓词重写，子查询消除等逻辑层面的优化技术，优化的目的当然是性能。比如等价谓词重写，用大于小于谓词消除like，between .. and..等不能利用索引的谓词。下一步是逻辑执行计划生成物理执行计划，物理执行计划树每个节点是一个operator，operator的执行就是实实在在的操作，比如扫表的operator，filter opertor。一个逻辑执行计划通常可以有多个物理执行对应，选择哪个就涉及到物理执行计划优化，这里涉及到经典的cost model，综合考虑内存,CPU, I/O,网络等。最典型的，三表join，从左到右还是右到左，使用hash join，还是sort merge join等。
Ⅳ 数据库的问题：关系型数据库与非关系型数据库的区别，和各自的发展前景
当前主流的关系型数据库有Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等。
非关系型数据库有 NoSql、Cloudant。
nosql和关系型数据库比较
优点：
1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。
2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。
3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。
4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。
缺点：
1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。
2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本。
3）不提供关系型数据库对事物的处理。
关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。
关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付(在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memchache已经无能为力了)，因此，必须用新的一种数据结构存储来代替关系数据库。
关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大变动，这一点关系型数据库也难以应付，需要新的结构化数据存储。
于是，非关系型数据库应运而生，由于不可能用一种数据结构化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。