关系型数据库遵循ACID规则

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

 

1、A (Atomicity) 原子性

 

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。

 

比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

 

2、C (Consistency) 一致性

 

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

 

例如现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。

 

3、I (Isolation) 独立性

 

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。

 

比如现在有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的。

 

4、D (Durability) 持久性

 

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

 

 

 

 

 

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

一致性(Consistency) (所有节点在同一时间具有相同的数据)

可用性(Availability) (保证每个请求不管成功或者失败都有响应)

分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

 

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

Basically Availble --基本可用

Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的

Eventual Consistency -- 最终一致性， 也是是 ACID 的最终目的。

 

 

 

 

 

 

NoSql优点：
1）查询速度：NoSql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。并且NOSQL是基于键值对的，查询只需要只要key即可查询出Value，并且不需要经过SQL解析
2）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。
3）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。NoSql可扩展性同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展，不需要预定义数据的存储模式。

缺点：
1）不提供对sql语句的支持，不支持复杂的数据查询

2）不提供关系型数据库对事务的处理。

 

关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。

 

关系型数据库的优势：

1.遵循ACID规则（一致性，原子性，持久性，独立性）

2.由于高度组织化结构化数据，因此数据更新的开销很小（相同的字段基本上都只有一处）

3.支持结构化查询语句（SQL）,可以进行Join等复杂查询

4.支持事务处理，使得对于安全性能很高的数据访问要求得以实现

其中能够保持数据的一致性是关系型数据库的最大优势。

 

关系型数据库的不足：

1. 大量数据的写入处理

2. 为有数据更新的表做索引或表结构（schema）变更

3. 字段不固定时应用

4. 对简单查询需要快速返回结果的处理

--大量数据的写入处理

读写集中在一个数据库上让数据库不堪重负，大部分网站已使用主从复制技术实现读写分离，以提高读写性能和读库的可扩展性。

所以在进行大量数据操作时，会使用数据库主从模式。数据的写入由主数据库负责，数据的读入由从数据库负责，可以比较简单地通过增加从数据库来实现规模化，但是数据的写入却完全没有简单的方法来解决规模化问题。

第一，要想将数据的写入规模化，可以考虑把主数据库从一台增加到两台，作为互相关联复制的二元主数据库使用，确实这样可以把每台主数据库的负荷减少一半，但是更新处理会发生冲突，可能会造成数据的不一致，为了避免这样的问题，需要把对每个表的请求分别分配给合适的主数据库来处理。

第二，可以考虑把数据库分割开来，分别放在不同的数据库服务器上，比如将不同的表放在不同的数据库服务器上，数据库分割可以减少每台数据库服务器上的数据量，以便减少硬盘IO的输入、输出处理，实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理，数据库分割的时候就需要预先考虑这些问题，数据库分割之后，如果一定要进行Join处理，就必须要在程序中进行关联，这是非常困难的。

 

 

--为有数据更新的表做索引或表结构变更

在使用关系型数据库时，为了加快查询速度需要创建索引，为了增加必要的字段就一定要改变表结构，为了进行这些处理，需要对表进行共享锁定，这期间数据变更、更新、插入、删除等都是无法进行的。如果需要进行一些耗时操作，例如为数据量比较大的表创建索引或是变更其表结构，就需要特别注意，长时间内数据可能无法进行更新。

 

--字段不固定时的应用

如果字段不固定，利用关系型数据库也是比较困难的，有人会说，需要的时候加个字段就可以了，这样的方法也不是不可以，但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段，但这样的话，时间一长很容易弄不清除字段和数据的对应状态，即哪个字段保存有哪些数据。

--对简单查询需要快速返回结果的处理  （这里的“简单”指的是没有复杂的查询条件）

这一点称不上是缺点，但不管怎样，关系型数据库并不擅长对简单的查询快速返回结果，因为关系型数据库是使用专门的sql语言进行数据读取的，它需要对sql进行解析，同时还有对表的锁定和解锁等这样的额外开销，这里并不是说关系型数据库的速度太慢，而只是想告诉大家若希望对简单查询进行高速处理，则没有必要非使用关系型数据库不可。

---------------------------

NoSQL数据库

关系型数据库应用广泛，能进行事务处理和表连接等复杂查询。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

优点：

 易于数据的分散

各个数据之间存在关联是关系型数据库得名的主要原因，为了进行join处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散，这也是关系型数据库并不擅长大数据量的写入处理的原因。相反NoSQL数据库原本就不支持Join处理，各个数据都是独立设计的，很容易把数据分散在多个服务器上，故减少了每个服务器上的数据量，即使要处理大量数据的写入，也变得更加容易，数据的读入操作当然也同样容易。

 

典型的NoSQL数据库

临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase）

一、 键值存储

它的数据是以键值的形式存储的，虽然它的速度非常快，但基本上只能通过键的完全一致查询获取数据，根据数据的保存方式可以分为临时性、永久性和两者兼具 三种。

（1）临时性

      所谓临时性就是数据有可能丢失，memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止时，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据，旧数据会丢失。总结来说：

      。在内存中保存数据

      。可以进行非常快速的保存和读取处理

      。数据有可能丢失

 （2）永久性

       所谓永久性就是数据不会丢失，这里的键值存储是把数据保存在硬盘上，与临时性比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的，但数据不会丢失是它最大的优势。总结来说：

       。在硬盘上保存数据

       。可以进行非常快速的保存和读取处理（但无法与memcached相比）

       。数据不会丢失

（3） 两者兼备

       Redis属于这种类型。Redis有些特殊，临时性和永久性兼具。Redis首先把数据保存在内存中，在满足特定条件（默认是 15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的键发生变更）的时候将数据写入到硬盘中，这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性，这种类型的数据库特别适合处理数组类型的数据。总结来说：

       。同时在内存和硬盘上保存数据

       。可以进行非常快速的保存和读取处理

       。保存在硬盘上的数据不会消失（可以恢复）

       。适合于处理数组类型的数据

     

二、面向文档的数据库

   MongoDB、CouchDB属于这种类型，它们属于NoSQL数据库，但与键值存储相异。

   （1）不定义表结构

　　   即使不定义表结构，也可以像定义了表结构一样使用，还省去了变更表结构的麻烦。

   （2）可以使用复杂的查询条件 

　　   跟键值存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据，虽然不具备事务处理和Join这些关系型数据库所具有的处理能力，但初次以外的其他处理基本上都能实现。

三、 面向列的数据库

   Cassandra、HBae、HyperTable属于这种类型，由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引入注目。

   普通的关系型数据库都是以行为单位来存储数据的，擅长以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被成为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。

面向列的数据库具有搞扩展性，即使数据增加也不会降低相应的处理速度（特别是写入速度），所以它主要应用于需要处理大量数据的情况。另外，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，故应用起来十分困难。

 

 

 

mongodb：

它是一个内存数据库，数据都是放在内存里面的。

对数据的操作大部分都在内存中，但mongodb并不是单纯的内存数据库。

持久化方式：

mongodb的所有数据实际上是存放在硬盘的，所有要操作的数据通过mmap的方式映射到内存某个区域内。

然后，mongodb就在这块区域里面进行数据修改，避免了零碎的硬盘操作。

至于mmap上的内容flush到硬盘就是操作系统的事情了，所以，如果，mongodb在内存中修改了数据后，mmap数据flush到硬盘之前，系统宕机了，数据就会丢失。

mmap详解链接：http://www.cnblogs.com/techdoc/archive/2010/12/22/1913521.html

redis：

它就是一个不折不扣的内存数据库了。

持久化方式：

redis所有数据都是放在内存中的，持久化是使用RDB方式或者aof方式。

解密redis持久化：http://blog.nosqlfan.com/html/3813.html

mysql：

无论数据还是索引都存放在硬盘中。到要使用的时候才交换到内存中。能够处理远超过内存总量的数据。

数据量和性能：

当物理内存够用的时候，redis>mongodb>mysql

当物理内存不够用的时候，redis和mongodb都会使用虚拟内存。

实际上如果redis要开始虚拟内存，那很明显要么加内存条，要么你换个数据库了。

但是，mongodb不一样，只要，业务上能保证，冷热数据的读写比，使得热数据在物理内存中，mmap的交换较少。

mongodb还是能够保证性能。有人使用mongodb存储了上T的数据。

mysql，mysql根本就不需要担心数据量跟内存下的关系。不过，内存的量跟热数据的关系会极大地影响性能表现。

当物理内存和虚拟内存都不够用的时候，估计除了mysql你没什么好选择了。

其实，从数据存储原理来看，我更倾向于将mongodb归类为硬盘数据库，但是使用了mmap作为加速的手段而已。

 

 

 

NoSQL数据库在以下的这几种情况下比较适用：

1、数据模型比较简单；

2、需要灵活性更强的IT系统；

3、对数据库性能要求较高；

4、不需要高度的数据一致性；

5、对于给定key，比较容易映射复杂值的环境。

 

 

 

 

 

数据库为什么用B+树而不用hash存储：

哈希文件也称为散列文件，是利用哈希存储方式组织的文件，亦称为直接存取文件。它类似于哈希表，即根据文件中关键字的特点，设计一个哈希函数和处理冲突的方法，将记录哈希到存储设备上。

在哈希文件中，是使用一个函数（算法）来完成一种将关键字映射到存储器地址的映射，根据用户给出的关键字，经函数计算得到目标地址，再进行目标的检索。

转自：http://imysql.com/2016/01/06/mysql-faq-different-between-btree-and-hash-index.shtml

B+树索引和哈希索引的区别

一个经典的B+树索引数据结构见下图：

(图片源自网络)

 

B+树服从 左节点 < 父节点 < 右节点；最底层叶子节点严格按照从小到大顺序排列。

B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接。

在B+树上的常规检索，从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动，而且基于索引的顺序扫描时，也可以利用双向指针快速左右移动，效率非常高。因此，B+树索引被广泛应用于数据库、文件系统等场景。

而哈希索引的示意图则是这样的：

(图片源自网络)

简单地说，哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。

从上面的图来看，B+树索引和哈希索引的明显区别是：

• 如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
• 从示意图中也能看到，如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
• 同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
• 哈希索引也不支持多列联合索引的最左匹配规则；
• B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。

后记

通常，B+树索引结构适用于绝大多数场景，像下面这种场景用哈希索引才更有优势：

在HEAP表中，如果存储的数据重复度很低（也就是说基数很大），对该列数据以等值查询为主，没有范围查询、没有排序的时候，特别适合采用哈希索引

例如这种SQL：
SELECT … FROM t WHERE C1 = ?; — 仅等值查询

在大多数场景下，都会有范围查询、排序、分组等查询特征，用B+树索引就可以了。

最后

以上就是丰富帽子为你收集整理的数据库分析与选择B+树索引和哈希索引的区别后记的全部内容，希望文章能够帮你解决数据库分析与选择B+树索引和哈希索引的区别后记所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。