Small Refinements to the DAM Can Have Big Consequences for Data-Structure Design

Total Page:16

File Type:pdf, Size:1020Kb

Small Refinements to the DAM Can Have Big Consequences for Data-Structure Design Small Refinements to the DAM Can Have Big Consequences for Data-Structure Design Michael A. Bender Alex Conway Martín Farach-Colton Stony Brook University Rutgers University and Rutgers University [email protected] VMware Research [email protected] [email protected] William Jannen Yizheng Jiao Rob Johnson Williams College The University of North Carolina at VMware Research [email protected] Chapel Hill [email protected] [email protected] Eric Knorr Sara McAllister Nirjhar Mukherjee Rutgers University Harvey Mudd College The University of North Carolina at [email protected] [email protected] Chapel Hill [email protected] Prashant Pandey Donald E. Porter Jun Yuan Carnegie Mellon University The University of North Carolina at Pace University [email protected] Chapel Hill [email protected] [email protected] Yang Zhan The University of North Carolina at Chapel Hill [email protected] ABSTRACT In this paper, we show that the affine and PDAM models, which Storage devices have complex performance profiles, including costs are small refinements of the DAM model, yield a surprisingly large to initiate IOs (e.g., seek times in hard drives), parallelism and bank improvement in predictability without sacrificing ease of use. We conflicts (in SSDs), costs to transfer data, and firmware-internal present benchmarks on a large collection of storage devices showing operations. that the affine and PDAM models give good approximations ofthe The Disk-Access Machine (DAM) model simplifies reality by performance characteristics of hard drives and SSDs, respectively. assuming that storage devices transfer data in blocks of size B and We show that the affine model explains node-size choices inB- ε that all transfers have unit cost. Despite its simplifications, the trees and B -trees. Furthermore, the models predict that the B-tree ε DAM model is reasonably accurate. In fact, if B is set to the half- is highly sensitive to variations in the node size whereas B -trees bandwidth point, where the latency and bandwidth of the hardware are much less sensitive. These predictions are born out empirically. are equal, the DAM approximates the IO cost on any hardware to Finally, we show that in both the affine and PDAM models, it within a factor of 2. pays to organize data structures to exploit varying IO size. In the ε Furthermore, the DAM explains the popularity of B-trees in affine model, B -trees can be optimized so that all operations are the 70s and the current popularity of Bε -trees and log-structured simultaneously optimal, even up to lower order terms. In the PDAM ε merge trees. But it fails to explain why some B-trees use small model, B -trees (or B-trees) can be organized so that both sequential nodes, whereas all Bε -trees use large nodes. In a DAM, all IOs, and and concurrent workloads are handled efficiently. hence all nodes, are the same size. We conclude that the DAM model is useful as a first cut when designing or analyzing an algorithm or data structure but the affine Permission to make digital or hard copies of all or part of this work for personal or and PDAM models enable the algorithm designer to optimize pa- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation rameter choices and fill in design details. on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission ACM Reference Format: and/or a fee. Request permissions from [email protected]. Michael A. Bender, Alex Conway, Martín Farach-Colton, William Jannen, SPAA ’19, June 22–24, 2019, Phoenix, AZ, USA Yizheng Jiao, Rob Johnson, Eric Knorr, Sara McAllister, Nirjhar Mukherjee, © 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-6184-2/19/06...$15.00 Prashant Pandey, Donald E. Porter, Jun Yuan, and Yang Zhan. 2019. Small https://doi.org/10.1145/3323165.3323210 Refinements to the DAM Can Have Big Consequences for Data-Structure Design. In 31st ACM Symposium on Parallelism in Algorithms and Architec- storage devices showing that the affine and PDAM models are good tures (SPAA ’19), June 22–24, 2019, Phoenix, AZ, USA. ACM, New York, NY, approximations of the performance characteristics of hard drives USA, 10 pages. https://doi.org/10.1145/3323165.3323210 and SSDs, respectively. We find that, for example, the PDAM isable to correctly predict the run-time of a parallel random-read bench- 1 INTRODUCTION mark on SSDs to within an error of never more than 14% across a Storage devices have complex performance profiles, including costs broad range of devices and numbers of threads. The DAM, on the to initiate IO (e.g., seek times in hard drives), parallelism and bank other hand, overestimates the completion time for large numbers conflicts (in SSDs), costs to transfer data, and firmware-internal of threads by roughly P, the parallelism of the device, which ranges operations. from 2.5 to 12. On hard drives, the affine model predicts the time The Disk-Access Machine (DAM) model [2] simplifies reality for IOs of varying sizes to within a 25% error, whereas, as described by assuming that storage devices transfer data in blocks of size B above, the DAM is off by up to a factor of2. and that all transfers have unit cost. Despite its simplifications, the Researchers have long understood the underlying hardware ef- DAM has been a success [4, 64], in part because it is easy to use. fects motivating the affine and PDAM models. Nonetheless, itwas The DAM model is also reasonably accurate. If B is set to the a pleasant surprise to see how accurate these models turn out to hardware’s half-bandwidth point, i.e., the IO size where the la- be, even though they are simple tweaks of the DAM. tency and bandwidth of the hardware are equal, then the DAM The affine and PDAM models explain software design model predicts the IO cost of any algorithm to within a factor of 2 choices. In §5 and §6, we reanalyze the B-tree and the Bε -tree on that hardware. That is, if an algorithm replaces all its IOs with in the affine and PDAM models. The affine model explains why IOs of the half-bandwidth size, then the cost of the IOs increase by B-trees typically use nodes that are much smaller than the half- a factor of at most 2. bandwidth point, whereas Bε -trees have nodes that are larger than Furthermore, the DAM explains some choices that software ar- the half-bandwidth point. Furthermore, the models predict that the chitects have made. For example, the DAM model gives an analytical B-tree is highly sensitive to variations in the node size whereas explanation for why B-trees [6, 27] took over in the 70s and why Bε -trees are much less sensitive. These predictions are borne out Bε -trees [13, 21], log-structured merge trees [11, 47], and external- empirically. memory skip lists [8, 15, 55] are taking over now. The affine and PDAM models enable better data-structure But the DAM model has its limits. For example, the DAM does designs. In a Bε -tree, small nodes optimize point queries and large not explain why B-trees in many databases and file systems use nodes optimize range queries and insertions. In §6, we show that nodes of size 16KiB [1, 44, 45, 49, 50], which is well below the in the affine model, nodes can be organized with internal structure half-bandwidth point on most storage devices, whereas B-trees (such that nodes have subnodes) so that all operations are simulta- optimized for range queries use larger node sizes, typically up to neously optimal, up to lower order terms. Since the DAM model around 1MB [51, 53]. Nor does it explain why TokuDB’s [62]Bε -tree looses a factor of 2, it is blind to such fine-grained optimizations. uses 4MiB nodes and LevelDB’s [36] LSM-tree uses 2MiB SSTables The PDAM allows us to organize nodes in a search tree so that for all workloads. In a DAM, all IOs, and hence all nodes, are the the tree achieves optimal throughput both when the number of same size. concurrent read threads are large and small. A small number of How can a optimization parameter that can vary by over three read threads favors large nodes, and a large number favors small orders of magnitude have escaped algorithmic recognition? The nodes. In §8, we show how to organize nodes so that part or all of answer is that the DAM model is too blunt an instrument to capture them can be read, which allows the data structure to handle both these design issues. work loads obliviously and optimally. In this paper, we show that the affine [3, 57] and PDAM [2] Discussion. Taking a step back, we believe that the affine and models, which are small refinements of the DAM model, yield a PDAM models are important complements to the DAM model. surprisingly large improvement in predictivity without sacrificing The DAM is useful as a first cut when designing or analyzing an ease of use. algorithm or data structure but the affine and PDAM models enable The affine and PDAM models explicitly account for seeks (in the algorithm designer to optimize parameter choices and fill in spinning disks) and parallelism (in solid-state storage devices).
Recommended publications
  • Percona Server for Mongodb Documentation Release 3.2.22-3.13
    Percona Server for MongoDB Documentation Release 3.2.22-3.13 Percona LLC and/or its affiliates 2015-2018 Jan 16, 2019 CONTENTS I Introduction3 II Installation7 III Features 21 IV Reference 51 i ii Percona Server for MongoDB Documentation, Release 3.2.22-3.13 Percona Server for MongoDB is a free, enhanced, fully compatible, open source, drop-in replacement for MongoDB 3.2 Community Edition with enterprise-grade features. It requires no changes to MongoDB applications or code. Percona Server for MongoDB provides the following features: • MongoDB’s original MMAPv1 storage engine, and the default WiredTiger engine • Optional PerconaFT, Percona Memory Engine, and MongoRocks storage engines • Percona TokuBackup for creating dynamic backups while data remains fully accessible and writable (hot backup) • External SASL authentication using OpenLDAP or Active Directory • Audit logging to track and query database interactions of users or applications Note: PerconaFT has been deprecated and will not be available in future releases. CONTENTS 1 Percona Server for MongoDB Documentation, Release 3.2.22-3.13 2 CONTENTS Part I Introduction 3 CHAPTER ONE PERCONA SERVER FOR MONGODB FEATURE COMPARISON Percona Server for MongoDB is based on MongoDB 3.2, and it is the successor to Percona TokuMX, which is based on MongoDB 2.4. Both MongoDB and Percona Server for MongoDB include a pluggable storage engine API. This enables you to select from a variety of storage engines depending on your needs. Previous MongoDB versions (before 3.0) and Percona TokuMX can run with only one default storage engine. The following table will help you evaluate the differences.
    [Show full text]
  • The Algorithmics of Write Optimization
    The Algorithmics of Write Optimization Michael A. Bender Stony Brook University Birds-eye view of data storage incoming data queries answers stored data Birds-eye view of data storage ? incoming data queries answers stored data Storage systems face a trade-off between the speed of inserts/deletes/updates and the speed of queries. Point of this talk The tradeoff Parallel hurts. computing is about high performance. x To get high performance, we need fast access to our data. Point of this talk The tradeoff Parallel hurts. computing is about high performance. x To get high performance, we need fast access to our data. How should we organize our stored data? Point of this talk The tradeoff Parallel hurts. computing is about high performance. x To get high performance, we need fast access to our data. How should we organize our stored data? This is a data- structural question. How should we organize our stored data? How should we organize our stored data? Like a librarian? How should we organize our stored data? Like a librarian? Fast to find stuff. Requires work to maintain. How should we organize our stored data? Like a librarian? Like a teenager? Fast to find stuff. Requires work to maintain. How should we organize our stored data? Like a librarian? Like a teenager? Fast to find stuff. Fast to add stuff. Requires work to maintain. Slow to find stuff. How should we organize our stored data? Like a librarian? Like a teenager? Fast to find stuff. Fast to add stuff. Requires work to maintain. Slow to find stuff.
    [Show full text]
  • Mongodb에서 B-트리 인덱스와 Fractal 트리 인덱스를 이용한 성능 비교
    MongoDB에서 B-트리 인덱스와 Fractal 트리 인덱스를 이용한 성능 비교 장성호* · 김수희* *호서대학교 Performance Comparisons on MongoDB with B-Tree Indexes and Fractal Tree Indexes Seongho Jang* · Suhee Kim* *Department of Computer Engineering, Hoseo University E-mail : [email protected], [email protected] 요 약 빅데이터가 다양한 가치를 만들어내기 시작하면서, 더 다양하면서도 막대한 량의 데이터를 수용할 수 있는 데이터베이스가 필요하게 되었다. 그래서 기존 RDBMS의 복잡도와 용량 한계를 극복하기 위 한 목적으로 NoSQL 데이터베이스가 등장하게 되었고, 그 중 대표적으로 MongoDB가 많이 사용되며, 오픈 소스로 제공되고 있다. MongoDB에서 사용되는 B-트리 인덱스는 데이터양이 증가함에 따라 그 성능이 현저히 떨어진다. Fractal 트리 인덱스는 B-트리의 삽입 알고리즘을 개선하여 상당한 성능향상을 가능하게 한다. 이 논문에서는 MongoDB에서 B-트리 인덱스를 사용하는 경우와 Fractal 트리 인덱스를 사용하는 경우를 구별하여 그 성능을 비교해 본다. ABSTRACT As Big data began to produce a variety of values, a database that allows for huge amount of data with varieties became to be needed. Therefore, for the purpose of overcoming the limitations of the complexity and capacity of the existing RDBMS, NoSQL databases were introduced. Among the different types of NoSQL databases, MongoDB is most commonly used and is offered as open sources. The B-Tree index, used in MongoDB, experiences a significant decrease in performance as the amount of data increases. The fractal tree index enables to enhance the performance of B-Tree substantially by improving B-Tree’s insertion algorithm. In this paper, the performances of MongoDB when using B-Tree Index and when using Fractal Tree Index are compared.. 키워드 MongoDB, Index, B-Tree, Fractal Tree, Performance Ⅰ. 서 론 이터들을 관리하기 위한 기술로 NoSQL이 등장했 다.
    [Show full text]
  • Data Structures and Algorithms for Big Databases
    Data Structures and Algorithms for Big Databases Michael A. Bender Bradley C. Kuszmaul Stony Brook & Tokutek MIT & Tokutek Big data problem data ingestion queries + answers oy vey 365 42 ??? ??? ??? ??? data indexing query processor Important and universal problem. 2 Hot topic. For on-disk data, one sees funny tradeoBig dataffs in theproblem speeds of data ingestion, query speed, and freshness of data. data ingestion queries + answers oy vey 365 42 ??? ??? ??? ??? data indexing query processor Important and universal problem. 2 Hot topic. Funny tradeoff in ingestion, querying, freshness • “Select queries were slow until I added an index onto the timestamp field... Adding the index really helped our reporting, BUT now the inserts are taking forever.” ‣ Comment on mysqlperformanceblog.com • “I'm trying to create indexes on a table with 308 million rows. It took ~20 minutes to load the table but 10 days to build indexes on it.” ‣ MySQL bug #9544 • “They indexed their tables, and indexed them well, And lo, did the queries run quick! But that wasn’t the last of their troubles, to tell– Their insertions, like treacle, ran thick.” ‣ Not from Alice in Wonderland by Lewis Carroll queries + answers ??? 42 data ingestion query processor 3 data indexing Don’t Thrash: How to Cache Your Hash in Flash Funny tradeoff in ingestion, querying, freshness • “Select queries were slow until I added an index onto the timestamp field... Adding the index really helped our reporting, BUT now the inserts are taking forever.” ‣ Comment on mysqlperformanceblog.com •
    [Show full text]
  • Database Management Systems Ebooks for All Edition (
    Database Management Systems eBooks For All Edition (www.ebooks-for-all.com) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sun, 20 Oct 2013 01:48:50 UTC Contents Articles Database 1 Database model 16 Database normalization 23 Database storage structures 31 Distributed database 33 Federated database system 36 Referential integrity 40 Relational algebra 41 Relational calculus 53 Relational database 53 Relational database management system 57 Relational model 59 Object-relational database 69 Transaction processing 72 Concepts 76 ACID 76 Create, read, update and delete 79 Null (SQL) 80 Candidate key 96 Foreign key 98 Unique key 102 Superkey 105 Surrogate key 107 Armstrong's axioms 111 Objects 113 Relation (database) 113 Table (database) 115 Column (database) 116 Row (database) 117 View (SQL) 118 Database transaction 120 Transaction log 123 Database trigger 124 Database index 130 Stored procedure 135 Cursor (databases) 138 Partition (database) 143 Components 145 Concurrency control 145 Data dictionary 152 Java Database Connectivity 154 XQuery API for Java 157 ODBC 163 Query language 169 Query optimization 170 Query plan 173 Functions 175 Database administration and automation 175 Replication (computing) 177 Database Products 183 Comparison of object database management systems 183 Comparison of object-relational database management systems 185 List of relational database management systems 187 Comparison of relational database management systems 190 Document-oriented database 213 Graph database 217 NoSQL 226 NewSQL 232 References Article Sources and Contributors 234 Image Sources, Licenses and Contributors 240 Article Licenses License 241 Database 1 Database A database is an organized collection of data.
    [Show full text]
  • Write-Optimization in a Kernel File System
    BetrFS: Write-Optimization in a Kernel File System WILLIAM JANNEN, JUN YUAN, YANG ZHAN, and AMOGH AKSHINTALA, Stony Brook University JOHN ESMET, Tokutek YIZHENG JIAO, ANKUR MITTAL, PRASHANT PANDEY, and PHANEENDRA REDDY, Stony Brook University LEIF WALSH, Tokutek MICHAEL A. BENDER, Stony Brook University MARTIN FARACH-COLTON, Rutgers University ROB JOHNSON, Stony Brook University BRADLEY C. KUSZMAUL, Massachusetts Institute of Technology DONALD E. PORTER, Stony Brook University The Bε-tree File System,orBetrFS (pronounced “better eff ess”), is the first in-kernel file system to use a 18 write-optimized data structure (WODS). WODS are promising building blocks for storage systems because they support both microwrites and large scans efficiently. Previous WODS-based file systems have shown promise but have been hampered in several ways, which BetrFS mitigates or eliminates altogether. For ex- ample, previous WODS-based file systems were implemented in user space using FUSE, which superimposes many reads on a write-intensive workload, reducing the effectiveness of the WODS. This article also con- tributes several techniques for exploiting write-optimization within existing kernel infrastructure. BetrFS dramatically improves performance of certain types of large scans, such as recursive directory traversals, as well as performance of arbitrary microdata operations, such as file creates, metadata updates, and small writes to files. BetrFS can make small, random updates within a large file 2 orders of magnitude faster than other local file systems. BetrFS is an ongoing prototype effort and requires additional data-structure tuning to match current general-purpose file systems on some operations, including deletes, directory renames, and large sequential writes.
    [Show full text]
  • Toward a Better Understanding and Evaluation of Tree Structures on Flash Ssds
    Toward a Better Understanding and Evaluation of Tree Structures on Flash SSDs Diego Didona Nikolas Ioannou Radu Stoica IBM Research Europe IBM Research Europe IBM Research Europe [email protected] [email protected] [email protected] ∗ Kornilios Kourtis Independent researcher [email protected] ABSTRACT hinders their adoption. Hence, flash SSDs are expected to Solid-state drives (SSDs) are extensively used to deploy per- be the storage medium of choice for many applications in sistent data stores, as they provide low latency random ac- the short and medium term future [1]. cess, high write throughput, high data density, and low cost. Persistent tree data structures (PTSes) are widely used Tree-based data structures are widely used to build persis- to index large datasets. PTSes are particularly appeal- tent data stores, and indeed they lie at the backbone of ing, because, as opposed to hash-based structures, they al- many of the data management systems used in production low for storing the data in sorted order, thus enabling effi- and research today. cient implementations of range queries and iterators over In this paper, we show that benchmarking a persistent the dataset. Examples of PTSes are the log structured tree-based data structure on an SSD is a complex process, merge (LSM) tree [56], used, e.g., by RocksDB [25] and which may easily incur subtle pitfalls that can lead to an BigTable [13]; the B+Tree [17], used, e.g., by Db2 [33] and inaccurate performance assessment. At a high-level, these WiredTiger [53] (which is the default storage engine in Mon- pitfalls stem from the interaction of complex software run- goDB [52]); the Bw-tree [42], used, e.g., by Hekaton [22] and ning on complex hardware.
    [Show full text]
  • Storage Solutions for Big Data Systems: a Qualitative Study and Comparison
    Storage Solutions for Big Data Systems: A Qualitative Study and Comparison Samiya Khana,1, Xiufeng Liub, Syed Arshad Alia, Mansaf Alama,2 aJamia Millia Islamia, New Delhi, India bTechnical University of Denmark, Denmark Highlights Provides a classification of NoSQL solutions on the basis of their supported data model, which may be data- oriented, graph, key-value or wide-column. Performs feature analysis of 80 NoSQL solutions in view of technology selection criteria for big data systems along with a cumulative evaluation of appropriate and inappropriate use cases for each of the data model. Classifies big data file formats into five categories namely text-based, row-based, column-based, in-memory and data storage services. Compares available data file formats, analyzing benefits and shortcomings, and use cases for each data file format. Evaluates the challenges associated with shift of next-generation big data storage towards decentralized storage and blockchain technologies. Abstract Big data systems‘ development is full of challenges in view of the variety of application areas and domains that this technology promises to serve. Typically, fundamental design decisions involved in big data systems‘ design include choosing appropriate storage and computing infrastructures. In this age of heterogeneous systems that integrate different technologies for optimized solution to a specific real-world problem, big data system are not an exception to any such rule. As far as the storage aspect of any big data system is concerned, the primary facet in this regard is a storage infrastructure and NoSQL seems to be the right technology that fulfills its requirements. However, every big data application has variable data characteristics and thus, the corresponding data fits into a different data model.
    [Show full text]
  • Betrfs: a Right-Optimized Write-Optimized File System
    BetrFS: A Right-Optimized Write-Optimized File System William Jannen, Jun Yuan, Yang Zhan, Amogh Akshintala, John Esmet∗, Yizheng Jiao, Ankur Mittal, Prashant Pandey, Phaneendra Reddy, Leif Walsh∗, Michael Bender, Martin Farach-Colton†, Rob Johnson, Bradley C. Kuszmaul‡, and Donald E. Porter Stony Brook University, ∗Tokutek Inc., †Rutgers University, and ‡Massachusetts Institute of Technology Abstract (microwrites). Examples include email delivery, creat- The Be -tree File System, or BetrFS, (pronounced ing lock files for an editing application, making small “better eff ess”) is the first in-kernel file system to use a updates to a large file, or updating a file’s atime. The un- write-optimized index. Write optimized indexes (WOIs) derlying problem is that many standard data structures in are promising building blocks for storage systems be- the file-system designer’s toolbox optimize for one case cause of their potential to implement both microwrites at the expense of another. and large scans efficiently. Recent advances in write-optimized indexes (WOI) [4, Previous work on WOI-based file systems has shown 8–10, 23, 27, 28] are exciting because they have the po- promise but has also been hampered by several open tential to implement both efficient microwrites and large problems, which this paper addresses. For example, scans. The key strength of the best WOIs is that they can FUSE issues many queries into the file system, su- ingest data up to two orders of magnitude faster than B- perimposing read-intensive workloads on top of write- trees while matching or improving on the B-tree’s point- intensive ones, thereby reducing the effectiveness of and range-query performance [4, 9].
    [Show full text]
  • Fractal Tree Indexes Theory to Practice Percona Live London 2013
    ® Fractal Tree Indexes Theory to Practice Percona Live London 2013 Tim Callaghan, Tokutek [email protected] @tmcallaghan ® Tuesday, November 12, 13 Ever seen this? IO Utilization Graph, performance is IO limited ® Tuesday, November 12, 13 Who is Tokutek? Tokutek builds high- performance database Developer Interface" software! " TokuDB - storage engine for Storage Engine" MySQL and MariaDB HDD & SSD! TokuMX - storage engine for storage" MongoDB ® Tuesday, November 12, 13 Who am I? • 17 year database consumer • schema design, development, deployment • database administration + infrastructure • mostly Oracle • 5 year database producer • 2 years @ VoltDB • 2+ years @ Tokutek ® Tuesday, November 12, 13 Housekeeping • Feedback is important to me • Ideas for Webinars or Presentations? • Who’s using MongoDB? • Anyone using TokuDB or TokuMX? • Please ask questions ® Tuesday, November 12, 13 Agenda • Why Fractal Tree indexes are cool ® • What they enable in MySQL (TokuDB) ® • What they enable in MongoDB (TokuMX) • Q+A ® Tuesday, November 12, 13 Indexing: B-trees and Fractal Tree Indexes ® Tuesday, November 12, 13 B-trees ® Tuesday, November 12, 13 B-tree Overview - vocabulary Pivots Pointers Internal Nodes - Path to data Leaf Nodes - Actual Data - Sorted ® Tuesday, November 12, 13 B-tree Overview - example 22 10 99 2, 3, 4 10,20 22,25 99 * Pivot Rule is >= ® Tuesday, November 12, 13 B-tree Overview - search “Find 25” 22 10 99 2, 3, 4 10,20 22,25 99 ® Tuesday, November 12, 13 B-tree Overview - insert “Insert 15” 22 10 99 2, 3, 4 10,15,20 22,25 99
    [Show full text]
  • Toward a Better Understanding and Evaluation Of
    Toward a Better Understanding and Evaluation of Tree Structures on Flash SSDs Diego Didona, Nikolas Ioannou, Radu Stoica Kornilios Kourtis∗ IBM Research Zurich Cilium Rüschlikon, Switzerland Zurich, Switzerland ddi,nio,[email protected] [email protected] ABSTRACT from a technology density standpoint, and have a high cost per GB, Solid-state drives (SSDs) are extensively used to deploy persistent which significantly hinders their adoption. Hence, flash SSDsare data stores, as they provide low latency random access, high write expected to be the storage medium of choice for many applications throughput, high data density, and low cost. Tree-based data struc- in the short and medium term [19]. tures are widely used to build persistent data stores, and indeed Persistent tree data structures (PTSes) are widely used to index they lie at the backbone of many of the data management systems large datasets. PTSes are particularly appealing, because, as opposed used in production and research today. to hash-based structures, they allow data to be stored in sorted We show that benchmarking a persistent tree-based data struc- order, thus enabling efficient implementations of range queries and ture on an SSD is a complex process, which may easily incur subtle iterators over the dataset. Examples of PTSes are the log structured pitfalls that can lead to an inaccurate performance assessment. At merge (LSM) tree [55], used, e.g., by RocksDB [27] and BigTable [10]; a high-level, these pitfalls stem from the interaction of complex the B+Tree [14], used, e.g., by Db2 [35] and WiredTiger [52] (which software running on complex hardware.
    [Show full text]
  • Bivariate, Cluster and Suitability Analysis of Nosql Solutions for Different Application Areas
    Bivariate, Cluster and Suitability Analysis of NoSQL Solutions for Different Application Areas Samiya Khana,1, Xiufeng Liub, Syed Arshad Alia, Mansaf Alama,2 aJamia Millia Islamia, New Delhi, India bTechnical University of Denmark, Denmark Highlights Performs feature analysis of 80 NoSQL solutions in view of technology selection criteria for big data systems and evaluates applications that use one of more of the mentioned NoSQL solutions. Presents quantitative analysis of a dataset created from qualitative analysis of 80 NoSQL solutions, investigating relationships between the chosen features. Proposes a classification scheme that uses 9 features, which are ‘supported data model’ (document-oriented, graph, key-value and wide-column), CAP (consistency, availability and partition tolerance) characteristics and free/proprietary ownership, on the basis of results obtained for k-modes clustering of the dataset. Determines relevant features for each class of applications and proposes a prediction model for determining the suitability of a NoSQL solution for a class of applications. Abstract Big data systems‘ development is full of challenges in view of the variety of application areas and domains that this technology promises to serve. Typically, fundamental design decisions involved in big data systems‘ design include choosing appropriate storage and computing infrastructures. In this age of heterogeneous systems that integrate different technologies for development of an optimized solution to a specific real-world problem, big data systems are not an exception to any such rule. As far as the storage aspect of any big data system is concerned, the primary facet in this regard is a storage infrastructure and NoSQL is the right technology that fulfills its requirements.
    [Show full text]