|+| 【音楽】このユニットでは、HTAPについて話します。

|+|HTAPはハイブリッドトランザクション/分析処理の略であり、翻訳結果にも復元されます。

名前が示すように、 OLTP と OLAP の両方のワークロードを同時に処理できるハイブリッドソリューションまたはハイブリッドデータベースです。|+|「|+|」は英語の文章にある場合、翻訳結果に再度挿入する必要があります。

|+|OLTPは通常、行ベースのデータで動作しますが、OLAPは列指向型ストアに偏っています。

|+|OLTPとOLAPの間の線は実際には曖昧になっていますが、|+|このディスカッションの目的のために、それがまだそのようであると仮定します。

|+|ディスクIOは、データベースにとって最も重要で時間を要するタスクの1つであり、IOが多いほどパフォーマンスが悪化することを理解しています。 |+|

|+|ここに、行ベースと列指向ベースのIOオーバーヘッドを比較する仮想的な例があります。|+|

単一の行を挿入する場合、行ベースのストレージは1つのデータブロックにアクセスする必要があります |+| 一方、カラムベースのデータストアは3つのデータブロックにアクセスする必要があります。

|+|しかしながら、集計について言えば、行ベースのストレージは3つのブロックにアクセスする必要がありますが、カラムベースのストレージは1つのデータブロックのスキャンだけで済みます。 |+|

|+|挿入の例は典型的なOLTPシナリオであり、集計の例は典型的なOLAPシナリオです。 |+|

|+|この例は、OLTPが行ベースのストレージを好む一方で、OLAPがカラムベースのストレージを好むことを示しています。

|+|当然、データブロックへのアクセスやスキャンの効率性は、2つのワークロード間の唯一の違いではありません。 |+|

|+|一方のパフォーマンスを改善するために、一方のパフォーマンスを犠牲にすることは珍しくありません。 |+|

|+|しかし、同じデータベースの同じテーブルに2つのワークロードが存在する限り、両方を同時に満足させることはできません。 |+|

|+|異なる構成で同じ感覚を共有することはできません。

OLAPではブロックサイズが大きい方が好ましいですが、OLTPでは比較的小さなブロックサイズが好まれます。このとき、|+|は元の英文に存在する場合、翻訳結果に再挿入する必要があります。

|+| 私たちは既に、TiKVが行ベースのキーバリューストアであることを知っています。

OLTPにとっては良いです。

OLAPプログラムを|+|クラックするために、TiDBのソリューションはTiFlashと呼ばれる別のサーバーをクラスタに追加することです。

|+|TiFlashはカラムベースのストレージを提供し、同じRaftアルゴリズムに依存してTiKVからデータをリアルタイムにレプリケートします。 |+|

|+| TiFlashへのデータレプリケーションは、TiKVの書き込み操作をブロックしません。

|+| TiKVのように一貫性のある読み取りを提供し、最新のデータが返されることを確実にします。

|+|TiFlashは、LearnerとしてRaftグループに参加します。これは、TiFlashが決してLeaderにならないことを意味します。

|+|デプロイ後、テーブルデータはデフォルトではTiflashに同期されません。

|+|同期機能は明示的に有効にする必要があります。

|+|エンジンのスマート選択機能により、TiDBサーバーはOLTPワークロードを処理する際にTiKVと通信し、クエリパフォーマンスの改善が見込める場合は、TiFlashから結果を取得することができます。 |+| |+|

|+| 私たちは、TiDB固有の機能というトレーニングコースでTiFlashの使用方法について説明します。