<p><a href="https://yahoodevelopers.tumblr.com/post/180863698576/a-new-chapter-for-omid" class="tumblr_blog">yahoodevelopers</a>:</p><blockquote> <p><i>By Ohad Shacham, Yonatan Gottesman, Edward Bortnikov<br/>Scalable Systems Research, Verizon/Oath</i></p> <p><a href="https://omid.incubator.apache.org/">Omid</a>, an open source transaction processing platform for Big Data, was born as a research project at Yahoo (now part of Verizon), and became an Apache Incubator project in 2015. Omid complements Apache HBase, a distributed key-value store in Apache Hadoop suite, with a capability to clip multiple operations into logically indivisible (atomic) units named transactions. This programming model has been extremely popular since the dawn of SQL databases, and has more recently become indispensable in the NoSQL world. For example, it is the centerpiece for dynamic content indexing of search and media products at Verizon, powering a web-scale content management platform since 2015. </p> <p>Today, we are excited to share a new chapter in Omid’s history. Thanks to its scalability, reliability, and speed, Omid has been selected as transaction management provider for <a href="https://phoenix.apache.org/">Apache Phoenix</a>, a real-time converged OLTP and analytics platform for Hadoop. Phoenix provides a standard SQL interface to HBase key-value storage, which is much simpler and in many cases more performant than the native HBase API. With Phoenix, big data and machine learning developers get the best of all worlds: increased productivity coupled with high scalability. Phoenix is designed to scale to 10,000 query processing nodes in one instance and is expected to process hundreds of thousands or even millions of transactions per second (tps). It is <a href="https://phoenix.apache.org/who_is_using.html">widely used in the industry</a>, including by Alibaba, Bloomberg, PubMatic, Salesforce, Sogou and many others.</p> <p>We have just released a new and significantly improved version of Omid (1.0.0), the first major release since its original launch. We have extended the system with multiple functional and performance features to power a modern SQL database technology, ready for deployment on both private and public cloud platforms. </p> <p>A few of the significant innovations include:</p> <p><b>Protocol re-design for low latency </b></p> <p>The early version of Omid was designed for use in web-scale data pipeline systems, which are throughput-oriented by nature. We re-engineered Omid’s internals to now support new ultra-low-latency OLTP (online transaction processing) applications, like messaging and algo-trading. The new protocol, Omid Low Latency (Omid LL), dissipates Omid’s major architectural bottleneck. It reduces the latency of short transactions by 5 times under light load, and by 10 to 100 times under heavy load. It also scales the overall system throughput to 550,000 tps while remaining within real-time latency SLAs. The figure below illustrates Omid LL scaling versus the previous version of Omid, for short and long transactions. </p> <figure data-orig-width="2973" data-orig-height="2067" class="tmblr-full"><img src="https://66.media.tumblr.com/9e6c4ca611a2cc882f608afdaf631315/tumblr_inline_pjalg3iWmc1w911gs_540.jpg" alt="image" data-orig-width="2973" data-orig-height="2067"/></figure><p><i>Throughput vs latency, transaction size=1 op</i></p> <figure data-orig-width="2973" data-orig-height="2067" class="tmblr-full"><img src="https://66.media.tumblr.com/4b497e02e0d8f17b337a0fb83c847095/tumblr_inline_pjalg3iovp1w911gs_540.jpg" alt="image" data-orig-width="2973" data-orig-height="2067"/></figure><p><i>Throughput vs latency, transaction size=10 ops</i></p> <p><i><b>Figure 1.</b> Omid LL scaling versus legacy Omid. The throughput scales beyond 550,000 tps while the latency remains flat (low milliseconds). </i></p> <p><b>ANSI SQL support</b></p> <p>Phoenix provides secondary indexes for SQL tables — a centerpiece tool for efficient access to data by multiple keys. The CREATE INDEX command is on-demand; it is not allowed to block already deployed applications. We added Omid support for accomplishing this without impeding concurrent database operations or sacrificing consistency. We further introduced a mechanism to avoid recursive read-your-own-writes scenarios in complex queries, like “INSERT INTO T … SELECT FROM T …” statements. This was achieved by extending Omid’s traditional Snapshot Isolation consistency model, which provides single-read-point-single-write-point semantics, with multiple read and write points. </p> <p><b>Performance improvements </b></p> <p>Phoenix extensively employs stored procedures implemented as HBase filters in order to eliminate the overhead of multiple round-trips to the data store. We integrated Omid’s code within such HBase-resident procedures, allowing for a smooth integration with Phoenix and also reduced the overhead of transactional reads (for example, filtering out redundant data versions). </p> <p>We collaborated closely with the Phoenix developer community while working on this project, and contributed code to Phoenix that made Omid’s integration possible. We look forward to seeing Omid’s adoption through a wide range of Phoenix applications. We always welcome new developers to <a href="https://github.com/apache/incubator-omid">join the community</a> and help push Omid forward!</p> </blockquote>