DOCSLIB.ORG

H-Store: a High-Performance, Distributed Main Memory Transaction Processing System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
H-Store: a High-Performance, Distributed Main Memory Transaction Processing System H-Store: A High-Performance, Distributed Main Memory Transaction Processing System Robert Kallman Evan P. C. Jones John Hugg Hideaki Kimura Samuel Madden Vertica Inc. Jonathan Natkins Michael Stonebraker [email protected] Andrew Pavlo Yang Zhang Alexander Rasin Massachusetts Institute of Stanley Zdonik Technology Daniel J. Abadi Brown University Yale University {evanj, madden, {rkallman, hkimura, stonebraker, [email protected] jnatkins, pavlo, alexr, yang}@csail.mit.edu sbz}@cs.brown.edu ABSTRACT sponsibilities across multiple shared-nothing machines. Al- Our previous work has shown that architectural and appli- though some RDBMS platforms now provide support for cation shifts have resulted in modern OLTP databases in- this paradigm in their execution framework, research shows creasingly falling short of optimal performance [10]. In par- that building a new OLTP system that is optimized from ticular, the availability of multiple-cores, the abundance of its inception for a distributed environment is advantageous main memory, the lack of user stalls, and the dominant use over retrofitting an existing RDBMS [2]. of stored procedures are factors that portend a clean-slate Using a disk-oriented RDBMS is another key bottleneck redesign of RDBMSs. This previous work showed that such in OLTP databases. All but the very largest OLTP applica- a redesign has the potential to outperform legacy OLTP tions are able to fit their entire data set into the memory of databases by a significant factor. These results, however, a modern shared-nothing cluster of server machines. There- were obtained using a bare-bones prototype that was devel- fore, disk-oriented storage and indexing structures are un- oped just to demonstrate the potential of such a system. We necessary when the entire database is able to reside strictly have since set out to design a more complete execution plat- in memory. There are some main memory database systems form, and to implement some of the ideas presented in the available today, but again many of these systems inherit the original paper. Our demonstration presented here provides architectural baggage of System R [6]. Other distributed insight on the development of a distributed main memory main memory databases have also focused on the migration OLTP database and allows for the further study of the chal- of legacy architectural features to this environment [4]. lenges inherent in this operating environment. Our research is focused on developing H-Store, a next- generation OLTP system that operates on a distributed clus- ter of shared-nothing machines where the data resides en- 1. INTRODUCTION tirely in main memory. The system model is based on the The use of specialized data engines has been shown to coordination of multiple single-threaded engines to provide outperform traditional or “one size fits all” database sys- more efficient execution of OLTP transactions. An earlier tems [8, 9]. Many of these traditional systems use a myriad prototype of the H-Store system was shown to significantly of architectural components inherited from the original Sys- outperform a traditional, disk-based RDBMS installation tem R database, regardless if the target application domain using a well-known OLTP benchmark [10, 11]. The results actually needs such unwieldy techniques [1]. For example, from this previous work demonstrate that our ideas have the workloads for on-line transaction processing (OLTP) merit; we expand on this work and in this paper we present systems have particular properties, such as repetitive and a more full-featured version of the system that is able to short-lived transaction executions, that are hindered by the execute across multiple machines within a local area clus- I/O performance of legacy RDBMS platforms. One obvious ter. With this new system, we are investigating interesting strategy to mitigate this problem is to scale a system hor- aspects of this operating environment, including how to ex- izontally by partitioning both the data and processing re- ploit non-trivial properties of transactions. We begin in Section 2 by first providing an overview of Permission to make digital or hard copies of portions of this work for the internals of the H-Store system. The justification for personal or classroom use is granted without fee provided that copies many of the design decisions for H-Store is found in ear- arePermission not made to copyor distr withoutibuted feefor all pr orofit part or ofco thismmercial material advantage is granted and provided lier work [10]. In Section 3 we then expand our previous that the copies are not made or distributed for direct commercial advantage, that copies bear this notice and the full citation on the first page. discussion on the kinds of transactions that are found in Copyrightthe VLDB for copyright components notice andof this the work title of owned the publication by others and than its VL dateD appear,B OLTP systems and the desirable properties of an H-Store Endowmentand notice is must given be thathonored. copying is by permission of the Very Large Data AbstractingBase Endowment. with credit To copyis per otherwise,mitted. To orcopy to republish,otherwise, toto postrepublish, on servers database design. We conclude the paper in Section 4 by toor post to redistribute on servers to or lists, to re requiresdistribute a feeto lists and/or requires special prior permission specific from the describing the demonstration system that we developed to permissionpublisher, ACM. and/or a fee. Request permission to republish from: explore these properties further and observe the execution PublicationsVLDB ‘08, August Dept., 24-30,ACM, 2008,Inc. Fax Auckland, +1 (212)8 New69-0481 Zealand or behavior of our system. Copyright 2008 VLDB Endowment, ACM 000-0-00000-000-0/00/00. [email protected]. PVLDB '08, August 23-28, 2008, Auckland, New Zealand Copyright 2008 VLDB Endowment, ACM 978-1-60558-306-8/08/08 1496 of multiple distributed skeleton plans, one for each query in the procedure. Each plan’s sub-operations are not spe- cific to database’s distributed layout, but are optimized us- ing common techniques found in non-distributed databases. Once this first optimization phase is complete, the compiled procedures are transmitted to each site in the local cluster. At runtime, the query planner on each site converts skeleton plans for the queries into multi-site, distributed query plans. This two-phase optimization approach is similar to strate- gies used in previous systems [3]. Our optimizer uses a pre- liminary cost model based on the number of network com- munications that are needed to process the request. This Figure 1: H-Store system architecture. has proven to be sufficient in our initial tests as transaction throughput is not affected by disk access. 2. SYSTEM OVERVIEW 2.2 Runtime Model The H-Store system is a highly distributed, row-store- At execution time, the client OLTP application requests based relational database that runs on a cluster on shared- a new transaction using the stored procedure handlers gen- nothing, main memory executor nodes. erated during deployment process. If a transaction requires We define a single H-Store instance as a cluster of two parameter values as input, the client must also pass these to or more computational nodes deployed within the same ad- the system along with the request. We assume for now that ministrative domain. A node is a single physical computer all sites are trusted and reside within the same administra- system that hosts one or more sites.A site is the basic oper- tive domain, and thus we trust any network communication ational entity in the system; it is a single-threaded daemon that the system receives. that an external OLTP application connects to in order to Any site in an H-Store cluster is able to execute any OLTP execute a transaction. We assume that the typical H-Store application request, regardless of whether the data needed node has multiple processors and that each site is assigned by a particular transaction is located on that site. Unless all to execute on exactly one processor core on a node. Each of the queries’ parameter values in a transaction are known site is independent from all other sites, and thus does not at execution time, we use a lazy-planning strategy for cre- share any data structures or memory with collocated sites ating optimized distributed execution plans. If all of the running on the same machine. parameter values are known in the beginning, then we per- Every relation in the database is divided into one or more form additional optimizations based on certain transaction partitions. A partition is replicated and hosted on a multiple properties (see Section 3.1). sites, forming a replica set. When a running transaction executes a SQL command, OLTP applications make calls to the H-Store system to it makes an internal request through an H-Store API. At repeatedly execute pre-defined stored procedures. Each pro- this point, all of the parameter values for that query are cedure is identified by a unique name and consists of struc- known by the system, and thus the plan is annotated with tured control code intermixed with parameterized SQL com- the locations of the target sites for each query sub-operation. mands. An instance of a store procedure initiated by an The updated plan is then passed to a transaction manager OLTP application is called a transaction. that is responsible for coordinating access with the other Using these definitions, we now describe the deployment sites. The manager transmits plan fragments to the ap- and execution schemes of the H-Store system (see Figure 1). propriate site over sockets and the intermediate results (if any) are passed back to the initiating site. H-Store uses a 2.1 System Deployment generic distributed transaction framework to ensure serializ- ability.
Load more

Recommended publications
  • Rainblock: Faster Transaction Processing in Public Blockchains
    RainBlock: Faster Transaction Processing in Public Blockchains Soujanya Ponnapalli1, Aashaka Shah1, Souvik Banerjee1, Dahlia Malkhi2, Amy Tai3, Vijay Chidambaram1,3, and Michael Wei3 1University of Texas at Austin, 2Diem Association and Novi Financial, 3VMware Research Abstract Metric No state State: 10M Ratio We present RAINBLOCK, a public blockchain that achieves Time taken to mine txs (s) 1047 6340 6× " high transaction throughput without modifying the proof-of- # Txs per block 2150 833 2.5× # work consensus. The chief insight behind RAINBLOCK is that Tx throughput (txs/s) 28.6 4.7 6× # while consensus controls the rate at which new blocks are added to the blockchain, the number of transactions in each Table 1: Impact of system state on blockchain throughput. block is limited by I/O bottlenecks. Public blockchains like This table shows the throughput of Ethereum with proof-of- Ethereum keep the number of transactions in each block low work consensus when 30K txs are mined using three miners, so that all participating servers (miners) have enough time to in two scenarios: first, there are no accounts on the blockchain, process a block before the next block is created. By removing and in the second, 10M accounts have been added. Despite the I/O bottlenecks in transaction processing, RAINBLOCK al- no other difference, tx throughput is 6× lower in the second lows miners to process more transactions in the same amount scenario; we trace this to the I/O involved in processing txs. of time. RAINBLOCK makes two novel contributions: the RAIN- BLOCK architecture that removes I/O from the critical path of processing transactions (txs), and the distributed, multi- Bitcoin [1] and Ethereum, process only tens of transactions versioned DSM-TREE data structure that stores the system per second, limiting their applications [33, 65].
    [Show full text]
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains
    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
    [Show full text]
  • What Is a Database Management System? What Is a Transaction
    What is a Database? Collection of data central to some enterprise Overview of Databases and Essential to operation of enterprise Transaction Processing Contains the only record of enterprise activity An asset in its own right Chapter 1 Historical data can guide enterprise strategy Of interest to other enterprises State of database mirrors state of enterprise Database is persistent 2 What is a Database Management What is a Transaction? System? When an event in the real world changes the A Database Management System (DBMS) state of the enterprise, a transaction is is a program that manages a database: executed to cause the corresponding change in the database state Supports a high-level access language (e.g. With an on-line database, the event causes the SQL). transaction to be executed in real time Application describes database accesses using A transaction is an application program that language. with special properties - discussed later - to DBMS interprets statements of language to guarantee it maintains database correctness perform requested database access. 3 4 What is a Transaction Processing Transaction Processing System System? Transaction execution is controlled by a TP monitor s DBMS database n o i Creates the abstraction of a transaction, t c a analogous to the way an operating system s n a r creates the abstraction of a process t DBMS database TP monitor and DBMS together guarantee the special properties of transactions TP Monitor A Transaction Processing System consists of TP monitor, databases, and transactions 5 6 1 System
    [Show full text]
  • Improving High Contention OLTP Performance Via Transaction
    Improving High Contention OLTP Performance via Transaction Scheduling Guna Prasaad, Alvin Cheung, Dan Suciu University of Washington {guna, akcheung, suciu}@cs.washington.edu ABSTRACT Validation-based protocols [5, 26] are known to be well- Research in transaction processing has made significant suited for workloads with low data contention or conflicts, i.e., progress in improving the performance of multi-core in- when data items are being accessed by transactions concur- memory transactional systems. However, the focus has mainly rently, with at least one access being a write. Since conflicting been on low-contention workloads. Modern transactional accesses are rare, it is unlikely that the value of a data item systems perform poorly on workloads with transactions ac- is updated by another transaction during its execution, and cessing a few highly contended data items. We observe that hence validation mostly succeeds. On the other hand, for most transactional workloads, including those with high workloads where data contention is high, locking-based con- contention, can be divided into clusters of data conflict-free currency control protocols are generally preferred as they transactions and a small set of residuals. pessimistically block other transactions that require access In this paper, we introduce a new concurrency control to the same data item instead of incurring the overhead of protocol called Strife that leverages the above observation. repeatedly aborting and restarting the transaction like in Strife executes transactions in batches, where each batch is OCC. When the workload is known to be partitionable, parti- partitioned into clusters of conflict-free transactions and a tioned concurrency control [12] is preferred as it eliminates small set of residual transactions.
    [Show full text]
  • A High-Performance, Distributed Main Memory Transaction Processing System
    H-Store: A High-Performance, Distributed Main Memory Transaction Processing System Robert Kallman Evan P. C. Jones John Hugg Hideaki Kimura Samuel Madden Vertica Inc. Jonathan Natkins Michael Stonebraker [email protected] Andrew Pavlo Yang Zhang Alexander Rasin Massachusetts Institute of Stanley Zdonik Technology Daniel J. Abadi Brown University Yale University {evanj, madden, {rkallman, hkimura, stonebraker, [email protected] jnatkins, pavlo, alexr, yang}@csail.mit.edu sbz}@cs.brown.edu ABSTRACT sponsibilities across multiple shared-nothing machines. Al- Our previous work has shown that architectural and appli- though some RDBMS platforms now provide support for cation shifts have resulted in modern OLTP databases in- this paradigm in their execution framework, research shows creasingly falling short of optimal performance [10]. In par- that building a new OLTP system that is optimized from ticular, the availability of multiple-cores, the abundance of its inception for a distributed environment is advantageous main memory, the lack of user stalls, and the dominant use over retrofitting an existing RDBMS [2]. of stored procedures are factors that portend a clean-slate Using a disk-oriented RDBMS is another key bottleneck redesign of RDBMSs. This previous work showed that such in OLTP databases. All but the very largest OLTP applica- a redesign has the potential to outperform legacy OLTP tions are able to fit their entire data set into the memory of databases by a significant factor. These results, however, a modern shared-nothing cluster of server machines. There- were obtained using a bare-bones prototype that was devel- fore, disk-oriented storage and indexing structures are un- oped just to demonstrate the potential of such a system.
    [Show full text]
  • Transaction Processing Monitors
    Chapter 24: Advanced Transaction Processing ! Transaction-Processing Monitors ! Transactional Workflows ! High-Performance Transaction Systems ! Main memory databases ! Real-Time Transaction Systems ! Long-Duration Transactions ! Transaction management in multidatabase systems 1 Database System Concepts 24.1 ©Silberschatz, Korth and Sudarshan Transaction Processing Monitors ! TP monitors initially developed as multithreaded servers to support large numbers of terminals from a single process. ! Provide infrastructure for building and administering complex transaction processing systems with a large number of clients and multiple servers. ! Provide services such as: ! Presentation facilities to simplify creating user interfaces ! Persistent queuing of client requests and server responses ! Routing of client messages to servers ! Coordination of two-phase commit when transactions access multiple servers. ! Some commercial TP monitors: CICS from IBM, Pathway from Tandem, Top End from NCR, and Encina from Transarc 2 Database System Concepts 24.2 ©Silberschatz, Korth and Sudarshan 1 TP Monitor Architectures 3 Database System Concepts 24.3 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.) ! Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions. ! Memory requirements are high ! Multitasking- high CPU overhead for context switching between processes ! Single process model - all remote terminals connect to a single server process. ! Used in client-server environments ! Server process is multi-threaded; low cost for thread switching ! No protection between applications ! Not suited for parallel or distributed databases 4 Database System Concepts 24.4 ©Silberschatz, Korth and Sudarshan 2 TP Monitor Architectures (Cont.) ! Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.
    [Show full text]
  • High-Performance Transaction Processing in SAP HANA
    High-Performance Transaction Processing in SAP HANA Juchang Lee1, Michael Muehle1, Norman May1, Franz Faerber1, Vishal Sikka1, Hasso Plattner2, Jens Krueger2, Martin Grund3 1SAP AG 2Hasso Plattner Insitute, Potsdam, Germany, 3eXascale Infolab, University of Fribourg, Switzerland Abstract Modern enterprise applications are currently undergoing a complete paradigm shift away from tradi- tional transactional processing to combined analytical and transactional processing. This challenge of combining two opposing query types in a single database management system results in additional re- quirements for transaction management as well. In this paper, we discuss our approach to achieve high throughput for transactional query processing while allowing concurrent analytical queries. We present our approach to distributed snapshot isolation and optimized two-phase commit protocols. 1 Introduction An efficient and holistic data management infrastructure is one of the key requirements for making the right deci- sions at an operational, tactical, and strategic level and is core to support all kinds of enterprise applications[12]. In contrast to traditional architectures of database systems, the SAP HANA database takes a different approach to provide support for a wide range of data management tasks. The system is organized in a main-memory centric fashion to reflect the shift within the memory hierarchy[2] and to consistently provide high perfor- mance without prohibitively slow disk interactions. Completely transparent for the application, data is orga- nized along its life cycle either in column or row format, providing the best performance for different workload characteristics[11, 1]. Transactional workloads with a high update rate and point queries can be routed against a row store; analytical workloads with range scans over large datasets are supported by column oriented data struc- tures.
    [Show full text]
  • A Transaction Processing Method for Distributed Database
    Advances in Computer Science Research, volume 87 3rd International Conference on Mechatronics Engineering and Information Technology (ICMEIT 2019) A Transaction Processing Method for Distributed Database Zhian Lin a, Chi Zhang b School of Computer and Cyberspace Security, Communication University of China, Beijing, China [email protected], [email protected] Abstract. This paper introduces the distributed transaction processing model and two-phase commit protocol, and analyses the shortcomings of the two-phase commit protocol. And then we proposed a new distributed transaction processing method which adds heartbeat mechanism into the two- phase commit protocol. Using the method can improve reliability and reduce blocking in distributed transaction processing. Keywords: distributed transaction, two-phase commit protocol, heartbeat mechanism. 1. Introduction Most database services of application systems will be distributed on several servers, especially in some large-scale systems. Distributed transaction processing will be involved in the execution of business logic. At present, two-phase commit protocol is one of the methods to distributed transaction processing in distributed database systems. The two-phase commit protocol includes coordinator (transaction manager) and several participants (databases). In the process of communication between the coordinator and the participants, if the participants without reply for fail, the coordinator can only wait all the time, which can easily cause system blocking. In this paper, heartbeat mechanism is introduced to monitor participants, which avoid the risk of blocking of two-phase commit protocol, and improve the reliability and efficiency of distributed database system. 2. Distributed Transactions 2.1 Distributed Transaction Processing Model In a distributed system, each node is physically independent and they communicates and coordinates each other through the network.
    [Show full text]
  • Arxiv:1612.05566V1 [Cs.DB] 16 Dec 2016
    Building Efficient Query Engines in a High-Level Language Amir Shaikhha, École Polytechnique Fédérale de Lausanne Yannis Klonatos, École Polytechnique Fédérale de Lausanne Christoph Koch, École Polytechnique Fédérale de Lausanne Abstraction without regret refers to the vision of using high-level programming languages for systems de- velopment without experiencing a negative impact on performance. A database system designed according to this vision offers both increased productivity and high performance, instead of sacrificing the former for the latter as is the case with existing, monolithic implementations that are hard to maintain and extend. In this article, we realize this vision in the domain of analytical query processing. We present LegoBase, a query engine written in the high-level programming language Scala. The key technique to regain efficiency is to apply generative programming: LegoBase performs source-to-source compilation and optimizes the entire query engine by converting the high-level Scala code to specialized, low-level C code. We show how generative programming allows to easily implement a wide spectrum of optimizations, such as introducing data partitioning or switching from a row to a column data layout, which are difficult to achieve with existing low-level query compilers that handle only queries. We demonstrate that sufficiently powerful abstractions are essential for dealing with the complexity of the optimization effort, shielding developers from compiler internals and decoupling individual optimizations from each other. We evaluate our approach with the TPC-H benchmark and show that: (a) With all optimizations en- abled, our architecture significantly outperforms a commercial in-memory database as well as an existing query compiler.
    [Show full text]
  • Concurrency Control and Recovery ACID • Transactions • Recovery Transaction Model Concurency Control Recovery
    Data Management Systems • Transaction Processing • Concurrency control and recovery ACID • Transactions • Recovery Transaction model Concurency Control Recovery Gustavo Alonso Institute of Computing Platforms Department of Computer Science ETH Zürich Transactions-CC&R 1 A bit of theory • Before discussing implementations, we will cover the theoretical underpinning behind concurrency control and recovery • Discussion at an abstract level, without relation to implementations • No consideration of how the concepts map to real elements (tuples, pages, blocks, buffers, etc.) • Theoretical background important to understand variations in implementations and what is considered to be correct • Theoretical background also key to understand how system have evolved over the years Transactions-CC&R 2 Reference Concurrency Control and Recovery in Database Systems Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman • https://www.microsoft.com/en- us/research/people/philbe/book/ Transactions-CC&R 3 ACID Transactions-CC&R 4 Conventional notion of database correctness • ACID: • Atomicity: the notion that an operation or a group of operations must take place in their entirety or not at all • Consistency: operations should take the database from a correct state to another correct state • Isolation: concurrent execution of operations should yield results that are predictable and correct • Durability: the database needs to remember the state it is in at all moments, even when failures occur • Like all acronyms, more effort in making it sound cute than in
    [Show full text]
  • Jennie Duggan (Née Rogers)
    Jennie Duggan (n´eeRogers) MIT CSAIL Voice: omitted for web 32 Vasser Street, Room G904B E-mail: [email protected] Cambridge, MA 02139 Web: http://people.csail.mit.edu/jennie/ Interests Large-scale data processing, cloud computing, core database internals, scientific data management, database performance, big data Education Brown University December 2012 Ph.D., Computer Science • Thesis: \Query Performance Prediction for Analytical Workloads" • Advisor: U˘gurC¸etintemel Brown University May 2009 Sci.M., Computer Science • Thesis: \Towards a Generic Compression Advisor" • Advisor: U˘gurC¸etintemel Rensselaer Polytechnic Institute May 2003 B.S., Computer Science • Minor: Brain & Brain Behavior Research MIT CSAIL January 2013{Present Experience Postdoctoral Associate Data placement for elastic array processing (SciDB): • Researched the efficient reorganization of data for scalable array analytics • Designed a control loop for incrementally scaling out a scientific database cluster • Proposed partitioning schemes to maximize the preservation of array space for spatial querying Data placement for elastic distributed main memory databases (H-Store): • Investigated the management of execution skew for large-scale transactional workloads • Created algorithms for determining when and how to reprovision hardware resources for con- sistent query throughput • Built a two-level caching scheme that caters to hot spots in a transactional workload Massively parallelized join optimization (SciDB): • Proposed a two-phase join for arrays independently optimizing
    [Show full text]
  • Transactions and Failure Recovery
    Transactions and Failure Recovery Instructor: Matei Zaharia cs245.stanford.edu Outline Defining correctness Transaction model Hardware failures Recovery with logs CS 245 2 Outline Defining correctness Transaction model Hardware failures Recovery with logs CS 245 3 Focus of This Part of Course Correctness in case of failures & concurrency » There’s no point running queries quickly if the input data is wrong! CS 245 4 Correctness of Data Would like all data in our system to be “accurate” or “correct” at all times » Both logical data model and physical structs Employees Name Age Smith 52 Green 3421 Chen 1 CS 245 5 Idea: Integrity or Consistency Constraints Predicates that data structures must satisfy Examples: » X is an attribute of relation R » Domain(X) = {student, prof, staff} » If X = prof in a record then office != NULL in it » T is valid B-tree index for attribute X of R » No staff member should make more than twice the average salary CS 245 6 Definition Consistent state: satisfies all constraints Consistent DB: DB in consistent state CS 245 7 Constraints (As We Use Here) May Not Capture All Issues Example 1: transaction constraints When a salary is updated, new salary > old salary When an account record is deleted, balance = 0 CS 245 8 Constraints (As We Use Here) May Not Capture All Issues Note: some transaction constraints could be “emulated” by simple constraints, e.g., account acct # … balance is_deleted CS 245 9 Constraints (As We Use Here) May Not Capture All Issues Example 2: database should reflect real world DB Reality CS 245 10 Constraints (As We Use Here) May Not Capture All Issues Example 2: database should reflect real world DB Reality CS 245 11 In Any Case, Continue with Constraints..
    [Show full text]