具體來說，本文包括以下內容:
創(chuàng)新互聯(lián)公司主要從事成都做網站、成都網站設計、成都外貿網站建設、網頁設計、企業(yè)做網站、公司建網站等業(yè)務。立足成都服務洛南,十載網站建設經驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18980820575
事務
查詢性能
用戶和查詢沖突
容量
配置
NoSQL 數(shù)據(jù)庫
事務
事務可以觀察真實用戶的行為：能夠在應用交互時捕獲實時性能。眾所周知，測量事務的性能包括獲取整個事務的響應時間和組成事務的各個部分的響應時間。通常我們可以用這些響應時間與滿足事務需求的基線對比，來確定當前事務是否處于正常狀態(tài)。
如果你只想衡量應用的某個方面，那么可以評估事務的行為。所以，盡管容器指標能夠提供更豐富的信息，并且?guī)椭銢Q定何時對當前環(huán)境進行自動測量，但你的事務就足以確定應用性能。無需向應用程序服務器獲取 CPU 的使用情況，你更應該關心用戶是否完成了事務，以及該事務是否得到了優(yōu)化。
補充一個小知識點，事務是由入口點決定的，通過該入口點可以啟動事務與應用進行交互。
一旦定義了事務，會在整個應用生態(tài)系統(tǒng)中對其性能進行測量，并將每個事務與基線進行比對。例如，我們可能會決定當事務的響應時間與基線相比，一旦慢于平均響應時間的兩個標準差是否就應該判定為異常，如圖1所示。
圖1-基于基線評估當前事務響應時間
用于評估事務的基線與正在進行的事務活動在時間上是一致的，但事務會由每個事務執(zhí)行來完善。例如，當你選定一個基線，在當前事務結束之后，將事務與平均響應時間按每天的小時數(shù)和每周的天數(shù)進行對比，所有在那段時間內執(zhí)行的事務都將會被納入下周的基線中。通過這種機制，應用程序可以隨時間而變化，而無需每次都重建原始基線；你可以將其看作是一個隨時間移動的窗口。
總之，事務最能反映用戶體驗的測量方法，所以也是衡量性能狀況最重要的指標。
查詢性能?
最容易檢測到查詢性能是否正常的指標就是查詢本身。由查詢引起的問題可能會導致時間太長而無法識別所需數(shù)據(jù)或返回數(shù)據(jù)。所以不妨在查詢中排查以下問題。
1. 選擇過多冗余數(shù)據(jù)
編寫查詢語句來返回適當?shù)臄?shù)據(jù)是遠遠不夠的，很可能你的查詢語句會返回太多列，從而導致選擇行和檢索數(shù)據(jù)變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當需要在特定字段中查詢時，該計劃可能會確定一個覆蓋索引從而加快結果返回。覆蓋索引通常會包含查詢中使用的所有字段。這意味著數(shù)據(jù)庫可以僅從索引中產生結果，而不需要通過底層表來構建。
另外，列出結果中所需的列不僅可以減少傳輸?shù)臄?shù)據(jù)，還能進一步提高性能。
2. 表之間的低效聯(lián)接
聯(lián)接會導致數(shù)據(jù)庫將多組數(shù)據(jù)帶到內存中進行比較，這會產生多個數(shù)據(jù)庫讀取和大量 CPU。根據(jù)表的索引，聯(lián)接還可能需要掃描兩個表的所有行。如果寫不好兩個大型表之間的聯(lián)接，就需要對每個表進行完整掃描，這樣的計算量將會非常大。其他會拖慢聯(lián)接的因素包括聯(lián)接列之間存在不同的數(shù)據(jù)類型、需要轉換或加入包含 LIKE 的條件，這樣就會阻止使用索引。另外，還需注意避免使用全外聯(lián)接；在恰當?shù)臅r候使用內部聯(lián)接只返回所需數(shù)據(jù)。
3. 索引過多或過少
如果查詢優(yōu)化沒有可用的索引時，數(shù)據(jù)庫會重新掃描表來產生查詢結果，這個過程會生成大量的磁盤輸入/輸出（I/O）。適當?shù)乃饕梢詼p少排序結果的需要。雖然非唯一值的索引在生成結果時，不能像唯一索引那樣方便。如果鍵越大，索引也會變大，并通過它們創(chuàng)建更多的磁盤 I/O。大多數(shù)索引是為了提高數(shù)據(jù)檢索的性能，但也需要明白索引本身也會影響數(shù)據(jù)的插入和更新，因為所有相關聯(lián)的指標都必須更新。
4. 太多的SQL導致爭用解析資源
任何 SQL 查詢在執(zhí)行之前都必須被解析，在生成執(zhí)行計劃之前需要對語法和權限進行檢查。由于解析非常耗時，數(shù)據(jù)庫會保存已解析的 SQL 來重復利用，從而減少解析的耗時。因為 WHERE 語句不同，所以使用文本值的查詢語句不能被共享。這將導致每個查詢都會被解析并添加到共享池中，由于池的空間有限，一些已保存的查詢會被舍棄。當這些查詢再次出現(xiàn)時，則需要重新解析。
用戶和查詢沖突?
數(shù)據(jù)庫支持多用戶，但多用戶活動也可能造成沖突。
1. 由慢查詢導致的頁/行鎖定
為了確保查詢產生精確的結果，數(shù)據(jù)庫必須鎖定表以防止在運行讀取查詢時再發(fā)生其他的插入和更新行為。如果報告或查詢相當緩慢，需要修改值的用戶可能需要等待至更新完成。鎖提示能幫助數(shù)據(jù)庫使用最小破壞性的鎖。從事務數(shù)據(jù)庫中分離報表也是一種可靠的解決方法。
2. 事務鎖和死鎖
當兩個事務被阻塞時會出現(xiàn)死鎖，因為每一個都需要使用被另一個占用的資源。當出現(xiàn)一個普通鎖時，事務會被阻塞直到資源被釋放。但卻沒有解決死鎖的方案。數(shù)據(jù)庫會監(jiān)控死鎖并選擇終止其中一個事務，釋放資源并允許該事務繼續(xù)進行，而另一個事務則回滾。
3. 批處理操作造成資源爭奪
批處理過程通常會執(zhí)行批量操作，如大量的數(shù)據(jù)加載或生成復雜的分析報告。這些操作是資源密集型的，但可能影響在線用戶的訪問應用的性能。針對此問題最好的解決辦法是確保批處理在系統(tǒng)使用率較低時運行，比如晚上，或用單獨的數(shù)據(jù)庫進行事務處理和分析報告。
容量?
并不是所有的數(shù)據(jù)庫性能問題都是數(shù)據(jù)庫問題。有些問題也是硬件不合適造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分擔服務器負載，進一步提高性能。數(shù)據(jù)庫的性能不僅是數(shù)據(jù)庫的原因，還受到服務器上運行其他進程的影響。因此，對數(shù)據(jù)庫負載及使用進行審查也是必不可少的。由于 CPU 的利用率時時在變，在低使用率、平均使用率和峰值使用率的時間段分別檢查該指標可以更好地評估增加額外的 CPU 資源是否有益。
2. IOPS 不足的慢磁盤
磁盤性能通常以每秒輸入/輸出操作（IOPS）來計。結合 I/O 大小，該指標可以衡量每秒的磁盤吞吐量是多少兆。同時，吞吐量也受磁盤的延遲影響，比如需要多久才能完成請求，這些指標主要是針對磁盤存儲技術而言。傳統(tǒng)的硬盤驅動器（HDD）有一個旋轉磁盤，通常比固態(tài)硬盤（SSD）或閃存更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經降了下來，所以在市場上也更具競爭力。
3. 全部或錯誤配置的磁盤
眾所周知，數(shù)據(jù)庫會被大量磁盤訪問，所以不正確配置的磁盤可能帶來嚴重的性能缺陷。磁盤應該適當分區(qū)，將系統(tǒng)數(shù)據(jù)目錄和用戶數(shù)據(jù)日志分開。高度活躍的表應該區(qū)分以避免爭用，通過在不同磁盤上存放數(shù)據(jù)庫和索引增加并行放置，但不要將操作系統(tǒng)和數(shù)據(jù)庫交換空間放置在同一磁盤上。
4. 內存不足
有限或不恰當?shù)奈锢韮却娣峙鋾绊憯?shù)據(jù)庫性能。通常我們認為可用的內存更多，性能就越好。監(jiān)控分頁和交換,在多個非繁忙磁盤中建立多頁面空間，進一步確保分頁空間分配足夠滿足數(shù)據(jù)庫要求；每個數(shù)據(jù)庫供應商也可以在這個問題上提供指導。
5. 網速慢
網絡速度會影響到如何快速檢索數(shù)據(jù)并返回給終端用戶或調用過程。使用寬帶連接到遠程數(shù)據(jù)庫。在某些情況下，選擇 TCP/IP 協(xié)議而不是命名管道可顯著提高數(shù)據(jù)庫性能。
配置
每個數(shù)據(jù)庫都需設置大量的配置項。通常情況下，默認值可能不足以滿足數(shù)據(jù)庫所需的性能。所以，檢查所有的參數(shù)設置，包括以下問題。
1. 緩沖區(qū)緩存太小
通過將數(shù)據(jù)存儲在內核內存，緩沖區(qū)緩存可以進一步提高性能同時減少磁盤 I/O。當緩存太小時，緩存中的數(shù)據(jù)會更頻繁地刷新。如果它再次被請求，就必須從磁盤重讀。除了磁盤讀取緩慢之外，還給 I/O 設備增添了負擔從而成為瓶頸。除了給緩沖區(qū)緩存分配足夠的空間，調優(yōu) SQL 查詢可以幫助其更有效地利用緩沖區(qū)緩存。
2. 沒有查詢緩存
查詢緩存會存儲數(shù)據(jù)庫查詢和結果集。當執(zhí)行相同的查詢時，數(shù)據(jù)會在緩存中被迅速檢索，而不需要再次執(zhí)行查詢。數(shù)據(jù)會更新失效結果，所以查詢緩存是唯一有效的靜態(tài)數(shù)據(jù)。但在某些情況下，查詢緩存卻可能成為性能瓶頸。比如當鎖定為更新時，巨大的緩存可能導致爭用沖突。
3. 磁盤上臨時表創(chuàng)建導致的 I/O 爭用
在執(zhí)行特定的查詢操作時，數(shù)據(jù)庫需要創(chuàng)建臨時表，如執(zhí)行一個 GROUP BY 子句。如果可能，在內存中創(chuàng)建臨時表。但是，在某些情況下，在內存中創(chuàng)建臨時表并不可行，比如當數(shù)據(jù)包含 BLOB 或 TEXT 對象時。在這些情況下，會在磁盤上創(chuàng)建臨時表。大量的磁盤 I / O 都需要創(chuàng)建臨時表、填充記錄、從表中選擇所需數(shù)據(jù)并在查詢完成后舍棄。為了避免影響性能，臨時數(shù)據(jù)庫應該從主數(shù)據(jù)庫中分離出來。重寫查詢還可以通過創(chuàng)建派生表來減少對臨時表的需求。使用派生表直接從另一個 SELECT 語句的結果中選擇，允許將數(shù)據(jù)加到內存中而不是當前磁盤上。
NoSQL 數(shù)據(jù)庫
NoSQL 的優(yōu)勢在于它處理大數(shù)據(jù)的能力非常迅速。但是在實際使用中，也應該綜合參考 NoSQL 的缺點，從而決定是否適合你的用例場景。這就是為什么NoSQL通常被理解為 「不僅僅是 SQL」，說明了 NoSQL 并不總是正確的解決方案，也沒必要完全取代 SQL，以下分別列舉出五大主要原因。
1. 挑剔事務
難以保持 NoSQL 條目的一致性。當訪問結構化數(shù)據(jù)時，它并不能完全確保同一時間對不同表的更改都生效。如果某個過程發(fā)生崩潰，表可能會不一致。一致事務的典型代表是復式記賬法。相應的信貸必須平衡每個借方，反之亦然。如果雙方數(shù)據(jù)不一致則不能輸入。NoSQL 則可能無法保證「收支平衡」。
2. 復雜數(shù)據(jù)庫
NoSQL 的支持者往往以高效代碼、簡單性和 NoSQL 的速度為傲。當數(shù)據(jù)庫任務很簡單時，所有這些因素都是優(yōu)勢。但當數(shù)據(jù)庫變得復雜，NoSQL 會開始分解。此時，SQL 則比 NoSQL 更好地處理復雜需求，因為 SQL 已經成熟，有符合行業(yè)標準的接口。而每個 NoSQL 設置都有一個唯一的接口。
3. 一致聯(lián)接
當執(zhí)行 SQL 的聯(lián)接時，由于系統(tǒng)必須從不同的表中提取數(shù)據(jù)進行鍵對齊，所以有一個巨大的開銷。而 NoSQL 似乎是一個空想，因為缺乏聯(lián)接功能。所有的數(shù)據(jù)都在同一個表的一個地方。當檢索數(shù)據(jù)時，它會同時提取所有的鍵值對。問題在于這會創(chuàng)建同一數(shù)據(jù)的多個副本。這些副本也必須更新，而這種情況下，NoSQL 沒有功能來確保更新。
4. Schema設計的靈活性
由于 NoSQL 不需要 schema，所以在某些情況下也是獨一無二的。在以前的數(shù)據(jù)庫模型中，程序員必須考慮所有需要的列能夠擴展，能夠適應每行的數(shù)據(jù)條目。在 NoSQL 下，條目可以有多種字符串或者完全沒有。這種靈活性允許程序員迅速增加數(shù)據(jù)。但是，也可能存在問題，比如當有多個團體在同一項目上工作時，或者新的開發(fā)團隊接手一個項目時。開發(fā)人員能夠自由地修改數(shù)據(jù)庫，也可能會不斷實現(xiàn)各種各樣的密鑰對。
5. 資源密集型
NoSQL 數(shù)據(jù)庫通常比關系數(shù)據(jù)庫更加資源密集。他們需要更多的 CPU 儲備和 RAM 分配。出于這個原因，大多數(shù)共享主機公司都不提供 NoSQL。你必須注冊一個 VPS 或運行自己的專用服務器。另一方面，SQL 主要是在服務器上運行。初期的工作都很順利，但隨著數(shù)據(jù)庫需求的增加，硬件必須擴大。單個大型服務器比多個小型服務器昂貴得多，價格呈指數(shù)增長。所以在這種企業(yè)計算場景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的服務器。
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網web2.0網站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應用難題，包括超大規(guī)模數(shù)據(jù)的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關系型數(shù)據(jù)庫與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結構化數(shù)據(jù)
結構化查詢語言（SQL）
數(shù)據(jù)和關系都存儲在單獨的表中。
數(shù)據(jù)操縱語言，數(shù)據(jù)定義語言
嚴格的一致性
基礎事務
ACID
關系型數(shù)據(jù)庫遵循ACID規(guī)則
事務在英文中是transaction，和現(xiàn)實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務之間不會互相影響，如果一個事務要訪問的數(shù)據(jù)正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數(shù)據(jù)就不受未提交事務的影響。比如現(xiàn)有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務提交后，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫
最終一致性，而非ACID屬性
非結構化和不可預知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統(tǒng)，通常在可擴展性上不太強大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐σ恢滦砸蟮鸵恍?。
CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。
而由于當前的網絡硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統(tǒng)能同時保證這三點。
說明：C：強一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫
AP：大多數(shù)網站架構的選擇
CP：Redis、Mongodb
注意：分布式架構的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應用，其實并不需要強一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫產品的方向。
4. 當下NoSQL的經典應用
當下的應用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一臺；O 是指 Oracle 數(shù)據(jù)庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。
難點：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構。
數(shù)據(jù)源改造而服務平臺不需要大面積重構。
而傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數(shù)據(jù)庫應付上萬次SQL查詢還勉強頂?shù)米。菓渡先f次SQL寫數(shù)據(jù)請求，硬盤IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發(fā)寫請求的需求。
2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求
對于大型的SNS網站，每天用戶產生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統(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小時不間斷服務的網站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務器節(jié)點來實現(xiàn)擴展呢？
在上面提到的“三高”需求面前，關系數(shù)據(jù)庫遇到了難以克服的障礙，而對于web2.0網站來說，關系數(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類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，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，也得到了廣泛認同。
Web1.0的時代，數(shù)據(jù)訪問量很有限，用一夫當關的高性能的單點服務器可以解決大部分問題。
隨著Web2.0的時代的到來，用戶訪問量大幅度提升，同時產生了大量的用戶數(shù)據(jù)。加上后來的智能移動設備的普及，所有的互聯(lián)網平臺都面臨了巨大的性能挑戰(zhàn)。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關系型的數(shù)據(jù)庫。
NoSQL 不依賴業(yè)務邏輯方式存儲，而以簡單的key-value模式存儲。因此大大的增加了數(shù)據(jù)庫的擴展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫 列式數(shù)據(jù)庫 Hbase Hbase
HBase是Hadoop項目中的數(shù)據(jù)庫。它用于需要對大量的數(shù)據(jù)進行隨機、實時的讀寫操作的場景中。
HBase的目標就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計算機處理超過10億行數(shù)據(jù)，還可處理有數(shù)百萬列元素的數(shù)據(jù)表。
Cassandra Cassandra
Apache Cassandra是一款免費的開源NoSQL數(shù)據(jù)庫，其設計目的在于管理由大量商用服務器構建起來的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達到PB級別)。在眾多顯著特性當中，Cassandra最為卓越的長處是對寫入及讀取操作進行規(guī)模調整，而且其不強調主集群的設計思路能夠以相對直觀的方式簡化各集群的創(chuàng)建與擴展流程。
主要應用：社會關系，公共交通網絡，地圖及網絡拓譜(n*(n-1)/2)
重慶分公司
重慶分公司
