去る２００７年２月に，ＤＤＢＪではシステムの入れ替えを行い，ＤＤＢＪ内部の情報システムからサービス提供システムまで（データベースから解析サーバまで）機器を一新して業務に臨んでおります。
ＤＤＢＪをご利用になる方からは，内部のシステムはなかなか見えて来ることはないかと思いますが，今回はこの内部のシステムの中でも超大量エントリの公開処理についてお話させて頂きたいと思います。

ＤＤＢＪでは，公開前のエントリ情報が外部から閲覧されることが決して無いように，公開前のエントリ情報を保持しているデータベースと getentry などで閲覧できる公開後のエントリの情報を保持するデータベースとを分離しています。このため，下図に示されるような流れで，一日に一回夜間処理によって，公開前エントリの情報を保持しているデータベースから，その日の公開分のフラットファイルを出力してgetentry，相同性検索サービス，ARSA，anonymous FTP などの公開サービスに展開してきました。



大量のエントリを展開するために，旧システムでは長時間を要していましたが，新システムでは今月（2008年1月），約１５０万件を無事展開することができました。新システムでも１日目約１００万件，２日目約５０万件と２日掛かりという超大量件数でしたが，事前にシステムの例外処理を行うこともなく計画通り完了しました。
システムの入れ替え前は，一日の展開は３５万件程度が限度でしたので，今回の展開には４日以上かかったことになります。システム入れ替え時に旧システムに対して３倍程度のエントリを処理可能なようにハードウエアとソフトウエアを見直しましたが，今回設計通りの性能を発揮することを確認できました。

しかし，公開処理は安全に行うことが出来たものの，夜間処理の開始時刻の再検討，転送用ファイル作成処理の見直しなど，課題もいくつか見つかりました。

検討の例

（課題１）過去の経験から夜間処理の開始を 01:00 に設定していたが，実は早められるのではないか
==>検討内容： 24:00 開始のバックアップシステムに影響しない方法を再検討する。
課題２）ファイルの受け渡し時間について，データベース側と公開サービス側とで，若干ずれが生じている。Flat File の作成は毎時３０分，Flat File の転送は毎時１０分で，約４０分のタイムラグが発生している。
==>検討内容：ずれが必要な理由は各サーバで出力された Flat File を１ファイルにしなければならないためで，各サーバで出力されたFlat Fileを公開サービスに直接渡すことが出来れば，３０分は時間短縮できる。
（課題３） getentry の反映開始時間は，04:00， 08:00， 12:00 となっているが，12:00 のタイミングで反映開始となると，１００万件の反映が完全に完了する時間が 18:30 になる。
==>検討内容：今の件数で 17:00 までに完了するには，10:00 から反映開始をする必要がある。現在，10:00 からは getentry で別の処理が実行されてしているため，タイミングを調整する必要がある。


こうした課題を解決するためには，サーバ同士の連携をさらに強化する必要があるため，システムエンジニアの中で検討を進めているところです。 今回はデータ登録やデータの検索ならびに解析をご利用いただいている方々が意識されるシステムの話題ではありませんでしたが，ＤＤＢＪから大量公開のお知らせが出た際には特に，円滑なデータ更新のためにシステムエンジニアが知恵を絞っているところを思い浮かべていただければ幸いです。