什么是存儲引擎以及不同存儲引擎特點

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樹塊大小的數據吧?？梢钥吹?#xff0c;在上面的模式中，需要兩次隨機尋道（一次查找，一次原位寫），才能夠完成一次數據的寫入，代價還是很高的。


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文本類型。其它引擎也許僅支持有限的字符寬度和數據大小。


　　這些局限性可能直接影響到你可以存儲的數據，同時也可能會對你實施的搜索的類型或者你對那些信息創建的索引產生間接的影響。這些區別能夠影響你的應用程序的性能和功能，因為你必須要根據你要存儲的數據類型選擇對需要的存儲引擎的功能做出決策。


　　鎖定


　　數據庫引擎中的鎖定功能決定了如何管理信息的訪問和更新。當數據庫中的一個對象為信息更新鎖定了，在更新完成之前，其它處理不能修改這個數據(在某些情況下還不允許讀這種數據)。


　　鎖定不僅影響許多不同的應用程序如何更新數據庫中的信息，而且還影響對那個數據的查詢。這是因為查詢可能要訪問正在被修改或者更新的數據?？偟膩碚f，這種延遲是很小的。大多數鎖定機制主要是為了防止多個處理更新同一個數據。由于向數據中插入信息和更新信息這兩種情況都需要鎖定，你可以想象，多個應用程序使用同一個數據庫可能會有很大的影響。


　　不同的存儲引擎在不同的對象級別支持鎖定，而且這些級別將影響可以同時訪問的信息。得到支持的級別有三種:表鎖定、塊鎖定和行鎖定。支持最多的是表鎖定，這種鎖定是在MyISAM中提供的。在數據更新時，它鎖定了整個表。這就防止了許多應用程序同時更新一個具體的表。這對應用很多的多用戶數據庫有很大的影響，因為它延遲了更新的過程。


　　頁級鎖定使用Berkeley DB引擎，并且根據上載的信息頁(8KB)鎖定數據。當在數據庫的很多地方進行更新的時候，這種鎖定不會出現什么問題。但是，由于增加幾行信息就要鎖定數據結構的最后8KB，當需要增加大量的行，也別是大量的小型數據，就會帶來問題。


　　行級鎖定提供了最佳的并行訪問功能，一個表中只有一行數據被鎖定。這就意味著很多應用程序能夠更新同一個表中的不同行的數據，而不會引起鎖定的問題。只有InnoDB存儲引擎支持行級鎖定。


　　建立索引


　　建立索引在搜索和恢復數據庫中的數據的時候能夠顯著提高性能。不同的存儲引擎提供不同的制作索引的技術。有些技術也許會更適合你存儲的數據類型。


　　有些存儲引擎根本就不支持索引，其原因可能是它們使用基本表索引(如MERGE引擎)或者是因為數據存儲的方式不允許索引(例如FEDERATED或者BLACKHOLE引擎)。


　　事務處理


　　事務處理功能通過提供在向表中更新和插入信息期間的可靠性。這種可靠性是通過如下方法實現的，它允許你更新表中的數據，但僅當應用的應用程序的所有相關操作完全完成后才接受你對表的更改。例如，在會計處理中每一筆會計分錄處理將包括對借方科目和貸方科目數據的更改，你需要要使用事務處理功能保證對借方科目和貸方科目的數據更改都順利完成，才接受所做的修改。如果任一項操作失敗了，你都可以取消這個事務處理，這些修改就不存在了。如果這個事務處理過程完成了，我們可以通過允許這個修改來確認這個操作。


　　至此為止，我們介紹了MySQL存儲引擎的相關基本概念，在下一篇文章里，我們會分別介紹各種MySQL存儲引擎。


http://soft.chinabyte.com/database/52/12609052.shtml
========

Oracle怎樣查看存儲引擎

Orace不像MySQL，沒有專門的存儲引擎這樣的概念。

總結

以上是生活随笔為你收集整理的数据库存储引擎学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。