✅ 心得(やるべきこと)
1. スキーマ設計
-
テキストフィールドは用途別に分ける
タイトル、本文、タグ、メタ情報などは別フィールドにして検索・ブーストを調整可能にする。 -
トークナイザー/アナライザーの適切な選択
-
英語:
StandardTokenizerFactory
+LowerCaseFilterFactory
+StopFilterFactory
-
日本語:
KuromojiTokenizerFactory
で形態素解析を利用
-
-
同義語辞書を活用
SynonymFilterFactory
で「ノートPC = ラップトップ」などを正規化。
2. クエリ設計
-
複数クエリパーサーを使い分ける
-
キーワード一致:
edismax
-
フレーズ検索:
phrase
-
ファセットや絞り込み:
fq
-
-
検索ブースティング
-
タイトル > 本文 > タグのように重み付けを設定
-
新しい記事や人気記事を
boost
パラメータで優遇する
-
3. ユーザー体験向上
-
サジェスト/オートコンプリート
Suggester
やTermsComponent
を利用して入力補助。 -
スペルチェック/曖昧検索
SpellCheckComponent
やFuzzyQuery (~演算子)
でユーザー誤入力を吸収。 -
ハイライト機能
検索ヒット箇所を強調表示して UX 改善。
4. 運用・パフォーマンス
-
キャッシュ活用
Filter Cache / Query Result Cache を調整し、再利用性の高いクエリを高速化。 -
インデックス最適化
大量更新の後はoptimize
よりもsoftCommit
やautoCommit
を推奨。 -
スケール設計
大規模用途では SolrCloud を採用してシャーディングとレプリケーションを組み合わせる。
❌ べからず(避けるべきこと)
1. スキーマ関連
-
❌ 全フィールドを
text_general
にまとめる
→ ブースト調整不能・パフォーマンス劣化の原因。 -
❌ ストップワードや形態素解析を無視
→ 「の」「は」などが検索に残ると精度低下。
2. クエリ関連
-
❌
q=*:*
を乱用
→ 全件検索は重い。必ずfq
と組み合わせて制限する。 -
❌ ユーザー入力をそのまま Solr に投げる
→ 不要なワイルドカードや構文エラーで負荷・脆弱性増大。 -
❌ クエリパーサーを1種類に固定
→ 複雑なニーズ(曖昧検索、ファセット、範囲検索)に対応できない。
3. ユーザー体験
-
❌ サジェストやスペル補正なしで自然文検索を実装
→ 「今日の天気」「きょの天気」などで結果ゼロになる。 -
❌ ハイライトなし
→ ユーザーが検索結果の「どこにヒットしたか」分からない。
4. 運用
-
❌ インデックスを無計画に再構築
→ サービス停止・性能劣化。更新戦略(近リアルタイム検索 NRT)を設計すること。 -
❌ SolrCloud 導入時に ZooKeeper の冗長化をしない
→ シングルポイント障害になる。 -
❌ キャッシュ設定をデフォルト放置
→ クエリごとの特性に応じた調整が必須。
0 件のコメント:
コメントを投稿