0 00:00:00,000 --> 00:00:08,208 [Music] 1 00:00:08,208 --> 00:00:11,208 In this unit, we will talk about HTAP. 2 00:00:11,208 --> 00:00:16,740 HTAP stands for hybrid transactional /  analytic processing. Just as the name suggests,   3 00:00:16,740 --> 00:00:22,080 it is a hybrid solution or hybrid database  that can handle two types of workloads,   4 00:00:22,080 --> 00:00:25,260 OLTP and OLAP, at the same time. 5 00:00:26,520 --> 00:00:33,120 OLTP normally works with row based data, while  OLAP is often biased towards columnar stores. 6 00:00:34,380 --> 00:00:38,400 The line between OLTP and  OLAP is actually blurring,   7 00:00:38,400 --> 00:00:42,420 but for the purposes of our discussion,  let's assume that it's still the case. 8 00:00:43,680 --> 00:00:47,658 We understand that disk IO is one  of the most heavy lifting and time   9 00:00:47,658 --> 00:00:52,140 consuming tasks for databases, and  more IO means worse performance. 10 00:00:52,980 --> 00:00:58,260 Here is an hypothetical example to compare  IO overhead between row based and a columnar   11 00:01:00,120 --> 00:01:04,200 store. When inserting one row, row based  storage need to access to one data block only,   12 00:01:04,200 --> 00:01:08,580 while the column based data store  requires access to three data blocks. 13 00:01:09,660 --> 00:01:14,640 However, for the aggregations, row based  storage requires access to three blocks,   14 00:01:14,640 --> 00:01:18,060 while the column based storage  only needs to scan one data block. 15 00:01:18,720 --> 00:01:22,020 The insertion example is a typical OLTP scenario   16 00:01:22,020 --> 00:01:25,200 and the aggregation example  is a typical OLAP scenario. 17 00:01:26,520 --> 00:01:32,700 This example tells us OLTP prefers row based  storage, while OLAP prefers column based storage. 18 00:01:33,960 --> 00:01:37,320 Of course data blocks accessing  or scanning efficiency is not   19 00:01:37,320 --> 00:01:39,840 the only difference between the two workloads. 20 00:01:39,840 --> 00:01:43,560 It is not unusual when you try to  trade off the performance for one   21 00:01:43,560 --> 00:01:46,080 side in order to improve the  performance for the other. 22 00:01:46,740 --> 00:01:50,880 However, as long as two workloads exist  in the same database on the same table,   23 00:01:50,880 --> 00:01:54,240 you cannot make both happy simultaneously. 24 00:01:54,240 --> 00:01:54,679 They cannot share the same feeling on  various configurations. For example,   25 00:01:54,679 --> 00:01:55,200 for block size OLAP prefers large blocks,  while OLTP prefers relatively small block size. 26 00:01:55,200 --> 00:02:01,620 We already know that TiKV is a key-value store  which is row based. It is good for OLTP. To   27 00:02:01,620 --> 00:02:08,100 crack the OLAP program, TiDB's solution is to add  another server into the cluster called TiFlash. 28 00:02:09,660 --> 00:02:13,260 TiFlash provides column based storage  and relies on the same Raft algorithm   29 00:02:13,260 --> 00:02:15,960 to replicate the data from TiKV in real time. 30 00:02:16,800 --> 00:02:20,520 Replicating data to TiFlash does  not block TiKV write operations. 31 00:02:21,360 --> 00:02:26,520 It also provides consistent reads like TiKV and  ensures that the latest the data is returned. 32 00:02:28,320 --> 00:02:32,880 TiFlash joins Raft the group as a learner  role, which means it will never become a leader. 33 00:02:33,720 --> 00:02:39,180 After the deployment, table data will not  be synchronized to Tiflash by default. 34 00:02:40,620 --> 00:02:44,160 The synchronization function  needs to be explicitly enabled. 35 00:02:45,000 --> 00:02:46,920 With the engine's smart selection feature,   36 00:02:46,920 --> 00:02:51,600 TiDB server can communicate with TiKV  when dealing with OLTP workload and   37 00:02:51,600 --> 00:02:56,820 fetch results from TiFlash in case the query  performance could benefit from columnar store. 38 00:02:57,960 --> 00:03:02,520 We will cover how to use TiFlash in the  training course named TiDB specific features.