リアルタイム分析を現実にするHTAPの進化
ミック氏は、HTAP（Hybrid Transactional Analytical Processing）の話題に入る前に、従来のデータベースアーキテクチャの常識について説明した。基幹系と情報系の分離は、その代表的な考え方だという。
基幹系は、銀行の取引や在庫管理などのリアルタイム処理を担うもので、安定性や高可用性が最優先される。これに対し、情報系はビジネスの意思決定を目的に、大量のデータを集計・分析する役割を果たす。
両者の分離が一般的である理由は、パフォーマンスと安定性のバランスにある。基幹系システムではダウンタイムは致命的だが、情報系では重いクエリの処理時間を高速化することに主眼がおかれる。そのため、情報系ではMPP（Massively Parallel Processing＝超並列分散処理）と呼ばれるシェアードナッシング構成が主流となっている。データを複数のノードに分散し、並列処理によってクエリを高速化する仕組みだ。
「この方式は分析処理には適しているものの、OLTP（オンライン取引処理）には不向きだ」とミック氏は指摘する。クエリの多重度が増えるとレスポンスタイムが線形に悪化する。そのため、基幹系と情報系は明確に分離する必要があるというわけだ。
そんな常識に対し、「基幹系と情報系を統合した単一のデータベースを作れないか」という発想を提示したのが、調査会社ガートナー社である。2014年に提唱されたHTAPのコンセプトは、「リアルタイムのトランザクションデータをそのまま使って分析できないか」というものだった。
理想的なコンセプトであるのは確かだが、「従来のアーキテクチャでは実現が難しかった」とミック氏は指摘する。それでも、近年この難題に挑戦するベンダーは増えており、先述のTiDBやGoogleのAlloyDB、SnowflakeのUnistoreなどがHTAPのコンセプトを掲げている。
HTAPの仕組みは、発想としては極めてシンプルだ。基幹系のデータは行ベース（Row-based）で保存し、追加や更新を最適化。一方、情報系のデータはカラムベース（Column-based）で格納し、集計や分析に特化させる。HTAPデータベースではこれら両方のデータをリアルタイムで同期し、SQLクエリに応じて自動的に最適なクエリエンジンを選択して処理を行うという。これにより、基幹系の安定性を保ちながら、即座に分析を実行できる。
ただし、ミック氏は「このアイデア自体は新しいものではない」とも指摘する。Oracleは12cからインメモリデータベースを提供しており、カラムベースのデータをメモリ上に保持して分析処理を高速化する仕組みを実現していた。つまりHTAPの仕組みは以前から存在していたが、リアルタイム分析への需要の高まりと技術の進化により、2020年代に入り再び注目が集まっているのだ。
HTAPの活用が特に注目されるのは、リアルタイムマーケティングや不正検知、IoTの分野だという。例えば、ECサイトのライブコマースでは、顧客の行動をリアルタイムで分析し、即座にパーソナライズした商品提案を行うことが求められる。金融業界では、異常な送金や決済を即座に検知・対策する必要があり、こうした用途でHTAPの導入が進んでいる。IoTではセンサーからのデータをリアルタイムで分析し、設備の異常を早期に検知するといった使い方が想定されている。
具体例として、中国のECサイトがTiDBを活用してリアルタイムの不正検知やマーケティングを実現したケースが紹介された。従来はHadoopを用いてバッチ処理していたが、TiDBへの移行により、分析速度の向上を実現したという。
一方でミック氏は、日本ではこのようなリアルタイム分析が普及しにくいことを指摘する。その理由として、「リアルタイム分析のメリットよりも、基幹系への影響を最小限にとどめたい」というユーザ心理を挙げた。
NewSQLとHTAPは、それぞれ異なる課題に対応する形で進化を続けている。NewSQLはRDBの整合性やSQLの利便性を維持しつつ、スケーラビリティを高める技術として登場したが、運用負担やリソースの効率的な使用を重視する日本企業にとっても魅力的な選択肢となるだろう。一方、HTAPは基幹系と情報系を統合することでリアルタイム分析を可能にし、特に迅速な意思決定が求められる分野でその有用性が期待されている。
ミック氏の示したこれらの視点は、エンジニアにとって今後の技術選定やシステム設計の重要な指針となるはずだ。技術の進化を見極め、自社に最適なデータベースの形を模索していくことが求められている。
