nosql是什么

NoSQL，泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應用難題。

目前成都創(chuàng)新互聯(lián)已為上千的企業(yè)提供了網(wǎng)站建設、域名、虛擬主機、網(wǎng)站運營、企業(yè)網(wǎng)站設計、喀喇沁網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現(xiàn)在已經(jīng)開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴酷的事實：技術越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲不得不進行重寫，也有少數(shù)人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴展的存儲庫。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。

對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

不需要預定義模式：不需要事先定義數(shù)據(jù)模式，預定義表結構。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當插入數(shù)據(jù)時，并不需要預先定義它們的模式。

無共享架構：相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡中的全共享架構。NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。

彈性可擴展：可以在系統(tǒng)運行的時候，動態(tài)增加或者刪除結點。不需要停機維護，數(shù)據(jù)可以自動遷移。

分區(qū)：相對于將數(shù)據(jù)存放于同一個節(jié)點，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進行分區(qū)，將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復制。這樣既提高了并行性能，又能保證沒有單點失效的問題。

異步復制：和RAID存儲系統(tǒng)不同的是，NoSQL中的復制，往往是基于日志的異步復制。這樣，數(shù)據(jù)就可以盡快地寫入一個節(jié)點，而不會被網(wǎng)絡傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時候，可能會丟失少量的數(shù)據(jù)。

BASE：相對于事務嚴格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務。

NoSQL數(shù)據(jù)庫并沒有一個統(tǒng)一的架構，兩種NoSQL數(shù)據(jù)庫之間的不同，甚至遠遠超過兩種關系型數(shù)據(jù)庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應用，在這些場合中會遠遠勝過關系型數(shù)據(jù)庫和其他的NoSQL。

nosql解決方案為什么需要固態(tài)硬盤

Membase

Membase 是 NoSQL 家族的一個新的重量級的成員。Membase是開源項目，源代碼采用了Apache2.0的使用許可。該項目托管在GitHub.Source tarballs上，可以下載beta版本的Linux二進制包。該產(chǎn)品主要是由North Scale的memcached核心團隊成員開發(fā)完成，其中還包括Zynga和NHN這兩個主要貢獻者的工程師，這兩個組織都是很大的在線游戲和社區(qū)網(wǎng)絡空間的供應商。

Membase容易安裝、操作，可以從單節(jié)點方便的擴展到集群，而且為memcached（有線協(xié)議的兼容性）實現(xiàn)了即插即用功能，在應用方面為開發(fā)者和經(jīng)營者提供了一個比較低的門檻。做為緩存解決方案，Memcached已經(jīng)在不同類型的領域（特別是大容量的Web應用）有了廣泛的使用，其中 Memcached的部分基礎代碼被直接應用到了Membase服務器的前端。

通過兼容多種編程語言和框架，Membase具備了很好的復用性。在安裝和配置方面，Membase提供了有效的圖形化界面和編程接口，包括可配置 的告警信息。

Membase的目標是提供對外的線性擴展能力，包括為了增加集群容量，可以針對統(tǒng)一的節(jié)點進行復制。 另外，對存儲的數(shù)據(jù)進行再分配仍然是必要的。

這方面的一個有趣的特性是NoSQL解決方案所承諾的可預測的性能，類準確性的延遲和吞吐量。通過如下方式可以獲得上面提到的特性：

◆ 自動將在線數(shù)據(jù)遷移到低延遲的存儲介質的技術（內存，固態(tài)硬盤，磁盤）

◆ 可選的寫操作一一異步，同步（基于復制，持久化）

◆ 反向通道再平衡[未來考慮支持]

◆ 多線程低鎖爭用

◆ 盡可能使用異步處理

◆ 自動實現(xiàn)重復數(shù)據(jù)刪除

◆ 動態(tài)再平衡現(xiàn)有集群

◆ 通過把數(shù)據(jù)復制到多個集群單元和支持快速失敗轉移來提供系統(tǒng)的高可用性。

MongoDB

MongoDB是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫的。他支持的數(shù)據(jù)結構非常松散，是類似json的bjson格式，因此可以存儲比較復雜的數(shù)據(jù)類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。它的特點是高性能、易部署、易使用，存儲數(shù)據(jù)非常方便。

主要功能特性：

◆ 面向集合存儲，易存儲對象類型的數(shù)據(jù)

“面向集合”（Collenction-Oriented），意思是數(shù)據(jù)被分組存儲在數(shù)據(jù)集中，被稱為一個集合（Collenction)。每個 集合在數(shù)據(jù)庫中都有一個唯一的標識名，并且可以包含無限數(shù)目的文檔。集合的概念類似關系型數(shù)據(jù)庫（RDBMS）里的表（table），不同的是它不需要定 義任何模式（schema)。

◆ 模式自由

模式自由（schema-free)，意味著對于存儲在mongodb數(shù)據(jù)庫中的文件，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的文件存儲在同一個數(shù)據(jù)庫里。

◆支持動態(tài)查詢

◆支持完全索引，包含內部對象

◆支持查詢

◆支持復制和故障恢復

◆使用高效的二進制數(shù)據(jù)存儲，包括大型對象（如視頻等）

◆自動處理碎片，以支持云計算層次的擴展性

◆支持RUBY，PYTHON，JAVA，C++，PHP等多種語言

◆文件存儲格式為BSON（一種JSON的擴展）

BSON（Binary Serialized document Format）存儲形式是指：存儲在集合中的文檔，被存儲為鍵-值對的形式。鍵用于唯一標識一個文檔，為字符串類型，而值則可以是各種復雜的文件類型。

◆可通過網(wǎng)絡訪問

MongoDB服務端可運行在Linux、Windows或OS X平臺，支持32位和64位應用，默認端口為27017。推薦運行在64位平臺，因為MongoDB在32位模式運行時支持的最大文件尺寸為2GB。

MongoDB把數(shù)據(jù)存儲在文件中（默認路徑為：/data/db），為提高效率使用內存映射文件進行管理。

Hypertable

Hypertable是一個開源、高性能、可伸縮的數(shù)據(jù)庫，它采用與Google的Bigtable相似的模型。在過去數(shù)年中，Google為在PC集群 上運行的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統(tǒng)，提供了一個全局的命名空間。它通過跨機器（和跨機架）的文件數(shù)據(jù)復制來達到高可用性，并因此免受傳統(tǒng) 文件存儲系統(tǒng)無法避免的許多失敗的影響，比如電源、內存和網(wǎng)絡端口等失敗。第二個基礎設施是名為Map-Reduce的計算框架，它與GFS緊密協(xié)作，幫 助處理收集到的海量數(shù)據(jù)。第三個基礎設施是Bigtable，它是傳統(tǒng)數(shù)據(jù)庫的替代。Bigtable讓你可以通過一些主鍵來組織海量數(shù)據(jù)，并實現(xiàn)高效的 查詢。Hypertable是Bigtable的一個開源實現(xiàn)，并且根據(jù)我們的想法進行了一些改進。

Apache Cassandra

Apache Cassandra是一套開源分布式Key-Value存儲系統(tǒng)。它最初由Facebook開發(fā)，用于儲存特別大的數(shù)據(jù)。Facebook在使用此系統(tǒng)。

主要特性：

◆ 分布式

◆ 基于column的結構化

◆ 高伸展性

Cassandra的主要特點就是它不是一個數(shù)據(jù)庫，而是由一堆數(shù)據(jù)庫節(jié)點共同構成的一個分布式網(wǎng)絡服務，對Cassandra 的一個寫操作，會被復制到其他節(jié)點上去，對Cassandra的讀操作，也會被路由到某個節(jié)點上面去讀取。對于一個Cassandra群集來說，擴展性能 是比較簡單的事情，只管在群集里面添加節(jié)點就可以了。

Cassandra是一個混合型的非關系的數(shù)據(jù)庫，類似于Google的BigTable。其主要功能比 Dynomite（分布式的Key-Value存 儲系統(tǒng)）更豐富，但支持度卻不如文檔存儲MongoDB（介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的開源產(chǎn)品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫 的。Cassandra最初由Facebook開發(fā)，后轉變成了開源項目。它是一個網(wǎng)絡社交云計算方面理想的數(shù)據(jù)庫。以Amazon專有的完全分布式的Dynamo為基礎，結合了Google BigTable基于列族（Column Family）的數(shù)據(jù)模型。P2P去中心化的存儲。很多方面都可以稱之為Dynamo 2.0。

CouchDB

所用語言： Erlang

特點：DB一致性，易于使用

使用許可： Apache

協(xié)議： HTTP/REST

雙向數(shù)據(jù)復制，持續(xù)進行或臨時處理，處理時帶沖突檢查，因此，采用的是master-master復制

MVCC – 寫操作不阻塞讀操作

可保存文件之前的版本

Crash-only（可靠的）設計

需要不時地進行數(shù)據(jù)壓縮

視圖：嵌入式 映射/減少

格式化視圖：列表顯示

支持進行服務器端文檔驗證

支持認證

根據(jù)變化實時更新

支持附件處理

因此， CouchApps（獨立的 js應用程序）

需要 jQuery程序庫

最佳應用場景：適用于數(shù)據(jù)變化較少，執(zhí)行預定義查詢，進行數(shù)據(jù)統(tǒng)計的應用程序。適用于需要提供數(shù)據(jù)版本支持的應用程序。

例如：CRM、CMS系統(tǒng)。 master-master復制對于多站點部署是非常有用的。

和其他數(shù)據(jù)庫比較，其突出特點是：

◆ 模式靈活 ：使用Cassandra，像文檔存儲，你不必提前解決記錄中的字段。你可以在系統(tǒng)運行時隨意的添加或移除字段。這是一個驚人的效率提升，特別是在大型部 署上。

◆ 真正的可擴展性 ：Cassandra是純粹意義上的水平擴展。為給集群添加更多容量，可以指向另一臺電腦。你不必重啟任何進程，改變應用查詢，或手動遷移任何數(shù)據(jù)。

◆ 多數(shù)據(jù)中心識別 ：你可以調整你的節(jié)點布局來避免某一個數(shù)據(jù)中心起火，一個備用的數(shù)據(jù)中心將至少有每條記錄的完全復制。

◆ 范圍查詢 ：如果你不喜歡全部的鍵值查詢，則可以設置鍵的范圍來查詢。

◆ 列表數(shù)據(jù)結構 ：在混合模式可以將超級列添加到5維。對于每個用戶的索引，這是非常方便的。

◆ 分布式寫操作 ：有可以在任何地方任何時間集中讀或寫任何數(shù)據(jù)。并且不會有任何單點失敗。

問度娘，啥都有。

NoSQL應用

而傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，例如：

1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求

web2.0網(wǎng)站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數(shù)據(jù)庫應付上萬次SQL查詢還勉強頂?shù)米。菓渡先f次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實對于普通的BBS網(wǎng)站，往往也存在對高并發(fā)寫請求的需求。

2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求

對于大型的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數(shù)以億計的帳號，關系數(shù)據(jù)庫也很難應付。

3、High Scalability High Availability- 對數(shù)據(jù)庫的高可擴展性和高可用性的需求

在基于web的架構當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務器節(jié)點來實現(xiàn)擴展呢？

在上面提到的“三高”需求面前，關系數(shù)據(jù)庫遇到了難以克服的障礙，而對于web2.0網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性卻往往無用武之地，例如：

1、數(shù)據(jù)庫事務一致性需求

很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務管理成了數(shù)據(jù)庫高負載下一個沉重的負擔。

2、數(shù)據(jù)庫的寫實時性和讀實時性需求

對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應用來說，并不要求這么高的實時性。

3、對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求

任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設計角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

因此，關系數(shù)據(jù)庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數(shù)據(jù)庫應運而生。

NoSQL 是非關系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結構，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術語在 2009 年初得到了廣泛認同。

當今的應用體系結構需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。

nosql數(shù)據(jù)庫是什么 具有代表性以key-value的形式存儲的

什么是NoSQL

大家有沒有聽說過“NoSQL”呢?近年，這個詞極受關注。看到“NoSQL”這個詞，大家可能會誤以為是“No!SQL”的縮寫，并深感憤怒：“SQL怎么會沒有必要了呢?”但實際上，它是“Not Only SQL”的縮寫。它的意義是：適用關系型數(shù)據(jù)庫的時候就使用關系型數(shù)據(jù)庫，不適用的時候也沒有必要非使用關系型數(shù)據(jù)庫不可，可以考慮使用更加合適的數(shù)據(jù)存儲。

為彌補關系型數(shù)據(jù)庫的不足，各種各樣的NoSQL數(shù)據(jù)庫應運而生。

為了更好地了解本書所介紹的NoSQL數(shù)據(jù)庫，對關系型數(shù)據(jù)庫的理解是必不可少的。那么，就讓我們先來看一看關系型數(shù)據(jù)庫的歷史、分類和特征吧。

關系型數(shù)據(jù)庫簡史

1969年，埃德加?6?1弗蘭克?6?1科德(Edgar Frank Codd)發(fā)表了劃時代的論文，首次提出了關系數(shù)據(jù)模型的概念。但可惜的是，刊登論文的《IBM Research Report》只是IBM公司的內部刊物，因此論文反響平平。1970年，他再次在刊物《Communication of the ACM》上發(fā)表了題為“A Relational Model of Data for Large Shared Data banks”(大型共享數(shù)據(jù)庫的關系模型)的論文，終于引起了大家的關注。

科德所提出的關系數(shù)據(jù)模型的概念成為了現(xiàn)今關系型數(shù)據(jù)庫的基礎。當時的關系型數(shù)據(jù)庫由于硬件性能低劣、處理速度過慢而遲遲沒有得到實際應用。但之后隨著硬件性能的提升，加之使用簡單、性能優(yōu)越等優(yōu)點，關系型數(shù)據(jù)庫得到了廣泛的應用。

通用性及高性能

雖然本書是講解NoSQL數(shù)據(jù)庫的，但有一個重要的大前提，請大家一定不要誤解。這個大前提就是“關系型數(shù)據(jù)庫的性能絕對不低，它具有非常好的通用性和非常高的性能”。毫無疑問，對于絕大多數(shù)的應用來說它都是最有效的解決方案。

突出的優(yōu)勢

關系型數(shù)據(jù)庫作為應用廣泛的通用型數(shù)據(jù)庫，它的突出優(yōu)勢主要有以下幾點:

保持數(shù)據(jù)的一致性(事務處理)

由于以標準化為前提，數(shù)據(jù)更新的開銷很小(相同的字段基本上都只有一處)

可以進行JOIN等復雜查詢

存在很多實際成果和專業(yè)技術信息(成熟的技術)

這其中，能夠保持數(shù)據(jù)的一致性是關系型數(shù)據(jù)庫的最大優(yōu)勢。在需要嚴格保證數(shù)據(jù)一致性和處理完整性的情況下，用關系型數(shù)據(jù)庫是肯定沒有錯的。但是有些情況不需要JOIN，對上述關系型數(shù)據(jù)庫的優(yōu)點也沒有什么特別需要，這時似乎也就沒有必要拘泥于關系型數(shù)據(jù)庫了。

關系型數(shù)據(jù)庫的不足

不擅長的處理

就像之前提到的那樣，關系型數(shù)據(jù)庫的性能非常高。但是它畢竟是一個通用型的數(shù)據(jù)庫，并不能完全適應所有的用途。具體來說它并不擅長以下處理：

大量數(shù)據(jù)的寫入處理

為有數(shù)據(jù)更新的表做索引或表結構(schema)變更

字段不固定時應用

對簡單查詢需要快速返回結果的處理

。。。。。。

NoSQL數(shù)據(jù)庫

為了彌補關系型數(shù)據(jù)庫的不足(特別是最近幾年)，NoSQL數(shù)據(jù)庫出現(xiàn)了。關系型數(shù)據(jù)庫應用廣泛，能進行事務處理和JOIN等復雜處理。相對地，NoSQL數(shù)據(jù)庫只應用在特定領域，基本上不進行復雜的處理，但它恰恰彌補了之前所列舉的關系型數(shù)據(jù)庫的不足之處。

易于數(shù)據(jù)的分散

如前所述，關系型數(shù)據(jù)庫并不擅長大量數(shù)據(jù)的寫入處理。原本關系型數(shù)據(jù)庫就是以JOIN為前提的，就是說，各個數(shù)據(jù)之間存在關聯(lián)是關系型數(shù)據(jù)庫得名的主要原因。為了進行JOIN處理，關系型數(shù)據(jù)庫不得不把數(shù)據(jù)存儲在同一個服務器內，這不利于數(shù)據(jù)的分散。相反，NoSQL數(shù)據(jù)庫原本就不支持JOIN處理，各個數(shù)據(jù)都是獨立設計的，很容易把數(shù)據(jù)分散到多個服務器上。由于數(shù)據(jù)被分散到了多個服務器上，減少了每個服務器上的數(shù)據(jù)量，即使要進行大量數(shù)據(jù)的寫入操作，處理起來也更加容易。同理，數(shù)據(jù)的讀入操作當然也同樣容易。

提升性能和增大規(guī)模

下面說一點題外話，如果想要使服務器能夠輕松地處理更大量的數(shù)據(jù)，那么只有兩個選擇：一是提升性能，二是增大規(guī)模。下面我們來整理一下這兩者的不同。

首先，提升性能指的就是通過提升現(xiàn)行服務器自身的性能來提高處理能力。這是非常簡單的方法，程序方面也不需要進行變更，但需要一些費用。若要購買性能翻倍的服務器，需要花費的資金往往不只是原來的2倍，可能需要多達5到10倍。這種方法雖然簡單，但是成本較高。

另一方面，增大規(guī)模指的是使用多臺廉價的服務器來提高處理能力。它需要對程序進行變更，但由于使用廉價的服務器，可以控制成本。另外，以后只要依葫蘆畫瓢增加廉價服務器的數(shù)量就可以了。

不對大量數(shù)據(jù)進行處理的話就沒有使用的必要嗎？

NoSQL數(shù)據(jù)庫基本上來說為了“使大量數(shù)據(jù)的寫入處理更加容易(讓增加服務器數(shù)量更容易)”而設計的。但如果不是對大量數(shù)據(jù)進行操作的話，NoSQL數(shù)據(jù)庫的應用就沒有意義嗎?

答案是否定的。的確，它在處理大量數(shù)據(jù)方面很有優(yōu)勢。但實際上NoSQL數(shù)據(jù)庫還有各種各樣的特點，如果能夠恰當?shù)乩眠@些特點將會是非常有幫助。具體的例子將會在第2章和第3章進行介紹，這些用途將會讓你感受到利用NoSQL的好處。

希望順暢地對數(shù)據(jù)進行緩存(Cache)處理

希望對數(shù)組類型的數(shù)據(jù)進行高速處理

希望進行全部保存

多樣的NoSQL數(shù)據(jù)庫

NoSQL數(shù)據(jù)庫存在著“key-value存儲”、“文檔型數(shù)據(jù)庫”、“列存儲數(shù)據(jù)庫”等各種各樣的種類，每種數(shù)據(jù)庫又包含各自的特點。下一節(jié)讓我們一起來了解一下NoSQL數(shù)據(jù)庫的種類和特點。

NoSQL數(shù)據(jù)庫是什么

NoSQL說起來簡單，但實際上到底有多少種呢?我在提筆的時候，到NoSQL的官方網(wǎng)站上確認了一下，竟然已經(jīng)有122種了。另外官方網(wǎng)站上也介紹了本書沒有涉及到的圖形數(shù)據(jù)庫和對象數(shù)據(jù)庫等各個類別。不知不覺間，原來已經(jīng)出現(xiàn)了這么多的NoSQL數(shù)據(jù)庫啊。

本節(jié)將為大家介紹具有代表性的NoSQL數(shù)據(jù)庫。

key-value存儲

這是最常見的NoSQL數(shù)據(jù)庫，它的數(shù)據(jù)是以key-value的形式存儲的。雖然它的處理速度非常快，但是基本上只能通過key的完全一致查詢獲取數(shù)據(jù)。根據(jù)數(shù)據(jù)的保存方式可以分為臨時性、永久性和兩者兼具三種。

臨時性

memcached屬于這種類型。所謂臨時性就是 “數(shù)據(jù)有可能丟失”的意思。memcached把所有數(shù)據(jù)都保存在內存中，這樣保存和讀取的速度非常快，但是當memcached停止的時候，數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內存中，所以無法操作超出內存容量的數(shù)據(jù)(舊數(shù)據(jù)會丟失)。

在內存中保存數(shù)據(jù)

可以進行非常快速的保存和讀取處理

數(shù)據(jù)有可能丟失

永久性

Tokyo Tyrant、Flare、ROMA等屬于這種類型。和臨時性相反，所謂永久性就是“數(shù)據(jù)不會丟失”的意思。這里的key-value存儲不像memcached那樣在內存中保存數(shù)據(jù)，而是把數(shù)據(jù)保存在硬盤上。與memcached在內存中處理數(shù)據(jù)比起來，由于必然要發(fā)生對硬盤的IO操作，所以性能上還是有差距的。但數(shù)據(jù)不會丟失是它最大的優(yōu)勢。

在硬盤上保存數(shù)據(jù)

可以進行非常快速的保存和讀取處理(但無法與memcached相比)

數(shù)據(jù)不會丟失

兩者兼具

Redis屬于這種類型。Redis有些特殊，臨時性和永久性兼具，且集合了臨時性key-value存儲和永久性key-value存儲的優(yōu)點。Redis首先把數(shù)據(jù)保存到內存中，在滿足特定條件(默認是15分鐘一次以上，5分鐘內10個以上，1分鐘內10000個以上的key發(fā)生變更)的時候將數(shù)據(jù)寫入到硬盤中。這樣既確保了內存中數(shù)據(jù)的處理速度，又可以通過寫入硬盤來保證數(shù)據(jù)的永久性。這種類型的數(shù)據(jù)庫特別適合于處理數(shù)組類型的數(shù)據(jù)。

同時在內存和硬盤上保存數(shù)據(jù)

可以進行非常快速的保存和讀取處理

保存在硬盤上的數(shù)據(jù)不會消失(可以恢復)

適合于處理數(shù)組類型的數(shù)據(jù)

面向文檔的數(shù)據(jù)庫

MongoDB、CouchDB屬于這種類型。它們屬于NoSQL數(shù)據(jù)庫，但與key-value存儲相異。

不定義表結構

面向文檔的數(shù)據(jù)庫具有以下特征：即使不定義表結構，也可以像定義了表結構一樣使用。關系型數(shù)據(jù)庫在變更表結構時比較費事，而且為了保持一致性還需修改程序。然而NoSQL數(shù)據(jù)庫則可省去這些麻煩(通常程序都是正確的)，確實是方便快捷。

可以使用復雜的查詢條件

跟key-value存儲不同的是，面向文檔的數(shù)據(jù)庫可以通過復雜的查詢條件來獲取數(shù)據(jù)。雖然不具備事務處理和JOIN這些關系型數(shù)據(jù)庫所具有的處理能力，但除此以外的其他處理基本上都能實現(xiàn)。這是非常容易使用的NoSQL數(shù)據(jù)庫。

不需要定義表結構

可以利用復雜的查詢條件

面向列的數(shù)據(jù)庫

Cassandra、Hbase、HyperTable屬于這種類型。由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長，這種類型的NoSQL數(shù)據(jù)庫尤其引人注目。

面向行的數(shù)據(jù)庫和面向列的數(shù)據(jù)庫

普通的關系型數(shù)據(jù)庫都是以行為單位來存儲數(shù)據(jù)的，擅長進行以行為單位的讀入處理，比如特定條件數(shù)據(jù)的獲取。因此，關系型數(shù)據(jù)庫也被稱為面向行的數(shù)據(jù)庫。相反，面向列的數(shù)據(jù)庫是以列為單位來存儲數(shù)據(jù)的，擅長以列為單位讀入數(shù)據(jù)。

高擴展性

面向列的數(shù)據(jù)庫具有高擴展性，即使數(shù)據(jù)增加也不會降低相應的處理速度(特別是寫入速度)，所以它主要應用于需要處理大量數(shù)據(jù)的情況。另外，利用面向列的數(shù)據(jù)庫的優(yōu)勢，把它作為批處理程序的存儲器來對大量數(shù)據(jù)進行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫跟現(xiàn)行數(shù)據(jù)庫存儲的思維方式有很大不同，應用起來十分困難。

高擴展性(特別是寫入處理)

應用十分困難

最近，像Twitter和Facebook這樣需要對大量數(shù)據(jù)進行更新和查詢的網(wǎng)絡服務不斷增加，面向列的數(shù)據(jù)庫的優(yōu)勢對其中一些服務是非常有用的，但是由于這與本書所要介紹的內容關系不大，就不進行詳細介紹了。

總結：

NoSQL并不是No-SQL，而是指Not Only SQL。

NoSQL的出現(xiàn)是為了彌補SQL數(shù)據(jù)庫因為事務等機制帶來的對海量數(shù)據(jù)、高并發(fā)請求的處理的性能上的欠缺。

NoSQL不是為了替代SQL而出現(xiàn)的，它是一種替補方案，而不是解決方案的首選。

絕大多數(shù)的NoSQL產(chǎn)品都是基于大內存和高性能隨機讀寫的（比如具有更高性能的固態(tài)硬盤陣列），一般的小型企業(yè)在選擇NoSQL時一定要慎重！不要為了NoSQL而NoSQL，可能會導致花了冤枉錢又耽擱了項目進程。

NoSQL不是萬能的，但在大型項目中，你往往需要它！

簡述什么是nosql數(shù)據(jù)庫，并列舉兩種常見的nosql數(shù)據(jù)庫名稱及其特點

NoSQL太火，冒出太多產(chǎn)品了，保守估計也成百上千了。

互聯(lián)網(wǎng)公司常用的基本集中在以下幾種，每種只舉一個比較常見或者應用比較成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同時提供了更加豐富的數(shù)據(jù)結構和運算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機恢復，同時支持replication提供讀可擴展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盤的key-value storage, 模型單一簡單，數(shù)據(jù)量不受限于內存大小，數(shù)據(jù)落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序寫盤的方式對于新硬件ssd再適合不過了，不足是僅提供了一個庫，需要自己封裝server端。

3. Document Store: Mongodb

分布式nosql，具備了區(qū)別mysql的最大亮點：可擴展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對于數(shù)據(jù)量遠超內存限制的場景來說，還需要慎重。

4. Column Table Store: HBase

這個富二代似乎不用贅述了，最大的優(yōu)勢是開源，對于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴展性方面是最強的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產(chǎn)品不少，來解決諸如join、聚集運算等復雜查詢。

ssdb、minio性能測試c

項目上需要找一個硬盤型的NoSQL，用于將 Redis 中的冷數(shù)據(jù)落入硬盤。初步選型了幾款 key-value 類型的NoSQL，分別有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均為基于 levelDB 開發(fā)的幾款NoSQL。其中因為 levelDB、rocksDB 無網(wǎng)絡接口，不方便做分布式和高可用。， TiDB 過重，還有 swapDB 社區(qū)不夠活躍且相關client API不完備。暫時選型 SSDB 。

項目需要存儲的其實是一個略長的二進制字符串，初步認為，使用 對象存儲 方案其實也可以替代NoSQL，所以壓測對象添加當前非常火的云原生對象存儲 MinIO

硬件名|配置 系統(tǒng)| Ubuntu(基于win10 wsl版的docker啟動) 內存| 16GB(實際可用6.08G) CPU| Intel i5-8400

測試項目： 1. 寫50M數(shù)據(jù)100次 2. 隨機讀取任意key 100次（對LRU機制不友好）

寫

數(shù)據(jù)導入成功！

數(shù)據(jù)序列化成功！

a 數(shù)據(jù)大小:50.99295234680176 MB

第1次寫入總用時: 797 ms

第2次寫入總用時: 848 ms

第3次寫入總用時: 3621 ms

第4次寫入總用時: 813 ms

第5次寫入總用時: 1862 ms

第6次寫入總用時: 838 ms

第7次寫入總用時: 2235 ms

第8次寫入總用時: 836 ms

第9次寫入總用時: 900 ms

第10次寫入總用時: 1027 ms

第11次寫入總用時: 1101 ms

第12次寫入總用時: 880 ms

第13次寫入總用時: 1956 ms

第14次寫入總用時: 866 ms

第15次寫入總用時: 2422 ms

第16次寫入總用時: 852 ms

第17次寫入總用時: 4511 ms

第18次寫入總用時: 875 ms

第19次寫入總用時: 2736 ms

第20次寫入總用時: 814 ms

第21次寫入總用時: 7172 ms

第22次寫入總用時: 891 ms

第23次寫入總用時: 7820 ms

第24次寫入總用時: 836 ms

第25次寫入總用時: 22103 ms

第26次寫入總用時: 877 ms

第27次寫入總用時: 2712 ms

第28次寫入總用時: 841 ms

第29次寫入總用時: 1928 ms

第30次寫入總用時: 916 ms

第31次寫入總用時: 839 ms

第32次寫入總用時: 826 ms

第33次寫入總用時: 7759 ms

第34次寫入總用時: 843 ms

第35次寫入總用時: 10670 ms

第36次寫入總用時: 843 ms

第37次寫入總用時: 9361 ms

第38次寫入總用時: 821 ms

第39次寫入總用時: 810 ms

第40次寫入總用時: 794 ms

第41次寫入總用時: 13281 ms

第42次寫入總用時: 833 ms

第43次寫入總用時: 811 ms

第44次寫入總用時: 798 ms

第45次寫入總用時: 18843 ms

第46次寫入總用時: 911 ms

第47次寫入總用時: 9428 ms

第48次寫入總用時: 898 ms

第49次寫入總用時: 17582 ms

第50次寫入總用時: 903 ms

第51次寫入總用時: 831 ms

第52次寫入總用時: 800 ms

第53次寫入總用時: 14602 ms

第54次寫入總用時: 827 ms

第55次寫入總用時: 5898 ms

第56次寫入總用時: 856 ms

第57次寫入總用時: 5693 ms

第58次寫入總用時: 1050 ms

第59次寫入總用時: 882 ms

第60次寫入總用時: 1020 ms

第61次寫入總用時: 15060 ms

第62次寫入總用時: 902 ms

第63次寫入總用時: 1062 ms

第64次寫入總用時: 915 ms

第65次寫入總用時: 7572 ms

第66次寫入總用時: 823 ms

第67次寫入總用時: 9649 ms

第68次寫入總用時: 832 ms

第69次寫入總用時: 10403 ms

第70次寫入總用時: 907 ms

第71次寫入總用時: 978 ms

第72次寫入總用時: 789 ms

第73次寫入總用時: 2111 ms

第74次寫入總用時: 947 ms

第75次寫入總用時: 4675 ms

第76次寫入總用時: 944 ms

第77次寫入總用時: 8592 ms

第78次寫入總用時: 832 ms

第79次寫入總用時: 2940 ms

第80次寫入總用時: 842 ms

第81次寫入總用時: 19835 ms

第82次寫入總用時: 862 ms

第83次寫入總用時: 7646 ms

第84次寫入總用時: 873 ms

第85次寫入總用時: 1002 ms

第86次寫入總用時: 842 ms

第87次寫入總用時: 9057 ms

第88次寫入總用時: 801 ms

第89次寫入總用時: 5117 ms

第90次寫入總用時: 918 ms

第91次寫入總用時: 798 ms

第92次寫入總用時: 853 ms

第93次寫入總用時: 7728 ms

第94次寫入總用時: 810 ms

第95次寫入總用時: 3969 ms

第96次寫入總用時: 814 ms

第97次寫入總用時: 2050 ms

第98次寫入總用時: 819 ms

第99次寫入總用時: 9566 ms

第100次寫入總用時: 833 ms/pre

隨機讀

第1次讀取 15總用時: 2251 ms

第2次讀取 73總用時: 2045 ms

第3次讀取 98總用時: 1548 ms

第4次讀取 20總用時: 2683 ms

第5次讀取 46總用時: 1156 ms

第6次讀取 69總用時: 1160 ms

第7次讀取 46總用時: 1520 ms

第8次讀取 51總用時: 1381 ms

第9次讀取 48總用時: 1000 ms

第10次讀取 69總用時: 1400 ms

第11次讀取 82總用時: 1236 ms

第12次讀取 22總用時: 1140 ms

第13次讀取 36總用時: 864 ms

第14次讀取 66總用時: 843 ms

第15次讀取 47總用時: 922 ms

第16次讀取 17總用時: 885 ms

第17次讀取 14總用時: 864 ms

第18次讀取 64總用時: 888 ms

第19次讀取 74總用時: 815 ms

第20次讀取 33總用時: 866 ms

第21次讀取 36總用時: 822 ms

第22次讀取 78總用時: 975 ms

第23次讀取 40總用時: 1186 ms

第24次讀取 54總用時: 857 ms

第25次讀取 92總用時: 963 ms

第26次讀取 43總用時: 955 ms

第27次讀取 38總用時: 853 ms

第28次讀取 47總用時: 926 ms

第29次讀取 62總用時: 877 ms

第30次讀取 70總用時: 890 ms

第31次讀取 88總用時: 895 ms

第32次讀取 15總用時: 937 ms

第33次讀取 3總用時: 993 ms

第34次讀取 99總用時: 892 ms

第35次讀取 76總用時: 818 ms

第36次讀取 30總用時: 1020 ms

第37次讀取 89總用時: 863 ms

第38次讀取 99總用時: 819 ms

第39次讀取 62總用時: 818 ms

第40次讀取 1總用時: 871 ms

第41次讀取 66總用時: 809 ms

第42次讀取 68總用時: 847 ms

第43次讀取 72總用時: 910 ms

第44次讀取 50總用時: 1128 ms

第45次讀取 47總用時: 898 ms

第46次讀取 26總用時: 909 ms

第47次讀取 35總用時: 872 ms

第48次讀取 30總用時: 826 ms

第49次讀取 79總用時: 904 ms

第50次讀取 66總用時: 863 ms

第51次讀取 2總用時: 885 ms

第52次讀取 65總用時: 900 ms

第53次讀取 67總用時: 1023 ms

第54次讀取 16總用時: 934 ms

第55次讀取 63總用時: 892 ms

第56次讀取 9總用時: 894 ms

第57次讀取 71總用時: 896 ms

第58次讀取 20總用時: 947 ms

第59次讀取 89總用時: 865 ms

第60次讀取 57總用時: 872 ms

第61次讀取 62總用時: 856 ms

第62次讀取 14總用時: 881 ms

第63次讀取 19總用時: 950 ms

第64次讀取 14總用時: 876 ms

第65次讀取 86總用時: 968 ms

第66次讀取 12總用時: 911 ms

第67次讀取 93總用時: 877 ms

第68次讀取 59總用時: 886 ms

第69次讀取 79總用時: 878 ms

第70次讀取 49總用時: 869 ms

第71次讀取 91總用時: 964 ms

第72次讀取 38總用時: 838 ms

第73次讀取 73總用時: 915 ms

第74次讀取 8總用時: 875 ms

第75次讀取 96總用時: 827 ms

第76次讀取 98總用時: 826 ms

第77次讀取 95總用時: 892 ms

第78次讀取 36總用時: 843 ms

第79次讀取 44總用時: 872 ms

第80次讀取 89總用時: 863 ms

第81次讀取 24總用時: 883 ms

第82次讀取 89總用時: 804 ms

第83次讀取 49總用時: 876 ms

第84次讀取 81總用時: 873 ms

第85次讀取 72總用時: 914 ms

第86次讀取 68總用時: 861 ms

第87次讀取 73總用時: 893 ms

第88次讀取 4總用時: 880 ms

第89次讀取 3總用時: 987 ms

第90次讀取 76總用時: 896 ms

第91次讀取 16總用時: 1010 ms

第92次讀取 73總用時: 903 ms

第93次讀取 83總用時: 933 ms

第94次讀取 52總用時: 945 ms

第95次讀取 48總用時: 901 ms

第96次讀取 26總用時: 942 ms

第97次讀取 37總用時: 883 ms

第98次讀取 44總用時: 866 ms

第99次讀取 89總用時: 921 ms

第100次讀取 61總用時: 896 ms/pre

寫

數(shù)據(jù)導入成功！

第1次寫入總用時: 956 ms

第2次寫入總用時: 912 ms

第3次寫入總用時: 1241 ms

第4次寫入總用時: 1564 ms

第5次寫入總用時: 942 ms

第6次寫入總用時: 3666 ms

第7次寫入總用時: 1629 ms

第8次寫入總用時: 1712 ms

第9次寫入總用時: 977 ms

第10次寫入總用時: 1515 ms

第11次寫入總用時: 911 ms

第12次寫入總用時: 1009 ms

第13次寫入總用時: 1024 ms

第14次寫入總用時: 1206 ms

第15次寫入總用時: 984 ms

第16次寫入總用時: 943 ms

第17次寫入總用時: 954 ms

第18次寫入總用時: 1033 ms

第19次寫入總用時: 1008 ms

第20次寫入總用時: 1121 ms

第21次寫入總用時: 963 ms

第22次寫入總用時: 949 ms

第23次寫入總用時: 889 ms

第24次寫入總用時: 1066 ms

第25次寫入總用時: 1289 ms

第26次寫入總用時: 1125 ms

第27次寫入總用時: 1111 ms

第28次寫入總用時: 953 ms

第29次寫入總用時: 964 ms

第30次寫入總用時: 1125 ms

第31次寫入總用時: 998 ms

第32次寫入總用時: 1993 ms

第33次寫入總用時: 926 ms

第34次寫入總用時: 920 ms

第35次寫入總用時: 926 ms

第36次寫入總用時: 1169 ms

第37次寫入總用時: 1325 ms

第38次寫入總用時: 1170 ms

第39次寫入總用時: 1074 ms

第40次寫入總用時: 1011 ms

第41次寫入總用時: 931 ms

第42次寫入總用時: 984 ms

第43次寫入總用時: 1563 ms

第44次寫入總用時: 905 ms

第45次寫入總用時: 944 ms

第46次寫入總用時: 1147 ms

第47次寫入總用時: 1429 ms

第48次寫入總用時: 934 ms

第49次寫入總用時: 1133 ms

第50次寫入總用時: 912 ms

第51次寫入總用時: 953 ms

第52次寫入總用時: 1127 ms

第53次寫入總用時: 1065 ms

第54次寫入總用時: 1323 ms

第55次寫入總用時: 1003 ms

第56次寫入總用時: 1489 ms

第57次寫入總用時: 1377 ms

第58次寫入總用時: 940 ms

第59次寫入總用時: 1317 ms

第60次寫入總用時: 912 ms

第61次寫入總用時: 898 ms

第62次寫入總用時: 934 ms

第63次寫入總用時: 1005 ms

第64次寫入總用時: 1729 ms

第65次寫入總用時: 983 ms

第66次寫入總用時: 1684 ms

第67次寫入總用時: 908 ms

第68次寫入總用時: 895 ms

第69次寫入總用時: 1171 ms

第70次寫入總用時: 1372 ms

第71次寫入總用時: 1261 ms

第72次寫入總用時: 1024 ms

第73次寫入總用時: 1048 ms

第74次寫入總用時: 904 ms

第75次寫入總用時: 941 ms

第76次寫入總用時: 928 ms

第77次寫入總用時: 1806 ms

第78次寫入總用時: 1052 ms

第79次寫入總用時: 1030 ms

第80次寫入總用時: 1092 ms

第81次寫入總用時: 1117 ms

第82次寫入總用時: 950 ms

第83次寫入總用時: 933 ms

第84次寫入總用時: 928 ms

第85次寫入總用時: 935 ms

第86次寫入總用時: 1908 ms

第87次寫入總用時: 994 ms

第88次寫入總用時: 1097 ms

第89次寫入總用時: 930 ms

第90次寫入總用時: 1052 ms

第91次寫入總用時: 1119 ms

第92次寫入總用時: 958 ms

第93次寫入總用時: 987 ms

第94次寫入總用時: 973 ms

第95次寫入總用時: 2036 ms

第96次寫入總用時: 891 ms

第97次寫入總用時: 954 ms

第98次寫入總用時: 951 ms

第99次寫入總用時: 1044 ms

第100次寫入總用時: 1366 ms/pre

隨機讀

第1次讀取 46總用時: 40 ms

第2次讀取 8總用時: 36 ms

第3次讀取 28總用時: 26 ms

第4次讀取 80總用時: 10 ms

第5次讀取 77總用時: 13 ms

第6次讀取 27總用時: 49 ms

第7次讀取 86總用時: 20 ms

第8次讀取 0總用時: 45 ms

第9次讀取 54總用時: 34 ms

第10次讀取 24總用時: 153 ms

第11次讀取 78總用時: 29 ms

第12次讀取 0總用時: 17 ms

第13次讀取 91總用時: 56 ms

第14次讀取 5總用時: 99 ms

第15次讀取 23總用時: 138 ms

第16次讀取 37總用時: 120 ms

第17次讀取 40總用時: 156 ms

第18次讀取 88總用時: 41 ms

第19次讀取 76總用時: 32 ms

第20次讀取 49總用時: 102 ms

第21次讀取 20總用時: 179 ms

第22次讀取 40總用時: 68 ms

第23次讀取 6總用時: 215 ms

第24次讀取 36總用時: 197 ms

第25次讀取 37總用時: 30 ms

第26次讀取 68總用時: 154 ms

第27次讀取 14總用時: 314 ms

第28次讀取 27總用時: 91 ms

第29次讀取 51總用時: 255 ms

第30次讀取 66總用時: 166 ms

第31次讀取 86總用時: 140 ms

第32次讀取 29總用時: 374 ms

第33次讀取 96總用時: 235 ms

第34次讀取 68總用時: 72 ms

第35次讀取 74總用時: 264 ms

第36次讀取 11總用時: 334 ms

第37次讀取 55總用時: 316 ms

第38次讀取 31總用時: 287 ms

第39次讀取 93總用時: 233 ms

第40次讀取 44總用時: 499 ms

第41次讀取 26總用時: 312 ms

第42次讀取 76總用時: 33 ms

第43次讀取 11總用時: 31 ms

第44次讀取 86總用時: 191 ms

第45次讀取 96總用時: 217 ms

第46次讀取 20總用時: 145 ms

第47次讀取 1總用時: 772 ms

第48次讀取 69總用時: 477 ms

第49次讀取 9總用時: 320 ms

第50次讀取 46總用時: 42 ms

第51次讀取 34總用時: 823 ms

第52次讀取 76總用時: 115 ms

第53次讀取 62總用時: 635 ms

第54次讀取 99總用時: 596 ms

第55次讀取 64總用時: 657 ms

第56次讀取 66總用時: 97 ms

第57次讀取 18總用時: 461 ms

第58次讀取 91總用時: 247 ms

第59次讀取 46總用時: 147 ms

第60次讀取 12總用時: 702 ms

第61次讀取 79總用時: 545 ms

第62次讀取 47總用時: 956 ms

第63次讀取 17總用時: 853 ms

第64次讀取 97總用時: 771 ms

第65次讀取 74總用時: 368 ms

第66次讀取 84總用時: 790 ms

第67次讀取 72總用時: 866 ms

第68次讀取 82總用時: 742 ms

第69次讀取 93總用時: 313 ms

第70次讀取 57總用時: 917 ms

第71次讀取 61總用時: 1185 ms

第72次讀取 66總用時: 162 ms

第73次讀取 5總用時: 168 ms

第74次讀取 68總用時: 275 ms

第75次讀取 43總用時: 1108 ms

第76次讀取 74總用時: 281 ms

第77次讀取 65總用時: 955 ms

第78次讀取 22總用時: 1169 ms

第79次讀取 88總用時: 501 ms

第80次讀取 80總用時: 1685 ms

第81次讀取 92總用時: 1286 ms

第82次讀取 89總用時: 1680 ms

第83次讀取 30總用時: 1537 ms

第84次讀取 41總用時: 1576 ms

第85次讀取 2總用時: 2193 ms

第86次讀取 52總用時: 1817 ms

第87次讀取 8總用時: 323 ms

第88次讀取 81總用時: 1409 ms

第89次讀取 40總用時: 577 ms

第90次讀取 88總用時: 598 ms

第91次讀取 19總用時: 2324 ms

第92次讀取 75總用時: 2275 ms

第93次讀取 29總用時: 668 ms

第94次讀取 77總用時: 2773 ms

第95次讀取 62總用時: 484 ms

第96次讀取 84總用時: 883 ms

第97次讀取 32總用時: 2945 ms

第98次讀取 44總用時: 884 ms

第99次讀取 66總用時: 631 ms

第100次讀取 38總用時: 2739 ms/pre

非常奇怪的是 MinIO 整體性能略優(yōu)于 SSDB 但是理論上不太應該， SSDB 怎么說也是半內存半硬盤的NoSQL不應該比純硬盤的 MinIO 性能要差，有可能是 SSDB 寫到一定數(shù)據(jù)量后把本機內存寫爆了，導致讀寫非常慢。但這變相驗證了 SSDB 在極端情況下的不穩(wěn)定。

名稱欄目：基于硬盤的nosql,基于硬盤的創(chuàng)新產(chǎn)品
文章鏈接：http://chinadenli.net/article29/dsiehjh.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、全網(wǎng)營銷推廣、網(wǎng)站內鏈、營銷型網(wǎng)站建設、網(wǎng)站維護、App開發(fā)

廣告

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