コミュニティ版に断念も「TiDB Cloud」を検討へ、その魅力は
先述した課題を抱える中、検証に着手したのは分散型のNewSQLである「TiDB」だ。まずはOSSである「TiDB Community Edition」のTiDBを検証してみたものの「自分たちの体制だけでは、TiDBをAmazon EKS（Elastic Kubernetes Service）などに載せて運用し続けることが難しいと感じました」と田幸氏。特にTiDBは、新機能開発や機能改善が日々行われているため、最新情報を追い続けながら適用すべきか否かを適宜判断し続けるような運用が難しいのではないか、と懸念したという。
加えて、OSSコミュニティへの問い合わせやサポート体制への不安も拭えず、コミュニティ版の採用は見送られた。その後、新たなアプローチを模索する中、PingCAPから紹介を受けたことで検討を進めたのが「TiDB Cloud」だ。
TiDB Cloudは、TiDBをフルマネージドでクラウド利用できるサービス。PingCAPからServerlessとDedicatedという2つの形式で提供されており、Serverlessはマルチテナント型、Dedicatedは専有型となる。PingCAP シニアソリューションアーキテクトの日下太智氏によると、TiDB Cloudではマシンスペックや台数を柔軟に変更でき、Serverlessはスケール操作が自動化され、DedicatedはGUIまたはAPI経由で変更可能な点が特徴的だという。なお、TiDBはMySQLとの互換性が高いことから関心を集めることも多いが、完全互換ではない点は留意したい。
また、分散型SQLデータベースであることもTiDBの特徴だ。アプリケーションからは、単一のMySQLデータベースのようにも見えるが、実際には4つのコンポーネントで構成されており、ノード追加やスペックアップも容易だ。
TiDBは、各テーブルのプライマリキーの範囲でシャーディングを行い、2つのストレージコンポーネント「TiKV」「TiFlash」を有している。基本的にはTiKVを用いるが、アドホック・クエリによる大量データを集計するためには、カラム型のデータストアであるTiFlashも利用できるという。残る2つのコンポーネントは「TiDB」「PD」であり、TiDBノードは、SQLクエリを受け付け、TiKVまたはTiFlashに転送する役割を担う。そしてPDは、シャードされたデータの位置情報を管理するコンポーネントだ。
従来のRDBMSでは、書き込みスループットの限界に対処するために水平シャーディングが必要だった。しかし、TiDBではシャーディングが自動で行われるため、アプリケーションからは単一のデータベースとして見える。実際には、データは3つのコピーで冗長化され、単一AZ障害にも対応できるという。
なお、バージョンアップやDDLなどもオンライン実行可能だ。何よりも分散型アーキテクチャであるため、多少のネットワークオーバーヘッドが発生するものの、スループット向上を期待できる点が最大のメリットといっても過言ではないだろう。
