NoSQL，指的是非關(guān)系型的數(shù)據(jù)庫。NoSQL有時也稱作Not Only SQL的縮寫，是對不同于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)的統(tǒng)稱。
成都創(chuàng)新互聯(lián)服務(wù)項目包括西區(qū)網(wǎng)站建設(shè)、西區(qū)網(wǎng)站制作、西區(qū)網(wǎng)頁制作以及西區(qū)網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，西區(qū)網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到西區(qū)省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
NoSQL用于超大規(guī)模數(shù)據(jù)的存儲。（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴展。
NoSQL的優(yōu)點/缺點
優(yōu)點:
- 高可擴展性
- 分布式計算
- 低成本
- 架構(gòu)的靈活性，半結(jié)構(gòu)化數(shù)據(jù)
- 沒有復(fù)雜的關(guān)系
缺點:
- 沒有標(biāo)準(zhǔn)化
- 有限的查詢功能（到目前為止）
- 最終一致是不直觀的程序 （BY三人行慕課）
Web1.0的時代，數(shù)據(jù)訪問量很有限，用一夫當(dāng)關(guān)的高性能的單點服務(wù)器可以解決大部分問題。
隨著Web2.0的時代的到來，用戶訪問量大幅度提升，同時產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來的智能移動設(shè)備的普及，所有的互聯(lián)網(wǎng)平臺都面臨了巨大的性能挑戰(zhàn)。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關(guān)系型的數(shù)據(jù)庫。
NoSQL 不依賴業(yè)務(wù)邏輯方式存儲，而以簡單的key-value模式存儲。因此大大的增加了數(shù)據(jù)庫的擴展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫 列式數(shù)據(jù)庫 Hbase Hbase
HBase是Hadoop項目中的數(shù)據(jù)庫。它用于需要對大量的數(shù)據(jù)進行隨機、實時的讀寫操作的場景中。
HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計算機處理超過10億行數(shù)據(jù)，還可處理有數(shù)百萬列元素的數(shù)據(jù)表。
Cassandra Cassandra
Apache Cassandra是一款免費的開源NoSQL數(shù)據(jù)庫，其設(shè)計目的在于管理由大量商用服務(wù)器構(gòu)建起來的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達到PB級別)。在眾多顯著特性當(dāng)中，Cassandra最為卓越的長處是對寫入及讀取操作進行規(guī)模調(diào)整，而且其不強調(diào)主集群的設(shè)計思路能夠以相對直觀的方式簡化各集群的創(chuàng)建與擴展流程。
主要應(yīng)用：社會關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜(n*(n-1)/2)
NoSQL 數(shù)據(jù)庫因其功能性、易于開發(fā)性和可擴展性而廣受認可，它們越來越多地用于大數(shù)據(jù)和實時 Web 應(yīng)用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。
NoSQL是一種下一代數(shù)據(jù)庫管理系統(tǒng) (DBMS)。NoSQL 數(shù)據(jù)庫具有靈活的模式，可用于構(gòu)建具有大量數(shù)據(jù)和高負載的現(xiàn)代應(yīng)用程序。
“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的，盡管自 1960 年代后期以來就已經(jīng)存在類似的數(shù)據(jù)庫。然而，NoSQL 的發(fā)展始于 2009 年初，并且發(fā)展迅速。
在處理大量數(shù)據(jù)時，任何關(guān)系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 的響應(yīng)時間都會變慢。為了解決這個問題，我們可以通過升級現(xiàn)有硬件來“擴大”信息系統(tǒng)，這非常昂貴。但是，NoSQL 可以更好地橫向擴展并且更具成本效益。
NoSQL 對于非結(jié)構(gòu)化或非常大的數(shù)據(jù)對象（例如聊天日志數(shù)據(jù)、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯(lián)網(wǎng)巨頭中特別受歡迎的原因。
一些流行的 NoSQL 數(shù)據(jù)庫包括：
隨著企業(yè)更快地積累更大的數(shù)據(jù)集，結(jié)構(gòu)化數(shù)據(jù)和關(guān)系模式并不總是適合。有必要使用非結(jié)構(gòu)化數(shù)據(jù)和大型對象來更好地捕獲這些信息。
傳統(tǒng)的 RDBMS 使用 SQL（結(jié)構(gòu)化查詢語言）語法來存儲和檢索結(jié)構(gòu)化數(shù)據(jù)，相反，NoSQL 數(shù)據(jù)庫包含廣泛的功能，可以存儲和檢索結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化和多態(tài)數(shù)據(jù)。
有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強調(diào)它可能支持類似 SQL 的語言或與 SQL 數(shù)據(jù)庫并列。SQL 和 NoSQL DBMS 之間的一個區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫使用 JOIN 子句來組合來自兩個或多個表的行，因為 NoSQL 數(shù)據(jù)庫本質(zhì)上不是表格的，所以這個功能并不總是可行或相關(guān)的。
但是，一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數(shù)據(jù)庫傾向于以不同的方式解決類似的問題。
一般來說，在以下情況下，NoSQL 比 SQL 更可?。?/p>
許多行業(yè)都在采用 NoSQL，取代關(guān)系數(shù)據(jù)庫，從而為某些業(yè)務(wù)應(yīng)用程序提供更高的靈活性和可擴展性，下面給出了 NoSQL 數(shù)據(jù)庫的一些企業(yè)用例。
內(nèi)容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數(shù)據(jù)庫可以通過其靈活和開放的數(shù)據(jù)模型為存儲多媒體內(nèi)容提供更好的選擇。
例如，福布斯在短短幾個月內(nèi)就構(gòu)建了一個基于 MongoDB 的定制內(nèi)容管理系統(tǒng)，以更低的成本為他們提供了更大的敏捷性。
大數(shù)據(jù)是指太大而無法通過傳統(tǒng)處理系統(tǒng)處理的數(shù)據(jù)集，實時存儲和檢索大數(shù)據(jù)的系統(tǒng)在分析 歷史 數(shù)據(jù)的同時使用流處理來攝取新數(shù)據(jù)，這是一系列非常適合 NoSQL 數(shù)據(jù)庫的功能。
Zoom使用 DynamoDB（按需模式）使其數(shù)據(jù)能夠在沒有性能問題的情況下進行擴展，即使該服務(wù)在 COVID-19 大流行的早期使用量激增。
物聯(lián)網(wǎng)設(shè)備具有連接到互聯(lián)網(wǎng)或通信網(wǎng)絡(luò)的嵌入式軟件和傳感器，能夠在無需人工干預(yù)的情況下收集和共享數(shù)據(jù)。隨著數(shù)十億臺設(shè)備生成數(shù)不清的數(shù)據(jù)，IoT NoSQL 數(shù)據(jù)庫為 IoT 服務(wù)提供商提供了可擴展性和更靈活的架構(gòu)。
Freshub就是這樣的一項服務(wù)，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態(tài)、非統(tǒng)一的數(shù)據(jù)集。
擁有數(shù)十億智能手機用戶，可擴展性正成為在移動設(shè)備上提供服務(wù)的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數(shù)據(jù)模型的 NoSQL DBMS 通常是完美的解決方案。
例如，The Weather Channel使用 MongoDB 數(shù)據(jù)庫每分鐘處理數(shù)百萬個請求，同時還處理用戶數(shù)據(jù)并提供天氣更新。
關(guān)系數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，已經(jīng)非常成熟，但同時也存在不足：
表結(jié)構(gòu)是強約束的，業(yè)務(wù)變更時擴充很麻煩。
如果對大數(shù)據(jù)量的表進行統(tǒng)計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數(shù)據(jù)讀入內(nèi)存。
全文搜索只能使用 Like 進行整表掃描，性能非常低。
針對這些不足，產(chǎn)生了不同的 NoSQL 解決方案，在某些場景下比關(guān)系數(shù)據(jù)庫更有優(yōu)勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應(yīng)將其作為 SQL 的有利補充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類：
Redis 是典型，其 value 是具體的數(shù)據(jù)結(jié)構(gòu)，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器。
以 list 為例：
LPOP key 是移除并返回隊列左邊的第一個元素。
如果用關(guān)系數(shù)據(jù)庫就比較麻煩了，需要操作：
Redis 的缺點主要體現(xiàn)在不支持完成的ACID事務(wù)，只能保證隔離性和一致性，無法保證原子性和持久性。
最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導(dǎo)致語法錯誤。
特點：
以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關(guān)系數(shù)據(jù)庫中會有很大的麻煩，而使用文檔數(shù)據(jù)庫則非常方便。
文檔數(shù)據(jù)庫的主要缺點：
關(guān)系數(shù)據(jù)庫是按行來存儲的，列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。
按行存儲的優(yōu)勢：
在某些場景下，這些優(yōu)勢就成為劣勢了，例如，計算超重人員的數(shù)據(jù)，只需要讀取體重這一列進行統(tǒng)計即可，但行式存儲會將整行數(shù)據(jù)讀取到內(nèi)存中，很浪費。
而列式存儲中，只需要讀取體重這列的數(shù)據(jù)即可，I/O 將大大減少。
除了節(jié)省I/O，列式存儲還有更高的壓縮比，可以節(jié)省存儲空間。普通行式數(shù)據(jù)庫的壓縮比在 3:1 到 5:1 左右，列式數(shù)據(jù)庫在 8:1 到 30:1，因為單個列的數(shù)據(jù)相似度更高。
列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續(xù)空間中，而列式存儲將不同列存儲在不連續(xù)的空間。
一般將列式存儲應(yīng)用在離線大數(shù)據(jù)分析統(tǒng)計場景，因為這時主要針對部分列進行操作，而且數(shù)據(jù)寫入后無須更新。
關(guān)系數(shù)據(jù)庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：
假設(shè)有一個交友網(wǎng)站，信息表如下：
需要匹配性別、地點、語言列。
需要匹配性別、地點、愛好列。
實際搜索中，各種排列組合非常多，關(guān)系數(shù)據(jù)庫很難支持。
全文搜索引擎是使用 倒排索引 技術(shù)，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：
所以特別適合根據(jù)關(guān)鍵詞來查詢文檔內(nèi)容。
上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據(jù)實際需求進行選擇。
一般將NoSQL數(shù)據(jù)庫分為四大類：鍵值(Key-Value)存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形(Graph)數(shù)據(jù)庫。它們的數(shù)據(jù)模型、優(yōu)缺點、典型應(yīng)用場景。
鍵值(Key-Value)存儲數(shù)據(jù)庫Key指向Value的鍵值對，通常用hash表來實現(xiàn)查找速度快數(shù)據(jù)無結(jié)構(gòu)化(通常只被當(dāng)作字符串或者二進制數(shù)據(jù))內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問負載，也用于一些日志系統(tǒng)等。
列存儲數(shù)據(jù)庫，以列簇式存儲，將同一列數(shù)據(jù)存在一起查找速度快，可擴展性強，更容易進行分布式擴展功能相對局限分布式的文件系統(tǒng)。
文檔型數(shù)據(jù)庫，Key-Value對應(yīng)的鍵值對，Value為結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)要求不嚴(yán)格，表結(jié)構(gòu)可變(不需要像關(guān)系型數(shù)據(jù)庫一樣需預(yù)先定義表結(jié)構(gòu))，查詢性能不高，而且缺乏統(tǒng)一的查詢語法，Web應(yīng)用。
圖形(Graph)數(shù)據(jù)庫，圖結(jié)構(gòu)，利用圖結(jié)構(gòu)相關(guān)算法(如最短路徑尋址，N度關(guān)系查找等)，很多時候需要對整個圖做計算才能得出需要的信息，而且這種結(jié)構(gòu)不太好做分布式的集群方案，社交網(wǎng)絡(luò)，推薦系統(tǒng)等。
這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當(dāng)?shù)胤治鲆恍┏晒Π咐?，希望有成功使用NoSQL經(jīng)驗的朋友給我提供一些線索和信息。
NoSQL概念隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關(guān)系數(shù)據(jù)庫的名字。）
NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲，當(dāng)然還有其他的文檔型的、列存儲、圖型數(shù)據(jù)庫、xml數(shù)據(jù)庫等。在NoSQL概念提出之前，這些數(shù)據(jù)庫就被用于各種系統(tǒng)當(dāng)中，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫。
傳統(tǒng)關(guān)系數(shù)據(jù)庫的瓶頸
傳統(tǒng)的關(guān)系數(shù)據(jù)庫具有不錯的性能，高穩(wěn)定型，久經(jīng)歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻。
在90年代，一個網(wǎng)站的訪問量一般都不大，用單個數(shù)據(jù)庫完全可以輕松應(yīng)付。在那個時候，更多的都是靜態(tài)網(wǎng)頁，動態(tài)交互類型的網(wǎng)站不多。
到了最近10年，網(wǎng)站開始快速發(fā)展?；鸨恼搲⒉┛汀ns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期，論壇的流量其實也不大，如果你接觸網(wǎng)絡(luò)比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。
Memcached+MySQL
后來，隨著訪問量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力，但是當(dāng)訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術(shù)產(chǎn)品。
Memcached作為一個獨立的分布式的緩存服務(wù)器，為多個web服務(wù)器提供了一個共享的高性能緩存服務(wù)，在Memcached服務(wù)器上，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務(wù)的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端。當(dāng)時，如果你去面試，你說你有Memcached經(jīng)驗，肯定會加分的。
Mysql主從讀寫分離
由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負，大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網(wǎng)站標(biāo)配了。
分表分庫隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復(fù)制，讀寫分離的基礎(chǔ)之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴(yán)重的鎖問題，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題。這個時候，分表分庫成了一個熱門技術(shù)，是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個時候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。
MySQL的擴展性瓶頸
在互聯(lián)網(wǎng)，大部分的MySQL都應(yīng)該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設(shè)計得有性能問題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開發(fā)越來越復(fù)雜，也越來越具有技術(shù)挑戰(zhàn)性。分表分庫的規(guī)則把握都是需要經(jīng)驗的。雖然有像淘寶這樣技術(shù)實力強大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復(fù)雜性，但是避免不了整個架構(gòu)的復(fù)雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。
MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導(dǎo)致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復(fù)的時候就導(dǎo)致非常的慢，不容易快速恢復(fù)數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。
關(guān)系數(shù)據(jù)庫很強大，但是它并不能很好的應(yīng)付所有的應(yīng)用場景。MySQL的擴展性差（需要復(fù)雜的技術(shù)來實現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。
NOSQL的優(yōu)勢易擴展NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴展。也無形之間，在架構(gòu)的層面上帶來了可擴展的能力。
大數(shù)據(jù)量，高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。
高可用NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復(fù)制模型也能實現(xiàn)高可用。
總結(jié)NoSQL數(shù)據(jù)庫的出現(xiàn)，彌補了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護成本。
MySQL和NoSQL都有各自的特點和使用的應(yīng)用場景，兩者的緊密結(jié)合將會給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思路。
重慶分公司
重慶分公司
