「TiDB」が注目される理由――「TiDB User Day 2023」でプレイドやMicoworksが語った検証結果と課題：「HTAP」の現状と未来

「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介していきます。今回は「TiDB User Day 2023」で気になったセッションを中心に紹介します。

[小林隆浩，＠IT]

　多くのエンジニアから「既存のデータベースサービスでは性能目標やメンテナンス時間などの要件を満たすことが難しい」という声を聞きます。アプリケーション開発のスピードが上がり、そのアジリティにデータベース技術も追随する必要がある点は筆者の過去連載でも述べましたが、開発現場でどのような課題意識をもって、新たなデータベースの検証をしているのでしょうか。

　本稿では、そうしたリアルな検証事例や採用事例を聞くことができる年次イベント「TiDB User Day 2023」の模様をお伝えします。オフライン会場にも多くのユーザーが集まり、セッション内容もMySQL利用者を中心にDBエンジニアを引きつける事例が豊富に取りそろえられていました。

　イベントでは、大規模に「TiDB」導入を検討している事例が示され、どのようなメリットがあり、どこに課題があるのか、ユーザーから紹介された点に大きく注目が集まった印象です。記事後半で詳しく解説しますが、HTAPと呼ばれるTiDBの特徴に魅力を感じるユーザーが数多く見られました。

　2022年はゲーム業界におけるTiDBの事例が中心でしたが、2023年は金融業界などミッションクリティカルなシステムで検証している事例も紹介されていました。製品の成熟が進んだだけではなく、分散SQLデータベースとしてのTiDBがより広く国内のユーザーに知られるようになった結果を示しています。そうした新規ユーザーはPingCAPが提供する「TiDB Cloud」を積極的に利用しており、構成、運用の難易度が増す傾向にある分散データベースを上手に活用していました。

　イベント冒頭、PingCAPの共同創業者兼CTO（最高技術責任者）であるEd Huang氏のセッションでは、彼自身の課題でもあったスケーラブルなOLTP（オンライントランザクション処理）向けデータベースをMySQL互換で開発し、そこからHTAPを目指してOLAP（オンライン分析処理）機能を合わせて構築してきたTiDBの歴史が詳しく語られました。そして、PingCAPとしてデータベース管理の負荷を下げるためのマネージドサービスの提供を開始し、多くのクラウドベンダーで利用可能としていることが徐々にユーザーに受け入れられ、2023年7月に一般利用可能となった「TiDB Serverless」の利用が急速に拡大していることも紹介されました。

　またMySQL/InnoDBの開発をリードしていたという経歴を持つ同社のシニアアーキテクトSunny Bains氏は、大規模OLTP向けに行っているTiDB/TiKVのさらなる性能改善の具体例を示し、セッション後もイベントに参加しているエンジニアたちと積極的な議論を交わしていました。同氏のセッション内で示されたリソースコントロールやオンラインDDL（データ定義言語）対応は、TiDBを長期的に運用する中で利用が増えていく機能となるでしょう。セッション最後には2023〜2024年のプロダクトロードマップが示され、その中にMySQL 8.0対応も上がっているなど今後のさらなるTiDBの発展を予想させるのに十分な内容でした。

　ここからは、数多くのセッションの中から特に筆者が気になったセッションについて、NewSQLが置かれている現状と合わせて紹介していきます。

「プロダクト分析サービスの超高速集計レイヤーとしてのTiDB」

　プレイドの小川拓也氏（Lead Product Engineer）によるセッションでは、タイトルの通り、分析基盤としてのTiDB/TiFlashの検証結果が共有されました。

　プレイドはWebサイトの訪問者の行動をリアルタイムに解析できる顧客体験プラットフォームとしてKARTEを提供しており、大量のトラッキングデータを高速に解析する必要があります。現在のデータ分析基盤は、クラウドベンダーが提供するリレーショナルデータベースやデータウェアハウス（DWH）を組み合わせて構築していますが、データ加工の煩雑さやリアルタイム性に課題があり、何より大規模データの分析における応答速度を今以上に向上させたいという大きな目標を持っていました。その目標は「0.x秒以内で分析処理をさばくことを目指す」と非常に野心的で、同社はTiDB以外にもさまざまな専用DWHを検証しています。

TiFlashのイメージ図（小川氏の講演資料より）

　プレイドはTiDB Cloudを用いて、TiKVノード3台とTiFlashノード1台という構成で、OLAPの性能にポイントを絞って同社が求める応答性能をクリアできるかどうかを検証しました。その観点でセッション後半ではJSONの扱いやテーブルのパーティション設計など、一般的なOLAPのチューニングをTiDB/TiFlashでどのように実現可能にするか詳細な解説があり、現時点で専用のデータウェアハウスと比較するとTiFlashの機能として不足している部分（JSONの各フィールドへの簡便なアクセスなど）にも言及がありました。

　TiDBはTiKVとTiFlashのデュアルストレージとして機能するため、オプティマイザ次第でレコード形式とカラムナ形式の2つのストレージエンジンに処理を振り分ける可能性があります（詳細は後述します）。こうした構成でも想定した速度でレスポンスが返ってくるのか、特にレコード形式側を参照した際に性能向上する際に正しく選択できるのか懸念があったとのこと。小川氏によるとその点も問題なく、TiDBの成熟度の高さをあらためて認識する結果となりました。

　検証結果を踏まえ「TiDBがOLAP特化のデータベースに比肩し得る性能を持っていた」と小川氏は説明しています。プレイドが抱える大規模データの検証は今後実施とのことでしたが、TiDB/TiFlashは個別にノードを増やして水平スケールが可能で、その点もポテンシャルが高いと評価をしていました。TiDB Cloudによるフルマネージドなサービス運用も魅力的で、専任のデータベース管理者を置かずに高度な分散型のHTAPデータベースを利用できる点が素晴らしいという話もありました。

　もちろんTiDB利用による課題もあり、OLAP機能のさらなる成熟化やコスト改善などを、PingCAP社と協力して利用に向けて前進していく予定とのことです。

「アジアNo.1のマーケティングSaaSを目指すMicoworksがNoSQLからNewSQLに移行した理由」

　2つ目はMicoworksの陳 瀚（Chen Han）氏（プロダクト統括本部 SREチーム Senior Specialist）による、複数の目的別データベースを利用する構成からTiDBのHTAPの特徴を取り入れてシステムをシンプル化した事例の紹介です。

　Micoworksはチャットを活用したマーケティングツールであるMicoCloudを提供しており、チャット上の顧客の反応を分析可能な形で迅速に提供する必要があります。そのため、基盤の堅牢（けんろう）性をかなり重視し、以前はクラウドベンダーが提供する目的別のデータベースを次のように使い分けていました。

• 配信やアンケートなどのマスターデータを管理する、リレーショナルデータベース
• 大量のデータ流入、更新が可能な、スケーラブルなNoSQLデータベース
• 顧客のセグメントを分類して検索、分析が可能なDWH

　こうした構成は他社の大規模システムでもよく見られるものです。マネージドなサービスをうまく取り入れたとしてもシステム運用に手間がかかり、目的別に異なる3つのデータベースを使うことでそれぞれの機能や性能を最大限生かすことは難しかったと、陳氏はセッション内で述べています。特にノウハウが不足していたデータウェアハウス部分のパフォーマンス最適化が同社の課題だったそうです。

　そこで複雑さを解消し、運用性の向上と分析計処理の性能改善を見込んでTiDB/TiFlashに移行することが決まりました。具体的には、上述した中でもマスターデータ管理のリレーショナルデータベースはそのまま残し、NoSQLとデータウェアハウスをTiDBを用いて統合しています。これにより、従来必要だったNoSQL→DWHのデータ同期処理をなくすことができたとのこと。陳氏は、TiDBはMySQLとの互換性を担保しているため、なじんでいたSQLベースの開発やORマッパーなどのツール利用が可能であったことも生産性の向上に寄与したと言います。

　セッションでは、それまでNoSQLとDWHそれぞれが達成していた応答性能を、TiDBとTiFlashの組み合わせで担保できたか検証結果が示されました。プレイドの事例と同様に、TiDBのオプティマイザがレコード形式の検索が必要なクエリではそちらを自動的に選択し、カラムナ形式の集計が必要なクエリではTiFlashを選択することで、想定していた性能が満たされることが示されました。

　同セッションでは、Micoworksが非常に迅速にシステムの移行を完遂したことに対して多くの質問が寄せられました。TiDBのMySQL互換という特徴を生かして複数の機能を寄せることで、開発者の生産性が向上することを説明されていました。

TiDBとHTAPの未来

　今回のTiDB User Dayで示された「TiDB」や「HTAP」はこれからどう進展していくか、そして現状はどこに課題があるのでしょうか。

　HTAPとは、Hybrid Transactional/Analytical Processingの略語で、データベース業界では以前からさまざまなベンダーによって提唱されてきた概念です。オンライン系のトランザクションと分析系の長時間クエリを単一のデータベースクラスタで処理しようとする試みであり、これまでさまざまなな製品、サービスが下記の①と②を交互に繰り返す形で進歩を続けてきました。

①	分析データの大容量化に伴い、専用DWHの機能や性能が発展する
②	インメモリやカラムナなどの形式で従来のRDBMSにデータを併せ持ち、分析系クエリを処理するHTAPが発展する

　特に近年ではクラウドベンダーが提供するデータ分析基盤が強力かつユーザーフレンドリーで、多くの企業で①の専用DWHを用いて、そこにデータを流し込むパイプラインを実装する流れが続いていました。しかし、課題はパイプライン処理の実装に移ることになり、複雑化によりメンテナンス性が下がるという問題が起き始めています。本来、処理後のデータを分析することでビジネス的な価値が生まれますが、パイプラインのメンテナンスにエンジニアの力が割かれる結果となってしまっているのです。

　TiDBは「MySQL互換の分散SQLデータベース」であり水平スケーラビリティと高い可用性に特色を持ちますが、同時にTiDB 4.0以降で導入されたTiFlashというカラムナ形式のデータストレージ機能を備えています。今回のTiDB User Day 2023ではスケーラビリティのベンチマークよりもHTAPという特徴に参加者の注目が集まっていたと著者は感じています。

　上述したように、HTAPはPingCAPのみが提供するものではないため、他のベンダーがどのような形で類似サービスを提供しているかを理解することはデータベース選択の大きな助けとなるでしょう。それらの一部を下表に整理します（※これ以外にもHTAPを提供するサービスは多く存在します）。

ベンダー	製品、サービス名	カラムナ保持形式
PingCAP	TiDB/TiFlash	ディスク
Microsoft	Citus（Azure Cosmos DB）	ディスク
Oracle	MySQL HeatWave	インメモリ
Google	AlloyDB	インメモリ

　まず、PingCAPのTiFlashとMicrosoftが提供するCitusでは、レコード形式（行）とカラムナ形式（列）のデータを、それぞれ別にディスクに永続化して保持します。一方でOracleのHeatWaveやGoogleのAlloyDBでは、レコード形式をディスクに永続化し、カラムナ形式はメモリに展開します。当然これらには一長一短がありますが、TiFlashの方式ではメモリよりも広大な領域にカラムナ形式のデータを展開できるため、広範囲なデータの分析に対応できるというメリットが生まれます。

　こうして現状を整理すると、リレーショナルデータベースに強力な分析機能が加わったTiDBや他のHTAP対応データベースが発展すると、次は独自の分析機能を発展させた専用DWHが登場してくる未来が予想できます。AI（人工知能）による分析や現在課題となっているパイプラインの開発効率化などを実装する製品、サービスが現れるなどです。

　そのため、プレイドの事例のようにビジネス価値のクリティカルな部分は常に最新の技術をキャッチアップしながら、より良い構成に向けた検証を繰り返す姿勢が求められます。またMicoworksのように現在トレンドとなっていても目的別のデータベースという構成に疑問を持ち、HTAPによる統合型のデータベース利用が次のトレンドとなること、自社にとってメリットをもたらすことを迅速に判断し、アーキテクチャを変更していく手腕も同時に必要になってくるでしょう。

TiDB/TiFlashの今後の課題

　TiDB/TiFlashの利用については、今回イベントのセッションや議論においてさまざまな課題が提起されました。その中からHTAPということに限れば、以下が解決すべき問題点となってくるでしょう。

1. 分散SQLデータベースとしてTiFlashも並列利用する際の、データ容量の増加
2. TiDB Cloudにおけるリソース利用の柔軟性

　データ容量の増加は、TiDB+TiKVという構成で1レコードにつき最低3つのレプリカを持ちます。そして、TiFlashでそれとは別にカラムナ形式のデータを保持します。つまり、その分のストレージ容量コストが発生します。今回のイベントではTiKVとTiFlashの圧縮率はかなり高いことが示されていましたが、データ総量がペタバイト級になればレプリカによる影響を無視できません。

　1のデータ容量の増加は、他の分散データベースで用いられているWitnessノード（データのレプリカを持たないが、分散データベースに必要な合意には参加して耐障害性を高める構成）を採用して対策可能だと考えられます。

　2のリソース利用の柔軟性は、TiDB CloudでTiFlashを構成すると利用可能なノードのサイズが限定されており、コスト最適化が難しい点がユーザーの声として上がっていました。TiDB Serverlessが発展すれば解消されていくでしょう。

最後に

　本稿ではTiDB User Day 2023のイベント模様をお届けしました。国内でこのような大規模な分散SQLデータベースのイベントが行われることを、これまでNewSQLを取り上げてきた一個人として非常にうれしく思っています。またPingCAPがユーザー、エンジニアと真摯（しんし）に向き合ってサービスを改善する姿勢を示していたことから、国内にTiDBファンが増えることを確信しています。

　イベント後はデータベースの世界で長年課題になっているトランザクション系と分析系の統合について、懇親会でも議論が盛り上がりました。こうしたエンジニア同士の意見交換はオフラインでのカンファレンスにおける大きな長所であり、素晴らしいことです。

　2023年後半に向けて、データベースに関するイベントが複数予定されています。今後も本連載を通じて読者の皆さまに情報をお届けしていきます。

筆者紹介

小林隆浩

さまざまなプロジェクトで基盤担当のエンジニアとして経験を積む。なかでもデータベースに関する設計、運用、トラブルシューティングなどの業務で実績があり、得意とするDBMSはOracle DatabaseおよびPostgreSQL。データベースや基盤技術に関するコミュニティーに積極的に参加し、国内外のカンファレンスで登壇実績を持つ。