10年前の登場から再び脚光を浴びる「HTAP」は何がスゴイのか？──野心的なTiDBの構成から紐解く

事例：90億以上のOSSイベントデータをリアルタイムに分析

　HTAPには様々なユースケースが考えられる。たとえばECや金融業界では近年、ユーザー行動データのリアルタイム分析によるパーソナライズド・マーケティングや不正検知を素早く実行することが重要視されている。またIoTではセンサーデータから危険な故障を事前検知するといった仕組みにも応用が考えられている。ここでは、TiDBのHTAP機能を使用した「OSS Inshight」というサービスを見てみたい。

　OSS Insightは、HTAPの活用方法を伝えることを目的にPingCAPが開発したサービスで、オープンソースソフトウェア（OSS）プロジェクトに関するデータを分析し、視覚化することができる。このプラットフォームは、GitHub上の90億以上の膨大なイベントデータを活用して、OSSプロジェクトのトレンド、貢献者の活動、リポジトリの成長など、多角的な分析機能をリアルタイムで提供している。具体的には以下のような機能を提供している。

　GitHubは世界中の開発者が常に更新を行っているという意味で、24時間365日稼働するワールドワイドなOLTPシステムだと見なせる。その巨大システムからリアルタイムにデータを集計してインサイトを抽出するということは、従来のOLTP/OLAPを分離するシステム構成を前提にしては不可能なことである。HTAPデータベースによって初めて可能になった好例と言えるだろう。

HTAPの主流になるのはどっち？ 「密結合 vs 疎結合」　

　これは筆者が個人的に行っている分類なので特に公式なものではないが、HTAPを実現するアプローチには2種類あると考えている。それが密結合と疎結合である。前述のAlloyDBやUnistoreといった単独のDBMSの中に2つの異なるアーキテクチャのデータベースを包含するのが密結合だとすれば、疎結合の代表はAWSの「Zero-ETL」である。

　AWSは、OLTP（Aurora）とOLAP（Redshift）は分離しておこう、と言う。そこは保守的である。その代わり、両者を接続するETLをCDCによって極力リアルタイムに近い形でデータ連携を行う、究極的には「ETLをゼロにする」という方向の発想である。AWSはこのサービスをHTAPとは呼んでいないが、目的は分析のリアルタイム化にあるため、筆者は疎結合型のHTAPと呼んで差し支えないと考えている。

　密結合型の方が、トランザクション処理と高速な分析クエリを同一システム上でシームレスに実行可能というメリットがあるが、疎結合型の方にも様々なデータソースからデータ統合が可能というメリットがある。「密結合 vs 疎結合」のどちらがHTAPの主流になっていくかは、今後数年の動向を見る必要があるだろう。

まとめ

　さて、3回にわたってTiDBをモデルにNewSQLというデータベースのアーキテクチャやユースケースについて見てきた。データベースのようなバックエンドの技術は、フロントエンドの技術に比べると一般に技術革新のスピードが遅いが、NewSQLとHTAPは久々にデータベースの世界に訪れたビッグウェーブになる可能性を秘めている。当初、NewSQLは「ハイパースケールRDB」というコンセプトとして登場したが、第2回で見たように最初想定しなかった応用方法が発見されてきている。こうした新たなユースケースの発見が、社会へ浸透していく鍵になるだろう。

　同様に、HTAPの浮沈もそのユースケースにかかっている。ECや金融の不正検知だけでは市場が少し小さいだろう。今後エッジデバイスやロボット、車両にもAIが搭載されてエッジAIの用途が増えてくると、膨大な量のセンサーデータをリアルタイムに分析処理する必要が出てくるため、光の当たる可能性のあるコンセプトである。今後も2つのキーワードに着目してデータベースの技術を見てもらえると、理解の助けになるのではないだろうか。