RDBの課題を克服する新しいDB、NewSQLとは何か
NewSQLは、これまでRDB（Relational Database）がデメリットとする拡張性や処理速度、NoSQLにおけるデータの一貫性や検索機能の甘さを解決し、メリット部分はそのままサポートしてくれるデータベースとして注目されている。
MySQLプロトコルとも互換しているため、RDBに対するスキルセットを活かすことができる。また、NewSQLは完全分散型なので、リードレプリカを通じてレプリケーション遅延がなくなるといったメリットもある。さらに林氏が強調するのは、その運用性の高さだ。
「そもそも分散型のデータベースなので、ノードをまたいだアクセス、クエリー、JOINなど、性能が劣化することなく実施できます」
世界で採用されるTiDBの特徴
NewSQLの主な製品には、Amazon Aurora、Google Cloud Spanner、YugabyteDB、CockroachDB、TiDBが挙げられる。特にMySQL互換があるTiDBは、世界1600社以上の商用環境が採用している注目のオープンソースデータベースだ。
林氏は、TiDBの特徴として以下の3つを挙げている。
- スケールアウト＋MySQL互換
- クラウドネイティブ
- リアルタイム分析
特徴1：スケールアウト＋MySQL互換
TiDBはMySQL互換のデータベースなので、アプリケーション側にMySQLクライアントをそのまま利用できる。MySQL 5.6もしくは5.7の互換が可能であり、今後は8.0以降もサポートしていく予定だという。
以下スライドの緑で囲っている部分が、データベースシステムとして提供しているコンポーネント。TiDBがSQLの解析レイヤーで、TiKVというコンポーネントが実際にデータが入っているデータストアレイヤーとなっている。
「TiDBはMySQLプロトコルを理解し、クエリーに応じてTiDBの方にデータを保存したり、TiDBの中のデータを読んだりします。コンポーネントと共にノードを増やすことによって容量や性能などを拡張することも可能です」
TiKVのデータストアは、3面コピーをすることによって耐障害性を高めており、AZ障害にも耐えうるアーキテクチャである。
注意点としては、大きく3つ挙げられる。1つ目は、ストアドプロシージャ、トリガー、外部キー制約など、サポートしていない部分もあり、MySQL互換は100％ではないこと。2つ目は、トランザクションはスナップショットアイソレーションを使っており、MySQLのRepeatable Readと同等の動きをするように模倣していること。悲観ロックもサポートしているので、結果的に動きはほぼ一緒となる。3つ目は、Auto_Incrementの動きも完全には順番にはならないことである。
アプリ側からアクセスできるコネクタやフレームワークは、Go、Java、Python、Ruby、PHPなど。基本的にMySQLで用意されているツールをそのまま使うことができる。その他のツールが必要な場合は、PingCAPで検証・動作確認も可能とのことなので、問い合わせしてみよう。
事例として、NetEaseのオンラインゲーム「荒野行動」が紹介された。15億行ものデータが格納されているため、リードライトの性能に影響があり、MySQLの互換性を高めたいというのが導入の背景。キャンペーン時には数倍にもなるアクセス数を捌き、終了時には性能を縮小してコスト最適を保つこともできた。
特徴2：クラウドネイティブ
TiDBはオープンソースのソフトウェアなので、コミュニティ版が存在する。サーバー上のLinuxにインストールしたり、Kubernetesをコンテナとしてデプロイしたりすることも可能だ。また、TiDB Cloudというフルマネージドのサービスもあり、AWSやGCP上で開発することもできる。2021年11月にリリースしたTiDB Cloud Developer Tierは、TiDB Cloudを無料で使うこともできる。
「PingCAPのサーバー上でインストールし、ロードバランサーをつけて利用していただきます。障害が起きたときの対応やメンテナンス、ファームウェアのアップグレードなども、PingCAP側で全て行います」
さらにアーキテクチャについても語られた。TiKVのKVはKey-Valueストアを意味しており、実際どのようにデータがレイアウトしているのか、4台構成をイメージして示したものが、以下のスライドである。
TiKVではリージョンという単位でデータが保存されており、プライマリーキーをキーとしてレンジでパーティショニングされ、同容量になるように自動で配置される。この状態でノードを増やしていくと、5台目を追加したときも、直ちに移動が始まって自動的に同容量でスケールアウトする。
この実装はデータベースによって異なる。例えばTiDBとSpannerを比較してみると、データ単位はTiDBが32MBでSpannerは数GBである。データ配置設計においては、TiDBはAUTO_INCREMENTでも構わないが、SpannerはUUID推奨、スケールアウトではTiDBはノードを追加することによって直ちにスケールアウトが開始するが、Spannerはさらにそのスケールアウトするだけにふさわしい負荷をかけていく必要がある。
また、データ整合性を担保するRaftといった新しいアーキテクチャも使われている、例えば、ノードに障害が起きたときに、AとBという2つのノードがあったとしたら、過半数を取ったものが正しいとする耐障害性のアルゴリズムである。
特徴3：リアルタイム分析
3つ目の特徴として紹介されたのは、OLTPのレイヤーをデータハブに進化させて、リアルタイム分析に活用するというもの。例えば、アプリケーションのログを全てTiDBに投入し、それを分析対象にする使い方や、列指向のMPPエンジンやSparkSQLとのコネクタで分析するといった使い方もある。
また、データを列ごとに保存して分析処理を高速化するコンポーネント、TiFlashについても紹介された。HTAPによるリアルタイム分析を実現し、3倍以上の効率化を実現できたという。
最後に林氏は、改めてクラウドネイティブアプリ開発にはスケーラビリティが必要であり、MySQL互換のTiDBを活用してほしいとメッセージを送り、セッションをまとめた。
「TiDBは、オンラインイントランザクションとリアルタイム分析を一つのシステムで実装でき、マルチプラットフォームでの対応が可能。フルマネージドも揃っています。TiDBのコミュニティもあり、Slackでいろいろ質問や相談を受けることもできますので、ぜひ活用ください」
