如何選擇NoSQL數(shù)據(jù)庫

NoSQL，指的是非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的

建網(wǎng)站原本是網(wǎng)站策劃師、網(wǎng)絡程序員、網(wǎng)頁設計師等，應用各種網(wǎng)絡程序開發(fā)技術和網(wǎng)頁設計技術配合操作的協(xié)同工作。成都創(chuàng)新互聯(lián)公司專業(yè)提供成都網(wǎng)站制作、做網(wǎng)站,網(wǎng)頁設計,網(wǎng)站制作(企業(yè)站、響應式網(wǎng)站設計、電商門戶網(wǎng)站)等服務,從網(wǎng)站深度策劃、搜索引擎友好度優(yōu)化到用戶體驗的提升,我們力求做到極致!

SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。

NoSQL(NoSQL

= Not Only SQL

)，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數(shù)

據(jù)存儲，相對于鋪天蓋地的關系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。

從這一新興技術中選擇一款正確的NoSQL數(shù)據(jù)庫是非常具有挑戰(zhàn)性的。比一下網(wǎng)建議在選擇時考慮以下因素：

并發(fā)控制

并

發(fā)控制指的是當多個用戶同時更新運行時，用于保護數(shù)據(jù)庫完整性的各種技術。并發(fā)機制不正確可能導致臟讀、幻讀和不可重復讀等此類問題。并發(fā)控制的目的是保

證一個用戶的工作不會對另一個用戶的工作產(chǎn)生不合理的影響。在某些情況下，這些措施保證了當用戶和其他用戶一起操作時，所得的結果和她單獨操作時的結果是

一樣的。在另一些情況下，這表示用戶的工作按預定的方式受其他用戶的影響。

封鎖

就是事務T在對某個數(shù)據(jù)對象（例如表、記錄等）操作之前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務T就對該數(shù)據(jù)對象有了一定的控制，在事務T釋放它的鎖之前，其它的事務不能更新此數(shù)據(jù)對象。

封鎖是一次只允許一個用戶讀取或修改的一種機制，是實現(xiàn)并發(fā)控制的一個非常重要的技術。

MVCC

Multi-Version Concurrency Control多版本并發(fā)控制，維持一個數(shù)據(jù)的多個版本使讀寫操作沒有沖突。MVCC優(yōu)化了數(shù)據(jù)庫并發(fā)系統(tǒng)，使系統(tǒng)在有大量并發(fā)用戶時得到最高的性能，并且可以不用關閉服務器就直接進行熱備份。

ACID

指

數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久

性（Durability）。一個支持事務（Transaction）的數(shù)據(jù)庫系統(tǒng)，必需要具有這四種特性，否則在事務過程（Transaction

processing）當中無法保證數(shù)據(jù)的正確性，交易過程極可能達不到交易方的要求。

None

一些系統(tǒng)不提供原子性。

鏡像

數(shù)據(jù)庫鏡像是DBMS根據(jù)DBA的要求，自動把整個數(shù)據(jù)庫或其中的關鍵數(shù)據(jù)復制到另一個磁盤上，每當主數(shù)據(jù)庫更新時，DBMS會自動把更新后的數(shù)據(jù)復制過去，即DBMS自動保證鏡像數(shù)據(jù)與主數(shù)據(jù)的一致性。

鏡像分為同步和異步。

數(shù)據(jù)存儲

指的是數(shù)據(jù)的物理特性怎樣被存儲在數(shù)據(jù)庫中。

磁盤 數(shù)據(jù)被存儲在硬盤驅動器里；

GFS或谷歌文件系統(tǒng)是一個由谷歌開發(fā)的專有的分布式文件系統(tǒng)；

Hadoop是Apache軟件框架，免費許可下支持數(shù)據(jù)密集型分布式應用程序；

RAM隨機存儲器；

插件 可以添加外部插件；

Amazon S3通過Web服務接口提供存儲；

BDB：BDB

全稱是 “Berkeley DB”，它是MySQL具有事務能力的表類型，由Sleepycat

Software開發(fā)。BDB表類型提供了MySQL用戶長久期盼的功能，即事務控制能力。在任何RDBMS中，事務控制能力都是一種極其重要和寶貴的功

能。事務控制能力使得我們能夠確保一組命令確實已經(jīng)全部執(zhí)行成功，或者確保當任何一個命令出現(xiàn)錯誤時所有命令的執(zhí)行結果均被退回。

實現(xiàn)語言

實現(xiàn)語言會影響數(shù)據(jù)庫的發(fā)展速度。典型的NoSQL數(shù)據(jù)庫是用低級語言如C / C + +編寫的。另一方面，那些更高層次的語言如Java，使自定義更容易。

實現(xiàn)語言有：C, C++, Erlang, Java, Python

特性

考慮下列哪一個特點對你的數(shù)據(jù)庫是最重要的：

持久性

可用性

一致性

分區(qū)容忍性

證書類型

下面這些許可證是一個不同的開放源碼許可的形式：

GPL：通用公共許可證

BSD：伯克利軟件分發(fā)

MPL：Mozilla公共許可證

EPL：Eclipse公共許可證

IDPL：最初的開發(fā)者的公共許可證

LGPL：較寬松通用公共許可證

存儲類型

存儲類型是NoSQL數(shù)據(jù)庫最大的不同，是決定使用哪款數(shù)據(jù)庫的一個首要指標。

關鍵字：支持get、put和刪除操作

按列存儲：相對于傳統(tǒng)的按行存儲，數(shù)據(jù)集成容易多了

面向文件系統(tǒng)：存儲像是JSON或XML這樣的結構化文件，很容易就能從面向對象軟件中獲取數(shù)據(jù)。

圖數(shù)據(jù)庫和關系數(shù)據(jù)庫的區(qū)別

1、數(shù)據(jù)bai存儲方式不同。

關系型和非關系型數(shù)據(jù)庫的主要差異是數(shù)據(jù)存儲的方式。關系型數(shù)據(jù)天然就是表格式的，因此存儲在數(shù)據(jù)表的行和列中。數(shù)據(jù)表可以彼此關聯(lián)協(xié)作存儲，也很容易提取數(shù)據(jù)。

與其相反，非關系型數(shù)據(jù)不適合存儲在數(shù)據(jù)表的行和列中，而是大塊組合在一起。非關系型數(shù)據(jù)通常存儲在數(shù)據(jù)集中，就像文檔、鍵值對或者圖結構。你的數(shù)據(jù)及其特性是選擇數(shù)據(jù)存儲和提取方式的首要影響因素。

2、擴展方式不同。

SQL和NoSQL數(shù)據(jù)庫最大的差別可能是在擴展方式上，要支持日益增長的需求當然要擴展。

要支持更多并發(fā)量，SQL數(shù)據(jù)庫是縱向擴展，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的數(shù)據(jù)集就更快了。

因為數(shù)據(jù)存儲在關系表中，操作的性能瓶頸可能涉及很多個表，這都需要通過提高計算機性能來客服。雖然SQL數(shù)據(jù)庫有很大擴展空間，但最終肯定會達到縱向擴展的上限。而NoSQL數(shù)據(jù)庫是橫向擴展的。

而非關系型數(shù)據(jù)存儲天然就是分布式的，NoSQL數(shù)據(jù)庫的擴展可以通過給資源池添加更多普通的數(shù)據(jù)庫服務器(節(jié)點)來分擔負載。

3、對事務性的支持不同。

如果數(shù)據(jù)操作需要高事務性或者復雜數(shù)據(jù)查詢需要控制執(zhí)行計劃，那么傳統(tǒng)的SQL數(shù)據(jù)庫從性能和穩(wěn)定性方面考慮是你的最佳選擇。SQL數(shù)據(jù)庫支持對事務原子性細粒度控制，并且易于回滾事務。

雖然NoSQL數(shù)據(jù)庫也可以使用事務操作，但穩(wěn)定性方面沒法和關系型數(shù)據(jù)庫比較，所以它們真正閃亮的價值是在操作的擴展性和大數(shù)據(jù)量處理方面。

什么是nosql非結構化數(shù)據(jù)庫

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

NewSQL為何使傳統(tǒng)關系數(shù)據(jù)庫黯然失色？

傳統(tǒng)數(shù)據(jù)庫仍舊會有一席之地，至于NewSQL的優(yōu)勢又是什么，簡單和大家說說：

首先關于“中間件+關系數(shù)據(jù)庫分庫分表”算不算NewSQL分布式數(shù)據(jù)庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫，本文暫不詳細介紹）。

基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關系數(shù)據(jù)庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現(xiàn)橫向擴展。但是不是“偽”分布式數(shù)據(jù)庫？從架構先進性來看，這么說也有一定道理。

“偽”主要體現(xiàn)在中間件層與底層DB重復的SQL解析與執(zhí)行計劃生成、存儲引擎基于B+Tree等，這在分布式數(shù)據(jù)庫架構中實際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫特指這種新架構NewSQL數(shù)據(jù)庫。

NewSQL數(shù)據(jù)庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：

傳統(tǒng)數(shù)據(jù)庫面向磁盤設計，基于內存的存儲管理及并發(fā)控制，不如NewSQL數(shù)據(jù)庫那般高效利用；

中間件模式SQL解析、執(zhí)行計劃優(yōu)化等在中間件與數(shù)據(jù)庫中重復工作，效率相比較低；

NewSQL數(shù)據(jù)庫的分布式事務相比于XA進行了優(yōu)化，性能更高；

新架構NewSQL數(shù)據(jù)庫存儲設計即為基于paxos（或Raft）協(xié)議的多副本，相比于傳統(tǒng)數(shù)據(jù)庫主從模式（半同步轉異步后也存在丟數(shù)問題），在實現(xiàn)了真正的高可用、高可靠（RTO30s，RPO=0）；

NewSQL數(shù)據(jù)庫天生支持數(shù)據(jù)分片，數(shù)據(jù)的遷移、擴容都是自動化的，大大減輕了DBA的工作，同時對應用透明，無需在SQL指定分庫分表鍵。

NoSQL會取代完全取代關系型數(shù)據(jù)庫嗎？

對此，前Google工程師，Milo（本地商店搜索引擎）創(chuàng)始人Ted Dziuba最近發(fā)表標題驚人的博客“I Can't Wait for NoSQL to Die”，對NoSQL的適用范圍進行了分析。他認為， NoSQL也會帶來一連串的新問題，并不會成為主流，無法取代關系型數(shù)據(jù)庫。 他的理由是：Cassandra等NoSQL數(shù)據(jù)庫在使用上并不方便，比如，修改column family定義時就需要重啟。而且NoSQL更適合Google那樣的規(guī)模，而一般的互聯(lián)網(wǎng)公司都不是Google，早早地去考慮Google那樣的規(guī)模的可擴展性，純粹是浪費時間，存在巨大的商業(yè)風險。 他還透露，即使在Google，AdWords這樣的關鍵產(chǎn)品也是基于MySQL實現(xiàn)的。 他在文中最后表示，NoSQL當然死不了，但是 它最終會被邊緣化，就像Rails被NoSQL邊緣化一樣 Dziuba的文章因為言辭激烈，在社區(qū)里引起了強烈反應。 SQL數(shù)據(jù)庫陣營贊同者大有人在。craigslist工程師、著名的MySQL專家Jeremy Zawodny表示，在讀此文的時候，不時會心一笑。他說， NoSQL運動只是軟件不斷進化進程中的正?，F(xiàn)象 。關系型數(shù)據(jù)庫也會繼續(xù)發(fā)展，MySQL社區(qū)不斷推出的XtraDB或InnoDB插件, PBXT, Drizzle都是證據(jù)。各種技術競爭的結果是，我們獲得了更多解決問題的選擇。 drizzle項目開發(fā)者Eric Day也表示，NoSQL有很多值得學習的，但是目前大部分實際項目的最佳選擇還是關系型數(shù)據(jù)庫。 NoSQL陣營當然不會坐視不理，Cassandra項目組的Eric Evans表示，Dziuba提到Cassandra修改column family定義的問題其實很容易解決。而且，NoSQL并不是要取代MySQL，事實上Twitter仍然在用MySQL。如果關系型數(shù)據(jù)庫能夠承擔負荷，那就用好了；如果不行，請考慮NoSQL。 而德國知名博客Code Monkeyism則嘲笑Dziuba看起來并沒有用MySQL做過真實項目，因為MySQL如果沒有memcache，基本上無法應付網(wǎng)站項目。他認為，NoSQL將使SQL數(shù)據(jù)庫邊緣化，而且一個重要理由恰恰是可以節(jié)省DBA的開銷。 digg的前任首席架構師現(xiàn)在也在創(chuàng)業(yè)的Joe Stump說，自己現(xiàn)在的創(chuàng)業(yè)項目就是用NoSQL，而且列舉了一系列問題挑戰(zhàn)SQL陣營。

數(shù)據(jù)管理員DBA是什么意思？

數(shù)據(jù)庫管理員（Database Administrator，簡稱DBA），是從事管理和維護數(shù)據(jù)庫管理系統(tǒng)(DBMS)的相關工作人員的統(tǒng)稱，屬于運維工程師的一個分支，主要負責業(yè)務數(shù)據(jù)庫從設計、測試到部署交付的全生命周期管理。

DBA的核心目標是保證數(shù)據(jù)庫管理系統(tǒng)的穩(wěn)定性、安全性、完整性和高性能。在國外，也有公司把DBA稱作數(shù)據(jù)庫工程師(Database Engineer)，兩者的工作內容基本相同，都是保證數(shù)據(jù)庫服務7*24小時的穩(wěn)定高效運轉。

擴展資料

優(yōu)秀的DBA不僅關心自己運維的數(shù)據(jù)庫系統(tǒng)的原理和發(fā)展，而且緊跟業(yè)界數(shù)據(jù)庫前沿技術，并關注數(shù)據(jù)庫領域的頂級會議。其中包括國際著名的數(shù)據(jù)庫三大會議SIGMOD、VLDB、ICDE，還有知名數(shù)據(jù)庫公司Percona主辦的Percona Live和Oracle主辦的Open World等。

從另外一個角度說，DBA工作領域對實踐經(jīng)驗和獨立工作能力要求較高，沒有經(jīng)過大量的動手實踐是很難勝任DBA相關工作的 。正是由于上述原因，其職場現(xiàn)狀是DBA職位不易進入，而用人單位很難找到合適的從業(yè)人員，人員缺口非常大。

參考資料來源：百度百科-數(shù)據(jù)庫管理員