NoSQL-HDFS-基本概念

Hadoop

10年積累的網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有辰溪免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

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

文件存儲在哪里？硬盤

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

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

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

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

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

潛在問題

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

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

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

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

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

實際上，每個數(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端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當(dāng)然也可以借鑒這個思想，數(shù)據(jù)其實只需要寫入到一個datanode上，然后由datanode之間相互進行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當(dāng)然這個設(shè)置會影響到數(shù)據(jù)寫入的吞吐率，我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。

潛在問題

NameNode確實會回放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ā)生單點故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。

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

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

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

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

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

優(yōu)點：

缺點：

大數(shù)據(jù)專業(yè)課程設(shè)置有哪些？

1、大數(shù)據(jù)專業(yè)，一般是指大數(shù)據(jù)采集與管理專業(yè)；

2、課程設(shè)置，大數(shù)據(jù)專業(yè)將從大數(shù)據(jù)應(yīng)用的三個主要層面（即數(shù)據(jù)管理、系統(tǒng)開發(fā)、海量數(shù)據(jù)分析與挖掘）系統(tǒng)地幫助企業(yè)掌握大數(shù)據(jù)應(yīng)用中的各種典型問題的解決辦法，包括實現(xiàn)和分析協(xié)同過濾算法、運行和學(xué)習(xí)分類算法、分布式Hadoop集群的搭建和基準(zhǔn)測試、分布式Hbase集群的搭建和基準(zhǔn)測試、實現(xiàn)一個基于、Mapreduce的并行算法、部署Hive并實現(xiàn)一個的數(shù)據(jù)操作等等，實際提升企業(yè)解決實際問題的能力。

3、核心技術(shù)，

（1）大數(shù)據(jù)與Hadoop生態(tài)系統(tǒng)。詳細介紹分析分布式文件系統(tǒng)HDFS、集群文件系統(tǒng)ClusterFS和NoSQL Database技術(shù)的原理與應(yīng)用；分布式計算框架Mapreduce、分布式數(shù)據(jù)庫HBase、分布式數(shù)據(jù)倉庫Hive。

（2）關(guān)系型數(shù)據(jù)庫技術(shù)。詳細介紹關(guān)系型數(shù)據(jù)庫的原理，掌握典型企業(yè)級數(shù)據(jù)庫的構(gòu)建、管理、開發(fā)及應(yīng)用。

（3）分布式數(shù)據(jù)處理。詳細介紹分析Map/Reduce計算模型和Hadoop Map/Reduce技術(shù)的原理與應(yīng)用。

（4）海量數(shù)據(jù)分析與數(shù)據(jù)挖掘。詳細介紹數(shù)據(jù)挖掘技術(shù)、數(shù)據(jù)挖掘算法–Minhash, Jaccard and Cosine similarity，TF-IDF數(shù)據(jù)挖掘算法–聚類算法；以及數(shù)據(jù)挖掘技術(shù)在行業(yè)中的具體應(yīng)用。

（5）物聯(lián)網(wǎng)與大數(shù)據(jù)。詳細介紹物聯(lián)網(wǎng)中的大數(shù)據(jù)應(yīng)用、遙感圖像的自動解譯、時間序列數(shù)據(jù)的查詢、分析和挖掘。

（6）文件系統(tǒng)（HDFS）。詳細介紹HDFS部署，基于HDFS的高性能提供高吞吐量的數(shù)據(jù)訪問。

（7）NoSQL。詳細介紹NoSQL非關(guān)系型數(shù)據(jù)庫系統(tǒng)的原理、架構(gòu)及典型應(yīng)用。

4、行業(yè)現(xiàn)狀，

今天，越來越多的行業(yè)對大數(shù)據(jù)應(yīng)用持樂觀的態(tài)度，大數(shù)據(jù)或者相關(guān)數(shù)據(jù)分析解決方案的使用在互聯(lián)網(wǎng)行業(yè)，比如百度、騰訊、淘寶、新浪等公司已經(jīng)成為標(biāo)準(zhǔn)。而像電信、金融、能源這些傳統(tǒng)行業(yè)，越來越多的用戶開始嘗試或者考慮怎么樣使用大數(shù)據(jù)解決方案，來提升自己的業(yè)務(wù)水平。

在“大數(shù)據(jù)”背景之下，精通“大數(shù)據(jù)”的專業(yè)人才將成為企業(yè)最重要的業(yè)務(wù)角色，“大數(shù)據(jù)”從業(yè)人員薪酬持續(xù)增長，人才缺口巨大。

衡量數(shù)據(jù)庫性能的重要指標(biāo)

具體來說，本文包括以下內(nèi)容:

事務(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)境進行自動測量，但你的事務(wù)就足以確定應(yīng)用性能。無需向應(yīng)用程序服務(wù)器獲取 CPU 的使用情況，你更應(yīng)該關(guān)心用戶是否完成了事務(wù)，以及該事務(wù)是否得到了優(yōu)化。

補充一個小知識點，事務(wù)是由入口點決定的，通過該入口點可以啟動事務(wù)與應(yīng)用進行交互。

一旦定義了事務(wù)，會在整個應(yīng)用生態(tài)系統(tǒng)中對其性能進行測量，并將每個事務(wù)與基線進行比對。例如，我們可能會決定當(dāng)事務(wù)的響應(yīng)時間與基線相比，一旦慢于平均響應(yīng)時間的兩個標(biāo)準(zhǔn)差是否就應(yīng)該判定為異常，如圖1所示。

圖1-基于基線評估當(dāng)前事務(wù)響應(yīng)時間

用于評估事務(wù)的基線與正在進行的事務(wù)活動在時間上是一致的，但事務(wù)會由每個事務(wù)執(zhí)行來完善。例如，當(dāng)你選定一個基線，在當(dāng)前事務(wù)結(jié)束之后，將事務(wù)與平均響應(yīng)時間按每天的小時數(shù)和每周的天數(shù)進行對比，所有在那段時間內(nèi)執(zhí)行的事務(wù)都將會被納入下周的基線中。通過這種機制，應(yīng)用程序可以隨時間而變化，而無需每次都重建原始基線；你可以將其看作是一個隨時間移動的窗口。

總之，事務(wù)最能反映用戶體驗的測量方法，所以也是衡量性能狀況最重要的指標(biāo)。

查詢性能?

最容易檢測到查詢性能是否正常的指標(biāo)就是查詢本身。由查詢引起的問題可能會導(dǎo)致時間太長而無法識別所需數(shù)據(jù)或返回數(shù)據(jù)。所以不妨在查詢中排查以下問題。

1. 選擇過多冗余數(shù)據(jù)

編寫查詢語句來返回適當(dāng)?shù)臄?shù)據(jù)是遠遠不夠的，很可能你的查詢語句會返回太多列，從而導(dǎo)致選擇行和檢索數(shù)據(jù)變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當(dāng)需要在特定字段中查詢時，該計劃可能會確定一個覆蓋索引從而加快結(jié)果返回。覆蓋索引通常會包含查詢中使用的所有字段。這意味著數(shù)據(jù)庫可以僅從索引中產(chǎn)生結(jié)果，而不需要通過底層表來構(gòu)建。

另外，列出結(jié)果中所需的列不僅可以減少傳輸?shù)臄?shù)據(jù)，還能進一步提高性能。

2. 表之間的低效聯(lián)接

聯(lián)接會導(dǎo)致數(shù)據(jù)庫將多組數(shù)據(jù)帶到內(nèi)存中進行比較，這會產(chǎn)生多個數(shù)據(jù)庫讀取和大量 CPU。根據(jù)表的索引，聯(lián)接還可能需要掃描兩個表的所有行。如果寫不好兩個大型表之間的聯(liá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)限進行檢查。由于解析非常耗時，數(shù)據(jù)庫會保存已解析的 SQL 來重復(fù)利用，從而減少解析的耗時。因為 WHERE 語句不同，所以使用文本值的查詢語句不能被共享。這將導(dǎo)致每個查詢都會被解析并添加到共享池中，由于池的空間有限，一些已保存的查詢會被舍棄。當(dāng)這些查詢再次出現(xiàn)時，則需要重新解析。

用戶和查詢沖突?

數(shù)據(jù)庫支持多用戶，但多用戶活動也可能造成沖突。

1. 由慢查詢導(dǎo)致的頁/行鎖定

為了確保查詢產(chǎn)生精確的結(jié)果，數(shù)據(jù)庫必須鎖定表以防止在運行讀取查詢時再發(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ù)進行，而另一個事務(wù)則回滾。

3. 批處理操作造成資源爭奪

批處理過程通常會執(zhí)行批量操作，如大量的數(shù)據(jù)加載或生成復(fù)雜的分析報告。這些操作是資源密集型的，但可能影響在線用戶的訪問應(yīng)用的性能。針對此問題最好的解決辦法是確保批處理在系統(tǒng)使用率較低時運行，比如晚上，或用單獨的數(shù)據(jù)庫進行事務(wù)處理和分析報告。

容量?

并不是所有的數(shù)據(jù)庫性能問題都是數(shù)據(jù)庫問題。有些問題也是硬件不合適造成的。

1. CPU 不足或 CPU 速度太慢

更多 CPU 可以分擔(dān)服務(wù)器負載，進一步提高性能。數(shù)據(jù)庫的性能不僅是數(shù)據(jù)庫的原因，還受到服務(wù)器上運行其他進程的影響。因此，對數(shù)據(jù)庫負載及使用進行審查也是必不可少的。由于 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ù)庫性能。通常我們認為可用的內(nèi)存更多，性能就越好。監(jiān)控分頁和交換,在多個非繁忙磁盤中建立多頁面空間，進一步確保分頁空間分配足夠滿足數(shù)據(jù)庫要求；每個數(shù)據(jù)庫供應(yīng)商也可以在這個問題上提供指導(dǎo)。

5. 網(wǎng)速慢

網(wǎng)絡(luò)速度會影響到如何快速檢索數(shù)據(jù)并返回給終端用戶或調(diào)用過程。使用寬帶連接到遠程數(shù)據(jù)庫。在某些情況下，選擇 TCP/IP 協(xié)議而不是命名管道可顯著提高數(shù)據(jù)庫性能。

配置

每個數(shù)據(jù)庫都需設(shè)置大量的配置項。通常情況下，默認值可能不足以滿足數(shù)據(jù)庫所需的性能。所以，檢查所有的參數(shù)設(shè)置，包括以下問題。

1. 緩沖區(qū)緩存太小

通過將數(shù)據(jù)存儲在內(nèi)核內(nèi)存，緩沖區(qū)緩存可以進一步提高性能同時減少磁盤 I/O。當(dāng)緩存太小時，緩存中的數(shù)據(jù)會更頻繁地刷新。如果它再次被請求，就必須從磁盤重讀。除了磁盤讀取緩慢之外，還給 I/O 設(shè)備增添了負擔(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ù)進行鍵對齊，所以有一個巨大的開銷。而 NoSQL 似乎是一個空想，因為缺乏聯(lián)接功能。所有的數(shù)據(jù)都在同一個表的一個地方。當(dāng)檢索數(shù)據(jù)時，它會同時提取所有的鍵值對。問題在于這會創(chuàng)建同一數(shù)據(jù)的多個副本。這些副本也必須更新，而這種情況下，NoSQL 沒有功能來確保更新。

4. Schema設(shè)計的靈活性

由于 NoSQL 不需要 schema，所以在某些情況下也是獨一無二的。在以前的數(shù)據(jù)庫模型中，程序員必須考慮所有需要的列能夠擴展，能夠適應(yīng)每行的數(shù)據(jù)條目。在 NoSQL 下，條目可以有多種字符串或者完全沒有。這種靈活性允許程序員迅速增加數(shù)據(jù)。但是，也可能存在問題，比如當(dāng)有多個團體在同一項目上工作時，或者新的開發(fā)團隊接手一個項目時。開發(fā)人員能夠自由地修改數(shù)據(jù)庫，也可能會不斷實現(xiàn)各種各樣的密鑰對。

5. 資源密集型

NoSQL 數(shù)據(jù)庫通常比關(guān)系數(shù)據(jù)庫更加資源密集。他們需要更多的 CPU 儲備和 RAM 分配。出于這個原因，大多數(shù)共享主機公司都不提供 NoSQL。你必須注冊一個 VPS 或運行自己的專用服務(wù)器。另一方面，SQL 主要是在服務(wù)器上運行。初期的工作都很順利，但隨著數(shù)據(jù)庫需求的增加，硬件必須擴大。單個大型服務(wù)器比多個小型服務(wù)器昂貴得多，價格呈指數(shù)增長。所以在這種企業(yè)計算場景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的服務(wù)器。

網(wǎng)頁名稱：nosql設(shè)置,nosql的定義
本文地址：http://chinadenli.net/article40/dsieseo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、網(wǎng)站排名、建站公司、品牌網(wǎng)站制作、企業(yè)建站、外貿(mào)建站

廣告

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