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