[.com快速翻译]这些天几乎每个人都以这种或那种方式抱怨性能。数据库管理员和程序员不断发现自己处于服务器瓶颈或查询无休止的情况并不少见。这种抑郁症对我们所有人来说都很熟悉，并且有不同的解决方案。最常见的情况是看一眼查询就责怪程序员没有更好地处理它。也许他们可以使用合适的索引或物化视图，或者以更好的方式重写查询。有时，如果您的公司使用云服务，您可能希望启用更多节点。在其他情况下，如果服务器因过多的慢速查询而不堪重负，您可能希望为不同的查询设置不同的优先级，这样至少更紧急的查询（例如***执行的查询）可以更快地完成。如果数据库不支持优先队列，管理员甚至可能会取消你的查询，腾出一些资源用于更紧急的查询。无论您遇到过上述哪种情况，您可能都熟悉不得不等待缓慢查询，或者购买更多云实例，或者购买更快、更大的服务器的痛苦经历。大多数人都熟悉传统的数据库调优和查询优化方法。这些方法各有优缺点。所以，我们不会在这里谈论这些方法。在本文中，我们讨论的是更新颖的方法，这些方法鲜为人知，但在许多情况下确实提供了显着提高性能和节省成本的机会。首先，请考虑以下场景：场景1（探索性分析）-您是一名分析师，正在交叉分析数据、寻找见解和模式，或者测试关于您的公司、客户或服务的不同假设。在这种情况下，您常常不知道自己看到的到底是什么。您运行查询，查看结果，然后决定是否需要运行不同的查询。换句话说，您执行一系列探索性的即席查询，直到找到所需的结果。只有您运行的某些查询用于填充公司报告、填写表格或为客户生成图形。但是每当您提交查询时，可能需要几分钟才能得到答案，具体取决于数据的大小和集群中其他并行查询的数量。在等待的时候，你通常无事可做，也不能决定下一个查询，因为这取决于你还在等待完成的上一个查询的输出！解决方法：在等待的过程中，您可以立即看到“几乎***”的答案。这里的“几乎***”答案是什么意思？比较下面的两个图像。这些是同一商业智能工具在运行从后端数据库加载数据的查询后的输出。右边的图像使用全部10亿个数据点用了71分钟完成，而左边的图像只用了3秒只用了100万个数据点完成！当然，左边的图和右边的***版相比，有点模糊。但是想想看：值得吗？您无需等待71分钟，而是立即得到几乎相同的答案，然后决定是否要再等71分钟以获得完整答案，或者等待并做其他事情！这当然不是一个新想法！几乎所有的网络浏览器都已经这样做了。下次您尝试在浏览器上加载高分辨率图像时，请注意Web浏览器如何首先尝试加载和显示模糊图像，然后图像会逐渐变得越来越清晰。但对于将相同的原则应用于数据库和SQL查询处理，人们知之甚少。所以，现在您可能有几个问题：我们实际上如何获得这种加速？即使您的数据分布是倾斜的，这个技巧也能奏效吗？您是否仍然看到异常数据？您是否需要使用特定的数据库才能享受这种速度和准确性之间的权衡？我将在文章末尾回答所有这些问题，但首先让我谈谈其他几个场景，在这些场景中，您可能会发现同样的想法很有吸引力：立即看到准确率为99.9%的结果，但速度提高了200倍！场景2（过载的集群）——像当今大多数数据库用户一样，您可能没有专供自己使用的集群。换句话说，您与您的团队共享集群，甚至共享其他报告和商业智能工具。这些工具针对相同的共享数据库资源池执行SQL查询。如果这些共享集群过载，实际上可能会发生以下三种情况之一：A.普遍抑郁。你什么都没做，让每个人都受同样的苦。换句话说，一旦数据库查询积压，CPU内核满载，就没有人能足够快地完成查询。B.部分抑郁症。您可以更巧妙地执行此操作，终止或暂停优先级较低的查询，让更紧急的查询（例如您的经理的查询）首先完成。换句话说，你确保一些更重要的人开心，但让其他人生气！C.如果经常出现这种情况，可能需要购买更多更大的服务器，或者迁移到云端，并根据需要启用更多节点。当然，这种方案会花费一定的金钱，而且也不方便。另外，这通常不是短期解决方案。大多数人没有意识到的是，还有第四种方法比前两种方法更好，而且与第三方方法不同，它不需要花钱。那么这个方法是什么？第四种方法如下：为低优先级查询返回99.9%的准确答案，为其余查询返回100%的准确答案！这是有效的，因为统计法则通常仅使用0.1%的数据和处理即可获得99.9%准确的答案。这就是为什么牺牲0.1%的准确度实际上意味着100倍到200倍的加速。我知道没有人愿意凑合使用99.9%的准确率，但您需要考虑其他选择：终止查询、进入长长的等待列表，或者只是坐在那里等待查询完成。正如我在场景1中提到的，在许多情况下，您仍然可以获得完整答案，只需在等待完整答案时使用99.9%的准确答案即可。我将回到文章末尾的“如何”问题。不过现在，请记住：99.9%的准确率并不意味着您遗漏了0.1%的输出。通常您仍能看到所有内容，但实际数字可能会相差0.1%，这意味着在大多数情况下，除非您真的眯着眼睛，否则您甚至无法分辨出差异。比较这两个图：这些是查询的输出，使用著名的纽约市出租车数据集询问在市区打车所需的总时间。你能说出哪个是100%正确答案，哪个是99.9%正确答案吗？对大多数人来说，两者是一样的。但是上面的查询只用了1.7秒，而下面的查询用了42.7秒。这意味着通过牺牲0.1%的准确度，您可以节省25倍的CPU时间！让我们谈谈第一个场景，然后我将向您展示“操作方法”部分。场景3（机器学习和数据科学）——如果您是机器学习专家或数据科学家，您会经常发现自己在训练统计模型、调整参数或进行一些特征选择和工程。这方面最常令人沮丧的问题之一是你需要尝试大量的参数或特征，训练一个机器学习模型需要很长时间。集群不断忙于训练和测试不同的模型，这限制了数据科学家可以尝试的不同模型和参数集，或者至少减慢了过程。在许多应用程序中，您不需要完全准确的答案来做出合理合理的决定。A/B测试、根本原因分析、特征选择、可视化、噪声数据或具有缺失值的数据库就是这种情况。除非您在计费部门，否则您不想这样做！我可能会写另一篇关于如何加速参数调整或特征选择的文章。但是“如何”让查询速度提高200倍，而只牺牲一点点准确性呢？答案在于一种称为近似查询处理（ApproximateQueryProcessing，简称AQP）的技术。有多种实现AQP的方法，但最简单的方法是使用表的随机样本。结果是，如果您的数据有偏差，您就不想使用随机样本，因为这会遗漏原始表中可能存在的大多数异常值和稀有项目。因此，实际上更常见的是一种称为“分层样本”的样本。什么是分层样本？看下图：假设你想在这个表上运行下面的查询：SELECTavg(salary)FROMtableWHEREcity='AnnArbor'当然你可以运行这个查询，但是如果表有数亿行数，或者跨多台机器的分区可能需要几分钟才能完成。相反，您可以决定仅对表的随机（即统一）样本运行查询，例如：如您所见，由于与原始表中的NYC元组相比AnnArbor元组很少见，因此您可能会看到AnnArbor很少或根本没有。相比之下，分层抽样会先按照城市对表进行分层（即分区），然后对每个城市的行进行随机抽样：NYC 67 62,492 1/4***nnArbor25120,2421/2事实证明，在不深入研究统计数据的情况下，这样的分层样本将确保：通过处理小的原始元组，可以达到非常高的精度。现在，下一个问题是如何创建这些样本？以及如何衡量准确性？有自动的方法可以做到这一点。市场上有几种产品可以用来隐藏这种复杂性，这样您只需按下一个按钮，它们就会为您一路走来，并以极快的速度返回答案，有些甚至为您提供旋钮。通过转动旋钮，您可以决定您需要多少精度来换取您可以提高多快的速度。BlinkDB/G-OLA尽管市面上有很多AQP解决方案，但BlinkDB可能是第一个成为开源项目的分布式（大规模并行）AQP引擎。本着完全公开的精神，我参与了这个项目，所以我在这里可能有偏见，因为我确实喜欢BlinkDB的方法，我认为它确实影响了后面描述的许多学术和工业项目。Databricks（将ApacheSpark商业化的公司）继续致力于BlinkDB。Databricks不久前公布了BlinkDB的扩容计划，将逐步完善其查询答案，直到用户满意为止。这个扩展称为G-OLA。G-OLA之前从未公开发布过，BlinkDB也很久没有更新了。SnappyDataSnappyData是一个开源的内存混合分析平台，在一个引擎中提供OLTP、OLAP和Streaming。数据库引擎本身是通过扩展ApacheSpark构建的（因此它与Spark完全兼容）。内存核心还通过精心策划的分层抽样和其他概率结构提供AQP。查询语法类似于BlinkDB，它允许用户指定所需的准确性。这意味着您可以像对待可调刻度盘一样对待准确性。例如，如果你想要准确的答案（这是默认行为），你可以要求100%的准确率；但如果你想要快速的答案，你也可以在一秒钟左右得到99%的准确答案。在我看来，SnappyData的一大优点是它使用了精选的分层样本。这意味着您可以在几秒钟内运行分析查询，甚至可以在笔记本电脑或共享集群（以及许多其他并行查询）中处理数TB的数据。它还具有对数据流的内置支持，使您可以构建示例并实时更新它们以响应传入的数据流。SnappyData的另一大特点是它带有许多高级用户界面，这意味着您无需精通统计学即可使用其AQP功能。例如，它现在拥有iSight，这是一种免费的云服务，它使用ApacheZeppelin作为前端，在后台运行完整查询的同时立即显示查询响应。PrestoFacebook的Presto具有一个近似于基本聚合查询的实验性功能。我其实不知道***版本是否有这个功能，但缺点是你必须使用不同的语法（即修改SQL查询）才能调用那些近似聚合函数。如果您现有的商业智能工具或应用程序不使用此特定语法，那将很麻烦，因为除非将它们重写为使用此新语法，否则它们将无法从潜在的加速中获益。语法。InfoBrightInfoBright提供了一个近似查询功能（名为IAQ）。与其他系统不同，IAQ根本不使用样本。不幸的是，关于逼近函数如何工作，它们提供什么样的准确性保证，并没有公布太多细节，但在阅读他们的博客后，我认为他们正在构建底层数据的模型，并使用这些模型来回答查询，而不是使用样品。我也不太了解IAQ，因为它不是开源的，我在其官方网站上找不到很多细节，但这听起来是一种值得研究的方法。ABSAnalyticalSteeringSystem(ABS)是另一种近似查询引擎，它使用样本和高效的统计方法来估计误差。***该代码有点过时，仅适用于早期版本的ApacheHive。该项目目前处于非活动状态。VerdictVerdict是一个中间件，位于您的应用程序或商业智能工具与后端SQL数据库之间。您只需对现有数据库执行与以前相同的查询，即可立即获得大概的答案。原则上，可以将Verdict与任何SQL数据库一起使用，这意味着您不受任何特定数据库管理系统(DBMS)的束缚。但目前，它只附带了SparkSQL、Hive和Impala的驱动程序。优点是通用，兼容任何SQL数据库，开源；缺点是由于它是中间件，可能不如某些商业解决方案（如InfoBright或SnappyData）高效。Oracle12COOracle12C引入了approximatecountdistinct和approximatepercentage函数。这些近似聚合提高了性能并使用更少的内存进行计算。Oracle12C还提供物化视图支持，因此用户甚至可以预先计算近似聚合。虽然近似百分比和不同计数查询很有用并且实际上很常见，但其他类型的查询并未得到广泛支持。但考虑到Oracle庞大的用户群，即使是这些有限的功能，许多用户也会受益。然而，据我所知，许多其他数据库供应商长期以来一直支持近似计数不同的查询（例如使用HyperLogLog算法）。原标题：HowToMakeYourDatabase200xFasterWithoutHavingToPayMore?，作者：BarzanMozafari
