資料庫減少副本演算法

1. 分布式存儲中，怎樣使用paxos演算法保證數據的一致性

在分布式系統中，我們經常遇到多數據副本保持一致的問題，在我們所能找到的資料中該問題講的很籠統，模模糊糊的，把多個問題或分類糅合在一起，難以理解。在思考和翻閱資料後，通俗地把一致性的問題可分解為2個問題：
1、任何一次修改保證數據一致性。
2、多次數據修改的一致性。
在弱一致性的演算法，不要求每次修改的內容在修改後多副本的內容是一致的，對問題1的解決比較寬松，更多解決問題2，該類演算法追求每次修改的高度並發性，減少多副本之間修改的關聯性，以獲得更好的並發性能。例如最終一致性，無所謂每次用戶修改後的多副本的一致性及格過，只要求在單調的時間方向上，數據最終保持一致，如此獲得了修改極大的並發性能。
在強一致性的演算法中，強調單次修改後結果的一致，需要保證了對問題1和問題2要求的實現，犧牲了並發性能。本文是討論對解決問題1實現演算法，這些演算法往往在強一致性要求的應用中使用。
解決問題1的方法，通常有兩階段提交演算法、採用分布式鎖服務和採用樂觀鎖原理實現的同步方式,下面分別介紹這幾種演算法的實現原理。

兩階段提交演算法

在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。兩階段提交協議由兩個階段組成，在正常的執行下，這兩個階段的執行過程如下所述：
階段1：請求階段（commit-request phase，或稱表決階段，voting phase）。
在請求階段，協調者將通知事務參與者准備提交或取消事務，然後進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
階段2：提交階段（commit phase）。
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的消息後將執行響應的操作。
舉個例子：A組織B、C和D三個人去爬長城：如果所有人都同意去爬長城，那麼活動將舉行；如果有一人不同意去爬長城，那麼活動將取消。用2PC演算法解決該問題的過程如下：
首先A將成為該活動的協調者，B、C和D將成為該活動的參與者。
階段1：A發郵件給B、C和D，提出下周三去爬山，問是否同意。那麼此時A需要等待B、C和D的郵件。B、C和D分別查看自己的日程安排表。B、C發現自己在當日沒有活動安排，則發郵件告訴A它們同意下周三去爬長城。由於某種原因，D白天沒有查看郵件。那麼此時A、B和C均需要等待。到晚上的時候，D發現了A的郵件，然後查看日程安排，發現周三當天已經有別的安排，那麼D回復A說活動取消吧。
階段2：此時A收到了所有活動參與者的郵件，並且A發現D下周三不能去爬山。那麼A將發郵件通知B、C和D，下周三爬長城活動取消。此時B、C回復A「太可惜了」，D回復A「不好意思」。至此該事務終止。
兩階段提交演算法在分布式系統結合，可實現單用戶對文件（對象）多個副本的修改，多副本數據的同步。其結合的原理如下：
1、客戶端（協調者）向所有的數據副本的存儲主機（參與者）發送：修改具體的文件名、偏移量、數據和長度信息，請求修改數據，該消息是1階段的請求消息。
2、存儲主機接收到請求後，備份修改前的數據以備回滾，修改文件數據後，向客戶端回應修改成功的消息。 如果存儲主機由於某些原因（磁碟損壞、空間不足等）不能修改數據，回應修改失敗的消息。
3、客戶端接收發送出去的每一個消息回應，如果存儲主機全部回應都修改成功，向每存儲主機發送確認修改的提交消息；如果存在存儲主機回應修改失敗，或者超時未回應，客戶端向所有存儲主機發送取消修改的提交消息。該消息是2階段的提交消息。
4、存儲主機接收到客戶端的提交消息，如果是確認修改，則直接回應該提交OK消息；如果是取消修改，則將修改數據還原為修改前，然後回應取消修改OK的消息。
5、 客戶端接收全部存儲主機的回應，整個操作成功。
在該過程中可能存在通信失敗，例如網路中斷、主機宕機等諸多的原因，對於未在演算法中定義的其它異常，都認為是提交失敗，都需要回滾，這是該演算法基於確定的通信回復實現的，在參與者的確定回復（無論是回復失敗還是回復成功）之上執行邏輯處理，符合確定性的條件當然能夠獲得確定性的結果哲學原理。

分布式鎖服務

分布式鎖是對數據被外界修改持保守態度，在整個數據處理過程中將數據處於鎖定狀態，在用戶修改數據的同時，其它用戶不允許修改。
採用分布式鎖服務實現數據一致性，是在操作目標之前先獲取操作許可，然後再執行操作，如果其他用戶同時嘗試操作該目標將被阻止，直到前一個用戶釋放許可後，其他用戶才能夠操作目標。分析這個過程，如果只有一個用戶操作目標，沒有多個用戶並發沖突，也申請了操作許可，造成了由於申請操作許可所帶來的資源使用消耗，浪費網路通信和增加了延時。
採用分布式鎖實現多副本內容修改的一致性問題， 選擇控制內容顆粒度實現申請鎖服務。例如我們要保證一個文件的多個副本修改一致， 可以對整個文件修改設置一把鎖，修改時申請鎖，修改這個文件的多個副本，確保多個副本修改的一致，修改完成後釋放鎖；也可以對文件分段，或者是文件中的單個位元組設置鎖， 實現更細顆粒度的鎖操作，減少沖突。
常用的鎖實現演算法有Lamport bakery algorithm （俗稱麵包店演算法）， 還有Paxos演算法。下面對其原理做簡單概述。

Lamport麵包店演算法

是解決多個線程並發訪問一個共享的單用戶資源的互斥問題的演算法。 由Leslie Lamport（英語：Leslie Lamport）發明。
Lamport把這個並發控制演算法可以非常直觀地類比為顧客去麵包店采購。麵包店只能接待一位顧客的采購。已知有n位顧客要進入麵包店采購，安排他們按照次序在前台登記一個簽到號碼。該簽到號碼逐次加1。根據簽到號碼的由小到大的順序依次入店購貨。完成購買的顧客在前台把其簽到號碼歸0. 如果完成購買的顧客要再次進店購買，就必須重新排隊。
這個類比中的顧客就相當於線程，而入店購貨就是進入臨界區獨占訪問該共享資源。由於計算機實現的特點，存在兩個線程獲得相同的簽到號碼的情況，這是因為兩個線程幾乎同時申請排隊的簽到號碼，讀取已經發出去的簽到號碼情況，這兩個線程讀到的數據是完全一樣的，然後各自在讀到的數據上找到最大值，再加1作為自己的排隊簽到號碼。為此，該演算法規定如果兩個線程的排隊簽到號碼相等，則線程id號較小的具有優先權。
把該演算法原理與分布式系統相結合，即可實現分步鎖。

Paxos演算法

該演算法比較熱門，參見WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos演算法解決的問題是一個分布式系統如何就某個值(決議)達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。節點通信存在兩種模型：共享內存(Shared memory)和消息傳遞(Messages passing)。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。BigTable使用一個分布式數據鎖服務Chubby，而Chubby使用Paxos演算法來保證備份的一致性。

採用樂觀鎖原理實現的同步

我們舉個例子說明該演算法的實現原理。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用前面的分布式鎖服務機制，也就意味著整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個並發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 「version」 欄位來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。
對於上面修改用戶帳戶信息的例子而言，假設資料庫中帳戶信息表中有一個 version 欄位，當前值為 1 ；而當前帳戶余額欄位（ balance ）為 $100 。
操作員 A 此時將其讀出（version=1 ），並從其帳戶余額中扣除 $50（$100-$50 ）。
在操作員 A 操作的過程中，操作員B也讀入此用戶信息（ version=1 ），並從其帳戶余額中扣除 $20 （ $100-$20 ）。
操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除後余額（ balance=$50 ），提交至資料庫更新，此時由於提交數據版本大於資料庫記錄當前版本，數據被更新，資料庫記錄 version 更新為 2 。
操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交數據（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足 「 提交版本必須大於記錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 B 的提交被駁回。這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
樂觀鎖機制與分布式系統相結合上， 我整理了偽代碼如下：
obj 操作的目標
vlaue 修改的值
atom_update_ver 每個目標上的版本，每次修改該值遞增
set( obj, value)
{
//從每個節點上取出修改前的對象版本
get original_ver = obj.atom_update_ver from each node;
//將值賦到每個節點的obj目標
set obj = value from each node;
//條件修改每個節點的obj版本，目標版本加一
//比較和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功遞歸修改

該演算法未考慮節點下線、失效等問題，在後續我將分析採用樂觀鎖原理實現一致性演算法，解決問題2、節點失效、通信失敗等問題。

2. 分布式資料庫容忍副本故障

在常見的分布式存儲系統中，實現2F+1個副本冗餘，最多能容忍F個副本同時故障。
在分布式存儲中，一般通過冗餘服務、數據來滿足可用性需求。冗餘服務提供的存儲服務斷不斷。主備模式涉及到提供服務的節點進行切換，對外服務可能中斷。雙活與無狀態分布不斷服務。
無論是雲計算、大數據還是互聯網公司的各種應用，其後台基礎設施的主要目標都是構建低成本、高性能、可擴展、易用的分布式存儲系統。

3. 影響資料庫性能的主要因素有哪些

以MySQL為例：

影響資料庫性能的主要因素總結如下：

1、sql查詢速度

2、網卡流量

3、伺服器硬體

4、磁碟IO

以上因素並不是時時刻刻都會影響資料庫性能，而就像木桶效應一樣。如果其中一個因素嚴重影響性能，那麼整個資料庫性能就會嚴重受阻。另外，這些影響因素都是相對的。

例如：當數據量並沒有達到百萬千萬這樣的級別，那麼sql查詢速度也許就不是個重要因素，換句話說，你的sql語句效率適當低下可能並不影響整個效率多少，反之，這種情況，無論如何怎麼優化sql語句，可能都沒有太明顯的效果。

相關內容拓展：

1、SQL查詢速度

風險：效率低下的SQL

2、網卡流量

風險：網卡IO被占滿（100Mb/8=100MB）

方案：

①減少從伺服器的數量。從伺服器都要從主伺服器上復制日誌，所以，從伺服器越多，網路流量越大。

②進行分級緩存。前方大量緩存突然失效會對資料庫造成嚴重的沖擊。

③避免使用「select * 」進行查詢

④分離業務網路和伺服器網路

3、磁碟IO

風險：磁碟IO性能突然下降。

方案：使用更好的磁碟設備解決。

4. 資料庫技術知識數據結構的演算法

資料庫技術知識數據結構的演算法

對於將要參加計算機等級考試的考生來說，計算機等級考試的知識點輔導是非常重要的復習資料。以下是我收集的資料庫技術知識數據結構的演算法，希望大家認真閱讀!

1、數據：數據的基本單位是數據元素。數據元素可由一個或多個數據項組成。數據項是數據的不可分割的最小單位

2、數據結構：數據的邏輯結構、數據的存儲結構、數據的運算

3、主要的數據存儲方式：順序存儲結構(邏輯和物理相鄰，存儲密度大)和鏈式存儲結構

順序存儲結構：

順序存儲計算公式 Li=L0+(i-1)×K 順序結構可以進行隨機存取;插人、刪除運算會引起相應節點的大量移動

鏈式存儲結構：a、指針域可以有多個，可以指向空，比比順序存儲結構的存儲密度小

b、邏輯上相鄰的節點物理上不一定相鄰。 c、插人、刪除等不需要大量移動節點

4、順序表：一般情況下，若長度為n的順序表，在任何位置插入或刪除的概率相等，元素移動的平均次數為n/2(插入)和(n-1)/2(刪除)。

5、鏈表：線性鏈表(單鏈表和雙向鏈表等等)和非線性鏈表

線性鏈表也稱為單鏈表，其每個一節點中只包含一個指針域，雙鏈表中，每個節點中設置有兩個指針域。(注意結點的插入和刪除操作)

6、棧：“後進先出”(LIFO)表。棧的應用：表達式求解、二叉樹對稱序周遊、快速排序演算法、遞歸過程的實現等

7、隊列：“先進先出”線性表。應用：樹的層次遍歷

8、串：由零個或多個字元組成的有限序列。

9、多維數組的順序存儲：

10、稀疏矩陣的存儲：下三角矩陣順序存儲

其他常見的存儲方法還有三元組法和十字鏈表法

11、廣義表：由零個或多個單元素或子表所組成的有限序列。廣義表的元素可以是子表，而子表的元素還可以是子表

12、樹型結構：非線性結構。常用的樹型結構有樹和二叉樹。

二叉樹與樹的區別：二叉樹不是樹的特殊情況，樹和二叉樹之間最主要的區別是：二叉樹的節點的子樹要區分左子樹和右子樹，即使在節點只有一棵子樹的情況下也要明確指出該子樹是左子樹還是右子樹。

13、樹(森林)與二叉樹之間的轉換(要會轉換)

14、二叉樹和樹的周遊(遍歷)

二叉樹的周遊主要有以下3種方式：前序法(NLR)、對稱序法(LNR)、後序法(LRN)

周遊樹和樹林：深度優先和按廣度優先兩種方式進行。深度優先方式又可分為按先根次序和按後根次序周遊

樹與二叉樹周遊之間的對應關系：按先根次序周遊樹正好與按前序法周遊樹對應的二叉樹等同，後根次序周遊樹正好與按對稱序法周遊對應的`二叉樹等同

按廣度優先方式就是層次次序周遊

15、二叉樹的存儲和線索

二叉樹的存儲結構：二叉樹的llink一rlink法存儲表示

線索二叉樹：在有n個節點的二叉樹的且llink - rlink法存儲表示中，必定有n+1個空指針域

16、哈夫曼樹：一類帶權路徑長度最短的樹。樹的帶權路徑長度為樹中所有葉子節點的帶權路徑長度之和WPL。

17、查找：

(1)順序查找：平均查找長度為(n +1 )/2次，時間復雜度為O(n)

(2)二分法查找：線性表節點必須按關鍵碼值排序，且線性表是以順序存儲方式存儲的。查找成功比較次數log2n，查找失敗比較次數log2n+1

(3)分塊查找：先是塊間查找，然後塊內查找。

(4)散列表(哈希表Hash)的存儲和查找：處理沖突的方法：開地址法(線性探測法)、拉鏈法等

負載因子(裝填因子)=表實際存儲的結點個數/表的最大能存儲結點個數(即表長)

二叉排序樹：每個結點左子樹的所有關鍵碼值都小於該結點關鍵碼值，右子樹所有結點關鍵碼值都大於該結點關鍵碼值。對稱周遊二叉排序樹，得到一個有序序列，時間復雜度O(log2n)

B樹和B+樹：M階樹，每個結點至多有M-1個關鍵碼，至少有M/2(取上界)-1個關鍵碼。B樹適合隨機查找，不適合順序查找。B+樹適合順序查找。

18、排序

直接插人排序、希爾排序、直接選擇排序、堆排序、起泡排序、快速排序等排序演算法要了解。

直接選擇排序、希爾排序、快速排序和堆排序是不穩定排序，其他排序為穩定排序

5. 我做了個相似性的演算法，要與資料庫上百萬比對，其他一些網站都用了Hadoop分布式，知網也是這樣的嗎

引言

Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬體(commodity hardware)上的分布式文件系統。它和現有的分布式文件系統有很多共同點。但同時，它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。這個項目的地址是http://hadoop.apache.org/core/。

前提和設計目標

硬體錯誤

硬體錯誤是常態而不是異常。HDFS可能由成百上千的伺服器所構成，每個伺服器上存儲著文件系統的部分數據。我們面對的現實是構成系統的組件數目是巨大的，而且任一組件都有可能失效，這意味著總是有一部分HDFS的組件是不工作的。因此錯誤檢測和快速、自動的恢復是HDFS最核心的架構目標。

流式數據訪問

運行在HDFS上的應用和普通的應用不同，需要流式訪問它們的數據集。HDFS的設計中更多的考慮到了數據批處理，而不是用戶交互處理。比之數據訪問的低延遲問題，更關鍵的在於數據訪問的高吞吐量。POSIX標准設置的很多硬性約束對HDFS應用系統不是必需的。為了提高數據的吞吐量，在一些關鍵方面對POSIX的語義做了一些修改。

大規模數據集

運行在HDFS上的應用具有很大的數據集。HDFS上的一個典型文件大小一般都在G位元組至T位元組。因此，HDFS被調節以支持大文件存儲。它應該能提供整體上高的數據傳輸帶寬，能在一個集群里擴展到數百個節點。一個單一的HDFS實例應該能支撐數以千萬計的文件。

簡單的一致性模型

HDFS應用需要一個「一次寫入多次讀取」的文件訪問模型。一個文件經過創建、寫入和關閉之後就不需要改變。這一假設簡化了數據一致性問題，並且使高吞吐量的數據訪問成為可能。Map/Rece應用或者網路爬蟲應用都非常適合這個模型。目前還有計劃在將來擴充這個模型，使之支持文件的附加寫操作。

「移動計算比移動數據更劃算」

一個應用請求的計算，離它操作的數據越近就越高效，在數據達到海量級別的時候更是如此。因為這樣就能降低網路阻塞的影響，提高系統數據的吞吐量。將計算移動到數據附近，比之將數據移動到應用所在顯然更好。HDFS為應用提供了將它們自己移動到數據附近的介面。

異構軟硬體平台間的可移植性

HDFS在設計的時候就考慮到平台的可移植性。這種特性方便了HDFS作為大規模數據應用平台的推廣。

Namenode 和 Datanode

HDFS採用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心伺服器，負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個，負責管理它所在節點上的存儲。HDFS暴露了文件系統的名字空間，用戶能夠以文件的形式在上面存儲數據。從內部看，一個文件其實被分成一個或多個數據塊，這些塊存儲在一組Datanode上。Namenode執行文件系統的名字空間操作，比如打開、關閉、重命名文件或目錄。它也負責確定數據塊到具體Datanode節點的映射。Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。

Namenode和Datanode被設計成可以在普通的商用機器上運行。這些機器一般運行著GNU/Linux操作系統(OS)。HDFS採用Java語言開發，因此任何支持Java的機器都可以部署Namenode或Datanode。由於採用了可移植性極強的Java語言，使得HDFS可以部署到多種類型的機器上。一個典型的部署場景是一台機器上只運行一個Namenode實例，而集群中的其它機器分別運行一個Datanode實例。這種架構並不排斥在一台機器上運行多個Datanode，只不過這樣的情況比較少見。

集群中單一Namenode的結構大大簡化了系統的架構。Namenode是所有HDFS元數據的仲裁者和管理者，這樣，用戶數據永遠不會流過Namenode。

文件系統的名字空間 (namespace)

HDFS支持傳統的層次型文件組織結構。用戶或者應用程序可以創建目錄，然後將文件保存在這些目錄里。文件系統名字空間的層次結構和大多數現有的文件系統類似：用戶可以創建、刪除、移動或重命名文件。當前，HDFS不支持用戶磁碟配額和訪問許可權控制，也不支持硬鏈接和軟鏈接。但是HDFS架構並不妨礙實現這些特性。

Namenode負責維護文件系統的名字空間，任何對文件系統名字空間或屬性的修改都將被Namenode記錄下來。應用程序可以設置HDFS保存的文件的副本數目。文件副本的數目稱為文件的副本系數，這個信息也是由Namenode保存的。

數據復制

HDFS被設計成能夠在一個大集群中跨機器可靠地存儲超大文件。它將每個文件存儲成一系列的數據塊，除了最後一個，所有的數據塊都是同樣大小的。為了容錯，文件的所有數據塊都會有副本。每個文件的數據塊大小和副本系數都是可配置的。應用程序可以指定某個文件的副本數目。副本系數可以在文件創建的時候指定，也可以在之後改變。HDFS中的文件都是一次性寫入的，並且嚴格要求在任何時候只能有一個寫入者。

Namenode全權管理數據塊的復制，它周期性地從集群中的每個Datanode接收心跳信號和塊狀態報告(Blockreport)。接收到心跳信號意味著該Datanode節點工作正常。塊狀態報告包含了一個該Datanode上所有數據塊的列表。

副本存放: 最最開始的一步

副本的存放是HDFS可靠性和性能的關鍵。優化的副本存放策略是HDFS區分於其他大部分分布式文件系統的重要特性。這種特性需要做大量的調優，並需要經驗的積累。HDFS採用一種稱為機架感知(rack-aware)的策略來改進數據的可靠性、可用性和網路帶寬的利用率。目前實現的副本存放策略只是在這個方向上的第一步。實現這個策略的短期目標是驗證它在生產環境下的有效性，觀察它的行為，為實現更先進的策略打下測試和研究的基礎。

大型HDFS實例一般運行在跨越多個機架的計算機組成的集群上，不同機架上的兩台機器之間的通訊需要經過交換機。在大多數情況下，同一個機架內的兩台機器間的帶寬會比不同機架的兩台機器間的帶寬大。

通過一個機架感知的過程，Namenode可以確定每個Datanode所屬的機架id。一個簡單但沒有優化的策略就是將副本存放在不同的機架上。這樣可以有效防止當整個機架失效時數據的丟失，並且允許讀數據的時候充分利用多個機架的帶寬。這種策略設置可以將副本均勻分布在集群中，有利於當組件失效情況下的負載均衡。但是，因為這種策略的一個寫操作需要傳輸數據塊到多個機架，這增加了寫的代價。

在大多數情況下，副本系數是3，HDFS的存放策略是將一個副本存放在本地機架的節點上，一個副本放在同一機架的另一個節點上，最後一個副本放在不同機架的節點上。這種策略減少了機架間的數據傳輸，這就提高了寫操作的效率。機架的錯誤遠遠比節點的錯誤少，所以這個策略不會影響到數據的可靠性和可用性。於此同時，因為數據塊只放在兩個（不是三個）不同的機架上，所以此策略減少了讀取數據時需要的網路傳輸總帶寬。在這種策略下，副本並不是均勻分布在不同的機架上。三分之一的副本在一個節點上，三分之二的副本在一個機架上，其他副本均勻分布在剩下的機架中，這一策略在不損害數據可靠性和讀取性能的情況下改進了寫的性能。

當前，這里介紹的默認副本存放策略正在開發的過程中。

副本選擇

為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那麼就讀取該副本。如果一個HDFS集群跨越多個數據中心，那麼客戶端也將首先讀本地數據中心的副本。

安全模式

Namenode啟動後會進入一個稱為安全模式的特殊狀態。處於安全模式的Namenode是不會進行數據塊的復制的。Namenode從所有的 Datanode接收心跳信號和塊狀態報告。塊狀態報告包括了某個Datanode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當Namenode檢測確認某個數據塊的副本數目達到這個最小值，那麼該數據塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個參數可配置）的數據塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，並將這些數據塊復制到其他Datanode上。

文件系統元數據的持久化

Namenode上保存著HDFS的名字空間。對於任何對文件系統元數據產生修改的操作，Namenode都會使用一種稱為EditLog的事務日誌記錄下來。例如，在HDFS中創建一個文件，Namenode就會在Editlog中插入一條記錄來表示；同樣地，修改文件的副本系數也將往Editlog插入一條記錄。Namenode在本地操作系統的文件系統中存儲這個Editlog。整個文件系統的名字空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱為FsImage的文件中，這個文件也是放在Namenode所在的本地文件系統上。

Namenode在內存中保存著整個文件系統的名字空間和文件數據塊映射(Blockmap)的映像。這個關鍵的元數據結構設計得很緊湊，因而一個有4G內存的Namenode足夠支撐大量的文件和目錄。當Namenode啟動時，它從硬碟中讀取Editlog和FsImage，將所有Editlog中的事務作用在內存中的FsImage上，並將這個新版本的FsImage從內存中保存到本地磁碟上，然後刪除舊的Editlog，因為這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。在當前實現中，檢查點只發生在Namenode啟動時，在不久的將來將實現支持周期性的檢查點。

Datanode將HDFS數據以文件的形式存儲在本地的文件系統中，它並不知道有關HDFS文件的信息。它把每個HDFS數據塊存儲在本地文件系統的一個單獨的文件中。Datanode並不在同一個目錄創建所有的文件，實際上，它用試探的方法來確定每個目錄的最佳文件數目，並且在適當的時候創建子目錄。在同一個目錄中創建所有的本地文件並不是最優的選擇，這是因為本地文件系統可能無法高效地在單個目錄中支持大量的文件。當一個Datanode啟動時，它會掃描本地文件系統，產生一個這些本地文件對應的所有HDFS數據塊的列表，然後作為報告發送到Namenode，這個報告就是塊狀態報告。

通訊協議

所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端通過一個可配置的TCP埠連接到Namenode，通過ClientProtocol協議與Namenode交互。而Datanode使用DatanodeProtocol協議與Namenode交互。一個遠程過程調用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，Namenode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求。

健壯性

HDFS的主要目標就是即使在出錯的情況下也要保證數據存儲的可靠性。常見的三種出錯情況是：Namenode出錯, Datanode出錯和網路割裂(network partitions)。

磁碟數據錯誤，心跳檢測和重新復制

每個Datanode節點周期性地向Namenode發送心跳信號。網路割裂可能導致一部分Datanode跟Namenode失去聯系。Namenode通過心跳信號的缺失來檢測這一情況，並將這些近期不再發送心跳信號Datanode標記為宕機，不會再將新的IO請求發給它們。任何存儲在宕機Datanode上的數據將不再有效。Datanode的宕機可能會引起一些數據塊的副本系數低於指定值，Namenode不斷地檢測這些需要復制的數據塊，一旦發現就啟動復制操作。在下列情況下，可能需要重新復制：某個Datanode節點失效，某個副本遭到損壞，Datanode上的硬碟錯誤，或者文件的副本系數增大。

集群均衡

HDFS的架構支持數據均衡策略。如果某個Datanode節點上的空閑空間低於特定的臨界點，按照均衡策略系統就會自動地將數據從這個Datanode移動到其他空閑的Datanode。當對某個文件的請求突然增加，那麼也可能啟動一個計劃創建該文件新的副本，並且同時重新平衡集群中的其他數據。這些均衡策略目前還沒有實現。

數據完整性

從某個Datanode獲取的數據塊有可能是損壞的，損壞可能是由Datanode的存儲設備錯誤、網路錯誤或者軟體bug造成的。HDFS客戶端軟體實現了對HDFS文件內容的校驗和(checksum)檢查。當客戶端創建一個新的HDFS文件，會計算這個文件每個數據塊的校驗和，並將校驗和作為一個單獨的隱藏文件保存在同一個HDFS名字空間下。當客戶端獲取文件內容後，它會檢驗從Datanode獲取的數據跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數據塊的副本。

元數據磁碟錯誤

FsImage和Editlog是HDFS的核心數據結構。如果這些文件損壞了，整個HDFS實例都將失效。因而，Namenode可以配置成支持維護多個FsImage和Editlog的副本。任何對FsImage或者Editlog的修改，都將同步到它們的副本上。這種多副本的同步操作可能會降低Namenode每秒處理的名字空間事務數量。然而這個代價是可以接受的，因為即使HDFS的應用是數據密集的，它們也非元數據密集的。當Namenode重啟的時候，它會選取最近的完整的FsImage和Editlog來使用。

Namenode是HDFS集群中的單點故障(single point of failure)所在。如果Namenode機器故障，是需要手工干預的。目前，自動重啟或在另一台機器上做Namenode故障轉移的功能還沒實現。

快照

快照支持某一特定時刻的數據的復制備份。利用快照，可以讓HDFS在數據損壞時恢復到過去一個已知正確的時間點。HDFS目前還不支持快照功能，但計劃在將來的版本進行支持。

數據組織

數據塊

HDFS被設計成支持大文件，適用HDFS的是那些需要處理大規模的數據集的應用。這些應用都是只寫入數據一次，但卻讀取一次或多次，並且讀取速度應能滿足流式讀取的需要。HDFS支持文件的「一次寫入多次讀取」語義。一個典型的數據塊大小是64MB。因而，HDFS中的文件總是按照64M被切分成不同的塊，每個塊盡可能地存儲於不同的Datanode中。

Staging

客戶端創建文件的請求其實並沒有立即發送給Namenode，事實上，在剛開始階段HDFS客戶端會先將文件數據緩存到本地的一個臨時文件。應用程序的寫操作被透明地重定向到這個臨時文件。當這個臨時文件累積的數據量超過一個數據塊的大小，客戶端才會聯系Namenode。Namenode將文件名插入文件系統的層次結構中，並且分配一個數據塊給它。然後返回Datanode的標識符和目標數據塊給客戶端。接著客戶端將這塊數據從本地臨時文件上傳到指定的Datanode上。當文件關閉時，在臨時文件中剩餘的沒有上傳的數據也會傳輸到指定的Datanode上。然後客戶端告訴Namenode文件已經關閉。此時Namenode才將文件創建操作提交到日誌里進行存儲。如果Namenode在文件關閉前宕機了，則該文件將丟失。

上述方法是對在HDFS上運行的目標應用進行認真考慮後得到的結果。這些應用需要進行文件的流式寫入。如果不採用客戶端緩存，由於網路速度和網路堵塞會對吞估量造成比較大的影響。這種方法並不是沒有先例的，早期的文件系統，比如AFS，就用客戶端緩存來提高性能。為了達到更高的數據上傳效率，已經放鬆了POSIX標準的要求。

流水線復制

6. 如何通過 Nutanix 資料庫管理避免不必要的資料庫開支

可從Forrester Consulting 采訪報告中可以看出，大多數選擇Nutanix資料庫管理Era的客戶一是看中了它在功能、降低成本和低風險方面的好處；二是Nutanix資料庫管理基於超融合基礎架構，使用可擴展的節點結構來滿足組織需求，同時還可以避免高昂的前期基礎架構成本，雖然部署於本地，但可以點來類雲的使用體驗，可以用於管理不同類型的資料庫大大的好。
具體是通過這些避免不必要的資料庫開支的：
加快資料庫置備速度；
將副本和備份存儲需求減少 60%；
更簡單的資料庫管理可將資料庫管理員的加班時間減少多達 50%；
降低與管理工具集和許可相關的成本；
自動化的資料庫修補和管理，避免了每小時超過 35,000 美元的損失。

7. 數據冗餘由什麼引起

數據冗餘由什麼引起?
資料庫中數據冗餘會產生什麼問題？？如果表空間占滿，會有插入，更新操作失敗的問題發生。
數據冗餘是什麼意思啊?大概一點....數據冗餘:在一個數據集合中重復的數據稱為數據冗餘.數據冗餘技術是使用一組或多組附加驅動器存儲數據的副本,這就叫數據冗餘技術。比如鏡像就是一種數據冗餘技術。數據冗餘技術。工控軟體開發中，冗餘技術是一項最為重要的技術，它是系統長期穩定工作的保障。OPC技術的使用可以更加方便的實現軟體冗餘，而且具有較好的開放性和可互操作性。出現這種情況，是因為光碟刻錄時有某些數據記錄不正確，也有可能是光碟與你的光碟機不兼容，或光碟機某處物理損壞讀不過去。循環冗餘檢查(CRC)是一種數據傳輸檢錯功能，對數據進行多項式計，並將得到的結果附在幀的後面，接收設備也執行類似演算法，以保證數據傳輸的正確性和完整性。若CRC校驗不通過，系統重復向硬碟復制數據，陷入死循環，導致復制過程無法完成。
什麼是數據冗餘，數據冗餘會帶來哪些問題？數據冗餘就是指一些不必要的，多餘的內容。最常見的就是在資料庫中，由於數據結構、存儲等方面設計不合理，造成信息重復。
數據冗餘產生哪些問題數據冗餘:在一個數據集合中重復的數據稱為數據冗餘.
數據冗餘的目的：
數據的應用中為了某種目的採取數據冗餘方式。
1、重復存儲或傳輸數據以防止數據的丟失。
2、對數據進行冗餘性的編碼來防止數據的丟失、錯誤，並提供對錯誤數據進行反變換得到原始數據的功能。
3、為簡化流程所造成額數據冗餘。例如向多個目的發送同樣的信息、在多個地點存放同樣的信息，而不對數據進行分析而減少工作量。
4、為加快處理過程而將同一數據在不同地點存放。例如並行處理同一信息的不同內容，或用不同方法處理同一信息等。
5、為方便處理而是同一信息在不同地點有不同的表現形式。例如一本書的不同語言的版本。
6、大量數據的索引。一般在資料庫中經常使用。其目的類似第4點。
7、方法類的信息冗餘：比如每個司機都要記住同一城市的基本交通信息；大量個人電腦都安裝類似的操作系統或軟體。
8、為了完備性而配備的冗餘數據。例如字典里的字很多，但我們只查詢其中很少的一些字。軟體功能很多，但我們只使用其中一部分。
9、規則性的冗餘。根據法律、制度、規則等約束進行的。例如合同中大量的模式化的內容。
10、為達到其他目的所進行的冗餘。例如重復信息以達到被重視等等。
數據冗餘或者信息冗餘是生產、生活所必然存在的行為，沒有好與不好的總體傾向。
而對於自然界，則是物質存在的一種形式，是客觀存在情況。例如每個人都有與其他人基本相同的基因。
數據冗餘是指數據之間的重復，也可以說是同一數據存儲在不同數據文件中的現象。可以說增加數據的獨立性和減少數據冗餘是企業范圍信息資源管理和大規模信息系統獲得成功的前提條件。
以上回答來自網路……
冗餘是什麼意思在資料庫中的數據冗餘大概是這么個意思:數據重復鼎浪費空間.例如:
一個資料庫中有兩個表,一個表中有一欄位存放某個人員的照片,如果在第二個表中再次存放照片就是典型的數據冗餘.
其實我們在描述一個對象的時候,這個對象又很多的屬性.在用資料庫保存這些屬性時,就應該將這些屬性恰當的放到資料庫中的某個具體的表中去.設計好的表,數據冗餘就小.例如描述一個學生的屬性有一些基本星信和成績信息等,這樣就應該將基本信息和成績信息分成兩個表分別存儲,否則當你查看基本信息時,成績信息就是多餘的,影響性能,浪費時間.
什麼是數據冗餘數據冗餘概念簡單說就是多個地方重復存儲相同數據。一般是用在資料庫上。
城市數據團-數據不說謊：大數據之下的世界
數據冗餘的類型有哪些數據的應用中為了某種目的採取數據冗餘方式。
1、重復存儲或傳輸數據以防止數據的丟失。
2、對數據進行冗餘性的編碼來防止數據的丟失、錯誤，並提供對錯誤數據進行反變換得到原始數據的功能。
3、為簡化流程所造成額數據冗餘。例如向多個目的發送同樣的信息、在多個地點存放同樣的信息，而不對數據進行分析而減少工作量。
4、為加快處理過程而將同一數據在不同地點存放。例如並行處理同一信息的不同內容，或用不同方法處理同一信息等。
5、為方便處理而使同一信息在不同地點有不同的表現形式。例如一本書的不同語言的版本。
6、大量數據的索引,一般在資料庫中經常使用。其目的類似第4點。
7、方法類的信息冗餘：比如每個司機都要記住同一城市的基本交通信息；大量個人電腦都安裝類似的操作系統或軟體。
8、為了完備性而配備的冗餘數據。例如字典里的字很多，但我們只查詢其中很少的一些字。軟體功能很多，但我們只使用其中一部分。
9、規則性的冗餘。根據法律、制度、規則等約束進行的。例如合同中大量的模式化的內容。
10、為達到其他目的所進行的冗餘。例如重復信息以達到被重視等等。
什麼是數據冗餘?什麼是數據的完整性?如何來實施數據完整性?數據冗餘是指在兩個或更多文件中重復出現的數據。例如，職工的信息可能同時在人事部文件、銷售部文件和財務部文件中存在。它可能產生的後果有：數據異常、數據不一致性和影響數據的完整性
數據完整性分為以下3類。
（1）域完整性：是指一個列的輸入有效性，是否允許為空值。強制域完整性的方法有：限制類型（通過設定列的數據類型）、格式（通過CHECK約束和規則）或可能值的范圍（通過FOREIGNKEY約束、CHECK約束、DEFAULT定義、NOTNULL定義和規則）。如：學生的考試成績必須在0～100之間，性別只能是「男」或「女」。
（2）實體完整性：是指保證表中所有的行唯一。實體完整性要求表中的所有行都有一個唯一標識符。這個唯一標識符可能是一列，也可能是幾列的組合，稱為主鍵。也就是說，表中的主鍵在所有行上必須取唯一值。強制實體完整性的方法有：索引、UNIQUE約束、PRIMARYKEY約束或IDENTITY屬性。如：student表中sno（學號）的取值必須唯一，它唯一標識了相應記錄所代表的學生，學號重復是非法的。學生的姓名不能作為主鍵，因為完全可能存在兩個學生同名同姓的情況。
（3）參照完整性：是指保證主關鍵字（被引用表）和外部關鍵字（引用表）之間的參照關系。它涉及兩個或兩個以上表數據的一致性維護。外鍵值將引用表中包含此外鍵的記錄和被引用表中主鍵與外鍵相匹配的記錄關聯起來。在輸入、更改或刪除記錄時，參照完整性保持表之間已定義的關系，確保鍵值在所有表中一致。這樣的一致性要求確保不會引用不存在的值，如果鍵值更改了，那麼在整個資料庫中，對該鍵值的所有引用要進行一致的更改。參照完整性是基於外鍵與主鍵之間的關系。例如學生學習課程的課程號必須是有效的課程號，score表（成績表）的外鍵o（課程號）將參考course表（課程表）中主鍵o（課程號）以實現數據完整性。
域完整性、實體完整性及參照完整性分別在列、行、表上實施。數據完整性任何時候都可以實施，但對已有數據的表實施數據完整性時，系統要先檢查表中的數據是否滿足所實施的完整性，只有表中的數據滿足了所實施的完整性，數據完整性才能實施成功。
SQLserver為什麼會存在數據冗餘？這種數據冗餘會導致哪兩類典型的問題？不是sqlserver會存在數據冗餘，所有的資料庫都會存在數撫冗餘，數據冗餘大多是由於建庫的時候表之間的關系沒有充分考慮完全，這涉及到資料庫中範式的概念（目前最高的是NF範式，不過一般的設計符合第三範式就好）。
冗餘會導致：1、存儲空間的浪費。2、數據交互和資料庫訪問執行效率降低。
數據冗餘錯誤的介紹數據冗餘錯誤是一種計算機錯誤。數據冗餘:在一個數據集合中重復的數據稱為數據冗餘.數據冗餘技術是使用一組或多組附加驅動器存儲數據的副本,這就叫數據冗餘技術。比如鏡像就是一種數據冗餘技術。

8. 分布式資料庫的數據分配方式

（1）集中式：所有數據片段都安排在同一個場地上。
（2）分割式：所有數據只有一份，它被分割成若干邏輯片段，每個邏輯片段被指派在一個特定的場地上。
（3）全復制式：數據在每個場地重復存儲。也就是每個場地上都有一個完整的數據副本。
（4）混合式：這是一種介乎於分割式和全復制式之間的分配方式。
目前分布式資料庫分配的設計，越來越多的採用尋找最優解的演算法，比如遺傳演算法、退火機制等

9. 基於資料庫搜索的演算法，關鍵有哪幾點

B+、B- Tree(mysql,oracle,mongodb)
主要用在關系資料庫的索引中，如oracle，mysql innodb；mongodb中的索引也是B-樹實現的；還有HBase中HFile中的DataBlock的索引等等。
動態查找樹主要有：二叉查找樹（Binary Search Tree），平衡二叉查找樹（Balanced Binary Search Tree），紅黑樹(Red-Black Tree )，B-tree/B+-tree/ B*-tree (B~Tree)。前三者是典型的二叉查找樹結構，其查找的時間復雜度O(log2N)與樹的深度相關，那麼降低樹的深度自然會提高查找效率。
但是咱們有面對這樣一個實際問題：就是大規模數據存儲中，實現索引查詢這樣一個實際背景下，樹節點存儲的元素數量是有限的（如果元素數量非常多的話，查找就退化成節點內部的線性查找了），這樣導致二叉查找樹結構由於樹的深度過大而造成磁碟I/O讀寫過於頻繁，進而導致查詢效率低下，那麼如何減少樹的深度（當然是不能減少查詢的數據量），一個基本的想法就是：採用多叉樹結構（由於樹節點元素數量是有限的，自然該節點的子樹數量也就是有限的）。
也就是說，因為磁碟的操作費時費資源，如果過於頻繁的多次查找勢必效率低下。那麼如何提高效率，即如何避免磁碟過於頻繁的多次查找呢？根據磁碟查找存取的次數往往由樹的高度所決定，所以，只要我們通過某種較好的樹結構減少樹的結構盡量減少樹的高度，那麼是不是便能有效減少磁碟查找存取的次數呢？那這種有效的樹結構是一種怎樣的樹呢？
這樣我們就提出了一個新的查找樹結構——多路查找樹。根據平衡二叉樹的啟發，自然就想到平衡多路查找樹結構，也就是B~tree，即B樹結構(後面，我們將看到，B樹的各種操作能使B樹保持較低的高度，從而達到有效避免磁碟過於頻繁的查找存取操作，從而有效提高查找效率)。

Hash表+桶(redis)
mysql中的adaptive hash index，redis中的數據存儲實現都是採用hash，可以高效的進行數據的查詢。
哈希表（Hash table，也叫散列表），是根據關鍵碼值(Key value)而直接進行訪問的數據結構。也就是說，它通過把關鍵碼值映射到表中一個位置來訪問記錄，以加快查找的速度。這個映射函數叫做散列函數，存放記錄的數組叫做散列表。
哈希表的做法其實很簡單，就是把Key通過一個固定的演算法函數既所謂的哈希函數轉換成一個整型數字，然後就將該數字對數組長度進行取余，取余結果就當作數組的下標，將value存儲在以該數字為下標的數組空間里。
而當使用哈希表進行查詢的時候，就是再次使用哈希函數將key轉換為對應的數組下標，並定位到該空間獲取value，如此一來，就可以充分利用到數組的定位性能進行數據定位
數組的特點是：定址容易，插入和刪除困難；而鏈表的特點是：定址困難，插入和刪除容易。綜合兩者特性，設計一種定址容易，插入刪除也容易的數據結構，如拉鏈法實現的哈希表。

Booleam Filter（HBase）
HBase中的rowkey設置建立Booleam Filter映射，用於快速判斷rowkey是否在一個HFile中。在分布式資料庫中用的比較多。
基於BitMap的存儲結構，採用的是哈希函數的方法，將一個元素映射到一個 m 長度的陣列上的一個點，當這個點是 1 時，那麼這個元素在集合內，反之則不在集合內。這個方法的缺點就是當檢測的元素量很多時候可能有沖突，解決方法就是使用 k 個哈希 函數對應 k 個點，如果所有點都是 1 的話，那麼元素在集合內，如果有 0 的話，元素則不再集合內。