通过访问了专攻数据分析、数据建模、数据仓储和商业智能（BI）的PenguinSoft咨询公司联合创始人Mark Whitehorn先生，他表示任何一个称职的顾问都会在提出数据仓库改变建议之前，先看看这个公司存在的问题。
很多公司都想要提高数据加载和查询处理性能。在访问了专攻数据分析、数据建模、数据仓储和商业智能（BI）的PenguinSoft咨询公司联合创始人Mark Whitehorn先生，他表示任何一个称职的顾问都会在提出数据仓库改变建议之前，先看看这个公司存在的问题。总体上说，存储产品的选择很关键，有6个技巧可以改进数据库性能。
1.在考虑性能优化之前，需要先找出现存的瓶颈。如果你的查询性能CPU负载比较高，那么买更快的磁盘就完全是浪费钱。
2.了解你的数据库引擎。当用户还不了解自己数据库输入和输出的时候，往往就要开始危及性能了。例如，我见过用户使用SQL的Insert语句加载数据，而不是用更高效的批量加载工具。
我也见过用户用delete * 来删空一个表。这与Drop和Create相比是非常慢的，甚至比Truncate还要慢很多。当然，也许你的数据库软件并不支持Truncate--这就是为什么你需要了解它是如何工作的。如果你还没有一个好的DBA,也许单单从性能优化的角度看就值得聘用一个。
3.就查询而言，考虑将数据做成MOLAP立方体结构（例如，多维在线分析处理）并事先做好聚集，这可以让查询性能有很大提升。虽然会占用更多的磁盘空间和数据处理时间，但在性能方面会有很大提升。
4.考虑使用固态硬盘。这对磁盘速度问题会有意想不到的成本节约。最近，我正在跟一个有35GB的OLAP Cube的客户一起工作，性能很慢，聚集时间和查询速度都很慢。我推荐他们试试SSD.果然，在测试工作台上就有了一台崭新的70GB SSD PC.
这台机器是配置合理，RDBMS安装在硬盘上， OLAP cube创建在SSD上。Cube聚集得更快了，查询性能的改进就更显着了。有些查询比相同级别的聚集快20倍。与性能的提高相比，SSD的成本是完全是微不足道的。
5.考虑在笔记本上做SSD。（我自己也这么做了，我现在正在用的这台笔记本上有250G），但这也是对磁盘集中的令人难以置信的应用。如果可能，在内存中执行抽取、转换和加载（ETL）处理。对于执行时间很长的ETL操作，可以用磁盘缓存（以防处理失败），缓存到SSD而不是硬盘。
6.为分析的目的，而不是事务的目的对分析结构做索引。听起来很显然，但是，我见过无数的关系型OLAP星型模式，其中的索引策略都是根据事务型系统的长期经验而做的，很少有是根据分析型系统的经验。
例如，默认情况下，许多关系型数据库引擎都会对表的主键做索引。这在事务型结构中很普及，许多查询都会用到这个索引--但是很少有人知道，在星型模式中，很少会用主键索引进行常规的单行查询。另一方面，维表中所有的分析列都很有可能被查询，也常常会用到索引。
网友评论