Cleaning Antipatterns in an SQL Query Log
Natalia Arzamasova , Martin Scheuro;aler , and Klemens Beuro;ohm
1 INTRODUCTION
NOWADAYS, various databases from different scientific domains are publicly available. They typically offer interfaces for declarative access, i.e., can be accessed in a very broad variety of ways. For the operators of such databases, it is very important to know what the users are interested. However, due to the public availability of the database, its owners cannot interact with all users to learn their interests. On the other hand, the queries issued by a user are a formal representation of his information needs. In other words, a query log is a perfect source of information to that end. However, analyzing such a log is difficult. For example, [1] describes an approach to detect user interests based on the query log. They cluster queries, using the overlap of the data space accessed as the distance measure. In their case study with SkyServer, there were several clusters that domain experts could not explain. The queries in these clusters filter data by internal IDs. These attributes do not have any meaning in astronomy. We conclude that those SQL statements are follow-up queries of previous ones, i.e., they need to be considered in a context. Such follow-up queries appear to be frequent in the log. They introduce negative effects, e.g., falsify analyses, as we are about to explain. In software engineering, such an actuality is named antipattern [2]. An antipattern is a special case of a pattern [3]: while a pattern is a common solution, an antipattern is a pattern with a negative effect.
Example 1. Table 1 lists a sequence of SQL queries of a user. These statements reflect specific intentions of the user, i.e., form patterns. The second, the third, and the fourth query filter the tables using the same constant. Without the first query, one cannot understand this constant. Put differently, a join is computed outside of the database. This is an occurrence of the Circuitous Treasure Hunt (CTH) antipattern [4]. Next, the second and the third query select different columns of the same table. This is the Stifle antipattern [5].
Example 2. Suppose that one wants to find hotspots of user interests. Queries 2 and 3 by the same user refer to the same data object, and a naive log-analysis scheme would count two occurrences of interest in this object. But it should not be overly controversial that these queries represent the same information need, at least when being issued right after each other. In other words, an occurrence of the Stifle has falsified this analysis.
Example 3. Consider again Table 1. Queries 2 to 4 can only be understood together with Query 1. This is because the Attribute id does not have any meaning from the domain perspective. Thus, if queries are rewritten with antipatterns removed, the specific user interest would be more obvious:
The topic of this paper is the detection of antipatterns in an SQL query log. We have consciously decided to see this as a general preprocessing step in the data-analysis processing chain, i.e., subsequent log-analysis tasks like user-interest identification or association-rule mining are decoupled from it. This is in line with the general, commonly accepted perspective that there is a data cleaning step that precedes more abstract, goal-oriented analyses. Having said this, we nevertheless have conducted combined experiments which reveal the usefulness of the preprocessing proposed in this article, see Section 6.9 below. Of course, with any data cleaning, an analyst needs to be aware of the fact that the cleaning has modified (biased) the original data. But that decoupling gives way to more flexibility as well as effectiveness and efficiency of the subsequent analyses. In other words, the approach described here is a variant of data cleaning, and we use the terms cleaning or solving for those re writes.
A common method to detect antipatterns [4] requires access to the software that generates the requests. Regarding SQL antipatterns, this means that one would need to have access to all systems working with the database. This is practically impossible, for databases on the Web in particular. That solution also does not help regarding antipatterns in an already existing query log. As Example 1 has insinuated, one challenge when looking for SQL antipatterns is the identification of dependencies among subsequent queries. At first sight, a promising approach is re-querying. For instance, to know for sure that Statements 2, 3 and 4 depend on Statement 1, one should run the first statement again and inspect the result. However, this is not viable, for the following reasons:
1. Performance aspect: Re-running a significant part of a SQL log implies a huge load on the database.
2. Side effects aspect: The database will save these lsquo;rerunrsquo; queries in the query log; this will bias any subsequent log analysis.
3. Data persistence aspect: In the presence of modifications of the data set, the result of a re-issued query does not have to be the same as the original one.
4. Schema modification aspect: Because of database schema refactoring such as renaming of attributes, old requests might even cause errors.
So when it comes to the design of a method that detects patterns and solves antipatterns, we see a difficulty in deciding what exactly should be rewritten.
Example 4. Consider Table 1 once more. If we did not have the information that all queries are from the same user, or if the attribute had a meaning in a specific domain, in contrast to lsquo;idrsquo;, it would be less clear if this were indeed occurrences of CTH and the Stifle.
This suggests to first examine how distinct/how frequent the clear cases are, and how far respective solutions will take us. It
全文共19225字，剩余内容已隐藏，支付完成后下载完整资料
在SQL查询日志中清除反模式
1引言
现在，来自不同科学领域的各种数据库都是公开的。它们通常提供用于声明性访问的接口，即可以以各种各样的方式访问。对于这些数据库的运营商而言，了解用户感兴趣的内容非常重要。但是，由于数据库的公开可用性，其所有者无法与所有用户交互以了解他们的兴趣。另一方面，用户发出的查询是他的信息需求的正式表示。换句话说，查询日志是达到这个目的的完美信息来源。但是，分析这种日志很困难。例如，描述了一种基于查询日志来检测用户兴趣的方法。他们使用作为距离测量访问的数据空间的重叠来对查询进行聚类。在他们对服务器的案例研究中，有几个领域专家无法解释的集群。这些群集中的查询通过内部ID过滤数据。这些属性在天文学中没有任何意义。我们得出这样的结论：那些SQL语句是对先前语句的后续查询，即它们需要在上下文中考虑。这种后续查询似乎在日志中很频繁。正如我们即将解释的，它们引入了负面影响，例如伪造分析。在软件工程中，这种实际情况被命名为反模式。反模式是模式的特例：虽然模式是常见的解决方案，但反模式是一种负面影响的模式。
例1.表1列出了用户的一系列SQL查询。 这些陈述反映了用户的具体意图，即形式模式。 第二个，第三个和第四个查询使用相同的常量过滤表。 没有第一个查询，就无法理解这个常数。 换句话说，联接是在数据库之外计算的。 这是迂回反模式的一个发生。 接下来，第二个和第三个查询选择同一个表的不同列。这是抑制反模式。
例2.假设你想找到用户兴趣的热点。同一个用户的查询2和3引用相同的数据对象，而一个简单的日志分析方案将计算这个对象中出现的两个兴趣点。但是，这些查询代表了相同的信息需求，至少是在彼此之间发布的时候，应该不会引起太大的争议。换句话说，窒息的发生已经证伪了这个分析。
例3.考虑表1。查询2到4只能与查询1一起理解。这是因为属性id从域的角度没有任何意义。因此，如果用反模式重写查询，特定的用户兴趣将更加明显:
本文的主题是在SQL查询日志中检测反模式。我们有意识地将此视为数据分析处理链中的一般预处理步骤，即。随后的日志分析任务(如用户兴趣识别或关联规则挖掘)与it分离。这与一般的、普遍接受的观点一致，即有一个数据清理步骤先于更抽象的、面向目标的分析。尽管如此，我们还是进行了联合实验，揭示了本文提出的预处理的有用性，见下文第6.9节。当然，对于任何数据清理，分析师都需要意识到清理已经修改了原始数据。但是，这种脱钩让我们有了更多的灵活性，以及后续分析的有效性和效率。换句话说，这里描述的方法是数据清理的一种变体，我们使用清理或解决这些重写的术语。
检测反模式的常用方法需要访问生成请求的软件。对于SQL反模式，这意味着需要访问所有与数据库一起工作的系统。这几乎是不可能的，特别是对于Web上的数据库。该解决方案在已经存在的查询日志中对反模式也没有帮助。如示例1所示，寻找SQL反模式的一个挑战是在后续查询中识别依赖关系。乍一看，一种有前途的方法是重新查询。例如，要确定语句2、3和4依赖于语句1，就应该再次运行第一个语句并检查结果。然而，这是不可行的，理由如下:
1.性能方面:重新运行SQL日志的一个重要部分意味着数据库的巨大负载。
2.副作用方面:数据库将在查询日志中保存这些“重新运行”查询;这将会影响后续的日志分析。
3.所示。数据持久性方面:在对数据集进行修改的情况下，重新发布的查询的结果不必与原始查询的结果相同。
4.所示。模式修改方面:由于数据库模式重构(比如重命名属性)，旧的请求甚至可能导致错误。因此，当涉及到一种检测模式并解决反模式的方法时，我们发现很难决定应该重写什么。
例4.再考虑一下表1。如果我们没有所有查询来自同一用户的信息，或者该属性在特定域中具有意义，与“id”相反，则不太清楚是否确实出现了迂回和抑制。
这意味着首先要研究清楚的案例有多清晰，以及各自的解决方案将会给我们带来多大的影响。还不清楚应该关注哪些反模式。
在这篇文章中，我们通过一个基于大量自由可用的查询日志的实证研究来回答这些问题。我们的主要步骤和核心见解如下:
1.我们提供了将查询负载划分为正常查询、模式和反模式的正式定义。
2.我们描述了检测和分类模式和反模式以及在查询日志中解决反模式的解决方案。当我们将自己局限于迂回和窒息时，我们设计了一个处理框架，它也可以容纳其他反模式(参见5.4节)。
3.所示。我们的实证研究依赖于服务器系统的日志，覆盖了7年的时间，包含了近4200万个查询。
4.所示。与其他关于数据清理的研究相一致，我们的核心评价标准是我们的结果的可信性(与任何下游分析的结果质量相反)。例如，在服务器日志中，反模式的份额是显著的(在15个最常见的模式中有6个反模式)，在删除它们之后，40个最频繁的模式中的所有模式都代表了有意义的信息需求。
5.我们提供的证据表明，以前对服务器日志的研究(例如，[6],[1])的结果会有所不同，因为日志已经被清除了反模式。
论文大纲:第二节回顾处理查询日志和一些众所周知的数据库反模式。在第3节中，我们关注影响查询日志的SQL反模式。第4节为我们的上下文提供模式和反模式的定义，并尽可能地重写规则。在第5节中，我们详细描述了我们的框架。第6节是实证研究。第7节是总结归纳。
2 相关工作
在本节中，我们首先看一下针对查询日志的工作。然后，我们回顾了检测和移除与数据库交互引入的反模式的方法。我们也参考了本文其他部分的相关工作，而本节只讨论在其他地方没有解决的相对较少的相关方法。
2.1处理查询日志
目前，查询日志分析是一个深入研究的领域。web日志和SQL日志之间有一个基本的区别。对诸如[7]和[8]等web日志处理的研究往往侧重于通过其信息查找活动来理解用户行为。[7]通过挖掘过去的查询来研究web搜索引擎优化。[8]通过挖掘点击和会话数据，提出了上下文感知的查询推荐方法。对SQL日志的研究主要考虑公开可用的科学数据库。[1]对Sky Server日志进行分析，目的是在数据空间中识别用户的兴趣。[6]使用相同的用例为SQL查询提供建议系统。[9], [10]和[11]是Sky服务器用户活动的详细报告。他们分析了两种类型的日志、SQL和web。该研究提供了自SDSS 处理器上线以来的前5个[9]和10年[10], [11]的各种统计数据。
SQL日志分析的另一个有希望的分支是诊断和修复错误更新引起的数据错误。[12]使用日志更新查询、更新、插入和删除语句，以及一组已知的数据错误，以查找和修复数据集中的错误。DML查询的处理没有解决我们的特定问题——找到反模式。然而，这项研究与我们的工作有联系，因为它提供了发现和解决错误的正式定义规则。总的来说，查询日志分析有不同的研究思路，即查询推荐、理解用户行为和诊断错误。我们的研究涉及所有这些目标。在查询日志中查找和修复反模式是进一步分析的预处理步骤，例如提供查询建议[6]或调查用户行为[1]，而不存在偏见。
2.2数据库反模式的回顾。
接下来，我们简要回顾一下数据库反模式的研究。[13]列出SQL查询中的语义错误。他们的见解来源于他们在纠正数据库考试时的经验。列出的一些错误导致了语法错误。这个功和我们的正交。如果错误频繁，可能会有相应的反模式，可以从日志中解决或删除。[14]通过查询元数据表来检测数据库设计的反模式。这种反模式反映了数据库模式中的错误，这不是我们研究的主题。[15]提出了一个用于检测对象关系映射(ORM)性能反模式的框架。它基于静态代码分析和基于规则的方法。在[16]中研究了DML错误模式的检测。然而，DML查询并不是我们论文的重点。原因是我们的目标是清除查找语句的查询日志，以便对其进行进一步的分析数据库用户在数据库中发现了什么有趣的东西。
3 基本原理
在本节中，我们将重点讨论两个反模式，它们影响对SQL查询日志的分析。这些是窒息[17]和迂回的寻宝[18]。它们也被认为是反模式相关性能下降的主要原因。我们的解释包括对他们的检测和移除的建议。然后，我们指出了当前解决方案的局限性，激励了一种新的方法。
3.1.1抑制反模式
窒息反模式包含几个包含类似SQL语句的查询[5]。类似的术语没有正式的定义。但是，除了WHERE子句中的常量之外，示例是相同的，如例1所示。处理此类查询可能是一个瓶颈，对性能有负面影响。在分析查询日志时，可能会篡改结果。例如，如前所述，它模糊了用户兴趣的表示。
例5．语句说明了窒息反模式。因此，itemList中的每个Id都会导致对表t的请求。在日志中，窒息表现为一系列类似的语句。
for (int item: itemList)
{String sql = 'SELECT * FROM T WHERE Id = ' item;
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);}
一种用于抑制[17]的检测方法是基于对软件运行实例的测量。它假设高负荷是存在反模式的高概率指示器。一个特定的抑制指标是每个服务的大量数据库调用和每个查询的平均结果行数。因此，这种方法基于一般的统计数据，可能不够精确。[18]在源代码级别上，针对基于度量的几种反模式的检测提出了启发式算法。在那里，窒息反模式的特点是许多类似的数据库请求。如果来自一个用户的两个或多个数据库请求存在，就会检测到一个窒息。此外，请求需要具有相同的结构，除了传递给方法构建或执行查询的值。因此，这种方法需要访问服务的源代码。此外，它基于对源代码中使用的字符串进行比较，然后形成查询。总之，这些检测方法是有限的，而且需要更复杂的方法来查看实际的查询负载。
现在，我们回顾了重写“窒息”反模式实例的方法。在软件开发中，这叫做重构。[12]提出了包重构。他们的想法是收集单个SQL语句，并将它们一次性发送到数据库。
例6.示例5的包重构是:
String sql = '';
for (int item: itemList)
{sql = sql 'SELECT * FROM T WHERE Id = ' item ';';}
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);
在包重构之后，一个人得到一个包含几个SQL语句的请求。此解决方案将删除不必要的网络开销，用于将来的任何查询。但是，它仍然需要相同数量的数据库资源。它不会改变查询日志。我们寻求的方法是在现有的日志中重写这样的查询，以促进有意义的分析。
3.1.2迂回模式(CTH)
“电路模式”(CTH)反模式[19]与“抑制”有一个相似之处，因为它们都是由多个数据库请求组成的。但是，单个的CTH查询相互依赖。这意味着随后的查询需要先前的查询结果作为输入。
类似地，高数据库开销是CTH反模式[17]的指示。但是，为了识别任何CTH，需要了解查询的知识或跟踪信息流的能力。在[18]中检测CTH是基于应用程序的源代码。因此，需要一种新的方法来发现数据库日志中CTH的实例。然而，这并不是微不足道的。如示例1所示，如果没有第一个查询的结果，就不能确定SQL语句序列的依赖关系。在[19]中，CTH的解决方案取决于软件开发的阶段，当反模式被发现时。如果在开发的早期发现了它，作者建议重新组织数据库模式。对于无法做到这一点的分布式系统，可以通过使用适配器模式来减少远程数据库调用的数量[20]。对于具有较大中间结果的设计，另一种方法是创建一个直接导致最终结果的新关联。
这些解决方案依赖于具体的案例，而不是自动的。此外，它们可以防止未来的CTH事件，但不能解决日志中的CTH事件。
4 模式和反模式
在我们的语境中，对“模式”有一个严格的定义是不可缺少的，要建立一个检测方法。模式的概念在反模式检测中非常重要，因为反模式是带有负面影响的模式。这部分还介绍了模式的某些属性。我们还需要精确定义的窒息和CTH反模式，以方便他们的检测和自动解决。本节包含这些定义。
4.1数据库模式
如例1中所指出的，我们将模式看作是表示特定功能的查询序列。从软件工程的模式定义开始，这个函数是一个模式，我们首先用非正式的方式描述数据库中模式的属性。然后，这个讨论导致了模式的正式定义，然后在本文中使用。
4.4.1直觉
在软件工程中，模式是在特定环境中部署的标准问题的重复解决方案模式[4]。在本文中，模式是查询日志中的SQL查询序列。想想鞋类零售商的数据库。
例7.购买一双鞋会导致以下一系列需要与数据库交互的步骤:
1.扫描鞋子的条形码。
2.给定条形码，查找大小和模型。
3.把购买的东西写进销售表。
4.减少当前可用的对的计数。
如下所示，步骤2、3和4会导致不同的查询形成一个模式。由于这些步骤
全文共6234字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12579]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
