(57)【要約】【課題】リアルタイム性を維持しつつ、より高度な情報を検索用データベースに登録することが可能なデータ管理システム、データ管理方法、およびプログラムを提供すること。【解決手段】ソースデータを検索用データベースに登録するデータ管理部と、前記ソースデータの一部または全部を前記データ管理部と並行して取得すると共に、前記ソースデータの一部または全部について特定処理を実行し、前記特定処理の結果として生成された遅延更新データを前記検索用データベースに反映させるための処理を行う遅延更新処理部と、を備えるデータ管理システム。【選択図】図１
2018156237.tif 000002
【特許請求の範囲】
【請求項１】
ソースデータを検索用データベースに登録するデータ管理部と、
前記ソースデータの一部または全部を前記データ管理部と並行して取得すると共に、前記ソースデータの一部または全部について特定処理を実行し、前記特定処理の結果として生成された遅延更新データを前記検索用データベースに反映させるための処理を行う遅延更新処理部と、
を備えるデータ管理システム。
【請求項２】
前記遅延更新処理部は、前記遅延更新データを前記検索用データベースに登録するように前記データ管理部に通知し、
前記通知を受けた前記データ管理部が、前記特定処理の結果を前記検索用データベースに反映させる、
請求項１記載のデータ管理システム。
【請求項３】
前記遅延更新処理部は、前記データ管理部からのリクエストに依存せず、任意のタイミングで前記データ管理部に通知する、
請求項２記載のデータ管理システム。
【請求項４】
前記データ管理部は、
前記ソースデータを取得したときに、前記遅延更新データの代わりに仮のデータを前記検索用データベースに登録しておき、
その後、前記データ管理部または前記遅延更新処理部により、前記遅延更新データで前記仮のデータが置き換えられる、
請求項１から３のうちいずれか１項記載のデータ管理システム。
【請求項５】
前記遅延更新処理部は、前記ソースデータの用途に鑑み価値の低いデータを除外して前記特定処理を行う、
請求項１から４のうちいずれか１項記載のデータ管理システム。
【請求項６】
データ管理部が、ソースデータを検索用データベースに登録し、
遅延更新処理部が、前記ソースデータの一部または全部を前記データ管理部と並行して取得すると共に、前記ソースデータの一部または全部について特定処理を実行し、前記特定処理の結果として生成された遅延更新データを前記検索用データベースに反映させるための処理を行う、
データ管理方法。
【請求項７】
コンピュータに、
ソースデータを検索用データベースに登録させ、
前記ソースデータの一部または全部について特定処理を実行させ、
前記特定処理の結果として生成された遅延更新データを前記検索用データベースに反映させるための処理を行わせる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理システム、データ管理方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、視覚クエリを受け取り、検索結果を提供する方法が知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１３９４２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ネットオークションなどのネットワークサービスにおいては、検索用データベースに登録されたデータを用いて、ランキング決定や検索結果の絞込みといった処理がなされることがある。この処理において、単なるメタ情報だけでなく、画像の特徴量やテキストの分散表現などの情報を利用する試みがなされているが、これらの情報は、生成する際の処理負荷が高く、これを検索用データベースに入れ込む場合、検索用データベースの更新が遅れ、リアルタイム性が損なわれる場合がある。
【０００５】
本発明は、このような事情を考慮してなされたものであり、リアルタイム性を維持しつつ、より高度な情報を検索用データベースに登録することが可能なデータ管理システム、データ管理方法、およびプログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【０００６】
本発明の一態様は、ソースデータを検索用データベースに登録するデータ管理部と、前記ソースデータの一部または全部を前記データ管理部と並行して取得すると共に、前記ソースデータの一部または全部について特定処理を実行し、前記特定処理の結果として生成された遅延更新データを前記検索用データベースに反映させるための処理を行う遅延更新処理部と、を備えるデータ管理システムである。
【発明の効果】
【０００７】
本発明の一態様によれば、リアルタイム性を維持しつつ、より高度な情報を検索用データベースに登録することができる。
【図面の簡単な説明】
【０００８】
【図１】データ管理システムを含むネットワークシステムの構成図である。
【図２】検索用ＤＢ２５２の内容の一例を示す図である。
【図３】転置インデックス２５４の内容の一例を示す図である。
【図４】遅延更新用ＤＢ３３２の内容の一例を示す図である。
【図５】検索サーバ２００のソースデータ取得部２１０とデータ管理部２２０により実行される処理の流れの一例を示すフローチャートである。
【図６】検索サーバ２００のデータ管理部２２０により実行される処理の流れの一例を示すフローチャートである。
【図７】検索サーバ２００の検索実行部２３０およびランキング処理部２４０により実行される処理の流れの一例を示すフローチャートである。
【図８】遅延更新処理サーバ３００により実行される処理の流れの一例を示すフローチャートである。
【図９】各フェーズ（局面）の処理を概念的に示す図である。
【発明を実施するための形態】
【０００９】
以下、図面を参照し、本発明のデータ管理システム、データ管理方法、およびプログラムの実施形態について説明する。
【００１０】
［概要］
データ管理システムは、一以上のプロセッサにより実現される。データ管理システムは、ネットオークションにおける検索などに使用される検索用データベース（検索用ＤＢ）を管理するシステムである。データ管理システムは、例えば、オークションの出品者などにより提供されるデータを含むソースデータを検索用ＤＢに登録する一方で、ソースデータの一部または全部について、画像特徴の計算、テキストの分散表現化などの特定処理を実行する。この特定処理がなされる間、データ管理システムは、特定処理が行われた結果として生成されるデータ（以下、遅延更新データ）の代わりに仮のデータ（以下、デフォルトデータ）を検索用ＤＢに登録しておく。特定処理が完了した後、デフォルトデータが遅延更新データで置き換えられる。これによって、リアルタイム性を維持しつつ、より高度な情報を検索用データベースに登録することができる。
【００１１】
［全体構成］
図１は、データ管理システムを含むネットワークシステムの構成図である。ネットワークシステムでは、オークションサーバ１００、検索サーバ２００、遅延更新処理サーバ３００、検索利用サービスサーバ４００、端末装置５００などの装置がネットワークＮＷを介して通信を行う。これらの装置は、ネットワークＮＷに接続するためのインターフェースを備える。ネットワークＮＷは、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などを含む。なお、図１に示すハードウェアの区分はあくまで一例であり、例えば、検索サーバ２００と遅延更新サーバ３００は、統合されたサーバによって実現されてもよいし、更にオークションサーバ１００に併合されてもよい。すなわち、図１に示す各種サーバのうち一部は、仮想サーバであってもよい。
【００１２】
［オークションサーバ］
オークションサーバ１００は、例えば、オークション管理部１１０と、バッファ管理部１２０とを備える。オークション管理部（オークションマスタ）１１０は、端末装置５００に対してネットオークションサービスを提供する。端末装置５００では、ブラウザやアプリケーションプログラムなどのＵＡ（User Agent）が起動し、オークションサーバ１００に対して画像の要求、クエリの送信、その他の処理を行う。オークションの出品者の使用する端末装置５００からは、出品する商品またはサービス（以下、単に商品という）に関するデータがオークションサーバ１００に送信される。オークションの入札者（これから入札しようとするユーザも含むものとする）の使用する端末装置５００からは、入札者が興味のある商品を検索するためのクエリ、入札する旨の意思を示す情報、入札額などがオークションサーバ１００に送信される。
【００１３】
オークション管理部１１０は、オークションに関する種々の情報を、ソースデータとして検索サーバ２００に提供する。ソースデータには、オークションの出品者から提供されたデータの他、オークションの進捗に関するデータなどが含まれる。また、オークション管理部１１０は、入札者の端末装置１００から受信したクエリを用いた検索を、検索サーバ２００に依頼する。なお、オークションサーバ１００と検索サーバ２００が一体である場合、これらの処理は、ソフトウェア間で通知を行うことを意味する。
【００１４】
バッファ管理部１２０は、例えば、オークションの出品者からのソースデータをバッファに蓄積し、所望のタイミングで検索サーバ２００と遅延更新処理サーバ３００に送信する。この送信されるソースデータには、出品された商品の識別情報であるドキュメントＩＤが付与されている。ドキュメントＩＤは、オークション管理部１１０によって商品に対して付与されるものである。なお、バッファ管理部１２０は、ソースデータを検索サーバ２００にのみ送信し、検索サーバ２００において、ソースデータの一部または全部を遅延更新処理サーバ３００に転送するようにしてもよい。
【００１５】
［検索サーバ］
検索サーバ２００は、例えば、ソースデータ取得部２１０と、データ管理部２２０と、検索実行部２３０と、ランキング処理部２４０と、第１記憶部２５０とを備える。ソースデータ取得部２１０、データ管理部２２０、検索実行部２３０、およびランキング処理部２４０は、例えば、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラムを実行することにより実現される。また、これらの機能部のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアの協働により実現されてもよい。第１記憶部２５０は、例えば、ＨＤＤ（Hard Disk Drive）やフラッシュメモリにより実現される。第１記憶部２５０には、例えば、検索用ＤＢ２５２と、転置インデックス２５４とが格納される。
【００１６】
ソースデータ取得部２１０は、オークションサーバ１００からソースデータを取得し、データバッファ（不図示）に格納する。前述したように、ソースデータ取得部２１０は、オークションサーバ１００から受信したソースデータのうち一部または全部を遅延更新処理サーバ３００に転送する機能を有してもよい。
【００１７】
データ管理部２２０は、ソースデータを適宜加工して検索用ＤＢ２５２に登録する。図２は、検索用ＤＢ２５２の内容の一例を示す図である。検索ＤＢ２５２には、例えば、ドキュメントＩＤ、タイトル、画像ＵＲＬ（Uniform Resource Locator）、価格、入札数、お気に入り登録数、遅延更新データなどの情報が登録される。
【００１８】
タイトルは、例えば、商品の紹介画像へのリンクに表示されるテキスト情報である。画像ＵＲＬは、商品の画像を参照するためのＵＲＬ（参照情報）である。価格は、現時点での最高入札額である。未入札である場合、出品者により設定された最低入札額が格納される。入札数は、商品に入札した入札者の数である。お気に入り登録数は、その商品のオークションページをお気に入りに登録しているユーザの数である。
【００１９】
遅延更新データの項目には、遅延更新処理サーバ３００により生成される遅延更新データが格納される。この遅延更新データの項目には、遅延更新処理サーバ３００により処理が行われている間、代わりにデフォルト値が格納される。図２の例では、ドキュメントＩＤ＝００１の商品に対しては既に遅延更新データが格納されているが、ドキュメントＩＤ＝００２の商品に対してはデフォルト値が格納されている。デフォルト値は、後述するランキング処理部２４０の処理において、大きな影響を与えない値であることが望ましい。
【００２０】
また、データ管理部２２０は、検索実行部２３０による検索を高速化するために、転置インデックス２５４を生成する。図３は、転置インデックス２５４の内容の一例を示す図である。転置インデックス２５４は、クエリとなり得る単語に対して、ドキュメントＩＤが対応付けられた情報である。データ管理部２２０は、その単語或いは類似する単語をタイトルに含む商品、或いは、画像からその単語に該当すると推定される商品のドキュメントＩＤを、転置インデックス２５４に登録する。類似する単語の判定には、テキストを分散表現化したベクトルが使用されてよい。
【００２１】
検索実行部２３０は、転置インデックス２５４を用いて、オークションサーバ１００から依頼された検索を実行する。例えば、オークションサーバ１００からクエリ「テレビ」について検索を依頼された場合、検索実行部２３０は、転置インデックス２５４からドキュメントＩＤ＝００１、００５、…を取得する。そして、検索実行部２３０は、ドキュメントＩＤ＝００１、００５、…である商品の情報を検索用ＤＢ２５２から抽出する。
【００２２】
ランキング処理部２４０は、検索実行部２３０により抽出された商品に対して、所定の基準によって順位付けを行うと共に、上位のｋ個の商品を選択する（ｋは任意の自然数）。そして、選択したｋ個の商品の情報を、順位付けの情報と共にオークションサーバ１００に送信する。
【００２３】
ランキング処理部２４０による順位付けの手法としては、種々のものが採用され得る。例えば、ランキング処理部２４０は、入札数が多い商品に高いスコアを付与してよい。また、ランキング処理部２４０は、お気に入り登録数が多い商品に高いスコアを付与してよい。また、ランキング処理部２４０価格が安い商品に高いスコアを付与してよい。
【００２４】
また、ランキング処理部２４０は、遅延更新データとして登録された画像特徴から、商品の画像が鮮明であることが分かる商品に高いスコアを付与してよい。画像特徴としては、画像の明るさ、カラフルさ、コントラスト、Ｌ*ａ*ｂヒストグラム、細部の鮮鋭度などがある。遅延更新データとして画像特徴などの高度な情報を含めておくことで、精度の高いランキング処理を行うことができる。
【００２５】
［遅延更新処理サーバ］
遅延更新処理サーバ３１０は、例えば、フロント処理部３１０と、一以上の特定処理部３２０−１〜３２０−ｎ（ｎは任意の自然数）と、第２記憶部３３０と、プッシュ通知部３４０とを備える。以下、いずれの特定処理部であるか区別しないときは、単に特定処理部３２０と称する。フロント処理部３１０、特定処理部３２０、およびプッシュ通知部３４０は、例えば、ＣＰＵなどのプロセッサがプログラムを実行することにより実現される。また、これらの機能部のうち一部または全部は、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアの協働により実現されてもよい。第２記憶部３３０は、例えば、ＨＤＤやフラッシュメモリにより実現される。第２記憶部３３０には、例えば、遅延更新用ＤＢ３３２が格納される。
【００２６】
図４は、遅延更新用ＤＢ３３２の内容の一例を示す図である。遅延更新用ＤＢ３３２は、例えば、ドキュメントＩＤに対して、対象特定情報、遅延更新データ、送信済フラグ、登録日時などの情報が対応付けられたものである。対象特定情報とは、特定処理の対象となるデータを特定する情報であり、画像特徴を求める対象の画像の画像ＵＲＬや、分散表現化するテキストの識別情報（或いはテキストそのもの）などである。
【００２７】
フロント処理部３１０は、オークションサーバ１００からソースデータの一部または全部を取得すると、まず、第２記憶部３３０の遅延更新用ＤＢを参照し、同じドキュメントＩＤの遅延更新データ、或いは対象特定情報が同じ遅延更新データが存在するか否かを確認する。これらが存在しない場合、フロント処理部３１０は、ソースデータの一部または全部を、特定処理の対象として特定処理部３２０に分配する。なお、フロント処理部３１０は、ソースデータの内容を解析し、価値の低い商品に関するデータを除外してもよい。価値の低い商品とは、例えば、長期間オークションにかけられているにも関わらず、入札数がゼロである商品などである。
【００２８】
それぞれの特定処理部３２０−１〜３２０−ｎは、固有の特定処理を実行する。例えば、特定処理部３２０−１は画像特徴を求める処理を実行し、特定処理部３２０−２はテキストを分散表現化する処理を実行する。特定処理部３２０は、処理の結果として生成される遅延更新データを、ドキュメントＩＤや対象特定情報、登録日時等の情報と共に遅延更新用ＤＢ３３２に格納する。
【００２９】
プッシュ通知部３４０は、例えば、検索サーバ２００のデータ管理部２２０の動作に依存しない所望のタイミングで、遅延更新用ＤＢ３３２に格納された遅延更新データを検索用ＤＢ２５２に登録するように、検索サーバ２００にプッシュ通知する。プッシュ通知とは、例えば、検索用ＤＢ２５２に登録するように要求するメッセージと共に、遅延更新データの内容を送信することである。なお、検索サーバ２００と遅延更新処理サーバ３００が一体である場合、プッシュ通知は、ソフトウェア間で通知を行うことを意味する。プッシュ通知を行うと、送信済フラグが立てられる。また、検索サーバ２００と遅延更新処理サーバ３００が一体である場合、プッシュ通知部３４０は、検索用ＤＢの該当する項目に直接、遅延更新データを登録（書き込み）してもよい。
【００３０】
プッシュ通知部３４０は、例えば、送信済フラグが立てられていないレコードを、プッシュ通知の対象とする。また、送信済フラグを省略し、プッシュ通知部３４０は、遅延更新用ＤＢ３３２の全てのレコードをプッシュ通知の対象としてもよい。プッシュ通知部３４０は、登録日時を参照し、ある程度の期間が経過したレコードを削除するようにしてもよい。
【００３１】
［処理フロー］
図５は、検索サーバ２００のソースデータ取得部２１０とデータ管理部２２０により実行される処理の流れの一例を示すフローチャートである。まず、ソースデータ取得部２１０が繰り返しソースデータを取得する（Ｓ１）。検索用ＤＢ２５２の更新タイミングが到来すると（Ｓ２）、データ管理部２２０が、既に取得されたソースデータに基づいて、検索用ＤＢ２５２を更新する（Ｓ３）。そして、データ管理部２２０は、遅延更新データの項目にデフォルト値をセットする（Ｓ４）。検索サーバ２００は、係る処理を繰り返し実行する。
【００３２】
図６は、検索サーバ２００のデータ管理部２２０により実行される処理の流れの一例を示すフローチャートである。遅延更新処理サーバ３００からプッシュ通知があると（Ｓ１０）、データ管理部２２０は、遅延更新データでデフォルト値を置き換える（Ｓ１１）。
【００３３】
図７は、検索サーバ２００の検索実行部２３０およびランキング処理部２４０により実行される処理の流れの一例を示すフローチャートである。検索実行部２３０は、オークションサーバ１００からクエリを取得すると（Ｓ２０）、転置インデックス２５４を参照してドキュメントＩＤを取得する（Ｓ２１）。次に、検索実行部２３０は、検索用ＤＢ２５２からＳ２１で取得したドキュメントＩＤに対応する商品を抽出する（Ｓ２２）。次に、ランキング処理部２４０が、Ｓ２２で抽出された商品についてランキング計算を行い（Ｓ２３）、ランキング結果をオークションサーバ１００に送信する（Ｓ２４）。
【００３４】
図８は、遅延更新処理サーバ３００により実行される処理の流れの一例を示すフローチャートである。フロント処理部３１０は、ソースデータを取得すると（Ｓ３０）、遅延更新用ＤＢ３３２を参照し（Ｓ３１）、ドキュメントＩＤまたは対象特定情報がソースデータと同じ遅延更新データが存在するか否かを判定する（Ｓ３２）。同じものが存在しない場合、フロント処理部３１０は、特定処理部３２０に対して特定処理を指示する（ステップＳ３３）。
【００３５】
［処理イメージ］
図９は、以上説明した処理によって実現される各フェーズ（局面）の処理を概念的に示す図である。まず、フェーズ１において、出品者がオークションサーバ１００に商品を出品すると、オークションサーバ１００は、ドキュメントＩＤを付与してソースデータを生成し、ソースデータを検索サーバ２００に送信する。検索サーバ２００は、検索用ＤＢ２５２にソースデータを登録する。図示を省略しているが、ソースデータの一部または全部は遅延更新サーバ３００にも送信されている。
【００３６】
フェーズ２において、入札者がクエリをオークションサーバ１００に伝えると、オークションサーバ１００はクエリを検索サーバ２００に送信する。検索サーバ２００は、転置インデックス２５４と検索用ＤＢ２５２を用いて検索およびランキング処理を行う。検索およびランキングの結果はオークションサーバ１００を介して入札者に提供される。この時点では、検索用ＤＢ２５２における、該当するドキュメントＩＤの遅延更新データの項目には、デフォルト値が登録されている。
【００３７】
フェーズ３において、遅延更新サーバ３００が検索サーバ２００に対してプッシュ通知を行い、検索サーバ２００は、検索用ＤＢ２５２における、該当するドキュメントＩＤの遅延更新データの項目を、デフォルト値から遅延更新データに置き換える。
【００３８】
フェーズ４において、入札者がクエリをオークションサーバ１００に伝えると、オークションサーバ１００はクエリを検索サーバ２００に送信する。検索サーバ２００は、転置インデックス２５４と検索用ＤＢ２５２を用いて検索およびランキング処理を行う。検索およびランキングの結果はオークションサーバ１００を介して入札者に提供される。この時点では、検索用ＤＢ２５２における、該当するドキュメントＩＤの遅延更新データの項目には、フェーズ３で受信した遅延更新データが登録されている。
【００３９】
なお、図１に示す検索利用サービスサーバ４００は、例えば、各種の検索サービスを実行するサーバである。サービスサーバ４００は、自身が行う検索サービスの結果の中に、オークションサーバ１００において出品されている商品の情報を含めて端末装置５００に送信するなどの処理を行う。
【００４０】
以上説明した実施形態のデータ管理システム、データ管理方法、およびプログラムによれば、ソースデータ取得部２１０がソースデータを取得し、データ管理部２２０が取得されたソースデータを検索用ＤＢ２５２に登録し、遅延更新処理サーバ３００がソースデータの一部または全部をデータ管理部２２０と並行して取得すると共に、ソースデータの一部または全部について特定処理を実行し、遅延更新データを、検索用ＤＢ２５２に登録するための処理を行うことで、リアルタイム性を維持しつつ、より高度な情報を検索用ＤＢ２５２に登録することができる。データ管理部２２０は、処理時間を要する特定処理の結果を待たずにソースデータを検索用ＤＢ２５２に登録するため、出品後、間もない商品を検索結果に含ませることができる。なお、その時点では遅延更新データをランキング処理に反映させることはできないが、デフォルト値を用いてランキング計算を行うことで、速報的なランキング結果を返すことができる。また、事後的に遅延更新データを検索用ＤＢに追加することで、価値の高い商品を高い順位で入札者に推奨することができる。
【００４１】
上記説明した処理とは別に、検索サーバ２００は、あるユーザがクリックした商品の画像の画像特徴に基づいて、Histogram Intersectionによってランキング計算を行ってもよい。この場合、検索サーバ２００は、以下の手順で処理を行う。
【００４２】
（１）対象のサムネイル画像のＲＧＢを１つにまとめ、ビンの数が６４個のヒストグラムを計算する。
（２）ユーザの閲覧履歴（最大２０件）から各サムネイル画像のヒストグラムを計算し、平均を求める（ユーザ特徴）。
（３）対象のサムネイル画像とユーザ特徴について、式（１）によってHistogram Intersectionを計算する。式中、Ｈ１はユーザ特徴のヒストグラムであり、Ｈ２は対象のサムネイル画像のヒストグラムである。このHistogram Intersectionが高い画像ほど、ユーザがこれまでに検索した画像に近い画像特徴を有すると考えられるため、順位を高くする。
【００４３】
【数１】
2018156237.tif 000003
【００４４】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００４５】
１００  オークションサーバ
１１０  オークション管理部
１２０  バッファ管理部
２００  検索サーバ
２１０  ソースデータ取得部
２２０  データ管理部
２３０  検索実行部
２４０  ランキング処理部
２５０  第１記憶部
３００  遅延更新処理サーバ
３１０  フロント処理部
３２０  特定処理部
３３０  第２記憶部
３４０  プッシュ通知部
４００  検索利用サービスサーバ
５００  端末装置
【図１】
2018156237.tif 000004
【図２】
2018156237.tif 000005
【図３】
2018156237.tif 000006
【図４】
2018156237.tif 000007
【図５】
2018156237.tif 000008
【図６】
2018156237.tif 000009
【図７】
2018156237.tif 000010
【図８】
2018156237.tif 000011
【図９】
2018156237.tif 000012