今年もAdvent Calendarの季節がやってきました。
TiDBのAdvent Calendarは今年で2回目になります。昨年に比べると少しはTiDBを知ってもらえる機会が増えたようなきがしています。

初日の記事として、TiDBとはなにか、そして最近の事例から、TiDBが必要とされる背景について考えてみました。

TiDBとは

TiDBは、端的に言ってしまえば「キーバリューストアをラップしてRDBのように見せてる分散データベース」です。
アーキテクチャの詳細などはPingCAP ソリューションアーキテクトの小板橋さんがZennに書いているのでそちらを参照ください。

ここでは、このアーキテクチャがもたらすTiDB機能的な特徴について書きます。

トランザクション処理やSQLなどで従来のRDBMS相当の機能を持つ
スケールアウトによる性能増強が可能
複数のノードから構成されており、障害時のフェイルオーバーや、データの偏りのリバランスを自動化

というものです。もう一つ大きな特徴として、内部的には小板橋さんの記事にあるように複数のコンポーネントによる依存関係がありますが、ユーザーからみたときは一つの大きなDBとして利用できるという点です。Read/Writeともにスケールアウトによる能力増強が実現でき、かつ一つの大きなDBとして利用できます。
アプリケーションがDBの物理的な構成（Read / Writeエンドポイントやシャーディングといったもの）を扱わなくても良いのはメリットです。

ユーザーニーズ

さて、TiDBを広めていく中で、TiDBを求めるユーザーニーズも明確になってきました。。

TiDBのようなNewSQLデータベースは、一般には大規模なDBや膨大なアクセスをさばくために必要なものとみなされています。しかし、意外なことに、実際のTiDBの利用は、そのようなユースケースだけではなく、もっと様々なニーズを汲み取っていることがわかりました。

そのようなニーズの中で代表的なものを列挙します。恐らくいくつかは読者の皆さんがDBを利用している中でも遭遇しているものではないでしょうか

ワークロードの柔軟性

スケールアウト性も重要ですが、単なる増強ではなくて柔軟にデータベースのサイズを増減させることが求められています。ECなどのユーザーの多くはピークとそうでない時との差が激しく、通常時にオーバースペックで運用することに対して無駄を感じています。

サービスの継続性

DBやインフラ更新をサービスを継続させたまま行いたいというものです。アプリケーションがデプロイ方法を工夫してこれらを提供するようになりつつありますが、DBも含めたシステム全体としてサービスの継続性が求められるようになってきています。

マイクロサービス、マルチテナントでの運用性

マイクロサービスでは、サービス単位でDBないしテーブルを分割するパターンを採用されることが多いです。それらを複数面持つマルチテナントのサービスも多く出てきています。イメージとしてはマルチテナントはマイクロサービスをテナントごとにインスタンス化するようなものです。マルチテナントでの論理的なDBやテーブルの総数はかなりの数に上り、これらの運用改善に対する期待があります。

学習効率の良さ

DBの運用やモニタリングはそれだけで一大テーマです。現在のDBが性能や拡張性に難があるとしても、これらの運用ノウハウの学習や、仕組みの構築に多大なコストがかかるため移行に二の足を踏むケースは多いです。学習のしやすさ、親しみやすさというのは導入に際してかなり重要なポイントです。

これらのユーザーニーズは相互に関係しており、トレードオフを生じさせることもあります。
TiDBは決して完璧なDBではありません。性能だけで言えばより優れたDBのアーキテクチャもあります。その中でTiDBが注目されてきたのは、汎用性が高く、運用・学習が容易な点によるものと思います。

まとめ

この記事ではTiDBの簡単な紹介と、実際にTiDBの利用事例から見えてきたニーズについて記載しました。
実際のところ現代のデータベースの利用法や性能要求は非常に幅が広く、従来の3層アーキテクチャのときのRDBのような位置づけの、「クラウド時代の汎用性の高いDB」が求められており、そこにうまくフィットしているのかなと思います。

私の次の記事ではここ1年のTiDBの更新から、こういったニーズへ対応する機能の強化の過程と事例をみていきたいと思います。

引き続きアドベントカレンダーをお楽しみください！