DOCSLIB.ORG

SAQE: Practical Privacy-Preserving Approximate Query Processing for Data Federations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SAQE: Practical Privacy-Preserving Approximate Query Processing for Data Federations SAQE: Practical Privacy-Preserving Approximate Query Processing for Data Federations Johes Bater Yongjoo Park Xi He Northwestern University University of Illinois (UIUC) University of Waterloo [email protected] [email protected] [email protected] Xiao Wang Jennie Rogers Northwestern University Northwestern University [email protected] [email protected] ABSTRACT 1. INTRODUCTION A private data federation enables clients to query the union of data Querying the union of multiple private data stores is challeng- from multiple data providers without revealing any extra private ing due to the need to compute over the combined datasets without information to the client or any other data providers. Unfortu- data providers disclosing their secret query inputs to anyone. Here, nately, this strong end-to-end privacy guarantee requires crypto- a client issues a query against the union of these private records graphic protocols that incur a significant performance overhead as and he or she receives the output of their query over this shared high as 1,000× compared to executing the same query in the clear. data. Presently, systems of this kind use a trusted third party to se- As a result, private data federations are impractical for common curely query the union of multiple private datastores. For example, database workloads. This gap reveals the following key challenge some large hospitals in the Chicago area offer services for a cer- in a private data federation: offering significantly fast and accurate tain percentage of the residents; if we can query the union of these query answers without compromising strong end-to-end privacy. databases, it may serve as invaluable resources for accurate diag- To address this challenge, we propose SAQE, the Secure Ap- nosis, informed immunization, timely epidemic control, and so on. proximate Query Evaluator, a private data federation system that Yet, their databases stay siloed by default; these hospitals (i.e., data scales to very large datasets by combining three techniques — dif- providers) are reticent to share their data with one another, fearing ferential privacy, secure computation, and approximate query pro- the sensitive health records of their patients may be breached in cessing — in a novel and principled way. First, SAQE adds novel the process of carelessly data sharing. To address this, we need a secure sampling algorithms into the federation’s query processing principled approach to querying over multiple private datastores. pipeline to speed up query workloads and to minimize the noise the Private Data Federations. A private data federation [9, 58] is system must inject into the query results to protect the privacy of the a database system that offers end-to-end privacy guarantees for data. Second, we introduce a query planner that jointly optimizes querying the union of multiple datastores. In other words, a private the noise introduced by differential privacy with the sampling rates data federation ensures that the secret inputs of each data provider and resulting error bounds owing to approximate query processing. are accessible only to him or her 1) before, 2) during, and 3) af- Our research shows that these three techniques are synergistic: ter query processing. Before query processing, the system makes sampling within certain accuracy bounds improves both query pri- all query optimization decisions in a data-independent manner; no vacy and performance, meaning that SAQE executes over less data one can learn anything about the data by examining the query’s op- than existing techniques without sacrificing efficiency, privacy, or erators or parameters. During query processing, the system uses accuracy. Using our optimizer, we leverage this counter-intuitive secure computation protocols that compute over the private data of result to identify an inflection point that maximizes all three crite- multiple parties such that none of them learn the secret inputs of ria prior query evaluation. Experimentally, we show that this result their peers; the only information that is revealed is that which can enables SAQE to trade-off among these three criteria to scale its be deduced from the query output. Finally, after query process- query processing to very large datasets with accuracy bounds de- ing, the system adds carefully calibrated noise to the query results pendent only on sample size, and not the raw data size. using differential privacy [22] such that an adversary viewing this output will get essentially the same answer whether or not an indi- PVLDB Reference Format: Johes Bater, Yongjoo Park, Xi He, Xiao Wang, Jennie Rogers. SAQE: Prac- vidual chose to make his or her data available for querying. This tical Privacy-Preserving Approximate Query Processing for Data Federa- system has an integrated suite of differential privacy mechanisms tions. PVLDB, 13(11): 2691-2705, 2020. for modeling this controlled information leakage both during and DOI: https://doi.org/10.14778/3407790.3407854 after query processing. Existing differential privacy systems [36,46] with a single trusted data curator do not have to protect data during query processing. This work is licensed under the Creative Commons Attribution- Conversely, a private data federation must add noise using secure NonCommercial-NoDerivatives 4.0 International License. To view a copy computation [10] so that no party can deduce the true query answer of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. For any use beyond those covered by this license, obtain permission by emailing and any client that colludes with a data provider is unable to break [email protected]. Copyright is held by the owner/author(s). Publication rights the system’s privacy guarantees, even under repeated querying of licensed to the VLDB Endowment. a single dataset. To uphold this strong privacy guarantee of the Proceedings of the VLDB Endowment, Vol. 13, No. 11 input data, private data federations must add noise to query results, ISSN 2150-8097. reducing accuracy, and thereby compromising their utility. DOI: https://doi.org/10.14778/3407790.3407854 2691 4 Differential Privacy ·10 Sampling Error 2 Accuracy Privacy Performance DP Noise Privacy Amplification Summed Error 1:5 Approximate Query Processing SAQE 1 Accuracy Privacy Performance Max Accuracy Private Data Federation Error (Variance in Tuple Count) 0:5 Private Sampling Algorithms Positive Effect Secure Multi-party Computation No Effect 0 Negative Effect 0:2 0:4 0:6 0:8 1 Accuracy Privacy Performance Sampling Rate Figure 1: Key components of SAQE query processing Figure 2: Expected error for COUNT query results in SAQE, n = 10; 000, = 0:05, and δ = 10−5. Secure Computation.. We use secure computation to obliviously compute over the data of two or more data providers. An oblivious SQL querying over private data federations by generalizing approx- program’s observable transcript (i.e., its program counter, mem- imate query processing to this setting. Unlike the na¨ıve approach, ory access patterns, network transmissions) leaks nothing about its SAQE generalizes approximate query processing to this setting by input data because these signals are data-independent. Oblivious carefully composing it with differential privacy and secure compu- query processing incurs extremely high overhead owing to its use tation, making their interactions synergistic through an integrated of heavyweight cryptographic protocols to encrypt and process in- model of their performance profiles and information leakage. We put data. In practice, an oblivious query execution runs in worst- illustrate SAQE’s composition of these techniques in Figure 1. case time to uphold rigorous security guarantees. For example, a First, SAQE ensures sampling-time privacy by introducing two 2 join with inputs of length n will have an output cardinality of n . private sampling algorithms. That is, the na¨ıve approach— sam- Oblivious database operators produce worst-case output cardinal- pling locally at each data provider then computing on all the sam- ities by padding their results with dummy tuples. These crypto- ples using secure computation—reveals the exact size of each sam- graphic protocols also incur significant computation and network ple and the data provider knows their precise contribution to the overhead to run with their data encrypted in flight. Queries over query results. A curious data provider could use this knowledge secure computation have runtimes that are multiple orders of mag- to deduce unauthorized information about private data from query nitude slower than running the same query with no security. Hence, results. Our private sampling algorithms prevent this as follows. systems that use secure computation alone to protect data under In our first private sampling algorithm (i.e., an oblivious sampling computation [9, 58] do not scale to datasets that are greater than algorithm), the data providers work together in secure computa- hundreds of megabytes. tion to winnow down their input data to a set of samples for use in Approximate Query Processing. When executing queries over query evaluation without leaking any information. It outperforms a extremely large data sets, big data systems speed up execution by straw-man method by reducing the sampling cost from O(n log2 n) using approximate query processing [3, 20, 35, 38, 49], evaluating to O(n log n), where n is the size of the input data. The second a query over a sample of its input data rather than computing the algorithm uses computational differential
Load more

Recommended publications
  • Veritas: Shared Verifiable Databases and Tables in the Cloud
    Veritas: Shared Verifiable Databases and Tables in the Cloud Lindsey Alleny, Panagiotis Antonopoulosy, Arvind Arasuy, Johannes Gehrkey, Joachim Hammery, James Huntery, Raghav Kaushiky, Donald Kossmanny, Jonathan Leey, Ravi Ramamurthyy, Srinath Settyy, Jakub Szymaszeky, Alexander van Renenz, Ramarathnam Venkatesany yMicrosoft Corporation zTechnische Universität München ABSTRACT A recent class of new technology under the umbrella term In this paper we introduce shared, verifiable database tables, a new "blockchain" [11, 13, 22, 28, 33] promises to solve this conundrum. abstraction for trusted data sharing in the cloud. For example, companies A and B could write the state of these shared tables into a blockchain infrastructure (such as Ethereum [33]). The KEYWORDS blockchain then gives them transaction properties, such as atomic- ity of updates, durability, and isolation, and the blockchain allows Blockchain, data management a third party to go through its history and verify the transactions. Both companies A and B would have to write their updates into 1 INTRODUCTION the blockchain, wait until they are committed, and also read any Our economy depends on interactions – buyers and sellers, suppli- state changes from the blockchain as a means of sharing data across ers and manufacturers, professors and students, etc. Consider the A and B. To implement permissioning, A and B can use a permis- scenario where there are two companies A and B, where B supplies sioned blockchain variant that allows transactions only from a set widgets to A. A and B are exchanging data about the latest price for of well-defined participants; e.g., Ethereum [33]. widgets and dates of when widgets were shipped.
    [Show full text]
  • WIN: an Efficient Data Placement Strategy for Parallel XML Databases
    WIN : An Efficient Data Placement Strategy for Parallel XML Databases Nan Tang† Guoren Wang‡ Jeffrey Xu Yu† Kam-Fai Wong† Ge Yu‡ † Department of SE & EM, The Chinese University of Hong Kong, Hong Kong, China ‡ College of Information Science and Engineering, Northeastern University, Shenyang, China {ntang, yu, kfwong}se.cuhk.edu.hk {wanggr, yuge}@mail.neu.edu.cn Abstract graph-based. Distinct from them, XML employs a tree struc- The basic idea behind parallel database systems is to ture. Conventional data placement strategies in perform operations in parallel to reduce the response RDBMSs and OODBMSs cannot serve XML data well. time and improve the system throughput. Data place- Semistructured data involve nested structures; there ment is a key factor on the overall performance of are much intricacy and redundancy when represent- parallel systems. XML is semistructured data, tradi- ing XML as relations. Data placement strategies in tional data placement strategies cannot serve it well. RDBMSs cannot, therefore, well solve the data place- In this paper, we present the concept of intermediary ment problem of XML data. Although graph partition node INode, and propose a novel workload-aware data algorithms in OODBMSs can be applied to tree parti- placement WIN to effectively decluster XML data, to tion problems, the key relationships between tree nodes obtain high intra query parallelism. The extensive ex- such as ancestor-descendant or sibling cannot be clearly periments show that the speedup and scaleup perfor- denoted on graph. Hence data placement strategies mance of WIN outperforms the previous strategies. for OODBMSs cannot well adapt to XML data either.
    [Show full text]
  • SQL Database Management Portal
    APPENDIX A SQL Database Management Portal This appendix introduces you to the online SQL Database Management Portal built by Microsoft. It is a web-based application that allows you to design, manage, and monitor your SQL Database instances. Although the current version of the portal does not support all the functions of SQL Server Management Studio, the portal offers some interesting capabilities unique to SQL Database. Launching the Management Portal You can launch the SQL Database Management Portal (SDMP) from the Windows Azure Management Portal. Open a browser and navigate to https://manage.windowsazure.com, and then login with your Live ID. Once logged in, click SQL Databases on the left and click on your database from the list of available databases. This brings up the database dashboard, as seen in Figure A-1. To launch the management portal, click the Manage icon at the bottom. Figure A-1. SQL Database dashboard in Windows Azure Management Portal 257 APPENDIX A N SQL DATABASE MANAGEMENT PORTAL N Note You can also access the SDMP directly from a browser by typing https://sqldatabasename.database. windows.net, where sqldatabasename is the server name of your SQL Database. A new web page opens up that prompts you to log in to your SQL Database server. If you clicked through the Windows Azure Management Portal, the database name will be automatically filled and read-only. If you typed the URL directly in a browser, you will need to enter the database name manually. Enter a user name and password; then click Log on (Figure A-2).
    [Show full text]
  • Tepzz¥ 67¥¥Za T
    (19) TZZ¥ ¥¥Z_T (11) EP 3 267 330 A1 (12) EUROPEAN PATENT APPLICATION (43) Date of publication: (51) Int Cl.: 10.01.2018 Bulletin 2018/02 G06F 17/30 (2006.01) (21) Application number: 16187202.3 (22) Date of filing: 05.09.2016 (84) Designated Contracting States: (72) Inventors: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB • Abolhassani, Neda GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO Athens, GA Georgia 30605 (US) PL PT RO RS SE SI SK SM TR • Sheausan Tung, Teresa Designated Extension States: San Jose, CA California 95120 (US) BA ME • Gomadam, Karthik Designated Validation States: San Jose, CA California 95112 (US) MA MD (74) Representative: Müller-Boré & Partner (30) Priority: 07.07.2016 US 201662359547 P Patentanwälte PartG mbB 03.08.2016 US 201615227605 Friedenheimer Brücke 21 80639 München (DE) (71) Applicant: Accenture Global Solutions Limited Dublin 4 (IE) (54) QUERY REWRITING IN A RELATIONAL DATA HARMONIZATION FRAMEWORK (57) A query rewriting processor (processor) analyz- an SQL query). The processor may then pass the rela- es database semantic models (e.g., RDF knowledge tional database query to another system or process (e.g., graphs) that capture the interconnections (e.g., foreign a data virtualization layer) for execution against the indi- and primary key links to other tables) present in a rela- vidual relational databases. In this manner, the processor tional database. The processor generates an enriched automatically translates queries for information about the model query given an initial model query (e.g., a SPARQL relational database structure to a corresponding or query) against the semantic model.
    [Show full text]
  • Plan Stitch: Harnessing the Best of Many Plans
    Plan Stitch: Harnessing the Best of Many Plans Bailu Ding Sudipto Das Wentao Wu Surajit Chaudhuri Vivek Narasayya Microsoft Research Redmond, WA 98052, USA fbadin, sudiptod, wentwu, surajitc, [email protected] ABSTRACT optimizer chooses multiple query plans for the same query, espe- Query performance regression due to the query optimizer select- cially for stored procedures and query templates. ing a bad query execution plan is a major pain point in produc- The query optimizer often makes good use of the newly-created indexes and statistics, and the resulting new query plan improves tion workloads. Commercial DBMSs today can automatically de- 1 tect and correct such query plan regressions by storing previously- in execution cost. At times, however, the latest query plan chosen executed plans and reverting to a previous plan which is still valid by the optimizer has significantly higher execution cost compared and has the least execution cost. Such reversion-based plan cor- to previously-executed plans, i.e., a plan regresses [5, 6, 31]. rection has relatively low risk of plan regression since the deci- The problem of plan regression is painful for production applica- sion is based on observed execution costs. However, this approach tions as it is hard to debug. It becomes even more challenging when ignores potentially valuable information of efficient subplans col- plans change regularly on a large scale, such as in a cloud database lected from other previously-executed plans. In this paper, we service with automatic index tuning. Given such a large-scale pro- propose a novel technique, Plan Stitch, that automatically and op- duction environment, detecting and correcting plan regressions in portunistically combines efficient subplans of previously-executed an automated manner becomes crucial.
    [Show full text]
  • Exploring Query Re-Optimization in a Modern Database System
    Radboud University Nijmegen Institute of Computing and Information Sciences Exploring Query Re-Optimization In a Modern Database System Master Thesis Computing Science Supervisor: Prof. dr. ir. Arjen P. Author: de Vries BSc Laurens N. Kuiper Second reader: Prof. dr. ir. Djoerd Hiemstra May 2021 Abstract The standard approach to query processing in database systems is to optimize before executing. When available statistics are accurate, optimization yields the optimal plan, and execution is as quick as it can be. However, when queries become more complex, the quality of statistics degrades, which leads to sub-optimal query plans, sometimes up to several orders of magnitude worse. Improving statistics for these queries is infeasible because the cardinality estimation error propagates exponentially through the plan. This problem can be alleviated through re-optimization, which is to progressively optimize the query, executing parts of the plan at a time, improving plan quality at the cost of additional overhead. In this work, re-optimization is implemented and simulated in DuckDB, a main-memory database system designed for analytical workloads, and evaluated on the Join Order Benchmark. Total plan cost of the benchmark is reduced by up to 44% using this method, and a reduction in end-to-end query latency of up to 20% is observed using only simple re-optimization schemes, showing the potential of this approach. Acknowledgements The past year has been a challenging and exciting year. From breaking my leg to starting a job, and finally finishing my thesis. I would like to thank everyone who supported me during this period, and helped me get here.
    [Show full text]
  • Queryguard: Privacy-Preserving Latency-Aware Query Optimization for Edge Computing
    QueryGuard: Privacy-preserving Latency-aware Query Optimization for Edge Computing Runhua Xu ∗, Balaji Palanisamy y and James Joshi z School of Computing and Information University of Pittsburgh, Pittsburgh, PA USA ∗[email protected], [email protected], [email protected] Abstract—The emerging edge computing paradigm has en- adopting distributed database techniques in edge computing abled applications having low response time requirements to brings new challenges and concerns. First, in contrast to meet the quality of service needs of applications by moving the cloud data centers where cloud servers are managed through computations to the edge of the network that is geographically closer to the end-users and end-devices. Despite the low latency strict and regularized policies, edge nodes may not have the advantages provided by the edge computing model, there are same degree of regulatory and monitoring oversight. This significant privacy risks associated with the adoption of edge may lead to higher privacy risks compared to that in cloud computing services for applications dealing with sensitive data. servers. In particular, when dealing with a join query, tra- In contrast to cloud data centers where system infrastructures are ditional distributed query processing techniques sometimes managed through strict and regularized policies, edge computing nodes are scattered geographically and may not have the same ship selected or projected data to different nodes, some of degree of regulatory and monitoring oversight. This can lead which may be untrusted or semi-trusted. Thus, such techniques to higher privacy risks for the data processed and stored at may lead to greater disclosure of private information within the edge nodes, thus making them less trusted.
    [Show full text]
  • Conjunctive Query Answering in the Description Logic EL Using a Relational Database System
    Conjunctive Query Answering in the Description Logic EL Using a Relational Database System Carsten Lutz - Universität Bremen, Germany David Toman - University of Waterloo, Canada FrankWolter - University of Liverpool, UK Presented By : Jasmeet Jagdev Background • One of the main application of ontologies is data access • Ontologies formalize conceptual information about the data • Calvanese et al. have argued, true scalability of CQ answering over DL ontologies can only be achieved by making use of RDBMSs • Not straight forward ! Background • RDBMSs are unaware of Tboxes (the DL mechanism for storing conceptual information) and adopt the closed-world semantics • In contrast, ABoxes (the DL mechanism for storing data) and the associated ontologies employ the open-world semantics Introduction • Approach for using RDBMSs for CQ answering over DL ontologies • We apply it to an extension of EL family of DLs • Widely used as ontology languages for large scale bio-medical ontologies such as SNOMED CT and NCI Introduction • EL allows – Concept Intersection – Existential restrictions dr • ELH⊥ = EL + bottom concept, role inclusions, and domain and range restrictions Main Idea • To incorporate the consequences of the TBox T into the relational instance corresponding to the given ABox A • To introduce the idea of combined first-order (FO) rewritability • It is possibly only if: – A and T can be written into an FO structure – q and T into FO query q* Main Idea • Properties of this approach: – It applies to DLs for which data complexity of CQ dr answering
    [Show full text]
  • Lesson 4: Optimize a Query Using the Sybase IQ Query Plan
    Author: Courtney Claussen – SAP Sybase IQ Technical Evangelist Contributor: Bruce McManus – Director of Customer Support at Sybase Getting Started with SAP Sybase IQ Column Store Analytics Server Lesson 4: Optimize a Query using the SAP Sybase IQ Query Plan Copyright (C) 2012 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase and the Sybase logo are trademarks of Sybase, Inc. or its subsidiaries. SAP and the SAP logo are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other trademarks are the property of their respective owners. (R) indicates registration in the United States. Specifications are subject to change without notice. Table of Contents 1. Introduction ................................................................................................................1 2. SAP Sybase IQ Query Processing ............................................................................2 3. SAP Sybase IQ Query Plans .....................................................................................4 4. What a Query Plan Looks Like ................................................................................5 5. What a Query Plan Will Tell You ............................................................................7 5.1 Query Tree Nodes and Node Detail ......................................................................7 5.1.1 Root Node Details ..........................................................................................7
    [Show full text]
  • Query Processing for SQL Updates
    Query Processing for SQL Updates Cesar´ A. Galindo-Legaria Stefano Stefani Florian Waas [email protected] [email protected] fl[email protected] Microsoft Corp., One Microsoft Way, Redmond, WA 98052 ABSTRACT tradeoffs between plans that do serial or random I/Os. This moti- A rich set of concepts and techniques has been developed in the vates the integration of update processing in the general framework context of query processing for the efficient and robust execution of query processing. To be successful, this integration needs to of queries. So far, this work has mostly focused on issues related model update processing in a suitable way and consider the special to data-retrieval queries, with a strong backing on relational alge- requirements of updates. One of the few papers in this area is [2], bra. However, update operations can also exhibit a number of query which deals with delete operations, but there is little documented processing issues, depending on the complexity of the operations on the integration of updates with query processing, to the best of and the volume of data to process. Such issues include lookup and our knowledge. matching of values, navigational vs. set-oriented algorithms and In this paper, we present an overview of the basic concepts used trade-offs between plans that do serial or random I/Os. to support SQL Data Manipulation Language (DML) by the query In this paper we present an overview of the basic techniques used processor in Microsoft SQL Server. We focus on the query process- to support SQL DML (Data Manipulation Language) in Microsoft ing aspects of the problem, how data is modeled, primitive opera- SQL Server.
    [Show full text]
  • Query Rewriting Using Monolingual Statistical Machine Translation
    Query Rewriting using Monolingual Statistical Machine Translation Stefan Riezler∗ Yi Liu∗∗ Google Google Long queries often suffer from low recall in web search due to conjunctive term matching. The chances of matching words in relevant documents can be increased by rewriting query terms into new terms with similar statistical properties. We present a comparison of approaches that deploy user query logs to learn rewrites of query terms into terms from the document space. We show that the best results are achieved by adopting the perspective of bridging the “lexical chasm” between queries and documents by translating from a source language of user queries into a target language of web documents. We train a state-of-the-art statistical machine translation (SMT) model on query-snippet pairs from user query logs, and extract expansion terms from the query rewrites produced by the monolingual translation system. We show in an extrinsic evaluation in a real-world web search task that the combination of a query-to-snippet translation model with a query language model achieves improved contextual query expansion compared to a state-of-the-art query expansion model that is trained on the same query log data. 1. Introduction Information Retrieval (IR) applications have been notoriously resistant to improvement attempts by Natural Language Processing (NLP). With a few exceptions for specialized tasks1, the contribution of part-of-speech taggers, syntactic parsers, or ontologies of nouns or verbs, has been inconclusive. In this paper, instead of deploying NLP tools or ontologies, we apply NLP ideas to IR problems. In particular, we take a viewpoint that looks at the problem of the word mismatch between queries and documents in web search as a problem of translating from a source language of user queries into a target language of web documents.
    [Show full text]
  • CPS216: Advanced Database Systems Notes 03:Query Processing
    CPS216: Advanced Database Systems Notes 03:Query Processing (Overview, contd.) Shivnath Babu Overview of SQL query Query parse Processing parse tree Query rewriting Query statistics logical query plan Optimization Physical plan generation physical query plan execute Query Execution result SQL query Initial logical plan parse parse tree Rewrite rules Query rewriting Logical plan statistics logical query plan Physical plan generation “Best” logical plan physical query plan execute result Query Rewriting π π B,D B,D σ σ R.C = S.C R.A = “c” Λ R.C = S.C σ R.A = “c” X X RS RS We will revisit it towards the end of this lecture SQL query parse parse tree Query rewriting statistics Best logical query plan Physical plan generation Best physical query plan execute result Physical Plan Generation π B,D Project Natural join Hash join σ R.A = “c” S Index scan Table scan R RS Best logical plan SQL query parse parse tree Enumerate possible physical plans Query rewriting statistics Best logical query plan Find the cost of each plan Physical plan generation Best physical query plan Pick plan with execute minimum cost result Physical Plan Generation Logical Query Plan Physical P1 P2 …. Pn plans C1 C2 …. Cn Costs Pick minimum cost one Plans for Query Execution • Roadmap – Path of a SQL query – Operator trees – Physical Vs Logical plans – Plumbing: Materialization Vs pipelining Modern DBMS Architecture Applications SQL DBMS Parser Logical query plan Query Optimizer Physical query plan Query Executor Access method API calls Storage Manager Storage system API calls File system API calls OS Disk(s) Logical Plans Vs.
    [Show full text]