设计一个非常大的低粒度数据库的提示/链接/书籍？

Question

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

SAS程序员向我们的DBA团队寻求存储数据的方法，以便大大提高查询性能。

两个主要困难是：

1. 我们只有少数几个示例查询，并且没有特别典型的查询集。

2. 许多查询都是

   之类的形式

   SELECT COUNT（DISTINCT id） FROM TABLE t   在哪里=真     并且b = 3     AND c IN（3到10）;

但WHERE过滤器参数未知，可包括列和属性的任意组合。这就是说，在我看来（对数据仓库有点了解）我们的要求排除了我们执行某些聚合并使用更高粒度的记录的典型数据仓库方法。

我正在寻找与设计具有类似约束的数据库相关的任何资源。在Bill Inmon的构建数据仓库中，他简要提到了“勘探仓库”和“数据挖掘仓库”。使用这些术语，我发现这篇文章稍微有点帮助：“设计数据仓库以进行有效的数据挖掘”[pdf]，但这或多或少都是如此。我在搜索时发现的大部分内容：“数据挖掘”都是关于OLAP的。

我是新手DBA，我的任务是为这个设计提出一些建议。我认为在这一点上，我最有帮助的建议是建议我们尽可能避免昂贵的连接。我不在这里 - 不要期待奇迹，但任何圣人建议或阅读建议都会非常受欢迎。

谢谢！

Answer 1

阅读Ralph Kimball所能提供的一切。

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

您的典型查询（SELECT aggregate FROM fact JOIN dimension WHERE criteria）是星型模式的最佳位置。

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

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

Answer 2

我想发表评论以获得更多澄清，但似乎我还不能！ 比如......

• 文本文件读取了多长时间？
• 是否可以发送增量文本文件和 维护一堆附加增量的SAS数据集 数据？

以下是一些建议......

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

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

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

如果您需要更多信息，请与我们联系。

谢谢， 中号