PR

高い場所でもラクラク届く

図3●遅すぎる類似商品検索をチューニング
チューニング前に比べ,検索速度は5~10倍に向上した
図4●PostgreSQLのソート・メモリーを最適化
ソート・メモリーのサイズを徐々に増やしながら,ソートの負荷が異なる2種類のクエリーを実行してレスポンス・タイムを計測した

 ICタグは,売り場における在庫確認以外にも効果を発揮している。例えば入荷検品や棚卸しの手間を大幅に軽減できた。

 ICタグを導入する前はバーコードで検品していた。婦人靴は,倉庫内にある幅1.7メートル,高さ3メートルの棚に収納されているため,「棚にうずたかく積まれた婦人靴のバーコードを一つひとつ読み取るのは時間がかかった。特に高いところにある商品は大変だった」(伊藤氏)。

 一方,ICタグならば複数商品を一度に読み取れる。しかも,数十センチ離れた場所からでも読み取れるので,手間がかからない。「1棚250足を入荷検品する場合,バーコードだと15分かかっていたが,ICタグでは3分30秒に短縮できた」(伊藤氏)という。

 在庫管理システムは,導入コストを抑えるためにオープンソース・ソフトを積極的に採用した。

 Webアプリケーション・サーバーは,Red Hat Enterprise Linux ES 3.0,JBoss 3.2.5,Tomcat 5.0.26。DBサーバーは,Red Hat Enterprise Linux ES 3.0とPostgreSQL 7.4.3で構成している。両サーバーが搭載している「RFIDミドルウェア」は,リーダーのドライバ機能や,重複して読み込んだICタグのIDを取り除く機能などを備える。

検索時間が15~20秒に悪化

 このシステムは顧客も利用するため,検索速度は重要な要件の一つである。しかし,機能追加の過程で検索速度が著しく低下する事態に直面した。当初は1商品の在庫検索なら1,2秒で結果が返ってきていたが,その後に新規追加した類似商品検索の処理時間が15~20秒にもなっていた。

 主な原因は,「類似商品検索機能を追加する際にテーブルを再設計した結果,テーブル数が倍に増えた。これが検索時の結合テーブル数の増加を招き,検索速度を低下させた」と苅田氏は語る。結合テーブル数の増加は,特に多数の商品データを検索する類似商品検索への影響が大きかった。

 「20秒も端末の前で待たされては,顧客も不快だし,販売員も仕事に支障を来す。このままでは使い物にならない」(苅田氏)。こう感じたNTTコムウェアは,類似商品検索処理のチューニングに取りかかった。

 類似商品検索は,売り場にある端末からサンダルやパンプスといった靴の形や色,サイズを指定して,タグ履歴管理テーブルを検索し,該当データを抽出/ソートして端末に表示する,という流れになる。このフローのうち,NTTコムウェアはPostgreSQLが実行する検索とソートの処理に注目した(図3[拡大表示])。

テストを240回繰り返す

 検索速度の向上策として,検索するレコード件数そのものを少なくする手段を講じた。タグ履歴管理テーブルには,「卸売業者から出荷」,「入荷して倉庫在庫」,「販売済み」といったように,商品のステータスが変わるたびにレコードが追加される。つまり同一商品に対して異なるステータスのレコードが混在しているが,類似商品検索に必要なのは各商品の最新ステータスのレコードだけである。

 そこで,タグ履歴管理テーブルから最新のレコードだけを抜き出し,新たなテーブル「最新観測履歴管理テーブル」を作成してそこに格納。類似商品検索では,レコード数がタグ履歴管理テーブルの4分の1であるこのテーブルを検索することで効率を高めた。

 ソート処理のチューニング策は,PostgreSQLがソートのために使うメモリー・サイズを増やし,実行時間の短縮を狙った。「PostgreSQLのソート・メモリーはデフォルトで1Mバイトしかないため,短縮の余地は大きいと考えた」(苅田氏)ためだ。

 具体的には,ソートの負荷が異なるクエリーを2種類用意し,ソート・メモリーを徐々に増やしながら,レスポンス・タイムを計測していった(図4[拡大表示])。ソート・メモリーのサイズを変えるごとに20回ずつ計測し,3日間かけて合計240回のテストを実行した。

 狙い通り,ソート・メモリーを増やすと,レスポンス・タイムが大幅に改善された。ソート・メモリーが1Mバイトの場合と32Mバイトの場合を比べると,後者のレスポンス・タイムは約5分の1になった。一方,ソート・メモリーを32Mバイト以上に増やしても大幅な改善が見られなくなったため,32Mバイトが最適だと判断した。

 これらのチューニングの結果,15~20秒かかっていた検索時間は2~3秒に改善した。

(松浦 龍夫)