<p><a href="https://yahoodevelopers.tumblr.com/post/178045146133/introducing-oak-an-open-source-scalable-key-value" class="tumblr_blog">yahoodevelopers</a>:</p><blockquote> <p>By Dmitry Basin, Edward Bortnikov, Anastasia Braginsky, Eshcar Hillel, Idit Keidar, Hagar Meir, Gali Sheffi</p> <p>Real-time analytics applications are on the rise. Modern decision support and machine intelligence engines strive to continuously ingest large volumes of data while providing up-to-date insights with minimum delay. For example, in <a href="http://www.flurry.com/">Flurry Analytics</a>, an Oath service which provides mobile developers with rich tools to explore user behavior in real time, it only takes seconds to reflect the events that happened on mobile devices in its numerous dashboards. The scalability demand is immense – as of late 2017, <a href="http://flurrymobile.tumblr.com/post/169545749110/state-of-mobile-2017-mobile-stagnates">the Flurry SDK was installed on 2.6B devices and monitored 1M+ mobile apps</a>. Mobile data hits the Flurry backend at a huge rate, updates statistics across hundreds of dimensions, and becomes queryable immediately. Flurry harnesses the open-source distributed interactive analytics engine named <a href="http://druid.io/">Druid</a> to ingest data and serve queries at this massive rate. </p> <p>In order to minimize delays before data becomes available for analysis, technologies like Druid should avoid maintaining separate systems for data ingestion and query serving, and instead strive to do both within the same system. Doing so is nontrivial since one cannot compromise on overall correctness when multiple conflicting operations execute in parallel on modern multi-core CPUs. A promising approach is using <a href="https://www.amazon.com/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376">concurrent data structure</a> (CDS) algorithms which adapt traditional data structures to multiprocessor hardware. CDS implementations are thread-safe – that is, developers can use them exactly as sequential code while maintaining strong theoretical correctness guarantees. In recent years, CDS algorithms enabled dramatic application performance scaling and became popular programming tools. For example, Java programmers can use the <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentNavigableMap.html">ConcurrentNavigableMap</a> JDK implementations for the concurrent ordered key-value map abstraction that is instrumental in systems like Druid. </p> <p>Today, we are excited to share <a href="https://github.com/yahoo/oak">Oak</a>, a new open source project from Oath, available under the Apache License 2.0. The project was created by the Scalable Systems team at Yahoo Research. It extends upon our earlier research work, named <a href="https://dl.acm.org/citation.cfm?id=3018761">KiWi</a>. </p> <p>Oak is a Java package that implements OakMap – a concurrent ordered key-value map. OakMap’s API is similar to Java’s ConcurrentNavigableMap. Java developers will find it easy to switch most of their applications to it. OakMap provides the safety guarantees specified by ConcurrentNavigableMap’s programming model. However, it scales with the RAM and CPU resources well beyond the best-in-class ConcurrentNavigableMap implementations. For example, it compares favorably to Doug Lea’s seminal <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentSkipListMap.html">ConcurrentSkipListMap</a>, which is used by multiple big data platforms, including <a href="https://hbase.apache.org/">Apache HBase</a>, <a href="http://druid.io/">Druid</a>, <a href="https://github.com/Netflix/EVCache">EVCache</a>, etc. Our benchmarks show that OakMap harnesses 3x more memory, and runs 3x-5x faster on analytics workloads. </p> <p>OakMap’s implementation is very different from traditional implementations such as  ConcurrentSkipListMap. While the latter maintains all keys and values as individual Java objects, OakMap stores them in very large memory buffers allocated beyond the JVM-managed memory heap (hence the name Oak - abbr. Off-heap Allocated Keys). The access to the key-value pairs is provided by a lightweight two-level on-heap index. At its lower level, the references to keys are stored in contiguous chunks, each responsible for a distinct key range. The chunks themselves, which dominate the index footprint, are accessed through a lightweight top-level ConcurrentSkipListMap. The figure below illustrates OakMap’s data organization.</p> <figure data-orig-width="1280" data-orig-height="960" class="tmblr-full"><img src="https://66.media.tumblr.com/337ca872afdcf4b86d6a47051472a787/tumblr_inline_pf046lmN2K1w911gs_540.jpg" data-orig-width="1280" data-orig-height="960"/></figure><p><i>OakMap structure.</i><br/></p> <p>The maintenance of OakMap’s chunked index in a concurrent setting is the crux of its complexity as well as the key for its efficiency. Experiments have shown that our algorithm is advantageous in multiple ways:<br/></p> <p>1. <b>Memory scaling. </b>OakMap’s custom off-heap memory allocation alleviates the garbage collection (GC) overhead that plagues Java applications. Despite the permanent progress, modern Java GC algorithms do not practically scale beyond a few tens of GBs of memory, whereas OakMap scales beyond 128GB of off-heap RAM. </p> <p>2. <b>Query speed. </b>The chunk-based layout increases data locality, which speeds up both single-key lookups and range scans. All queries enjoy efficient, cache-friendly access, in contrast with permanent dereferencing in object-based maps. On top of these basic merits, OakMap provides safe direct access to its chunks, which avoids an extra copy for rebuilding the original key and value objects. Our benchmarks demonstrate OakMap’s performance benefits versus ConcurrentSkipListMap:</p> <blockquote> <p>A) Up to 2x throughput for ascending scans.</p> <p>B) Up to 5x throughput for descending scans. </p> <p>C) Up to 3x throughput for lookups.</p> </blockquote> <p>3. <b>Update speed. </b>Beyond avoiding the GC overhead typical for write-intensive workloads, OakMap optimizes the incremental maintenance of big complex values – for example, aggregate <a href="https://datasketches.github.io/">data sketches</a>, which are indispensable in systems like Druid. It adopts in situ computation on objects embedded in its internal chunks to avoid unnecessary data copy, yet again. In our benchmarks, OakMap achieves up to 1.8x data ingestion rate versus ConcurrentSkipListMap.</p> <p>With key-value maps being an extremely generic abstraction, it is easy to envision a variety of use cases for OakMap in large-scale analytics and machine learning applications – such as unstructured key-value storage, structured databases, in-memory caches, parameter servers, etc. For example, we are already working with the Druid community on <a href="https://github.com/apache/incubator-druid/pull/5732">rebuilding Druid’s core Incremental Index</a> component around OakMap, in order to boost its scalability and performance. </p> <p>We look forward to growing the Oak community! We invite you to explore the project, use OakMap in your applications, raise issues, suggest improvements, and <a href="https://github.com/yahoo/Oak/blob/master/CONTRIBUTING.md">contribute code</a>. If you have any questions, please feel free to send us a note on the Oak developers list: <a href="mailto:oakproject@googlegroups.com">oakproject@googlegroups.com</a>. It would be great to hear from you!</p> </blockquote>