JP2007156844A - データ登録・検索システムおよびデータ登録・検索方法 - Google Patents

Abstract

【課題】登録処理の高速化を図ったデータ登録・検索システムおよびデータ登録・検索方法を提供する。
【解決手段】第1の記憶部にデータを登録し、第１、第２の記憶部からデータを検索することで、第１の記憶部から前記第２の記憶部へとデータを移行させる前後双方でのデータ検索を可能とする。
【選択図】図１

Description

本発明は、データを登録し、検索するデータ登録・検索システムおよびデータ登録・検索方法に関する。

文書等のデータの登録および検索を可能とするデータ登録・検索システムが用いられている。ここで、登録された文書の全文を検索する全文検索システムなどでは、検索の高速化のために、登録されたデータのインデックスを作成する場合がある。一例として、単語とその単語を含む文書のＩＤとの対応表（インデックス）を作成する。例えば、「東京都」という単語は文書1と文書3に含まれ、「神奈川県」という単語は文書3と文書4に含まれるというような対応表を作り、単語のアルファベット順に並べておく。検索時に対応表の単語を２分探索することで、検索条件の単語を含む文書を高速に抽出できる。

このように、インデックスを作成することで、検索が高速化される。この一方、インデックスの作成に時間がかかるため、情報の登録に時間を要する。既に作成されているインデックスの量が多いほど（対応表が大きいほど）、新たなインデックスの追加に多くの時間が必要となる。
ここで、インデックスのサイズがほぼ均等になるようにキーワードをブロックに割り付けることで、インデックス作成を伴う登録処理を高速化する技術が公開されている（特許文献１参照）。
特開平０８−１４７３２８号

しかしながら、この技術の適用の可否はインデックスの作成方法に依存するため、汎用性にかける。
上記に鑑み、本発明は登録処理の高速化を図ったデータ登録・検索システムおよびデータ登録・検索方法を提供することを目的とする。

本発明の一態様に係るデータ登録・検索システムは、データを記憶する第１の記憶部と、データを記憶する第２の記憶部と、データを前記第1の記憶部に登録するデータ登録部と、前記第１、第２の記憶部からデータを検索するデータ検索部と、前記第１の記憶部から前記第２の記憶部へとデータを移行させるデータ移行部と、を具備することを特徴とする。

本発明の一態様に係るデータ登録・検索方法は、データを記憶する第１、第２の記憶部を用いるデータ登録・検索方法であって、前記第1の記憶部にデータを登録するステップと、前記第１、第２の記憶部からデータを検索するステップと、前記第１の記憶部から前記第２の記憶部へとデータを移行させるステップと、を具備することを特徴とする。

本発明によれば、登録処理の高速化を図ったデータ登録・検索システムおよびデータ登録・検索方法を提供できる。

以下、図面を参照して、本発明の実施の形態を詳細に説明する。
図１は本発明の一実施形態に係るデータベースシステムを表すブロック図である。
データベースシステムは、データの登録、検索等の処理を行うシステムであり、データ利用システム１００とデータ管理システム２００に区分される。
データ利用システム１００は、データ管理システム２００にデータの登録、検索等の処理を要求し、その処理結果を受け取るコンピュータ・システムである。このコンピュータ・システムは、例えば、単一、複数のコンピュータから構成することができる。

データ管理システム２００は、データ利用システム１００からの要求（登録要求、更新要求、削除要求、検索要求）により、データを処理（登録、更新、削除、検索）するものであり、例えば、単一、複数のコンピュータから構成することができる。
データ管理システム２００は、データ管理部２１０，登録用ＤＢ（データベース）２２０，検索用ＤＢ（データベース）２３０、データ移行部２４０，登録用ＤＢ管理部２５０，検索用ＤＢ管理部２６０を有する。データベースとして、登録用ＤＢ２２０，検索用ＤＢ２３０の双方を有することから、データの登録の高速化が可能となる。なお、この詳細は後述する。

データ管理部２１０は、登録用ＤＢ２２０，検索用ＤＢ２３０の双方を管理するものであり、データ登録部２１１，データ検索部２１２，データ更新部２１３，データ削除部２１４を有する。

データ登録部２１１は，ＤＢ（「登録用ＤＢ２２０，検索用ＤＢ２３０」をいう、以下、同様）にデータを登録する。この登録に際し、データ登録部２１１は，登録用ＤＢ２２０のみにデータを登録し、検索用ＤＢ２３０にはデータを登録しない。この結果、データの登録の高速化が可能となる。なお、この詳細は後述する。
データ検索部２１２は，ＤＢからデータを検索する。この検索に際し、データ検索部２１２は，登録用ＤＢ２２０および検索用ＤＢ２３０の双方からデータを検索する。この結果、登録用ＤＢ２２０，検索用ＤＢ２３０のいずれにデータが登録された状態でも、データの検索が可能となる。

データ更新部２１３は，ＤＢのデータを更新する。この更新に際し、データ更新部２１３は，登録用ＤＢ２２０のみでデータを更新ないし登録し、検索用ＤＢ２３０ではデータを更新しない（データがあれば削除する）。この結果、データの更新の高速化が可能となる。
データ削除部２１４は、ＤＢからデータを削除する。この削除に際し、データ削除部２１４は，登録用ＤＢ２２０および検索用ＤＢ２３０の双方からデータを検索する。この結果、登録用ＤＢ２２０，検索用ＤＢ２３０のいずれにデータが登録された状態でも、データの削除が可能となる。

なお、データ登録部２１１，データ検索部２１２，データ更新部２１３，データ削除部２１４のインタフェース（API（Application Program Interface））は、後述のデータ登録部２５１、２６１，データ検索部２５２、２６２，データ更新部２５３、２６３，データ削除部２５４、２６４によって、ＤＢをアクセスするときと同様のインタフェースとすることができる。このようにすると、利用者は登録用ＤＢ管理部２５０，検索用ＤＢ管理部２６０でＤＢをアクセスする場合と同様に、データ管理部２１０を操作することができる。

登録用ＤＢ２２０，検索用ＤＢ２３０は、全体として１つのＤＢを構成する記憶装置、例えば、ハードディスクであり、前者は登録用、後者は検索用である。データは、登録時には登録用ＤＢ２２０に登録され、その後、データ移行部２４０によって検索用ＤＢ２３０に移行される。
新たなデータは登録用ＤＢ２２０に登録されることから、登録処理の高速化がなされる。登録用ＤＢ２２０から検索用ＤＢ２３０への移行処理によって、登録用ＤＢ２２０内の登録されたデータが削減されることから、登録時の処理（例えば、インデックスの作成）の量が低減されるからである。言い換えれば、ＤＢを区分することで、登録処理の高速化が図られ、しかもデータベースの内部構成によらず、汎用的に適用可能である。なお、登録用ＤＢ２２０，検索用ＤＢ２３０は別個あるいは単一のハードウェアの何れで構成しても差し支えない。

登録用ＤＢ２２０，検索用ＤＢ２３０には、登録、検索対象のデータそのもの（登録対象データ）に加え、そのデータのスキーマ情報（スキーマ・データ）、およびインデックス（検索用の索引）用の情報（インデックス・データ）が記憶される。
図２〜図４はそれぞれ、登録対象データ、スキーマ・データ、およびインデックス・データの一例を表す模式図である。なお、これらの例ではデータとしてＸＭＬデータを用いているが、データの形式がＸＭＬ以外であっても差し支えない。

図２に示す登録対象データは、人物のデータの一例であり、データの項目として、その人物の「ファーストネーム（firstname）」、「ラストネーム（lastname）」、連絡先（contact）としての、「電子メールアドレス（email）」および「住所（address）」が表わされる。これらのデータ項目の内容として、「山田」、「太郎」、「yamada@toshiba.co.jp」、および「東京都...」が示される。

また、図２の登録対象データは、登録対象データを互いに識別する識別情報（ＩＤ）としての人物識別番号（person id）「87055710」を含む。このＩＤは適宜に付与することもできるし、既存の情報を用いることもできる。例えば、データが社員の場合に社員番号をＩＤとしたり、データが製品の場合に製品番号をＩＤとしたりすることができる。
また、図２の登録対象データのＩＤの情報が配置される場所のパス、例えば、「/person/@id」を別途保持する。このパスはXPathによって表現できる。なお、XPathとはXML Path Languageの略であり、W3Cにより標準化されたXMLデータを検索するための仕様である。XPathにより、XMLデータの階層構造の一部を指定できる。

「スキーマ」は、登録対象データのデータ構造、例えば、どのようなデータがどのように配列されるかを表現する。
図３に示すスキーマ・データは、図２の登録対象データのスキーマを示し、データの項目としての、「ファーストネーム（firstname）」、「ラストネーム（lastname）」、連絡先（contact）としての、「電子メールアドレス（email）」および「住所（address）」がどのように配列されているか、そのデータ項目の表現形式（「string」等を表している。

図４に示すインデックス・データは、図２の登録対象データのノードパス、ＩＤ、行番号の対応関係を表す。「ノードパス」は、データ項目（「氏名（name）」、「ファーストネーム（firstname）」、「ラストネーム（lastname）」、連絡先（contact）としての、「電子メールアドレス（email）」および「住所（address）」）を表す。
即ち、図４は、それぞれのデータ項目がその登録対象データのどこ（何行目）に配置されるかを表している。例えば、データ項目「ファーストネーム（firstname）」は図３の登録対象データ（ＩＤ：「87055710」）の３行目に配置される。インデックス・データによってデータ項目の配置が判ることから、登録対象データの全部の検索が不要となり、データの検索が高速化する。

データ移行部２４０は，登録用ＤＢ２２０から検索用ＤＢ２３０へとデータを移行する。即ち、登録用ＤＢ２２０からデータを削除し、削除されたデータを検索用ＤＢ２３０に登録する。また、データ移行部２４０は，登録用ＤＢ２２０および検索用ＤＢ２３０でのインデックスの更新を実行する。

登録用ＤＢ管理部２５０は，登録用ＤＢ２２０を管理するものであり、データ登録部２５１，データ検索部２５２，データ更新部２５３，データ削除部２５４を有する。
また、検索用ＤＢ管理部２６０は，検索用ＤＢ２３０を管理するものであり、データ登録部２６１，データ検索部２６２，データ更新部２６３，データ削除部２６４を有する。登録用ＤＢ管理部２５０と検索用ＤＢ管理部２６０はそれぞれ、管理対象が登録用ＤＢ２２０および検索用ＤＢ２３０である以外は実質的には同様の構成である。
なお、登録用ＤＢ管理部２５０と検索用ＤＢ管理部２６０は登録用ＤＢ２２０および検索用ＤＢ２３０を個別に管理するものであるが、登録用ＤＢ２２０等の個別的な管理を行わないのであれば省略することも可能である。

データ登録部２５１およびデータ登録部２６１はそれぞれ，登録用ＤＢ２２０および検索用ＤＢ２３０にデータを登録する。
データ検索部２５２およびデータ検索部２６２はそれぞれ，登録用ＤＢ２２０および検索用ＤＢ２３０からデータを検索する。
データ更新部２５３およびデータ更新部２６３はそれぞれ，登録用ＤＢ２２０および検索用ＤＢ２３０のデータを更新する。
データ削除部２５４およびデータ削除部２５４はそれぞれ，登録用ＤＢ２２０および検索用ＤＢ２３０からデータを削除する。

（データベースシステムの動作）
図５は、本実施形態に係るデータベースシステムの動作手順の一例を表すフロー図である。
データの登録、更新時には（ステップＳ１１）、登録用ＤＢ２２０のみに登録、更新された登録対象データが配置され、データの移行（ステップＳ１３）によって、全ての登録対象データが検索用ＤＢ２３０に移行する。即ち、検索用ＤＢ２３０からすれば、データが移行されなければ、データの登録、更新が完了したことにはならないことになる。
しかしながら、登録用ＤＢ２２０を補完的に用いることで、データの登録、更新を速やかに行い、しかもデータの移行の前後に依らず、データの検索を可能としている（ステップＳ１２、Ｓ１４）。
以下、データの登録、更新、削除、検索、移行の詳細を説明する。なお、データの削除に関しては、データの移行の影響を受けない（データの削除は移行すべきデータの消滅に結びつく）。

（１）データの登録
図６は、ステップＳ１１でのデータの登録の詳細な手順を表すフロー図である。
１）データ登録部２１１が、登録されるデータ自体とこの登録対象データを指定する登録要求を受領する（ステップＳ２１）。
この登録対象データの指定は、そのデータのＩＤの情報またはＩＤが配置される場所のパスの情報によって行える。このパスはXPathを用いて指定することができる。このパスを登録されるデータ自体とは別個の、設定ファイル等で指定してもよい。なお、ＩＤが登録データに含まれるときは、ＩＤの指定を省略してもよい。

２）登録用ＤＢ２２０および検索用ＤＢ２３０を検索し、これらの何れかにデータが存在するか否かを判断する（ステップＳ２２，Ｓ２３）。
同一のデータの２重登録を防止するためである。ＤＢを分離したことで、登録用ＤＢ２２０および検索用ＤＢ２３０それぞれで同一のデータが登録される可能性が生じている。
データの同一性はＩＤが同一か否かで判断できる。データの内容自体が同一であったとしても、ＩＤが異なれば別のデータだからである。
登録要求を受け付けると、データ登録部２１１は、登録に先だって、ＩＤの情報またはそのパスの情報に従って、登録用ＤＢ２２０および検索用ＤＢ２３０の両方を検索する。

３）登録用ＤＢ２２０および検索用ＤＢ２３０のいずれにも登録されるデータが存在しないときは、登録用ＤＢ２２０にデータを登録する（ステップＳ２４）。即ち、データ登録部２１１は、データの登録要求を受け付けると、登録用ＤＢ２２０にのみデータを登録する。この登録に際してインデックスが作成される。登録対象のインデックスのみを作成すれば良いので、インデックスの作成が速やかになされる。

データを登録するときは、登録されるデータの項目に対応して、インデックスが追加される。このインデックスの追加に際して、インデックスが検索され、登録されるデータの項目がインデックス中に存在するか否か（存在するときはどの箇所に存在するか）が判断される。
登録するデータの項目がインデックスに登録済であれば、インデックス上、その項目が記述されている箇所（例えば、行）に、インデックス情報が追加される。登録するデータの項目がインデックスに未登録であれば、インデックスにその項目が追加される（例えば、インデックスへの行の追加）。

４）登録用ＤＢ２２０および検索用ＤＢ２３０のいずれか、または双方に登録されるデータが存在するときは、エラー処理を行う（ステップＳ２５）。例えば、登録されるべきデータが既登録である旨を通知する。

（２）データの更新
図７は、ステップＳ１１でのデータの更新の詳細な手順を表すフロー図である。
１）データ更新部２１３が、更新データと更新対象データとを指定された更新要求を受領する（ステップＳ３１）。
この更新対象データの指定は、そのデータのＩＤの情報またはＩＤが配置される場所のパスの情報によって行える。このパスはXPathを用いて指定することができる。このパスを登録されるデータ自体とは別個の、設定ファイル等で指定してもよい。なお、ＩＤが更新データに含まれるときは、ＩＤの指定を省略してもよい。

２）データ更新部２１３は、登録用ＤＢ２２０および検索用ＤＢ２３０を検索し、これらの何れにデータが存在するか否かを判断する（ステップＳ３２，Ｓ３３）。即ち、データ更新部２１３は更新要求を受け付けると、登録用ＤＢ２２０および検索用ＤＢ２３０の両方を対象にデータを更新処理する。
ＤＢを分離したことで、登録用ＤＢ２２０および検索用ＤＢ２３０のいずれにもデータが登録されている可能性が生じている。

３）登録用ＤＢ２２０に更新されるデータが存在すときは、登録用ＤＢ２２０のデータを更新する（ステップＳ３４）。
４）検索用ＤＢ２３０に更新されるデータが存在するときは、検索用ＤＢ２３０から更新対象データを削除し、登録用ＤＢ２２０に更新データを登録する（ステップＳ３５，Ｓ３６）。

（３）データの削除
図８は、ステップＳ１１でのデータの削除の詳細な手順を表すフロー図である。
１）データ削除部２１４が、削除対象データを指定された削除要求を受領する（ステップＳ４１）。
この削除対象データの指定は、そのデータのＩＤの情報またはＩＤが配置される場所のパスの情報によって行える。このパスはXPathを用いて指定することができる。このパスは、設定ファイル等で指定してもよい。

２）データ削除部２１４は、登録用ＤＢ２２０および検索用ＤＢ２３０を検索する（ステップＳ４２）。即ち、データ削除部２１４は削除要求を受け付けると、登録用ＤＢ２２０および検索用ＤＢ２３０の両方を対象にデータを削除処理する。
ＤＢを分離したことで、登録用ＤＢ２２０および検索用ＤＢ２３０のいずれにもデータが登録されている可能性が生じている。

３）登録用ＤＢ２２０、検索用ＤＢ２３０からデータが削除される（ステップＳ４３）。即ち、登録用ＤＢ２２０に削除されるデータが存在するときは、登録用ＤＢ２２０のデータを削除する。また、検索用ＤＢ２３０に削除されるデータが存在するときは、検索用ＤＢ２３０から削除対象データを削除する。
データが削除されるときは、削除されるデータのインデックスも削除される。即ち、インデックス全体から、削除されるデータに含まれる項目が記述されている箇所（例えば、行）が検索される。そして、その箇所に記述された削除対象のデータのインデックス情報が削除される。

（４）データの検索
図９は、ステップＳ１２，Ｓ１４でのデータの検索の詳細な手順を表すフロー図である。
１）データ検索部２１２が、検索対象データを指定された検索要求を受領する（ステップＳ５１）。
この検索対象データの指定は、そのデータのＩＤの情報またはＩＤが配置される場所のパスの情報によって行える。このパスはXPathを用いて指定することができる。このパスは、設定ファイル等で指定してもよい。

２）データ検索部２１２は、登録用ＤＢ２２０および検索用ＤＢ２３０を検索する（ステップＳ５２）。登録用ＤＢ２２０および検索用ＤＢ２３０に対して同じXPath検索を実施する。
ＤＢを分離したことで、登録用ＤＢ２２０および検索用ＤＢ２３０のいずれにもデータが登録されている可能性が生じている。

３）登録用ＤＢ２２０および検索用ＤＢ２３０の検索結果を纏め、返信する（ステップＳ５３、Ｓ５４）。例えば、登録用ＤＢ２２０で２件、検索用ＤＢ２３０で３件のデータがヒットしたら、計５件のデータを纏めた検索結果として返信する。

（５）データの移行
図１０は、ステップＳ１３でのデータの移行の詳細な手順を表すフロー図である。
１）登録用ＤＢ２２０から検索用ＤＢ２３０にデータを移行する（ステップＳ６１，Ｓ６２）。具体的には、登録用ＤＢ２２０内のデータを削除し、同じデータを検索用ＤＢ２３０に登録する。ここでは１件ずつデータを移行するものとする。但し、複数件のデータを纏めて移行することも可能である。

データの移行に伴い、検索用ＤＢ２３０内のインデックスが更新される。即ち、移行したデータのインデックス情報が検索用ＤＢ２３０に登録される。また、登録用ＤＢ２２０内のインデックス・データが削除される。なお、この削除は個別のデータの移行に対応して行っても良いし、全てのデータの移行が完了した後でも行える。

データの移行に応じて、インデックスが更新され、インデックスの情報が追加、削除、変更される。即ち、移行するデータに含まれる項目がインデックス中に存在するか否か（存在するときはどの箇所に存在するか）が検索され、インデックスの項目への情報の追加、削除、変更の要否がそれぞれ判断される。

インデックスへの情報の追加は、インデックスの項目への情報の追加（対応する項目が既存の場合）、または項目自体の追加（対応する項目が存在しない場合）によって行われる。
インデックスからの情報の削除は、インデックスの項目中の情報の削除によって行われる。
インデックスの情報の変更は、インデックスの項目中の情報の変更によって行われる。

ここで、データのスキーマ情報は登録用ＤＢ２２０から削除されない。その結果、登録用ＤＢ２２０および検索用ＤＢ２３０で同じスキーマ情報が存在することになる。
スキーマ情報が登録用ＤＢ２２０および検索用ＤＢ２３０の双方に存在することで、データの追加、削除の度にスキーマ情報を追加、削除する手間を省くことができる。

２）ステップＳ６１，Ｓ６２での削除、登録の何れかに誤りがあれば、エラー処理を行う（ステップＳ６３，Ｓ６４）。データの削除、登録を一連の処理とし（いわゆるトランザクション処理）、登録用ＤＢ２２０と検索用ＤＢ２３０間で不整合が発生しないためである。

３）移行するデータが無くなるまで、ステップＳ６１〜Ｓ６４の処理が繰り返される（ステップＳ６５）。
４）インデックスを処理する（ステップＳ６６）。
必要であれば、データ移行後に、インデックスの処理がなされる。例えば、登録用ＤＢ２２０からデータを削除したときに、インデックスのごみ（無効なデータ）が残る場合は、登録用ＤＢ２２０のインデックスを削除する。また、登録用ＤＢ２２０へのインデックスの削除処理に換えて、インデックスの初期化を行ってもよい。例えば、登録用ＤＢ２２０のインデックス生成用のインスタンスを削除した後に、このインスタンスを再構築する。

以上のデータの移行は、全てのデータを一括して処理する、いわゆるバッチ処理によって実行できる。
また、データの移行は、スケジューラ機能等を用いて、周期的、定期的に行える。例えば、深夜など、利用が少ない時間にデータを定期的に移行させることができる。

（その他の実施形態）
本発明の実施形態は上記の実施形態に限られず拡張、変更可能であり、拡張、変更した実施形態も本発明の技術的範囲に含まれる。
上記実施形態は、データの例として、XMLデータを挙げて、説明しているが、蓄積、検索するデータはXMLデータに限られない。

本発明の一実施形態に係るデータベースシステムを表すブロック図である。 登録対象データの一例を表す模式図である。 スキーマ・データの一例を表す模式図である。 インデックス・データの一例を表す模式図である。 本発明の一実施形態に係るデータベースシステムの動作手順の一例を表すフロー図である。 図５に示すデータの登録の詳細な手順を表すフロー図である。 図５に示すデータの更新の詳細な手順を表すフロー図である。 図５に示すデータの削除の詳細な手順を表すフロー図である。 図５に示すデータの検索の詳細な手順を表すフロー図である。 図５に示すデータの移行の詳細な手順を表すフロー図である。

符号の説明

１００…データ利用システム、２００…データ管理システム、２１０…データ管理部、２１１…データ登録部、２１２…データ検索部、２１３…データ更新部、２１４…データ削除部、２２０…登録用ＤＢ、２３０…検索用ＤＢ、２４０…データ移行部、２５０…管理部、２５１…データ登録部、２５２…データ検索部、２５２…データ検索部、２５３…データ更新部、２５４…データ削除部、２６０…管理部、２６１…データ登録部、２６２…データ検索部、２６３…データ更新部、２６４…データ削除部

Claims (5)

1. データを記憶する第１の記憶部と、
   データを記憶する第２の記憶部と、
   データを前記第1の記憶部に登録するデータ登録部と、
   前記第１、第２の記憶部からデータを検索するデータ検索部と、
   前記第１の記憶部から前記第２の記憶部へとデータを移行させるデータ移行部と、
   を具備することを特徴とするデータ登録・検索システム。
2. 前記第1、第２の記憶部から更新対象データを検索し、検索されたデータを更新するデータ更新部
   をさらに具備することを特徴とする請求項１記載のデータ登録・検索システム。
3. 前記第1、第２の記憶部から削除対象データを検索し、検索されたデータを削除するデータ削除部
   をさらに具備することを特徴とする請求項１記載のデータ登録・検索システム。
4. 前記データが、このデータを識別する識別情報またはこの識別情報の存在場所を表すパス情報を含む
   ことを特徴とする請求項１記載のデータ登録・検索システム。
5. データを記憶する第１、第２の記憶部を用いるデータ登録・検索方法であって、
   前記第1の記憶部にデータを登録するステップと、
   前記第１、第２の記憶部からデータを検索するステップと、
   前記第１の記憶部から前記第２の記憶部へとデータを移行させるステップと、
   を具備することを特徴とするデータ登録・検索方法。

Images