MygramDB vs Elasticsearch vs MySQL FULLTEXT

全文検索ソリューションは要件に応じて選ぶ必要があります。それぞれの特徴を比較します。

選び方の前提

MygramDBは「既にMySQL/MariaDBに正本データがあり、検索だけを高速化したい」ケースに特化しています。検索エンジンをデータ基盤の中心に置きたい場合や、分散分析基盤が必要な場合はElasticsearchなどの方が適しています。

早見表

項目	MygramDB	Elasticsearch	MySQL FULLTEXT
レイテンシ	ベンチマークでは1ms未満が中心	50〜500ms程度	100〜3000ms程度
導入	バイナリ1つ	クラスタ構築	標準搭載
データ同期	MySQL / MariaDB binlogで自動	ETLが必要	不要
スケール	単一ノード	分散可能	単一ノード
メモリ	100万件で約2.3GB（verify_text有効時）	100万件で2〜4GB	バッファプール次第
並列性能	QPS 11,766	高い	QPS 2-8
日本語対応	N-gram標準	プラグイン追加	N-gramパーサー
分析機能	基本のみ	充実	なし
学習コスト	低い	高い	低い

それぞれの特徴

MygramDB

向いているケース: MySQLを使っていて、手軽に検索を高速化したい

良い点:

• ベンチマークではサブミリ秒級のレスポンス
• MySQL / MariaDBのbinlogから自動同期（MySQL 8.4/9.xおよびMariaDB 10.6+/11.x対応）
• バイナリ1つ置くだけで動く
• クラスタ管理なし
• 日本語のN-gram検索が得意
• BM25関連度スコア・ハイライト・ファジー検索・ファセット集計・シノニム展開に対応（v1.6.0以降）

注意点:

• 分散検索はできない
• データがメモリに収まる必要あり

ETLが不要な意味

MygramDBでは、アプリケーションが検索用データを別途pushする必要はありません。ただし、MySQL側のGTID、ROW形式binlog、レプリケーションユーザー、初回 SYNC などの設定は必要です。

Elasticsearch

向いているケース: 大規模データで高度な検索・分析が必要

良い点:

• 水平スケールで容量追加可能
• ファジー検索・ハイライト・集計など機能豊富
• エコシステムが充実
• ペタバイト級も対応

注意点:

• クラスタの構築・運用が大変
• データ連携にETLパイプラインが必要
• 運用コストが高い
• 学習に時間がかかる
• JVMのチューニングが必要

MySQL FULLTEXT

向いているケース: 小規模データ（10万件以下）でシンプルに済ませたい

良い点:

• MySQLに標準搭載
• 追加のシステム不要
• データ同期の手間なし

注意点:

• 大規模データでは遅くなりやすい
• 並列アクセスに弱い（2-8 QPS）
• キャッシュ状態で性能が大きく変動
• スケールしない

性能比較

詳しい数値はベンチマークをご覧ください。要点：110万件のWikipedia記事を使った測定では、MygramDBはサブミリ秒級のレイテンシで2,634-11,766 QPSを達成。MySQL FULLTEXTは300-2,566msのレイテンシで2-8 QPSでした。

移行方法

MySQL FULLTEXTからMygramDBへ

1. MySQLはそのまま使い続ける
2. MygramDBを横に立てる
3. 検索だけMygramDBに向ける
4. 書き込みはMySQLのまま

HTTPルートのバージョン差

v1.7.0以降のHTTP APIは /tables/{identity}/search を使います。古い /{table}/search 形式は削除されています。移行時はv1.7移行ガイドを確認してください。

# 1. MygramDBを起動（実運用では設定ファイルまたは環境変数を用途に合わせて指定）
docker run -d -p 11016:11016 -p 8080:8080 \
  -e MYSQL_HOST=your-mysql \
  ghcr.io/libraz/mygram-db:latest

# 2. 初回同期後、MygramDBで検索
curl -X POST http://localhost:8080/tables/articles/search \
  -H "Content-Type: application/json" \
  -d '{"q": "検索ワード"}'

ElasticsearchからMygramDBへ

こんな場合は乗り換えを検討：

• 分散検索が実は不要だった
• データが1台のメモリに収まる
• 運用が大変すぎる
• MySQLとの連携をシンプルにしたい

詳しくはGitHubをご覧ください。