どのデータベースも一長一短、適材適所で組み合わせることが多かった
今回のメインテーマは分散データベースのTiDB。その前に、まずは昨今のデータベースに求められる要件を知るサンプルとして、PingCAP 林正記氏は「OSS Insight」というサイトを示した。
これはPingCAPが「オープンソースプロジェクトの活発度を可視化したい」ということで作成したサイトとなる。GitHubのイベント情報から、スターをどれだけ獲得したか、どの地域の開発者が多いのかなどいろんな角度から可視化できる。元となるデータは56億レコードにもおよび、リアルタイムで増え続ける。またこのサイトでは標準UIで用意していない可視化にも対応している。こうした規模や要件は昨今のWebサイトやアプリケーションであれば珍しくないのではないだろうか。
こうした要件があるなか、データストアはどうするか。特殊な用途であれば別だが、よくある選択肢となるのがRDB（OLTP向け）、RDB（OLAP向け）、NoSQL、Hadoopだ。スケールするものがほしいのであればNoSQLやHadoop、複雑な分析や集計があるならRDB（OLAP）、更新頻度が高いのであればRDB（OLTP）やNoSQLなどおおよその傾向はあるものの、1つのデータベースで全てをカバーするのは難しい。
どれも一長一短なのだ。例えばRDB（OLTP）だと更新に強くてもスケールに限界があるとか、分析クエリが得意でないとか。NoSQLだとスケーラビリティはいいけど、JOINを含むような複雑なクエリに対応しづらいとか。
そのため現実的には複数のデータベースを組み合わせたりする。更新部分ではRDB（OLTP）をシャーディングしてスケーラビリティを確保し、KafkaなどでETLパイプラインを構築し、DWHにデータを流すことでデータを同期する。よくあるクエリはクエリキャッシュをつけたりする。結果的にアプリから見ると、RDB（OLTP）とRDB（OLAP）の2系統からデータを引っ張ってくるということが必要になってくる。
林氏は「これはこれで1つの姿ですが、新しいKafkaを覚える必要があるとか、ツールが多数あるとか、学習のコストや運用のコストが生まれてきます」と指摘する。
高頻度で更新され、OLTPとOLAPの両方が求められるときにどうすべきか
それでは「更新用にRDBをシャーディングして、ETLパイプラインを構築し、DWHに同期」というところを新たな技術を利用することでシンプルにできないかと考える。具体的には、①NewSQLでシャーディング不要とするということと、②HTAPでOLTPとOLAPを1つのデータベースで実現するという2つのアプローチを考えてみる。
①NewSQLでシャーディング不要とする
NewSQLとは、MySQLのような分散アーキテクチャでスケーラビリティを保ちつつ、分散トランザクションができるような仕組みもあり、シャーディングに頼らずスケーラビリティを獲得できるようになっている。またNewSQLでは有名プロトコルと互換性があるため、MySQLやPostgreSQLのようなスキルを活かすことができる。
該当するデータベースにはSpanner、TiDB、CockroachDB、YugabyteDBなどがある。
②HTAPでOLTPとOLAPを1つのデータベースで実現する
HTAPとは、OLTPとリアルタイムOLAP分析を1つの基盤でできるようにしたもの。OLTPとOLAPを両立させようとする試みはこれまで幾度となくあったものの、現実的には適材適所で使い分けることが多かった。なぜならOLTPは行型（ローベース）、OLAPは列型（カラムベース）でデータ配置や構造が異なるためだ。
そこでOLTPとOLAPを1つのデータベースで実現しようとしているのがHTAPとなる。目的は同じでも行と列をどう持つのか、その実装方法にはメモリ型とストア型の2種類がある。メモリ型となるのがAlloyDBで、メモリ内に持つので容量に制限が生まれてしまう。データ容量が増えるほど、ストア型が有利となる。ストア型となるTiDBはTiFlashにより大容量のデータのカラム化が可能となる。
該当するデータベースにはAlloyDB、SingleStore、TiDB、Snowflakeなどがある。
これら①と②の両方とも、該当するのがTiDBだ。NewSQLであり、HTAPでもあるデータベースとなる。
ではTiDBはどうしてNewSQLとHTAP、更新・参照と分析を両立させることができるのだろうか。林氏によると「TiDBは2つのエンジンを搭載し、あらゆる業務を1つのプラットフォームで実施可能。また全てのコンポーネントがリニアにオンラインスケールアウト・インが可能」となる。
TiDBのアーキテクチャの大きな特徴はストレージエンジンを2つ持つことができるところだ。更新・参照用（OLTP）のストレージエンジンにTiKVがある。こちらはローベースのストアになっている。また分析用（OLAP）ストレージエンジンにはTiFlashがある。こちらはカラムベースのストアだ。
アプリケーションからTiDB（データベース）に何らかのリクエストが届くと、クエリ処理コンポーネントが更新処理か分析処理が自動判別し、適切なエンジンに処理を実施させる。そしてTiKVで更新されたデータは、分析用のTiFlashへと同期されるようになっている。こうした仕組みで、これまで両立できなかったことを両立できている。
当初、PingCAPで開発されたTiKVは、後にCNCF（Cloud Native Computing Foundation）へと寄贈され、今では「Graduated」ステータスになっている。GitHubでは3万2000以上のスターがつくほど人気だ。また林氏は「実はこのTiDBはMySQL互換ということもあり、性能問題を抱えたMySQLの受け皿になっている側面もあります」と話す。
デモで紹介！ NewSQLのスケールアウト、HTAPの実行計画
林氏は2種類のデモを実施した。1つめはNewSQLとしてのデモとして、スケールアウトを実施して見せた。GUIの管理画面を開くと、現在の構成が確認できる。例えばTiDBが何台、TiKVやTiFlashが何台あるという具合だ。もし性能が足りなくなれば、管理画面から必要な台数を増やせばいい。オンラインでスケールアウトが実行できて、とても手軽だ。
2つめはHTAPデモとして、クエリの実行計画を確認する。サンプルでは、Webサイトでレポートを表示するようになっていて、それが24時間、1週間、1か月と期間を選ぶことができる。対象となるデータは50億ほどあり、比較的処理が重くなるクエリを走らせる。まずは24時間を選んで実行し、explainの画面を見ると「Row」と表示され、ローベースのTiKVで処理しているのが分かる。続いて、レポートの期間を1週間に変更して処理を実行する。SQL文は同じだがデータ量は増えている。画面を見ると「Column」と表示され、オプティマイザーがカラムベースのTiFlashで処理を始めたことが分かる。
こうしてTiDBではOLTPもOLAPも、オプティマイザーが判断するのでTiDBだけで処理できるようになっている。そのため複数のデータベースを組み合わせて、複雑な構成にすることはない。アプリケーションの構成はとてもシンプルになる。
フルマネージド型「TiDB Cloud」も利用可能
TiDBはフルマネージド版となる「TiDB Cloud」も利用できる。AWSやGoogle Cloudのクラウドプロバイダー上で、TiDBを従量課金制で利用できる。こうしたクラウドプロバイダーで有料で提供されるものは「Dedicated Tier」と呼ばれる。
フルマネージド型なので、クラウドプロバイダーで設定すれば利用開始できる。サーバーを用意する、ソフトウェアをインストールする、ロードバランサーを立てて、障害対応やメンテナンス対応するといった構築と運用作業はPingCAPに任せることができるのがメリットだ。
なお現在、無償トライアルが提供されている。サイトを開き、サインアップしたら、後はクラスタを設定していく。
クラスタの名前、クラウドプロバイダー（※無償トライアルではAWSのみ提供）やリージョン、コンポーネント数や容量などを入力して、最後に「Create」をクリックする。この背後ではVPCの作成し、セキュリティグループの作成、EC2やロードバランサーを立てるといった処理が自動的に進められる。一般的には15～20分ほど待つと、ステータスが「Available」に変わり、「後はMySQLっぽく使えます」と林氏。SSHクライアントからデータベースの一覧を表示したりできる。
ChatGPTを統合し、自然言語からクエリを自動生成
TiDBで目を引く話題となるのが今人気のAI、ChatGPTとの統合だ。エンジニアならChatGPTのアウトプットのサンプルを見たことがない人はいないだろう。TiDB Cloud Serverless TierではChatGPTを使うことでクエリ生成機能を実現している。つまり、自然言語を入力することで（SQLを知らなくても）有効なクエリを作成できる。例えば「2020年の本塁打数トップ10」と入力すれば、SQLが自動生成される。
実在するデータベースのスキーマを理解し、該当のデータベースを指定し、選手名・本塁打などの項目を選び、「ORDER BY 本塁打」や「LIMIT 10」などを組み込んでクエリ生成を生成する。これをアプリケーションに組み込めば、ユーザーは自然言語から好きな情報を取り出せるようになる。
最後に林氏は「NewSQLとHTAPを併せ持つTiDBにより、今まで複数のシステムで実現していたサービスが1つのデータベースで構成できるようになり、全体の運用コストと学習コストが抑えられるようになります。もう大容量、高性能、分析といった要件は怖くありません。さらにAIのクエリ生成機能を使えば、ユーザーのカスタマイズ性を高めるサービスを作れます」とTiDBのメリットを強調した。
