私の父は、私が間違ったレンチを使って急いで機械的な仕事をこなそうとしている（そして物事を苛立たせるような混乱に陥れている）とき、大抵の場合、「コースは馬のためにある」とよく言っていました。これは別の言い方をすれば、「仕事に適した道具を使え」ということです。私はここ数年AWSのデータベース（特にDynamoDB）で多くの仕事をしてきたが、AWSの “目的に合わせて構築された “データベース戦略は、同じ堅実な指針の応用であると理解するようになりました。データベースにはタダ飯はないのです。トレードオフの正しいセットを選択することがすべてだと思ってます。（CAPとPACELCはこれを教えてくれるます）。

人々がSQLに強力なクエリ機能を求めるとき、複数のレコードにまたがる一貫性、トランザクションの分離、原子性を期待します。歴史的に、このような特性をターゲットとするデータベースは垂直スケーリングに依存しており、ストレージ、コンピュート、接続処理のすべてを単一のシャードに集中させていました。これはスケーラビリティの問題をもたらし、これらの特性を水平方向にスケールするモデルに引き継ぐことは、分散システムにとって解決困難な問題である。10年前、NewSQLデータベースはこのようなSQLデータベースのシャーディングのために、よりシンプルなアプローチを組み込み始めましたが、近年では真の分散SQL（開発者はシャーディングされていないデータベースと同じように一貫性に関するグローバルな仮定を立てることができる）へのシフトが進んでいます。私たちは間違いなく、データベースの進化における黄金時代のようなものを迎えています。皆さんがよくご存知のSQLデータベースにおけるグローバル一貫性の課題に取り組む企業やプロジェクトがあります。

ケーキを食べながら

最近、この分散SQLの分野でエキサイティングな選択肢について学んでいる： TiDB（PingCAP）です。気に入った点はたくさんあります。TiDBはオープンソースで、MySQLと互換性があり（通常のMySQLクライアント／ドライバを使用）、必要に応じてシャード間で水平にスケールするが、トランザクション（OLTP）のニーズをサポートしながらデータ全体のグローバルな一貫性を保持します。
そして、私が特に興味をそそられるのは、TiDBはデータを行形式（OLTPに最適）と列形式（多くの重い分析クエリ（OLAP）に役立つ）の両方で保存します。ハイブリッド・トランザクション/分析処理（HTAP）は、OLTP SQLデータベースでは長い間可能でしたが、行ベースのストレージには制約がありました。TiDBはその境界を変え、HTAPをより幅広いユースケースの要件に対して、より柔軟で合理的なアプローチにします。

ちょっとの工夫で、何が得られるのか？

トレードオフの話をしたのを覚えていますか？データベースからの全ての読み取りが一貫している必要はありませんし、トランザクションの分離を尊重する必要もありません。これらの読み取りを別の最終的に一貫性のあるストアを使用するように調整することで、一貫性のあるトランザクション・ストアを使用する必要があるデータ操作のコストとスケーリングをスムーズにすることができます。これは、最終的に一貫性のある読み取りのスケールを改善する手段として、別のノードへの非同期レプリケーションを使用する従来のSQLデータベースで見たことがあるかもしれません。もう1つのアプローチは、インメモリストアをキャッシュとして適用することです。残念ながら、アーキテクチャにキャッシュを追加することは、一般的に、より多くのインフラ管理と運用の複雑さに取り組むことを意味します。PingCAPが提供するTiDBクラウドのようなコンポーネントを利用することで、アーキテクチャを簡素化し、運用のオーバーヘッドを削減したい場合、これは特に魅力的な提案ではないです。

そうここで朗報なのが、Momento Cacheを使えば、真のサーバーレス・キャッシュのシンプルさとコスト削減を手に入れることができるということです。

すべてまとめると

TiDB CloudとMomento Cacheは魅力的な組み合わせです。実際、TiDBチームの一人が、tidb-momento-exampleというAWSの実装例を作っています。

最初にRead-Aside Cacheの例を試してみました。Lambda関数形式のJavaアプリケーションです。このアプリケーションはTiDBからデータを取得し、将来の読み込みのためにキャッシュに保存します。X-Rayを使うことで、最終的な一貫性が許容される読み出しで得られるレイテンシの改善が簡単にわかります。

次に、同じリポジトリにあるSpring Bootのサンプルアプリケーションを試してみました。これは、アノテーションを使ってread-asideキャッシュを簡単に構築する方法を示しています。Springのアノテーションによって、開発者はコンパイラやフレームワークによって解釈されるメタデータをクラスに関連付けることができます。なぜこのような機能が複雑なソフトウェア環境において重要なのかについては、Edwin Riveraの記事を見てほしい： CBS Sportsのファサードに関する興味深い事実。アプリケーションを実行すると、localhost上でアクセスできる2つのエンドポイントがあります。1つは常にTiDBに直接アクセスして行を更新し、その直後に同じ項目を読み込みます。もう1つのエンドポイントは、最初にキャッシュからアイテムを取得しようとし、見つからなかった場合は、通常通り更新/読み込みを行い、結果をキャッシュに書き込みます。curlやwgetのようなクライアントを使えば、エンドポイントを実行するのは簡単で、curlコマンドの時間を計るのは有益だとわかった。キャッシュによるパフォーマンスの向上は、その後非常に明確になリました。

何を学び、そして次は何でしょうか？

これらの例は、TiDBとMomento Cacheを使ったビルドがいかに簡単かを示しているだけでなく、なぜread-asideパターンのキャッシュが多くのユースケースに適しているのかを有意義に示しています。このリポジトリが大きくなるにつれて、他のプログラミング言語の例が増えていくのを楽しみにしています。興味のある方はぜひ試してみてください！

また、あなたがMomento Cacheのために持っているかもしれない他の統合のアイデアを聞くことに非常に興味があります。また、Momento Cacheの他のアイデアについてもぜひお聞かせください。Twitter、LinkedIn、またはメールでご連絡ください。

ピート・ネイラー

著者

Runs a consulting business called High Bar Solutions. Previously worked as a Solution Architect for Momento and spent 6 years working with DynamoDB at AWS—plus “lots” of years accumulated in old-school environments which are better forgotten these days. Firmly believes that giving software developers the tools to innovate faster will move the world in a positive direction. Always seeking to embed within groups of smart people and act like a sponge. Likes disconnected breaks in the wilderness from time to time. Beware: may talk for hours about distributed systems, correctness and scale in a transactional database context.