0
00:00:00,000 --> 00:00:08,180
[Music]

1
00:00:08,180 --> 00:00:09,180
In this unit,

2
00:00:09,180 --> 00:00:14,820
we will talk about the reasons for choosing 
TiDB, as well as showing some of the TiDB users.

3
00:00:16,080 --> 00:00:19,440
Many customers choose TiDB 
due to these two reasons.

4
00:00:20,280 --> 00:00:25,020
The first one is “scalable”. TiDB is 
scalable for mission critical workloads.

5
00:00:25,680 --> 00:00:28,860
TiDB provides horizontal scalability, meaning that  

6
00:00:28,860 --> 00:00:34,620
TiDB supports zero downtime scaling in and 
scaling out at every sub-component layer,  

7
00:00:34,620 --> 00:00:40,380
which includes the computation layer, the 
storage layer, and the metadata layer. These  

8
00:00:40,380 --> 00:00:45,120
layers are decoupled from each other and can 
be scaled on demand without any disruptions.

9
00:00:45,840 --> 00:00:51,480
By using TiDB, you may eliminate both planned 
and unplanned downtime. In addition to the  

10
00:00:51,480 --> 00:00:56,100
scaling in and scaling out mentioned before, 
TiDB also supports online rolling updates  

11
00:00:56,100 --> 00:01:02,580
and online DDL. Its built-in self-healing 
ability is enabled at the compute, storage,  

12
00:01:02,580 --> 00:01:08,100
and metadata layers, ensuring that the business 
continuity when faced with software failures,  

13
00:01:08,100 --> 00:01:12,000
hardware malfunctions, and 
even a data center outages.  

14
00:01:12,600 --> 00:01:17,580
In addition, users can enjoy these benefits 
on TiDB Cloud with no additional setup.

15
00:01:18,180 --> 00:01:20,460
Similar to traditional RDBMS,  

16
00:01:20,460 --> 00:01:25,080
TiDB offers full ACID transactional 
support with strong consistency.

17
00:01:25,080 --> 00:01:30,600
TiDB is compatible with MySQL 
5.7, meaning that in most cases,  

18
00:01:30,600 --> 00:01:36,060
you can migrate your existing applications to TiDB 
without the need to alter the application code.  

19
00:01:37,260 --> 00:01:41,760
It has already been proven in production 
that consolidating hundreds or even  

20
00:01:41,760 --> 00:01:46,500
thousands of MySQL-compatible databases 
into a single TiDB cluster is possible.

21
00:01:47,340 --> 00:01:52,320
The second reason for choosing TiDB is the 
built-in Translytical, or HTAP, capability,  

22
00:01:52,320 --> 00:01:58,020
meaning TiDB is able to deal with transactional 
and analytical transactions at the same time.

23
00:01:58,860 --> 00:02:03,060
TiDB is equipped with both row-based 
and columnar-based storage engines,  

24
00:02:03,060 --> 00:02:06,600
making it optimized for handling both OLTP and  

25
00:02:06,600 --> 00:02:11,220
analytical workloads simultaneously. 
With a single standard SQL interface,  

26
00:02:11,220 --> 00:02:17,220
business analysts can easily gain insights from 
both online operations and cold data combined.

27
00:02:17,220 --> 00:02:23,160
TiDB is able to efficiently store and retrieve 
a large amount of data at the PB scale.  

28
00:02:23,700 --> 00:02:29,760
TiDB simplifies the handling of most Big Data 
issues with its implementation of standard SQL,  

29
00:02:29,760 --> 00:02:36,660
and with the added support for JSON data type and 
functions, it eliminates the need to incorporate  

30
00:02:36,660 --> 00:02:42,960
specialized tools from the Big Data ecosystem. 
As a result, SQL is back in the driver's seat.

31
00:02:43,980 --> 00:02:50,100
TiDB encapsulates the complexity of No One 
Size Fits All and reduces the re-investment,  

32
00:02:50,100 --> 00:02:56,160
especially the re-investment in the Cloud. 
In the field of databases, it has been widely  

33
00:02:56,160 --> 00:03:01,800
accepted for many years that there is no universal 
solution that fits all since varying applications  

34
00:03:01,800 --> 00:03:07,260
have their unique database requirements. While 
some require high availability and scalability,  

35
00:03:07,260 --> 00:03:13,260
others demand high performance and low latency. 
Furthermore, different database technologies and  

36
00:03:13,260 --> 00:03:19,440
configurations offer distinct advantages 
and limitations. Thus, it is essential to  

37
00:03:19,440 --> 00:03:25,080
comprehend the specific needs of your application 
and select the appropriate database technology and  

38
00:03:25,080 --> 00:03:31,560
configuration that optimally addresses those 
requirements. However, this often leads to a  

39
00:03:31,560 --> 00:03:36,660
significant increase in management complexity, 
which can be further amplified in public cloud  

40
00:03:36,660 --> 00:03:43,020
environments because of reinvestment issues. At 
TiDB's core, it is a key-value NoSQL database that  

41
00:03:43,020 --> 00:03:49,500
incorporates a stateless SQL layer, granting 
it the advantages of both NoSQL and RDBMS.  

42
00:03:51,360 --> 00:03:56,640
It has been designed to handle the complexities 
associated with combining these two technologies,  

43
00:03:56,640 --> 00:04:02,880
adhering to the principle of "No One 
Size Fits All" at a lower level. However,  

44
00:04:02,880 --> 00:04:08,700
at the higher operation level, TiDB presents a 
single management interface as a unified database,  

45
00:04:08,700 --> 00:04:15,300
enabling users to benefit from both approaches 
simultaneously. Unless your application requires  

46
00:04:15,300 --> 00:04:20,760
extremely low latency, otherwise for most of 
the cases, TiDB is a comprehensive solution.

47
00:04:23,040 --> 00:04:29,220
As mentioned earlier, TiDB offers both row-based 
and column-based storage engines. The column-based  

48
00:04:29,220 --> 00:04:33,960
engine is capable of automatically replicating 
the necessary data from the row-based engine  

49
00:04:33,960 --> 00:04:38,340
for analytical workloads, without 
the need for additional ETL jobs.

50
00:04:39,660 --> 00:04:46,800
Here goes an example architecture without TiDB. 
We placed six database clients instances here,  

51
00:04:47,400 --> 00:04:54,240
in the practice, of course, there could be much 
more. The architecture is already cloud friendly.  

52
00:04:54,240 --> 00:05:01,140
The availability zone here stands for the data 
centers or AZ provided by cloud service providers.  

53
00:05:02,280 --> 00:05:09,120
And, we have MySQL for online transaction 
processing. The standby database here is a  

54
00:05:09,120 --> 00:05:14,940
full replica of the leader database for high 
availability and disaster recovery purposes.  

55
00:05:15,660 --> 00:05:22,020
With the leader for writes and re-replica for 
reads you can handle a pretty serious workload.  

56
00:05:22,020 --> 00:05:28,740
And, there is a cache for transit objects or 
hotspot objects to improve the read performance.  

57
00:05:29,580 --> 00:05:35,820
NoSQL database here is a horizontally scalable 
persistent store and its nodes can span across  

58
00:05:35,820 --> 00:05:40,980
availability zones to achieve the requirements 
of high availability, disaster recovery,  

59
00:05:40,980 --> 00:05:48,840
performance and data growth at scale. The data 
layer architecture is complicated to some extent.  

60
00:05:49,560 --> 00:05:56,280
Let's zoom in MySQL master. As the business 
grows the data will eventually outgrow the single  

61
00:05:56,280 --> 00:06:03,300
machine. One way of handling the increasing writes 
is to split the data over multiple databases using  

62
00:06:03,300 --> 00:06:11,040
what's called sharding. For example to begin with 
you might store all information for users with the  

63
00:06:11,040 --> 00:06:18,540
user ID starting with the letter A through Z in 
a single database. To increase the write capacity  

64
00:06:18,540 --> 00:06:25,860
you split the database into two. Well, some users 
are handling the first database and some in the  

65
00:06:25,860 --> 00:06:31,860
second. Here we use the first letter of the 
user ID as an example, but in practice people  

66
00:06:31,860 --> 00:06:37,500
sometimes use consistent hash to determine 
the shard used for a specific piece of data.  

67
00:06:38,760 --> 00:06:43,860
When you need to increase capacity further you 
do the same thing and split the data set again.  

68
00:06:45,780 --> 00:06:48,840
Adding shards that makes generating 
reports gets more and more difficult.  

69
00:06:50,520 --> 00:06:55,080
Those are only for write operations, you 
also need replicas in local availability  

70
00:06:55,080 --> 00:07:00,840
zone for read performance and standby 
database per shard in the peering AZ for  

71
00:07:00,840 --> 00:07:07,920
high availability and disaster recovery. This is 
no fun at all for the developers and Ops team.  

72
00:07:09,360 --> 00:07:14,760
By using TiDB the data layer architecture is 
straightforward and the exposed complexity  

73
00:07:14,760 --> 00:07:23,220
is dramatically mitigated. Like NoSQL, TiDB is 
distributed and is capable of horizontal scaling.  

74
00:07:24,960 --> 00:07:29,220
TiDB handles sharding automatically and 
it's transparent to your application.  

75
00:07:30,540 --> 00:07:36,840
Unlike NoSQL, TiDB supports transaction and 
SQL in native and is compatible with MySQL.  

76
00:07:38,400 --> 00:07:42,120
Within TiDB, the replication happens 
automatically, the sharding happens  

77
00:07:42,120 --> 00:07:49,680
automatically, the role based and columnar store 
transformation happens automatically. It acts  

78
00:07:49,680 --> 00:07:55,980
in a position as a multiple purpose database to 
replace MySQL and NoSQL databases simultaneously.  

79
00:07:58,140 --> 00:08:03,480
TiDB is versatile, so you can focus on 
your application. Users acquire data  

80
00:08:03,480 --> 00:08:10,560
agility without worrying about the future of 
growing pain. But I have to mention that even  

81
00:08:10,560 --> 00:08:16,200
TiDB is versatile it cannot eliminate the hot 
spot bottleneck caused by your application.  

82
00:08:16,980 --> 00:08:23,880
So, cache components like Redis are still 
required for the application hotspot cases. We  

83
00:08:23,880 --> 00:08:29,520
will discuss how to mitigate hotspots in detail in 
the TiDB Performance Tuning course in the database  

84
00:08:29,520 --> 00:08:35,220
operation learning path and in TiDB specific 
feature course in the developer learning path.

85
00:08:36,960 --> 00:08:43,980
TiDB is used by more than 3,000 global adopters, 
and it is trusted by global innovation leaders.

86
00:08:43,980 --> 00:08:45,420
Here are a few examples.

87
00:08:47,280 --> 00:08:51,480
Catalyst is a Software-as-a-Service (SaaS) 
company that provides a powerful customer  

88
00:08:51,480 --> 00:08:55,680
success platform to help companies 
achieve success with their customers.

89
00:08:56,580 --> 00:09:03,000
Catalyst used PostgreSQL, and then Elasticsearch 
for their data backends, but did not work out.

90
00:09:03,600 --> 00:09:10,260
Then, Catalyst investigated TiDB. They found 
that TiDB’s response time was 10 to 60 times  

91
00:09:10,260 --> 00:09:17,700
faster than its competitors. Also they are keen 
that TiDB has perfect support for online DDL.

92
00:09:18,300 --> 00:09:23,340
Bolt is a global mobility company headquartered 
in Estonia that mainly offers vehicle hiring,  

93
00:09:23,340 --> 00:09:28,680
car-sharing, and food delivery services. 
Bolt has over 100 million customers.

94
00:09:29,460 --> 00:09:34,380
Previously, Bolt used MySQL as its main 
database. As the data volume grows,  

95
00:09:34,380 --> 00:09:37,980
sharding was introduced, and 
did not meet their expectations.

96
00:09:38,940 --> 00:09:43,440
Bolt explored Vitess and TiDB 
for the MySQL replacement. It  

97
00:09:43,440 --> 00:09:47,280
turned out that Vitess required too 
many changes to Bolt’s applications.  

98
00:09:48,060 --> 00:09:52,440
Bolt finally chose TiDB, an open 
source, distributed NewSQL database.

99
00:09:53,400 --> 00:09:57,720
Bolt is impressed by TiDB’s almost 
infinite horizontal scalability.  

100
00:09:57,720 --> 00:10:00,960
By automatically adding or removing storage nodes,  

101
00:10:00,960 --> 00:10:06,420
it can easily handle up to hundreds of 
terabytes of sudden data spikes or plunges.

102
00:10:07,200 --> 00:10:12,300
Moreover, TiDB has strong compression 
capability, which reduces storage costs.

103
00:10:13,260 --> 00:10:16,320
Lastly, it has a simplified 
architecture and can handle  

104
00:10:16,320 --> 00:10:19,380
transactional and analytical 
workloads at the same time.

105
00:10:20,280 --> 00:10:24,600
For more information, you may go to 
https://www.pingcap.com/customers/  

106
00:10:24,600 --> 00:10:26,220
for more use cases.