Rethinking Database System Architecture:
Towards a self-tuning RISC-style Database System
数据库系统结构反思:实现自我调节的RISC型数据库系统
Abstract
Database technology is one of the cornerstones for the new millennium's IT landscape. However, database systems as a unit of code packaging and deployment are at a crossroad: commercial systems have been adding features for a long time and have now reached complexity that makes them a difficult choose, in terms of their "again/pain ratio", as a central platform for value-added information services such as ERP or e-commerce. It is critical that database systems be easy to manage, predictable in their performance characteristics, and ultimately self-tuning. For this elusive goal, RISC-style simplification of server functionality and interfaces is absolutely crucial. We suggest a radical architectural departure in which database technology is packaged into much smaller RISC-style data managers with lean, specialized APIs, and with built-in self-assessment and auto-tuning capabilities.
数据库技术是新时代IT业领域的基石之一。然而,作为一个单位代码数据库系统封装及部署在十字路口：商业系统已久,加上安特复杂,使得他们已经有了一个困难的选择,他们在"增益/疼痛比" 作为中央平台的增值服务,如信息的ERP或电子商务. 至关重要的是,数据库系统是易于管理,明确其性能特点,并最终自校正. 这个难以捉摸的目标,的RISC式简化服务器和接口功能是极为重要的. 我们建议激进建筑班车其中数据库技术包装成小得多的RISC式数据管理精益、 专门短片,内置自我评估和自动整能力.
1. The Need for a New Departure
Database technology has an extremely successful track record as a backbone of information technology (IT) throughout the last three decades. High-level declarative query languages like SQL and atomic transactions are key assets in the cost-effective development and maintenance of information systems. Furthermore, database technology continues to play a major role in the trends of our modern cyberspace society with applications ranging from web-based applications/services, and digital libraries to information mining on business as well as scientific data. Thus, database technology has impressively proven its benefits and seems to remain crucially relevant in the new millennium as well.
需要一个新的出发 
在过去三十年里，数据库技术作为骨干的信息技术(IT)已经是非常成功的。 高级说明性查询语言，如SQL查询语言和原子事物处理的使用，成为信息系统高效率开发和维护的关键技术. 此外, 数据库技术继续发挥着重要作用,在社会发展趋势与应用现代基于web网的：网上应用/服务、数字图书馆信息挖掘以及科学数据业务.近乎于有声有色影响,仍然在千禧年相关工作；因此,数据库技术已经证明了它的重要。
Success is a lousy teacher (to paraphrase Bill Gates), and therefore we should not conclude that the database system, as the unit of engineering, deploying, and operating packaged database technology, is in good shape. A closer look at some important application areas and major trends in the software industry strongly indicates that database system have an overly low "again/pain ration". First, with the dramatic drop of hardware and software prices, the expenses due to human administration and tuning staff dominate the cost of ownership for a database system. The complexity and cost of these feed-and-care tasks is likely to prohibit database systems form further playing their traditionally prominent role in the future IT infrastructure. Next, database technology is more likely to be adopted in unbundled and dispersed form within higher-level application services.
成功是笨教师(套用盖茨),所以我们不应该断定该数据库系统 作为单位工程,部署、数据库技术和经营包装,状况良好. 仔细看看一些重要领域和大型应用软件产业的发展趋势表明强烈数据库系统 有过于低"又/疼痛口粮". 首先,随着原油价格的硬件和软件, 由于人力和经费管理人员调主宰了数据库系统拥有成本. 这些复杂性和成本饲料、保健任务可能禁止数据库系统形成传统,进一步发挥其突出 在未来的资讯科技基础建设. 接下来,数据库技术更可能采取分散方式分解和更高层次应用服务.
Both of the above problems stem from packaging all database technology into a single unit of development, maintenance, deployment, and operation. We argue that this architecture is no longer appropriate for the new age of cyberspace applications. The alternative approach that we envision and advocate in this paper is to provide RISC-style, functionally restricted, specialized data managers that have a narrow interface as well as a smaller footprint and are more amenable to automatic tuning. 
两人以上问题都来源于数据库技术包装成一个单一单位的发展,维护、部署 和操作. 我们认为这是不恰当的建筑新时代赛博申请. 我们设想的替代办法,并主张在这一文件是提供的RISC型、功能受限, 经理说有一个专门的数据接口,以及缩小足迹较小,也比较适合自动 校正.
The rest of the paper is organized as follows. Section 2 puts together some important observations indicating that database systems in their traditional form are in crisis. Section 3 briefly reviews earlier attempts for a new architectural departure along the lines of the current paper, and discusses why they did not catch on. Section 4 outlines the envisioned architecture with emphasis on RISC-style simplification of data-management components and consequences for the viability of auto-tuning. Section 5 outlines a possible research agenda towards our vision. 
其余的文件是有组织如下. 第2拼凑在一起数据库系统的一些重要意见,表示他们是在传统形式的危机. 第3节简要回顾了新建筑的尝试早班车沿线目前皮 他们不明白为什么讨论. 第4概述设想的RISC结构,重点式简化数据管理部件和后果的可行性 自整. 第5概述了研究议程可能走向自己的梦想.
2.  Crisis Indicators 
To begin our analysis, let us put together a few important observations on how database systems are perceived by customers, vendors, and the research community. Observation 1: Featurism drives products beyond manageability. Database systems offer more and more features, leading to extremely broad and thus complex interfaces. Quite often novel features are more a marketing issue rather than a real application need or technological advance; for example, a database system vendor may decide to support a fancy type of join or spatial index in the next product release because the major competitors have already announced this feature. As a result, database systems become overloaded with functionality, increasing the complexity of maintaining the system’s code base as well as installing and managing the system. The irony of this trend lies in the fact that each individual customer (e.g., a small enterprise) only makes use of a tiny fraction of the system’s features and many high-end features are hardly ever exercised at all.  
2. 危机指标
开始我们的分析, 让我们把一些重要的观察数据库系统是如何知觉顾客,供应商, 而研究界. 观察1:featurism开车产品以外规范性. 数据库系统提供更多的特点,从而导致极其广泛复杂接口. 往往一个营销更为新颖的特点,而不是真正的问题还是需要应用技术进步; 例如 数据库系统供应商可能决定支持或参加花式型产品在未来的空间索引 由于主要竞争对手已释放宣布这一特点. 由于数据库系统成为超负荷功能, 日益复杂的系统维护代码基地以及安装和管理体制. 讽刺的是,这种趋势个别客户(如 小企业)只有一小部分利用该系统的特点,许多高端特点难以 行使好.
Observation 2: SQL is painful. A big headache that comes with a database system is the SQL language. It is the union of all conceivable features (many of which are rarely used or should be discouraged to use anyway) and is way too complex for the typical application developer. Its core, say selection-projection-join queries and aggregation, is extremely useful, but we doubt that there is wide and wise use of all the bells and whistles.  Understanding semantics of SQL (not even of SQL-92), covering all combinations of nested (and correlated) subqueries, null values, triggers, ADT functions, etc. is a nightmare. Teaching SQL typically focuses on the core, and leaves the featurism as a “learning-on-the-job” life experience. Some trade magazines occasionally pose SQL quizzes where the challenge is to express a complicated information request in a single SQL statement. Those statements run over several pages, and are hardly comprehensible. When programmers adopt this style in real applications and given the inherent difficulty of debugging a very high-level “declarative” statement, it is extremely hard if not impossible to gain high confidence that the query is correct in capturing the users’ information needs.  In fact, good SQL programming in many cases decomposes complex requests into a sequence of simpler SQL statements.  
观察2:SQL的痛苦. 头痛面对着的是一个数据库系统的SQL语言. 这是欧盟所有可以想象特点(其中许多是很少使用或者应当劝阻使用 无论如何),是太过复杂的典型应用发展. 其核心说甄选投影连接查询和聚集,是非常有益的, 但我们相信,有广泛运用一切智慧和笛长鸣. 了解SQL的语义(连的SQL-92),涵盖所有组合套(及相关)语句、空值、触发器、 ADT分泌功能等,是一场噩梦. 典型的SQL教学重点放在核心离开featurism作为"学习的在职"的生活经验. 一些贸易杂志偶而构成的SQL问答下一个挑战就是复杂信息的要求,表达了单一 SQL的声明. 那些办了几页报表,令人费解. 当程序员采用这种风格,并在实际应用的内在调试难度非常高层次的"宣示"声明 这是极其艰苦,甚至无法确信高增益质疑是正确把握用户 信息需求. 事实上,在许多情况良好的SQL编程复杂要求分解成简单的SQL陈述顺序.
Observation 3: Performance is unpredictable. Commercial database engines are among the most sophisticated pieces of software that have ever been built in the history of computer technology. Furthermore, as product releases have been driven by the time-to-market pressure for quite a few years, these systems have little leeway for redesigning major components so that adding features and enhancements usually increases the code size and complexity and, ultimately, the general  “software entropy” of the system. The scary consequence is that database systems become inherently unpredictable in their exact behavior and, especially, performance. Individual components like query optimizers may already have crossed the critical complexity barrier. There is probably no single person in the world who fully understands all subtleties of the complex interplay of rewrite rules, approximate cost models, and search-space traversal heuristics that underlie the optimization of complex queries. Contrast this dilemma with the emerging need for performance and service quality guarantees in e-commerce, digital libraries, and other Internet applications. The PTAC report has rightly emphasized: “our ability to analyze and predict the performance of the enormously complex software systems that lie at the core of our economy is painfully inadequate” [18]. 
观察3:表现难测. 商业数据库是世界上最先进的发动机件,从未建成软件史 计算机技术. 此外,由于产品已驱使发布时间对市场的压力好几年, 这些系统都很少回旋余地,以便重新加入主要成分特点和改良往往增加了代码大小 和复杂,最终总"软件熵"的制度. 可怕的后果是难以预测的数据库系统变得天生确切行为,尤其表现. 个体喜欢质疑optimizers可能已经越过临界复杂屏障. 有可能在世界上任何一个人都充分理解那些微妙复杂的相互作用改写 规则,大约型号、搜索遍历空间启发式理解复杂问题的优化. 相比之下,这种两难的新兴需要绩效和服务质量的保证电子商务、数字图书馆、 和其它互联网应用. Ptac的报告正确地强调: "我们的分析和预测能力,性能非常复杂的软件系统的核心所在 我们的经济痛苦不够"
Observation 4: Tuning is a nightmare and auto-tuning is wishful thinking at this stage.  The wide diversity of applications for a given database system makes it impossible to provide universally good performance by solely having a well-engineered product. Rather all commercial database systems offer a variety of “tuning knobs” that allow the customer to adjust certain system parameters to the specific workload characteristics of the application. These knobs include index selection, data placement across parallel disks, and other aspects of physical database design, query optimizer hints, thresholds that govern the partitioning of memory or multiprogramming level in a multi-user environment. Reasonable settings for such critical parameters for a complex application often depend on the expertise and experience of highly skilled tuning gurus and/or time-consuming trial-and-error experimentation; both ways are expensive and tend to dominate the cost of ownership for
a database system. “Auto-tuning” capabilities and “zero-admin” systems have been put on the research and development agenda as high priority topics for several years (see, e.g., [2]), but despite some advances on individual issues (e.g., [4,7,8,10,24]) progress on the big picture of self-tuning system architectures is slow and a breakthrough is not nearly in sight. Although commercial systems have admittedly improved on ease of use, many tuning knobs are merely disguised by introducing internal thresholds that still have to be carefully considered, e.g., at packaging or installation time to take into account the specific resources and the application environment. In our experience, robust, universally working default settings for complex tuning knobs are wishful thinking.  Despite the common myth is that a few rules of thumb could be sufficient for most tuning concerns, with complex, highly diverse workloads whose characteristics evolve over time it is quite a nightmare to find appropriate settings for physical design and the various run-time parameters of a database server to ensure at least decent performance. 
观察4:校正是一场梦魇,自动整现阶段是痴心妄想. 品种繁多的申请给予它无法提供数据库系统普遍表现良好的纯粹 具有良好的产品设计. 而所有的商业数据库系统提供各种"整把手",让顾客调整部分系统参数 工作量的具体特点,适用. 这些指标包括纽甄选,全国就业数据并行盘、设计及其他方面的实物资料, 查询优化小贴士门槛,执政的部份记忆还是在实现多层次多用户环境. 合理设置等关键参数的复杂应用知识和经验,往往取决于高技能 调谐大师和/或费时的试错实验; 两种方法都昂贵,往往主宰了数据库系统拥有成本. "自动校正"能力和"零剂量"系统已提上日程,作为研发重点课题数 年(见,例如,[2]),尽管有一些进展,但在个别方面(如 [4,7,8,10,24])进度全局自校正系统结构缓慢,几乎没有突破的迹象. 虽然商业系统已无可改进好用, 许多整只把手掩引进门槛,内部也要仔细考虑,例如, 在容器或安装时间顾及具体应用环境和资源. 根据我们的经验,稳健,普遍校正工作缺省背景复杂把手一厢情愿. 尽管共同神话拇指规则是少数能足够一般调谐关注 与复杂 高度多样的特点,工作量随着时间很恶梦找到适当场合对物理设计 以及各种运行时参数,以确保数据库服务器至少像样的表现.
Observation 5: We are not alone in the universe. Database systems are not (or no longer) at the center of the IT universe. Mail servers, document servers, web application servers, media servers, workflow management servers, e-commerce servers, auction servers, ERP systems, etc. play an equally important role in modern cyberspace applications.  A good fraction of these higher-level services have their own specialized storage engines and, to some extent, simple query engines, and even those that do make use of a database system utilize only a tiny fraction of the functionality up to the extreme point where the database system is essentially used as a luxurious BLOB manager. Thus, while we have been busy building universal database management systems, many important applications have simply decided to go on their own. In particular, quite a few vendors of such generic applications view complex SQL and the underlying query optimizer as a burden rather than an opportunity and consequently ignore or circumvent most high-level database system features (e.g., see [17]). Of course, this approach often amounts to “re-inventing” certain query optimization techniques in the layer on top of the database systems, but the vendors of these “value-added” Services consider the re-implementation as appropriate given that it can now be streamlined and tailored to a specific application class.  
观察5:我们不是单独在宇宙. 数据库系统不(或不再)为中心的宇宙它. 邮件服务器、文件服务器、Web应用服务器、媒体服务器、工作流程管理服务器,电子商务服务器,拍卖服务器,ERP系统, 同样重要的角色扮演等现代网络应用. 这些分数好高层次的服务都有自己专门存储引擎,并在一定程度上 简单查询引擎 即使那些不使用数据库系统只利用了小部分的功能 推向极致地步数据库系统,主要是用来作为豪华团块经理. 因此,虽然我们一直忙于通用数据库管理系统的建设, 许多重要应用已经偎在自己. 尤其 不少商贩等通用应用的基本观点和复杂的SQL查询优化作为一种负担,而 大于机遇,因此无视或规避最高层数据库系统特征(例如,见[17]). 当然 这种方法往往是"重新发明"在某些查询优化技术数据库系统层之上, 但这些商贩"增值"服务考虑重新实施酌情给予,现在可以简化 针对特定应用班.
Observation 6: System footprint considered harmful. The market for “classical” database installations may saturate in the near future. On the other hand, significant growth potential for the database system industry lies in embedded applications such as information services in cellular phones, cars, palm-pilots, etc.. These applications need even smaller fractions of the rich feature sets offered by a full-fledged database system. On the other hand, they face much tighter resource constraints in their embedded settings: neither the customer’s wallet nor the battery supply of a typical gizmo easily allows purchasing another 256 MB of memory. This implies that the footprint of a system (i.e., code-size and especially memory requirements) is a key issue for lightweight embedded applications. Also, brute-force solutions to performance problems (i.e., adding hardware) are often infeasible. Thus, the current generation of commercial database systems, despite some of them advertising lightweight versions, are not geared for these settings. 
观察六:制度足迹视为有害. 市场"经典"数据库装置可能在近期内渍. 在另一方面, 大幅增长潜力的产业,关键是嵌入式数据库系统等应用在手机信息服务, 汽车、手掌飞行员等. 这些应用需要更小的组分专题集提供丰富全面的数据库系统. 在另一方面,他们面临更严格的嵌入式环境资源限制: 无论客户的钱包电池供应也不容易让大人收购另一典型256甲基溴的记忆. 这意味着足迹制(即 代码大小和内存需求尤其)是一个关键问题轻量级嵌入式应用. 同时,强力解决问题的表现(即加入硬件)往往不可行. 因此,这一代的商业数据库系统,尽管他们有的广告轻量级版本 这些场合并不适合.
Observation 7: System-oriented database research is frustrating.  For the academic research (and teaching community the ever-increasing complexity of commercial database systems makes it very hard to position its individual research efforts in the fast-moving IT world On one hand, some of the traditional database-engine topics have been almost beaten to death, and the community leaders aim to steer researchers away from studying these seemingly myopic issues (although some of them are still far from a truly satisfactory solution). On the other hand, the success of research is more and more measured in terms of product impact, and for an academic idea to be intriguing to product developers, major prototype implementation and extensive experimentation is often required. With commercial database system being such a highly complex target, this kind of work becomes less and less rewarding and all too often exceeds the available resources in a university environment. Thus, it is no wonder that systems-oriented database research has become so scarce outside the labs of the major vendors The personal consequence for many academic researchers is that they turn away from database systems and star working on different topics, often in conjunction with startup companies where again the “entrance fee” is much lower than for a new database system). Similar observations can be made about teaching: teaching interface standards is boring, and teaching database system internals is often unsatisfactory because of the lack of documented knowledge or the indigestibility of the collection of tricks and hacks found in some systems. 
观察七:系统对象数据库研究是沮丧. 为学术研究(社会和教学的日益复杂,使得商业数据库系统很难立场 其个人科研工作日新月异的世界它一方面 一些传统的数据库引擎课题已几乎打死 旨在引导和社会贤达学研究者远离这些看似近视问题(尽管有些人 远未真正圆满解决). 在另一方面, 成功测研究越来越在产品冲击 而学术思想是耐人寻味产品商 大型样机试验往往需要广泛实施. 与商业数据库系统正在这样一个高度复杂的对象, 这种工作会越来越小,往往超过了奖励和资源在大学 环境. 因此, 也难怪系统对象数据库的研究等,已成为珍贵的大型实验室外的商贩 许多学者个人的后果是,他们转脸数据库系统和工作明星不同课 经常与公司那里再次启动了"入场费"比作一个新的数据库系统). 类似的意见可以左右教学:教学接口标准太枯燥 数据库系统内部及教学往往因为缺乏令人满意记载的知识或indigestibility 收集、棍发现一些花招系统.
All these observations together strongly indicate that database systems are in crisis: they have reached or even crossed a complexity barrier beyond which their lack of manageability and predictability will become so painful that information technology is likely to abandon database systems as a cornerstone of data-intensive applications. The bottom line is that database systems have become unattractive in terms of their !±gain/pain ratio: the gain of using a database system versus going on your own is outweighed by the pain of having to cope with overly sophisticated features and a hardly manageable, humongous piece of software. 
这些观测资料表明系统一起强烈的危机: 他们已达到甚至超越障碍越过了复杂而缺乏规范性和可预见性,将自己变得这么 痛苦,很可能放弃信息技术作为基石数据库系统数据密集型应用. 底线是,数据库系统已成为吸引在自己! +增益/疼痛比率: 增益用数据库系统相抵销,是靠自己走出伤痛不必 应付过于复杂的特点,难以应付,其所一块软件.
3.  Explanations and Previous Attempts 
3.1 Explanations 
Database systems (and possibly software technology in general) are susceptible to several “traps”: principles that open up both opportunities and complexity (just like Pandora’s box in the Greek mythology) and have been overstressed in the evolution of database systems. 
 3. 与以往的解释 
3.1解释 
数据库系统(可能是软件技术一般)易几个"陷阱": 开放原则,既充满机遇和复杂(就像潘多拉在希腊神话中),并已吸引 在数据库系统的演变.
Trap 1, the “universality trap”: Since a computer is a universal tool, software developers strive for extremely versatile, general-purpose solutions. This attitude of trying to cover as much ground as possible is ambivalent and extremely delicate, however. After all, every good principle can be generalized to the point where it is no longer useful. In the case of database systems, this has led to extremely complex, and hard-to-manage software packages. Contrast this evolution with other fields of engineering: despite the fact that wheels or engines are universal components of cars, the automobile industry has not attempted to develop a universal car that unifies all features of a sports convertible, luxury limousine, 4WD, and economic as well as “ecologically correct” compact into a single product. 
陷井1、"普遍性陷阱":由于计算机是一种普遍的工具,软件开发商争取极其多才多艺、通用的解决办法. 这种态度试图复盖尽可能多地含糊和极为微妙,但是. 毕竟,每个好的原则可以概括为地步不再有用. 在发生数据库系统,这导致极其复杂、艰苦地管理软件. 相比之下这种演变与其他工程领域: 尽管轮子或引擎部件通用汽车、 汽车工业并没有试图建立统一通用汽车的特点是所有体育兑换 豪华轿车、四轮驱动、经济以及"生态型"紧凑成一个单一的产品.
Trap 2, the “cost trap”: Since software is inexpensive to “manufacture”, i.e., copy and distribute to customers, database systems tend to agglomerate too much into a single package of deployment. This approach disregards the cost of maintenance, system operation, and especially the “cost” of gaining confidence in the dependability of the product comprising both correct behavior in all situations and predictable, ideally guaranteed performance. The latter is, of course, more a problem for customers (and also developers of value-added services on top of database systems) than for the vendors.  
陷阱2、"成本陷阱":由于软件是廉价的"制",即以复制、散发顾客 数据库系统往往凝聚成一个单一的一揽子太多部署. 这一做法无视维修成本、营运体系, 特别是"成本"的自信中包括了产品的可靠性,在任何情况下正确行为 并预测,表现最好保证. 后者,当然 更多客户问题(也是地产增值服务之上的数据库系统)比商贩.
Trap 3, the “transparency trap”: A “transparency trap” arises from very high-level features that hide execution costs. Historically, Algol 68 is a good historic example for this kind of pitfall. This was an extremely powerful language (for the standards of that period), and programmers could easily write code that would end up being a run-time nightmare. A similar phenomenon of hidden execution cost and thus careless programming can be observed with SQL. We teach our students that they can exploit its full expressiveness and rely on the query optimizer producing a miracle, but real life is pretty different. Efficiency should no longer be the main driving force in program designs and coding, but it should not be completely disregarded either. The concepts of a computer language should steer programmers towards reasonably efficient code rather than offering features for which there is little hope that their runtime is acceptable. 
陷阱3、"透明陷阱":一个"透明陷阱"来自很高层次的特点,躲在执行成本. 历史上,68算法语言来说这是一个好样的历史陷阱. 这是一个非常强大的语言(标准时间) 而写程式码,将很容易沦为磨合时间噩梦. 类似的现象,因此小心隐藏成本执行程式可观察的SQL. 我们教给学生,他们可以充分发挥其表现力,靠查询优化产生了奇迹, 但现实生活中是相当不同的. 效率不再主要动力设计和编码方案, 但不能完全抹煞. 计算机语言概念应该如何迈向程序员代码而非提供合理高效的特点所 很少希望自己运行是可接受的.
Trap 4, the “resource sharing trap”: By putting as much functionality as possible into a single software box with certain underlying hardware resources (disks, memory, etc.), we can dynamically share these resources for different purposes. For example, by storing videos in a relational database, video streaming can exploit the space and performance capacity of disks that hold also conventional tables and indexes during daytimes when disks are lightly used for the OLTP or OLAP part of the business. Likewise, by running business-object-style application code, in the form of user-defined functions and abstract data types (ADTs), in the database server, the 
Server’s memory and processors are dynamically shared between query and application processing. The flip side of this coin is that such resource sharing introduces interesting but horribly complex tuning problems. Disk configuration planning and disk scheduling for both video streaming and conventional data accesses are much harder than dealing with each of the two data categories separately on two disjoint disk pools. Query optimization in the presence of ADTs is an intriguing research problem, but seems like trying to solve a combined problem before we fully understand each of its constituents. 
陷阱4、"资源共享陷阱": 把尽可能多的功能,成为一箱若干基本软件硬件资源(磁盘存储器, 等等),可以动态地共享这些资源的不同用途. 例如,在一个关系数据库存储录像、 视频流可以利用的空间和容量磁碟性能,还进行常规指标在桌子和混配 磁盘是用来当儿戏或联机联机部分业务. 同样,由经营对象式申请法的形式自定义功能和抽象数据类型(Gikongoro) 在数据库服务器,服务器的内存和处理器之间共享动态查询及申请手续. 彼此钱币介绍有趣的是,这些资源共享的问题,而是整复恐怖. 磁盘配置规划和磁盘调度视频流和常规数据通道均远远要比处理 每两个数据分别在两个相交类磁盘池. 查询优化当着Gikongoro是个有趣的研究问题 但好像设法解决一个问题,然后结合我们完全理解每一个组成.
Some people may argue that we should completely give up building complex software systems, and go back to the roots of programming with every line of code documented by its mathematical properties (e.g., invariants) and not release any software package whose correctness is not rigorously verified. But we should, of course, avoid this unrealistic attitude and the “humble programmer trap”, too. 
有人会说,我们应彻底摒弃大楼软件系统 折返线每根程式码记载其数学性质(例如 变量)和不释放任何软件包的正确性并不是严格核实. 但是我们当然应该避免这种不切实际的态度和"谦虚程序员陷阱"天方夜谭.
3.2   Previous Attempts 
We are surely not the first ones who have made similar observations, have drawn potential conclusions, and have toyed with possible departures from the beaten paths. In the following we briefly discuss some of the most prominent attempts and why we believe they did not achieve their goals. 
3.2以往
我们都不是最早有类似的意见,得出结论潜力, 并有可能偏离把玩殴打路子. 在以下我们讨论一下最突出的企图,为什么我们认为他们没有达到 其目标.
Attempt 1, database system generators:  A common approach in computer science is to address problems by going to a meta level. In the specific case of database system architecture, [3] has proposed to generate customized database systems from a large library of primitive components (see also [13] for a related generator approach). The focus of this interesting but ultimately not so successful work was on storage and index management, but even in this limited context it seems impossible to implement such a generator approach in a practically viable form. Also, once such approaches take into account also cache management, concurrency control, recovery, query optimization, etc., they would inevitably realize the many subtle but critically important interdependencies among the primitive components, which makes the generation of correct and efficient system configurations awfully difficult. 
图1数据库系统发电机: 计算机科学是一种常见的方式去解决问题的梅塔水平. 在具体案件数据库系统结构、 [3]建议客户创造一个大型图书数据库系统原始成分(又见一[13] 发生器相关办法). 这个有趣的重点工作,但最终没有成功就被储存和索引管理 但即使在这方面似乎无法实施有限这种做法产生了切实可行的形式. 同时,也考虑到一旦这种做法缓存管理,并发控制,恢复,查询优化等 他们必然会实现许多微妙而重要的依存原始组件 使得一代正确而有效率的制度结构要命难.
Attempt 2, extensible kernel systems: A related approach that avoids some of the pitfalls of the generator theme has been to put core functionality into a kernel system and provide means for extending the kernel’s functions as well as internal mechanisms [5, 15, 19, 23]. This approach has led to the current generation of “data blades”, “cartridges”, and “extenders” in object-relational products [6].The extensibility with regard to user-defined functions and ADTs is working reasonably well, but the extensibility with regard to internals, e.g., adding a new type of spatial index, is an engineering nightmare as it comes with all sorts of hardly manageable interdependencies with concurrency control, recovery, query optimization, etc. We would even claim that functional extensibility also creates major problems with respect to managing the overall system in the application environment; especially predicting and tuning the system’s performance becomes horribly complex. In fact, it seems that all data-blade-style extensions are written by the database system vendor (or some of their partners) anyway. So extensibility on a per application basis appears to remain wishful thinking, and vendor-provided extensions that are coupled with the “kernel” (actually, a full-fledged database system anyway) are just additional complexity from the customers’ viewpoint. 
图2、系统内核扩展: 相关办法,避免一些陷阱发电机主题已经把核心功能成 内核系统,并提供了手段把内核的职能以及内部机制[5,15,19, 23〕. 这一做法导致了一代"数据刀片","子弹" 而"稀释"对象关系制品[6]. 对于扩展用户定义功能和Gikongoro做法行之有效, 但对于内部延伸,例如加入了新型空间指数 是一个恶梦,因为是工程的种种难以应付的相互依赖与并发控制,恢复, 查询优化、 我们会更声称等功能延展性方面的问题,也造成重大的总体管理体系 应用环境; 尤其预测和校正系统的性能变得复杂可怕. 事实上, 一切似乎数据刀片式分机均由数据库系统供应商(或者他们的一些伙伴)撤走. 所以每一个延展性应用基础似乎仍然是一厢情愿, 与供应商所提供的分机加上"内核"(其实, 正式反正数据库系统)只是个复杂的客户观点.
Attempt 3, unbundled technology: More recently several senior researchers have proposed to view database technology, i.e., our know-how about storage management, transaction management, etc., as something that is independent from the packaging of this technology into the traditional form of database systems [1, 12, 22]. A practical consequence (not necessarily fostered by but fully in line with these positions) is that we see more and more mature, industrial-strength database technology in all sorts of non-database products such as mail servers, document servers, specialized main-memory servers for switching and billing in telecommunication. In contrast to the situation ten years ago, most of these products have state-of-the-art algorithms for recovery, caching, etc. With a broad variety of such services, building applications that span multiple services becomes more difficult.  Identifying principles for federating services into value-added information systems is subject of ongoing and future research. 
图3分解技术:最近几期的高级研究员提出数据库技术,即 我们的诀窍约仓储管理、交易管理等 看成是独立于这一技术引入传统包装形式数据库系统[1、 12,22〕. 一个现实的结果(但不一定完全符合培育这些岗位),我们看到越来越 更成熟、产业强度数据库技术种种非数据库产品如邮件服务器,文件服务器, 专门主存储器和服务器转换电信帐单. 相较于十年前的情况下,这些产品已美国最先进的算法复苏缓存、 等提供多种服务,建设跨多个应用服务变得更加困难. 联邦原则确定服务成增值信息系统,是当前和今后的研究课题.
The third approach, unbundling database technology and exploiting it in all sorts of services, is closest to our own position. However, the previous position papers have not said anything about the future role of database systems themselves as a package of installation and operation. We aim to redefine the scope and role of database servers, and outline also a possible path towards a world of composable “RISC”-style data management blocks. 
第三,分拆数据库技术,开发各种资讯服务,贴近了自己的位置. 但是 以往立场文件没有谈及未来的作用数据库系统本身作为一套 安装和操作. 我们的目标是重新确定范围和作用,数据库服务器, 纲要还可能走上与世界KD-FedWrapper"的RISC"式的数据管理组件.
4.  Towards RISC-style Components 
In computer architecture, the paradigm shift to RISC microprocessors led to a substantial simplification of the hardware-software interface. We advocate a similarly radical simplification of database system interfaces. Our proposal calls for building database systems with components that are built with RISC philosophy in mind. The components need to be carefully designed so that they enable building of richer components on top of the simpler components while maintaining a clear separation among components. Thus, each RISC-style component will have a well defined and relatively narrow functionality (and API). There is a need for “universal glue” as well to enable components to cooperate and build value-added services. 
 4. 走向的RISC式电脑组件建筑学 
范式转向导致了大幅简化的RISC微处理器的软硬件接口. 我们主张激进同样简化数据库系统接口. 我们提出要求建立数据库系统组成,是金子的RISC哲学记. 部件需要加以精心设计,使他们更加丰富,使建设上的简单部件 同时保持清醒的分离组件组成. 因此,每个的RISC式组件将有明确界定和相对狭小的功能(短片). 有需要"通用胶水"也使组件合作,建立增值服务.
RISC data-management components appear attractive for us for three reasons. First, such components, with their relatively narrow functionality (and API), give us some new hope for predictable behavior and self-tuning capabilities. Second, the narrow functionality, coupled with the ability to build value-added services “on-top” makes such components far more attractive for varied information applications of today compared to a monolithic “universal” database management system. Third, even if we only build a monolithic database management system and no other data management services, building it using RISC data-management components will make it far more predictable and tunable than today’s database management systems. All these benefits apply equally to RISC-style componentization within a database system as well as across different kinds of data managers for IT systems in the large. 
的RISC数据管理组件出现三个理由对我们有吸引力. 第一,这种元件,其功能相对狭小(空气) 给我们一些新的希望和预见行为的自我调节能力. 第二,缩小功能, 加上能力建设增值服务"顶"这样就吸引更多不同成分的申请资料 今天比铁板"通用"数据库管理系统. 第三,即使我们只是建立一个单一的数据库管理系统,又没有其他资料管理服务 它采用的RISC建设数据管理组件将更为明确和可调比今天的数据库管理系统. 同样适用于所有这些好处的RISC型数据库系统组件以及在全国不同类型的数据 资讯系统经理大.
RISC philosophy for database systems:  
We will illustrate our intuition on RISC data components by focusing on querying capabilities of the database system.  The simplest class of query engine is a single-table selection processor, one that supports single-table selection processing and simple updates with B+-tree indexing built-in. Such a single-table engine can be used in many simple application contexts. Indeed, with transactional support, such a query engine provides an ideal platform that can be used by many applications. In fact, until recently, even SAP R/3 essentially used the underlying DBMS as a storage engine of this kind. Another advantage of such a selection processor is that it can be used with a programmer-friendly API, with little or no knowledge of SQL. Another class of query engine that is quite attractive is the Select-Project-Join (SPJ) query-processing engine, suitable for OLTP and simple business applications. Such a RISC-component service can build on top of the simpler single table selection processor, much like how RDS was layered on RSS in System-R. The theory and performance of a SPJ query processor is much more clearly understood than that of a full-blown SQL query engine. In fact, the simplicity of the System-R optimizer has led to a deep understanding of how to process such queries efficiently, with join ordering, local choice of access methods, and interesting orders being the three central concepts. Adding support for aggregation to the SPJ engine, through sorting, data-stream partitioning (possibly hierarchical) capabilities, and more powerful local computation within a group (e.g., see [9]) brings it closer to requirements of decision support applications and specifically  OLAP. Furthermore, note that the support for aggregation needs to be stronger than what SQL supports today. Yet, layering enables us to view the optimization problem for SPJ+Aggregation query engine as the problem of moving (and replicating) the partitioning and aggregation functions on top of SPJ query sub-trees. The challenge in designing such a RISC-component successfully is to identify optimization techniques that require us to enumerate only a few of all the SPJ query sub-trees. Finally, one could implement a full-fledged SQL processor that exploits the SPJ+Aggregation engine. Despite building the same old SQL engine, such an approach offers the hope of decomposing the optimization problem and thus the search complexity. Although in principle such a layered approach can result in inferior plans, it offers the hope of controlling the search space for each layered component much more tightly. Furthermore, the ad-hoc-ness in many of the commercial optimizer search techniques leave us far from being convinced that a global search would necessarily lead to better solutions in most cases. The above discussion illustrates how database technology may be re-packaged into layers of independently usable and manageable components. It should be noted that the vision that such “reduced-functionality” data managers will be available is implicit and anticipated in the OLE-DB API. However, provisions in the API have not led to products with such components yet.  
数据库系统的RISC理念: 我们会说明我们对直觉的RISC数据组件围绕这个数据库查询系统的能力. 最简单的查询引擎类是单表选择处理器、 其中,支持单一表和简单加工遴选与更新B+树索引内置式. 这种单引擎表可用于许多简单应用情境. 事实上,随着交易的支持,这质疑引擎提供理想的平台,可用于许多应用. 事实上,直到最近,甚至SAP单元基本上用于存储基本数据库,作为这种发动机. 选择这样一个处理器的另一个好处是,它可以用来与程序员商短片 很少或根本不知情的SQL. 另一类是颇具吸引力的发动机质疑责项目投(SPJ)查询处理引擎 适合联机及简单的商业应用. 这样的RISC组件服务之上可以建立简单表选择单一处理器, 很像是如何分层对RSS在铁路系统住宅. 理论与表现SPJ查询处理器是一种更为清楚明白得多,一发不可收拾的SQL 查询引擎. 事实上, 简单的系统优化研究导致深刻了解如何有效地处理这些问题, 参加订购与当地接入方式的选择,而有趣的三个核心概念是命令. 加入支持聚集到SPJ引擎,通过分拣、数据流分割(可能分层)能力 一个更强大的运算和地方组(如 见[9])带来更接近决策支持应用和具体要求联机. 另外,注意到需要以强大的支持聚集比今天的SQL支持. 然而, 层叠使我们看问题SPJ+聚集优化引擎的问题提出质疑(复制) 板聚集功能之上SPJ质疑分树木. 设计这种挑战的RISC组分是确定优化技术,成功地要求我们只列举 所有SPJ查询数分树木. 最后,人们可以实施全面的SQLSPJ+处理器,利用聚集引擎. 尽管旧建筑物的SQL引擎 这种做法是希望提供分解问题,从而优化了搜索复杂. 虽然在原则上这种做法可能导致劣分层图 它提供了搜索,希望能控制每一个层次组成的空间更为严密. 此外, 特设烦躁许多商业技巧搜索优化离开我们远远确信全球搜索 必然会导致更好的办法在大多数情况. 上述讨论说明数据库技术,可重新包装成易于管理、层层独立可用零件. 应当指出,这种构想"降功能"数据管理者可预期的是,在隐性 <欧勒-分贝短片. 不过,条文并没有导致空气污染的产品,但这些部件.
In a similar vein, even the architecture of storage managers could be opened up for RISC-style redesign. A number of key mechanisms like disk management, caching, logging and recovery, and also concurrency control are undoubtedly core features in every kind of storage manager. But when we consider also the corresponding strategies that drive the run-time decisions of these mechanisms, we realize that different data or application classes could prefer tailored algorithms, for example, for cache replacement and prefetching, rather than universal algorithms that need more explicit tuning. For example, a media manager that stores video and audio files and needs to provide data-rate guarantees for smooth playback at clients would differ from the storage manager underneath a relational selection processor. Similarly, a semi-structured data storage manager that is geared for variances in record lengths and structures may choose implementation techniques that differ from those of schematic table storage. Finally, we could argue that even an index manager should be separated from the primary-data storage. This would make immediate versus deferred index maintenance equal citizens, with the latter being the preferable choice for text or multimedia document management. The price for this extreme kind of specialization and separation would be in additional overhead for calls across components; in the extreme case we may need an explicit two-phase commit between the primary-data and the index storage manager. However, this price seems to be tolerable for the benefit of removing tuning options that a universal storage manager would typically have and a much better chance of automating the remaining fine-tuning issues because of the smaller variance in the per-component workload characteristics. 
在同样,连储存管理架构可开垦的RISC式重新设计. 一批重点像磁盘管理机制、缓存、伐木、回收、 无疑又并发控制核心特点各种存储经理. 但是,当我们考虑战略也相应驱动运行时决定这些机制 我们认识到不同的数据或应用班可以选择适合的算法,例如置换、预作缓存, 通用算法,而不需要更加明确校正. 例如 商店经理说,媒体影音档案需要提供数据速率为保证客户顺利回放 仓库经理将不同于桥下关联选择处理器. 同样, 半结构数据存储,是面向经理差额记录为可选择长度和结构,实现技术 不同于示意图表存储. 最后,我们甚至可以说,一个经理指数应分开初级数据存储. 这将使即时指数维持平等与递延公民 而后者是最好的选择文本或多媒体文件管理. 这样的代价极端专业化和分离将额外开销为全国电话零件; 在极端情况下,我们可能需要一个明确的两个阶段之间的主要承担数据存储与经理指数. 但是 这似乎是可以承受的价格为全民清除校正方案经理通常存储 有一个更好的机会和自动化其余微调问题,因为较小的变异7877组件 工作量。
The “RISC”-style componentization has some important ramifications. First, such componentization limits the interactions among components. For example, the SPJ query engine must use the “selection processor” as an encapsulated engine accessed through the specific APIs. The SPJ engine will have no knowledge of the internals of the selection processor except what can be gleaned via the API published for any consumer of the selection processor. Thus, the SPJ processor will know no more or no less than any other consumer of the “single-table selection” processor.  Second, the API provided by any such component must expose at least two classes of interfaces: functionality as well as import/export of meta-information. For example, in the case of a selection processor, the functionality interface enables specification of a query request (table name and a filter on a column of the table). The import/export interface can expose to external components limited information that determines performance of the selection processor. In particular, the selection processor (specifically, the optimizer) should support an interface to return estimated selectivity of (predicates in) a query as well as the estimated run-time and resource consumption of executing the query. Note that obtaining reasonably accurate run-time estimates is important not only for query optimizers to choose an execution plan but also for deciding what priority a query should be given or whether it is worthwhile to submit it all (an issue that frequently arises in OLAP). Conversely, through an import interface, we can empower the application to specify parameters (e.g., response-time or throughput goals) that influence query execution.  
"的RISC"式将有重大影响的组件. 首先,这些组件之间的界限的互动元件. 例如,SPJ查询引擎必须使用"选择处理器"作为一个封装引擎浏览具体的宣传. 该发动机将SPJ不知情内部选拔处理器除了可以透过战绩 环保署公布任何消费者选择处理器. 因此,了解不多或SPJ处理器将不低于其他任何消费者的"单表选择"处理器. 二、空气等提供的组件必须揭露至少有两类接口: 功能以及入口/出口汇总资料. 例如,对于选处理器, 介面规格的功能,使查询请求(表名称和过滤表一栏). 输入/输出接口可为外部元件有限公司资讯揭露,决定选用处理器的性能. 特别挑选处理器(具体 优化了),估计应该支持接口返回选择性(谓词)的质疑以及估计 磨合时间和资源消耗执行查询. 注意到获取相当准确磨合时间估计质疑optimizers不仅是重要的执行计划,而是选择 还有什么疑问,应优先考虑是否值得提交全体( 题频频出现联机). 相反,通过一个入口介面,可以授权申请指定参数(例如 响应时间或吞吐量目标)影响查询执行.
RISC philosophy for IT systems in the large:  
For building IT systems in the large, we obviously need more building blocks than the various database services discussed above. So we need to apply similar considerations also to web application servers, message queue managers, text document servers, video/audio media servers etc. Each of them should be constructed according to our RISC philosophy, and all of them together would form a library of RISC-style building blocks for composing higher-level, value-added information services. We have to make sure that the complexity that we aim to reduce by simplifying the components does not reappear at the global application level. Research into principles of service composability should thus be put high on our community’s agenda (a serious discussion of these issues is beyond the scope of this paper). 
它的RISC系统大哲学:科技系统的大型建筑、 我们显然需要更多的积木比上面所讨论的各种数据库服务. 所以我们需要类似的考虑也适用于Web应用服务器、消息队列经理文文件服务器、 视频/音频媒体服务器等每个人应根据我们的RISC建成哲学 而所有这些一起组成了图书馆的RISC式积木组成的高层次、增值信息服务. 我们已经使我们的目标是减少复杂性简化部件不再现 在全球应用水平. 研究服务原则composability因此应摆在我们社会的议程(认真的讨论这些 问题已超出本文).
The challenge in adopting a RISC-style architecture is to precisely identify and standardize the functionality and import/export interfaces for each component such that the following objectives are met:  (1) these interfaces can be exploited by a multitude of applications, (2) the performance loss due to the encapsulation via the API results is tolerable, and (3) each individual component is self-tuning and exhibits predictable performance. The last point is worth reemphasizing since it attempts to explain as to why RISC-style components are of great importance. It is only when we construct components that can be “locally” understood and explained, that we can hope to achieve predictability of performance and the ability to tune them as a component. As an example, we feel that it is much easier to understand the behavior (and indeed theory) of a single-table selection processor, or that of an SPJ processor that is built using only the narrow interfaces exposed by a selection processor. Of course, use of such narrow interfaces and creation of limited functionality can hamper performance, but as long as the degradation is marginal or even moderate, the need for predictable performance and self-tuning far outweighs such concerns given the cost point of today’s commodity hardware. We now describe some of the important ramifications of the architecture we are espousing. 
采用的RISC挑战式建筑恰恰是要找出规范功能和进口/出口每界面 这种成分达到以下目标:(1)接口可以被这些众多的应用, (二)因业绩亏损的结果是可以容忍的空气经封装、 (三)是每一个人组成的自我调节和展品预测业绩. 最后一点是值得,因为它企图再度宣扬解释为何的RISC式元件均十分重要. 而只有当我们能够建构元件"当地的"理解和解释 我们希望能做到的预见性和表现能力作为调组成. 为例, 我们觉得这是很容易理解的行为(乃至理论)单表选择处理器、 或者说是建立一个SPJ处理器只用狭隘接口处理器曝光遴选. 当然,用这种狭隘的接口功能有限,可以阻碍创造业绩 但只要是轻微甚至中度退化、 必须明确表现和自我调节的成本远远大于这个角度给予关注今天的商品硬件. 我们现在描述的一些重要影响,我们倡导的建筑.
4.1 Notable Departures from Today’s Architectures 
The new departure that we advocate in this paper follows, in spirit, the earlier approaches of system generators and unbundling (referred to as Attempts 1 and 3 in Section 3.2). However, in contrast to these earlier proposals, we consider the appropriate packaging as a vital aspect of the overall architecture. In comparison to the modules considered by a generator, our RISC-style components are much coarser and ready for self-contained installation, thus avoiding the pitfall of the many subtle inter-dependencies among overly fine-grained modules. Similarly, we go beyond the unbundling theme by striving for components that are self-contained also in terms of predictability and self-tuning, and we aim to reduce the complexity of components and are willing to lose some performance to this end. The following simplifications would be important steps in this direction. 
 4.1显着背离当今的新建筑,
我们主张离境本文如下,在精神上、 较早系统发电机和分拆方式(简称为试图在第1和3320). 然而,相对于这些先前建议,我们考虑适当的包装,作为一个重要的方面整体建筑. 相对这个单元由电机、 我们的RISC式元件非常粗和准备自足安装 从而避免了许多微妙的陷阱跨属地之间过于细粒度组件. 同样, 我们超越分拆为主题的部件是自足也从预见性和自校正、 我们的目的是要减少复杂零件并愿意为此失去了一些业绩. 以下是简化这一方向的重要步骤.
Support only for limited data types: The mantra in our new architecture is predictability and auto-tuning. This strongly argues against support for arbitrary data types. Instead, database systems should focus on the data types that they are best at, namely, tables with attributes of elementary type. Essentially this means going back to the roots of database systems, business data. There is no truly compelling reason for supporting the entire plethora of application-specific and multimedia data types. The initial motivation for adding all these features has been to ease data integration. But integration does not imply universal storage. In fact, what replaces the need for universal storage are data exchange protocols, advanced APIs, and component models that enable specialized storage/query systems to federate with traditional databases, e.g., OLE-DB/COM, EJB, or emerging XML protocols. To reiterate, limiting the responsibilities of the database system to data in table format makes the system much more manageable and give us a significantly better handle on the, still remaining and all but trivial, (automated) tuning problem. 
只支持有限的数据类型:在我们的口头禅是预测性和新结构自动校正. 强烈反对这种论证类型支持任意数据. 反之,数据库系统应集中数据类型,他们最擅长的,即 桌子属性初级型. 基本上这意味着回到根数据库系统业务数据. 目前没有真正的理由支持整个展演申请特定类型和多媒体数据. 最初加入的动机已经缓和这些特征数据集成. 但一体化并不意味着全球存储. 其实,取代必须普遍都储存数据交换议定书,先进短片、 并组成专门的楷模,使存储/查询系统、联邦与传统数据库,例如ole-db/com,EJB中, 新兴的XML或议定书. 再次, 责任限制的资料库系统,以表格式使系统更易于管理,给 我们较好地处理了明显的,但一切仍微不足道,(自动化)调谐问题.
No more SQL: As mentioned in Section 2, there is no demand for much of the complexity of full-fledged SQL, nor for the “Select-From-Where” syntactic sugar that has outlived its original motivation. We advocate a streamlined API through which programs essentially submit operator trees to the database server modules. In the example above, a selection processor will accept operator trees that only contain scan and selection; an SPJ processor will be able to process requests for processing trees that contain selection, projection, and join operators. For convenience, these operator trees may be linearized. Moreover, they should avoid the complex forms of nested and correlated subqueries that make current SQL hard to master. However, only changing the syntactic form of SQL is not enough. The language constructs themselves have to be simplified. Given that so many intelligent people have already argued for a simplification for the past two decades without success, we are convinced that the key for simplification lies in substantially limiting the functionality and expressiveness (which most of the previous attempts did not want to compromise).  
不多的SQL:如上条第二款 并无需求大量复杂全面的SQL, 也为"责--从哪里",已失去其原有的句法糖动机. 我们主张通过精简短片节目基本上算树提交给数据库服务器模块. 在上述的例子,遴选处理器将接受操作,只包含扫描与选择树种; 一个SPJ处理器能加工工艺要求树木含有选拔、投影、入营. 为方便起见,这些树可算线性. 此外,他们应该避免复杂表格嵌套和相关的SQL语句,使目前难以掌握. 不过,只有改变形式的SQL句法是不够的. 建构自己的语言来加以简化. 既然有那么多聪明人早已主张简化为近二十年来一直没有成功, 我们深信,关键在于大大限制了功能简化及表现(其中大多数的 以往不愿妥协).
Disjoint, manageable resources:  There should be no dynamic resource sharing among components. This simplifies performance tuning and also provides additional isolation with regard to software failures. For example, when building a news-on-demand service on top of a video server, a text document server, and an SPJ table manager (for simple business issues such as accounting), each of these servers should have its own, dedicated hardware for simpler tuning (although this rules out additional cost/performance gains via dynamic resource sharing). In the extreme this could imply, for example, that, within a table manager, data pages and index pages should always reside on disjoint disks (which is a commonly used rule of thumb anyway) for the sake of simplicity and at the modest cost of a few additional disks. 
相交、管理资源:应无动力资源共享组件. 这简化并提供额外的隔离性能调整方面的软件故障. 例如,当建立一个消息都对视频服务器的服务之外,文文件服务器、 SPJ表和经理(诸如会计业务简单) 每个这些都应有自己的服务器, 专用硬件校正简单(虽然这排除额外成本/收益表现经动态资源共享). 这可能意味着,在极端,例如,在一张桌子经理 资料页及索引页始终居于交盘(即常用凭经验无论如何) 为求简朴,在适度的额外费用几盘.
Pre-configuration: Each RISC-style data management component could be pre-configured for say five or ten different “power levels” with regard to feature-richness (e.g., "basic", "standard", "advanced", and "full") as well as performance and/or availability levels. Along the latter lines one could support a small spectrum of data server models such as "good for mostly-read workloads", "good for small to medium data volumes". This pre-configuration approach promises a viable compromise between "one size fits all" and complete freedom for configuration and feature selection at the risk of facing a monstrous tuning problem. In many cases the need for customization and tuning could be completely eliminated, at least at installation times. Note that this trend towards pre-packaging can already be observed in the IT industry, definitely as far as marketing and sales are concerned, but to some technical extent also in OS installation. However, database systems are still engineered mostly monolithically for the largest possible feature set. We advocate that the idea of supporting a limited number of different "models" should already be a major consideration in the design and engineering of data management software. 
预先配置: 每次的RISC式数据管理组件可以预先配置为5年或10个不同的"权力级"对于描写丰富 (例如,"基本"、"标准"、"先进"、"全"),以及表现和/或供应的水平. 后者可以支持线路沿线小谱数据服务器模式,如"好事多阅读工作量" "好的中小型数据卷". 这个预配置一个可行的折衷办法诺言"一刀切",随意配置和特征选择 在面临一个可怕的风险校正问题. 在许多情况下需要定制和可调谐完全消除,至少安装倍. 看到这个趋势预包装已经可以看到,在IT产业 据销售绝对是对的,但在某些技术的程度还安装操作系统. 不过,大多单片数据库系统仍在策划的最大特点,集播出. 我们主张支持有限数量的想法不同的"模型"应该已经是一大考量 工程设计和数据管理软件.  
4.2 Prerequisites of Success 
Need for “Universal Glue”: The problem of composing different data managers into value-added application services is, of course, much more difficult than for standard consumer electronics. As noted earlier, we have to make sure that the complexity that we aim to reduce by simplifying the components does not reappear at the application layer and may become even more monstrous than ever. Simple interfaces with limited functionality and standardized cross-talk protocols are a fundamental prerequisite for composability and manageability of composite systems. Thus, higher-level application servers do need some standardized form of middleware such as OLE-DB or EJB to be able to talk to each underlying data server in a uniform manner. Such “universal glue” is available today. In particular, it is now a standard exercise to coordinate distributed transactions across arbitrary sets of heterogeneous servers by means of standardized 2PC protocols. So one important historical reason for putting all mission-critical data into a centralized, “universal” database for consistency preservation has become obsolete. Even when the classical ACID properties are inadequate for the application at hand, workflow technology is about to become mature and can reliably orchestrate activities on arbitrary servers within long-lived business processes. This is not to say that each and every technical aspect of how to combine arbitrary services into transactional federations is perfectly understood (e.g., see [1] for open issues), but most of the issues are settled and for the remaining ones research solutions are at least within reach.  
成功的必要前提420"胶水普及": 不同的数据管理问题,谱写成增值应用服务,当然 艰难得多标准电子消费品. 如前所述, 我们已经使我们的目标是减少复杂性简化部件不再现 在应用层,可能比以前更加可怕. 简单的介面功能有限、规范化串扰议定书是一项基本前提和规范composability复合系统. 因此, 上级需要做一些应用服务器中间件等形式规范欧勒-分贝还是能谈的EJB 每个基本数据服务器统一. 这种"普遍胶水"是6000万. 尤其 现在是一个标准的运动,以分布式交易协调全国任意套异构服务器通过规范化 2PC议定书. 这样一个重要的历史原因,把所有重要数据到中央、 "通用"数据库一致性保存已经过时了. 即使古典酸适用于性能不足,另一方面 工作流技术是成熟、可靠的配器可以任意服务器内活动长寿业务流程. 这并不是说,每个环节的技术服务如何结合成任意交易联合会 完全理解(例如,开放式问题见[1]) 但是大部分问题的解决,并为研究解决其余至少达成.
Apply Occam’s Razor:  Following Occam’s philosophy, we should be extremely careful, even purists, in selecting which features a data manager should support and which internal mechanisms it needs to have to this end, aiming to minimize the complexity of both interfaces and internals. Often certain involved features can be implemented on top of a RISC data manager with a moderate loss of performance and a minor increase in programming efforts. So the gain from using a database system would be slightly reduced, but, at the same time, the pain of having to manage a feature-overloaded, complex system could be drastically alleviated. So the win is in improving the gain/pain ratio of database technology. For example, one could argue that null values with all their ramifications should be implemented by the application rather than the underlying data manager: the application understands its specific semantics of missing or undefined values much better, and this would also eliminate a multitude of null-related, often tricky rewrite rules in the data manager’s query optimizer.  
适用奥克姆的剃刀:奥克姆的哲学,我们应该要很谨慎,甚至类似, 选择其中一个特征数据经理应当支持和内部机制都需要为此 为了减少复杂性和内部两种界面. 常常涉及某些特征可以再加一个经理的RISC数据表现温和损失 轻微上升和编程努力. 所以从一个数据库系统将使用略有减少,但在此同时, 痛经管理特征超载、复杂系统可以大大缓解. 所以赢得胜利是在改善/疼痛比数据库技术. 例如 可以说,一切后果无效值应实施的应用而不是潜在 数据经理:了解其具体应用语义学遗失或未定价值观好得多, 而这也消灭了许多无效的,常常刁钻重写规则的数据经理查询优化.
Likewise, we should avoid an unnecessarily broad repertoire of implementation mechanisms within a single-table, SPJ, or SPJ+Aggregation processor. Often certain mechanisms improve performance by only moderate factors and only in special cases, but significantly add to the complexity of system tuning. For example, hash indexes and hash-based query processing (including the popular hash joins) are probably never better than a factor of two compared to nested-loop variants (including those with index support etc.) or sort-merge-based query processing [14]. Similar arguments could probably be made about pipelined query execution (especially on SMPs with very large memory where the performance impact of pipelining is noise compared to that of data parallelism and may even hamper processor-cache effectively), fancy notions of join indexes etc.. 
同样,我们应该避免不必要的曲目广泛实施机制单一表SPJ,或聚集SPJ+处理器. 往往只表现某种机制健全的因素,只有在特殊情况下温和、 但大大增加了复杂系统校正. 例如 散列索引以及散列为基础的查询处理(包括流行哈希加入)大概不会好过了两个因素 比起巢回路变种(包括支援指数等)或排序合并的查询处理[14]. 类似的论点,就可能成为流水线执行查询(特别是对开关电源有很大的记忆表现 流水噪音的影响是并行的数据相比,甚至阻碍处理器缓存有效) 花式加入索引等概念.
Need for a Self-Tuning Framework: A major incentive for moving towards RISC style data managers is to enable auto-tuning of database components. As explained earlier, tuning must consider the relationship between workload characteristics, knob settings, and the resulting performance in a quantitative manner. Therefore, it is not surprising that the most promising and, to some extent, successful approaches in the past decade have been based on mathematical models and/or feedback control methods (e.g., to dynamically adapt memory partitioning or multiprogramming levels to an evolving, multi-class workload). Unfortunately, these models work only in a limited context, i.e., when focusing on a particular knob (or a small set of inter-related knobs). Attempting to cover the full spectrum of tuning issues with a single, comprehensive model is bound to fail because of the lack of sufficiently accurate mathematical models or the intractability of advanced models.  This is why limiting ourselves to using only RISC data managers is so important: we no longer need to aim for the most comprehensive, elusive performance model, and there is hope that we can get a handle on how to auto-tune an individual data server component. It is much easier to tune a system with a less diverse workload and less dynamic resource sharing among different data and workload classes. Of course, the global tuning problem is now pushed one level above: how do we tune the interplay of several RISC data managers? Fortunately, a hierarchical approach to system tuning appears to be more in reach than trying to solve the entire complex problem in one shot. The main steps of such a hierarchical self-tuning framework are: 1) identifying the need for tuning, 2) identifying the bottleneck, 3) analyzing the bottleneck, 4) estimating the performance impact of possible tuning options, and 5) adjusting the most cost-effective tuning knob. 
需要进行自我调整框架: 一大诱因的RISC风格走向数据管理是使自整数据库组成. 如前所述,必须考虑到整关系工作量特色旋钮场合 并由此定量地表现. 因此,这是不足为奇的最有前途的,并在一定程度上 成功的做法,在过去十年一直基于数学模型和/或反馈控制方法(例如, 为了适应动态存储器实现多层次分割或演变、多级工作量). 可惜,这些模型只是在有限的工作范围,即 当围绕某个旋钮(或一小套互相关把手). 企图进行全面的调整问题与单一 综合模式是注定要失败的,因为缺乏足够精确的数学模型或先进棘手 型号. 这就是为什么只局限于使用的RISC数据管理是那么重要: 我们不再需要为宗旨的最全面的、难以捉摸的表现模式 并希望我们能有一个如何处理自动调个人数据服务器组成. 这是非常容易的调制度,以减少工作量,少多样不同动态资源共享 数据和工作量班. 当然,现在的问题是全球调谐推一层以上: 怎样调几个相互作用的RISC数据管理者? 幸好 等级制的方式似乎更能达到调谐比设法解决整个复杂问题 在一枪. 这种分级的主要步骤自我调谐范围是:1)找出需要改善, 2)找出瓶颈,3)分析瓶颈,4)估计可能影响业绩调谐选择 5)调整最具成本效益的调谐旋钮.
The hierarchical nature of such a self-tuning procedure is perfectly in line with good practice for manual, or we should better say intellectual, tuning (e.g., [16, 20, 21]). In particular, our approach also adopts a “think globally, fix locally” regime. Further note that mathematical models have been and remain to be key assets also in the practical system tuning community (e.g., [11]). The key to making the mathematics sufficiently simple and thus practical lies in the reduced complexity of the component systems and their interfaces and interplay. We believe that there is a virtue in engineering system components such that their real behavior can be better captured by existing mathematical modeling techniques, even if this may lead to some (tolerable) loss of high-end features and efficiency. The true gain lies in the better predictability and thus tunability and manageability of systems. 
这种层次性的自校正程序是完全符合好的实践手册 或者应该说更好智力、调谐(如[16,20,21]). 特别是我们的态度也是采取了"放眼全球,本地固定"制度. 进一步注意到与数学模型已经资产也仍是关键系统在实际调谐社区 (例如[11]). 关键,从而使数学够简单实用的复杂性在于减少系统组件 接口和相互作用及其. 我们相信有一种美德,在工程系统组成,其行为可以更好地捕捉 现有数学建模技术,即使这可能导致一些损失(忍受)高端特点和效率. 真实的谎言得到更好的规范性和预见性,从而调谐系统.
5. Towards a Research Agenda 
5.1 Evaluation of Success 
How should we evaluate the viability and success or failure of the advocated architecture? Actually evaluating an architectural framework would entail designing, building, and operating nontrivial IT systems, which obviously is way beyond the scope of a paper (especially a semi-technical vision paper like this one). So we merely give a rough sketch of how we as a research community may proceed along these lines. 
 5. 迈向51世纪议程
5.1评价成功 
如何评估可行性和成败的主张建筑? 其实评价一个框架将导致建筑设计、建设和经营体制是平凡, 这显然是远远超出了纸张(尤其是半导体技术的眼光这样一个文件). 所以我们只是提供一个轮廓,如何为社会可以着手研究这些线路沿线.
The best measure of success of a RISC-style database system architecture would be to demonstrate the usefulness of the components in a variety of data management scenarios. To start with, we should be able to develop data management components that work well as scalable traditional OLTP systems as well as the basis for OLAP-style data management services. Such systems are likely to use the SPJ query processor and the SPJ+Aggregation query processor, respectively.  
最成功的一个举措的RISC型数据库系统结构将展示有用成分 在各种数据管理方案. 首先, 我们应该可以开发数据管理工作的组成部分,也是传统的联机系统,以及可伸缩 依据联机式数据管理服务. 这种系统可能使用SPJ查询处理器查询处理器和SPJ聚集+分别
Incidentally, recall that the first generation of OLAP services extensively used “multi-statement” SQL, i.e., they fed only simple queries (SPJ with aggregation) to backend servers to ensure that performance characteristics are predictable since database optimizers have been known to behave erratically for complex SQL queries (which should not really be a surprise given that a typical query optimizer is a large bag of tricks).  
无独有偶,记得第一代联机服务广泛应用于"多国"的SQL,即 他们只是单纯喂疑问(SPJ与聚集)后端服务器,以确保性能特点是可以预测,自数据库 optimizers历来表现不寻常复杂的SQL查询(真不该因为一个意外 一个典型的查询优化是一大包伎俩).
Another interesting instance of services is metadata management. Such a service is distinguished from traditional OLTP and OLAP in requiring more elaborate conceptual data models, but with relatively simple needs for querying and scalability (for large data volumes).  Yet another popular class of services is management of e-mail data.  Mail servers require fast insertion of mail messages and “mostly fast” access when queried by attributes. A key characteristic of mail data is that it is sparse, i.e., not all attributes are present and records are of widely variable length. It would be intriguing to consider an SPJ query engine and a separate indexing engine as a mail server’s base components. In contrast to traditional relational system designs, however, there should be no limiting necessity of a schema in this setting.  Other data services of interest, whose architecture would be worthwhile to re-examine with this paper’s philosophy of RISC building blocks in mind, are marketplace data servers (e.g., in E-Bay) or large-scale multimedia information servers for news-on-demand etc. 
另一个有趣的例子是数据管理服务. 这种服务有别于传统的联机和OLAP概念要求更详细的数据模型 但需求相对简单、可扩展性的质疑(大数据量). 又一热门服务管理阶层电子邮件数据. 邮件伺服器需要快速插入邮件讯息、"多快"准入当质疑属性. 主要特点是,它是稀疏的邮件数据,即 目前,并非所有的属性都具有普遍变长记录. 这是一个耐人寻味考虑SPJ查询引擎和索引引擎作为一个单独的邮件服务器基地 元件. 相对于传统的关联系统设计,但是不应局限于一种模式,在此设置的必要性. 其他数据服务感兴趣, 其建筑值得重新审视本报的哲学的RISC积木记、 有数据服务器市场(如电子湾)、大规模多媒体信息服务器消息都对等
5.2 Research Opportunities  
We wish to encourage researchers to make the system architecture of database technology and the simplification of component interfaces as well as internals (again) a top-priority item on their agenda. Although most of the problems with today’s architecture that we have identified refer to industrial products, we believe that the impetus for a new departure must come from academia as product architects and developers are way too busy in their time-to-market issues. To be fair, the database system industry has a lot of stake in maintaining existing products and market shares, and has too little leeway for radical departures. For academic researchers we see ample opportunities of system-oriented exploration that can hopefully drive the community towards a better overall architecture. It is crucial, however, already for component prototyping and systematic experimentation that this research avenue heads for simpler, smaller-scale, RISC-style building blocks.  
5.2研究机会,我们希望鼓励研究人员作技术和数据库系统结构简化 接口以及内部组件(再)头等议事日程. 虽然大部分的问题用今天的建筑,我们发现指工业品 我们相信,推动新产品出境必须来自学术界、商程师 太忙闲暇时间对市场问题. 平心而论,数据库系统有很多业保持现有产品和市场的股权股 激进的余地也太少班. 学术研究者,我们看到许多机会系统面向探索社区建设,有望在整体走向更美好 建筑. 这是至关重要的,但是,已经成型的组件和系统试验,这为研究巷头简单,规模较小, 的RISC式积木.
Along these lines, we propose making major efforts towards the following research (and, to some extent, sociological) challenges: 
  * Make viable an open, worldwide testbed for RISC-style data-management components to which even small research teams can contribute.  

*Work out lean APIs for each of the most important RISC-style components following our discussion of Section 4.1 on different kinds of query processors and storage managers.  
*Encourage a worldwide competition for the “best” instantiation of each of these building blocks, for example, with regard to certain standard benchmarks or common test suites for data mining and Web applications. To make this a real challenge and avoid compromising our goal of simplified and auto-tuned components, the rules should limit the code size of each component, limit its footprint, and disallow any kinds of tuning knobs other than what the component does internally based on its own self-assessment.
*To ensure that individual components are not tailored to other components by the same team or even tailored to specific benchmarks, all components that are registered with the worldwide testbed must be able to correctly cooperate, through their official APIs, with all other components from all other teams. 
*Identify more precisely the “universal glue” for the above kind of open test bed. Obviously this is already required for setting up the test bed. A bootstrap approach could be that one team provides an initial instantiation of the necessary middleware services and the most important components as a basis for other teams to contribute and plug in individual components or gradually replace some of the “glue” services (e.g., a two-phase commit protocol). 
在这些方面,我们提出以下的研究作出了重大努力(以及某种程度上社会学)的挑战: 
*提出可行公开,全世界的RISC试点式数据管理组成研究团队,甚至可以小.
 *每出短片精益最重要的RISC式元件4.1以下各组讨论 多种查询处理器和存储管理. 
*鼓励世界比赛的"最佳",这些实例每个积木,例如 对于某些共同标准或基准测试数据挖掘和Web应用一四. 这确实是一项挑战作出妥协,并避免目标简化、自动调谐组件 规则应该限制每个组件代码大小、限制其足迹, 不准任何形式的调谐把手以外什么成分是否基于自己内部的自我评估. 
*确保其它各组成成分不适合由同一组甚至针对具体 基准,所登记的所有部件必须能正确世界范围试验合作 透过其官方短片,其他所有部件全部从其他球队. 
*找出更准确的"全民胶水"为上述种公开测试床. 显然这已设置所需测试床. 举一个办法,可以提供一组初步的实例和最需要服务的中间件 重要组成部分,作为与其他球队贡献堵塞或个人逐步取代某些组件 "胶水"服务(例如,一个两阶段提交协议).
Once the envisioned test bed is operational for database-system components, its scope could and should be broadened to encompass different kinds of data managers for IT solutions in the large (e.g., a media server, a mail server each again built from several RISC-style components). So this worldwide test bed should be extensible beyond the narrow boundaries of what is commonly perceived as the “database community”. 
一旦作战设想试验台是为数据库系统组件 并应扩大其范围可涵盖不同的数据管理办法,在这大 (例如,媒体服务器,每年再建一个邮件服务器的RISC几式元件). 这一试验台等全世界应超越狭隘的界限扩展那就是一般认为"数据库 社区".
6.  Concluding Remarks 
Universal database systems grew out of our belief that database is the center of the universe and therefore the framework for integration. This is far from true in today’s world. Once we are liberated and can accept the fact that the database is one, certainly very important, component in the IT world, programmability and integration of database components with applications become a priority. In such a world, we need to build RISC-style data management components that have predictable performance and can be auto-tuned.  
6. 结束语 
通用数据库系统的前身,相信宇宙中心的数据库,因此框架 整合. 这是远远真在今天的世界. 一旦我们能够接受的是,解放和数据库之一,当然很重要, 在它的世界组成,可编程组件与数据库整合应用成为重中之重. 在这样一个世界,我们要建设的RISC式数据管理组件,可以预见的业绩和自动调谐.
When comparing our field to other areas of engineering that are building extremely complex artifacts such as aircrafts, high-speed trains, or space shuttles, we realize that such an architectural simplification is overdue and critical for the future success of database technology. Few, if any, understand the functions of a modern aircraft (e.g. Boeing 747) completely, but in contrast to the situation with database systems, there is excellent understanding of local components and a good understanding of the interaction across components. 
外地到其他地区相比,我国工程建设非常复杂,如飞机遗物、 高速火车,或者航天飞机, 我们认识到,这种简化是过期及建筑为未来的成功关键数据库技术. 综观世界,了解现代机功能(如波音747)完全, 但与此相反的情况数据库系统, 当地有很好的了解和掌握的互动元件.
The test for the advocated RISC-style database system architecture will be if it can be used broadly in many more contexts compared to today’s database systems. In this paper, we have hinted at some applications that can drive the design of such RISC data management components. These components can be “glued” together using narrow APIs to form powerful data services that have the hope of being effectively manageable. 
为倡导考试的RISC型数据库系统结构将大致若可用更多 情境相比今天的数据库系统. 在这篇文章中,我们已经隐约可以带动一些应用设计的RISC数据管理等部件. 这些组件可以"粘"在一起,形成强大的短片用狭隘数据服务,希望正在 有效控制.
The bottom line of these challenges is to foster improving the “gain/pain ratio” of database technology with regard to modern cyberspace applications. The key to this goal is to tolerate a moderate degradation of  “gain”, for example, by tolerating certain overhead for more interface-crossing across components, and reduce the “pain” level by orders of magnitude by ensuring predictable performance and eliminating the need for manual tuning. 
这些挑战底线是促进提高"赢得/疼痛比"现代数据库技术方面 网路应用. 这一目标的关键是要适度忍受退化"获得",例如 一些开销更包容界面过路组件 缩小"痛苦"的数量级水平,确保可预测性能和消除需要手工校正.


此帖转自:[url]http://www.programfan.com/team/team.asp?team_id=1288[/url]