考虑到答案查找的理论指数复杂性(以查询的大小为单位),为什么关系数据库根本无法工作?


19

似乎已经知道,要在关系数据库上找到查询的答案,一个人需要时间,而一个人不能摆脱指数。D | D | | | | |QD|D||Q||Q|

由于可能非常大,我们想知道为什么数据库实际上根本不起作用。D

仅仅是普通查询在实际应用程序中根本不占很大的问题吗?(然后,很有趣的是知道关系数据库系统所执行的查询的通常大小是多少,以及实际上期望由DB系统有效回答的查询的“最大”大小是多少。)

关于指数注释 不可移动|Q|

显示指数不可移动,可以使用查询来查询数据库给出的图中是否存在大小为的团。检查图是否具有 -clique是NP完全问题。而且,它不是固定参数可处理的,具有参数。细节可以在例如 Libkin,L .:有限模型理论的元素中找到。Springer(2004) 或 Papadimitriou,CH,Yannakakis,M .:关于数据库查询的复杂性。J.计算机 Syst。科学 58(3),407–427(1999)n n n|Q|nnn



7
普通查询(如SELECT * FROM users WHERE username="abc" AND passwrod="xyz")是简单的搜索,需要O(| D |)才能运行。如果在相关的数据库字段上有一个索引,它将采用O(log | D |)。我不喜欢数据库,但是我认为更复杂的查询不会花费指数时间。
MS Dousti 2011年

7
@imz:在您的示例中,复杂度为,仍然是多项式。看来,如果查询中有k个联接,则复杂度为。这是固定k的多项式,但是我认为对于大k,运行查询实际上会非常慢。因此,必须不惜一切代价避免太多的联接。O | D | k + 1O(|D|2)O(|D|k+1)
MS Dousti 2011年

7
在最坏的情况下,时间复杂度是查询长度的指数。这与某些长查询速度很快并不矛盾。数据库从业人员知道哪些查询在典型的数据库引擎中可以快速运行,而且无论如何,他们都不依赖于查询长度的最坏情况。
伊藤刚(Tsuyoshi Ito)

2
@Kaveh:“ Immerman的描述性复杂性书在上一章进行了少量讨论”:非常好的建议。剔除:在倒数第二章中讨论。@imz:您可能还会发现SQL的表达能力也很有用。
MS Dousti 2011年

5
@imz:“此图是否具有n-clique”在实践中并不常见。大多数查询更像@Sadeq建议的查询,并且具有很强的树状结构。而且,对于非常大的数据库,甚至一个完全线性的查询也太昂贵了,必须使用数据库的草图。
安德拉斯·萨拉蒙

Answers:


16

即使在最坏的情况下,也存在许多“容易”的查询类别。特别是,如果查询类仅包含联合查询,并且每个查询具有有限的宽度(例如,树宽,其入射图的树宽,分数超树宽度或子模数宽度),则可以使用连接树之类的方法来回答该查询。 ,以及针对查询偏离树的本地部分的强力枚举。这需要多项式时间,多项式的次数由width参数确定。

似乎在实践中遇到的许多查询都是合取的并且宽度较小。因此,在这种情况下,多项式运行时的阶数较低。

DánielMarx最近在STOC 2010上发表了一篇关于亚模宽的论文,其完整版包括对宽度的各种概念以及CSP公式与数据库形式主义的关系的不错总结(会议版缺少此内容)。

  • 丹尼尔·马克思,用于约束满意度和结膜查询听话的超图性质,2010年的arXiv:0911.0801

这不是一个完整的答案,因为它不能解决数据库查询的“典型”复杂性,但是即使使用最坏情况的分析,也可以轻松进行查询。


6

可以使用查询Q_n来检查表示为数据库的图是否包含具有n个元素的集团。检查图是否具有集团是NP完全问题。而且,它不是参数为n(表示D ^ n)的固定参数可处理的。


请以问题“评论”(而不是“答案”)的形式发布有关问题背景的其他说明,即问题下方的“添加评论”按钮,或者以编辑建议形式(以下链接为“编辑”链接)问题。“答案”不适用于该问题的任何讨论和补充。(如果您以非匿名用户身份注册,则参加此会议应该更方便;然后更容易跟踪讨论中谁在说什么。)
imz-Ivan Zakharyaschev 2011年

@imz:他将其作为答案,因为他无权发表评论。一个需要至少有50个代表。可以在任何地方发表评论。
Tomek Tarczynski 2011年

@Tomek,@imz,嗯,这是正在讨论的元此刻我们是否应该允许使用评论答案或没有。
卡夫

5

回答这个问题的另一种方法是:“他们不!”

如果为典型的DBMS实现提供一个包含大量联接的查询,即使该查询是非循环的或具有非常简单的结构(例如,安德拉斯(András)提到上面。

但是,对于“典型” DBMS工作负载,似乎不会出现这种查询。


1
对于复杂的查询,优化阶段的结果是随机选择的计划。这并不像听起来那样糟糕,因为执行路径可能仍然“足够好”,而且还有很多原因使优化难以超越联接数量的组合。
Tegiri Nenashi'2

4

从实际大量使用(关系)数据库的人的角度来看,这是tigreen答案的更现实的版本:其应用程序的全部要点和复杂性在于以他们只需要很少数量的数据库就可以构建它们的方式。为每个需要的查询尽可能地加入,这就是它们实际起作用的原因。换句话说,不要指望数据库能够自己为您解决复杂的问题-不会,但是如果明智地使用它们,它们将是真正方便且适用的工具。


0

在多对多关系中,联接仅是二次关系。这些相对很少见:实际上,大多数关系和联接都是一对多的,因此如果定义了索引/键,它们将花费线性时间。具有几个多对多连接的查询一个严重的问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.