DOCSLIB.ORG

Rocksdb…The Old Way…Log Structured Merge

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Rocksdb…The Old Way…Log Structured Merge TRocksDB Remi Brasga Sr. Software Engineer | Memory Storage Strategy Division Toshiba Memory America, Inc. Hi! I’m Remi (Remington Brasga). As a Sr. Software Engineer for the Memory Storage Strategy Division at Toshiba Memory America, Inc., I am dedicated to development and collaboration on open source software. I earned my B.S. and M.S. from University of California, Irvine. Today, I am here fresh from having my 3rd son who has kept me very busy the past few weeks. (thanks for letting me come here and rest!) Applications are King • Software is eating the world • Storage is “Defined by Software” – i.e., applications define how storage is used • Yet, applications do not always use storage wisely For Example, RocksDB RocksDB is a popular data storage engine …used by a wide range of database applications ArangoDB Ceph™ Cassandra® MariaDB® Python® MyRocks Rockset Cassandra is a registered trademark of The Apache Software Foundation. Ceph is a trademark of Red Hat, Inc. or its subsidiaries in the United States and other countries. Python is a registered trademark of the Python Software Foundation. MariaDB is a registered trademark of MariaDB in the European Union and other regions. All other company names, product names and service names may be trademarks of their respective companies. The Challenge of Rocks While highly effective as a data storage engine, RocksDB has some challenges for SSDs: Write Amplification is very large 20-30X (or more) as a result of the compaction layers rewriting the same data This can result in impact to SSD endurance. How does RocksDB work? Keys and Values are stored Data Key together in pairs. Level K+V0 As more data is added, these Level 1 pairs waterfall Target 1GB Level 2 through the levels. Target 10 GB Level 3 Target 100 GB Level 4 This waterfall occurs Target 1000 GB during each compaction. Let’s Demonstrate RocksDB…the Old Way…Log Structured Merge CPU Key & Value Key & Value Key & Value New key value database entries DRAM Saved to SSD in compaction level 1 Compaction Level 1 LSM Compaction Level 2 Compaction Level 3 RocksDB…the Old Way…Log Structured Merge CPU More writes to DRAM compaction level 1 Compaction Level 1 Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value LSM Compaction Level 2 Compaction Level 3 Compaction level 1 fills up RocksDB…the Old Way…Log Structured Merge CPU Consolidated for compaction level 2 DRAM Compaction level 1 is full; Compaction Level 1 Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value LSM Written to RAM… Compaction Level 2 Compaction Level 3 RocksDB…the Old Way…Log Structured Merge CPU Consolidated data written to compaction level 2 DRAM Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value Key & Value Application-generated write amplification Compaction Level 1 LSM Compaction Level 2 Compaction Level 3 RocksDB…the Old Way…Log Structured Merge CPU DRAM Compaction level 2 filling up Application-generated write amplification Compaction Level 1 LSM Compaction Level 2 KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKeyKey & & &Value Value Value KeyKey & & Value Value KeyKey & & Value Value KeyKey & & Value Value KeyKey & & Value Value KeyKey & & Value Value KeyKey & & Value Value KeyKey & & Value Value Compaction Level 3 RocksDB…the Old Way…Log Structured Merge CPU Written to DRAM, and consolidated DRAM Compaction level 2 fills up Compaction Level 1 LSM Compaction Level 2 Compaction Level 3 RocksDB…the Old Way…Log Structured Merge CPU DRAM Written to compaction Application-generated Compaction Level 1 level 3 LSM write amplification Compaction Level 2 Compaction Level 3 Result As you can see, • This results in rewriting data “that doesn’t change” during compaction • This can have a significant impact on SSD health and endurance The good news is… There is a better way Toshiba Memory America has re-architected RocksDB to solve this SSD endurance challenge Inspiration We looked at some of the academic work on Rocks – Major inspiration came from the “wisckey” from the university of Wisconsin WiscKey: Separating Keys from Values in SSD-conscious storage https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf Coding Work Significant code was involved to split the keys from the values • Replaced the LSM key value pairs with the ring buffer (for a Value Log - VLog) • The VLog is a large number of files, – with each file having about the same number of values as an SST* has keys • VLogFiles are organized into FIFO structures called VLogRings • One tricky issue - keeping track of the state of the VLog over a restart • Active recycling added to compactions to reduce instances of uncompacted files *SST=Stored String Table Coding Work Work involved managing the keys • While keys mostly are cached in memory • They still need to be written into LSM layers • Compactions still occur, – about one per second as usual but only on the keys • Coding for compaction involved – Compacting the keys – And cleaning up the stale data in the ring buffers Performance Tuning Tuning performance in the code was a challenge • Some changes made performance worse (against every expectation…) • The split keys and values approach needed new test cases • There are a number of new option settings to enable optimizations this added improvements to – Compaction picker improved ( to reduce need of active recycling ) – Write amp and space amp measuring – Bulk load efficiency Coding Merge Code Merge: RocksDB continues to evolve – TRocksDB is maintaining version compatibility with each current revision of RocksDB – TRocks is fully compatible and cross compiles with/into regular RocksDB code today – Once compiled Rocks or TRocks can be enabled with option settings How does TRocksDB work? Keys and Values Data Value Log are split Key Value is unaffected by compactions Level K Keys go into compaction 0 layers (in memory) Level 1 VV Target 1GB Level 2 Target 10 GB Values are stored Level 3 separately into Target 100 GB Level 4 a ring buffer Target 1000 GB The Improved TRocksDB Method TRocksDB…the New Way Ring Buffer, Separate Keys/Values CPU Key Value Key Value Key Value Key Value Create new DRAM database entries LSM Ring Buffer TRocksDB…the New Way Ring Buffer, Separate Keys/Values CPU Key Value Key Value Key Value Key Value Lookups are DRAM lightening fast LSM with keys cached in DRAM Keys stored separately (cacheable) Ring Buffer SSD endurance improved Write Values to Ring via lowered Buffer Write Amp Our Goal during Development Improved(reduced) Write Amplification with the same or better performance Improved Write Amplification Write Amplification (lower is better) 4.9 5 TRocks 1.2.5.23 Rocks FB 6.4 4 3 2.1 2 1 1 0.6 0.6 1 -57% -40% -40% 0 Test 1: Test 2: Test 3: Random Bulk Load Bulk Sequential Load Random Overwrites Performance results based on internal Toshiba Memory testing. Benchmark tests were developed by Facebook and generated in July 2018. They measure RocksDB performance when data resides on flash storage and tested using the newest release RocksDB 6.1.fb. The benchmark information and test descriptions are available at https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks. Same or Better Performance Performance Comparison (lower is better) Seconds TRocks 1.2.5.23 Rocks FB 6.4 155,081 160,000 140,000 118,244 120,000 100,000 80,000 -24% 60,000 29,742 40,000 21,565 9,890 6,938 9,595 20,000 -28% 6,155 -11% -3% 0 Test 1: Test 2: Test 3: Test 4: Random Bulk Load Bulk Sequential Load Random Overwrites Random Key Reads Performance results based on internal Toshiba Memory testing. Benchmark tests were developed by Facebook and generated in July 2018. They measure RocksDB performance when data resides on flash storage and tested using the newest release RocksDB 6.1.fb. The benchmark information and test descriptions are available at https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks. Tuning and Optimization • Every database is different • Rocks and TRocks have a wide range settings / options to optimize the database • These settings are often confusing or “left in default” GitHub is an exclusive trademark registered in the United States by GitHub, Inc. All other company names, product names and service names may be trademarks of their respective companies. Tuning and Optimization • Toshiba Memory America has created a “tuning” tool Fill in the blanks – It is on a Google spreadsheet • Available from the GitHub® – Easy to use - just fill in the blanks – It generates known good settings Generate “known-good” options settings GitHub is an exclusive trademark registered in the United States by GitHub, Inc. All other company names, product names and service names may be trademarks of their respective companies. Call to Action Download Test Use Enjoy ! Join the project improve and contribute to the code Developed by Toshiba Memory America (Which will be renamed KIOXIA America, Inc. as of October 1, 2019) Open Source Improved write amplification = SSD last longer with the same or better performance Available today: https://github.com/ToshibaMemoryAmerica All company names, product names and service names may be trademarks of their respective companies. © 2019 Toshiba Memory America, Inc. All rights reserved. Information, including product pricing and specifications, content of services, and contact information is current and believed to be accurate on the date of the announcement, but is subject to change without prior notice. Technical and application information contained here is subject to the most recent applicable Toshiba Memory product specifications..
Load more

Recommended publications
  • NUMA-Aware Thread Migration for High Performance NVMM File Systems
    NUMA-Aware Thread Migration for High Performance NVMM File Systems Ying Wang, Dejun Jiang and Jin Xiong SKL Computer Architecture, ICT, CAS; University of Chinese Academy of Sciences fwangying01, jiangdejun, [email protected] Abstract—Emerging Non-Volatile Main Memories (NVMMs) out considering the NVMM usage on NUMA nodes. Besides, provide persistent storage and can be directly attached to the application threads accessing file system rely on the default memory bus, which allows building file systems on non-volatile operating system thread scheduler, which migrates thread only main memory (NVMM file systems). Since file systems are built on memory, NUMA architecture has a large impact on their considering CPU utilization. These bring remote memory performance due to the presence of remote memory access and access and resource contentions to application threads when imbalanced resource usage. Existing works migrate thread and reading and writing files, and thus reduce the performance thread data on DRAM to solve these problems. Unlike DRAM, of NVMM file systems. We observe that when performing NVMM introduces extra latency and lifetime limitations. This file reads/writes from 4 KB to 256 KB on a NVMM file results in expensive data migration for NVMM file systems on NUMA architecture. In this paper, we argue that NUMA- system (NOVA [47] on NVMM), the average latency of aware thread migration without migrating data is desirable accessing remote node increases by 65.5 % compared to for NVMM file systems. We propose NThread, a NUMA-aware accessing local node. The average bandwidth is reduced by thread migration module for NVMM file system.
    [Show full text]
  • Unravel Data Systems Version 4.5
    UNRAVEL DATA SYSTEMS VERSION 4.5 Component name Component version name License names jQuery 1.8.2 MIT License Apache Tomcat 5.5.23 Apache License 2.0 Tachyon Project POM 0.8.2 Apache License 2.0 Apache Directory LDAP API Model 1.0.0-M20 Apache License 2.0 apache/incubator-heron 0.16.5.1 Apache License 2.0 Maven Plugin API 3.0.4 Apache License 2.0 ApacheDS Authentication Interceptor 2.0.0-M15 Apache License 2.0 Apache Directory LDAP API Extras ACI 1.0.0-M20 Apache License 2.0 Apache HttpComponents Core 4.3.3 Apache License 2.0 Spark Project Tags 2.0.0-preview Apache License 2.0 Curator Testing 3.3.0 Apache License 2.0 Apache HttpComponents Core 4.4.5 Apache License 2.0 Apache Commons Daemon 1.0.15 Apache License 2.0 classworlds 2.4 Apache License 2.0 abego TreeLayout Core 1.0.1 BSD 3-clause "New" or "Revised" License jackson-core 2.8.6 Apache License 2.0 Lucene Join 6.6.1 Apache License 2.0 Apache Commons CLI 1.3-cloudera-pre-r1439998 Apache License 2.0 hive-apache 0.5 Apache License 2.0 scala-parser-combinators 1.0.4 BSD 3-clause "New" or "Revised" License com.springsource.javax.xml.bind 2.1.7 Common Development and Distribution License 1.0 SnakeYAML 1.15 Apache License 2.0 JUnit 4.12 Common Public License 1.0 ApacheDS Protocol Kerberos 2.0.0-M12 Apache License 2.0 Apache Groovy 2.4.6 Apache License 2.0 JGraphT - Core 1.2.0 (GNU Lesser General Public License v2.1 or later AND Eclipse Public License 1.0) chill-java 0.5.0 Apache License 2.0 Apache Commons Logging 1.2 Apache License 2.0 OpenCensus 0.12.3 Apache License 2.0 ApacheDS Protocol
    [Show full text]
  • Artificial Intelligence for Understanding Large and Complex
    Artificial Intelligence for Understanding Large and Complex Datacenters by Pengfei Zheng Department of Computer Science Duke University Date: Approved: Benjamin C. Lee, Advisor Bruce M. Maggs Jeffrey S. Chase Jun Yang Dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science in the Graduate School of Duke University 2020 Abstract Artificial Intelligence for Understanding Large and Complex Datacenters by Pengfei Zheng Department of Computer Science Duke University Date: Approved: Benjamin C. Lee, Advisor Bruce M. Maggs Jeffrey S. Chase Jun Yang An abstract of a dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science in the Graduate School of Duke University 2020 Copyright © 2020 by Pengfei Zheng All rights reserved except the rights granted by the Creative Commons Attribution-Noncommercial Licence Abstract As the democratization of global-scale web applications and cloud computing, under- standing the performance of a live production datacenter becomes a prerequisite for making strategic decisions related to datacenter design and optimization. Advances in monitoring, tracing, and profiling large, complex systems provide rich datasets and establish a rigorous foundation for performance understanding and reasoning. But the sheer volume and complexity of collected data challenges existing techniques, which rely heavily on human intervention, expert knowledge, and simple statistics. In this dissertation, we address this challenge using artificial intelligence and make the case for two important problems, datacenter performance diagnosis and datacenter workload characterization. The first thrust of this dissertation is the use of statistical causal inference and Bayesian probabilistic model for datacenter straggler diagnosis.
    [Show full text]
  • Characterizing, Modeling, and Benchmarking Rocksdb Key-Value
    Characterizing, Modeling, and Benchmarking RocksDB Key-Value Workloads at Facebook Zhichao Cao, University of Minnesota, Twin Cities, and Facebook; Siying Dong and Sagar Vemuri, Facebook; David H.C. Du, University of Minnesota, Twin Cities https://www.usenix.org/conference/fast20/presentation/cao-zhichao This paper is included in the Proceedings of the 18th USENIX Conference on File and Storage Technologies (FAST ’20) February 25–27, 2020 • Santa Clara, CA, USA 978-1-939133-12-0 Open access to the Proceedings of the 18th USENIX Conference on File and Storage Technologies (FAST ’20) is sponsored by Characterizing, Modeling, and Benchmarking RocksDB Key-Value Workloads at Facebook Zhichao Cao†‡ Siying Dong‡ Sagar Vemuri‡ David H.C. Du† †University of Minnesota, Twin Cities ‡Facebook Abstract stores is still challenging. First, there are very limited studies of real-world workload characterization and analysis for KV- Persistent key-value stores are widely used as building stores, and the performance of KV-stores is highly related blocks in today’s IT infrastructure for managing and storing to the workloads generated by applications. Second, the an- large amounts of data. However, studies of characterizing alytic methods for characterizing KV-store workloads are real-world workloads for key-value stores are limited due to different from the existing workload characterization stud- the lack of tracing/analyzing tools and the difficulty of collect- ies for block storage or file systems. KV-stores have simple ing traces in operational environments. In this paper, we first but very different interfaces and behaviors. A set of good present a detailed characterization of workloads from three workload collection, analysis, and characterization tools can typical RocksDB production use cases at Facebook: UDB (a benefit both developers and users of KV-stores by optimizing MySQL storage layer for social graph data), ZippyDB (a dis- performance and developing new functions.
    [Show full text]
  • Myrocks in Mariadb
    MyRocks in MariaDB Sergei Petrunia <[email protected]> MariaDB Shenzhen Meetup November 2017 2 What is MyRocks ● #include <Yoshinori’s talk> ● This talk is about MyRocks in MariaDB 3 MyRocks lives in Facebook’s MySQL branch ● github.com/facebook/mysql-5.6 – Will call this “FB/MySQL” ● MyRocks lives there in storage/rocksdb ● FB/MySQL is easy to use if you are Facebook ● Not so easy if you are not :-) 4 FB/mysql-5.6 – user perspective ● No binaries, no packages – Compile yourself from source ● Dependencies, etc. ● No releases – (Is the latest git revision ok?) ● Has extra features – e.g. extra counters “confuse” monitoring tools. 5 FB/mysql-5.6 – dev perspective ● Targets a CentOS-type OS – Compiler, cmake version, etc. – Others may or may not [periodically] work ● MariaDB/Percona file pull requests to fix ● Special command to compile – https://github.com/facebook/mysql-5.6/wiki/Build-Steps ● Special command to run tests – Test suite assumes a big machine ● Some tests even a release build 6 Putting MyRocks in MariaDB ● Goals – Wider adoption – Ease of use – Ease of development – Have MyRocks in MariaDB ● Use it with MariaDB features ● Means – Port MyRocks into MariaDB – Provide binaries and packages 7 Status of MyRocks in MariaDB 8 Status of MyRocks in MariaDB ● MariaDB 10.2 is GA (as of May, 2017) ● It includes an ALPHA version of MyRocks plugin – Working to improve maturity ● It’s a loadable plugin (ha_rocksdb.so) ● Packages – Bintar, deb, rpm, win64 zip + MSI – deb/rpm have MyRocks .so and tools in a separate package. 9 Packaging for MyRocks in MariaDB 10 MyRocks and RocksDB library ● MyRocks is tied RocksDB@revno MariaDB – RocksDB is a github submodule – No compatibility with other versions MyRocks ● RocksDB is always compiled with RocksDB MyRocks S Z n ● l i And linked-in statically a b p ● p Distros have a RocksDB package y – Not using it.
    [Show full text]
  • Dmon: Efficient Detection and Correction of Data Locality
    DMon: Efficient Detection and Correction of Data Locality Problems Using Selective Profiling Tanvir Ahmed Khan and Ian Neal, University of Michigan; Gilles Pokam, Intel Corporation; Barzan Mozafari and Baris Kasikci, University of Michigan https://www.usenix.org/conference/osdi21/presentation/khan This paper is included in the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation. July 14–16, 2021 978-1-939133-22-9 Open access to the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. DMon: Efficient Detection and Correction of Data Locality Problems Using Selective Profiling Tanvir Ahmed Khan Ian Neal Gilles Pokam Barzan Mozafari University of Michigan University of Michigan Intel Corporation University of Michigan Baris Kasikci University of Michigan Abstract cally at run time. In fact, as we (§6.2) and others [2,15,20,27] Poor data locality hurts an application’s performance. While demonstrate, compiler-based techniques can sometimes even compiler-based techniques have been proposed to improve hurt performance when the assumptions made by those heuris- data locality, they depend on heuristics, which can sometimes tics do not hold in practice. hurt performance. Therefore, developers typically find data To overcome the limitations of static optimizations, the locality issues via dynamic profiling and repair them manually. systems community has invested substantial effort in devel- Alas, existing profiling techniques incur high overhead when oping dynamic profiling tools [28,38, 57,97, 102]. Dynamic used to identify data locality problems and cannot be deployed profilers are capable of gathering detailed and more accurate in production, where programs may exhibit previously-unseen execution information, which a developer can use to identify performance problems.
    [Show full text]
  • Real-Time LSM-Trees for HTAP Workloads
    Real-Time LSM-Trees for HTAP Workloads Hemant Saxena Lukasz Golab University of Waterloo University of Waterloo [email protected] [email protected] Stratos Idreos Ihab F. Ilyas Harvard University University of Waterloo [email protected] [email protected] ABSTRACT We observe that a Log-Structured Merge (LSM) Tree is a natu- Real-time data analytics systems such as SAP HANA, MemSQL, ral fit for a lifecycle-aware storage engine. LSM-Trees are widely and IBM Wildfire employ hybrid data layouts, in which dataare used in key-value stores (e.g., Google’s BigTable and LevelDB, Cas- stored in different formats throughout their lifecycle. Recent data sandra, Facebook’s RocksDB), RDBMSs (e.g., Facebook’s MyRocks, are stored in a row-oriented format to serve OLTP workloads and SQLite4), blockchains (e.g., Hyperledger uses LevelDB), and data support high data rates, while older data are transformed to a stream and time-series databases (e.g., InfluxDB). While Cassandra column-oriented format for OLAP access patterns. We observe that and RocksDB can simulate columnar storage via column families, a Log-Structured Merge (LSM) Tree is a natural fit for a lifecycle- we are not aware of any lifecycle-aware LSM-Trees in which the aware storage engine due to its high write throughput and level- storage layout can change throughout the lifetime of the data. We oriented structure, in which records propagate from one level to fill this gap in our work, by extending the capabilities ofLSM- the next over time. To build a lifecycle-aware storage engine using based systems to efficiently serve real-time analytics and HTAP an LSM-Tree, we make a crucial modification to allow different workloads.
    [Show full text]
  • As Focused on Software Tools That Support Software Engineering, Along with Data Structures and Algorithms Generally
    PETER C DILLINGER, Ph.D. 2110 N 89th St [email protected] Seattle WA 98103 http://www.peterd.org 404-509-4879 Overview My work in software has focused on software tools that support software engineering, along with data structures and algorithms generally. My core strength is seeing many paths to “success,” so I'm often the person consulted when others think they're stuck. Highlights ♦ Key developer and project lead in adapting and extending the legendary Coverity static analysis engine, for C/C++ bug finding, to find bugs with high accuracy in Java, C#, JavaScript, PHP, Python, Ruby, Swift, and VB. https://www.synopsys.com/blogs/software-security/author/pdillinger/ ♦ Inventor of a fast, scalable, and accurate method of detecting mistyped identifiers in dynamic languages such as JavaScript, PHP, Python, and Ruby without use of a natural language dictionary. Patent pending, app# 20170329697. Coverity feature: https://stackoverflow.com/a/34796105 ♦ Did the impossible with git: on wanting to “copy with history” as part of a refactoring, I quickly developed a way to do it despite the consensus wisdom. https://stackoverflow.com/a/44036771 ♦ Did the impossible with Bloom filters: made the data structure simultaneously fast and accurate with a simple hashing technique, now used in tools including LevelDB and RocksDB. https://en.wikipedia.org/wiki/Bloom_filter (Search "Dillinger") ♦ Early coder / Linux user: started BASIC in 1st grade; first game hack in 3rd grade; learned C in middle school; wrote Tetris in JavaScript in high school (1997); steady Linux user since 1998. Work Coverity, August 2009 to October 2017, acquired by Synopsys in 2014 Software developer, tech lead, and manager for static and dynamic program analysis projects.
    [Show full text]
  • Reducing DRAM Footprint with NVM in Facebook (Eurosys'18)
    Reducing DRAM Footprint with NVM in Facebook (EuroSys’18) Assaf Eisenman1, Darryl Gardner2, Islam AbdelRahman2, Jens Axboe2, Siying Dong2, Kim Hazelwood2, Chris Petersen2, Asaf Cidon1, Sachin Katti1 1Stanford University 2Facebook, Inc. Extended Abstract first obvious step would be to simply reduce the DRAM Modern key-value stores like RocksDB and LevelDB are capacity on a MyRocks server configuration. Unfortunately, highly dependent on DRAM, even when using a persistent reducing the amount of DRAM degrades the performance storage medium (e.g. flash) for storing data. Since DRAM is of MyRocks. To demonstrate this point, Figure 1 shows that still about 1000× faster than flash, these systems typically when reducing the DRAM cache in MyRocks from 96 GB to leverage DRAM for caching hot indices and objects. 16 GB, the mean latency increases by 2×, and P99 latency MySQL databases are often implemented on top of these increases by 2.2×. key-value stores. For example, MyRocks, which is built on NVM offers the potential to reduce the dependence of top of RocksDB, is the primary MySQL database in Face- systems like MyRocks on DRAM. NVM comes in two book and is used extensively in data center environments. forms: a more expensive byte-addressable form, and a less MyRocks stores petabytes of data and is used to serve real- expensive block device. Since our goal is to reduce total cost time user activities across large-scale web applications [6]. of ownership, we use NVM as a block device, which has a In order to achieve high throughput and low latency, My- cost about an order of magnitude less per bit than DRAM.
    [Show full text]
  • Realtime Data Processing at Facebook
    Realtime Data Processing at Facebook Guoqiang Jerry Chen, Janet L. Wiener, Shridhar Iyer, Anshul Jaiswal, Ran Lei Nikhil Simha, Wei Wang, Kevin Wilfong, Tim Williamson, and Serhat Yilmaz Facebook, Inc. ABSTRACT dural language (such as C++ or Java) essential? How Realtime data processing powers many use cases at Face- fast can a user write, test, and deploy a new applica- book, including realtime reporting of the aggregated, anon- tion? ymized voice of Facebook users, analytics for mobile applica- • Performance: How much latency is ok? Milliseconds? tions, and insights for Facebook page administrators. Many Seconds? Or minutes? How much throughput is re- companies have developed their own systems; we have a re- quired, per machine and in aggregate? altime data processing ecosystem at Facebook that handles hundreds of Gigabytes per second across hundreds of data • Fault-tolerance: what kinds of failures are tolerated? pipelines. What semantics are guaranteed for the number of times Many decisions must be made while designing a realtime that data is processed or output? How does the system stream processing system. In this paper, we identify five store and recover in-memory state? important design decisions that affect their ease of use, per- formance, fault tolerance, scalability, and correctness. We • Scalability: Can data be sharded and resharded to pro- compare the alternative choices for each decision and con- cess partitions of it in parallel? How easily can the sys- trast what we built at Facebook to other published systems. tem adapt to changes in volume, both up and down? Our main decision was targeting seconds of latency, not Can it reprocess weeks worth of old data? milliseconds.
    [Show full text]
  • Optimizing Space Amplification in Rocksdb
    Optimizing Space Amplification in RocksDB Siying Dong1, Mark Callaghan1, Leonidas Galanis1, Dhruba Borthakur1, Tony Savor1 and Michael Stumm2 1Facebook, 1 Hacker Way, Menlo Park, CA USA 94025 {siying.d, mcallaghan, lgalanis, dhruba, tsavor}@fb.com 2Dept. Electrical and Computer Engineering, University of Toronto, Canada M8X 2A6 [email protected] ABSTRACT Facebook has one of the largest MySQL installations in RocksDB is an embedded, high-performance, persistent key- the world, storing many 10s of petabytes of online data. The value storage engine developed at Facebook. Much of our underlying storage engine for Facebook's MySQL instances current focus in developing and configuring RocksDB is to is increasingly being switched over from InnoDB to My- give priority to resource efficiency instead of giving priority Rocks, which in turn is based on Facebook's RocksDB. The to the more standard performance metrics, such as response switchover is primarily motivated by the fact that MyRocks time latency and throughput, as long as the latter remain uses half the storage InnoDB needs, and has higher average acceptable. In particular, we optimize space efficiency while transaction throughput, yet has only marginally worse read ensuring read and write latencies meet service-level require- latencies. ments for the intended workloads. This choice is motivated RocksDB is an embedded, high-performance, persistent key-value storage system [1] that was developed by Face- by the fact that storage space is most often the primary 1 bottleneck when using Flash SSDs under typical production book after forking the code from Google's LevelDB [2, 3]. workloads at Facebook. RocksDB uses log-structured merge RocksDB was open-sourced in 2013 [5].
    [Show full text]
  • Towards Left Duff S Mdbg Holt Winters Gai Incl Tax Drupal Fapi Icici
    jimportneoneo_clienterrorentitynotfoundrelatedtonoeneo_j_sdn neo_j_traversalcyperneo_jclientpy_neo_neo_jneo_jphpgraphesrelsjshelltraverserwritebatchtransactioneventhandlerbatchinsertereverymangraphenedbgraphdatabaseserviceneo_j_communityjconfigurationjserverstartnodenotintransactionexceptionrest_graphdbneographytransactionfailureexceptionrelationshipentityneo_j_ogmsdnwrappingneoserverbootstrappergraphrepositoryneo_j_graphdbnodeentityembeddedgraphdatabaseneo_jtemplate neo_j_spatialcypher_neo_jneo_j_cyphercypher_querynoe_jcypherneo_jrestclientpy_neoallshortestpathscypher_querieslinkuriousneoclipseexecutionresultbatch_importerwebadmingraphdatabasetimetreegraphawarerelatedtoviacypherqueryrecorelationshiptypespringrestgraphdatabaseflockdbneomodelneo_j_rbshortpathpersistable withindistancegraphdbneo_jneo_j_webadminmiddle_ground_betweenanormcypher materialised handaling hinted finds_nothingbulbsbulbflowrexprorexster cayleygremlintitandborient_dbaurelius tinkerpoptitan_cassandratitan_graph_dbtitan_graphorientdbtitan rexter enough_ram arangotinkerpop_gremlinpyorientlinkset arangodb_graphfoxxodocumentarangodborientjssails_orientdborientgraphexectedbaasbox spark_javarddrddsunpersist asigned aql fetchplanoriento bsonobjectpyspark_rddrddmatrixfactorizationmodelresultiterablemlibpushdownlineage transforamtionspark_rddpairrddreducebykeymappartitionstakeorderedrowmatrixpair_rddblockmanagerlinearregressionwithsgddstreamsencouter fieldtypes spark_dataframejavarddgroupbykeyorg_apache_spark_rddlabeledpointdatabricksaggregatebykeyjavasparkcontextsaveastextfilejavapairdstreamcombinebykeysparkcontext_textfilejavadstreammappartitionswithindexupdatestatebykeyreducebykeyandwindowrepartitioning
    [Show full text]