データアクセスがよりリアルタイムになればと思うことは多々あります。それは、様々な業界にとってそれぞれ異なる意味を持っています。物流であれば、より速い頻度で資源配分を行えるようになることでしょう。eコマースでは、販売情報をもとにしたプロモーション戦略の迅速な調整を意味します。金融の分野でも、リスク管理の迅速化やストップロスのタイムリーな実施に繋がります。

開発者にとっては、コミュニティで最もホットなプロジェクト、最も貢献している組織、最も使われているプログラミング言語などのトピックに関するリアルタイムの洞察を意味します。例えば、あなたの友人が最近どんなプロジェクトに貢献しているか、誰がTiDBの最新のPRに貢献したかなど、より個人的な情報を知りたい場合もあります。しかも、これらすべてをリアルタイムで知ることができると便利です。

 

OSDBリポジトリで最も使用されているプログラミング言語トップ5をリアルタイムで表示

幸いなことに、GH Archiveはこれらの質問に対応するための基本データを提供しています。必要なのは、これらのクエリをサポートするデータベースだけです。とても簡単に見えますね。

実は、よく考えてみると、簡単ではないことに気づくかもしれません。例えば、上の図の人気言語のランキングや、個々のアカウントへの同時アクセス数など、大量のデータを持つ統計データをシステムに提供させたい場合などがあります。

 

一方は高頻度で同期される詳細データサービスに重点を置き、もう一方は大量のデータに基づくインサイトレポートを必要とする、2つのシステムが必要かもしれません。GitHubのインサイトに関わらず、日々の業務で似たような問題に遭遇することがあるかもしれません。

例えば、業務用ゲームのデータサービスシステムを構築している場合、お客様からのこのような問い合わせがあります。「無限の剣を手に入れたのに、バックパックの中に見当たらない！」そのような場合、大量の記録から、その不運なプレイヤーの戦利品データを素早く探し出し、状況の手がかりを得る必要があります。彼は誤って剣を破壊してしまったのか？仕組みを悪用されて盗まれてしまったのか？退屈しているプレイヤーは、単にゲームマスターとおしゃべりしたいだけなのか？

 

その一方で、運用チームも催促しています。「最近登場したクラス『ナイトロード』については、最新のダメージ統計値をすぐに出してください。ダークハンマースキルがイバりすぎていて、すぐにナーフが必要だと思われます。」

 

これらをすべて一緒に実現するには、データベースが必要です。

1. 干し草の中から針を探すようなもの
2. 膨大なデータを素早く分析する
3. リアルタイム更新

 

これまで、大量の詳細なデータを扱うサービスには、NoSQLやデータシャーディングを選択するのが一般的でした。NoSQLは、大量のホットデータを保存するための人気のある選択肢ですが、その欠点もまた明らかです。複雑なセマンティクスを表現するためにSQLを使うことはできませんし、主キー以外の項目を通じてデータを見つけるための適切なインデックスメカニズムも欠けています。

 

一方、データシャーディングはかなり面倒な作業です。クラスタを拡張したり、パーティションキーを設計したりするのも大変な作業です。さらに、分析サービスでは、分析専用のデータベースを導入し、リアルタイムのETLパイプラインを整備する必要がある場合もあります。少数のミッションクリティカルなアプリケーションの場合は、ただ歯を食いしばってやればいいのです。しかし、分析やデータサービスなど、ますます複雑化するニーズに対しては、それに見合うだけの価値があるかどうかを検討する必要があります。

 

選定にあたっては、従来のデータベースのSQL機能、成熟したインデックス作成メカニズム、リアルタイムレポート機能、拡張性などを備えたソリューションが求められます。さらに、エンジニアリングの難解な知識を必要としない、シンプルなソリューションであることが望ましいです。

 

そう、TiDBはそれらすべてを備えているのです。

HTAPデータベースであるTiDBは、トランザクションサポートと高性能な分析の両立を簡単に実現できます。ユーザーが詳細なデータを検索したい場合（例えば、GitHub IDや所属組織を経由して最新のコミット履歴を検索する）、複数の次元に対して細かいインデックスを構築することで、高速な検索と高い並行性を実現することが可能です。同時に、TiDBの分析エンジンであるTiFlash は、高頻度な更新をサポートするように内蔵されています。カラムストレージシステム（そう、数十万TPSのトランザクション更新も可能）により、データをリアルタイムかつシームレスに同期して分析することが可能です。ユーザーはクエリの種類を気にせずSQLクエリを実行するだけで、オプティマイザーが自動的に最適な実行計画を選択します。実際、どのエンジンがより適しているか、ユーザー自身が正確に区別することはできないかもしれません。個々の組織に対するクエリについて考えてみましょう。3〜5人の小さな組織であれば、創設以来の GitHub イベントは 10,000 を超えないかもしれません。一方、MicrosoftやAlibabaのような大企業では、データ量の差は桁外れになります。そのような場合、異なるデータベースにワークロードを分けることはおろか、エンジンの選択もかなり難しくなってきます。TiDBの場合、選択は自動的に行われます。統計的な推定により、TiDBはアクセスされるデータ量を「推測」し、それをコストモデルと組み合わせて、最も適切な実行計画を見つけることが可能です。さらに、 TiDBはMySQLと互換性があり、十分な人材を備えています。そのため、開発サイクルを大幅に短縮することができます。

 

実際、OSS Insightのような興味深いプロジェクトに加え、TiDBは、履歴の注文サービス、広告、リスク管理、データハブ、物流追跡など、同様のリアルタイムデータの洞察やサービスにおいて幅広い用途があります。

 

リアルタイムデータの価値を引き出すことがますます重要になってきていますが、TiDBがお役に立てればと思います。