数据仓库中的索引
我正在 SQL Server 2008 中创建一个数据集市,使用 SSIS 进行加载,使用 SSAS 进行 OLAP 多维数据集。 到目前为止,一切都很顺利。 但是,除了主键上的默认集群之外,我没有在源数据库上创建任何索引。
我对在应用程序数据库上设计索引非常满意,但由于该数据库主要是作为多维数据集的源,因此我不确定哪种类型的索引(如果有)会有所帮助。
我应该做任何类型的索引来改进维度和多维数据集的处理吗? 我正在使用你们的常规 Molap 存储空间。
I'm creating a data mart in SQL Server 2008 using SSIS for load, and SSAS for an OLAP cube. So far, everything is working great. However, I haven't created any indexes on the source database other than the default clustering on primary key.
I'm pretty comfortable with designing indexes on the application databases, but since this database is intended primary to be the source for a cube, I'm not sure what sort of indexing, if any, will be beneficial.
Is there any sort of indexing I should be doing to improve the processing of the dimensions and cube? I'm using your regular Molap storage.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
一般来说,最佳实践是让索引和约束远离集市,除非它们直接用于报告。 索引和约束会严重消耗您的 ETL 时间(尤其是通常进入仓库的数据量)。
我发现最有效的方法是在所有表上都有一个单独的 PK(包括事实,因为我有复合键,如果需要的话,我只需对复合键进行哈希处理即可获得 PK)。 拥有 PK(即标识列)可为您提供自动生成的索引、构建多维数据集时的快速连接以及非常快速的插入。
如果您要进行报告,请按照您的意愿构建索引,但请确保在 ETL 过程中禁用然后重建索引。 否则,批量插入需要一些时间才能完成(在某些情况下需要数小时才能提交)。
Generally, the best practice is to keep indexes and constraints off of marts, unless they'll be used directly for reporting. Indexes and constraints can seriously hose your ETL time (especially with the amounts of data that usually go into warehouses).
What I've found works best is to have a single, solitary PK on all of your tables (including fact, because I have composite keys, and I'll just hash the composite to get myself a PK if I have to). Having PK's (that are identity columns) provides you with an autogenerated index, quick joining when the cubes are built, and very quick inserts.
If you're going to be doing reporting, then build out the indexes as you would, but make sure to disable and then rebuild the indexes as part of your ETL process. Otherwise, bulk inserts take some time to do (hours upon hours to commit, in some cases).