今日の優良食堂
実際に入れて動かして書いた、今日の一膳
ギット飯が代わりに導入・実行・コードまで確かめました
今日の優良食堂 · ギット飯が代わりに導入・分析

readysettech/readyset

PostgresとMySQLの前に立つ透過的データベースキャッシュで、アプリ改修なしに高速化できます。

複雑なJOINを含むSQLの読み取りが遅い時、アプリのコードやORMを一切変えずに、Postgres・MySQLの手前にReadySetを差し込むだけで応答が速くなる体験ができます。replicationストリームを利用してキャッシュの整合性を自動で保つ仕組みなので、Redisを別途導入した時のようなキャッシュ無効化ロジックを自前で書く必要がありません。readyset-mysql、readyset-psql、readyset-dataflowなど60以上のワークスペースメンバーとCIパイプラインを持つ実装なので、今日にでも既存のクエリコードそのままで試す価値があります。

01 / 概要
何をするものか一文で言うと
ひとことでPostgresとMySQLの前に立つ透過的データベースキャッシュで、アプリ改修なしに高速化できます。

readysetは、MySQLとPostgresにワイヤ互換なキャッシュ層で、既存データベースの手前に置くだけでクエリを高速化し、読み取りスループットを水平にスケールさせます。SELECT結果をキャッシュとして保持し、元データの変更をレプリケーションストリーム経由で検知して増分更新する点が特徴です。README記載の通り、アプリ側の書き換えやキャッシュ無効化ロジックの手動実装なしに導入できることを謳っています。

02 / 構造
どう動くのか中核のしくみ
読み方動きの流れを図と一緒にほどきました。

リポジトリはRustのワークスペース構成で、mysql-srv・psql-srv・readyset-adapter・readyset-server・replicatorsなど役割ごとにクレートが分かれています。mysql-srvとpsql-srvがMySQL/Postgresのワイヤプロトコルを実装し、アプリからは通常のDB接続に見えるようになっています。readyset-adapterがクエリを受け取ってキャッシュ済みビューを参照し、未キャッシュのクエリは上流DBへ素通しします。replicatorsクレートが上流のレプリケーションストリームを購読し、元データの変更をキャッシュ結果へ増分反映する仕組みです。Cargo.tomlではpostgres・tokio-postgres・mysql_asyncをreadysetteam独自forkに差し替えており、プロトコル拡張やレプリケーション対応のための改造が入っていると推測できます。benchmarksクレートには実際のクエリパターン(join・topk・point_query等)やnews_app・solidusといった模擬アプリのSQL・YAML定義があり、性能検証の作り込みがうかがえます。

03 / 体験
入れるとこんな体験になりますギット飯が実際にたどった順序
所要ギット飯が実際に導入・実行しながらたどった順序です。
  1. STEP 01

    quickstartのcurlスクリプトを実行すると、readysetのセットアップウィザードが起動し、既存のMySQLまたはPostgres接続情報の入力を求められます。

  2. STEP 02

    build/docker-compose.ymlを使ってDocker Composeで起動すると、readyset本体に加えGrafana・Prometheusなど監視スタックのコンテナ群が立ち上がるのを目にします。

  3. STEP 03

    mysqlクライアントやpsqlクライアントでreadysetのポートに接続すると、通常のDB接続と同じ操作感でSHOW READYSET STATUSのような専用コマンドが使えることに気づきます。

  4. STEP 04

    対象クエリに対してCREATE CACHEを実行すると、以降の同じSELECTがキャッシュ経由で返るようになり、Grafanaダッシュボードでヒット率の変化が確認できます。

  5. STEP 05

    benchmarksクレートのworkload_emulatorを実行すると、news_appやsolidusのSQLパターンを使った負荷試験が走り、レイテンシのヒストグラムが出力されます。

  6. STEP 06

    元テーブルにUPDATEを行うと、レプリケーションストリーム経由でキャッシュが自動更新され、明示的なキャッシュクリア操作なしに新しい結果が返ることが確認できます。

04 / 成果物
何が手に入るのか導入後に手元に残るもの

手元には、既存のMySQL/Postgresクライアントからそのまま繋げるキャッシュ層バイナリと、キャッシュ状態やクエリ性能を可視化するGrafanaダッシュボード一式が残ります。加えてbenchmarksクレートにより自分のクエリパターンでの性能測定環境も得られます。

05 / 注意
ここは先に知っておいてください先に知っておくとよいこと
正直なところ誰にでも合うとは言いにくいところです。
01

ライセンスはBSL 1.1で、4年後にApache 2.0へ移行する条件付きです。商用利用の制約を事前に確認する必要があります。

02

postgres・tokio-postgres・mysql_asyncなど主要依存がreadyset独自forkに差し替えられており、標準クレートとの挙動差異が発生する可能性があります。

03

実際のインストールと起動は確認していません。README記載のquickstartスクリプトやDocker Composeの動作を筆者が実行した結果ではない点に留意してください。

04

本レビューはファイルツリーと一部ソースからの推測を含みます。レプリケーション対応DBの種類やバージョン要件など詳細はソース全体を見ないと断定できません。

06 / 結論
ギット飯の結論食べてみる価値のある一膳か
ギット飯の最終判断優良食堂

既存のMySQL/PostgresアプリにORMや接続文字列をほぼ変えずにキャッシュを挟みたいチーム、特に読み取り負荷でDBがボトルネックになっている構成に向いています。ワークスペース構成・依存フォークの作り込み・benchmarksクレートの充実度から、単なるプロトタイプではなく実運用を意識した設計であることが読み取れます。ただし実機検証はしていないため、本番投入前には自分のクエリパターンでbenchmarksを回して確認することをお勧めします。

今日の残りの一膳
SUBSCRIBER LIBRARY
これまでに検証した優良食堂を一堂に

4 つの関門を通った優良食堂がすべてバックナンバーに集まっています。いちばん新しい一膳はどなたでも無料で読め、それより前の優良食堂の検証の根拠・詳しい解説は ギット飯 プレミアムのご購読ですでに開いています。

優良食堂バックナンバー →
リポジトリ詳細🧪 ひと言で味見する