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.