【问题标题】:Tips/links/books for designing a very large, low-granularity database?用于设计非常大的低粒度数据库的提示/链接/书籍?
【发布时间】:2011-09-02 10:38:11
【问题描述】:

我公司的 SAS 程序员与研究人员合作,分析存储在许多大小约为 1Tb 的文本文件中的数据。生成的 SAS 流程可能需要数天才能运行。每当研究人员想要稍微改变一个问题时,就必须重新运行这些过程,这需要更多的小时或数天时间。

SAS 程序员向我们的 DBA 团队寻求一种存储数据的方法,目的是大大提高查询性能。

两个主要困难是:

  1. 我们只有少数几个示例查询,没有特别典型的查询集。
  2. 许多查询的形式类似于

    选择计数(不同的 id) 从表 t 其中 a = 真 和 b = 3 AND c IN (3 到 10);

但其中 WHERE 过滤器参数未知并且可以包括列和属性的任意组合。也就是说,在我看来(已经阅读了一些关于数据仓库的知识),我们的要求排除了典型的数据仓库方法,在这种方法中我们执行一些聚合并使用更高粒度的记录。

我正在寻找任何与设计具有类似约束条件的数据库相关的资源。在 Bill Inmon 的构建数据仓库中,他简要提到了“探索仓库”和“数据挖掘仓库”。使用这些术语,我发现这篇文章有点帮助:“Designing the Data Warehouse for Effective Data Mining”[pdf],但差不多就是这样。我在搜索 re:“数据挖掘”时发现的大部分内容都与 OLAP 相关。

我是一名新手 DBA,我的任务是为此设计提出一些建议。我认为在这一点上我最有用的建议是建议我们在设计时尽可能避免昂贵的连接。我在这里处于危险之中 - 不期待奇迹,但任何明智的建议或阅读建议都会受到欢迎。

谢谢!

【问题讨论】:

  • 您能描述一下每个分析背后的工作流程吗?您是否还衡量了流程的哪个部分花费的时间最多?

标签: database-design postgresql data-mining data-warehouse


【解决方案1】:

阅读 Ralph Kimball 的所有内容。

http://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimensional/dp/0471200247

您的典型查询 (SELECT aggregate FROM fact JOIN dimension WHERE criteria) 是星型模式的最佳选择。

忘记“数据挖掘”吧。这不是一个有用的术语。

专注于“星型模式”。构建正确的数据结构。

【讨论】:

  • 我同意,这是一本非常好的书。 kindall 也是“支持粒度”
【解决方案2】:

我想发表评论以获得更多澄清,但似乎我还不能! 比如……

  • 读取文本文件需要多长时间?
  • 是否可以发送增量文本文件和 维护一堆 SAS 数据集,在这些数据集上追加增量 数据?

这里有一些建议...

如果资金不是问题,那么切换到像 Netezza 这样的后端 DBMS 将有助于解决这个问题。

一种更简单的方法可能是将数据拆分为更小的数据集,然后更改查询以动态查看正确的数据集。例如如果所有查询都在查看 A 变量是 true 还是 false 并且 true 或 false 大约是 50/50,那么在此处将数据拆分为两个数据集可能会使该给定示例的查询时间减半。这种方法的唯一问题是它实际上取决于找到最佳拆分以适应所有查询类型。

索引也可能有助于加快速度。您需要分析哪些变量将成为索引的候选者。

如果您需要更多信息,请告诉我。

谢谢, M

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-08-10
    • 2021-03-07
    • 1970-01-01
    • 2012-09-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多