どのデータベースも一長一短、適材適所で組み合わせることが多かった
今回のメインテーマは分散データベースの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を覚える必要があるとか、ツールが多数あるとか、学習のコストや運用のコストが生まれてきます」と指摘する。
