JP2020119445A - 情報処理装置、情報処理プログラム、及び情報処理システム - Google Patents

Abstract

【課題】キーバリューストアに格納されたデータに対するインデックスの作成処理のリソース量を低減させる。【解決手段】キーとバリューとを対応付けて格納するキーバリューストア１２ａに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストア１２ａに格納する格納処理部１１と、単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報１３ａを管理する管理部１３と、前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報１３ａと、前記キーバリューストア１２ａが格納するデータと、に基づいて、前記キーバリューストア１２ａのインデックス１５ｂを作成する作成部１５、１６と、を備える。【選択図】図２

Description

本発明は、情報処理装置、情報処理プログラム、及び情報処理システムに関する。

ＩｏＴ（Internet of Things）において利用されるセンサ等の観測又は計測（以下、まとめて「観測」と表記する）を行なうＩｏＴデバイスは、観測対象の近くに設置され、観測結果をデータセンタ等における１以上のサーバに送信する。

なお、観測結果は、ＩｏＴデバイスから、インターネット等のネットワークを介して直接、又は、観測対象の近く（「エッジ」）に設置されたエッジコンピュータ及び当該ネットワークを介して、サーバに送信される。サーバでは、受信した（収集した）観測結果が様々な分析やサービスに利用される。

なお、観測結果は、観測する情報の種類（キー；ｋｅｙ）、及び、観測する情報の値（バリュー；ｖａｌｕｅ）を含んでよい。以下、観測結果を「キーバリュー」と表記する場合がある。

サーバでは、ＩｏＴデバイスから受信した複数のキーバリュー（キーバリュー群）を、ＫＶＳ（Key-Value Store）等のデータベース（ＤＢ；DataBase、「データストア」と表記されてもよい）に格納する。ＫＶＳシステムとしては、公知の分散ＫＶＳシステムを用いることができる。

分散ＫＶＳシステムでは、ＫＶＳからのリード（ｒｅａｄ）のみならずＫＶＳへのライト（ｗｒｉｔｅ）においても、処理を行なうノード（以下、「担当ノード」と表記する場合がある）を増加させることで、リニアに性能を向上させることが可能である。

これは、分散ＫＶＳシステムが、分散ハッシュテーブル（ＤＨＴ；Distributed Hash Table）等によって、キー（ｋｅｙ）に対しキー数に依存しないオーダで担当ノードを決定するとともに、負荷を平準化するからである。

特開２０１８−１３３０３７号公報

ところで、サーバは、ＫＶＳシステムに対して、一般的なＲＤＢＭＳ（Relational DB Management System）で用いられるインデックス作成機構によって、ＫＶＳの蓄積データのインデックスを作成し、インデックスを使用して検索要求に対する処理を行なう。以下の説明において、「インデックス」を「ＩＤＸ」（Index）と表記する場合がある。

しかし、ＩｏＴデバイス等からのキーバリュー群を蓄積するＫＶＳシステムにおいては、多様なキーが比較的高いレートでＫＶＳに書き込まれることになる。

そのため、例えば、ＩＤＸ作成処理におけるプロセッサの処理負荷の増加や、ＩＤＸを記憶する記憶領域の使用サイズの増加等が生じ、ＩＤＸの計算リソースや記憶領域のリソースを多く要する場合がある。

１つの側面では、本発明は、キーバリューストアに格納されたデータに対するインデックスの作成処理のリソース量を低減させることを目的の１つとする。

１つの側面では、情報処理装置は、格納処理部と、管理部と、作成部と、を備えてよい。前記格納処理部は、キーとバリューとを対応付けて格納するキーバリューストアに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納してよい。前記管理部は、単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理してよい。前記作成部は、前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成してよい。

１つの側面では、キーバリューストアに格納されたデータに対するインデックスの作成処理のリソース量を低減させることができる。

一実施形態に係るＩｏＴシステムの構成例を示すブロック図である。 一実施形態に係るＫＶＳシステムの機能構成例を示すブロック図である。 エントリ情報の一例を示す図である。 ＫＶＳに格納されるデータの一例を示す図である。 ＵＩＤ（Unique Identifier）リストに格納されるデータの一例を示す図である。 エントリ検索情報の一例を示す図である。 ＩＤＸ作成状況の一例を示す図である。 ＩＤＸに格納されるデータの一例を示す図である。 ＫＶＳクラスタに対するエントリの登録処理に係る構成例を示すブロック図である。 ノードリストの一例を示す図である。 ＫＶＳクラスタに対するエントリの検索処理に係る構成例を示すブロック図である。 インデクサリストの一例を示す図である。 一実施形態に係るＫＶＳシステムにおけるスケールアウト処理の制御に着目した機能構成例を示すブロック図である。 一実施形態に係るＫＶＳシステムによる処理の一例を説明するフローチャートである。 一実施形態に係るＫＶＳシステムによる処理の一例を説明するフローチャートである。 一実施形態に係るＫＶＳシステムによる処理の一例を説明するフローチャートである。 エントリ格納処理の動作例を説明するフローチャートである。 エントリ格納処理の動作例を説明する図である。 エントリ検索処理の動作例を説明するフローチャートである。 エントリ検索処理及びＩＤＸ作成処理の動作例を説明する図である。 エントリ検索処理の動作例を説明する図である。 ＩＤＸ作成処理の動作例を説明するフローチャートである。 スケールアウト処理の動作例を説明するフローチャートである。 一実施形態に係るコンピュータのハードウェア構成例を示すブロック図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の説明で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕一実施形態
一般的なＲＤＢＭＳで作成されるＩＤＸは、蓄積量に従ってＩＤＸサイズが肥大化し、また、蓄積量に従ってエントリの追加や削除の際の処理時間が大きくなる。そのため、頻繁な更新が行なわれない検索キーに対して少数のＩＤＸを作成するというのが一般的である。

これに対し、ＩｏＴデバイス等は、デバイスの種類や設置場所、目的等に応じて、多様なキーを持つことが想定される。また、ＩｏＴデバイス等は、一般的なＲＤＢＭＳ或いはＫＶＳシステムで想定されるレートよりも比較的高いレートで、ＫＶＳに対してキーバリュー群の書き込みを行なうことが想定される。

そのため、ＩｏＴデバイス等からのキーバリュー群を蓄積する分散ＫＶＳシステムにおいては、多様なキーが高いレートでＫＶＳに書き込まれることになり、上述したように、ＩＤＸの計算コストや記憶領域のコストが高くなることが想定される。

また、ＩｏＴデバイス等で収集されるデータは、格納処理数に対して検索要求の頻度が低い場合が多い。そのため、一般的なＲＤＢＭＳのようにＩＤＸを常時維持することは、費用対効果の面においても、ＫＶＳシステムには適さない場合があるといえる。

そこで、一実施形態では、１つの側面において、ＫＶＳシステムに格納されたデータに対するＩＤＸの作成処理のリソース量を低減させる手法を説明する。

また、一実施形態では、他の側面において、ＩｏＴデバイス等で生成されるキーバリュー群に対し、リソース量の面でスケール可能な仕組みを提供する手法を説明する。

〔１−１〕一実施形態の構成例
図１は、一実施形態の一例としてのＩｏＴシステム１００の構成例を示すブロック図である。図１に示すように、ＩｏＴシステム１００は、例示的に、複数のＩｏＴデバイス１０１、複数のエッジコンピュータ１０２、インターネット等のネットワーク１０３及び１０６、データセンタ１０４、及び、複数のサーバ１０５を備えてよい。

ＩｏＴデバイス１０１は、種々の手法によってデータを取得し、当該データをデータセンタ１０４に登録するために、当該データを含む登録要求を、対応するエッジコンピュータ１０２に送信する。なお、ＩｏＴデバイス１０１は、データを取得する都度、エッジコンピュータ１０２に送信してもよいし、データを蓄積し、一定時間間隔で蓄積したデータを送信してもよい。なお、ＩｏＴデバイス１０１は、エッジコンピュータ１０２を介さずに、ネットワーク１０３（データセンタ１０４）に対して登録要求を送信してもよい。

ＩｏＴデバイス１０１が取得するデータとしては、例えば、観測対象の観測結果、ユーザ等による入力結果、及び、入力されたデータに対する演算結果、等のキーバリューが挙げられる。キーバリューは、情報の種類（キー）、及び、情報の値（バリュー）を含んでよい。

ＩｏＴデバイス１０１としては、例えば、情報処理装置１０１ａ、ＧＰＳ等の衛星測位システムを利用する測位デバイス１０１ｂ、及び、種々のセンサ１０１ｃ等が挙げられる。情報処理装置としては、ＰＣ（Personal Computer）、スマートホン、タブレット、及び携帯電話等が挙げられる。なお、ＩｏＴデバイスは、無線又は有線による通信機能を備えてもよいし、当該通信機能を備える通信デバイスと接続されてもよい。

エッジコンピュータ１０２は、観測対象の近く（エッジ）に設置され、ＩｏＴデバイス１０１から受信した登録要求を、ネットワーク１０３を介してデータセンタ１０４に送信する。なお、エッジコンピュータ１０２は、ＩｏＴデバイス１０１からデータそのものを受信し、ＩｏＴデバイス１０１に代わって、受信したデータを含む登録要求を作成し、作成した登録要求をデータセンタ１０４に送信してもよい。

データセンタ１０４は、図示しない複数のサーバを備える。データセンタ１０４は、複数のサーバにより、ＩｏＴデバイス１０１から送信された登録要求を受信し、受信した登録要求に含まれるデータを、ＤＢ、例えばＫＶＳに格納する。また、データセンタ１０４は、複数のサーバにより、サーバ１０５から送信された検索要求を受信し、検索要求で指定された検索条件を満たすデータを、ＩＤＸを用いてＤＢから検索して、検索結果を検索要求元に応答する。

複数のサーバ１０５は、インターネット等のネットワーク１０６を介してデータセンタ１０４のＤＢ、例えばＫＶＳに格納されたデータの参照を行なう。例えば、サーバ１０５は、データセンタ１０４の複数のサーバに対して検索要求を送信し、検索結果を複数のサーバから受信する。なお、ネットワーク１０６は、ネットワーク１０３と同一のネットワークであってもよい。

複数のサーバ１０５としては、種々の情報処理装置、例えば、物理マシン、仮想マシン、又は、これらの組み合わせ、等のコンピュータが挙げられる。サーバ１０５は、例えば、人工知能（ＡＩ；Artificial Intelligence）における学習（例えば深層学習（Deep Learning））用又は分析用のデータとして、ＫＶＳに格納されたデータを参照してもよい。ＫＶＳに格納されるデータは、いわゆる「ビッグデータ」として扱われるデータであってもよい。

〔１−２〕機能構成例
図２は、一実施形態の一例としてのＫＶＳシステム１の機能構成例を示すブロック図である。ＫＶＳシステム１は、情報処理システムの一例であり、例えば、図１に示すデータセンタ１０４が備える複数のサーバにより実現されてよい。なお、ＫＶＳシステム１は、データセンタ１０４とは異なる施設等の拠点に設けられたサーバにより実現されてもよい。

データセンタ１０４及び／又は拠点に設けられた複数のサーバの各々は、後述するように、プロセッサ、メモリ、及び、記憶装置等を備えた物理マシンであってよい。物理マシンである複数のサーバは、複数の仮想マシン（ＶＭ；Virtual Machine）を実行してもよい。仮想マシンは、例えば複数のサーバがＩａａＳ（Infrastructure as a Service）等のクラウドシステムを提供する場合、当該クラウドシステムにより提供される仮想マシンであってもよい。

従って、ＫＶＳシステム１は、複数の物理マシン、複数の仮想マシン、或いは、１以上の物理マシン及び１以上の仮想マシンの組み合わせによって実現（実行）されてよい。

ＫＶＳシステム１としては、分散ＫＶＳシステムを用いることができる。

図２に示すように、ＫＶＳシステム１は、例示的に、ストアハンドラ１１、ＫＶＳクラスタ１２、ＵＩＤマネージャ１３、クエリハンドラ１４、ＩＤＸマネージャ１５、及び、インデクサ１６を備えてよい。

ストアハンドラ１１、ＫＶＳクラスタ１２、ＵＩＤマネージャ１３、クエリハンドラ１４、ＩＤＸマネージャ１５、及び、インデクサ１６は、それぞれ、１つ又は複数のノードにより実現（実行）されてよい。ノードとしては、例えば、仮想マシン、又は、物理マシンが挙げられる。

一実施形態に係るＫＶＳシステム１は、後述する構成によって、スケールアウトを可能とする。スケールアウトとは、ＫＶＳシステム１に対して、ハードウェア（ＨＷ；Hardware）資源やネットワーク（ＮＷ；Network）資源を投入（追加）することにより、ＫＶＳシステム１全体の性能を向上させることである。一実施形態に係るＫＶＳシステム１は、スケールアウトにより、ＫＶＳに対するデータの格納性能及び検索性能を、スケールアウトの規模に比例して向上させることが可能となる。

なお、ＨＷ資源としては、ＣＰＵ（Central Processing Unit）等のプロセッサ、メモリ、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記憶装置、等が挙げられる。ＮＷ資源としては、通信回線の帯域（又は帯域幅）、ルータやスイッチ等の通信機器、等が挙げられる。

以下、図２〜図８を参照した説明においては、便宜上、機能ブロック１１〜１６が、それぞれ１つのノードにより実現される場合について説明する。

ストアハンドラ１１は、ＫＶＳクラスタ１２に対するデータのストア（登録、格納）の制御を行なう。例えば、ストアハンドラ１１は、ＩｏＴデバイス１０１からＫＶＳクラスタ１２へのデータの登録要求を受け付ける登録受付ＡＰＩ（Application Programming Interface）として機能してよい。なお、ストアハンドラ１１は、ストアハンドラ１１の処理負荷等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

図２に示すように、ストアハンドラ１１は、例示的に、登録受付ＡＰＩの一例であるストア受付部１１ａと、格納部１１ｂと、を備えてよい。

ストア受付部１１ａは、例えば、ＩｏＴデバイス１０１から登録要求（格納要求）を受信し、登録要求からＫＶＳクラスタ１２に登録する登録対象のデータ（以下、「エントリ」と表記する場合がある）を含むエントリ情報を引数として取得する。そして、ストア受付部１１ａは、取得したエントリ情報を格納部１１ｂに出力する。

図３は、エントリ情報の一例を示す図である。上述のように、一実施形態においては、ＫＶＳシステム１は、ＩｏＴデバイス１０１から、データとして、観測結果等のキーバリューを受信する。従って、一実施形態において、エントリにはキーバリューが含まれる。

以下の説明において、ＩｏＴデバイス１０１から受信したオリジナルの「キー」、「バリュー」、「キーバリュー」を、それぞれ、「オリジナルキー」、「オリジナルバリュー」、「オリジナルキーバリュー」と表記する場合がある。

ここで、図３に示すように、エントリ情報には、タイムスタンプ（timestamp）が含まれてよい。タイムスタンプには、ＩｏＴデバイス１０１がデータを取得した時刻又は送信した時刻がＩｏＴデバイス１０１により設定されてよい。なお、タイムスタンプには、上記時刻に加えて又は代えて、ＫＶＳシステム１（ストアハンドラ１１）がデータを受信した時刻又はＫＶＳクラスタ１２への格納時刻等がストア受付部１１ａにより設定されてもよい。

格納部１１ｂは、ストア受付部１１ａが受け付けたエントリ情報に基づいて、ＫＶＳクラスタ１２にエントリを登録する。

例えば、格納部１１ｂは、受け付けたエントリ情報に含まれる、ＫＶＳクラスタ１２への登録対象のエントリに対して、ユニークＩＤ（ＵＩＤ；Unique Identifier）を付与してよい。ＵＩＤは、ＫＶＳシステム１（例えばＫＶＳクラスタ１２）において固有のＩＤであり、「識別情報」の一例である。

一例として、格納部１１ｂは、ＵＩＤマネージャ１３に対してＵＩＤの発行を依頼し、発行されたＵＩＤを登録対象のエントリ、換言すればオリジナルキーバリューに割り当てる（対応付ける）。なお、ＩｏＴデバイス１０１が一定時間ごとに登録要求を送信する場合のように、エントリ情報には、オリジナルキーバリューの複数のセットが含まれることがある。この場合、格納部１１ｂは、オリジナルキーバリューの複数のセットに対して、１つのＵＩＤを割り当ててもよいし、オリジナルキーバリューのセットごとにＵＩＤを割り当ててもよい。

なお、格納部１１ｂは、ＵＩＤの発行依頼の送信とともに、又は、ＵＩＤの発行後に、エントリ情報をＵＩＤマネージャ１３に送信してもよい。

さらに、格納部１１ｂは、ＫＶＳクラスタ１２に対して、ＵＩＤをキーとし、登録対象のエントリをバリューとしたキーバリューを送信し、後述するＫＶＳ１２ａへの当該キーバリューの格納を指示してよい。なお、格納部１１ｂからＫＶＳクラスタ１２に送信されるキー（ＵＩＤ）及びバリュー（エントリ）のうちのバリューは、ＩｏＴデバイス１０１から受信した「オリジナルキーバリュー」となる。

このように、ストアハンドラ１１は、ＫＶＳ１２ａに対するデータの格納要求を受け付け、当該データに割り当てられた識別情報と当該データとをＫＶＳ１２ａに格納する格納処理部の一例である。

ＫＶＳクラスタ１２は、キーとバリューとを対応付けて格納するキーバリューストアの一例であるＫＶＳ１２ａを備え、ＫＶＳ１２ａに対するデータのリード及びライトの制御、ＫＶＳ１２ａの管理等を行なう。

なお、ＫＶＳクラスタ１２は、分散ハッシュテーブル（ＤＨＴ）等により、例えばＫＶＳクラスタ１２の処理負荷やＫＶＳ１２ａでのデータの記憶容量（或いは空き容量）等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

ＫＶＳクラスタ１２は、例えば、格納部１１ｂからキーバリューの格納指示を受けると、ＫＶＳ１２ａに対するキーバリューの格納を行なう。

図４は、ＫＶＳ１２ａに格納されるデータの一例を示す図である。図４に例示するように、ＫＶＳクラスタ１２は、格納指示に係るキーであるＵＩＤと、格納指示に係るバリューであるエントリ（オリジナルキーバリュー）と、をＫＶＳ１２ａに格納する。

ＫＶＳ１２ａは、ＫＶＳクラスタ１２を実現するノードが有する記憶領域により実現されてよい。なお、図４では、ＫＶＳ１２ａに格納されるデータを、便宜上、テーブル形式として示すが、これに限定されるものではない。ＫＶＳクラスタ１２は、例えば、ＤＢ形式やＸＭＬ（eXtensible Markup Language）形式等の種々の形態で、ＫＶＳ１２ａにデータを記憶してよい。

また、ＫＶＳクラスタ１２は、後述するクエリハンドラ１４、ＩＤＸマネージャ１５、又は、インデクサ１６から、検索キーとしてＵＩＤを指定した抽出要求（検索要求）を受信すると、当該ＵＩＤに対応するバリューであるエントリをＫＶＳ１２ａから抽出する。そして、ＫＶＳクラスタ１２は、抽出したエントリを抽出要求元に応答する。

ＵＩＤマネージャ１３は、ＵＩＤの発行、及び、ＵＩＤリスト１３ａの管理を行なう管理部の一例である。例えば、ＵＩＤマネージャ１３は、ＵＩＤリスト１３ａの管理において、ＵＩＤリスト１３ａへのデータの追加、ＵＩＤリスト１３ａからのデータの抽出、等を行なう。

なお、ＵＩＤマネージャ１３は、例えばＵＩＤマネージャ１３の処理負荷等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

ＵＩＤマネージャ１３は、格納部１１ｂからのＵＩＤの発行依頼に応じて、ＫＶＳシステム１（ＫＶＳ１２ａ）内で一意のＵＩＤを、格納部１１ｂに発行する。ＵＩＤの決定は、所定の規則に従った演算や所定のリストからの抽出等、既知の種々の手法により行なうことが可能である。

また、ＵＩＤマネージャ１３は、格納部１１ｂからエントリを受信すると、受信したエントリ内のオリジナルキー及びタイムスタンプと、当該エントリに対して発行したＵＩＤとに基づくリストを作成し、ＵＩＤリスト１３ａに格納する。

図５は、ＵＩＤリスト１３ａに格納されるデータの一例を示す図である。ＵＩＤリスト１３ａは、ＵＩＤマネージャ１３を実現するノードが有する記憶領域に記憶される情報であってよい。なお、図５では、ＵＩＤリスト１３ａを、便宜上、テーブル形式として示すが、これに限定されるものではなく、ＵＩＤリスト１３ａは、ＤＢ形式や配列、ＸＭＬ形式等の種々の形態でノードの記憶領域に記憶されてよい。

ＵＩＤリスト１３ａは、各タイムスロット（ＴＳ；time_slot）において受信したエントリのＵＩＤを管理する情報である。ＴＳは、単位時間或いは一定期間の一例であり、各ＴＳは、一定の時刻範囲（開始時刻〜終了時刻）に対応してよい。１つのＴＳは、例えば、１時間〜数日等であってよく、一実施形態では、「１日」であるとする。なお、ＴＳの長さ（ＴＳ長、ＴＳ区間）は、後述するように可変であってもよい。

ＵＩＤリスト１３ａは、例えば、オリジナルキーごとにリストを有してよい。図５の例において、“key_x”、“key_y”、“key_z”、…、は、オリジナルキーを示す。図５の例において、オリジナルキー“key_x”に着目すると、“time_slot=1”の期間において受信したエントリであって、オリジナルキー“key_x”を含むエントリのＵＩＤは、“66ea7427”、“15f2883e”、“fd41a09c”であることがわかる。

このように、ＵＩＤリスト１３ａによれば、特定のオリジナルキーを含むエントリをＫＶＳ１２ａから検索するための検索キー（ＵＩＤ）を、ＴＳ単位で特定することが可能となる。

換言すれば、ＵＩＤリスト１３ａは、単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報の一例である。

例えば、ＵＩＤマネージャ１３は、格納部１１ｂから受信したエントリ情報に含まれるオリジナルキーを参照してよい。また、ＵＩＤマネージャ１３は、格納部１１ｂから受信したエントリ情報に含まれるタイムスタンプを参照し、タイムスタンプが属するＴＳを特定してよい。そして、ＵＩＤマネージャ１３は、ＵＩＤリスト１３ａにおいて、参照したオリジナルキー及び特定したＴＳに対応するリストを特定し、当該リストに対して、エントリに割り当てられたＵＩＤを設定（格納）する。

なお、上記の説明では、タイムスタンプが示す時刻を、ストア受付部１１ａがＩｏＴデバイス１０１からエントリを受信した時刻として扱っている。これは、例えば、タイムスタンプにＩｏＴデバイス１０１がデータを取得した時刻又は送信した時刻が設定されている場合、タイムスタンプが示す時刻とエントリを受信した時刻との差が、これらを同一視できる程度に小さいものと仮定したためである。

しかしながら、これに限定されるものではなく、一実施形態では、上記「差」が生じないように、ストア受付部１１ａは、例えば、上述したように、ＩｏＴデバイス１０１からデータを受信した時刻を、受信したデータのタイムスタンプに設定してもよい。

クエリハンドラ１４は、ＫＶＳクラスタ１２に対するデータの検索の制御を行なう検索受付部の一例である。例えば、クエリハンドラ１４は、サーバ１０５からＫＶＳクラスタ１２へのデータの検索要求を受け付ける検索受付ＡＰＩとして機能してよい。なお、クエリハンドラ１４は、クエリハンドラ１４の処理負荷等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

クエリハンドラ１４は、例示的に、検索受付ＡＰＩの一例であるクエリ受付部１４ａと、検索部１４ｂと、を備えてよい。

例えば、クエリ受付部１４ａは、サーバ１０５から検索要求を受信し、検索要求から、ＫＶＳクラスタ１２から検索する条件である検索条件を含むエントリ検索情報を引数として取得し、取得したエントリ検索情報を検索部１４ｂに出力する。

図６は、エントリ検索情報の一例を示す図である。図６に例示するように、エントリ検索情報には、検索条件として、時刻範囲（timerange）、並びに、検索キー及び検索バリューが含まれてよい。時刻範囲には、検索対象とする開始時刻及び終了時刻の少なくとも一方が含まれてよい。検索キー及び検索バリューには、検索対象とするオリジナルキー、検索対象とするオリジナルバリュー、及び、検索対象とするオリジナルバリューの範囲、の少なくとも１つが含まれてよい。なお、オリジナルバリューの範囲には、検索対象とする開始値及び終了値の少なくとも一方が含まれてよい。

検索部１４ｂは、クエリ受付部１４ａから受信したエントリ検索情報に基づいて、ＫＶＳクラスタ１２に対してエントリの検索要求を送信し、ＫＶＳクラスタ１２から検索結果を受信すると、検索要求の送信元であるサーバ１０５に対して、検索結果を応答する。

例えば、検索部１４ｂは、検索条件に含まれる時刻範囲に基づき、検索対象となるＴＳを特定してよい。そして、検索部１４ｂは、ＩＤＸマネージャ１５に対して、エントリ検索情報、及び、特定したＴＳを含む、ＵＩＤリストの取得要求を送信してよい。検索部１４ｂは、ＩＤＸマネージャ１５からＵＩＤリストを受信すると、ＫＶＳクラスタ１２に対して、受信したＵＩＤリストを含む、バリュー（オリジナルキーバリュー）の検索要求を送信してよい。検索部１４ｂは、ＫＶＳクラスタ１２から、ＵＩＤリストにより特定されるキー（ＵＩＤ）に対応するバリュー（オリジナルキーバリュー）を、検索結果として受信する。

ＩＤＸマネージャ１５は、ＩＤＸ作成状況１５ａ及びＩＤＸ１５ｂを管理し、クエリハンドラ１４からの取得要求に応じた処理、ＩＤＸ１５ｂからのＩＤＸデータの抽出、インデクサ１６の動作の制御、等を行なう。

なお、ＩＤＸマネージャ１５は、例えばＩＤＸマネージャ１５又はインデクサ１６の処理負荷等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

図７は、ＩＤＸ作成状況１５ａに格納されるデータの一例を示す図であり、図８は、ＩＤＸ１５ｂに格納されるデータの一例を示す図である。ＩＤＸ作成状況１５ａ及びＩＤＸ１５ｂは、それぞれ、ＩＤＸマネージャ１５を実現するノードが有する記憶領域に記憶される情報であってよい。なお、図７及び図８では、ＩＤＸ作成状況１５ａ及びＩＤＸ１５ｂを、便宜上、テーブル形式として示すが、これに限定されるものではない。例えば、ＩＤＸ作成状況１５ａ及びＩＤＸ１５ｂは、それぞれ、ＤＢ形式や配列、ＸＭＬ形式、ビットマップ形式等の種々の形態でノードの記憶領域に記憶されてよい。

ＩＤＸ作成状況１５ａは、オリジナルキーごとのＩＤＸデータの作成状況を管理するための情報である。図７に示すように、ＩＤＸ作成状況１５ａには、例示的に、ＴＳごと、且つ、オリジナルキーごとに、ＩＤＸデータの有効又は無効が設定されてよい。一例として、図７に示すように、“key_x”の“time_slot（time_slot_id）”=“1”及び“5”には、ＩＤＸデータが有効である（作成されている）ことを示す“1”（又は“true”）が設定される。また、“key_x”の“time_slot（time_slot_id）”=“2”、“3”及び“4”には、ＩＤＸデータが無効である（作成されていない）ことを示す“0”（又は“false”）が設定される。

ここで、一実施形態では、ＩＤＸデータの作成は、チャンク（chunk）単位で行なわれてよい。「チャンク」は、連続する複数（図７の例では５つ）のＴＳを一単位として束ねた所定期間の一例である。これは、ＩｏＴデバイス１０１で収集されるデータに対する検索要求には、局所性、例えば時間的局所性があるためである。

図７の例では、“key_x”の“time_slot”=“1”及び“5”に“1”が設定されているため、ＩＤＸ１５ｂには、“chunk（chunk_id）”=“1”の期間（“time_slot”=“1”〜“5”の期間）における“key_x”のＩＤＸデータが作成されている。なお、ＩＤＸ作成状況１５ａにおいて、チャンクに属する全てのＴＳに“0”が設定されている場合、ＩＤＸ１５ｂには、当該チャンクのＩＤＸデータは作成されない。

このように、ＩＤＸ作成状況１５ａは、チャンクに含まれる各ＴＳに受信したデータに関するＩＤＸデータが当該チャンクのＩＤＸ１５ｂに含まれるか否かを示す作成管理情報の一例である。

チャンク単位でＩＤＸデータを作成することにより、ＴＳ単位でＩＤＸデータを作成するよりも、ＩＤＸ１５ｂ内のＩＤＸツリー数の増加を抑制することができるとともに、ＩＤＸ１５ｂの走査（参照）効率を高めることができる。

なお、チャンクの長さ（チャンク長、チャンク区間）は、可変であってもよい。例えば、チャンクごとに、内包するＴＳ数が異なるように設定されてもよい。或いは、上述のようにＴＳ長が可変に設定されることで、チャンク長が調整されてもよい。又は、チャンク長及びＴＳ長の双方が可変に設定されてもよい。チャンク長、ＴＳ長の調整（増減）は、ＩＤＸマネージャ１５により制御されてよい。

以上のことから、図７に示す例では、ＩＤＸ１５ｂに含まれるＩＤＸデータのうち、チャンク“1”における“key_x”のＩＤＸデータは、“time_slot”=“1”及び“5”の期間に受信したエントリを含むことを意味する。換言すれば、ＩＤＸ１５ｂに含まれるＩＤＸデータのうち、チャンク“1”における“key_x”のＩＤＸデータは、“time_slot”=“2”〜“4”の期間に受信したエントリを含まないことを意味する。

図８に示すように、一実施形態に係るＩＤＸ１５ｂは、１つのオリジナルキーに対して、チャンク単位でＩＤＸデータを含んでよい。なお、図８の例では、“key”、“chunk（chunk_id）”及び“index”のセットがＩＤＸデータに対応する。“index”には、オリジナルバリューから当該オリジナルバリューに割り当てられた（対応付けられた）ＵＩＤを探索するためのツリー（ＩＤＸツリー）が設定される。ＩＤＸツリーのデータ構造は、例えば、ＲＤＢＭＳのＩＤＸツリーと同様であってよい。

なお、ＩＤＸマネージャ１５は、ＩＤＸ１５ｂの利用状況を、例えばＬＲＵ（Least Recently Used）アルゴリズム等により管理してよく、ＩＤＸ１５ｂのサイズの要件等に合わせて、チャンク単位でＩＤＸデータを削除してもよい。

ＩＤＸマネージャ１５は、クエリハンドラ１４からＵＩＤリストの取得要求を受信すると、ＩＤＸ作成状況１５ａを参照し、エントリ検索情報に含まれる検索キー及び時刻範囲に基づき、ＵＩＤリストを抽出するためのＩＤＸデータの有無を判定してよい。

ＩＤＸマネージャ１５は、ＵＩＤリストを抽出するためのＩＤＸデータが作成されていないと判定した場合、インデクサ１６とともに、未作成分のＩＤＸデータの作成処理（ＩＤＸ作成処理）を行なう。換言すれば、ＩＤＸマネージャ１５は、検索要求で指定された時刻に対応するＴＳに受信したデータに関するＩＤＸデータがＩＤＸ１５ｂに含まれない場合に、ＩＤＸ作成処理により当該ＩＤＸデータをＩＤＸ１５ｂに追加するのである。

なお、ＩＤＸマネージャ１５は、ＩＤＸ作成処理が完了した場合、ＩＤＸ作成状況１５ａにおける、ＩＤＸデータを作成したＴＳ、且つ、ＩＤＸデータを作成した検索キー（オリジナルキー）に、有効を示す“1”を設定してよい。

ＩＤＸマネージャ１５は、ＩＤＸデータが作成されていると判定した場合、又は、ＩＤＸ作成処理を行なった場合、検索条件に含まれる全ての検索キーに対して、ＩＤＸ１５ｂを走査（参照）し、検索条件に該当する１以上のエントリのＵＩＤを取得（抽出）する。

そして、ＩＤＸマネージャ１５は、取得したＵＩＤのリスト（ＵＩＤリスト）を、取得要求の応答としてクエリハンドラ１４に送信する。

インデクサ１６は、ＩＤＸマネージャ１５とともに、以下のＩＤＸ作成処理を行なう。なお、インデクサ１６は、例えばＩＤＸマネージャ１５又はインデクサ１６の処理負荷等に応じてノードを増減可能とする、スケールアウト機構を有してよい。

ＩＤＸ作成処理において、ＩＤＸマネージャ１５は、ＩＤＸデータの作成対象となるＴＳにおいて、ＩＤＸデータの作成対象となる検索キーを持つエントリ群のＵＩＤリストを、例えばインデクサ１６を介して、ＵＩＤマネージャ１３から取得する。そして、ＩＤＸマネージャ１５は、インデクサ１６に対して、取得したＵＩＤリストに基づくＩＤＸデータの作成を指示する。

インデクサ１６は、ＩＤＸマネージャ１５からの指示に応じて、ＵＩＤリストに含まれるＵＩＤを検索キーとしてＫＶＳ１２ａからエントリを検索するための検索要求を、ＫＶＳクラスタ１２に送信する。

そして、インデクサ１６は、ＫＶＳクラスタ１２から検索結果のエントリを受信し、受信したエントリに基づき、ＩＤＸ１５ｂにＩＤＸデータを作成（追加）する。これにより、ＩＤＸ作成処理が完了する。

このように、ＩＤＸマネージャ１５及びインデクサ１６は、時刻が指定された検索要求と、ＵＩＤリスト１３ａと、ＫＶＳ１２ａが格納するデータと、に基づいて、ＫＶＳ１２ａのＩＤＸ１５ｂを作成する作成部の一例である。この作成部は、検索要求で指定された時刻に対応する識別情報をＵＩＤリスト１３ａから抽出し、抽出した識別情報に対応するデータをＫＶＳ１２ａから抽出して、抽出した識別情報及びデータに基づき、ＩＤＸ１５ｂのＩＤＸデータを作成するのである。

以上のように、一実施形態に係るＫＶＳシステム１は、エントリの検索要求を受信した場合であって、検索条件に対応するＩＤＸデータが作成されていない場合に、ＩＤＸ作成処理を行なう。

これにより、一般的なＲＤＢＭＳで作成されるＩＤＸを利用する場合のように、ＫＶＳへのエントリ格納時にＩＤＸを作成（更新）する従来の手法と比較して、以下の利点がある。

・ＩｏＴデバイス１０１から高頻度でＫＶＳ１２ａに対してキーバリュー群の書き込みが発生したとしても、ＫＶＳ１２ａへのエントリの格納時にＩＤＸ作成処理が行なわれないため、ＩＤＸ作成処理の処理負荷や処理時間の増加を抑制できる。従って、ＫＶＳ１２ａへのエントリの格納処理自体の処理負荷や処理時間の増加を抑制できる。

・ＩＤＸマネージャ１５及びインデクサ１６は、サーバ１０５からの検索条件で指定された検索キーに係るＩＤＸデータを、検索要求に応じて作成するため、不要なＩＤＸデータを作成せずに済み、ＩＤＸ１５ｂに使用される記憶領域のサイズの増加を抑制できる。

・チャンク単位でＩＤＸデータが管理され、使用されないＩＤＸデータはチャンク単位で削除されるため、ＩＤＸ１５ｂに使用される記憶領域のサイズの増加を抑制できる。

このように、一実施形態に係るＫＶＳシステム１によれば、ＫＶＳ１２ａに格納されたデータに対するＩＤＸの作成処理のリソース量を低減させることができる。従って、例えば、ＫＶＳ１２ａへのキーバリュー群の登録量に依存しない処理時間及び処理性能によって、ＫＶＳ１２ａに対するキーバリュー群の格納及び検索等が可能となる。

なお、ここまで、一実施形態に係るＫＶＳシステム１は、エントリの検索要求を受信した場合であって、検索条件に対応するＩＤＸデータが作成されていない場合に、ＩＤＸ作成処理を行なうものとして説明したが、これに限定されるものではない。

ＫＶＳシステム１では、例えば、ＫＶＳ１２ａに対してＵＩＤ及びエントリが格納されるストアのタイミングで、ＩＤＸ作成処理が行なわれることが許容されてもよい。

一例として、ＫＶＳシステム１は、検索部１４ｂにキーバリューを格納する際に、ＩＤＸ作成フラグを参照し、ＩＤＸ作成フラグが有効か否かを判定してよい。そして、ＫＶＳシステム１は、ＩＤＸ作成フラグが有効である場合に、ＩＤＸマネージャ１５に対してＩＤＸ作成処理の実行を指示してもよい。

ＩＤＸ作成フラグは、ＫＶＳ１２ａにおけるキーバリューの格納のタイミングで（換言すれば、格納の都度）、ＩＤＸ作成処理を行なうか否かを指定する情報であり、例えば、ＫＶＳシステム１のユーザや管理者等により予めＫＶＳシステム１に設定されてよい。ＩＤＸ作成フラグの参照及び判定は、ストアハンドラ１１、ＫＶＳクラスタ１２、又は、ＩＤＸマネージャ１５等が行なってもよい。

〔１−３〕スケールアウトに係る構成例
ここまで、ＫＶＳシステム１における、ＫＶＳ１２ａへのエントリの格納、ＩＤＸデータの作成、及び、ＫＶＳ１２ａからの検索、の処理に着目して説明を行なった。一実施形態に係るＫＶＳシステム１は、上述した構成に加えて、以下のような構成を備えることにより、スケールアウトを容易に実現することが可能である。

以下、図９〜図１２を参照して、ＫＶＳシステム１におけるスケールアウトの機能に着目した構成例を説明する。

図９は、ＫＶＳクラスタ１２に対するエントリの登録処理に係る構成例を示すブロック図である。なお、図９の例では、ＫＶＳシステム１におけるクエリハンドラ１４、ＩＤＸマネージャ１５、及び、インデクサ１６の図示、並びに、ＫＶＳクラスタ１２におけるＫＶＳ１２ａ及びＵＩＤマネージャ１３におけるＵＩＤリスト１３ａの図示を省略している。

図９に示すように、ＫＶＳシステム１は、図２に示す構成に加えて、ロードバランサ１７を備えてよい。また、ストアハンドラ１１、ＫＶＳクラスタ１２、及びＵＩＤマネージャ１３としての機能は、それぞれ、複数（図９の例では３台）のノード２１、複数（図９の例では４台）のノード２２、及び複数（図９の例では３台）のノード２３、により実現されてよい。さらに、ＵＩＤマネージャ１３は、管理部２を備えてよい。

ロードバランサ１７は、ＩｏＴデバイス１０１から受信した登録要求を、複数のノード２１の各々の処理負荷（Load）等に応じて、いずれかのノード２１に送信する、負荷分散（ロードバランス）を行なう。

複数のノード２１の各々は、図２に示すストアハンドラ１１としての機能を備えてよい。すなわち、いずれのノード２１がロードバランサ１７から登録要求を受信したとしても、上述したストアハンドラ１１としての処理を行なうことができる。

複数のノード２２は、ＤＨＴ等によるスケールアウト機構を有し、複数のノード２２により、図２に示すＫＶＳクラスタ１２及びＫＶＳ１２ａの機能が実現される。

複数のノード２３の各々は、図２に示すＵＩＤマネージャ１３の機能を備えてよく、また、複数のノード２３間でＵＩＤリスト１３ａを分散して管理してよい。

管理部２は、複数のノード２３の各々による、ＵＩＤリスト１３ａに対するＵＩＤの登録（更新）処理の処理負荷等に応じて、登録（更新）処理を行なう（担当する）ノード２３を決定する。このように、管理部２は、複数のノード２３の負荷分散を行なう。なお、管理部２自体も、１つ又は複数のノードであってよい。

管理部２は、図９に示すように、ノード２３を管理するためのノードリスト２ａを管理してよい。例えば、管理部２は、オリジナルキーごとに、ＵＩＤリストを記録するノード２３を割り当ててよい。

図１０は、ノードリスト２ａの一例を示す図である。図１０に示すように、ノードリスト２ａは、オリジナルキーのＵＩＤを記録するノード２３を管理する情報であってよい。なお、１つのオリジナルキーに対して、複数のノード２３が割り当てられてもよい。

図１０の例では、オリジナルキー“key_x”に対して、複数のノード２３のうちのノードＡ及びノードＢ（図１０参照）が割り当てられており、“key_y”に対して、ノードＢが割り当てられている。

このように、一実施形態に係るＫＶＳシステム１によれば、エントリの登録処理に係るストアハンドラ１１、ＫＶＳクラスタ１２、及び、ＵＩＤマネージャ１３のそれぞれにおいて負荷分散が可能な構成を採用することができる。

従って、例えば、ストアハンドラ１１によるストア受付部１１ａとしての機能を、複数のノード２１（換言すれば、複数のホスト）により並列に実行可能となる。また、ストアハンドラ１１による格納部１１ｂとしての機能を、複数のノード２１により並列に実行可能となる。

また、ＫＶＳ１２ａにおいては、ノード２２（ホスト）を追加することにより、略リニアにライト性能及びリード性能を向上させることが可能となる。

さらに、例えば、ＵＩＤリスト１３ａに対する、ＴＳごとのエントリのＵＩＤの記録処理を、複数のノード２３（換言すれば、複数のホスト）により並列に実行可能となる。

これにより、ＫＶＳシステム１のスケールアウトを容易に実現することができ、ＫＶＳに対するデータの格納性能を、スケールアウトの規模に比例して向上させることが可能となる。

図１１は、ＫＶＳクラスタ１２に対するエントリの検索処理に係る構成例を示すブロック図である。なお、図１１の例では、ＫＶＳシステム１におけるストアハンドラ１１の図示、並びに、ＫＶＳクラスタ１２におけるＫＶＳ１２ａ、ＵＩＤマネージャ１３におけるＵＩＤリスト１３ａ、及び、ＩＤＸマネージャ１５におけるＩＤＸ１５ｂの図示を省略している。

図１１に示すように、ＫＶＳシステム１は、図２及び図９に示す構成に加えて、ロードバランサ１８を備えてよい。また、クエリハンドラ１４、ＩＤＸマネージャ１５、及びインデクサ１６としての機能は、それぞれ、複数（図１１の例では４台）のノード２４、複数（図１１の例では３台）のノード２５、及び複数（図１１の例では３台）のノード２６、により実現されてよい。さらに、ＩＤＸマネージャ１５は、管理部３を備えてよい。

ロードバランサ１８は、サーバ１０５から受信した検索要求を、複数のノード２４の各々の処理負荷等に応じて、いずれかのノード２４に送信する、負荷分散（ロードバランス）を行なう。なお、例えば、ロードバランサ１７及び１８は、同一の情報処理装置又は通信装置、例えばノードにより実現されてもよい。

複数のノード２４の各々は、図２に示すクエリハンドラ１４としての機能を備えてよい。すなわち、いずれのノード２４がロードバランサ１８から検索要求を受信したとしても、上述したクエリハンドラ１４としての処理を行なうことができる。

複数のノード２５の各々は、図２に示すＩＤＸマネージャ１５の機能を備えてよく、また、複数のノード２５間でＩＤＸ１５ｂを分散して管理してよい。

複数のノード２６の各々は、図２に示すインデクサ１６の機能を備えてよい。すなわち、いずれのノード２６によっても、ＩＤＸ作成処理を行なうことができる。

管理部３は、複数のノード２５及び２６の各々による、ＩＤＸ作成処理の処理負荷等に応じて、ＩＤＸデータの管理やＩＤＸ作成処理を行なう（担当する）ノード２５及びノード２６を決定する。このように、管理部３は、複数のノード２５及び複数のノード２６の負荷分散を行なう。なお、管理部３自体も、１つ又は複数のノードであってよい。

例えば、管理部３は、チャンクごと、且つ、オリジナルキーごとに、ＩＤＸデータの管理やＩＤＸ作成処理を行なうノード２５及びノード２６を割り当ててよい。管理部３は、図１１に示すように、ノード２５及びノード２６を管理するためのインデクサリスト３ａを管理してよい。

図１２は、インデクサリスト３ａの一例を示す図である。図１２に示すように、インデクサリスト３ａは、チャンク単位で、各オリジナルキーのＩＤＸデータを管理するノード２５及びノード２６を管理する情報であってよい。なお、１組のノード２５及びノード２６に対して、複数のチャンク及び複数のオリジナルキーが割り当てられてもよい。

なお、一実施形態において、ノード２５とノード２６とは、１対１、１対他、又は、他対１のいずれの対応であってもよい。図１２の例では、ノード２５とノード２６とは、１対１に対応するものとするものとし、複数のノード２５のうちのノードＡ、ノードＢ、ノードＣは、それぞれ、複数のノード２６のうちのノードＡ、ノードＢ、ノードＣ（いずれも図示省略）に対応するものとする。

図１２の例では、オリジナルキー“key_x”、“chunk_id”=“1”に対して、ノードＡが割り当てられており、“key_x”、“chunk_id”=“2”に対して、ノードＢが割り当てられている。また、“key_y”、“chunk_id”=“1”に対して、ノードＢが割り当てられており、“key_y”、“chunk_id”=“2”に対して、ノードＢが割り当てられている。

このように、一実施形態に係るＫＶＳシステム１によれば、エントリの検索処理及びＩＤＸ作成処理に係るクエリハンドラ１４、ＩＤＸマネージャ１５、及び、インデクサ１６のそれぞれにおいて負荷分散が可能な構成を採用することができる。

従って、例えば、クエリハンドラ１４によるクエリ受付部１４ａとしての機能を、複数のノード２４（換言すれば、複数のホスト）により並列に実行可能となる。また、クエリハンドラ１４による検索部１４ｂとしての機能を、複数のノード２４により並列に実行可能となる。

また、例えば、ＩＤＸマネージャ１５は、各チャンクのＩＤＸデータをチャンク単位で異なるノード２５及び２６（換言すれば、ホスト）で管理することが可能となる。

これにより、ＫＶＳシステム１のスケールアウトを容易に実現することができ、ＫＶＳに対するデータの検索性能を、スケールアウトの規模に比例して向上させることが可能となる。

ここで、図１３に例示するように、一実施形態に係るＫＶＳシステム１は、図２及び図９〜図１２に示す構成に加えて、ボトルネック箇所を解析し、ボトルネック箇所に応じたスケールアウト処理の実行を制御するスケールアウト制御部１９を備えてよい。

スケールアウト制御部１９は、ＫＶＳシステム１の性能を監視する監視部の一例であり、所定のタイミングでＫＶＳシステム１におけるボトルネックを解析してよい。スケールアウト制御部１９による監視対象の「性能」としては、例えば、ストアハンドラ１１、ＵＩＤマネージャ１３、クエリハンドラ１４、ＩＤＸマネージャ１５等のノードの処理性能（例えばプロセッサやメモリの使用率や処理時間）等が挙げられる。なお、監視対象の「性能」には、例えば、ＫＶＳシステム１に対する格納要求や検索要求のリクエスト数等が含まれてもよい。

スケールアウト制御部１９は、所定のタイミングで、各種性能監視結果と、性能の種別に応じた所定の閾値とを比較し、性能が所定の閾値を超えたノードをボトルネック箇所として特定する。そして、スケールアウト制御部１９は、特定したボトルネック箇所に対して、スケールアウト処理の実行を指示する。換言すれば、スケールアウト制御部１９は、性能監視結果に基づき、ボトルネック箇所に対して、スケールアウト処理の実行トリガを送信するといえる。

一例として、スケールアウト制御部１９は、ボトルネック箇所がストアハンドラ１１又はクエリハンドラ１４である場合、ボトルネック箇所であるストアハンドラ１１又はクエリハンドラ１４に対して、ノード２１又は２４の台数を増加させる指示を送信してよい。ストアハンドラ１１又はクエリハンドラ１４は、当該指示の受信に応じて、ノード２１又は２４の台数を増加させてよい。

また、スケールアウト制御部１９は、ボトルネック箇所がＵＩＤマネージャ１３によるＵＩＤリスト１３ａの更新処理である場合、ＵＩＤマネージャ１３に対して、ノード２３の台数を増加させる指示を送信してよい。ＵＩＤマネージャ１３は、当該指示の受信に応じて、ノード２３の台数を増加させ、監視結果に基づいて、オリジナルキーごとに、ノード２３にＵＩＤリスト１３ａを分散して記憶させてよい。例えば、ＵＩＤマネージャ１３は、監視結果に基づいて、格納頻度の高いオリジナルキーのリクエスト（ＵＩＤリスト１３ａ）を、複数のノード２３に分散させてよい。

さらに、スケールアウト制御部１９は、ボトルネック箇所がＩＤＸ１５ｂの更新処理である場合、ＩＤＸマネージャ１５及び／又はインデクサ１６に対して、ノード２５及び／又は２６の台数を増加させる指示を送信してよい。ＩＤＸマネージャ１５及び／又はインデクサ１６は、当該指示の受信に応じて、ノード２５及び／又は２６の台数を増加させ、監視結果に基づいて、オリジナルキーごとに、ノード２５及び／又は２６にＩＤＸ１５ｂを分散して記憶させてよい。また、ＩＤＸマネージャ１５は、検索頻度の高いキーのチャンク長を小さくしてよい。

このように、スケールアウト制御部１９は、監視の結果に基づいて、ノード２１、ノード２２、ノード２３、ノード２４、並びに、ノード２５及び２６、のうちの少なくとも１つのノード数を変更する制御を行なう。

以上のように、スケールアウト制御部１９によれば、性能監視結果に応じて、ＫＶＳシステム１のスケールアウトを柔軟に実行することができる。また、ボトルネック箇所に応じてスケールアウトが実行されるため、ＨＷ資源やＮＷ資源を効率的に使用することができる。

なお、スケールアウト制御部１９は、例えば、図２に示すストアハンドラ１１、ＵＩＤマネージャ１３、クエリハンドラ１４、及び、ＩＤＸマネージャ１５、の少なくとも１つの機能として実装されてもよい。すなわち、ストアハンドラ１１、ＵＩＤマネージャ１３、クエリハンドラ１４、及び、ＩＤＸマネージャ１５の少なくとも１つが、スケールアウト制御部１９の機能を備えてもよい。或いは、スケールアウト制御部１９は、ノード２１〜２６（図９及び図１１参照）とは異なる１以上のノードにより実現されてもよい。

〔１−４〕動作例
次に、図１４〜図２３を参照して、上述の如く構成された一実施形態に係るＫＶＳシステム１の動作例を説明する。

〔１−４−１〕全体の処理
まず、図１４〜図１６を参照して、ＫＶＳシステム１による全体の処理を説明する。

（エントリの格納要求を受信した場合）
図１４に例示するように、ストアハンドラ１１のストア受付部１１ａは、ＩｏＴデバイス１０１からエントリの格納要求を受信すると（ステップＡ１）、エントリ情報を引数として取得し、エントリ情報を格納部１１ｂに出力する。

格納部１１ｂは、エントリ情報に基づき、ＫＶＳクラスタ１２に対するエントリ格納処理を行ない（ステップＡ２）、処理が終了する。

なお、ストアハンドラ１１又はＫＶＳクラスタ１２は、エントリ格納処理において、ＩＤＸ作成フラグを参照し、ＩＤＸ作成フラグが有効である場合には、ＩＤＸマネージャ１５に対してＩＤＸ作成処理の実行を指示してもよい（ステップＡ３）。ＩＤＸマネージャ１５がＩＤＸ作成フラグの参照を行なってもよい。

（エントリの検索要求を受信した場合）
図１５に例示するように、クエリハンドラ１４のクエリ受付部１４ａは、サーバ１０５からエントリの検索要求を受信すると（ステップＢ１）、エントリ検索情報を引数として取得し、エントリ検索情報を検索部１４ｂに出力する。

検索部１４ｂは、エントリ検索情報に基づき、ＫＶＳクラスタ１２からのエントリ検索処理を行ない（ステップＢ２）、処理が終了する。

なお、エントリ検索処理において、ＩＤＸマネージャ１５及びインデクサ１６が、ＩＤＸ作成処理を行なう場合がある（ステップＢ３）。

（スケールアウト処理を行なう場合）
図１６に例示するように、スケールアウト制御部１９は、ＫＶＳシステム１の性能監視を行ない、性能の監視結果に基づき、ボトルネック箇所を特定する。そして、スケールアウト制御部１９は、特定したボトルネック箇所に対して、スケールアウト処理の実行トリガを送信する。

ボトルネック箇所は、上述のようにしてスケールアウト制御部１９から送信された実行トリガを受信すると（ステップＣ１）、スケールアウト処理を実行し（ステップＣ２）、処理が終了する。ボトルネック箇所としては、例えば、ストアハンドラ１１、ＵＩＤマネージャ１３、クエリハンドラ１４、又は、ＩＤＸマネージャ１５が挙げられる。

〔１−４−２〕エントリ格納処理
次に、図１７及び図１８を参照して、図１４のステップＡ２に示すエントリ格納処理の動作例を説明する。

図１７に例示するように、格納部１１ｂは、ストア受付部１１ａからエントリ情報を受信すると、ＵＩＤマネージャ１３に対して、ＵＩＤの発行を依頼する。格納部１１ｂは、発行されたＵＩＤを登録対象のエントリに付与する（ステップＡ１１）。

図１８の例では、登録受付ＡＰＩとしてのストア受付部１１ａが、タイムスタンプ“112233”、オリジナルキー“hoge”：オリジナルバリュー：“huga”、オリジナルキー“foo”：オリジナルバリュー：“10.5”、のエントリ情報を取得する（符号Ｉ参照）。そして、格納部１１ｂは、当該エントリ情報に対して、ＵＩＤマネージャ１３から発行されたＵＩＤ“a058b76a”を付加する（符号II参照）。

そして、格納部１１ｂは、ＫＶＳクラスタ１２に対して、ＵＩＤをキーとし、エントリ情報に含まれるオリジナルキーバリューをバリューとしたキーバリューの格納指示を送信する。ＫＶＳクラスタ１２は、格納指示に応じて、キーバリューをＫＶＳ１２ａに格納し（ステップＡ１２；図１８の符号III参照）、処理が終了する。

また、格納部１１ｂは、ステップＡ１１と並行して、又は、ステップＡ１１の後に、エントリ情報をＵＩＤマネージャ１３に送信する。ＵＩＤマネージャ１３は、現在のＴＳで識別されるＵＩＤリスト１３ａに、エントリ情報に対して発行したＵＩＤの情報を追記し（ステップＡ１３）、処理が終了する。図１８の例では、ＵＩＤマネージャ１３は、ＴＳ“1122”、オリジナルキー“hoge”、ＵＩＤ“a058b76a”の情報と、ＴＳ“1122”、オリジナルキー“foo”、ＵＩＤ“a058b76a”の情報と、を、それぞれＵＩＤリスト１３ａに追加する（図１８の符号IV参照）。

さらに、例えば格納部１１ｂは、ＩＤＸ作成フラグを参照し、ＩＤＸ作成フラグが有効か否か、すなわち、即時にＩＤＸ作成処理を行なうか否か、を判定する（ステップＡ１４）。ＩＤＸ作成フラグが無効の場合（ステップＡ１４でＮｏ）、処理が終了する。

ＩＤＸ作成フラグが有効の場合（ステップＡ１４でＹｅｓ）、格納部１１ｂは、ＩＤＸマネージャ１５に対してＩＤＸ作成処理の実行を指示する。ＩＤＸマネージャ１５は、インデクサ１６とともにＩＤＸ作成処理を行ない（ステップＡ１５；図１８の符号Ｖ参照）、処理が終了する。

なお、ステップＡ１２、Ａ１３、並びに、Ａ１４及びＡ１５、の処理は、並行して（換言すれば、互いに非同期に）実行されてよい。

〔１−４−３〕エントリ検索処理
次に、図１９〜図２１を参照して、図１５のステップＢ２に示すエントリ検索処理の動作例を説明する。

図１９に例示するように、検索部１４ｂは、クエリ受付部１４ａからエントリ検索情報を受信すると、エントリ検索情報に含まれる検索条件の時刻範囲に該当するＴＳを特定する（ステップＢ１１）。そして、検索部１４ｂは、ＩＤＸマネージャ１５に対して、エントリ検索情報及び特定したＴＳを含む、ＵＩＤリストの取得要求を送信する。

次いで、ＩＤＸマネージャ１５は、該当ＴＳにおいて、検索条件が含む検索キーのＩＤＸデータが作成済か否かを判定する。

図２０の例では、検索受付ＡＰＩとしてのクエリ受付部１４ａが、時刻範囲“112210”〜“112240”、検索キー“hoge”：検索バリュー“fuga”、検索キー“foo”：検索バリュー“9.0”〜“12.0”のエントリ検索情報を取得した場合を想定する（符号Ｉ参照）。この場合、ＩＤＸマネージャ１５は、ＩＤＸ作成状況１５ａを参照して、ＴＳ“1122”における、検索キー“hoge”及び“foo”のそれぞれのＩＤＸデータの作成有無を判定する（符号II参照）。

ＩＤＸデータが作成済の場合（ステップＢ１２でＹｅｓ）、処理がステップＢ１４に移行する。一方、ＩＤＸデータが未作成の場合（ステップＢ１２でＮｏ）、ＩＤＸマネージャ１５は、インデクサ１６とともにＩＤＸ作成処理を行ない（ステップＢ１３）、処理がステップＢ１４に移行する。

図２０の例では、符号IIに示すように、ＩＤＸ作成状況１５ａにおいて、ＴＳ“1122”における検索キー“foo”のＩＤＸデータは作成済（true）となっている（ステップＢ１２でＹｅｓ）。一方、ＴＳ“1122”における検索キー“hoge”のＩＤＸデータは未作成（false）となっている（ステップＢ１２でＮｏ）。従って、ＩＤＸマネージャ１５は、ステップＢ１３のＩＤＸ作成処理において、ＴＳ“1122”における検索キー“hoge”のＩＤＸデータを作成する（図２０の符号III〜符号Ｖ参照（後述する））。

ＩＤＸマネージャ１５は、検索条件に含まれる全ての検索キーに対して、それぞれＩＤＸ１５ｂを走査（参照）し、各検索キーに該当するエントリのＵＩＤを取得（抽出）することで、ＵＩＤリストを取得（作成）する（ステップＢ１４；図２１の符号Ｉ参照）。そして、ＩＤＸマネージャ１５は、取得したＵＩＤリストを検索部１４ｂに送信する。

検索部１４ｂは、ＩＤＸマネージャ１５からＵＩＤリストを受信すると、ＫＶＳクラスタ１２に対して、受信したＵＩＤリストを含む、バリュー（オリジナルキーバリュー）の検索要求を送信する。

ＫＶＳクラスタ１２は、ＫＶＳ１２ａから、ＵＩＤリストに含まれるキー（ＵＩＤ）に対応するバリュー（オリジナルキーバリュー；エントリ）を取得し（図２１の符号II参照）、取得したエントリ群を検索部１４ｂに送信する。

検索部１４ｂは、ＫＶＳクラスタ１２から取得したエントリ群を検索結果としてサーバ１０５に送信（応答）し（ステップＢ１５）、処理が終了する。

〔１−４−４〕ＩＤＸ作成処理
次に、図２２及び図２０を参照して、図１７のステップＡ１５に示すＩＤＸ作成処理、及び、図１９のステップＢ１３に示すＩＤＸ作成処理の動作例を説明する。

以下、図１７のステップＡ１５に示すＩＤＸ作成処理に係るＴＳ、チャンク、検索キー等を、「登録」に係るＴＳ、チャンク、検索キー等と表記する。また、図１９のステップＢ１３に示すＩＤＸ作成処理に係るＴＳ、チャンク、検索キー等を、「検索」に係るＴＳ、チャンク、検索キー等と表記する。

図２２に例示するように、ＩＤＸマネージャ１５は、登録又は検索に係るＴＳにおいて登録又は検索の対象となる検索キーを持つエントリ群のＵＩＤリストの取得要求を、ＵＩＤマネージャ１３に送信する。

ＵＩＤマネージャ１３は、ＵＩＤリストの取得要求を受信すると、ＵＩＤリスト１３ａから、指定されたＵＩＤリストを検索（抽出）し（図２０の符号III参照）、得られたＵＩＤリストをＩＤＸマネージャ１５に送信する。ＩＤＸマネージャ１５は、ＵＩＤマネージャ１３からＵＩＤリストを取得する（ステップＳ１１）。

ＩＤＸマネージャ１５は、ＵＩＤマネージャ１３からＵＩＤリストを取得すると、ＩＤＸ作成状況１５ａを参照して、登録又は検索に係るチャンク内で一部のＩＤＸデータが作成済か否かを判定する（ステップＳ１２）。例えば、ＩＤＸマネージャ１５は、ＩＤＸ作成状況１５ａにおいて、登録又は検索に係るＴＳが属するチャンク内の全てのＴＳのうち、少なくとも１つのＴＳが有効を示すか否かを判定する。

当該チャンク内において少なくとも一部のＩＤＸデータが作成済である場合（ステップＳ１２でＹｅｓ）、処理がステップＳ１４に移行する。

一方、当該チャンク内においていずれのＩＤＸデータも作成されていない場合（ステップＳ１２でＮｏ）、ＩＤＸマネージャ１５は、当該チャンクに対するＩＤＸ１５ｂを、ノード２５に割り当て（ステップＳ１３）、当該ノード２５を担当ノードに決定する。負荷の平準化を図るためである。

そして、当該チャンクを担当する担当ノード２５から、当該担当ノード２５に対応するインデクサ１６のノード２６に対して、ＵＩＤリストを送信する（ステップＳ１４）。

インデクサ１６のノード２６は、ＫＶＳクラスタ１２に対して、ＩＤＸマネージャ１５から受信したＵＩＤリストに基づくエントリの取得（検索）要求を送信する。ＫＶＳクラスタ１２は、ＫＶＳ１２ａから、ＵＩＤリストで指定されたＵＩＤ（キー）に対応するエントリ（バリュー）を抽出（検索）し（図２０の符号IV参照）、抽出結果をインデクサ１６に送信する。インデクサ１６は、抽出結果をＫＶＳクラスタ１２から受信する（ステップＳ１５）。

インデクサ１６は、ＵＩＤリスト、並びに、ＫＶＳクラスタ１２から受信したエントリ群、すなわち、オリジナルキーバリュー群に基づき、ＩＤＸ１５ｂに対して、ＩＤＸデータを作成（追加）する（ステップＳ１６；図２０の符号Ｖ参照）。そして、インデクサ１６は、ＩＤＸマネージャ１５に対して、ＩＤＸデータの作成完了を通知する。

ＩＤＸマネージャ１５は、登録又は検索に係る検索キー及びＴＳについてのＩＤＸデータを作成したこと、ＩＤＸ作成状況１５ａに記録し（ステップＳ１７）、処理が終了する。

〔１−４−５〕スケールアウト処理
次に、図２３を参照して、図１６のステップＣ１及びＣ２に示す処理の動作例を説明する。

図２３に例示するように、スケールアウト制御部１９は、ＫＶＳシステム１の性能監視結果に基づき、ボトルネック箇所を解析し（ステップＣ１１）、ステップＣ１２、Ｃ１４、及び、Ｃ１６の各処理を行なう。なお、ステップＣ１２、Ｃ１４、及び、Ｃ１６の処理は、並行して行なわれてもよいし、所定の順序で行なわれてもよい。

スケールアウト制御部１９は、ボトルネック箇所がストアハンドラ１１又はクエリハンドラ１４であるか否かを判定する（ステップＣ１２）。

ボトルネック箇所がストアハンドラ１１又はクエリハンドラ１４である場合（ステップＣ１２でＹｅｓ）、スケールアウト制御部１９は、ボトルネック箇所であるストアハンドラ１１又はクエリハンドラ１４に対してスケールアウト処理の実行を指示する。

ボトルネック箇所であるストアハンドラ１１又はクエリハンドラ１４は、スケールアウト処理の実行指示に応じて、ボトルネック箇所のノード２１又は２４の台数を増加させる（ステップＣ１３）。

ステップＣ１３の指示をした場合、又は、ボトルネック箇所がストアハンドラ１１又はクエリハンドラ１４ではない場合（ステップＣ１２でＮｏ）、処理が終了する。

また、スケールアウト制御部１９は、ボトルネック箇所がＵＩＤマネージャ１３であるか否かを判定する（ステップＣ１４）。

ボトルネック箇所がＵＩＤマネージャ１３である場合（ステップＣ１４でＹｅｓ）、スケールアウト制御部１９は、ボトルネック箇所であるＵＩＤマネージャ１３に対してスケールアウト処理の実行を指示する。

ボトルネック箇所であるＵＩＤマネージャ１３は、スケールアウト処理の実行指示に応じて、ボトルネック箇所のノード２３の台数を増加させ、格納頻度の高いキーのリクエストを、複数のノード２３に分散させる（ステップＣ１５）。

ステップＣ１５の指示をした場合、又は、ボトルネック箇所がＵＩＤマネージャ１３ではない場合（ステップＣ１４でＮｏ）、処理が終了する。

さらに、スケールアウト制御部１９は、ボトルネック箇所がＩＤＸ１５ｂの更新（又は作成）であるか否かを判定する（ステップＣ１６）。

ボトルネック箇所がＩＤＸ１５ｂの更新等である場合（ステップＣ１６でＹｅｓ）、スケールアウト制御部１９は、ボトルネック箇所であるＩＤＸマネージャ１５に対してスケールアウト処理の実行を指示する。

ボトルネック箇所であるＩＤＸマネージャ１５は、スケールアウト処理の実行指示に応じて、ボトルネック箇所のノード２５及び／又はノード２６の台数を増加させ、検索頻度の高いキーのチャンクを小さくする（ステップＣ１７）。

ステップＣ１７の指示をした場合、又は、ボトルネック箇所がＩＤＸ１５ｂの更新等ではない場合（ステップＣ１６でＮｏ）、処理が終了する。

〔１−５〕ハードウェア構成例
図２４は、一実施形態に係るＫＶＳシステム１が備える複数のノードを実現するＨＷ資源及びＮＷ資源を構成するコンピュータ１０のハードウェア構成例を示すブロック図である。コンピュータ１０は、ＨＷ構成として、例示的に、プロセッサ１０ａ、メモリ１０ｂ、記憶部１０ｃ、ＩＦ（Interface）部１０ｄ、Ｉ／Ｏ（Input / Output）部１０ｅ、及び、読取部１０ｆを備えてよい。

プロセッサ１０ａは、種々の制御や演算を行なう演算処理装置の一例である。プロセッサ１０ａは、コンピュータ１０内の各ブロックとバス１０ｉで相互に通信可能に接続されてよい。なお、プロセッサ１０ａは、複数のプロセッサを含むマルチプロセッサであってもよいし、複数のプロセッサコアを有するマルチコアプロセッサであってもよく、或いは、マルチコアプロセッサを複数有する構成であってもよい。

プロセッサ１０ａとしては、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路（ＩＣ；Integrated Circuit）が挙げられる。ＭＰＵはMicro Processing Unitの略称である。ＧＰＵはGraphics Processing Unitの略称であり、ＡＰＵはAccelerated Processing Unitの略称である。ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific ICの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。

メモリ１０ｂは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。メモリ１０ｂとしては、例えばＤＲＡＭ（Dynamic Random Access Memory）等の揮発性メモリが挙げられる。

記憶部１０ｃは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。記憶部１０ｃとしては、ＨＤＤ等の磁気ディスク装置、例えばＳＳＤ等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。

また、記憶部１０ｃは、コンピュータ１０の各種機能の全部若しくは一部を実現するプログラム１０ｇを格納してよい。例えば、コンピュータ１０のプロセッサ１０ａは、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して実行することにより、図２及び図９〜図１３に示すＫＶＳシステム１としての機能を実現できる。

ＩＦ部１０ｄは、図示しないネットワーク（図１に示すネットワーク１０３及び１０６を含んでもよい）との間の接続及び通信の制御等を行なう通信ＩＦの一例である。例えば、ＩＦ部１０ｄは、ＬＡＮ（Local Area Network）、或いは、光通信（例えばＦＣ（Fibre Channel；ファイバチャネル））等に準拠したアダプタを含んでよい。例えば、プログラム１０ｇは、当該通信ＩＦを介して、ネットワークからコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。

Ｉ／Ｏ部１０ｅは、マウス、キーボード、又は操作ボタン等の入力部、並びに、タッチパネルディスプレイ、ＬＣＤ（Liquid Crystal Display）等のモニタ、プロジェクタ、又はプリンタ等の出力部、の一方又は双方を含んでよい。

読取部１０ｆは、記録媒体１０ｈに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部１０ｆは、記録媒体１０ｈを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部１０ｆとしては、例えば、ＵＳＢ（Universal Serial Bus）等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体１０ｈにはプログラム１０ｇが格納されてもよく、読取部１０ｆが記録媒体１０ｈからプログラム１０ｇを読み出して記憶部１０ｃに格納してもよい。

記録媒体１０ｈとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等が挙げられる。なお、ＣＤとしては、例示的に、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ等が挙げられる。また、ＤＶＤとしては、例示的に、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。

上述したコンピュータ１０のハードウェア構成は例示である。従って、コンピュータ１０内でのハードウェアの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。

なお、一実施形態では、図示しないネットワークによって相互に通信可能に接続された複数のコンピュータ１０により構成されるＨＷ資源及びＮＷ資源によって、例えば、クラウドシステムとしてのＫＶＳシステム１が構成されてよい。この場合、ＫＶＳシステム１が備える複数のノードの各々は、複数のコンピュータ１０により構成されるＨＷ資源及びＮＷ資源を、論理的に（仮想的に）又は物理的に分割してノードに割り当てることにより実現されてよい。

換言すれば、ＫＶＳシステム１は、複数のコンピュータ１０により提供されるＨＷ資源及びＮＷ資源としての、プロセッサ資源（プロセッサ）、メモリ資源（メモリ）、記憶資源（記憶部）、ＩＦ資源（ＩＦ部）、を備える１つの情報処理装置であると捉えてもよい。情報処理装置（コンピュータ）としてのＫＶＳシステム１は、スケールアウト処理によって、プロセッサ資源、メモリ資源、記憶資源、及びＩＦ資源を、特定の機能ブロックを実現するためのノードに割り当てたり、或いはノードへの割り当てを解放したりすることができる。

なお、ＫＶＳシステム１が備える複数の機能ブロックの各々を、（１以上のノードを備える）１つの装置と捉えてもよく、この場合、ＫＶＳシステム１は、複数の装置を備える情報処理システムと捉えられてよい。

また、クラウドシステムとしてのＫＶＳシステム１においては、ＫＶＳシステム１としての機能を実現するためのプログラム１０ｇを、複数のノードの各々における実行単位に分割し、分割したプログラムを複数のノードに分散して配置してもよい。なお、上述のように、複数のノード（複数のノード２１〜２６）は、複数の物理マシン、複数の仮想マシン（ＶＭ）、及び、１以上の物理マシン及び１以上の仮想マシンの組み合わせ、のいずれであってもよい。

すなわち、プログラム１０ｇは、複数のノードに分散して配置されたとしても、ＫＶＳシステム１の機能を、情報処理装置（コンピュータ）又は情報処理システムに実行させる１つのプログラムと捉えることができる。

〔２〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。

例えば、図２、図９〜図１２、並びに、図１３に示すＫＶＳシステム１の各機能ブロックは、任意の組み合わせで併合してもよく、それぞれ分割してもよい。ＫＶＳシステム１の機能ブロックとは、ストアハンドラ１１、ＫＶＳクラスタ１２、ＵＩＤマネージャ１３、クエリハンドラ１４、ＩＤＸマネージャ１５、インデクサ１６、ロードバランサ１７及び１８、並びに、スケールアウト制御部１９である。

また、一実施形態において、ストアハンドラ１１がＩｏＴデバイス１０１からキーバリュー（オリジナルキーバリュー）の格納要求を受け付けるものとしたが、これに限定されるものではない。ストアハンドラ１１は、ＩｏＴデバイス１０１以外の他のコンピュータから、種々の形態のデータをＫＶＳクラスタ１２に格納する格納要求を受け付けてよい。従って、ＫＶＳ１２ａに格納されるバリューは、オリジナルキーバリューに限定されるものではなく、スキーマレスな種々のデータであってよい。

〔３〕付記
以上の一実施形態に関し、さらに以下の付記を開示する。

（付記１）
キーとバリューとを対応付けて格納するキーバリューストアに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納する格納処理部と、
単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理する管理部と、
前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する作成部と、を備える
情報処理装置。

（付記２）
前記作成部は、前記検索要求で指定された時刻に対応する識別情報を前記対応情報から抽出し、前記抽出した識別情報に対応するデータを前記キーバリューストアから抽出して、前記抽出した識別情報及び前記抽出したデータに基づき、前記インデックスを作成する、付記１に記載の情報処理装置。

（付記３）
前記作成部は、連続する複数の前記単位時間を含む所定期間を一単位として前記インデックスを作成する、付記１又は付記２に記載の情報処理装置。

（付記４）
前記作成部は、
前記所定期間に含まれる各単位時間に受信したデータに関するインデックスデータが前記所定期間の前記インデックスに含まれるか否かを示す作成管理情報を管理し、
前記検索要求で指定された時刻に対応する単位時間に受信したデータに関するインデックスデータが前記インデックスに含まれない場合に、当該インデックスデータを前記インデックスに追加する、付記３に記載の情報処理装置。

（付記５）
前記格納要求により前記キーバリューストアへの格納を要求されるデータは、キー及びバリューを含み、
前記格納処理部は、前記データに割り当てられた識別情報を前記キーバリューストアのキーとし、前記キー及び前記バリューを含む前記データを前記キーバリューストアのバリューとして、前記識別情報と前記データとを前記キーバリューストアに格納し、
前記対応情報は、前記単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータのキーとを対応付けた情報である、付記１〜４のいずれか１項に記載の情報処理装置。

（付記６）
前記格納処理部、前記キーバリューストア、前記管理部、及び、前記作成部は、それぞれ、１以上のノードにより実行され、
前記情報処理装置の性能を監視する監視部をさらに備え、
前記監視部は、前記監視の結果に基づいて、前記格納処理部を実行する１以上のノード、前記キーバリューストアを実行する１以上のノード、前記管理部を実行する１以上のノード、及び、前記作成部を実行する１以上のノード、のうちの少なくとも１つのノード数を変更する制御を行なう、付記１〜５のいずれか１項に記載の情報処理装置。

（付記７）
前記管理部は、前記管理部を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記対応情報を分散して記憶させる、付記６に記載の情報処理装置。

（付記８）
前記作成部は、前記作成部を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記インデックスを分散して記憶させる、付記６又は付記７に記載の情報処理装置。

（付記９）
コンピュータに、
キーとバリューとを対応付けて格納するキーバリューストアに対するデータの格納要求を受け付け、
前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納し、
単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理し、
前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する、
処理を実行させる情報処理プログラム。

（付記１０）
前記作成は、
前記検索要求で指定された時刻に対応する識別情報を前記対応情報から抽出し、
前記抽出した識別情報に対応するデータを前記キーバリューストアから抽出し、
前記抽出した識別情報及び前記抽出したデータに基づき、前記インデックスを作成する、付記９に記載の情報処理プログラム。

（付記１１）
前記作成は、連続する複数の前記単位時間を含む所定期間を一単位として前記インデックスを作成する、付記９又は付記１０に記載の情報処理プログラム。

（付記１２）
前記コンピュータに、
前記所定期間に含まれる各単位時間に受信したデータに関するインデックスデータが前記所定期間の前記インデックスに含まれるか否かを示す作成管理情報を管理する、
処理を実行させ、
前記作成は、前記検索要求で指定された時刻に対応する単位時間に受信したデータに関するインデックスデータが前記インデックスに含まれない場合に、当該インデックスデータを前記インデックスに追加する、付記１１に記載の情報処理プログラム。

（付記１３）
前記格納要求により前記キーバリューストアへの格納を要求されるデータは、キー及びバリューを含み、
前記格納は、前記データに割り当てられた識別情報を前記キーバリューストアのキーとし、前記キー及び前記バリューを含む前記データを前記キーバリューストアのバリューとして、前記識別情報と前記データとを前記キーバリューストアに格納し、
前記対応情報は、前記単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータのキーとを対応付けた情報である、付記９〜１２のいずれか１項に記載の情報処理プログラム。

（付記１４）
前記格納、前記キーバリューストア、前記管理、及び、前記作成は、それぞれ、１以上のノードにより実行され、
前記コンピュータに、
前記コンピュータの性能を監視し、
前記監視の結果に基づいて、前記格納を実行する１以上のノード、前記キーバリューストアを実行する１以上のノード、前記管理を実行する１以上のノード、及び、前記作成を実行する１以上のノード、のうちの少なくとも１つのノード数を変更する制御を行なう、
処理を実行させる、付記９〜１３のいずれか１項に記載の情報処理プログラム。

（付記１５）
前記コンピュータに、
前記管理を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記対応情報を分散して記憶させる、
処理を実行させる、付記１４に記載の情報処理プログラム。

（付記１６）
前記コンピュータに、
前記作成を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記インデックスを分散して記憶させる、
処理を実行させる、付記１４又は付記１５に記載の情報処理プログラム。

（付記１７）
キーとバリューとを対応付けて格納するキーバリューストアと、
前記キーバリューストアに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納する格納処理部と、
単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理する管理部と、
前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する作成部と、を備える
情報処理システム。

１ ＫＶＳシステム
１０ コンピュータ
１１ ストアハンドラ
１１ａ ストア受付部
１１ｂ 格納部
１２ ＫＶＳクラスタ
１２ａ ＫＶＳ
１３ ＵＩＤマネージャ
１３ａ ＵＩＤリスト
１４ クエリハンドラ
１４ａ クエリ受付部
１４ｂ 検索部
１５ ＩＤＸマネージャ
１５ａ ＩＤＸ作成状況
１５ｂ ＩＤＸ
１６ インデクサ
１７、１８ ロードバランサ
１９ スケールアウト制御部
１００ ＩｏＴシステム
１０１ ＩｏＴデバイス
１０２ エッジコンピュータ
１０３、１０６ ネットワーク
１０４ データセンタ
１０５ サーバ
２、３ 管理部
２ａ ノードリスト
２１〜２６ ノード
３ａ インデクサリスト

Claims (9)

1. キーとバリューとを対応付けて格納するキーバリューストアに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納する格納処理部と、
   単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理する管理部と、
   前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する作成部と、を備える
   情報処理装置。
2. 前記作成部は、前記検索要求で指定された時刻に対応する識別情報を前記対応情報から抽出し、前記抽出した識別情報に対応するデータを前記キーバリューストアから抽出して、前記抽出した識別情報及び前記抽出したデータに基づき、前記インデックスを作成する、請求項１に記載の情報処理装置。
3. 前記作成部は、連続する複数の前記単位時間を含む所定期間を一単位として前記インデックスを作成する、請求項１又は請求項２に記載の情報処理装置。
4. 前記作成部は、
   前記所定期間に含まれる各単位時間に受信したデータに関するインデックスデータが前記所定期間の前記インデックスに含まれるか否かを示す作成管理情報を管理し、
   前記検索要求で指定された時刻に対応する単位時間に受信したデータに関するインデックスデータが前記インデックスに含まれない場合に、当該インデックスデータを前記インデックスに追加する、請求項３に記載の情報処理装置。
5. 前記格納処理部、前記キーバリューストア、前記管理部、及び、前記作成部は、それぞれ、１以上のノードにより実行され、
   前記情報処理装置の性能を監視する監視部をさらに備え、
   前記監視部は、前記監視の結果に基づいて、前記格納処理部を実行する１以上のノード、前記キーバリューストアを実行する１以上のノード、前記管理部を実行する１以上のノード、及び、前記作成部を実行する１以上のノード、のうちの少なくとも１つのノード数を変更する制御を行なう、請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記管理部は、前記管理部を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記対応情報を分散して記憶させる、請求項５に記載の情報処理装置。
7. 前記作成部は、前記作成部を実行する前記１以上のノードの各々に対して、前記監視の結果に基づいて、前記キーバリューストアが格納する複数のデータの内容ごとに、前記インデックスを分散して記憶させる、請求項５又は請求項６に記載の情報処理装置。
8. コンピュータに、
   キーとバリューとを対応付けて格納するキーバリューストアに対するデータの格納要求を受け付け、
   前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納し、
   単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理し、
   前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する、
   処理を実行させる情報処理プログラム。
9. キーとバリューとを対応付けて格納するキーバリューストアと、
   前記キーバリューストアに対するデータの格納要求を受け付け、前記データに割り当てられた識別情報と前記データとを前記キーバリューストアに格納する格納処理部と、
   単位時間に受信したデータに割り当てた識別情報と、当該単位時間に受信したデータの内容とを対応付けた対応情報を管理する管理部と、
   前記キーバリューストアからデータを検索するための検索要求であって、時刻が指定された前記検索要求と、前記対応情報と、前記キーバリューストアが格納するデータと、に基づいて、前記キーバリューストアのインデックスを作成する作成部と、を備える
   情報処理システム。

Images