RONDHUIT REPORT Vol.1 - SOLR QUERY PERFORMANCE

Solr の検索性能
2007 年 9 月 29 日株式会社 ロンウイット

はじめに関口宏司• 商用利用可能な無料のオープンソースの検索エンジンサ

本書は「Apache Solr（以下 Solr）」の検索性能の検証ーバ。
• HTTP/XML による文書の索引付けと検索。検索結果結果および考察を述べたものである。

は XML で返すため、フロントエンドアプリケーションは必ずしも Java で開発する必要がない。

Solr について• Lucene フィールドに「データ型」を導入。

Solr は 高 性 能 の 全 文 検 索 ラ イ ブ ラ リ Apache• 検索を高速化するための各種キャッシュ機構の装備。

Lucene(*1)を使って構築された、「検索エンジンサーバ」• キャッシュを最大限に利用した高速絞り込み検索。

である。もとは CNET のために構築された検索エンジンフレー• スケーラビリティと運用性を考慮したインデックスレプリケー

ムワークであるが、CNET の許諾により Apache Software
Foundation にコードが寄贈され、現在は Lucene のサブプロジェクトとしてオープンソースで開発・管理がなされていション。
• 「類義語検索」や「ハイライター」などの各種ツール類の装備。
• 管理画面。

る。

• 各種プラグイン開発インタフェース提供による高い拡張性(*1) Apache Luceneと柔軟性。

http://lucene.apache.org/java/docs/index.ht
ml検証に用いたデータ

Apache Solr

性能検証には、「Yahoo!オークション」から約 201 万件のhttp://lucene.apache.org/solr/商品データをクロールしてインデックスに登録したものを使用した。商品データの収集は、「Yahoo!デベロッパーネットワー

Solr は全文検索機能を API で提供する Lucene よりもク」が提供している Web サービスを使って行った。

使い方が簡単なため、公開されると同時に利用事例が急Yahoo!デベロッパーネットワーク - Yahoo!オークション

速に拡大している。

http://developer.yahoo.co.jp/auctions/Powered by Solr
http://wiki.apache.org/solr/PublicServers

インデックスのファイルサイズは合計で約 14GB となった。

弊社も顧客向けに Solr の導入コンサルティングを多数行っ

インデックスのスキーマは、下表のとおりである。ており、事例は国内だけでなく海外にも広がりつつある（諸事情により、弊社の顧客事例は公開できない）。

フィールド名auction_id

Solr の特徴を以下に列挙する。
Copyright © RONDHUIT Co.,Ltd.
1型

概要

string

オークション ID

RONDHUIT REPORT Vol.1 - SOLR QUERY PERFORMANCE

category_id

stringカテゴリ ID

category_path

text_ja

カテゴリパス

title

text_ja

商品タイトルurlstring

商品 URLseller_id

string

出品者 ID

image1_url

string

画像 1 の URL

ハードディ

120GB SATA HDD（5400 回

image2_url

string画像 2 の URLスク転）

image3_url

string

画像 3 の URL

ネットワー

100MB Ethernet

init_price

sint

開始価格

クpricesint

現在価格

start_time

date

オークション開始日時

Kernelend_timedate

オークション終了日時

2.6.20-1.2962.fc6

description

text_ja

商品説明

Java

build 1.5.0_12-b04

text

text_ja(*2)

Java ヒープ設定-Xms256m -Xmx256m

timestampdate

インデックス登録日時

Servlet コンテナ

Tomcat 5.5.23(*2) auction_id, category_id, category_path,Solr

rev575809

title, seller_id および description のフィールドをコピーし負荷試験ツール

Apache JMeter 2.2

ハードウ

機種名

DELL Inspiron 1501

CPUAMD Athlon(TM) 64 X2 デュアルコア・プロセッサ TK-53

メモリ

1GB(512MBx2) デ ュ ア ル チ ャ
ネル DDR2-SDRAM メモリ

OSFedora Core 6
Rel.て合成したもの。
Solr を実行するサーバマシンには DELL 製のノート PC を使
上記フィールドのうち auction_id をユニークキーとし、text用した（本体価格：57,124 円）。ハードディスクは低速なたフィールドをデフォルトの検索フィールドに指定した。

め、次のようにページキャッシュとハードディスクの速度に大きな開きがある。

一部のフィールドの型について若干補足する。text_ja はイ
ンデックスに索引付けする日本語のテキストを示し、形態素# hdparm -ftT /dev/sda

解析により単語分割をしている。形態素解析器には Sen を/dev/sda:使用した。

Timing cached reads:

3208 MB in

Sen Project

seconds = 1604.93 MB/sec

http://ultimania.org/sen/Timing buffered disk reads:
seconds =122 MB in

2.00
3.06

39.93 MB/sec

sint 型は Sortable Integer であり、当該フィールドで検索結果一覧のソートを行ったり、範囲検索を行ったりする場

そこで今回の検証では、OS のページキャッシュが十分に効い合に使用する Int 型である。

た状態で性能を測定することとした。
サーバに負荷をかけるクライアントマシンであるが、事前調査

検証環境の段階でほとんどの場合においてネットワークがボトルネックと検証環境を下表に示す。

なることが判明したため、ノート PC 1 台で行った。クライアン
トからは JMeter で 200 同時ユーザ（スレッド）を起動して負項目説明

荷をかけた。Ramp Up は 400 秒に設定した。
Copyright © RONDHUIT Co.,Ltd.
2

RONDHUIT REPORT Vol.1 - SOLR QUERY PERFORMANCE

常、検索式と文書の適合度合いを数値化した「スコア」によまた、サーバ/クライアントとも、CPU を使い切ることはなかっり決められる。しかし、アプリケーションによっては「スコア」よりた。

も文書のフィールド値の大小によるソート機能が求められることがあり、Solr もこれをサポートしている。

Solr 検索性能サマリー

ソートに使用するフィールドは 1 つ以上指定可能である。こユーザから見た Solr の検索性能（応答時間とスループットれには「スコア」を含めることができる。

（QPS；1 秒あたりのクエリ数））のサマリーを以下に記す。
ソートフィールドには以下を使用した。
検索

同時

平均応答

単語数

ユーザ数

時間（ms）

1QPS

項目名

ソートフィールド数

7123.9sort-0

1

10

46

187.3

50

143

203.3

sort-11

category_id asc

100262210.2

sort-22

category_id asc,

200

523

215.8

20097579.4

12

ソート対象フィールドscore desc
（デフォルト）(*3)

end_time asc
sort-33category_id asc,end_time asc,
score desc

「検索単語数」が 1 のものについては、絞込みが十分に行われ な い 場 面 を 想 定 し 、 検 索 結 果 文 書 数 が 1,001 〜(*3) asc は昇順、desc は降順を示す。

10,000 件になる検索キーワードをインデックスから 1,024件抽出して負荷をかけた。また、「検索単語数」が 2 のもの

検証結果では、ソートフィールドの数の上昇による応答時間については、AND 検索によってある程度絞込みが行われたや QPS の性能劣化は見られなかった。ただし、サーバの場面を想定し、検索結果文書数が 101〜1,000 件にな

CPU 平均使用率は 27%（sort-0）から 35%（sort-3）

る検索キーワード 2 単語 1 組をインデックスから 1,024 組に上昇したため、CPU に余裕のない場合はソートフィールド抽出して負荷をかけた。の指定による性能劣化は起こりうると考えられる。

単語数 1 では同時 200 ユーザで応答時間 0.5 秒、200QPS を達成した。単語数 2 では同時 200 ユーザで応1 レスポンスあたりのデータ量
Solr では検索結果一覧を XML で返すが、XML のサイズ答時間 1 秒、80QPS となった。

が大きくなれば性能にも影響する。XML のサイズが変わる
以上の結果を踏まえ、次節以降は、「単語数 1・同時 200要因にはいくつか考えられるが、ここでは Solr の代表的なユーザ」の基本モデルにさまざまな検索条件を付加して検証

HTTP パラメータである「rows」、「fl」、「hl」を変更することを行った結果を述べる（ただし、一部の検証では「同時 50で XML のサイズを変更することとした。

ユーザ」で行っており、その旨明記してある）。
rows パラメータは、1 件の XML に含まれる検索結果の文書件数を指定する。デフォルトは 10 である。このパラメータをソートフィールドの数5〜40 で指定した結果を以下に示す。

検索結果一覧の文書のランキング（文書の表示順）は、通Copyright © RONDHUIT Co.,Ltd.
3

RONDHUIT REPORT Vol.1 - SOLR QUERY PERFORMANCE

平均応答時間rows

データ量

（ms）

fl-4

*, score (*5)

QPS

（KB/s）(*4) 基本モデルでは fl-2 の fl を使用している。

591

317.9

722.68(*5) score は検索結果 XML にスコア値を含めることを指10143

203.3

834.98

定する。

20240

118.5

922.82

40453

64.3

977.18

結果は次のとおりで、fl に指定するフィールドが増えると XMLのサイズが大きくなるため、rows パラメータを変更したときと同じ傾向となる。

500
450
400

平均応答時間Ave(ms) | QPS

350

項目名300
Ave
QPS

250
200
150
100
50
05-rows

10-rows

20-rows

（ms）

データ量
QPS

（KB/s）

fl-1

258

393.8

697.25

fl-2

523

215.8

886.26

fl-3

720

142.4

953.00

fl-4

1595

63.1

1018.92

40-rows

fl=*,score を指定している fl-4 では平均応答時間がrows が大きくなるにつれ、平均応答時間が延び、QPS が1.6 秒にもなったが、これはオークション商品の詳細説明が下がった。このことから、アプリケーションの要件によって適切記述された description フィールドが大きいためである（最な rows を設定することが重要であることがわかる（たとえば、大 8KB）。通常、検索結果一覧には商品の細かい説明は携帯電話向けのアプリケーションでは rows を小さくするな不要であり、この結果からもアプリケーションの要件によって適ど）。

切な fl パラメータを指定することが重要であることがわかる。

なお、このテストでは rows=10 で早々にネットワークがボト

hl パラメータには、ハイライト（検索語の強調表示と要約文ルネックとなってしまうため、同時 50 ユーザで行った。の抽出）の使用有無を指定する。hl=true でハイライト機
能を ON にし、hl.fl でハイライトするフィールド名を 1 つ以上

fl パラメータは、XML に含める文書のフィールド名を指定す指定する。今回のスキーマではハイライトに適したフィールドる。デフォルトは fl=*であり、「文書を構成するすべてのフィーが title と description 以外にないので、hl.fl にはこの 2ルド」を XML で返す意味となる。

つのフィールドを指定することとし、hl.snippets で要約文の断片数を 1,2,3 と変えて比較した。

fl パラメータは、以下のバリエーションでテストを行った。
結果は次のとおりで、断片数の数による性能の変化は見らfl

項目名れない。

fl-1

auction_id, title

fl-2

auction_id,(*4)

end_time, price, title, url

fl-3

auction_id,

bids,

category_id,

11495

37.7

212.90

end_time,

image1_url,

init_price,

21567

37.9

219.43

31559

37.6

220.87bids,

category_id,

平均応答時間断片数

price, seller_id, start_time, title, url

Copyright © RONDHUIT Co.,Ltd.
4（ms）

データ量
QPS（KB/s）RONDHUIT REPORT Vol.1 - SOLR QUERY PERFORMANCE

ヒット率 0〜99%の間で QPS 性能は改善している。
平均応答時間が 1.5 秒となったが、中央値は 100 ミリ秒であったことを注記しておく。また、CPU の使用率は hl=true「文書キャッシュ」についてはヒット率の違いで検索性能の変は hl=false の 2 倍強となった。さらに GC 時間の占める割化は見られなかった。これは OS のページキャッシュが効いて合を比べると、hl=true は hl=false の 8 倍にも達した。ハいる状況下では「文書キャッシュ」の威力が発揮されないたイライトでは Full GC は発生していないことから、短寿命のオめである。Solr に装備されているフィールドの遅延ロード機ブジェクトが多数生成されていることが考えられる。

能もこの場合性能改善には役立たない。ただし、高速ハードディスク・少メモリのマシンでは「文書キャッシュ」を使ってSolr の検索性能を大きく改善できる可能性がある。

Solr キャッシュ効果
Solr には検索結果リストをヒープに保存する「検索結果キャまとめッシュ」、ロードした文書データをヒープに保存する「文書キャッシュ」、フィルタをヒープに保存する「フィルタキャッシュ」がある。

単純な検索ながら、文書数 200 万件・ヒット件数 1,000件超・同時 200 ユーザ接続という条件で 200QPS/0.5「検索結果キャッシュ」については、キャッシュの大きさを変え秒のレスポンスを 6 万円のノート PC で達成できた。高速なることでヒット率 52%と 98%、およびキャッシュを使用しないディスクのサーバマシンの利用や、複数サーバを並べてスケー場合（0%）の性能を測定した。結果は次のとおりとなった。

ルアップを図ることでさらなる QPS 向上が期待できる。

CPU 使用

平均応答時間ヒット率

QPS（ms）

性能検証の残項目率（%）

0%

486

142.988.96

今回は時間的・リソース的制約から、以下に列挙する項目

52%

484

206.5

78.11については検証しなかった。

98%

486

212.6

22.05

• N-gram による検索性能。
• リクエストハンドラ種別による検索性能の違い。

ヒット率が 0%から 52%に上がると、QPS がやや改善した• JDK バージョンによる違い。

が、52%から 98%ではほとんど改善しない。ただし、ヒット• 1,000 万件程度の文書量に対する検索性能（クロール率が上がると CPU 使用率の低減に大きく貢献することがわ

時間とディスク容量の制約により今回は見送った）。
• インデックスへの文書の登録性能。

かる。
「フィルタキャッシュ」についても、キャッシュの大きさを変えるこ（株）ロンウイットについてとでヒット率 54%と 99%、およびキャッシュを使用しない場

ロンウイットはオープンソースの全文検索エンジン Lucene合（0%）の性能を測定した。結果は次のとおりとなった。

/Solr を企業システムに導入する支援サービス事業を展開している。

CPU 使用

平均応答時間ヒット率

QPS（ms）率（%）

お問い合わせ先〒100-0005

0%

558

137.4

81.25

東京都千代田区丸の内 1-1-3 AIG ビル B1F

54%

637

156.0

72.88

電話：03-5288-5927

99%

564

179.3

48.91

メール：sales@rondhuit.com

FAX：03-5288-5353

ホームページ：http://www.rondhuit.com/
Copyright © RONDHUIT Co.,Ltd.
5