[Music] In this unit, we will talk about the reasons for choosing TiDB, as well as showing some of the TiDB users.

Many customers choose TiDB due to these two reasons.

The first one is “scalable”.

TiDB is scalable for mission critical workloads.

TiDB provides horizontal scalability, meaning that TiDB supports zero downtime scaling in and scaling out at every sub-component layer, which includes the computation layer, the storage layer, and the metadata layer.

These layers are decoupled from each other and can be scaled on demand without any disruptions.

By using TiDB, you may eliminate both planned and unplanned downtime.

In addition to the scaling in and scaling out mentioned before, TiDB also supports online rolling updates and online DDL.

Its built-in self-healing ability is enabled at the compute, storage, and metadata layers, ensuring that the business continuity when faced with software failures, hardware malfunctions, and even a data center outages.

In addition, users can enjoy these benefits on TiDB Cloud with no additional setup.

Similar to traditional RDBMS, TiDB offers full ACID transactional support with strong consistency.

TiDB is compatible with MySQL 5.7, meaning that in most cases, you can migrate your existing applications to TiDB without the need to alter the application code.

It has already been proven in production that consolidating hundreds or even thousands of MySQL-compatible databases into a single TiDB cluster is possible.

The second reason for choosing TiDB is the built-in Translytical, or HTAP, capability, meaning TiDB is able to deal with transactional and analytical transactions at the same time.

TiDB is equipped with both row-based and columnar-based storage engines, making it optimized for handling both OLTP and analytical workloads simultaneously.

With a single standard SQL interface, business analysts can easily gain insights from both online operations and cold data combined.

TiDB is able to efficiently store and retrieve a large amount of data at the PB scale.

TiDB simplifies the handling of most Big Data issues with its implementation of standard SQL, and with the added support for JSON data type and functions, it eliminates the need to incorporate specialized tools from the Big Data ecosystem.

As a result, SQL is back in the driver's seat.

TiDB encapsulates the complexity of No One Size Fits All and reduces the re-investment, especially the re-investment in the Cloud.

In the field of databases, it has been widely accepted for many years that there is no universal solution that fits all since varying applications have their unique database requirements.

While some require high availability and scalability, others demand high performance and low latency.

Furthermore, different database technologies and configurations offer distinct advantages and limitations.

Thus, it is essential to comprehend the specific needs of your application and select the appropriate database technology and configuration that optimally addresses those requirements.

However, this often leads to a significant increase in management complexity, which can be further amplified in public cloud environments because of reinvestment issues.

At TiDB's core, it is a key-value NoSQL database that incorporates a stateless SQL layer, granting it the advantages of both NoSQL and RDBMS.

It has been designed to handle the complexities associated with combining these two technologies, adhering to the principle of "No One Size Fits All" at a lower level.

However, at the higher operation level, TiDB presents a single management interface as a unified database, enabling users to benefit from both approaches simultaneously.

Unless your application requires extremely low latency, otherwise for most of the cases, TiDB is a comprehensive solution.

As mentioned earlier, TiDB offers both row-based and column-based storage engines.

The column-based engine is capable of automatically replicating the necessary data from the row-based engine for analytical workloads, without the need for additional ETL jobs.

Here goes an example architecture without TiDB.

We placed six database clients instances here, in the practice, of course, there could be much more.

The architecture is already cloud friendly.

The availability zone here stands for the data centers or AZ provided by cloud service providers.

And, we have MySQL for online transaction processing.

The standby database here is a full replica of the leader database for high availability and disaster recovery purposes.

With the leader for writes and re-replica for reads you can handle a pretty serious workload.

And, there is a cache for transit objects or hotspot objects to improve the read performance.

NoSQL database here is a horizontally scalable persistent store and its nodes can span across availability zones to achieve the requirements of high availability, disaster recovery, performance and data growth at scale.

The data layer architecture is complicated to some extent.

Let's zoom in MySQL master.

As the business grows the data will eventually outgrow the single machine.

One way of handling the increasing writes is to split the data over multiple databases using what's called sharding.

For example to begin with you might store all information for users with the user ID starting with the letter A through Z in a single database.

To increase the write capacity you split the database into two.

Well, some users are handling the first database and some in the second.

Here we use the first letter of the user ID as an example, but in practice people sometimes use consistent hash to determine the shard used for a specific piece of data.

When you need to increase capacity further you do the same thing and split the data set again.

Adding shards that makes generating reports gets more and more difficult.

Those are only for write operations, you also need replicas in local availability zone for read performance and standby database per shard in the peering AZ for high availability and disaster recovery.

This is no fun at all for the developers and Ops team.

By using TiDB the data layer architecture is straightforward and the exposed complexity is dramatically mitigated.

Like NoSQL, TiDB is distributed and is capable of horizontal scaling.

TiDB handles sharding automatically and it's transparent to your application.

Unlike NoSQL, TiDB supports transaction and SQL in native and is compatible with MySQL.

Within TiDB, the replication happens automatically, the sharding happens automatically, the role based and columnar store transformation happens automatically.

It acts in a position as a multiple purpose database to replace MySQL and NoSQL databases simultaneously.

TiDB is versatile, so you can focus on your application.

Users acquire data agility without worrying about the future of growing pain.

But I have to mention that even TiDB is versatile it cannot eliminate the hot spot bottleneck caused by your application.

So, cache components like Redis are still required for the application hotspot cases.

We will discuss how to mitigate hotspots in detail in the TiDB Performance Tuning course in the database operation learning path and in TiDB specific feature course in the developer learning path.

TiDB is used by more than 3,000 global adopters, and it is trusted by global innovation leaders.

Here are a few examples.

Catalyst is a Software-as-a-Service (SaaS) company that provides a powerful customer success platform to help companies achieve success with their customers.

Catalyst used PostgreSQL, and then Elasticsearch for their data backends, but did not work out.

Then, Catalyst investigated TiDB.

They found that TiDB’s response time was 10 to 60 times faster than its competitors.

Also they are keen that TiDB has perfect support for online DDL.

Bolt is a global mobility company headquartered in Estonia that mainly offers vehicle hiring, car-sharing, and food delivery services.

Bolt has over 100 million customers.

Previously, Bolt used MySQL as its main database.

As the data volume grows, sharding was introduced, and did not meet their expectations.

Bolt explored Vitess and TiDB for the MySQL replacement.

It turned out that Vitess required too many changes to Bolt’s applications.

Bolt finally chose TiDB, an open source, distributed NewSQL database.

Bolt is impressed by TiDB’s almost infinite horizontal scalability.

By automatically adding or removing storage nodes, it can easily handle up to hundreds of terabytes of sudden data spikes or plunges.

Moreover, TiDB has strong compression capability, which reduces storage costs.

Lastly, it has a simplified architecture and can handle transactional and analytical workloads at the same time.

For more information, you may go to https://www.pingcap.com/customers/ for more use cases.