書籍検索サーバ　＝Books.or.jp＝　(上)

電子書籍ケーススタディ　16

【2002年5月時点の古い情報です】 

　WebとCDを同時

　4月16日、東京国際ブックフェアの前々日、社団法人日本書籍出版協会(http://www.jbpa.or.jp、以下書協)の新宿区袋町にある立派な会館の4階会議室で、「本のサーチエンジンBooks」のリニューアル発表会が開催された。NHKのテレビカメラも入り、記者団30名、出版関係者100名以上が参加し、書協のデータベース委員会の佐藤委員長(新潮社社長)、凸版印刷 情報・出版副事業本部長の秋山取締役、マイクロソフト社の安藤部長そして私が新Booksの概要を説明した。

Books開発の経緯

　旧Booksは、5年前の平成9年9月9日、午前9時9分に一般公開した。

　平成9年の初め、書協の前田副理事長(三修社社長)の発案で、「日本書籍総目録」のWeb版を制作することになった。凸版印刷さんが管理している印刷用のデータを入手し、SQLサーバに入れて、アクティブ・サーバ・ページという仕組みで、ソフトウェアを開発した。試作はたったの三日で行った。

　旧Booksの開発には半年ほどかかった。取りあえず書籍の検索が行えるだけのシステムは簡単に開発できるが、月次でのデータ更新や毎月10万回の想定検索数に耐えるシステム作りで苦労した。

盛大な発表会が行われ、新聞やテレビでも報道されたため、アクセス数はグングン上昇し、ピーク時には60万検索に達した。Booksにそれほどのアクセスが集中したのは、「書協が運営しているので中立的である」、「今、販売されている書籍のみが入っている」、「シンプルな操作で、検索が容易」などの理由によるものだが、想定ユーザ数の6倍ものアクセスで、サーバシステムはパンク状態になり、応答に数分もかかるケースも発生した。

　また、新刊の登録は月次で行うため、当時大ヒットしていた渡辺淳一の「失楽園」が見つからず、ミルトンの「失楽園」しか検索されない時期があり、多くのユーザからお叱りをうけた。

　ホームページのアクセス数は、以下のように、いくつかの数え方がある。

トップページ・ビュー　トップページが表示された回数

ページ・ビュー　　　　各ページが表示された合計数

ファイル・ビュー　　　ファイルがサーバから送信された回数

ユニーク・ユーザ数　　そのサイトを訪れた人の数

検索数　　　　　　　　検索が行われた回数

　Booksは検索サイトなので検索数をカウントしているが、トップページ・ビューやページ・ビューが一般的である。Booksはトップページで検索を行うので、検索数とトップページ・ビューはほぼ同じ値となる。トップページを眺めるだけで、検索を行わない人は検索数にカウントされないが、それは稀である。

　Booksは、検索(トップ)画面⇒検索結果一覧画面⇒詳細画面と遷移するので、一回の検索で3ページが表示される。60万検索は180万ページ・ビューとなる。

　ファイル・ビューは、送信されたファイルの数で、これがもっとも多いカウント数である。講談社のWeb現代は週刊誌の電車広告風の画面なので、トップページを表示するだけで、50ファイル・ビューくらいになる。

　ユニーク・ユーザ数は、アクセス・カウンタなどで使用する方法で、IPアドレスをチェックして、同じ人が何回そのページを見ても一回しかカウントしない、もっとも少ないカウント方法である。

　旧Booksは平成9年9月の公開以降、数回の改良を行った。最初はBooksLinkである。これは、「Booksで探していた本を見つけたが、もう少し詳しい内容を知りたい」、「どこで買えるのか」というご要望をたくさんいただいて発案したものである。書籍にはISBNというユニークな番号が付いているので、これをキーにして、出版社のサイトにBooksからパイパー・リンクを行う。該当する書籍のページをダイレクトに表示して欲しいとの要求仕様を提示し、200社以上の出版社サイトで対応していただいた。

　Booksの詳細画面で、書名にアンダーラインが引かれている書籍をクリックすると、BooksLinkで、出版社のサイトにリンクされ、購入ボタンや目次、概要などが表示される。

　次はアクセスログ管理で、毎月60万件の検索語や出版社名、著者名など、ユーザが入力した情報を分類、整理してグラフ表示する仕組みを追加した。

　2年後には、サーバ・ハードウェアの増強を行った。当時最強のPentium Proの4CPU構成とし、640メガバイトのメモリを搭載して、検索速度を数倍向上させた。

新Booksの登場

　2001年、新Booksの開発プランがまとまり、一年がかりで開発を行った。コンピュータの速度向上は、ハードウェアをいくら高価な最高速マシンにしても数倍しか向上しないが、ソフトウェアのロジックを改良すれば、数百倍、数千倍も向上することがある。今回の最大のテーマは、検索速度の向上で、平均2分半(150秒)かかっていたものを、0.5秒つまり300倍の高速化を目指した。

　SQL系のデータベースで部分一致検索を行うこと、応答が極端に遅くなる、という問題点は判っていたので、SQL DBは使わず、三省堂.NETなどで使用している、イースト・オリジナルのXMLドキュメント全文検索エンジンBTONICを使用した。辞書のようなドキュメント系のXMLデータではなく、書名、出版社名、著者名などの項目に分かれたデータベース系のデータにBTONICを適用する最初の事例であったが、多少の機能追加で、高速検索を実現することができた。

　SQLでの部分一致は、実際にデータベースのインデックス部分をサーチするので、それをメモリ上に置き高速化を行った。しかし、BTONICは全文検索用のインデックスがあらかじめ生成されているので、数回のデータアクセスで、検索が完了する。CPU負荷だけを考えれば、数千倍の高速化が行える。

　新Booksは、4、50万円程度の薄型サーバ二台で運用しているが、二台構成はハードウェア障害対策が目的なので、検索能力だけであれば一台で充分処理できる。理論値だが、普及型のサーバで、一時間に1万検索、月間600万検索くらいは可能である。

　Amazon.comは一時間で2200万ページ・ビューとのことで、誰もがAmazonを目指してインターネット・ビジネスに参入するが、最初からサーバに数億円投資できるわけではないので、BTONICを使った安上がりの高速検索は、引合いが増えている。

　BTONICは全文検索やXMLタグ(論理構造)のインデックスを事前に生成して高速検索を実現しているので、データがドンドン更新されるシステムでの検索には不向きである。

　Booksでは、毎月以下のようなデータ更新作業を行っている。

各出版社　(出版VANなど)

　　　　　　　　↓　随時更新

書協：データベース総目録　(収集、編集用サーバ)

　　　　　　　　↓　月次更新

SQL系データベース　(旧Books）

　　　　　　　　↓　自動処理

SQL⇒XML自動変換

　　　　　　　　↓　自動処理

LaBamba　(BTONIC用インデックス生成ツール)

　　　　　　　　↓　自動処理

新Books　(BTONICエンジン＋.NETフレームワーク、配信用サーバ)

　書協の収集用サーバには、出版VANなどから書誌データが随時登録されるが、それを一ヶ月分まとめてSQL系の旧Booksに登録している。旧Booksでは、これで更新完了であったが、ここからBTONICまで、「SQL DBからXMLへの変換」、「XMLデータのインデックス生成」そして「新Booksへの登録」までを自動的に行っている。処理時間は5時間ほどなので、毎晩処理することにより、月次ではなく、日次更新のアプリケーションであっても、BTONIC方式での対応が可能である。

　満を持して開発した新Booksは、携帯電話対応、PDA対応、オンライン書店アフィリエート機能、Webサービスなどにより、支持を増やしつつある。そのあたりについては、次号でご紹介する。