EN: |+| [Music] In this unit, we will talk about HTAP. EN: |+| HTAP stands for hybrid transactional / analytic processing. EN: Just as the name suggests, |+| it is a hybrid solution or hybrid database that can handle two types of workloads, |+| OLTP and OLAP, at the same time. EN: |+| OLTP normally works with row based data, while OLAP is often biased towards columnar stores. EN: |+| The line between OLTP and OLAP is actually blurring, |+| but for the purposes of our discussion, let's assume that it's still the case. EN: |+| We understand that disk IO is one of the most heavy lifting and time |+| consuming tasks for databases, and more IO means worse performance. EN: |+| Here is an hypothetical example to compare IO overhead between row based and a columnar |+| store. EN: When inserting one row, row based storage need to access to one data block only, |+| while the column based data store requires access to three data blocks. EN: |+| However, for the aggregations, row based storage requires access to three blocks, |+| while the column based storage only needs to scan one data block. EN: |+| The insertion example is a typical OLTP scenario |+| and the aggregation example is a typical OLAP scenario. EN: |+| This example tells us OLTP prefers row based storage, while OLAP prefers column based storage. EN: |+| Of course data blocks accessing or scanning efficiency is not |+| the only difference between the two workloads. EN: |+| It is not unusual when you try to trade off the performance for one |+| side in order to improve the performance for the other. EN: |+| However, as long as two workloads exist in the same database on the same table, |+| you cannot make both happy simultaneously. EN: |+| They cannot share the same feeling on various configurations. EN: For example, |+| for block size OLAP prefers large blocks, while OLTP prefers relatively small block size. EN: |+| We already know that TiKV is a key-value store which is row based. EN: It is good for OLTP. EN: To |+| crack the OLAP program, TiDB's solution is to add another server into the cluster called TiFlash. EN: |+| TiFlash provides column based storage and relies on the same Raft algorithm |+| to replicate the data from TiKV in real time. EN: |+| Replicating data to TiFlash does not block TiKV write operations. EN: |+| It also provides consistent reads like TiKV and ensures that the latest the data is returned. EN: |+| TiFlash joins Raft the group as a learner role, which means it will never become a leader. EN: |+| After the deployment, table data will not be synchronized to Tiflash by default. EN: |+| The synchronization function needs to be explicitly enabled. EN: |+| With the engine's smart selection feature, |+| TiDB server can communicate with TiKV when dealing with OLTP workload and |+| fetch results from TiFlash in case the query performance could benefit from columnar store. EN: |+| We will cover how to use TiFlash in the training course named TiDB specific features.