導讀：數(shù)據(jù)倉庫性能的優(yōu)化可以提高數(shù)據(jù)加載和查詢處理性能，針對優(yōu)化數(shù)據(jù)倉庫性能的技巧，PenguinSoft咨詢公司聯(lián)合創(chuàng)始人Mark Whitehorn作為一名數(shù)據(jù)分析、數(shù)據(jù)建模、數(shù)據(jù)倉儲和商業(yè)智能（BI）這些領域的專家，給出了幾點建議，內容如下：

請記住，任何一個稱職的顧問都會在提出數(shù)據(jù)倉庫改變建議之前，先看看這個公司存在的問題。我不了解你的公司。我只說說改進數(shù)據(jù)倉庫性能6個技巧：

　　1.在考慮性能優(yōu)化之前，需要先找出現(xiàn)存的瓶頸。如果你的查詢性能CPU負載比較高，那么買更快的磁盤就完全是浪費錢。

　　2.了解你的數(shù)據(jù)庫引擎。當用戶還不了解自己數(shù)據(jù)庫輸入和輸出的時候，往往就要開始危及性能了。例如，我見過用戶使用SQL的Insert語句加載數(shù)據(jù)，而不是用更高效的批量加載工具。

　　我也見過用戶用delete * 來刪空一個表。這與Drop和Create相比是非常慢的，甚至比Truncate還要慢很多。當然，也許你的數(shù)據(jù)庫軟件并不支持Truncate——這就是為什么你需要了解它是如何工作的。如果你還沒有一個好的DBA，也許單單從性能優(yōu)化的角度看就值得聘用一個。

　　3.就查詢而言，考慮將數(shù)據(jù)做成MOLAP立方體結構(例如，多維在線分析處理)并事先做好聚集，這可以讓查詢性能有很大提升。雖然會占用更多的磁盤空間和數(shù)據(jù)處理時間，但在性能方面會有很大提升。

　　4.考慮使用固態(tài)硬盤。這對磁盤速度問題會有意想不到的成本節(jié)約。最近，我正在跟一個有35GB的OLAP Cube的客戶一起工作，性能很慢，聚集時間和查詢速度都很慢。我推薦他們試試SSD。果然，在測試工作臺上就有了一臺嶄新的70GB SSD PC。

　　這臺機器是配置合理，RDBMS安裝在硬盤上， OLAP cube創(chuàng)建在SSD上。Cube聚集得更快了，查詢性能的改進就更顯著了。有些查詢比相同級別的聚集快20倍。與性能的提高相比，SSD的成本是完全是微不足道的。

　　5.考慮在筆記本上做SSD。(我自己也這么做了，我現(xiàn)在正在用的這臺筆記本上有250G)，但這也是對磁盤集中的令人難以置信的應用。如果可能，在內存中執(zhí)行抽取、轉換和加載(ETL)處理。對于執(zhí)行時間很長的ETL操作，可以用磁盤緩存(以防處理失敗)，緩存到SSD而不是硬盤。

　　6.為分析的目的，而不是事務的目的對分析結構做索引。聽起來很顯然，但是，我見過無數(shù)的關系型OLAP星型模式，其中的索引策略都是根據(jù)事務型系統(tǒng)的長期經驗而做的，很少有是根據(jù)分析型系統(tǒng)的經驗。

　　例如，默認情況下，許多關系型數(shù)據(jù)庫引擎都會對表的主鍵做索引。這在事務型結構中很普及，許多查詢都會用到這個索引——但是很少有人知道，在星型模式中，很少會用主鍵索引進行常規(guī)的單行查詢。另一方面，維表中所有的分析列都很有可能被查詢，也常常會用到索引。

原文鏈接：http://www.searchdatabase.com.cn/showcontent_49141.htm