如何根據性能選擇內存NoSQL數據庫

本文主要內容是測試了不同NoSQL數據庫在測試工具YCSB中的表現(xiàn)。我們選取了3款流行的內存(in-memory)數據庫管理系統(tǒng)：Redis，Tarantool 以及 CouchBase，還有緩存系統(tǒng)Memchached。Memchached雖然不屬于數據庫管理系統(tǒng)但常作為快速存儲系統(tǒng)使用。

創(chuàng)新互聯(lián)-專業(yè)網站定制、快速模板網站建設、高性價比運城網站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式運城網站制作公司更省心,省錢,快速模板網站建設找我們，業(yè)務覆蓋運城地區(qū)。費用合理售后完善，十多年實體公司更值得信賴。

測試環(huán)境由4臺在Microsoft Azure Cloud中的虛擬機組成的計算機組組成。這些虛擬機同屬于一個數據中心。nosql-1和nosql-2用作測試Tarantool和CouchBase，nosql-3和nosql-4用作測試Redis，Azure Redis Cache 以及 Memcached。這些機器都安裝和配置了相應數據庫和測試項目。虛擬機的配置為4核A3 CPU，7GB RAM，120GB硬盤。

數據庫及設置

內存數據庫管理系統(tǒng)會存儲所有在主內存中的數據并在磁碟上進行持續(xù)更新操作；透過日志記錄每個數據的修改以確保連貫性。由于是以append-only方式進行日志寫入，因此它很少遇到瓶頸問題；讀取/寫入都不會造成頻繁的磁碟頭移動。

Redis在2009推出，目前的最新版本是3.0.5。我們這里使用的版本是3.0.4，以append-only(只附加)方式進行數據管理，與其配合使用的是Microsoft Azure Redis Cache工具。

Tarantool是一款開源NoSQL數據庫管理系統(tǒng)。我們使用的是Tarantool 1.6.7-126-gb35aff9，日志采用write-ahead(先寫)模式。Memcached是一款分布式內存緩存系統(tǒng)，這里使用是Memcached 1.4.14-0ubuntu9。

Couchbase Server是開源分布式NoSQL面向文檔數據庫，這里使用的版本是Couchbase 4.0.0-4047-1。

YCSB測試工具

Yahoo! Cloud Serving Benchmark(YCSB)是功能強大的NoSQL數據庫性能測試工具，它提供了6種主要的負載工作類型，以字母A到F來區(qū)分。

負載A負責更新操作，極值是50/50的讀寫操作，如用于進行新近操作記錄。負載B負責讀取操作，極值是95/5的讀寫操作，如用于進行圖片標簽管理，多進行標簽讀取操作。負載C負載100%的讀取操作，如用于進行用戶屬性獲取。負載D以先進先出方式進行插入操作，如用戶進行最新數據讀取。負載E負責小范圍記錄讀取而不是單個記錄讀取，如線程會話。負載F負責記錄的讀取，修改和寫入，如用戶信息管理。

我們對配置文件作了兩處參數修改：數據條目recordcount設為200000，操作條目operationcount設為5000000。YCSB是多線程工具，我們將以8, 16, 32, 64, 128 及256 線程來進行測試。詳細的測試腳本請點擊這里進行下載。

下列測試結果圖以顏色進行測試對象區(qū)分，

Tarantool (HASH) （藍）

Tarantool (TREE)（淺藍）

Redis （紅）

Azure Redis Cache （橙）

Memcached （綠）

CouchBase（黑）

更多圖片請點擊［這里］查看。

結論

Tarantool在所有負載類型測試中皆取得了最優(yōu)成績。它創(chuàng)建了一個無鎖內存引擎，以協(xié)同多任務方式進行操作而不是互斥或并行處理方式。根據以下性能圖表現(xiàn)，我們的結論是Tarantool的高吞吐量處理是其最大優(yōu)勢之一。因此在多數場合下，Tarantool是用戶的最佳選擇。

高并發(fā)寫選sql還是nosql？

SQL的獨特優(yōu)勢包括：

1. SQL能夠加強與數據的交互，并允許對單個數據庫設計提出問題。這是很關鍵的特征，因為無法交互的數據基本上是沒用的，并且，增強的交互性能夠帶來新的見解、新的問題和更有意義的未來交互。

2. SQL是標準化的，使用戶能夠跨系統(tǒng)運用他們的知識，并對第三方附件和工具提供支持。

3. SQL能夠擴展，并且是多功能和經過時間驗證的，這能夠解決從快寫為主導的傳輸到掃描密集型深入分析等問題。

4. SQL對數據呈現(xiàn)和存儲采用正交形式，一些SQL系統(tǒng)支持JSON和其他結構化對象格式，比NoSQL具有更好的性能和更多功能。

NoSQL特點：

易擴展

NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關系性，數據庫的結構簡單。NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

高可用

NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現(xiàn)高可用。

高性能 NoSQL

關系數據庫經過幾十年的發(fā)展，已經非常成熟，但同時也存在不足：

表結構是強約束的，業(yè)務變更時擴充很麻煩。

如果對大數據量的表進行統(tǒng)計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數據讀入內存。

全文搜索只能使用 Like 進行整表掃描，性能非常低。

針對這些不足，產生了不同的 NoSQL 解決方案，在某些場景下比關系數據庫更有優(yōu)勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 SQL 的有利補充。

NoSQL != No SQL，而是：

NoSQL = Not Only SQL

典型的 NoSQL 方案分為4類：

Redis 是典型，其 value 是具體的數據結構，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數據結構服務器。

以 list 為例：

LPOP key 是移除并返回隊列左邊的第一個元素。

如果用關系數據庫就比較麻煩了，需要操作：

Redis 的缺點主要體現(xiàn)在不支持完成的ACID事務，只能保證隔離性和一致性，無法保證原子性和持久性。

最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。

特點：

以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數據庫中會有很大的麻煩，而使用文檔數據庫則非常方便。

文檔數據庫的主要缺點：

關系數據庫是按行來存儲的，列式數據庫是按照列來存儲數據。

按行存儲的優(yōu)勢：

在某些場景下，這些優(yōu)勢就成為劣勢了，例如，計算超重人員的數據，只需要讀取體重這一列進行統(tǒng)計即可，但行式存儲會將整行數據讀取到內存中，很浪費。

而列式存儲中，只需要讀取體重這列的數據即可，I/O 將大大減少。

除了節(jié)省I/O，列式存儲還有更高的壓縮比，可以節(jié)省存儲空間。普通行式數據庫的壓縮比在 3:1 到 5:1 左右，列式數據庫在 8:1 到 30:1，因為單個列的數據相似度更高。

列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續(xù)空間中，而列式存儲將不同列存儲在不連續(xù)的空間。

一般將列式存儲應用在離線大數據分析統(tǒng)計場景，因為這時主要針對部分列進行操作，而且數據寫入后無須更新。

關系數據庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：

假設有一個交友網站，信息表如下：

需要匹配性別、地點、語言列。

需要匹配性別、地點、愛好列。

實際搜索中，各種排列組合非常多，關系數據庫很難支持。

全文搜索引擎是使用 倒排索引 技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：

所以特別適合根據關鍵詞來查詢文檔內容。

上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據實際需求進行選擇。

為什么要使用NoSQL？NOSQL的優(yōu)勢

這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當地分析一些成功案例，希望有成功使用NoSQL經驗的朋友給我提供一些線索和信息。

NoSQL概念隨著web2.0的快速發(fā)展，非關系型、分布式數據存儲得到了快速的發(fā)展，它們不保證關系數據的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關系數據庫的名字。）

NoSQL被我們用得最多的當數key-value存儲，當然還有其他的文檔型的、列存儲、圖型數據庫、xml數據庫等。在NoSQL概念提出之前，這些數據庫就被用于各種系統(tǒng)當中，但是卻很少用于web互聯(lián)網應用。比如cdb、qdbm、bdb數據庫。

傳統(tǒng)關系數據庫的瓶頸

傳統(tǒng)的關系數據庫具有不錯的性能，高穩(wěn)定型，久經歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯(lián)網領域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯(lián)網的發(fā)展做出了卓越的貢獻。

在90年代，一個網站的訪問量一般都不大，用單個數據庫完全可以輕松應付。在那個時候，更多的都是靜態(tài)網頁，動態(tài)交互類型的網站不多。

到了最近10年，網站開始快速發(fā)展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，如果你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優(yōu)化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發(fā)展了根據hash算法來進行多臺Memcached緩存服務的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時，如果你去面試，你說你有Memcached經驗，肯定會加分的。

Mysql主從讀寫分離

由于數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。

分表分庫隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數據量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴重的鎖問題，大量的高并發(fā)MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業(yè)界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網幾乎沒有成功案例，性能也不能滿足互聯(lián)網的要求，只是在高可靠性上提供了非常大的保證。

MySQL的擴展性瓶頸

在互聯(lián)網，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設計得有性能問題，需要優(yōu)化了。大數據量高并發(fā)環(huán)境下的MySQL應用開發(fā)越來越復雜，也越來越具有技術挑戰(zhàn)性。分表分庫的規(guī)則把握都是需要經驗的。雖然有像淘寶這樣技術實力強大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復雜性，但是避免不了整個架構的復雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。

MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。

關系數據庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現(xiàn)），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發(fā)人員面臨的問題。

NOSQL的優(yōu)勢易擴展NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

高可用NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現(xiàn)高可用。

總結NoSQL數據庫的出現(xiàn)，彌補了關系數據（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護成本。

MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結合將會給web2.0的數據庫發(fā)展帶來新的思路。

網頁標題：nosql寫性能,nosql數據庫使用更加方便
文章來源：http://chinadenli.net/article27/dsihhjj.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網頁設計公司、搜索引擎優(yōu)化、網站設計公司、網站維護、ChatGPT、微信公眾號

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)