什么是nosql非結(jié)構(gòu)化數(shù)據(jù)庫

基本含義NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項(xiàng)全新的數(shù)據(jù)庫革命性運(yùn)動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運(yùn)用，這一概念無疑是一種全新的思維的注入。NoSQLNoSQL數(shù)據(jù)庫的四大分類鍵值(Key-Value)存儲數(shù)據(jù)庫這一類數(shù)據(jù)庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進(jìn)行查詢或更新的時候，Key/value就顯得效率低下了。[3] 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.列存儲數(shù)據(jù)庫。這部分?jǐn)?shù)據(jù)庫通常是用來應(yīng)對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點(diǎn)是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.文檔型數(shù)據(jù)庫文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲，比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如：CouchDB, MongoDb. 國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB，已經(jīng)開源。圖形(Graph)數(shù)據(jù)庫圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴(kuò)展到多個服務(wù)器上。NoSQL數(shù)據(jù)庫沒有標(biāo)準(zhǔn)的查詢語言(SQL)，因此進(jìn)行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。[2] 如：Neo4J, InfoGrid, Infinite Graph.因此，我們總結(jié)NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用：1、數(shù)據(jù)模型比較簡單；2、需要靈活性更強(qiáng)的IT系統(tǒng)；3、對數(shù)據(jù)庫性能要求較高；4、不需要高度的數(shù)據(jù)一致性；5、對于給定key，比較容易映射復(fù)雜值的環(huán)境。

成都創(chuàng)新互聯(lián)是一家專業(yè)提供維西企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、H5頁面制作、小程序制作等業(yè)務(wù)。10年已為維西眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

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

2. 什么是NoSQL？

2.1 NoSQL 概述

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

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

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

2.2 NoSQL代表

MongDB、 Redis、Memcache

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

3.1 RDBMS

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

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

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

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

嚴(yán)格的一致性

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

ACID

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

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

A (Atomicity) 原子性

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

C (Consistency) 一致性

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

I (Isolation) 獨(dú)立性

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

D (Durability) 持久性

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

3.2 NoSQL

代表著不僅僅是SQL

沒有聲明性查詢語言

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

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

最終一致性，而非ACID屬性

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

CAP定理

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

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

CAP定理：

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

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

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

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

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

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

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

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

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

AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通常可能對一致性要求低一些。

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

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

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

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

舉例：

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

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

CP：Redis、Mongodb

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

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

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

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

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

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

去 IOE 化。

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

難點(diǎn)：

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

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

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

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

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

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

1. In-Memory KV Store : Redis

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

2. Disk-Based KV Store: Leveldb

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

3. Document Store: Mongodb

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

4. Column Table Store: HBase

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

NoSQL-HDFS-基本概念

Hadoop

文件系統(tǒng)：文件系統(tǒng)是用來存儲和管理文件，并且提供文件的查詢、增加、刪除等操作。

直觀上的體驗(yàn)：在shell窗口輸入 ls 命令，就可以看到當(dāng)前目錄下的文件夾、文件。

文件存儲在哪里？硬盤

一臺只有250G硬盤的電腦，如果需要存儲500G的文件可以怎么辦？先將電腦硬盤擴(kuò)容至少250G，再將文件分割成多塊，放到多塊硬盤上儲存。

通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。

HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實(shí)現(xiàn)將分布在多臺機(jī)器上的文件系統(tǒng)進(jìn)行統(tǒng)一的管理。

在分布式文件系統(tǒng)中，一個大文件會被切分成塊，分別存儲到幾臺機(jī)器上。結(jié)合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然后分別存儲在若干臺機(jī)器上，然后提供統(tǒng)一的操作接口。

看到這里，不少人可能會覺得，分布式文件系統(tǒng)不過如此，很簡單嘛。事實(shí)真的是這樣的么？

潛在問題

假如我有一個1000臺機(jī)器組成的分布式系統(tǒng)，一臺機(jī)器每天出現(xiàn)故障的概率是0.1%，那么整個系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機(jī)制來保證發(fā)生差錯時文件依然可以讀出，這里暫時先不展開介紹。

如果要存儲PB級或者EB級的數(shù)據(jù)，成千上萬臺機(jī)器組成的集群是很常見的，所以說分布式系統(tǒng)比單機(jī)系統(tǒng)要復(fù)雜得多呀。

這是一張HDFS的架構(gòu)簡圖：

client通過nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教N(yùn)ameNode，看看應(yīng)該往哪個DateNode中去寫。

為了某一份數(shù)據(jù)只寫入到一個Datanode中，而這個Datanode因?yàn)槟承┰虺鲥e無法讀取的問題，需要通過冗余備份的方式來進(jìn)行容錯處理。因此，HDFS在寫入一個數(shù)據(jù)塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。

實(shí)際上，每個數(shù)據(jù)塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。

接下來我們來看一下完整的文件寫入的流程：

大文件要寫入HDFS，client端根據(jù)配置將大文件分成固定大小的塊，然后再上傳到HDFS。

讀取文件的流程：

1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？

2、NameNode回復(fù)client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取并且整合起來

文件寫入的流程：

1、client先將文件分塊，然后詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應(yīng)該怎么寫？

2、NameNode回復(fù)client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復(fù)寫3份，總共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據(jù)寫到他們上面

出于容錯的考慮，每個數(shù)據(jù)塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點(diǎn)是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進(jìn)行同步的，HDFS當(dāng)然也可以借鑒這個思想，數(shù)據(jù)其實(shí)只需要寫入到一個datanode上，然后由datanode之間相互進(jìn)行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當(dāng)然這個設(shè)置會影響到數(shù)據(jù)寫入的吞吐率，我們可以看到可靠性和效率永遠(yuǎn)是“魚和熊掌不可兼得”的。

潛在問題

NameNode確實(shí)會回放editlog，但是不是每次都從頭回放，它會先加載一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數(shù)據(jù)的內(nèi)存快照，然后再在這個基礎(chǔ)上回放editlog，完成后，會清空editlog，再把當(dāng)前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫入fsimage，方便下一次加載。

這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復(fù)的時間依然比較長，這個問題怎么解呢？

SecondNameNode是一個NameNode內(nèi)的定時任務(wù)線程，它會定期地將editlog寫入fsimage，然后情況原來的editlog，從而保證editlog的文件大小維持在一定大小。

NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統(tǒng)就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發(fā)生單點(diǎn)故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。

俗話說“一山不容二虎”，兩個NameNode只能有一個是活躍狀態(tài)active，另一個是備份狀態(tài)standby，我們看一下兩個NameNode的架構(gòu)圖。

兩個NameNode通過JournalNode實(shí)現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。

因?yàn)閍ctive的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據(jù)要時刻保持一致，在寫入數(shù)據(jù)的時候，兩個NameNode內(nèi)存中都要記錄數(shù)據(jù)的元信息，并保持一致。這個JournalNode就是用來在兩個NameNode中同步數(shù)據(jù)的，并且standby NameNode實(shí)現(xiàn)了SecondNameNode的功能。

進(jìn)行數(shù)據(jù)同步操作的過程如下：

active NameNode有操作之后，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化并進(jìn)行同步，同時standby NameNode會監(jiān)聽記錄的變化。這樣做的話就是實(shí)時同步了，并且standby NameNode就實(shí)現(xiàn)了SecondNameNode的功能。

優(yōu)點(diǎn)：

缺點(diǎn)：

nosql 怎么用?在關(guān)系數(shù)據(jù)庫中可以通過 select 語句查詢,但是在nosql中怎么用這個了,難道只能存儲鍵值對?

NoSQL數(shù)據(jù)庫有很多種，實(shí)現(xiàn)方式差別很大。有接近SQL查詢方式的，也有純粹的鍵值對查詢。

對于K-V型數(shù)據(jù)庫，比較典型的是Redis，系統(tǒng)提供了get、set之類的命令用于增刪改查。關(guān)鍵是鍵值對的鍵和值怎么設(shè)計(jì)。

什么是nosql數(shù)據(jù)庫？nosql和rdbms有什么區(qū)別

1 理解ACID與BASE的區(qū)別（ACID是關(guān)系型數(shù)據(jù)庫強(qiáng)一致性的四個要求，而BASE是NoSQL數(shù)據(jù)庫通常對可用性及一致性的弱要求原則，它們的意思分別是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸，BASE意思為堿）

2 理解持久化與非持久化的區(qū)別。這么說是因?yàn)橛械腘oSQL系統(tǒng)是純內(nèi)存存儲的。

3 你必須意識到傳統(tǒng)有關(guān)系型數(shù)據(jù)庫與NoSQL系統(tǒng)在數(shù)據(jù)結(jié)構(gòu)上的本質(zhì)區(qū)別。傳統(tǒng)關(guān)系型數(shù)據(jù)庫通常是基于行的表格型存儲，而NoSQL系統(tǒng)包括了列式存儲（Cassandra）、key/value存儲（Memcached）、文檔型存儲（CouchDB）以及圖結(jié)構(gòu)存儲（Neo4j）

4與傳統(tǒng)關(guān)系數(shù)據(jù)庫有統(tǒng)一的SQL語言操作接口不同，NoSQL系統(tǒng)通常有自己特有的API接口。

5 在架構(gòu)上，你必須搞清楚，NoSQL系統(tǒng)是被設(shè)計(jì)用于成百上千臺機(jī)器的集群中的，而非共享型數(shù)據(jù)庫系統(tǒng)的架構(gòu)。

6在NoSQL系統(tǒng)中，可能你得習(xí)慣一下不知道你的數(shù)據(jù)具體存在何處的情況。

7 在NoSQL系統(tǒng)中，你最好習(xí)慣它的弱一致性。”eventually consistent”(最終一致性)正是BASE原則中的重要一項(xiàng)。比如在Twitter，你在Followers列表中經(jīng)常會感受到數(shù)據(jù)的延遲。

8 在NoSQL系統(tǒng)中，你要理解，很多時候數(shù)據(jù)并不總是可用的。

9 你得理解，有的方案是擁有分區(qū)容忍性的，有的方案不一定有。

分享名稱：nosql接口,nosql數(shù)據(jù)庫技術(shù)
網(wǎng)址分享：http://chinadenli.net/article16/dsidpgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、服務(wù)器托管、網(wǎng)站導(dǎo)航、ChatGPT、Google、微信公眾號

廣告

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