NoSQL與關系型數(shù)據(jù)庫設計理念比較
創(chuàng)新互聯(lián)是一家專注于做網(wǎng)站、成都網(wǎng)站建設與策劃設計,昌寧網(wǎng)站建設哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設10余年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:昌寧等地區(qū)。昌寧做網(wǎng)站價格咨詢:18980820575
關系型數(shù)據(jù)庫中的表都是存儲一些格式化的數(shù)據(jù)結構，每個元組字段的組成都一樣，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結構可以便于表與表之間進行連接等操作，但從另一個角度來說它也是關系型數(shù)據(jù)庫性能瓶頸的一個因素。而非關系型數(shù)據(jù)庫以鍵值對存儲，它的結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。
特點：
它們可以處理超大量的數(shù)據(jù)。
它們運行在便宜的PC服務器集群上。
它們擊碎了性能瓶頸。
沒有過多的操作。
Bootstrap支持
缺點：
但是一些人承認，沒有正式的官方支持，萬一出了差錯會是可怕的，至少很多管理人員是這樣看。
此外，nosql并未形成一定標準，各種產(chǎn)品層出不窮，內部混亂，各種項目還需時間來檢驗
個人不認為nosql在少量數(shù)據(jù)存儲上有啥優(yōu)勢。nosql主要解決的是auto sharding的問題,你不需要sharding,搞啥nosql. 作者：方圓 鏈接：
NoSQL 數(shù)據(jù)庫因其功能性、易于開發(fā)性和可擴展性而廣受認可，它們越來越多地用于大數(shù)據(jù)和實時 Web 應用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。
NoSQL是一種下一代數(shù)據(jù)庫管理系統(tǒng) (DBMS)。NoSQL 數(shù)據(jù)庫具有靈活的模式，可用于構建具有大量數(shù)據(jù)和高負載的現(xiàn)代應用程序。
“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的，盡管自 1960 年代后期以來就已經(jīng)存在類似的數(shù)據(jù)庫。然而，NoSQL 的發(fā)展始于 2009 年初，并且發(fā)展迅速。
在處理大量數(shù)據(jù)時，任何關系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 的響應時間都會變慢。為了解決這個問題，我們可以通過升級現(xiàn)有硬件來“擴大”信息系統(tǒng)，這非常昂貴。但是，NoSQL 可以更好地橫向擴展并且更具成本效益。
NoSQL 對于非結構化或非常大的數(shù)據(jù)對象（例如聊天日志數(shù)據(jù)、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯(lián)網(wǎng)巨頭中特別受歡迎的原因。
一些流行的 NoSQL 數(shù)據(jù)庫包括：
隨著企業(yè)更快地積累更大的數(shù)據(jù)集，結構化數(shù)據(jù)和關系模式并不總是適合。有必要使用非結構化數(shù)據(jù)和大型對象來更好地捕獲這些信息。
傳統(tǒng)的 RDBMS 使用 SQL（結構化查詢語言）語法來存儲和檢索結構化數(shù)據(jù)，相反，NoSQL 數(shù)據(jù)庫包含廣泛的功能，可以存儲和檢索結構化、半結構化、非結構化和多態(tài)數(shù)據(jù)。
有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強調它可能支持類似 SQL 的語言或與 SQL 數(shù)據(jù)庫并列。SQL 和 NoSQL DBMS 之間的一個區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫使用 JOIN 子句來組合來自兩個或多個表的行，因為 NoSQL 數(shù)據(jù)庫本質上不是表格的，所以這個功能并不總是可行或相關的。
但是，一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數(shù)據(jù)庫傾向于以不同的方式解決類似的問題。
一般來說，在以下情況下，NoSQL 比 SQL 更可取：
許多行業(yè)都在采用 NoSQL，取代關系數(shù)據(jù)庫，從而為某些業(yè)務應用程序提供更高的靈活性和可擴展性，下面給出了 NoSQL 數(shù)據(jù)庫的一些企業(yè)用例。
內容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數(shù)據(jù)庫可以通過其靈活和開放的數(shù)據(jù)模型為存儲多媒體內容提供更好的選擇。
例如，福布斯在短短幾個月內就構建了一個基于 MongoDB 的定制內容管理系統(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ù)能夠在沒有性能問題的情況下進行擴展，即使該服務在 COVID-19 大流行的早期使用量激增。
物聯(lián)網(wǎng)設備具有連接到互聯(lián)網(wǎng)或通信網(wǎng)絡的嵌入式軟件和傳感器，能夠在無需人工干預的情況下收集和共享數(shù)據(jù)。隨著數(shù)十億臺設備生成數(shù)不清的數(shù)據(jù)，IoT NoSQL 數(shù)據(jù)庫為 IoT 服務提供商提供了可擴展性和更靈活的架構。
Freshub就是這樣的一項服務，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態(tài)、非統(tǒng)一的數(shù)據(jù)集。
擁有數(shù)十億智能手機用戶，可擴展性正成為在移動設備上提供服務的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數(shù)據(jù)模型的 NoSQL DBMS 通常是完美的解決方案。
例如，The Weather Channel使用 MongoDB 數(shù)據(jù)庫每分鐘處理數(shù)百萬個請求，同時還處理用戶數(shù)據(jù)并提供天氣更新。
NoSQL不像傳統(tǒng)關系型庫那樣有統(tǒng)一的標準，也不具有普適性。所以要根據(jù)應用和數(shù)據(jù)的存取特征來選擇適合的NoSQL。
如果以前沒有接觸過NoSQL，MongoDB是一個比較好的選擇，他支持的所以和查詢能力是所有NoSQL中最強大的，缺點是索引的成本和文檔大小限制。
如果是使用Hadoop大數(shù)據(jù)分析，數(shù)據(jù)基本上不存在修改，只是插入和查詢，并且需要配合Hadoop的MR任務，HBase會是很好的選擇。
如果要求有很強的擴展能力，高并發(fā)讀寫和維護方便，Casaandra則是不錯的選擇。
當然除了上面三個流行的NoSQL，還有很多優(yōu)秀的NoSQL數(shù)據(jù)庫，而且他們都有各自擅長領域，所以需要了解你們產(chǎn)品自身的特點然后分析選擇哪種才是最適合的，往往在大型系統(tǒng)中不是單一的數(shù)據(jù)庫，而是使用多種數(shù)據(jù)庫組合。
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ù)。并且不會有任何單點失敗。
問度娘，啥都有。
關系數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，已經(jīng)非常成熟，但同時也存在不足：
表結構是強約束的，業(yè)務變更時擴充很麻煩。
如果對大數(shù)據(jù)量的表進行統(tǒng)計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數(shù)據(jù)讀入內存。
全文搜索只能使用 Like 進行整表掃描，性能非常低。
針對這些不足，產(chǎn)生了不同的 NoSQL 解決方案，在某些場景下比關系數(shù)據(jù)庫更有優(yōu)勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 SQL 的有利補充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類：
Redis 是典型，其 value 是具體的數(shù)據(jù)結構，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數(shù)據(jù)結構服務器。
以 list 為例：
LPOP key 是移除并返回隊列左邊的第一個元素。
如果用關系數(shù)據(jù)庫就比較麻煩了，需要操作：
Redis 的缺點主要體現(xiàn)在不支持完成的ACID事務，只能保證隔離性和一致性，無法保證原子性和持久性。
最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。
特點：
以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數(shù)據(jù)庫中會有很大的麻煩，而使用文檔數(shù)據(jù)庫則非常方便。
文檔數(shù)據(jù)庫的主要缺點：
關系數(shù)據(jù)庫是按行來存儲的，列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。
按行存儲的優(yōu)勢：
在某些場景下，這些優(yōu)勢就成為劣勢了，例如，計算超重人員的數(shù)據(jù)，只需要讀取體重這一列進行統(tǒng)計即可，但行式存儲會將整行數(shù)據(jù)讀取到內存中，很浪費。
而列式存儲中，只需要讀取體重這列的數(shù)據(jù)即可，I/O 將大大減少。
除了節(jié)省I/O，列式存儲還有更高的壓縮比，可以節(jié)省存儲空間。普通行式數(shù)據(jù)庫的壓縮比在 3:1 到 5:1 左右，列式數(shù)據(jù)庫在 8:1 到 30:1，因為單個列的數(shù)據(jù)相似度更高。
列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續(xù)空間中，而列式存儲將不同列存儲在不連續(xù)的空間。
一般將列式存儲應用在離線大數(shù)據(jù)分析統(tǒng)計場景，因為這時主要針對部分列進行操作，而且數(shù)據(jù)寫入后無須更新。
關系數(shù)據(jù)庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：
假設有一個交友網(wǎng)站，信息表如下：
需要匹配性別、地點、語言列。
需要匹配性別、地點、愛好列。
實際搜索中，各種排列組合非常多，關系數(shù)據(jù)庫很難支持。
全文搜索引擎是使用 倒排索引 技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：
所以特別適合根據(jù)關鍵詞來查詢文檔內容。
上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據(jù)實際需求進行選擇。
重慶分公司
重慶分公司
