很多大數據應用的實施似乎都是在一個現有的數據倉庫上，添加一個或多個新的大容量數據流，還有一些支持數據存儲和業務分析的專業軟硬件。數據存儲問題通常是通過部署一個專門的硬件一體機來協調，這樣就可以在存儲大量數據的同時還能夠提供超快的數據訪問。
在這樣的情況下，我們還需要考慮數據庫設計的問題麽?
大數據環境下的數據建模
大多數DBA認為：良好的數據庫設計是系統和應用程序設計的一部分。很多的業務需求，如數據可用性，清理處理，還有應用性能都可以利用特定的數據庫設計加以解決。
那麽對於大數據又如何呢?有趣的是，為大數據業務分析提供軟硬件解決方案的供應商總是宣稱數據庫設計並不是那麽重要。他們認為，由於數據是以專門的格式進行存儲的，所以大多數數據庫設計便沒有了用武之地。
在這個問題上的困惑通常是源於對解決方案要以何種特殊的方式執行大數據查詢的誤解。簡單來說就是，在大多數情況下，數據會存儲在兩個地方：你當前的生產數據庫管理系統(DBMS)和新型專用的一體機。當前的生產流程是提取，轉換並加載數據到當前DBMS，繼續按原樣操作，還有一個額外步驟：每當你加載數據到一個表的時候，你還要確保新數據也能被加載到新一體機中去。
在DBMS加載成功後，便可以馬上把數據加載到一體機，或者可以供後續執行分批處理。而重要的是，在任何大數據查詢使用已加載數據來獲得性能改善之前，必須先把數據加載到一體機。
數據庫設計是質量的保證
有質量的數據庫設計意味著什麽呢?一般來說，數據庫設計開始於數據模型和定義之間關系的業務規則。例如，訂單總是與客戶相關的，並且客戶可能沒有訂單或者有多個訂單。有了這些東西以及數據元素定義和屬性，數據庫設計就可以在以下領域解決，處理或是降低風險：
1.通過自動數據元素有效值檢查來協助避免缺陷;
2.在應用構建和測試期間允許缺陷檢測和修復;
3.盡可能讓數據驗證接近其源頭;
4.提供穩定性，可靠性，數據可訪問性和系統擴展性。
數據庫設計人員的做法有什麽差別?
糟糕的數據庫設計對技術支持的影響非常之大，他們必須實時處理系統問題，這樣就會擡升定位和解決問題的成本。其在產品行為上還會體現為惹惱或是趕走客戶。而與糟糕設計相關的常見的問題就是非常差得應用性能和數據沖突。
典型的修復方法包括數據庫重組或重新設計，如添加表索引和改變表分區和聚簇。然而，在大數據環境中，這些方法在專用一體機中通常是行不通的。它們只會存在於數據庫的基本表中。這是問題的癥結所在：盡管供應商聲稱你所有的數據都可以遷移專用一體機，但這絕不是優先的解決方案。
讓數據在主數據庫管理系統和一體機之間共存是較好的方法，其原因如下：
1.避免單點故障。專用一體機往往存折一個單點故障。雖然有供應商和支持人員的努力，但是一體機中的軟硬件，網絡連接和流程都可能會發生故障。如果是這樣，如何才能進行滿意的查詢呢?數據協同定位在數據庫管理系統中，查詢結果可以通過訪問基本表得以滿足。當然，性能肯定會受到影響;但是，如果不這樣做的話，在有人修復這一問題之前，你的大數據應用都會是不可用的。
2.提供數據卸載。查詢並非是數據的為數不過消費方。一種常見的用法是將生產數據卸載到測試環境。此外，某些第三方供應商軟件工具會直接訪問本地數據庫中的數據，而這在一體機中是不可用的，因為數據是以專門的格式進行存儲的。
3.備份和恢復。常見的備份和恢復工具都是以那些駐留在數據庫中的數據為基礎的。而第三方供應商工具通常用於高性能備份和恢復，包括索引恢復。這些備份是針對基本表和表空間執行的，而非一體機。
4.某些性能狀況。在某些情況下，SQL查詢在一體機中無法執行。這些限製都是定義在手冊中的，並且隨著供應商一體機和版本的不同而不同。在這些情況下，你別無選擇;你必須訪問基本表並接受性能的下降。其中一些限製包含了特定的SQL語法，例如可滾動遊標，動態SQL，使用多個字符編碼方案，某些相關表表達式，以及使用某些內置函數。
发表回复