EN: |+| [Music] |+| In this unit, |+| we will talk about the reasons for choosing TiDB, as well as showing some of the TiDB users. EN: |+| Many customers choose TiDB due to these two reasons. EN: |+| The first one is “scalable”. EN: TiDB is scalable for mission critical workloads. EN: |+| 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. EN: These |+| layers are decoupled from each other and can be scaled on demand without any disruptions. EN: |+| By using TiDB, you may eliminate both planned and unplanned downtime. EN: In addition to the |+| scaling in and scaling out mentioned before, TiDB also supports online rolling updates |+| and online DDL. EN: 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. EN: |+| In addition, users can enjoy these benefits on TiDB Cloud with no additional setup. EN: |+| Similar to traditional RDBMS, |+| TiDB offers full ACID transactional support with strong consistency. EN: |+| 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. EN: |+| It has already been proven in production that consolidating hundreds or even |+| thousands of MySQL-compatible databases into a single TiDB cluster is possible. EN: |+| 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. EN: |+| TiDB is equipped with both row-based and columnar-based storage engines, |+| making it optimized for handling both OLTP and |+| analytical workloads simultaneously. EN: With a single standard SQL interface, |+| business analysts can easily gain insights from both online operations and cold data combined. EN: |+| TiDB is able to efficiently store and retrieve a large amount of data at the PB scale. EN: |+| 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. EN: As a result, SQL is back in the driver's seat. EN: |+| TiDB encapsulates the complexity of No One Size Fits All and reduces the re-investment, |+| especially the re-investment in the Cloud. EN: 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. EN: While some require high availability and scalability, |+| others demand high performance and low latency. EN: Furthermore, different database technologies and |+| configurations offer distinct advantages and limitations. EN: 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. EN: However, this often leads to a |+| significant increase in management complexity, which can be further amplified in public cloud |+| environments because of reinvestment issues. EN: 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. EN: |+| 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. EN: However, |+| at the higher operation level, TiDB presents a single management interface as a unified database, |+| enabling users to benefit from both approaches simultaneously. EN: Unless your application requires |+| extremely low latency, otherwise for most of the cases, TiDB is a comprehensive solution. EN: |+| As mentioned earlier, TiDB offers both row-based and column-based storage engines. EN: 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. EN: |+| Here goes an example architecture without TiDB. EN: We placed six database clients instances here, |+| in the practice, of course, there could be much more. EN: The architecture is already cloud friendly. EN: |+| The availability zone here stands for the data centers or AZ provided by cloud service providers. EN: |+| And, we have MySQL for online transaction processing. EN: The standby database here is a |+| full replica of the leader database for high availability and disaster recovery purposes. EN: |+| With the leader for writes and re-replica for reads you can handle a pretty serious workload. EN: |+| And, there is a cache for transit objects or hotspot objects to improve the read performance. EN: |+| 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. EN: The data layer architecture is complicated to some extent. EN: |+| Let's zoom in MySQL master. EN: As the business grows the data will eventually outgrow the single |+| machine. EN: One way of handling the increasing writes is to split the data over multiple databases using |+| what's called sharding. EN: 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. EN: To increase the write capacity |+| you split the database into two. EN: Well, some users are handling the first database and some in the |+| second. EN: 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. EN: |+| When you need to increase capacity further you do the same thing and split the data set again. EN: |+| Adding shards that makes generating reports gets more and more difficult. EN: |+| 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. EN: This is no fun at all for the developers and Ops team. EN: |+| By using TiDB the data layer architecture is straightforward and the exposed complexity |+| is dramatically mitigated. EN: Like NoSQL, TiDB is distributed and is capable of horizontal scaling. EN: |+| TiDB handles sharding automatically and it's transparent to your application. EN: |+| Unlike NoSQL, TiDB supports transaction and SQL in native and is compatible with MySQL. EN: |+| Within TiDB, the replication happens automatically, the sharding happens |+| automatically, the role based and columnar store transformation happens automatically. EN: It acts |+| in a position as a multiple purpose database to replace MySQL and NoSQL databases simultaneously. EN: |+| TiDB is versatile, so you can focus on your application. EN: Users acquire data |+| agility without worrying about the future of growing pain. EN: But I have to mention that even |+| TiDB is versatile it cannot eliminate the hot spot bottleneck caused by your application. EN: |+| So, cache components like Redis are still required for the application hotspot cases. EN: 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. EN: |+| TiDB is used by more than 3,000 global adopters, and it is trusted by global innovation leaders. EN: |+| Here are a few examples. EN: |+| Catalyst is a Software-as-a-Service (SaaS) company that provides a powerful customer |+| success platform to help companies achieve success with their customers. EN: |+| Catalyst used PostgreSQL, and then Elasticsearch for their data backends, but did not work out. EN: |+| Then, Catalyst investigated TiDB. EN: They found that TiDB’s response time was 10 to 60 times |+| faster than its competitors. EN: Also they are keen that TiDB has perfect support for online DDL. EN: |+| Bolt is a global mobility company headquartered in Estonia that mainly offers vehicle hiring, |+| car-sharing, and food delivery services. EN: Bolt has over 100 million customers. EN: |+| Previously, Bolt used MySQL as its main database. EN: As the data volume grows, |+| sharding was introduced, and did not meet their expectations. EN: |+| Bolt explored Vitess and TiDB for the MySQL replacement. EN: It |+| turned out that Vitess required too many changes to Bolt’s applications. EN: |+| Bolt finally chose TiDB, an open source, distributed NewSQL database. EN: |+| Bolt is impressed by TiDB’s almost infinite horizontal scalability. EN: |+| By automatically adding or removing storage nodes, |+| it can easily handle up to hundreds of terabytes of sudden data spikes or plunges. EN: |+| Moreover, TiDB has strong compression capability, which reduces storage costs. EN: |+| Lastly, it has a simplified architecture and can handle |+| transactional and analytical workloads at the same time. EN: |+| For more information, you may go to https://www.pingcap.com/customers/ |+| for more use cases.