{"id":5376,"date":"2022-03-07T22:40:00","date_gmt":"2022-03-08T06:40:00","guid":{"rendered":"https:\/\/en.pingcap.com\/?p=5376"},"modified":"2024-08-21T05:48:46","modified_gmt":"2024-08-21T12:48:46","slug":"how-an-htap-database-handles-oltp-and-olap-workloads-at-the-same-time","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/how-an-htap-database-handles-oltp-and-olap-workloads-at-the-same-time\/","title":{"rendered":"How an HTAP Database Handles OLTP and OLAP Workloads at the Same Time"},"content":{"rendered":"\n

An important idea in the database world is that specialized databases will outperform general-purpose databases. Michael Stonebraker, an A. M. Turing Award Laureate and one of the most influential people in the database world, also discussed this in his paper, \u201cOne Size Fits All: An Idea Whose Time Has Come and Gone.”[1]<\/sup><\/p>\n\n\n\n

This is a rational judgment, because it\u2019s tough enough to build a database that supports either<\/em> Online Transactional Processing (OLTP) or<\/em> Online Analytical Processing (OLAP) workloads, let alone one that supports both<\/em> at the same time. But the dilemma is, today, many users are facing increasing demands with mixed OLTP and OLAP workloads. How do we crack this dilemma?<\/p>\n\n\n\n

We, at PingCAP, provide a solution: TiDB, a Hybrid Transactional and Analytical Processing (HTAP) database that can handle mixed workloads. In this post, I will unveil the mystery of HTAP, and how an HTAP database can help users solve their problems. <\/p>\n\n\n\n

<\/span>HTAP \u2260 OLTP + OLAP<\/span><\/h2>\n\n\n\n

As our section title indicates, an HTAP is NOT<\/strong> a straight integration of OLTP and OLAP. <\/p>\n\n\n\n

A good analogy is a motorhome. It\u2019s sometimes called \u201ca home on wheels,\u201d but it really isn\u2019t a combination of a car and house. Instead, a motorhome is a unique experience\u2014a special product to meet special needs. So is HTAP.<\/strong><\/p>\n\n\n\n

HTAP is designed for special scenarios, not solely OLTP, OLAP, or a combination of the two. <\/p>\n\n\n\n

<\/span>The rise of HTAP scenarios<\/span><\/h2>\n\n\n\n

In recent years, the demand for real-time data processing and analytics has grown rapidly. Traditional databases that specialize more in offline data processing are failing to meet users\u2019 growing needs. There are two major reasons behind this.<\/p>\n\n\n\n

First, the technology stacks for real-time data processing have been constantly developing and maturing. <\/strong>Take the big data ecosystem as an example. The real-time computation framework has evolved from Apache Storm with simple semantics, to Apache Storm with Trident on top of it, and then to Apache Flink with complex semantics and supplemented by built-in state storage. Only now, after all these changes, the stream processing framework has been widely adopted in many complicated real-time analytical scenarios. These frameworks are paired with downstream sinks with different characteristics, which in turn accelerate the innovation of real-time applications. <\/p>\n\n\n\n

In addition, users keep trying new ideas to digitize their business operations in real time; technology stacks become easier to use; and the development of database technology also stimulates the prevalence of real-time applications. <\/p>\n\n\n\n

Second, the digital transformation process is speeding up in many traditional industries, generating new demands. <\/strong>Processing tasks that were once impossible are now requirements for a well-run business.  <\/p>\n\n\n\n

Take China\u2019s express delivery industry as an example. As its market size continues to expand, delivery orders have grown enormously. The real-time monitoring and analytics of those orders has become a must and can help optimize all aspects of operations such as real-time delivery route optimization and penalty management. Traditional off-line analytics can\u2019t meet these demands\u2014especially during large shopping carnivals when peak transactions occur. <\/p>\n\n\n\n

Today, more and more users are facing scenarios with mixed workloads, rather than pure OLTP or OLAP. We call these HTAP scenarios<\/strong>. Traditional OLAP solutions are too cumbersome to meet the new demands, as are pure OLTP databases. What users really want is a solution that is in between OLTP and OLAP databases. <\/p>\n\n\n\n

<\/span>HTAP\u2014PingCAP\u2019s solution<\/span><\/h2>\n\n\n\n

At PingCAP, our product strategy is that TiDB is an OLTP-oriented database supplemented with an OLAP capability<\/strong>. That is to say, our ambition is in the fields of OLTP and HTAP. <\/strong>Since we are discussing HTAP today, I will skip the OLTP part and focus on HTAP.<\/p>\n\n\n\n

I explained earlier why HTAP is not a straight combination of OLTP and OLAP. I can explain a bit more from our own experience. <\/p>\n\n\n\n

Previously, we faced scenarios with many data hub applications. Users intended to converge data from data silos on different business lines to the same real-time centralized data store, and then deliver data services and analytics on top of it. In another case, users planned to build a read replica replicated from their OLTP database. This replica was used to support separate analytics and data serving workloads and respond to unlimited queries and analytical services. <\/p>\n\n\n\n

The scenarios above require the database to: <\/p>\n\n\n\n