建站
咨詢
售后
建站咨詢
新聞中心
數(shù)據(jù)庫是什么?Oracle又是啥玩意?
經(jīng)常會有人問我數(shù)據(jù)庫是干啥的，其實一開始我是拒絕回答的，因為我也不能做到通俗易懂的表達出來，畢竟我接觸這個概念也沒有多長時間，但隨著問的人多了，我覺得是時候腦補一下我的第一堂課了，萬一哪天冒出來個貨跟你掰扯這事兒，你沒分分鐘給他說清，最后弄個丟里兒丟面兒，好尷尬呀。
為連城等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及連城網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站設計、網(wǎng)站建設、連城網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
數(shù)據(jù)庫，說白了就是按照數(shù)據(jù)結構來組織、存儲和管理數(shù)據(jù)的倉庫，這些數(shù)據(jù)是結構化的，并可為多種應用服務。也就是說，數(shù)據(jù)庫是使用計算機服務器來存儲數(shù)據(jù)的，專門用來提供各種數(shù)據(jù)服務。可以這樣想像，過去一個公司的所有財務數(shù)據(jù)都是放在保險柜里面，而現(xiàn)在我們就可以針對這些財務數(shù)據(jù)搭建一個數(shù)據(jù)庫放在某臺計算機或服務器上面;再比如，企業(yè)或事業(yè)單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個數(shù)據(jù)庫。有了這個"數(shù)據(jù)倉庫"我們就可以根據(jù)需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內(nèi)的職工人數(shù)等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。此外，在財務管理、倉庫管理、生產(chǎn)管理中也需要建立眾多的這種"數(shù)據(jù)庫"，使其可以利用計算機實現(xiàn)財務、倉庫、生產(chǎn)的自動化管理。最常見的數(shù)據(jù)庫有：銀行儲蓄系統(tǒng)、手機話費系統(tǒng)、美容美發(fā)會員系統(tǒng)、超市會員積分系統(tǒng)、水電費系統(tǒng)、機票或火車票系統(tǒng)等，這些都需要后臺數(shù)據(jù)庫基礎設施的支撐。舉了這么多例子，應該是把數(shù)據(jù)庫說明白了，至少能在大腦里面有個概念，知道這個東西是干啥的。
現(xiàn)在大數(shù)據(jù)被炒的紅得發(fā)紫，而大數(shù)據(jù)的基礎也是數(shù)據(jù)，由此可見，數(shù)據(jù)是一個企業(yè)的核心資源，說它是企業(yè)的立身之本、發(fā)展之基都不為過，因此，維護數(shù)據(jù)庫的數(shù)據(jù)庫管理員(DBA)是企業(yè)不可或缺的。
目前市面上的數(shù)據(jù)庫產(chǎn)品有很多，單從規(guī)模上分可分為大型、中型、小型幾種，典型的數(shù)據(jù)庫產(chǎn)品如下：
大型數(shù)據(jù)庫：Oracle、DB2、Sybase;
中型數(shù)據(jù)庫：MySQL、SQLServer、Infomix;
小型數(shù)據(jù)庫：Access、VisualFoxpro。在眾多的數(shù)據(jù)庫產(chǎn)品中，Oracle數(shù)據(jù)庫一直處于行業(yè)領導先地位，也是當今最流行的關系型數(shù)據(jù)庫。Oracle可翻譯成"甲骨文"，它是一家以數(shù)據(jù)庫為主業(yè)的全球化公司，是全球第二大軟件公司(第一名是微軟公司)，目前Oracle在數(shù)據(jù)庫軟件市場已經(jīng)排名第一，數(shù)據(jù)庫軟件市場份額達到48.6%，遙遙領先于第二名占有率僅為20.7%的IBM公司的DB2。在中國市場上的計算機專業(yè)系統(tǒng)后臺所使用的數(shù)據(jù)庫尤以Oracle數(shù)據(jù)庫居多。但是購買Oracle數(shù)據(jù)庫需要很大一筆費用，一般的大型企業(yè)使用，需要有專業(yè)人員進行管理和維護，中小企業(yè)承擔不起。中小企業(yè)為了節(jié)省成本，一般使用MySQL、PostgreSQL這類免費開源的數(shù)據(jù)庫，所以Oracle數(shù)據(jù)庫相關的工作崗位一般是在大型企業(yè)中。
對于為什么選擇Oracle數(shù)據(jù)庫，而不是其他的數(shù)據(jù)庫?
第一，是因為Oracle數(shù)據(jù)庫占據(jù)最大的市場份額，并且越來越大，市場需要很多Oracle數(shù)據(jù)庫方面的人才，中國有句老話說"做對事，選對人"，是同樣的道理;第二，是很多非Oracle數(shù)據(jù)庫的老系統(tǒng)正往Oracle數(shù)據(jù)庫遷移，其他數(shù)據(jù)庫市場占有率在減少，其他數(shù)據(jù)庫工作者有面臨失業(yè)的風險;第三，Oracle有大量的官方學習文檔，還有部分中文文檔，可以有效地進行學習;第四，Oracle有大量的從業(yè)人員，有共同方向的朋友可以互相幫助，不再是孤膽英雄;第五，是可以很容易地從Oracle官方網(wǎng)站下載功能齊全的數(shù)據(jù)庫最新版本進行學習，可以讓你了解數(shù)據(jù)庫方面的最新發(fā)展趨勢等。
在此說明，以后的所有內(nèi)容都是基于Oracle11g數(shù)據(jù)庫產(chǎn)品的，下面我們就簡單介紹一下Oracle11g的系列產(chǎn)品：
企業(yè)版(EnterpriseEdition)此版本包含了數(shù)據(jù)庫的所有組件，并且能夠通過購買選項和程序包來進一步對其增強。
能支持例如大業(yè)務量的在線事務處理OLTP(On-LineTransactionProcessing聯(lián)機事務處理系統(tǒng))環(huán)境、查詢密集的數(shù)據(jù)倉庫和要求苛刻的互聯(lián)網(wǎng)應用程序。
標準版1(StandardEditionOne)此版本為工作組、部門級和互聯(lián)網(wǎng)、內(nèi)聯(lián)網(wǎng)應用程序提供了前所未有的易用性和性價比。從針對小型商務的單服務器環(huán)境到大型的分布式部門環(huán)境，該版本包含了構建重要商務應用程序所必需的全部工具。它僅許可在最高容量為2個處理器的服務器上使用，支持Windows/Linux/UNIX操作系統(tǒng)，并支持64位平臺操作系統(tǒng)。
標準版(StandardEdition)此版本提供了StandardEditionOne所不具有的易用性、能力和性能，并且利用真正的應用集群(RAC)提供了對更大型計算機和服務集群的支持。它可以在最高容量為4個處理器的單臺服務器上、或者在一個支持最多4個處理器的集群上使用，可支持Windows、Linux和UNIX操作系統(tǒng)，并支持64位平臺操作系統(tǒng)。
簡化版此版本支持與標準版1、標準版和企業(yè)版完全兼容的單用戶開發(fā)和部署。通過將Oracle數(shù)據(jù)庫獲獎的功能引入到個人工作站中，該版本提供了結合世界上最流行的數(shù)據(jù)庫功能的數(shù)據(jù)庫，并且該數(shù)據(jù)庫具有桌面產(chǎn)品通常具有的易用性和簡單性，可支持Linux和Windows操作系統(tǒng)。
從存儲結構上來說，目前流行的數(shù)據(jù)庫主要包含以下兩種：
RDBMS：關系型數(shù)據(jù)庫，是指采用了關系模型來組織數(shù)據(jù)的數(shù)據(jù)庫;
NoSQL數(shù)據(jù)庫，是指那些非關系型的、分布式的數(shù)據(jù)庫。簡單來說，關系模型指的就是二維表格模型，而一個關系型數(shù)據(jù)庫就是由二維表及其之間的聯(lián)系所組成的一個數(shù)據(jù)組織。
關系型數(shù)據(jù)庫優(yōu)點：
1、容易理解
二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網(wǎng)狀、層次等其他模型來說更容易理解。
2、使用方便
通用的SQL語言使得操作關系型數(shù)據(jù)庫非常方便。
3、易于維護
豐富的完整性大大減低了數(shù)據(jù)冗余和數(shù)據(jù)部移植的概率。
4、事務安全
所有關系型數(shù)據(jù)庫都不同程度的遵守事物的四個基本屬性，因此對于銀行、電信、證券等交易型業(yè)務是不可或缺的。
關系型數(shù)據(jù)庫的瓶頸：
1、高并發(fā)讀寫需求
網(wǎng)站的用戶并發(fā)性非常高，往往達到每秒上萬次讀寫請求，對于傳統(tǒng)型數(shù)據(jù)庫來說，硬盤I/O是一個很大的瓶頸。
2、海量數(shù)據(jù)的高效率讀寫
互聯(lián)網(wǎng)上每天產(chǎn)生的數(shù)據(jù)量是巨大的，對于關系型數(shù)據(jù)庫來說，在一張包含海量數(shù)據(jù)的表中查詢，效率是非常低的。
3、高擴展性和可用性
在基于WEB的結構中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，數(shù)據(jù)庫卻沒有辦法像WEBServer和APPLICATIONServer那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移。
NoSQL數(shù)據(jù)庫
NoSQL一詞首先是CarloStrozzi在1998年提出的。2009年再次提出了NoSQL一詞，用于指那些非關系型的、分布式的，且一般不保證遵循ACID原則的數(shù)據(jù)存儲系統(tǒng)。
NoSQL具有以下特點：
1、可以彌補關系型數(shù)據(jù)庫的不足
2、針對某些特定的需求而設計，可以具有極高的性能
3、大部分都是開源的，由于成熟度不夠，存在潛在的穩(wěn)定性和維護性問題。
關系型數(shù)據(jù)庫適用于結構化數(shù)據(jù)，而非關系型數(shù)據(jù)庫適用于非結構化數(shù)據(jù)，二者優(yōu)勢互補，相得益彰。
Oracle數(shù)據(jù)庫未來的發(fā)展方向是提供結構化、非結構化、半結構化的解決方案，實現(xiàn)關系型數(shù)據(jù)庫和NoSQL共存互補。值得強調(diào)的是，目前關系型數(shù)據(jù)庫仍是主流數(shù)據(jù)庫。
雖然NoSQL數(shù)據(jù)庫打破了關系型數(shù)據(jù)庫存儲的觀念，可以很好地滿足WEB2.0時代數(shù)據(jù)的存儲要求，但NoSQL數(shù)據(jù)庫也有自己的缺陷。在現(xiàn)階段的情況下，可以將關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫結合使用，相互彌補各自的不足。
關于數(shù)據(jù)庫及其代表產(chǎn)品Oracle今天就介紹這么多，有興趣的可以繼續(xù)深挖，希望我的介紹能讓你對數(shù)據(jù)庫有一個更深入的認識。如果有志于在這方面發(fā)展的話，就讓我們一起跟往事干杯從頭再來。
NoSQL應用
而傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數(shù)據(jù)庫應付上萬次SQL查詢還勉強頂?shù)米?，但是應付上萬次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實對于普通的BBS網(wǎng)站，往往也存在對高并發(fā)寫請求的需求。
2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求
對于大型的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數(shù)以億計的帳號，關系數(shù)據(jù)庫也很難應付。
3、High Scalability High Availability- 對數(shù)據(jù)庫的高可擴展性和高可用性的需求
在基于web的架構當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務器節(jié)點來實現(xiàn)擴展呢？
在上面提到的“三高”需求面前，關系數(shù)據(jù)庫遇到了難以克服的障礙，而對于web2.0網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性卻往往無用武之地，例如：
1、數(shù)據(jù)庫事務一致性需求
很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務管理成了數(shù)據(jù)庫高負載下一個沉重的負擔。
2、數(shù)據(jù)庫的寫實時性和讀實時性需求
對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應用來說，并不要求這么高的實時性。
3、對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求
任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設計角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關系數(shù)據(jù)庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數(shù)據(jù)庫應運而生。
NoSQL 是非關系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結構，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
什么是NoSQL數(shù)據(jù)庫？
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應用難題，包括超大規(guī)模數(shù)據(jù)的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關系型數(shù)據(jù)庫與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結構化數(shù)據(jù)
結構化查詢語言（SQL）
數(shù)據(jù)和關系都存儲在單獨的表中。
數(shù)據(jù)操縱語言，數(shù)據(jù)定義語言
嚴格的一致性
基礎事務
ACID
關系型數(shù)據(jù)庫遵循ACID規(guī)則
事務在英文中是transaction，和現(xiàn)實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務之間不會互相影響，如果一個事務要訪問的數(shù)據(jù)正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數(shù)據(jù)就不受未提交事務的影響。比如現(xiàn)有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務提交后，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫
最終一致性，而非ACID屬性
非結構化和不可預知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統(tǒng)，通常在可擴展性上不太強大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐σ恢滦砸蟮鸵恍?。
CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。
而由于當前的網(wǎng)絡硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統(tǒng)能同時保證這三點。
說明：C：強一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫
AP：大多數(shù)網(wǎng)站架構的選擇
CP：Redis、Mongodb
注意：分布式架構的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應用，其實并不需要強一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當下NoSQL的經(jīng)典應用
當下的應用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一臺；O 是指 Oracle 數(shù)據(jù)庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。
難點：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構。
數(shù)據(jù)源改造而服務平臺不需要大面積重構。
NoSQL和MySQL的區(qū)別大嗎？
即非關系型數(shù)據(jù)庫和關系型數(shù)據(jù)庫。
MySQL的優(yōu)點：事務處理—保持數(shù)據(jù)的一致性；由于以標準化為前提，數(shù)據(jù)更新的開銷很?。ㄏ嗤淖侄位旧现挥幸惶帲豢梢赃M行Join等復雜查詢
NoSQL的優(yōu)點：首先它是基于內(nèi)存的，也就是數(shù)據(jù)放在內(nèi)存中，而不是像數(shù)據(jù)庫那樣把數(shù)據(jù)放在磁盤上，而內(nèi)存的讀取速度是磁盤讀取速度的幾十倍到上百倍，所以NoSQL工具的速度遠比數(shù)據(jù)庫讀取速度要快得多，滿足了高響應的要求。即使NoSQL將數(shù)據(jù)放在磁盤中，它也是一種半結構化的數(shù)據(jù) 格式，讀取到解析的復雜度遠比MySQL要簡單，這是因為MySQL存儲的是經(jīng)過結構化、多范式等有復雜規(guī)則的數(shù)據(jù)，還原為內(nèi)存結構的速度較慢。NoSQL在很大程度上滿足了高并發(fā)、快速讀/和響應的要求，所以它也是Java互聯(lián)網(wǎng)系統(tǒng)的利器。
簡單的擴展：典型例子是Cassandra，由于其架構是類似于經(jīng)典的P2P，所以能通過輕松地添加新的節(jié)點來擴展這個集群;
低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫共有的特點，因為主要都是開源軟件，沒有昂貴的License成本;
NoSQL的缺點：大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務，也不像 SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等; 不提供對SQL的支持
那么該如何選擇？
如果規(guī)模和性能比24小時的數(shù)據(jù)一致性更重要，那NoSQL是一個理想的選擇 （NoSQL依賴于BASE模型——基本可用、軟狀態(tài)、最終一致性）。
但如果要保證到“始終一致”，尤其是對于機密信息和財務信息，那么MySQL很可能是最優(yōu)的選擇（MySQL依賴于ACID模型——原子性、一致性、獨立性和耐久性）。
如果關系數(shù)據(jù)庫在你的應用場景中，完全能夠很好的工作，而你又是非常善于使用和維護關系數(shù)據(jù)庫的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。如果你是在金融，電信等以數(shù)據(jù)為王的關鍵領域，目前使用的是Oracle數(shù)據(jù)庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿(mào)然嘗試NoSQL。
然而，在WEB2.0的網(wǎng)站中，關系數(shù)據(jù)庫大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫可擴展上都花費了開發(fā)人員相當多的精力來優(yōu)化，比如做分表分庫（database sharding）、主從復制、異構復制等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場合，那么我覺得你應該嘗試一下NoSQL了。
具體問題具體分析
MySQL體積小、速度快、成本低、結構穩(wěn)定、便于查詢，可以保證數(shù)據(jù)的一致性，但缺乏靈活性。
NoSQL高性能、高擴展、高可用，不用局限于固定的結構，減少了時間和空間上的開銷，卻又很難保證數(shù)據(jù)一致性。
————————————————
版權聲明：本文為CSDN博主「蒟蒻熊」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：
什么是nosql數(shù)據(jù)庫？nosql和rdbms有什么區(qū)別
1 理解ACID與BASE的區(qū)別（ACID是關系型數(shù)據(jù)庫強一致性的四個要求，而BASE是NoSQL數(shù)據(jù)庫通常對可用性及一致性的弱要求原則，它們的意思分別是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸，BASE意思為堿）
2 理解持久化與非持久化的區(qū)別。這么說是因為有的NoSQL系統(tǒng)是純內(nèi)存存儲的。
3 你必須意識到傳統(tǒng)有關系型數(shù)據(jù)庫與NoSQL系統(tǒng)在數(shù)據(jù)結構上的本質區(qū)別。傳統(tǒng)關系型數(shù)據(jù)庫通常是基于行的表格型存儲，而NoSQL系統(tǒng)包括了列式存儲（Cassandra）、key/value存儲（Memcached）、文檔型存儲（CouchDB）以及圖結構存儲（Neo4j）
4與傳統(tǒng)關系數(shù)據(jù)庫有統(tǒng)一的SQL語言操作接口不同，NoSQL系統(tǒng)通常有自己特有的API接口。
5 在架構上，你必須搞清楚，NoSQL系統(tǒng)是被設計用于成百上千臺機器的集群中的，而非共享型數(shù)據(jù)庫系統(tǒng)的架構。
6在NoSQL系統(tǒng)中，可能你得習慣一下不知道你的數(shù)據(jù)具體存在何處的情況。
7 在NoSQL系統(tǒng)中，你最好習慣它的弱一致性。”eventually consistent”(最終一致性)正是BASE原則中的重要一項。比如在Twitter，你在Followers列表中經(jīng)常會感受到數(shù)據(jù)的延遲。
8 在NoSQL系統(tǒng)中，你要理解，很多時候數(shù)據(jù)并不總是可用的。
9 你得理解，有的方案是擁有分區(qū)容忍性的，有的方案不一定有。
當前文章：nosql為什么這么多,為什么要使用nosql
URL標題：http://fisionsoft.com.cn/article/hogcps.html
