{"id":4072,"date":"2022-01-11T11:57:03","date_gmt":"2022-01-11T11:57:03","guid":{"rendered":"https:\/\/en.pingcap.com\/?p=4072"},"modified":"2025-11-14T02:08:57","modified_gmt":"2025-11-14T10:08:57","slug":"journey-from-traditional-monolithic-architecture-to-distributed-sql","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/journey-from-traditional-monolithic-architecture-to-distributed-sql\/","title":{"rendered":"My Journey from Traditional Monolithic Architecture to Distributed SQL"},"content":{"rendered":"

Like many Data Management Engineers, I began my career many years ago focused on the Oracle database. At the time, it was a very pragmatic decision. Oracle was very mature, reliable, and feature-rich. I could build very fast and very large vertically scalable architectures. If I needed more resources for the database, I simply scaled up, deploying a larger machine, all the way up to Oracle’s flagship engineered system, Oracle Exadata.<\/p>\n\n\n\n

But then everything changed with the advent of the cloud and I found myself faced with moving very large on-premise applications and databases to various types of cloud infrastructure. Moving the applications to the cloud was relatively trivial, I could distribute them geographically where they were needed, and by that point, most of my clients were moving to microservices architectures that were designed to be cloud-native and horizontally distributed.<\/p>\n\n\n\n

The Oracle database, as it turns out, was far more difficult to transition to the cloud. It was designed from the beginning to be vertically scalable. I could scale up but not out to where I needed it in the cloud, and I resigned myself to the fact that Oracle, as well as their traditional RDBMS systems, were not my choice for cloud-native architectures<\/a>. There is a requirement for a database that can horizontally scale out and be accessed quickly by applications that are geographically dispersed to service users no matter where they reside. Traditional databases were becoming the ultimate bottleneck for mission-critical applications in the cloud. I needed something radically different, so I pivoted in a big way.<\/p>\n\n\n\n

<\/span>The advent of Distributed SQL<\/span><\/h2>\n\n\n\n

As it turned out, many of us were facing the same challenges, and it sparked an effort to build a next-generation cloud-native database that solved these key challenges. In the beginning of 2014, I was sent a newly released paper published by Google Research called Spanner: Google<\/meta>\u2019s Globally-Distributed Database. This article is a very detailed description of a clustered distributed database architecture that can span a single data center or multiple data centers. Data is automatically sharded and multiple copies of the data are distributed and balanced across the cluster. Applications can connect to any node in the cluster and access any data residing in the distributed database<\/a>. In addition, additional nodes can be added to easily allow a cluster to scale up and nodes can be removed to scale down.<\/p>\n\n\n\n

Here at PingCAP, we took the core concept of Distributed SQL\u2019s multi-node auto-sharding architecture and extended the architecture to allow for greater flexibility and functionality beyond Spanner and other Distributed SQL databases. We call this next-generation database \ud2f0DB<\/a>.<\/p>\n\n\n\n

<\/span>TiDB design tenets<\/span><\/h2>\n\n\n\n

In 2015, we built TiDB from scratch, leveraging a very large and active GitHub<\/a> open source community. Working with the collaboration of the community, our founders focused on a set of design tenets that would allow for the creation of the next generation, cloud-native, Distributed SQL architecture. These are our core tenets:<\/p>\n\n\n\n