具體來說，本文包括以下內(nèi)容:
成都創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元吳川做網(wǎng)站,已為上家服務(wù),為吳川各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220
事務(wù)
查詢性能
用戶和查詢沖突
容量
配置
NoSQL 數(shù)據(jù)庫
事務(wù)
事務(wù)可以觀察真實用戶的行為：能夠在應(yīng)用交互時捕獲實時性能。眾所周知，測量事務(wù)的性能包括獲取整個事務(wù)的響應(yīng)時間和組成事務(wù)的各個部分的響應(yīng)時間。通常我們可以用這些響應(yīng)時間與滿足事務(wù)需求的基線對比，來確定當(dāng)前事務(wù)是否處于正常狀態(tài)。
如果你只想衡量應(yīng)用的某個方面，那么可以評估事務(wù)的行為。所以，盡管容器指標(biāo)能夠提供更豐富的信息，并且?guī)椭銢Q定何時對當(dāng)前環(huán)境進(jìn)行自動測量，但你的事務(wù)就足以確定應(yīng)用性能。無需向應(yīng)用程序服務(wù)器獲取 CPU 的使用情況，你更應(yīng)該關(guān)心用戶是否完成了事務(wù)，以及該事務(wù)是否得到了優(yōu)化。
補(bǔ)充一個小知識點，事務(wù)是由入口點決定的，通過該入口點可以啟動事務(wù)與應(yīng)用進(jìn)行交互。
一旦定義了事務(wù)，會在整個應(yīng)用生態(tài)系統(tǒng)中對其性能進(jìn)行測量，并將每個事務(wù)與基線進(jìn)行比對。例如，我們可能會決定當(dāng)事務(wù)的響應(yīng)時間與基線相比，一旦慢于平均響應(yīng)時間的兩個標(biāo)準(zhǔn)差是否就應(yīng)該判定為異常，如圖1所示。
圖1-基于基線評估當(dāng)前事務(wù)響應(yīng)時間
用于評估事務(wù)的基線與正在進(jìn)行的事務(wù)活動在時間上是一致的，但事務(wù)會由每個事務(wù)執(zhí)行來完善。例如，當(dāng)你選定一個基線，在當(dāng)前事務(wù)結(jié)束之后，將事務(wù)與平均響應(yīng)時間按每天的小時數(shù)和每周的天數(shù)進(jìn)行對比，所有在那段時間內(nèi)執(zhí)行的事務(wù)都將會被納入下周的基線中。通過這種機(jī)制，應(yīng)用程序可以隨時間而變化，而無需每次都重建原始基線；你可以將其看作是一個隨時間移動的窗口。
總之，事務(wù)最能反映用戶體驗的測量方法，所以也是衡量性能狀況最重要的指標(biāo)。
查詢性能?
最容易檢測到查詢性能是否正常的指標(biāo)就是查詢本身。由查詢引起的問題可能會導(dǎo)致時間太長而無法識別所需數(shù)據(jù)或返回數(shù)據(jù)。所以不妨在查詢中排查以下問題。
1. 選擇過多冗余數(shù)據(jù)
編寫查詢語句來返回適當(dāng)?shù)臄?shù)據(jù)是遠(yuǎn)遠(yuǎn)不夠的，很可能你的查詢語句會返回太多列，從而導(dǎo)致選擇行和檢索數(shù)據(jù)變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當(dāng)需要在特定字段中查詢時，該計劃可能會確定一個覆蓋索引從而加快結(jié)果返回。覆蓋索引通常會包含查詢中使用的所有字段。這意味著數(shù)據(jù)庫可以僅從索引中產(chǎn)生結(jié)果，而不需要通過底層表來構(gòu)建。
另外，列出結(jié)果中所需的列不僅可以減少傳輸?shù)臄?shù)據(jù)，還能進(jìn)一步提高性能。
2. 表之間的低效聯(lián)接
聯(lián)接會導(dǎo)致數(shù)據(jù)庫將多組數(shù)據(jù)帶到內(nèi)存中進(jìn)行比較，這會產(chǎn)生多個數(shù)據(jù)庫讀取和大量 CPU。根據(jù)表的索引，聯(lián)接還可能需要掃描兩個表的所有行。如果寫不好兩個大型表之間的聯(lián)接，就需要對每個表進(jìn)行完整掃描，這樣的計算量將會非常大。其他會拖慢聯(lián)接的因素包括聯(lián)接列之間存在不同的數(shù)據(jù)類型、需要轉(zhuǎn)換或加入包含 LIKE 的條件，這樣就會阻止使用索引。另外，還需注意避免使用全外聯(lián)接；在恰當(dāng)?shù)臅r候使用內(nèi)部聯(lián)接只返回所需數(shù)據(jù)。
3. 索引過多或過少
如果查詢優(yōu)化沒有可用的索引時，數(shù)據(jù)庫會重新掃描表來產(chǎn)生查詢結(jié)果，這個過程會生成大量的磁盤輸入/輸出（I/O）。適當(dāng)?shù)乃饕梢詼p少排序結(jié)果的需要。雖然非唯一值的索引在生成結(jié)果時，不能像唯一索引那樣方便。如果鍵越大，索引也會變大，并通過它們創(chuàng)建更多的磁盤 I/O。大多數(shù)索引是為了提高數(shù)據(jù)檢索的性能，但也需要明白索引本身也會影響數(shù)據(jù)的插入和更新，因為所有相關(guān)聯(lián)的指標(biāo)都必須更新。
4. 太多的SQL導(dǎo)致爭用解析資源
任何 SQL 查詢在執(zhí)行之前都必須被解析，在生成執(zhí)行計劃之前需要對語法和權(quán)限進(jìn)行檢查。由于解析非常耗時，數(shù)據(jù)庫會保存已解析的 SQL 來重復(fù)利用，從而減少解析的耗時。因為 WHERE 語句不同，所以使用文本值的查詢語句不能被共享。這將導(dǎo)致每個查詢都會被解析并添加到共享池中，由于池的空間有限，一些已保存的查詢會被舍棄。當(dāng)這些查詢再次出現(xiàn)時，則需要重新解析。
用戶和查詢沖突?
數(shù)據(jù)庫支持多用戶，但多用戶活動也可能造成沖突。
1. 由慢查詢導(dǎo)致的頁/行鎖定
為了確保查詢產(chǎn)生精確的結(jié)果，數(shù)據(jù)庫必須鎖定表以防止在運(yùn)行讀取查詢時再發(fā)生其他的插入和更新行為。如果報告或查詢相當(dāng)緩慢，需要修改值的用戶可能需要等待至更新完成。鎖提示能幫助數(shù)據(jù)庫使用最小破壞性的鎖。從事務(wù)數(shù)據(jù)庫中分離報表也是一種可靠的解決方法。
2. 事務(wù)鎖和死鎖
當(dāng)兩個事務(wù)被阻塞時會出現(xiàn)死鎖，因為每一個都需要使用被另一個占用的資源。當(dāng)出現(xiàn)一個普通鎖時，事務(wù)會被阻塞直到資源被釋放。但卻沒有解決死鎖的方案。數(shù)據(jù)庫會監(jiān)控死鎖并選擇終止其中一個事務(wù)，釋放資源并允許該事務(wù)繼續(xù)進(jìn)行，而另一個事務(wù)則回滾。
3. 批處理操作造成資源爭奪
批處理過程通常會執(zhí)行批量操作，如大量的數(shù)據(jù)加載或生成復(fù)雜的分析報告。這些操作是資源密集型的，但可能影響在線用戶的訪問應(yīng)用的性能。針對此問題最好的解決辦法是確保批處理在系統(tǒng)使用率較低時運(yùn)行，比如晚上，或用單獨的數(shù)據(jù)庫進(jìn)行事務(wù)處理和分析報告。
容量?
并不是所有的數(shù)據(jù)庫性能問題都是數(shù)據(jù)庫問題。有些問題也是硬件不合適造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分擔(dān)服務(wù)器負(fù)載，進(jìn)一步提高性能。數(shù)據(jù)庫的性能不僅是數(shù)據(jù)庫的原因，還受到服務(wù)器上運(yùn)行其他進(jìn)程的影響。因此，對數(shù)據(jù)庫負(fù)載及使用進(jìn)行審查也是必不可少的。由于 CPU 的利用率時時在變，在低使用率、平均使用率和峰值使用率的時間段分別檢查該指標(biāo)可以更好地評估增加額外的 CPU 資源是否有益。
2. IOPS 不足的慢磁盤
磁盤性能通常以每秒輸入/輸出操作（IOPS）來計。結(jié)合 I/O 大小，該指標(biāo)可以衡量每秒的磁盤吞吐量是多少兆。同時，吞吐量也受磁盤的延遲影響，比如需要多久才能完成請求，這些指標(biāo)主要是針對磁盤存儲技術(shù)而言。傳統(tǒng)的硬盤驅(qū)動器（HDD）有一個旋轉(zhuǎn)磁盤，通常比固態(tài)硬盤（SSD）或閃存更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經(jīng)降了下來，所以在市場上也更具競爭力。
3. 全部或錯誤配置的磁盤
眾所周知，數(shù)據(jù)庫會被大量磁盤訪問，所以不正確配置的磁盤可能帶來嚴(yán)重的性能缺陷。磁盤應(yīng)該適當(dāng)分區(qū)，將系統(tǒng)數(shù)據(jù)目錄和用戶數(shù)據(jù)日志分開。高度活躍的表應(yīng)該區(qū)分以避免爭用，通過在不同磁盤上存放數(shù)據(jù)庫和索引增加并行放置，但不要將操作系統(tǒng)和數(shù)據(jù)庫交換空間放置在同一磁盤上。
4. 內(nèi)存不足
有限或不恰當(dāng)?shù)奈锢韮?nèi)存分配會影響數(shù)據(jù)庫性能。通常我們認(rèn)為可用的內(nèi)存更多，性能就越好。監(jiān)控分頁和交換,在多個非繁忙磁盤中建立多頁面空間，進(jìn)一步確保分頁空間分配足夠滿足數(shù)據(jù)庫要求；每個數(shù)據(jù)庫供應(yīng)商也可以在這個問題上提供指導(dǎo)。
5. 網(wǎng)速慢
網(wǎng)絡(luò)速度會影響到如何快速檢索數(shù)據(jù)并返回給終端用戶或調(diào)用過程。使用寬帶連接到遠(yuǎn)程數(shù)據(jù)庫。在某些情況下，選擇 TCP/IP 協(xié)議而不是命名管道可顯著提高數(shù)據(jù)庫性能。
配置
每個數(shù)據(jù)庫都需設(shè)置大量的配置項。通常情況下，默認(rèn)值可能不足以滿足數(shù)據(jù)庫所需的性能。所以，檢查所有的參數(shù)設(shè)置，包括以下問題。
1. 緩沖區(qū)緩存太小
通過將數(shù)據(jù)存儲在內(nèi)核內(nèi)存，緩沖區(qū)緩存可以進(jìn)一步提高性能同時減少磁盤 I/O。當(dāng)緩存太小時，緩存中的數(shù)據(jù)會更頻繁地刷新。如果它再次被請求，就必須從磁盤重讀。除了磁盤讀取緩慢之外，還給 I/O 設(shè)備增添了負(fù)擔(dān)從而成為瓶頸。除了給緩沖區(qū)緩存分配足夠的空間，調(diào)優(yōu) SQL 查詢可以幫助其更有效地利用緩沖區(qū)緩存。
2. 沒有查詢緩存
查詢緩存會存儲數(shù)據(jù)庫查詢和結(jié)果集。當(dāng)執(zhí)行相同的查詢時，數(shù)據(jù)會在緩存中被迅速檢索，而不需要再次執(zhí)行查詢。數(shù)據(jù)會更新失效結(jié)果，所以查詢緩存是唯一有效的靜態(tài)數(shù)據(jù)。但在某些情況下，查詢緩存卻可能成為性能瓶頸。比如當(dāng)鎖定為更新時，巨大的緩存可能導(dǎo)致爭用沖突。
3. 磁盤上臨時表創(chuàng)建導(dǎo)致的 I/O 爭用
在執(zhí)行特定的查詢操作時，數(shù)據(jù)庫需要創(chuàng)建臨時表，如執(zhí)行一個 GROUP BY 子句。如果可能，在內(nèi)存中創(chuàng)建臨時表。但是，在某些情況下，在內(nèi)存中創(chuàng)建臨時表并不可行，比如當(dāng)數(shù)據(jù)包含 BLOB 或 TEXT 對象時。在這些情況下，會在磁盤上創(chuàng)建臨時表。大量的磁盤 I / O 都需要創(chuàng)建臨時表、填充記錄、從表中選擇所需數(shù)據(jù)并在查詢完成后舍棄。為了避免影響性能，臨時數(shù)據(jù)庫應(yīng)該從主數(shù)據(jù)庫中分離出來。重寫查詢還可以通過創(chuàng)建派生表來減少對臨時表的需求。使用派生表直接從另一個 SELECT 語句的結(jié)果中選擇，允許將數(shù)據(jù)加到內(nèi)存中而不是當(dāng)前磁盤上。
NoSQL 數(shù)據(jù)庫
NoSQL 的優(yōu)勢在于它處理大數(shù)據(jù)的能力非常迅速。但是在實際使用中，也應(yīng)該綜合參考 NoSQL 的缺點，從而決定是否適合你的用例場景。這就是為什么NoSQL通常被理解為 「不僅僅是 SQL」，說明了 NoSQL 并不總是正確的解決方案，也沒必要完全取代 SQL，以下分別列舉出五大主要原因。
1. 挑剔事務(wù)
難以保持 NoSQL 條目的一致性。當(dāng)訪問結(jié)構(gòu)化數(shù)據(jù)時，它并不能完全確保同一時間對不同表的更改都生效。如果某個過程發(fā)生崩潰，表可能會不一致。一致事務(wù)的典型代表是復(fù)式記賬法。相應(yīng)的信貸必須平衡每個借方，反之亦然。如果雙方數(shù)據(jù)不一致則不能輸入。NoSQL 則可能無法保證「收支平衡」。
2. 復(fù)雜數(shù)據(jù)庫
NoSQL 的支持者往往以高效代碼、簡單性和 NoSQL 的速度為傲。當(dāng)數(shù)據(jù)庫任務(wù)很簡單時，所有這些因素都是優(yōu)勢。但當(dāng)數(shù)據(jù)庫變得復(fù)雜，NoSQL 會開始分解。此時，SQL 則比 NoSQL 更好地處理復(fù)雜需求，因為 SQL 已經(jīng)成熟，有符合行業(yè)標(biāo)準(zhǔn)的接口。而每個 NoSQL 設(shè)置都有一個唯一的接口。
3. 一致聯(lián)接
當(dāng)執(zhí)行 SQL 的聯(lián)接時，由于系統(tǒng)必須從不同的表中提取數(shù)據(jù)進(jìn)行鍵對齊，所以有一個巨大的開銷。而 NoSQL 似乎是一個空想，因為缺乏聯(lián)接功能。所有的數(shù)據(jù)都在同一個表的一個地方。當(dāng)檢索數(shù)據(jù)時，它會同時提取所有的鍵值對。問題在于這會創(chuàng)建同一數(shù)據(jù)的多個副本。這些副本也必須更新，而這種情況下，NoSQL 沒有功能來確保更新。
4. Schema設(shè)計的靈活性
由于 NoSQL 不需要 schema，所以在某些情況下也是獨一無二的。在以前的數(shù)據(jù)庫模型中，程序員必須考慮所有需要的列能夠擴(kuò)展，能夠適應(yīng)每行的數(shù)據(jù)條目。在 NoSQL 下，條目可以有多種字符串或者完全沒有。這種靈活性允許程序員迅速增加數(shù)據(jù)。但是，也可能存在問題，比如當(dāng)有多個團(tuán)體在同一項目上工作時，或者新的開發(fā)團(tuán)隊接手一個項目時。開發(fā)人員能夠自由地修改數(shù)據(jù)庫，也可能會不斷實現(xiàn)各種各樣的密鑰對。
5. 資源密集型
NoSQL 數(shù)據(jù)庫通常比關(guān)系數(shù)據(jù)庫更加資源密集。他們需要更多的 CPU 儲備和 RAM 分配。出于這個原因，大多數(shù)共享主機(jī)公司都不提供 NoSQL。你必須注冊一個 VPS 或運(yùn)行自己的專用服務(wù)器。另一方面，SQL 主要是在服務(wù)器上運(yùn)行。初期的工作都很順利，但隨著數(shù)據(jù)庫需求的增加，硬件必須擴(kuò)大。單個大型服務(wù)器比多個小型服務(wù)器昂貴得多，價格呈指數(shù)增長。所以在這種企業(yè)計算場景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的服務(wù)器。
NoSQL，指的是非關(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ù)庫則由于其本身的特點得到了非常迅速的發(fā)展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運(yùn)動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)
據(jù)存儲，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運(yùn)用，這一概念無疑是一種全新的思維的注入。
從這一新興技術(shù)中選擇一款正確的NoSQL數(shù)據(jù)庫是非常具有挑戰(zhàn)性的。比一下網(wǎng)建議在選擇時考慮以下因素：
并發(fā)控制
并
發(fā)控制指的是當(dāng)多個用戶同時更新運(yùn)行時，用于保護(hù)數(shù)據(jù)庫完整性的各種技術(shù)。并發(fā)機(jī)制不正確可能導(dǎo)致臟讀、幻讀和不可重復(fù)讀等此類問題。并發(fā)控制的目的是保
證一個用戶的工作不會對另一個用戶的工作產(chǎn)生不合理的影響。在某些情況下，這些措施保證了當(dāng)用戶和其他用戶一起操作時，所得的結(jié)果和她單獨操作時的結(jié)果是
一樣的。在另一些情況下，這表示用戶的工作按預(yù)定的方式受其他用戶的影響。
封鎖
就是事務(wù)T在對某個數(shù)據(jù)對象（例如表、記錄等）操作之前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務(wù)T就對該數(shù)據(jù)對象有了一定的控制，在事務(wù)T釋放它的鎖之前，其它的事務(wù)不能更新此數(shù)據(jù)對象。
封鎖是一次只允許一個用戶讀取或修改的一種機(jī)制，是實現(xiàn)并發(fā)控制的一個非常重要的技術(shù)。
MVCC
Multi-Version Concurrency Control多版本并發(fā)控制，維持一個數(shù)據(jù)的多個版本使讀寫操作沒有沖突。MVCC優(yōu)化了數(shù)據(jù)庫并發(fā)系統(tǒng)，使系統(tǒng)在有大量并發(fā)用戶時得到最高的性能，并且可以不用關(guān)閉服務(wù)器就直接進(jìn)行熱備份。
ACID
指
數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久
性（Durability）。一個支持事務(wù)（Transaction）的數(shù)據(jù)庫系統(tǒng)，必需要具有這四種特性，否則在事務(wù)過程（Transaction
processing）當(dāng)中無法保證數(shù)據(jù)的正確性，交易過程極可能達(dá)不到交易方的要求。
None
一些系統(tǒng)不提供原子性。
鏡像
數(shù)據(jù)庫鏡像是DBMS根據(jù)DBA的要求，自動把整個數(shù)據(jù)庫或其中的關(guān)鍵數(shù)據(jù)復(fù)制到另一個磁盤上，每當(dāng)主數(shù)據(jù)庫更新時，DBMS會自動把更新后的數(shù)據(jù)復(fù)制過去，即DBMS自動保證鏡像數(shù)據(jù)與主數(shù)據(jù)的一致性。
鏡像分為同步和異步。
數(shù)據(jù)存儲
指的是數(shù)據(jù)的物理特性怎樣被存儲在數(shù)據(jù)庫中。
磁盤 數(shù)據(jù)被存儲在硬盤驅(qū)動器里；
GFS或谷歌文件系統(tǒng)是一個由谷歌開發(fā)的專有的分布式文件系統(tǒng)；
Hadoop是Apache軟件框架，免費(fèi)許可下支持?jǐn)?shù)據(jù)密集型分布式應(yīng)用程序；
RAM隨機(jī)存儲器；
插件 可以添加外部插件；
Amazon S3通過Web服務(wù)接口提供存儲；
BDB：BDB
全稱是 “Berkeley DB”，它是MySQL具有事務(wù)能力的表類型，由Sleepycat
Software開發(fā)。BDB表類型提供了MySQL用戶長久期盼的功能，即事務(wù)控制能力。在任何RDBMS中，事務(wù)控制能力都是一種極其重要和寶貴的功
能。事務(wù)控制能力使得我們能夠確保一組命令確實已經(jīng)全部執(zhí)行成功，或者確保當(dāng)任何一個命令出現(xiàn)錯誤時所有命令的執(zhí)行結(jié)果均被退回。
實現(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ù)庫的一個首要指標(biāo)。
關(guān)鍵字：支持get、put和刪除操作
按列存儲：相對于傳統(tǒng)的按行存儲，數(shù)據(jù)集成容易多了
面向文件系統(tǒng)：存儲像是JSON或XML這樣的結(jié)構(gòu)化文件，很容易就能從面向?qū)ο筌浖蝎@取數(shù)據(jù)。
一、概念
SQL?(Structured?Query?Language)?數(shù)據(jù)庫，指關(guān)系型數(shù)據(jù)庫。主要代表：SQL?Server，Oracle，MySQL(開源)，PostgreSQL(開源)。
NoSQL（Not?Only?SQL）泛指非關(guān)系型數(shù)據(jù)庫。主要代表：MongoDB，Redis，CouchDB。
二、區(qū)別
1、存儲方式
SQL數(shù)據(jù)存在特定結(jié)構(gòu)的表中；而NoSQL則更加靈活和可擴(kuò)展，存儲方式可以省是JSON文檔、哈希表或者其他方式。SQL通常以數(shù)據(jù)庫表形式存儲數(shù)據(jù)。舉個栗子，存?zhèn)€學(xué)生借書數(shù)據(jù)：
而NoSQL存儲方式比較靈活，比如使用類JSON文件存儲上表中熊大的借閱數(shù)據(jù)：
2、表/數(shù)據(jù)集合的數(shù)據(jù)的關(guān)系
在SQL中，必須定義好表和字段結(jié)構(gòu)后才能添加數(shù)據(jù)，例如定義表的主鍵(primary?key)，索引(index),觸發(fā)器(trigger),存儲過程(stored?procedure)等。表結(jié)構(gòu)可以在被定義之后更新，但是如果有比較大的結(jié)構(gòu)變更的話就會變得比較復(fù)雜。在NoSQL中，數(shù)據(jù)可以在任何時候任何地方添加，不需要先定義表。例如下面這段代碼會自動創(chuàng)建一個新的"借閱表"數(shù)據(jù)集合：
NoSQL也可以在數(shù)據(jù)集中建立索引。以MongoDB為例，會自動在數(shù)據(jù)集合創(chuàng)建后創(chuàng)建唯一值_id字段，這樣的話就可以在數(shù)據(jù)集創(chuàng)建后增加索引。
從這點來看，NoSQL可能更加適合初始化數(shù)據(jù)還不明確或者未定的項目中。
3、外部數(shù)據(jù)存儲
SQL中如何需要增加外部關(guān)聯(lián)數(shù)據(jù)的話，規(guī)范化做法是在原表中增加一個外鍵，關(guān)聯(lián)外部數(shù)據(jù)表。例如需要在借閱表中增加審核人信息，先建立一個審核人表：
再在原來的借閱人表中增加審核人外鍵：
這樣如果我們需要更新審核人個人信息的時候只需要更新審核人表而不需要對借閱人表做更新。而在NoSQL中除了這種規(guī)范化的外部數(shù)據(jù)表做法以外，我們還能用如下的非規(guī)范化方式把外部數(shù)據(jù)直接放到原數(shù)據(jù)集中，以提高查詢效率。缺點也比較明顯，更新審核人數(shù)據(jù)的時候?qū)容^麻煩。
4、SQL中的JOIN查詢
SQL中可以使用JOIN表鏈接方式將多個關(guān)系數(shù)據(jù)表中的數(shù)據(jù)用一條簡單的查詢語句查詢出來。NoSQL暫未提供類似JOIN的查詢方式對多個數(shù)據(jù)集中的數(shù)據(jù)做查詢。所以大部分NoSQL使用非規(guī)范化的數(shù)據(jù)存儲方式存儲數(shù)據(jù)。
5、數(shù)據(jù)耦合性
SQL中不允許刪除已經(jīng)被使用的外部數(shù)據(jù)，例如審核人表中的"熊三"已經(jīng)被分配給了借閱人熊大，那么在審核人表中將不允許刪除熊三這條數(shù)據(jù)，以保證數(shù)據(jù)完整性。而NoSQL中則沒有這種強(qiáng)耦合的概念，可以隨時刪除任何數(shù)據(jù)。
6、事務(wù)
SQL中如果多張表數(shù)據(jù)需要同批次被更新，即如果其中一張表更新失敗的話其他表也不能更新成功。這種場景可以通過事務(wù)來控制，可以在所有命令完成后再統(tǒng)一提交事務(wù)。而NoSQL中沒有事務(wù)這個概念，每一個數(shù)據(jù)集的操作都是原子級的。
7、增刪改查語法
8、查詢性能
在相同水平的系統(tǒng)設(shè)計的前提下，因為NoSQL中省略了JOIN查詢的消耗，故理論上性能上是優(yōu)于SQL的。
重慶分公司
重慶分公司
