如何有效地搜索可能很大的数据库？
这更多的是一种讨论。
我们有一个多租户系统，并且具有可以包含数百万行的表。我们的 UI 允许用户使用许多不同的搜索条件对这些表执行搜索 - 因此他们可以使用这些条件的任意组合。
在数据库中索引所有这些搜索列或将完整表加载到内存中然后进行过滤是不切实际的。
任何人都可以为我指明解决此问题的模式/设计的正确方向吗？
This is more of a discussion.
We have a system which is multitenanted and will have tables that can have millions of rows. Our UI allows users to perform searches against these tables with many different search criterias -- so they can have any combination of these criteria.
It is not practical to index all these search columns in the database or to load the full tables in memory and then filter.
Can anybody point me in the correct direction for patterns/designs that tackles this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道有任何模式可以解决您所描述的情况。无限数量的行、完全即席查询、许多并发用户？这不是一个要求；这就是“一切皆有可能”。
我假设这是一个报告数据库，而不是事务性数据库。数据是只读的。这是正确的吗？
具有星型模式的数据仓库将沿着精心设计的维度规定查询。用户可以滚动维度（例如时间维度允许用户滚动到日、周、月、季度、年等）。但这样做的逻辑是在数据库上执行并在存储过程中编码的。
我对用户需要中间层数百万行的说法提出质疑。没有用户可以一次获取数百万行。 Google 一次返回 25 个单个查询返回的数百万个页面。
也许您可以流式传输以独立方式使用的数据集，并使用 Excel 或其他工具进行分析。但这是我能想象的最好的场景。
I'm not aware of any pattern to solve the situation you describe. An unlimited number of rows, completely ad hoc queries, many simultaneous users? That's not a requirement; that's "anything goes".
I'll assume that this is a reporting database, not transactional. The data is read-only. Is that correct?
A data warehouse with a star schema would prescribe queries along thoughtfully designed dimensions. Users can roll up dimensions (e.g. time dimension allows users to roll up to day, week, month, quarter, year, etc.). But the logic to do so is executed on the database and coded in stored procedures.
I'd challenge the assertion that users need millions of rows on the middle tier. No user can take in millions of rows at once. Google returns the millions of pages returned by a single query twenty-five at a time.
Maybe you can stream down data sets that are used in a detached manner, analyzed using Excel or some other tool. But that's the best scenario I can envision.