数据库存储引擎学习总结

た入场券 2022-06-13 07:26 193阅读 0赞

# 什么是存储引擎以及不同存储引擎特点 #

http://www.cnblogs.com/wildfox/p/5815414.html  
　　以前一直玩Oracle数据库，整天围着业务需求和执行计划转，刚刚接触Mysql看到存储引擎不慎理解，相应会有与我相同人群存在，所以写文以记之。  
  
  
　　首先简单从字面理解，想当是与磁盘打交道的，实际情况也是如此。一个数据库系统可以随意切换不同的存储引擎，也就是说随意选择写磁盘或操作磁盘的方式，觉得还是很牛掰的，所以这里看下Mysql的体系结构。  
  
  
　　MySQL服务器采用了多层设计和独立模块，插件式存储引擎体系结构，允许将存储引擎加载到正在运新的MySQL服务器中，图中的Pluggable Storage Engines部分。采用MySQL服务器体系结构，由于在存储级别上（也就是Pluggable Storage Engines）提供了一致和简单的应用模型和API，应用程序编程人员和DBA可不再考虑所有的底层实施细节。因此，尽管不同的存储引擎具有不同的能力，应用程序是与之分离的。存储引擎就司职与文件系统打交道了。  
  
  
　　到这里对与存储引擎的定位以及功能应该是基本了解的，接下来的疑问就是，有没有必要。很有必要的，因为一下罗列的内容是存储引擎处理的事情：  
  
  
并发性：某些应用程序比其他应用程序具有很多的颗粒级锁定要求（如行级锁定）。  
事务支持：并非所有的应用程序都需要事务，但对的确需要事务的应用程序来说，有着定义良好的需求，如ACID兼容等。  
引用完整性：通过DDL定义的 外键，服务器需要强制保持关联数据库的引用完整性。  
物理存储：它包括各种各样的事项，从表和索引的总的页大小，到存储数据所需的格式，到物理磁盘。  
索引支持：不同的应用程序倾向于采用不同的索引策略，每种存储引擎通常有自己的编制索引方法，但某些索引方法（如B-tree索引）对几乎所有的存储引擎来说是共同的。  
内存高速缓冲：与其他应用程序相比，不同的应用程序对某些内存高速缓冲策略的响应更好，因此，尽管某些内存高速缓冲对所有存储引擎来说是共同的（如用于用户连接的高速缓冲，MySQL的高速查询高速缓冲等），其他高速缓冲策略仅当使用特殊的存储引擎时才唯一定义。  
性能帮助：包括针对并行操作的多I/O线程，线程并发性，数据库检查点，成批插入处理等。  
其他目标特性：可能包括对地理空间操作的支持，对特定数据处理操作的安全限制等。  
以上要求会在不同的需求中予以体现，通过单独一个系统实现是不可能的，以上特点有些本身就是相互矛盾的，鱼和熊掌的问题。对以上内容做些选择，形成的存储引擎就是一个插件引擎了，某些特定的需求可以使用。如下图，部分现有的存储引擎以及基本特点：  
  
  
　　至此，应该对存储引擎有一个直观的印象了。对了，还有一点需要格外注意的： Mysql中不同的表可以指定不同的存储引擎，也就是说一套Mysql服务器可以同时使用N种不同的存储引擎，甚至自己写一个。  
========

# 三种基本的存储引擎比较 #

http://blog.csdn.net/kobejayandy/article/details/51064268  
1、Hash存储引擎  
  
  
代表数据库：Redis、memcache等  
  
  
通常也常见于其他存储引擎的查找速度优化上。 Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端。  
  
  
这里列举缺点：  
  
  
（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。  
（2）Hash 索引无法被用来避免数据的排序操作。  
（3）Hash 索引不能利用部分索引键查询。  
(4）Hash 索引在任何时候都不能避免表扫描。  
Hash碰撞，就是链式扫描：  
由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。  
（5）Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。  
  
  
2、B树存储引擎  
  
  
代表数据库：MongoDB、mysql(基本上关系型数据库)等  
\\  
  
  
还有一种算是B树存储引擎：COLA树（CacheObliviousBTree）  
  
  
代表数据库：tokudb  
  
  
为了如何让B树更有效的执行，他们提出了一个缓存忘却CacheOblivious算法，该算法在不需要明确知道存储器层次中数据传输规模的情况下，也可以高效的工作。更多请参见：http://en.wikipedia.org/wiki/Cache-oblivious\_algorithm。  
  
  
说个大家熟悉的名称TokuMX : 目前非常流行的NoSQL数据库mongodb的底层替换成与TokuDB同样的存储引擎\[ ToKuMx\]，达到了非常好的效 果  
  
  
3、LSM树（Log-Structured Merge Tree）存储引擎  
  
  
代表数据库：nessDB、leveldb、Hbase等  
  
  
核心思想的核心就是放弃部分读能力，换取写入的最大化能力。LSM Tree ，这个概念就是结构化合并树的意思，它的核心思路其实非常简单，就是假定内存足够大，因此不需要每次有数据更新就必须将数据写入到磁盘中，而可以先将最新的数据驻留在磁盘中，等到积累到最后多之后，再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的，可以通过合并排序的方式快速合并到一起)。  
  
  
日志结构的合并树（LSM-tree）是一种基于硬盘的数据结构，与B-tree相比，能显著地减少硬盘磁盘臂的开销，并能在较长的时间提供对文件的高速插入（删除）。然而LSM-tree在某些情况下，特别是在查询需要快速响应时性能不佳。通常LSM-tree适用于索引插入比检索更频繁的应用系统。Bigtable在提供Tablet服务时，使用GFS来存储日志和SSTable，而GFS的设计初衷就是希望通过添加新数据的方式而不是通过重写旧数据的方式来修改文件。而LSM-tree通过滚动合并和多页块的方法推迟和批量进行索引更新，充分利用内存来存储近期或常用数据以降低查找代价，利用硬盘来存储不常用数据以减少存储代价。  
  
  
磁盘的技术特性:对磁盘来说，能够最大化的发挥磁盘技术特性的使用方式是:一次性的读取或写入固定大小的一块数据，并尽可能的减少随机寻道这个操作的次数。  
\\  
   
LSM和Btree差异就要在读性能和写性能进行舍和求。在牺牲的同事，寻找其他方案来弥补。  
  
  
1、LSM具有批量特性，存储延迟。当写读比例很大的时候（写比读多），LSM树相比于B树有更好的性能。因为随着insert操作，为了维护B树结构，节点分裂。读磁盘的随机读写概率会变大，性能会逐渐减弱。 多次单页随机写，变成一次多页随机写,复用了磁盘寻道时间，极大提升效率。  
  
  
2、B树的写入过程:对B树的写入过程是一次原位写入的过程，主要分为两个部分，首先是查找到对应的块的位置，然后将新数据写入到刚才查找到的数据块中，然后再查找到块所对应的磁盘物理位置，将数据写入去。当然，在内存比较充足的时候，因为B树的一部分可以被缓存在内存中，所以查找块的过程有一定概率可以在内存内完成，不过为了表述清晰，我们就假定内存很小，只够存一个B树块大小的数据吧。可以看到，在上面的模式中，需要两次随机寻道（一次查找，一次原位写），才能够完成一次数据的写入，代价还是很高的。  
  
  
3、LSM Tree放弃磁盘读性能来换取写的顺序性，似乎会认为读应该是大部分系统最应该保证的特性，所以用读换写似乎不是个好买卖。但别急，听我分析一下。  
  
  
a、内存的速度远超磁盘，1000倍以上。而读取的性能提升，主要还是依靠内存命中率而非磁盘读的次数  
b、写入不占用磁盘的io，读取就能获取更长时间的磁盘io使用权，从而也可以提升读取效率。例如LevelDb的SSTable虽然降低了了读的性能，但如果数据的读取命中率有保障的前提下，因为读取能够获得更多的磁盘io机会，因此读取性能基本没有降低，甚至还会有提升。而写入的性能则会获得较大幅度的提升，基本上是5~10倍左右。  
  
  
下面说说详细例子:  
  
  
LSM Tree弄了很多个小的有序结构，比如每m个数据，在内存里排序一次，下面100个数据，再排序一次……这样依次做下去，我就可以获得N/m个有序的小的有序结构。  
  
  
在查询的时候，因为不知道这个数据到底是在哪里，所以就从最新的一个小的有序结构里做二分查找，找得到就返回，找不到就继续找下一个小有序结构，一直到找到为止。  
  
  
很容易可以看出，这样的模式，读取的时间复杂度是(N/m)\*log2N 。读取效率是会下降的。  
  
  
这就是最本来意义上的LSM tree的思路。那么这样做，性能还是比较慢的，于是需要再做些事情来提升，怎么做才好呢？  
  
  
LSM Tree优化方式：  
  
  
a、Bloom filter: 就是个带随即概率的bitmap,可以快速的告诉你，某一个小的有序结构里有没有指定的那个数据的。于是就可以不用二分查找，而只需简单的计算几次就能知道数据是否在某个小集合里啦。效率得到了提升，但付出的是空间代价。  
  
  
b、compact:小树合并为大树:因为小树他性能有问题，所以要有个进程不断地将小树合并到大树上，这样大部分的老数据查询也可以直接使用log2N的方式找到，不需要再进行(N/m)\*log2n的查询了  
========

# MySQL数据库中存储引擎的详解 #

http://blog.csdn.net/stormbjm/article/details/12033795   
关键字：  
　　存储引擎是什么？  
  
  
　　MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。  
  
  
　　例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)。  
  
  
　　这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型)。mysql默认配置了许多不同的存储引擎，可以预先设置或者在MySQL服务器中启用。你可以选择适用于服务器、数据库和表格的存储引擎，以便在选择如何存储你的信息、如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性。  
  
  
　　选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因。其它数据库系统(包括大多数商业选择)仅支持一种类型的数据存储。遗憾的是，其它类型的数据库解决方案采取的“一个尺码满足一切需求”的方式意味着你要么就牺牲一些性能，要么你就用几个小时甚至几天的时间详细调整你的数据库。使用MySQL，我们仅需要修改我们使用的存储引擎就可以了。  
  
  
　　在这篇文章中，我们不准备集中讨论不同的存储引擎的技术方面的问题(尽管我们不可避免地要研究这些因素的某些方面)，相反，我们将集中介绍这些不同的引擎分别最适应哪种需求和如何启用不同的存储引擎。为了实现这个目的，在介绍每一个存储引擎的具体情况之前，我们必须要了解一些基本的问题。  
  
  
　　如何确定有哪些存储引擎可用  
  
  
　　你可以在MySQL(假设是MySQL服务器4.1.2以上版本)中使用显示引擎的命令得到一个可用引擎的列表。  
  
  
　　mysql> show engines; +------------+---------+------------------------------------------------------------+ | Engine | Support | Comment | +------------+---------+------------------------------------------------------------+ | MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | | HEAP | YES | Alias for MEMORY | | MEMORY | YES | Hash based, stored in memory, useful for temporary tables | | MERGE | YES | Collection of identical MyISAM tables | | MRG\_MYISAM | YES | Alias for MERGE | | ISAM | NO | Obsolete storage engine, now replaced by MyISAM | | MRG\_ISAM | NO | Obsolete storage engine, now replaced by MERGE | | InnoDB | YES | Supports transactions, row-level locking, and foreign keys | | INNOBASE | YES | Alias for INNODB | | BDB | NO | Supports transactions and page-level locking | | BERKELEYDB | NO | Alias for BDB | | NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables | | NDB | NO | Alias for NDBCLUSTER | | EXAMPLE | NO | Example storage engine | | ARCHIVE | NO | Archive storage engine | | CSV | NO | CSV storage engine | +------------+---------+------------------------------------------------------------+ 16 rows in set (0.01 sec) 这个表格显示了可用的数据库引擎的全部名单以及在当前的数据库服务器中是否支持这些引擎。  
  
  
　　对于MySQL 4.1.2以前版本，可以使用mysql> show variables like "have\_%"(显示类似“have\_%”的变量):  
  
  
　　mysql> show variables like "have\_%"; +------------------+----------+ | Variable\_name | Value | +------------------+----------+ | have\_bdb | YES | | have\_crypt | YES | | have\_innodb | DISABLED | | have\_isam | YES | | have\_raid | YES | | have\_symlink | YES | | have\_openssl | YES | | have\_query\_cache | YES | +------------------+----------+ 8 rows in set (0.01 sec) 你可以通过修改设置脚本中的选项来设置在MySQL安装软件中可用的引擎。如果你在使用一个预先包装好的MySQL二进制发布版软件，那么，这个软件就包含了常用的引擎。然而，需要指出的是，如果你要使用某些不常用的引擎，特别是CSV、RCHIVE(存档)和BLACKHOLE(黑洞)引擎，你就需要手工重新编译MySQL源码 。  
  
  
　　使用一个指定的存储引擎  
  
  
　　你可以使用很多方法指定一个要使用的存储引擎。最简单的方法是，如果你喜欢一种能满足你的大多数数据库需求的存储引擎，你可以在MySQL设置文件中设置一个默认的引擎类型(使用storage\_engine 选项)或者在启动数据库服务器时在命令行后面加上--default-storage-engine或--default-table-type选项 。  
  
  
　　更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎。最直接的方式是在创建表时指定存储引擎的类型，向下面这样:  
  
  
　　CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB  
  
  
　　你还可以改变现有的表使用的存储引擎，用以下语句:  
  
  
　　ALTER TABLE mytable ENGINE = MyISAM  
  
  
　　然而，你在以这种方式修改表格类型的时候需要非常仔细，因为对不支持同样的索引、字段类型或者表大小的一个类型进行修改可能使你丢失数据。如果你指定一个在你的当前的数据库中不存在的一个存储引擎，那么就会创建一个MyISAM(默认的)类型的表.  
  
  
　　各存储引擎之间的区别  
  
  
　　为了做出选择哪一个存储引擎的决定，我们首先需要考虑每一个存储引擎提供了哪些不同的核心功能。这种功能使我们能够把不同的存储引擎区别开来。我们一般把这些核心功能分为四类:支持的字段和数据类型、锁定类型、索引和处理。一些引擎具有能过促使你做出决定的独特的功能，我们一会儿再仔细研究这些具体问题。  
  
  
　　字段和数据类型  
  
  
　　虽然所有这些引擎都支持通用的数据类型，例如整型、实型和字符型等，但是，并不是所有的引擎都支持其它的字段类型，特别是BLOG(二进制大对象)或者TEXT文本类型。其它引擎也许仅支持有限的字符宽度和数据大小。  
  
  
　　这些局限性可能直接影响到你可以存储的数据，同时也可能会对你实施的搜索的类型或者你对那些信息创建的索引产生间接的影响。这些区别能够影响你的应用程序的性能和功能，因为你必须要根据你要存储的数据类型选择对需要的存储引擎的功能做出决策。  
  
  
　　锁定  
  
  
　　数据库引擎中的锁定功能决定了如何管理信息的访问和更新。当数据库中的一个对象为信息更新锁定了，在更新完成之前，其它处理不能修改这个数据(在某些情况下还不允许读这种数据)。  
  
  
　　锁定不仅影响许多不同的应用程序如何更新数据库中的信息，而且还影响对那个数据的查询。这是因为查询可能要访问正在被修改或者更新的数据。总的来说，这种延迟是很小的。大多数锁定机制主要是为了防止多个处理更新同一个数据。由于向数据中插入信息和更新信息这两种情况都需要锁定，你可以想象，多个应用程序使用同一个数据库可能会有很大的影响。  
  
  
　　不同的存储引擎在不同的对象级别支持锁定，而且这些级别将影响可以同时访问的信息。得到支持的级别有三种:表锁定、块锁定和行锁定。支持最多的是表锁定，这种锁定是在MyISAM中提供的。在数据更新时，它锁定了整个表。这就防止了许多应用程序同时更新一个具体的表。这对应用很多的多用户数据库有很大的影响，因为它延迟了更新的过程。  
  
  
　　页级锁定使用Berkeley DB引擎，并且根据上载的信息页(8KB)锁定数据。当在数据库的很多地方进行更新的时候，这种锁定不会出现什么问题。但是，由于增加几行信息就要锁定数据结构的最后8KB，当需要增加大量的行，也别是大量的小型数据，就会带来问题。  
  
  
　　行级锁定提供了最佳的并行访问功能，一个表中只有一行数据被锁定。这就意味着很多应用程序能够更新同一个表中的不同行的数据，而不会引起锁定的问题。只有InnoDB存储引擎支持行级锁定。  
  
  
　　建立索引  
  
  
　　建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能。不同的存储引擎提供不同的制作索引的技术。有些技术也许会更适合你存储的数据类型。  
  
  
　　有些存储引擎根本就不支持索引，其原因可能是它们使用基本表索引(如MERGE引擎)或者是因为数据存储的方式不允许索引(例如FEDERATED或者BLACKHOLE引擎)。  
  
  
　　事务处理  
  
  
　　事务处理功能通过提供在向表中更新和插入信息期间的可靠性。这种可靠性是通过如下方法实现的，它允许你更新表中的数据，但仅当应用的应用程序的所有相关操作完全完成后才接受你对表的更改。例如，在会计处理中每一笔会计分录处理将包括对借方科目和贷方科目数据的更改，你需要要使用事务处理功能保证对借方科目和贷方科目的数据更改都顺利完成，才接受所做的修改。如果任一项操作失败了，你都可以取消这个事务处理，这些修改就不存在了。如果这个事务处理过程完成了，我们可以通过允许这个修改来确认这个操作。  
  
  
　　至此为止，我们介绍了MySQL存储引擎的相关基本概念，在下一篇文章里，我们会分别介绍各种MySQL存储引擎。  
  
  
http://soft.chinabyte.com/database/52/12609052.shtml  
========

# Oracle怎样查看存储引擎 #

Orace不像MySQL，没有专门的存储引擎这样的概念。