HTAPシステムの特徴はシンプルなアーキテクチャーそこでLiu氏が使ったのは次のスライドだ。HTAPデータベースを中心にしたシンプルなアーキテクチャーここではシンプルにオレンジ色の部分が中核となるHTAPデータベースを置き、その前後にデータ入力のトランザクションを行う部分とユーザーインターフェースとして様々な切り口で分析を行う機能などが並んでいる。しかしこのデータベースの中身を見てみると、シャーディングされた複数のデータベースのレプリカ、Kafkaなどのストリーミングデータサービスモジュール、そして分析用にETL加工されたうえでデータレイクに格納するまでが必要となると説明した。中核のデータベースサービスの中身は複雑なモジュールの組み合わせこの部分はHTAPとして機能することが期待されるが、従来のSQLデータベース、NoSQLなどでは複雑になるだけでスケーラブルに拡張できるとはとても思えないだろう。ではどうしてそれが可能になるのか、HTAPの実装例としてOSS Insightでも使われていたTiDBの中身を紹介していこう。ここからはこのセッションから少し脱線して、PingCAPの日本法人、PingCAP株式会社のCTO、林正記氏が2022年4月14日に行ったWebinarで公開したスライドから抜粋して、HTAPをPingCAPのテクノロジーであるTiDBがどうやって実装されているのかを紹介する。スライドの全体は以下を参照して欲しい。【参考】「DB性能でお悩みの方必見。スケーラブルなRDB NewSQLはどこまでできるか。」HTAPのユースケース、ZTO Expressのビフォア&アフターこのユースケースでは、Oracle Exadataを使っていたユーザーが容量の上限、ピーク性能の限界、データベースシャーディングによるリアルタイム分析の限界などの問題点をHTAPシステムであるTiDBが解消したことが説明されている。では、どのように容量、性能の限界を打ち破ったのか、シャーディングが不要なのはどうしてか? について説明しているのが次のスライドだ。SQL解析を担当するTiDBと堅牢なデータストアを実装するTiKVに分離TiDBのアーキテクチャーを解説したスライドではGoogleがSpannerを開発する際の発想と同じでデータベースの役割を明確に分離したこと、それぞれが分散処理によってスケールアウトを可能にしたことを示している。この分散構造にはマスターとなるリーダーノードを固定せずに動的な分散処理を行うため「Raft」と呼ばれる分散合意アルゴリズムを利用している。これはクラウドネイティブなコンテナーオーケストレーションツールの代名詞であるKubernetesの中核であるデータストア、etcdも利用する堅牢かつ高速な分散処理技術だ。最低3つのノードがリーダー、フォロワーを動的に分担することで分散処理を実行また、TiDBではデータストアのメタデータなどを管理するPDクラスタにより複数のノードが自律的に運用できることを示している。SQL解析、分散データストア、データのロケーション管理をそれぞれ分離このように、TiDBそのものが水平にスケールできる分散データベースとしてHTAPに必要な要素を備えていることが解説されている。特にデータベースの分割、シャーディングはデータベース運用チームにとっては頭の痛い問題点であり、これが解決されることは要注目だろう。分散データベースは全てHTAPになる