大數據時代數據庫面臨重建？

很多大數據應用的實施似乎都是在一個現有的數據倉庫上，添加一個或多個新的大容量數據流，還有一些支持數據存儲和業務分析的專業軟硬件。數據存儲問題通常是通過部署一個專門的硬件一體機來協調，這樣就可以在存儲大量數據的同時還能夠提供超快的數據訪問。

  在這樣的情況下，我們還需要考慮數據庫設計的問題么?

大數據環境下的數據建模

 大多數DBA認為：良好的數據庫設計是系統和應用程序設計的一部分。很多的業務需求，如數據可用性，清理處理，還有應用性能都可以利用特定的數據庫設計加以解決。

 那么對于大數據又如何呢?有趣的是，為大數據業務分析提供軟硬件解決方案的供應商總是宣稱數據庫設計并不是那么重要。他們認為，由于數據是以專門的格式進行存儲的，所以大多數數據庫設計便沒有了用武之地。

 在這個問題上的困惑通常是源于對解決方案要以何種特殊的方式執行大數據查詢的誤解。簡單來說就是，在大多數情況下，數據會存儲在兩個地方：你當前的生產數據庫管理系統(DBMS)和新型專用的一體機。當前的生產流程是提取，轉換并加載數據到當前DBMS，繼續按原樣操作，還有一個額外步驟：每當你加載數據到一個表的時候，你還要確保新數據也能被加載到新一體機中去。

 在DBMS加載成功后，便可以馬上把數據加載到一體機，或者可以供后續執行分批處理。而重要的是，在任何大數據查詢使用已加載數據來獲得性能改善之前，必須先把數據加載到一體機。

數據庫設計是質量的保證

 有質量的數據庫設計意味著什么呢?一般來說，數據庫設計開始于數據模型和定義之間關系的業務規則。例如，訂單總是與客戶相關的，并且客戶可能沒有訂單或者有多個訂單。有了這些東西以及數據元素定義和屬性，數據庫設計就可以在以下領域解決，處理或是降低風險：

1.通過自動數據元素有效值檢查來協助避免缺陷;

2.在應用構建和測試期間允許缺陷檢測和修復;

3.盡可能讓數據驗證接近其源頭;

4.提供穩定性，可靠性，數據可訪問性和系統擴展性。

  數據庫設計人員的做法有什么差別?

  糟糕的數據庫設計對技術支持的影響非常之大，他們必須實時處理系統問題，這樣就會抬升定位和解決問題的成本。其在產品行為上還會體現為惹惱或是趕走客戶。而與糟糕設計相關的常見的問題就是非常差得應用性能和數據沖突。

  典型的修復方法包括數據庫重組或重新設計，如添加表索引和改變表分區和聚簇。然而，在大數據環境中，這些方法在專用一體機中通常是行不通的。它們只會存在于數據庫的基本表中。這是問題的癥結所在：盡管供應商聲稱你所有的數據都可以遷移至專用一體機，但這絕不是優先的解決方案。

   讓數據在主數據庫管理系統和一體機之間共存是較好的方法，其原因如下：

1.避免單點故障。專用一體機往往存折一個單點故障。雖然有供應商和支持人員的努力，但是一體機中的軟硬件，網絡連接和流程都可能會發生故障。如果是這樣，如何才能進行滿意的查詢呢?數據協同定位在數據庫管理系統中，查詢結果可以通過訪問基本表得以滿足。當然，性能肯定會受到影響;但是，如果不這樣做的話，在有人修復這一問題之前，你的大數據應用都會是不可用的。

2.提供數據卸載。查詢并非是數據的為數不過消費方。一種常見的用法是將生產數據卸載到測試環境。此外，某些第三方供應商軟件工具會直接訪問本地數據庫中的數據，而這在一體機中是不可用的，因為數據是以專門的格式進行存儲的。

3.備份和恢復。常見的備份和恢復工具都是以那些駐留在數據庫中的數據為基礎的。而第三方供應商工具通常用于高性能備份和恢復，包括索引恢復。這些備份是針對基本表和表空間執行的，而非一體機。

4.某些性能狀況。在某些情況下，SQL查詢在一體機中無法執行。這些限制都是定義在手冊中的，并且隨著供應商一體機和版本的不同而不同。在這些情況下，你別無選擇;你必須訪問基本表并接受性能的下降。其中一些限制包含了特定的SQL語法，例如可滾動游標，動態SQL，使用多個字符編碼方案，某些相關表表達式，以及使用某些內置函數。

　　大數據的數據庫設計

  因為你要同時在DBMS和專用一體機中保存數據，所以標準數據庫設計規則對你來說仍然適用。有趣的是，由于一體機的存在，如今某些規則得以擴展或是變得更加復雜。下面是一些注意事項：

  對索引的需求。索引服務于多種需求：它們可以賦予數據元素為數不過性，它們可以賦予參照完整性關系，它們可以定義主鍵，并且它們可以定義額外訪問路徑。后一項是十分重要的。在大數據環境中，我們的想法是把長時間運行的查詢放進一體機中以進行高速處理。如果某些存在的索引僅僅是提供可選訪問路徑，那么可能就不再需要它們了。數據庫設計或是重新設計應該包括對所謂性能索引的檢查。如果此索引不再被查詢所用，那么就可以刪除它們，從而節省表數據恢復所需要的磁盤空間，處理時間和恢復時間。

  刪除一體機的SQL限制。通常來說，數據的業務規則決定著數據庫設計的部分內容。這包括進行物理分區以允許更快的查詢和更簡便的數據清理，諸如字段約束在內的數據元素域檢查，以及用于支持參照完整性規則的主鍵和外鍵定義。接著，應用程序開發人員會編寫SQL查詢來訪問數據。此外，用戶可能擁有的報告工具會自動為查詢和報告生成SQL代碼。因為SQL查詢語法和功能取決于數據庫設計，所以設計人員需要對一體機限制熟稔于胸。

 為高速一體機的數據加載進行設計。現在正常的數據庫加載過程包含一個額外步驟：將數據加載進一體機。如何才能對此以優先的方式實現呢?這主要取決于你的應用和數據波動程度，因此要考慮以下變量：

   定期批量加載(每天，每小時)一體機，但要明白其中的數據并不完全是前沿的。

   細流加載，基本表中的記錄有過更新的地方會同步傳送至一體機。這樣就會保持一體機數據前沿，但是記錄的處理要比批量加載緩慢許多。

總結

  雖然數據庫軟硬件方面的進步可以將數據查詢的速度提升一個檔次，但大數據和一體機并沒有把對良好數據庫設計的需求棄之不用。實際上，設計人員有更多的事情需要去考慮：備份和恢復，索引管理，多途徑數據訪問，以及SQL限制。