如何有效地搜索潜在的大型数据库？答案

【问题标题】：How do I efficiently search a potentially large database?如何有效地搜索潜在的大型数据库？
【发布时间】：2012-03-04 10:03:42
【问题描述】：

这更像是一个讨论。

我们有一个多租户系统，并且将拥有可以包含数百万行的表。我们的 UI 允许用户使用许多不同的搜索条件对这些表执行搜索——因此他们可以使用这些条件的任意组合。

在数据库中索引所有这些搜索列或将完整的表加载到内存中然后进行过滤是不切实际的。

谁能指出解决此问题的模式/设计的正确方向？

【问题讨论】：

这是一个开放式问题。实际上，在不了解您的领域的情况下，我会问您是否可以重新定义范围。是否可以制作 UI 来引导用户执行您确实有索引的搜索。与其让用户进行任何类型的adhoc 查询，不如让用户与您一起讨论他们的需求并相应地调整数据和索引。
这里是一个例子：用户可以搜索发票。他们能够搜索发票编号、发票日期、发票工作编号、发票客户、发票供应商、发票状态（已付款、作废等）、发票付款日期。没有搜索指南。他们可以选择/填写任何标准并点击搜索

【解决方案1】：

我不知道有什么模式可以解决您描述的情况。无限数量的行、完全即席查询、许多同时用户？这不是要求；这就是“一切顺利”。

我假设这是一个报告数据库，而不是事务性数据库。数据是只读的。对吗？

具有星型架构的数据仓库会根据精心设计的维度规定查询。用户可以汇总维度（例如时间维度允许用户汇总到日、周、月、季度、年等）。但这样做的逻辑是在数据库上执行并在存储过程中编码。

我会质疑用户在中间层需要数百万行的断言。没有用户可以一次接收数百万行。 Google 一次返回由单个查询返回的数百万页 25 个页面。

也许您可以流式传输以分离方式使用的数据集，使用 Excel 或其他工具进行分析。但这是我能想到的最好情况。

【讨论】：

您好，感谢您的回复。这不仅仅是一个报告系统。所以它也有实时交易。另外，您说用户永远不会使用磨坊行是正确的，但我描述的问题是查询超过一百万行的表。此查询可以是多个不同列的组合，这些列不一定要被索引
查询一百万行没有索引永远不会执行。那些进行交易的人也会受到影响。你完蛋了。
是用户不应该有这么多条件搜索的灵活性
也许吧。你的问题不恰当。它是如此开放，以至于无法回答。也许这就是为什么你在设计它时遇到这样的麻烦。你没有真正的要求或限制。
如果您阅读了我对 Matt Fenwick 的评论（上图），我已经举了一个用户如何使用系统的示例