如何玩轉(zhuǎn)NoSQL數(shù)據(jù)庫(kù)

如何玩轉(zhuǎn) NoSQL數(shù)據(jù)庫(kù)？作者：IT專家網(wǎng)

創(chuàng)新互聯(lián)公司2013年至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元鼎城做網(wǎng)站,已為上家服務(wù),為鼎城各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220

Weather公司CIO Bryson Koehler整理出了MongoDB，Riak和Cassandra等NoSQL數(shù)據(jù)庫(kù)的特性。他指出這其中最重要的特性是“NoSQL不會(huì)限制住你”。

Weather公司，致力于天氣報(bào)告和天氣預(yù)報(bào)業(yè)務(wù)，其并不缺乏數(shù)據(jù)，當(dāng)然也不缺乏數(shù)據(jù)管理工具。但它為什么需要三種不同的NoSQL數(shù)據(jù)庫(kù)？

最近，我向Weather 公司的CIO Bryson Koehler提出了這個(gè)疑問(wèn)，除了公司的CIO,Bryson Koehler還是其他很多業(yè)務(wù)單元的孵化者,包括Weather Channel，WeatherFX，Weather Underground，和Intellicast等。Weather公司每天獲取和處理著約20萬(wàn)億字節(jié)數(shù)據(jù)，對(duì)外提供當(dāng)前全球天氣狀況，并為航空公司，緊急服務(wù)，貨運(yùn)商，公用事業(yè)，保險(xiǎn)，以及在線天氣網(wǎng)站和天氣應(yīng)用程序的用戶提供天氣預(yù)報(bào)服務(wù)。每天需求增加了數(shù)十億的天氣數(shù)據(jù)請(qǐng)求，并且預(yù)期響應(yīng)時(shí)間要在10毫秒左右。

Riak是Weather 公司的后臺(tái)NoSQL數(shù)據(jù)庫(kù)，服務(wù)于公司的事務(wù)性存儲(chǔ)公用網(wǎng)絡(luò)(SUN)數(shù)據(jù)獲取平臺(tái)，它運(yùn)行在多個(gè)亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)的可用區(qū)域上，并以每小時(shí)15次的頻率捕獲超過(guò)20億氣象數(shù)據(jù)信息，。所以，Riak具有明確的處理規(guī)模，但該公司也使用Cassandra以及新近添加的MongoDB數(shù)據(jù)庫(kù)，為Weather.com 上IOS和Android移動(dòng)應(yīng)用程序服務(wù)。

Weather 公司使用了不同的產(chǎn)品，Koehler解釋說(shuō)，因?yàn)椤安煌墓ぞ哂胁煌膬?yōu)勢(shì)。

Cassandra，它服務(wù)于Weather 公司以及全球消費(fèi)者使用的第三方天氣應(yīng)用的API數(shù)據(jù)：“我們的數(shù)據(jù)分發(fā)平臺(tái)每秒處理數(shù)十萬(wàn)的事務(wù)，我們發(fā)現(xiàn)Cassandra在用于全球分發(fā)數(shù)據(jù)上是一個(gè)很棒的解決方案，并且在[數(shù)據(jù)庫(kù)]讀取方面體現(xiàn)出很高的可用性 “。它本質(zhì)上為全球各地消費(fèi)者所使用的數(shù)據(jù)服務(wù)，包括Weather 公司和第三方的天氣應(yīng)用程序。

MongoDB，它提供了Weather.com網(wǎng)站和移動(dòng)應(yīng)用程序的中間層緩存功能：“離開(kāi)我們的核心API，我們還沒(méi)有全部Weather.com內(nèi)容，所以MongoDB是容器和分發(fā)站，為Weather.com以及Android和iOS上的移動(dòng)應(yīng)用程序服務(wù)。Mongo有很多好處，這些好處基于其內(nèi)建的JSON格式以及靈活性上?！?/p>

Riak，用于消費(fèi)氣象數(shù)據(jù)和觀測(cè)，包括來(lái)自世界各地的圖片和視頻等：“我們喜愛(ài)Riak因其優(yōu)秀的數(shù)據(jù)攝取能力，而且是以一種全球分布式的方式來(lái)實(shí)現(xiàn)。這對(duì)于從全球分布式平臺(tái)上獲取數(shù)據(jù)的入站式數(shù)據(jù)庫(kù)是一個(gè)真正可靠的選擇。

我曾聽(tīng)說(shuō)Datastax，Basho和Couchbase的高管貶低MongoDB的可擴(kuò)展性，但MongoDB指向大規(guī)模部署，在Facebook對(duì)超過(guò)200萬(wàn)臺(tái)移動(dòng)設(shè)備上應(yīng)用程序提供支持，在eHarmony公司，MongDB每天處理著數(shù)十億的潛在比賽預(yù)約。據(jù)Koehle所述，MongoDB為Weather.com和Weather.com移動(dòng)應(yīng)用程序處理著“每天十億交易”，“毫無(wú)疑問(wèn)，你可以通過(guò)配置和部署Mongo來(lái)處理大批量的交易數(shù)據(jù)。”

盡管如此，Koehler承認(rèn)，他將“很樂(lè)于看到MongoDB繼續(xù)使全球集群和多位置[功能]更加無(wú)縫化且易于使用?！?這些屬于全球性的分布式集群，復(fù)制和負(fù)載平衡是Cassandra和Riak眾所周知的功能。

從規(guī)模討論的角度來(lái)看，很少有公司達(dá)到Weather公司的經(jīng)營(yíng)規(guī)模。易于開(kāi)發(fā)，架構(gòu)靈活性和JSON數(shù)據(jù)處理使得MongoDB的成為世界上最流行的NoSQL數(shù)據(jù)庫(kù)。這就是為什么微軟和IBM都進(jìn)行了MongoDB的模仿，如微軟的Azure DocumentDB和IBM的 Cloudant，而不是Cassandra和Riak。

Weather公司可以從三個(gè)NoSQL標(biāo)準(zhǔn)降低至兩個(gè)的過(guò)程中得到鞏固，Koehler說(shuō)，但公司沒(méi)有準(zhǔn)備好這么做。

“由于我們構(gòu)造了由許多不同的數(shù)據(jù)解決方案組成的網(wǎng)狀結(jié)構(gòu)，我們目前的環(huán)境已過(guò)于復(fù)雜，”他說(shuō)?！拔覀兿Ｍo團(tuán)隊(duì)一些自由的空間，讓我們可以了解所有選擇的利弊，但你將會(huì)看到一些整合。”

到了那個(gè)時(shí)候，遷移將不在是一件難事，因?yàn)椤瓣P(guān)于NoSQL數(shù)據(jù)庫(kù)最重要的事情是，你不會(huì)被困在其中，” Koehler說(shuō)?！叭绻愕募軜?gòu)和編碼正確，從一個(gè)數(shù)據(jù)庫(kù)遷移到另一個(gè)并不難。隨著模式的自由以及數(shù)據(jù)轉(zhuǎn)存技術(shù)的發(fā)展，無(wú)論前者是一個(gè)key-value存儲(chǔ)或其他什么形式，轉(zhuǎn)儲(chǔ)數(shù)據(jù)都將十分容易?！?/p>

對(duì)特定產(chǎn)品進(jìn)程自定義編碼的復(fù)雜的存儲(chǔ)過(guò)程已經(jīng)一去不復(fù)返了，Koehler說(shuō)，但關(guān)于“結(jié)構(gòu)化和編碼正確”還有很多需要考慮的地方?這樣做是為了避免特殊供應(yīng)商提供的工具和功能可能讓你身陷其中。他舉了亞馬遜網(wǎng)絡(luò)服務(wù)“(AWS)的消息服務(wù)為例。

“你不必讓服務(wù)在云中運(yùn)行，”他解釋說(shuō)?！澳憧梢灾徊渴鹱约旱腞abbitMQ的環(huán)境，而不是陷于其中，所以你可以將一個(gè)原先部署在AWS 上的應(yīng)用程序轉(zhuǎn)而部署在谷歌計(jì)算云服務(wù)上。無(wú)論它是數(shù)據(jù)平臺(tái)，存儲(chǔ)環(huán)境，或云計(jì)算環(huán)境，都要小心別讓自己局限在一個(gè)僅由一個(gè)供應(yīng)商提供的小范圍空間內(nèi)“。

轉(zhuǎn)載

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

2. 什么是NoSQL？

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

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

（例如谷歌或Facebook每天為他們的用戶收集萬(wàn)億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式，無(wú)需多余操作就可以橫向擴(kuò)展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 關(guān)系型數(shù)據(jù)庫(kù)與NoSQL的區(qū)別？

3.1 RDBMS

高度組織化結(jié)構(gòu)化數(shù)據(jù)

結(jié)構(gòu)化查詢語(yǔ)言（SQL）

數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中。

數(shù)據(jù)操縱語(yǔ)言，數(shù)據(jù)定義語(yǔ)言

嚴(yán)格的一致性

基礎(chǔ)事務(wù)

ACID

關(guān)系型數(shù)據(jù)庫(kù)遵循ACID規(guī)則

事務(wù)在英文中是transaction，和現(xiàn)實(shí)世界中的交易很類似，它有如下四個(gè)特性：

A (Atomicity) 原子性

原子性很容易理解，也就是說(shuō)事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個(gè)操作失敗，整個(gè)事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個(gè)步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢(qián)會(huì)莫名其妙少了100元。

C (Consistency) 一致性

一致性也比較容易理解，也就是說(shuō)數(shù)據(jù)庫(kù)要一直處于一致的狀態(tài)，事務(wù)的運(yùn)行不會(huì)改變數(shù)據(jù)庫(kù)原本的一致性約束。

I (Isolation) 獨(dú)立性

所謂的獨(dú)立性是指并發(fā)的事務(wù)之間不會(huì)互相影響，如果一個(gè)事務(wù)要訪問(wèn)的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問(wèn)的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事務(wù)提交后，它所做的修改將會(huì)永久的保存在數(shù)據(jù)庫(kù)上，即使出現(xiàn)宕機(jī)也不會(huì)丟失。

3.2 NoSQL

代表著不僅僅是SQL

沒(méi)有聲明性查詢語(yǔ)言

沒(méi)有預(yù)定義的模式

鍵 - 值對(duì)存儲(chǔ)，列存儲(chǔ)，文檔存儲(chǔ)，圖形數(shù)據(jù)庫(kù)

最終一致性，而非ACID屬性

非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)

CAP定理

高性能，高可用性和可伸縮性

分布式數(shù)據(jù)庫(kù)中的CAP原理(了解)

CAP定理：

Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動(dòng)都是同步的

Availability(可用性), 好的響應(yīng)性能

Partition tolerance(分區(qū)容錯(cuò)性) 可靠性

P: 系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。

定理：任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒(méi)法三者兼顧。

CAP理論的核心是：一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性，可用性和分區(qū)容錯(cuò)性這三個(gè)需求，

因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫(kù)分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

CA - 單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。

CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。

AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐?duì)一致性要求低一些。

CAP理論就是說(shuō)在分布式存儲(chǔ)系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。

而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問(wèn)題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。

所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒(méi)有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。

說(shuō)明：C：強(qiáng)一致性 A：高可用性 P：分布式容忍性

舉例：

CA：傳統(tǒng)Oracle數(shù)據(jù)庫(kù)

AP：大多數(shù)網(wǎng)站架構(gòu)的選擇

CP：Redis、Mongodb

注意：分布式架構(gòu)的時(shí)候必須做出取舍。

一致性和可用性之間取一個(gè)平衡。多余大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性。

因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。

4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用

當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。

代表項(xiàng)目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型機(jī)，很貴的，好像好幾萬(wàn)一臺(tái)；O 是指 Oracle 數(shù)據(jù)庫(kù)，也很貴的，好幾萬(wàn)呢；M 是指 EMC 的存儲(chǔ)設(shè)備，也很貴的。

難點(diǎn)：

數(shù)據(jù)類型多樣性。

數(shù)據(jù)源多樣性和變化重構(gòu)。

數(shù)據(jù)源改造而服務(wù)平臺(tái)不需要大面積重構(gòu)。

如何使用nosql db

No SQL DB是一種和關(guān)系型數(shù)據(jù)庫(kù)相對(duì)應(yīng)的對(duì)象數(shù)據(jù)庫(kù)。按照數(shù)據(jù)模型保存性質(zhì)將當(dāng)前NoSQL分為四種：

1.Key-value stores鍵值存儲(chǔ), 保存keys+BLOBs

2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra.

3.Document-oriented面向文本, 文本是一種類似XML文檔，MongoDB 和 CouchDB

4.Graph-oriented 面向圖論. 如Neo4J.

關(guān)系型數(shù)據(jù)庫(kù)的弊端：

關(guān)系型數(shù)據(jù)庫(kù)的歷史已經(jīng)有30余年了，因此，在某些情況下，關(guān)系型數(shù)據(jù)庫(kù)的弱點(diǎn)就會(huì)暴露出來(lái)：

1. “對(duì)象-關(guān)系 阻抗不匹配”。關(guān)系模型和面向?qū)ο竽Ｐ驮诟拍钌洗嬖谔烊坏牟黄ヅ涞牡胤?，比如?duì)象模型當(dāng)中特有的“繼承”，“組合”，“聚合”，“依賴”的概念在關(guān)系模型當(dāng)中是不存在的。

2. “模式演進(jìn)”。即隨著時(shí)間的推移，需要對(duì)數(shù)據(jù)庫(kù)模式進(jìn)行調(diào)整以便適應(yīng)新的需求，然而，對(duì)數(shù)據(jù)庫(kù)模式的調(diào)整是的成本很高的動(dòng)作，因此很多設(shè)計(jì)師在系統(tǒng)設(shè)計(jì)之初會(huì)設(shè)計(jì)一個(gè)兼容性很強(qiáng)的數(shù)據(jù)庫(kù)模式，以應(yīng)對(duì)將來(lái)可能出現(xiàn)的需求，然而在現(xiàn)在的web系統(tǒng)開(kāi)發(fā)過(guò)程中，系統(tǒng)的變更更加頻繁，幾乎無(wú)法預(yù)先設(shè)計(jì)出一種“萬(wàn)能”的數(shù)據(jù)庫(kù)模式以滿足所有的需求，因此 模式演進(jìn)的弊端就愈發(fā)凸顯。

3. 關(guān)系型數(shù)據(jù)庫(kù)處理 稀疏表時(shí)的性能非常差。

4. network-oriented data 很適合處理 人工智能、社交網(wǎng)絡(luò)中的一些需求。

所以，各種各樣的No SQL DB 出現(xiàn)了，這里只簡(jiǎn)單介紹下Neo4J 的基本知識(shí)。

Neo 數(shù)據(jù)模型

Neo4J 是一個(gè)基于圖實(shí)現(xiàn)的No SQL DB, 其基本的數(shù)據(jù)類型有如下幾種：

Node, Relationship, Property.

Node 對(duì)應(yīng)于圖中的 節(jié)點(diǎn)，Relationship 對(duì)應(yīng)圖中的邊，Node 和 Relationship 都可以擁有Property，

Property 的數(shù)據(jù)結(jié)構(gòu)為。

數(shù)據(jù)遍歷

Neo 提供了Traverser對(duì)數(shù)據(jù)中的數(shù)據(jù)進(jìn)行遍歷。

nosql數(shù)據(jù)庫(kù)的四種類型

nosql數(shù)據(jù)庫(kù)的四種類型如下：

1.key-value鍵值存儲(chǔ)數(shù)據(jù)庫(kù):

相關(guān)產(chǎn)品: Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached.

主要應(yīng)用: 內(nèi)容緩存,處理大量數(shù)據(jù)的高負(fù)載訪問(wèn),也用于系統(tǒng)日志。

優(yōu)點(diǎn):查找速度快,大量操作時(shí)性能高。

2.列存儲(chǔ)數(shù)據(jù)庫(kù):

相關(guān)產(chǎn)品: BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS.

主要應(yīng)用: 分布式數(shù)據(jù)的儲(chǔ)存與管理。

優(yōu)點(diǎn):查找速度快,可擴(kuò)展性強(qiáng),容易進(jìn)行分布式擴(kuò)展。

缺點(diǎn):功能相對(duì)局限。

3.文檔型數(shù)據(jù)庫(kù)

相關(guān)產(chǎn)品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit.

主要應(yīng)用: web應(yīng)用,管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù)。

優(yōu)點(diǎn):數(shù)據(jù)結(jié)構(gòu)靈活,表結(jié)構(gòu)可變,復(fù)雜性低。

缺點(diǎn):查詢效率低,且缺乏統(tǒng)一的查詢語(yǔ)言。

4.Graph圖形數(shù)據(jù)庫(kù)

相關(guān)產(chǎn)品: Neo4J、OrientDB、InfoGrid、GraphDB.

主要應(yīng)用: 復(fù)雜,互連接,低結(jié)構(gòu)化的圖結(jié)構(gòu)場(chǎng)合, 專注構(gòu)建關(guān)系圖譜。

優(yōu)點(diǎn): 利用圖結(jié)構(gòu)相關(guān)算法, 可用于構(gòu)建復(fù)雜的關(guān)系圖譜。

缺點(diǎn): 復(fù)雜度高。

一、NoSQL數(shù)據(jù)庫(kù)簡(jiǎn)介

Web1.0的時(shí)代，數(shù)據(jù)訪問(wèn)量很有限，用一夫當(dāng)關(guān)的高性能的單點(diǎn)服務(wù)器可以解決大部分問(wèn)題。

隨著Web2.0的時(shí)代的到來(lái)，用戶訪問(wèn)量大幅度提升，同時(shí)產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來(lái)的智能移動(dòng)設(shè)備的普及，所有的互聯(lián)網(wǎng)平臺(tái)都面臨了巨大的性能挑戰(zhàn)。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關(guān)系型的數(shù)據(jù)庫(kù)。

NoSQL 不依賴業(yè)務(wù)邏輯方式存儲(chǔ)，而以簡(jiǎn)單的key-value模式存儲(chǔ)。因此大大的增加了數(shù)據(jù)庫(kù)的擴(kuò)展能力。

Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫(kù) 列式數(shù)據(jù)庫(kù) Hbase Hbase

HBase是Hadoop項(xiàng)目中的數(shù)據(jù)庫(kù)。它用于需要對(duì)大量的數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)的讀寫(xiě)操作的場(chǎng)景中。

HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計(jì)算機(jī)處理超過(guò)10億行數(shù)據(jù)，還可處理有數(shù)百萬(wàn)列元素的數(shù)據(jù)表。

Cassandra Cassandra

Apache Cassandra是一款免費(fèi)的開(kāi)源NoSQL數(shù)據(jù)庫(kù)，其設(shè)計(jì)目的在于管理由大量商用服務(wù)器構(gòu)建起來(lái)的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達(dá)到PB級(jí)別)。在眾多顯著特性當(dāng)中，Cassandra最為卓越的長(zhǎng)處是對(duì)寫(xiě)入及讀取操作進(jìn)行規(guī)模調(diào)整，而且其不強(qiáng)調(diào)主集群的設(shè)計(jì)思路能夠以相對(duì)直觀的方式簡(jiǎn)化各集群的創(chuàng)建與擴(kuò)展流程。

主要應(yīng)用：社會(huì)關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜(n*(n-1)/2)