TTLを活用したTiDBの効率的なインスタンス運用

TTLを利用したTiDBの効率的なインスタンス活用 MySQLに高い互換性を持つデータベースであるTiDBには、古いデータを自動的に削除するTTL（Time to Live）機能があります。本記事では、この機能を活用してコスト削減と障害耐性の向上を実現した事例を紹介します。 メルカリでは、商品に対してコメントを付与することができ、値引きの依頼やさまざまなやり取りを行うことができます。これらのコメントが、例えば公序良俗に反すると想定される場合、ユーザーがそれを「通報」する機能があります。また、メルカリ内部でも古くからこれらを自動的に検知する仕組みが実装され、運用に利用されています。 これらのコメントデータは、歴史的経緯から古くはMySQLに、現在はTiDBに格納されています。 自動検知機能自体は、事前定義された特定のキーワードがコメントに含まれるかどうかを、いわゆる「全文検索」によって実現しています。 : 全文検索クエリのイメージ SELECT table1.* FROM table1 FORCE INDEX(idx_xxx_xxx) \ WHERE (column1 like ''%a%'' OR column1 like ''%b%'' … ) \ AND (column1 not like ''%c%'' OR column1 not like ''%d%'' … ) AND ... \ ORDER BY created DESC LIMIT 10; また、この機能を動作させるには、大量のコメントに対して高頻度で多数の全文検索を実行する必要があり、このような使い方はもちろんMySQLにはあまり適していません。しかし、TiDBに移行した際に、この負荷の影響がさらに目立つようになりました。 TiDB User Day 2025でResource Controlの導入について紹介（発表資料）しており、詳細は割愛しますが、対象のクエリにヒント句でResource Groupを割り当て、Burstableでない制約を加えることにより、TiKVでの優先度制御と、TiDBでの多少の負荷平滑化を実現していました。 しかし、この負荷は定期的に実行され、かつ実行間隔が短いものでした。実行を完了しなければならないタイムウィンドウの制約が比較的厳しいことから、平滑化による制御の効果は限定的でした。 また、Resource Controlによる制御は、TiDBへのOLTPワークロードに関しては比較的うまくいくものの、TiKVに対しては主に優先度でしか制御できず、リソースの隔離が不十分であるため、アプローチを変えて対応することにしました。 問題のあるコメントの検知に関しては、コメントデータが追記式で後から編集できない（更新されない）という性質上、ある程度最近のデータにのみクエリを発行できれば良いため、最近のデータだけをうまく処理するという方針を軸に、主に以下の観点から2つのアプローチを比較しました。 既存のTiDBからデータが簡易に生成できる。 a. TiDBからTiCDCへ流通させたデータにKSQLを発行する TiDBにはTiCDCという、TiDBの実データを保存するTiKVの変更を取得し、ダウンストリームのデータベースに変更を伝播させるための、いわゆるCDC（Change Data Capture）の便利な機能があります。 MySQLであれば、例えばdebeziumといったソフトウェアがこれに該当します。TiCDCは変更イベントを以下のような様々なプロトコルで出力可能な柔軟さを持っています。 このTiCDCを使って、Debezium形式で下流のKafkaにデータを流せば、KSQLというストリームデータに対してSQLを発行できる機能を活用し、インメモリでクエリを発行できる可能性があります。 KSQLの発行先であるKSQL DBのレコードはイミュータブルになります。また、KSQLは全文検索に特化した機能はありませんが、全文検索のクエリも発行できます。 KSQL自体はすでに社内で活用・運用実績がある状況でした。 b. TTLにより一部のデータを保持する専用のTiDB Clusterを作成する ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/0faa6a8a-cleanshot-2025-12-25-at-16.45.40.png) まず、必要なテーブルのみを持つTiDB Clusterを作成します。TiCDCのレプリケーションタスクはChangefeedと呼ばれますが、テーブルの絞り込みには、このChangefeedのTable Filterという機能が活用できます。本ケースでは、コメントを保存するテーブルのみを保持するClusterを用意することになります。 次に、このテーブルのデータを最新のデータのみ保持するようにします。TiDBには、Spanner同様、古いデータを自動的に削除するTTL機能があります（MySQLにはありません）。この機能を活用すると、最近のデータ以外は不要という要件を簡易に達成できます。TTL機能をCluster単体で利用した場合は、特に追加の考慮は必要ありませんが、TiCDCを経由したデータに対して利用した場合は、追加の考慮が必要です。すなわち、上流には存在する一方、下流には（TTLで削除されたため）存在しないデータが発生し、全てのイベントを伝播した場合、例えば、下流に存在しないデータに対する削除が伝播してエラーになるといった可能性に対処する必要があります。この問題に対しては、ChangefeedにEvent Filterという機能があり、特定のDELETEやUPDATEを無視するといった設定が可能です。 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/579860f1-cleanshot-2025-12-26-at-10.22.53.png) : 上記のデータセットでEvent Filterがないとエラーになるクエリの例 DELETE FROM comments WHERE id=1 /* すでに下流にはデータがない */; UPDATE comments SET comment="good morning" where id=2 /* すでに下流にはデータがない */; さらに、TTLパラメータにより、保持するデータがメモリに収まるようコントロールできれば、実質的に多くのケースでインメモリに近い形で処理可能です。 なお、メルカリではTiDBのマネージドサービスであるTiDB Cloudを利用しており、ここで紹介したChangefeedのTable FilterおよびEvent FilterはTiDB Cloudでも利用可能な機能です。 主にクライアントへの変更要求が少ないことから、TTLを用いる手法を選択することにしました。万が一問題が発生した場合の切り戻しや暫定対処に関しても、クエリの発行先を元のClusterに戻し、元のClusterのリソースを増やしてあげれば良いだけという便利さもあります。 ここで改めて、隔離した一部のデータセットを作成し、そこにクエリを発行するというアプローチを取った利点を確認します。 利点1：構築が容易/短期で可能 特筆すべきこととして、TTLが十分短ければ、初期構築が非常に迅速かつ容易に行えることが言えます。 既存のデータベースから一部のデータを保持する別のデータベースを作成する際に、最も手間となるのは、既存のデータベースからのエクスポート/リストアから始まる初期データの作成ではないかと思います。 しかし、Event Filterで所定の構成をすれば、TTLが短い場合、下流に空のデータベースを用意し、その時点からデータの複製を始めれば、保持すべきTTL期間を待つだけでデータの用意が完了します。 利点2：障害単位が独立し個別調整の余地が出る リソースを完全に独立させた専用のClusterを用意することで、障害の単位も分離でき、さらに、決まった使われ方をする独立したClusterに対して、積極的にリソースを活用するようチューニングが可能です。 もちろん、設定が同一ではない非対称なものが生まれるのは運用における認知負荷が上がるという問題はあり、構成変更により得られる効果とのバランスをチームで納得のいくものにする必要があります。 変更前後のTiKVの負荷について示します。 A) 変更前のTiKVの負荷 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/5bc093c7-cleanshot-2025-10-30-at-12.11.18-1.png) B) 変更後のTiKVの負荷（ピーキーな負荷が隔離され利用量が平滑化された） ![](https://storage.googleapis.com/prd-engineering-asset/2026/01/b86b34aa-cleanshot-2026-01-05-at-09.19.24@2x.png) C) 新規TiKV with TTLの負荷 ![](https://storage.googleapis.com/prd-engineering-asset/2026/01/cd1a7078-cleanshot-2026-01-05-at-09.28.59.png) このように負荷は別のClusterに分離され、上位のスペックで運用していた既存のClusterの負荷が減少し、かつ安定したことから、既存のClusterのノード数を減らすことができました。新規に別のClusterを作成しているものの、トータルコストとしても削減でき、障害に関するリスクも分離できました。 追記：BのグラフのCPU利用率はAより高くなっていますが、BのグラフはTiKVノードを減らした後に作成したためです。負荷が平滑化され、上下の激しい負荷が別Clusterに分離されたという文脈でご参照ください。 本記事では、Changefeedのフィルター機能（Table Filter, Event Filter）、TiDBのTTLを活用し、一部のデータに対して高頻度で発行される全文検索の負荷を、独立したClusterに分離することでコスト削減をした事例を紹介しました。 このアプローチでは、アプリケーションの変更および構築ともに少ない変更ですみ、結果として早期に移行を完了することができました。 メルカリでは、TiDBを利用していますが、初期導入のフェーズから、この記事のような継続的改善のフェーズに入っています。現在、様々な取り組みをしており、近々別の記事で紹介していく予定です。 本論とは少しそれる、細かな検討事項について補足します。 TiDBの全文検索については、一部のリージョン、一部のサービスプロバイダ、一部のサービス提供形態で、試験的に利用できるものが提供されています。現状では選択肢には入りませんでした。また、商品に対するコメントについては、ある商品のコメントを表示する、コメントを書き込むというのが主な用途であり、そういった点からも元データとしてはこのデータのみを全文検索エンジンに格納するのは相応しくないと考えています。 https://docs.pingcap.com/tidbcloud/vector-search-full-text-search-sql TiKV MVCC In-Memory Engineについては、B案の一部として試しました。今回のケースがIn-Memory Engineに向いたケースではなく、「構成変更により得られる効果とのバランス」が悪かったため、今回は採用には至りませんでした。 ![](/img/In-Blue-128@2x.png) ![](https://b.st-hatena.com/images/v4/public/entry-button/button-only@2x.png) Related article 2025/12/22 ![](https://storage.googleapis.com/prd-engineering-asset/2025/11/cf9f9e27-adventcalendar2025_merpaymercoin.png) インターン生が挑んだ認証方式のマイグレーション──メルペイ加盟店管理画面へのOAuth 2.0導入 Author: t-kawakami 2025/12/21 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/0d77977d-adventcalendar2025_mercari.png) Non-AI tasks in the AI task force：AIツール開発の現場でこそ必要な「AI以外の」技術選定 Author: akkie30 2025/12/20 ![](https://storage.googleapis.com/prd-engineering-asset/2025/11/cf9f9e27-adventcalendar2025_merpaymercoin.png) LLMを用いたおしゃべり機能「しゃべるおさいふ」のバックエンド設計 Author: kobaryo ![TiCDCダウンストリームをKSQL DBとして活用](https://storage.googleapis.com/prd-engineering-asset/2025/12/14ee415a-cleanshot-2025-12-25-at-16.47.27.png)

TTLを活用したTiDBの効率的なインスタンス運用

背景や根拠まで確認しますか？

調べる

選ぶ

サイト