JP6192171B2 - プログラムおよびクラスタシステム - Google Patents
プログラムおよびクラスタシステム Download PDFInfo
- Publication number
- JP6192171B2 JP6192171B2 JP2014178321A JP2014178321A JP6192171B2 JP 6192171 B2 JP6192171 B2 JP 6192171B2 JP 2014178321 A JP2014178321 A JP 2014178321A JP 2014178321 A JP2014178321 A JP 2014178321A JP 6192171 B2 JP6192171 B2 JP 6192171B2
- Authority
- JP
- Japan
- Prior art keywords
- hash
- bit string
- key
- attribute
- attribute value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、プログラムおよびクラスタシステムに関する。
スケーラビリティの高い効果を得ることを最大目標としたデータベースの技術として、分散データベース（ＤＢ）が存在する。スケーラビリティを獲得するための方式としては、ＫＶＳ（Key Value Store）が代表的である。
現在広く利用されているデータベース（ＤＢ）として、ＲＤＢ（Relational Data Base）が存在する。このＲＤＢの技術は、Row（行）、Column（列）からなる２次元のテーブル構造でデータを表現し、ＳＱＬ（Structured Query Language）言語等によるクエリに応じて、JOIN（結合）や正規化を実行することで、検索等の処理を実現することができる。様々なアプリケーションは、ＲＤＢを用いて作成されることが多く、その理由は多岐に渡るが、特に重要な要素として、単純なkey検索だけでなく、データの属性値（value）でも検索できる機能を有するところが大きいと言える。但し、従来の分散システムでは、単純なkeyを用いたアプリケーションには適用できるが、valueを操作するアプリケーションには適用できないか、できてもスケールしない状況のものが多かった。しかもデータの構造を分散プラットフォーム（ＰＦ）用に大きく見直す必要もあった。
分散システムの研究分野でも、上記を鑑み、単純key検索用途のＮｏＳＱＬから、属性値検索を始めとしたＲＤＢ並みの操作能力を持つＮｅｗＳＱＬへの検討が多くされつつある。
現在広く利用されているデータベース（ＤＢ）として、ＲＤＢ（Relational Data Base）が存在する。このＲＤＢの技術は、Row（行）、Column（列）からなる２次元のテーブル構造でデータを表現し、ＳＱＬ（Structured Query Language）言語等によるクエリに応じて、JOIN（結合）や正規化を実行することで、検索等の処理を実現することができる。様々なアプリケーションは、ＲＤＢを用いて作成されることが多く、その理由は多岐に渡るが、特に重要な要素として、単純なkey検索だけでなく、データの属性値（value）でも検索できる機能を有するところが大きいと言える。但し、従来の分散システムでは、単純なkeyを用いたアプリケーションには適用できるが、valueを操作するアプリケーションには適用できないか、できてもスケールしない状況のものが多かった。しかもデータの構造を分散プラットフォーム（ＰＦ）用に大きく見直す必要もあった。
分散システムの研究分野でも、上記を鑑み、単純key検索用途のＮｏＳＱＬから、属性値検索を始めとしたＲＤＢ並みの操作能力を持つＮｅｗＳＱＬへの検討が多くされつつある。
分散システムにおいて属性値検索を可能とする代表的な手法として、Secondary Index等の転置インデックス手法があり、ＣａｓｓａｎｄｒａやＭｅｒｃｕｒｙ等の代表的な分散ＤＢが採用してきている（非特許文献１，２参照）。但し上記では、基本的に、複数のhash関数を用い、keyを主のhash関数に適用して得られた出力の場所にマスターデータを置き、検索したい属性値を別のhash関数に適用して得られた出力の場所にレプリカデータを置く仕組みである。
また、レプリカデータをリンクとして、データ容量の効率性を高めたＭｅｒＤｙという手法も存在する。
また、レプリカデータをリンクとして、データ容量の効率性を高めたＭｅｒＤｙという手法も存在する。
図１０は、ＭｅｒＤｙを説明する図である。
ＭｅｒＤｙは、転置インデックス（属性検索用）を用いて、属性値による検索を可能にする分散ＤＢにおいて、データの場所を示す識別子（hash値）を付与する。分散ＤＢにおけるデータ配置のサーバへの配置の決定方法としては、データの属性タグや属性値等にhash値をかけて識別子とする。一方、サーバ毎に担当する識別子領域を割り当ててある。
ＭｅｒＤｙは、転置インデックス（属性検索用）を用いて、属性値による検索を可能にする分散ＤＢにおいて、データの場所を示す識別子（hash値）を付与する。分散ＤＢにおけるデータ配置のサーバへの配置の決定方法としては、データの属性タグや属性値等にhash値をかけて識別子とする。一方、サーバ毎に担当する識別子領域を割り当ててある。
図１０に示すように、h0(key)を主のhash関数に適用して得られた出力のサーバ（このサーバは、ストレージとしての機能）にマスターデータ（ｖ０，ｖ１，ｖ２ ） を置き、検索したい属性値を別のhash関数に適用して得られた出力の場所にレプリカデータ（ｖ０，ｖ１，ｖ２ ） と（ｖ０，ｖ１，ｖ２ ）と を置く。なお、２つのレプリカデータを置くのは一例であって、冗長化数に従って決定される。
上記主のhash関数は、keyで検索されるh0(key)であり、ＭＤ５（Message Digest Algorithm 5）などの不連続hash関数である。このh0(key)にマスターデータ（ｖ０，ｖ１，ｖ２ ）を置く。
上記別のhash関数は、「属性値を検索するためのhash関数」であり、検索したい属性値に対して適用される上記主のhash関数とは別の、属性値で検索されるh1(v0),h2(v1),h3(v2)である。例えば、h1(v0)は、文字コード変換などの連続hash関数、h2(v1)は、文字数などの連続hash関数、h3(v2)は、ＳＨＡ１（Secure Hash Algorithm 1）などの不連続なhash関数である。なお、後記する図１１および図１２において、転置インデックス（属性検索用）のkeyをk1,k2,…で表すことがある。
上記別のhash関数は、「属性値を検索するためのhash関数」であり、検索したい属性値に対して適用される上記主のhash関数とは別の、属性値で検索されるh1(v0),h2(v1),h3(v2)である。例えば、h1(v0)は、文字コード変換などの連続hash関数、h2(v1)は、文字数などの連続hash関数、h3(v2)は、ＳＨＡ１（Secure Hash Algorithm 1）などの不連続なhash関数である。なお、後記する図１１および図１２において、転置インデックス（属性検索用）のkeyをk1,k2,…で表すことがある。
川上 大輔, 他: "範囲検索と複数属性のデータの処理に適応した分散データストア," 情報処理学会研究報告[システムソフトウェアとオペレーティング・システム] 2010-OS-113(10), 1-8, 2010-01-20.
Cassandra secondary index，［online］、［平成２６年7月21日検索］、インターネット<URL:http://books.***.co.jp/books?hl=ja&lr=&id=MKGSbCbEdg0C&oi=fnd&pg=PR7&dq=Cassandra+secondary+index&ots=XpPC2yy91A&sig=oCxd9a_Gvrp4cbfpidKEEVVMW6Y#v=onepage&q=Cassandra%20secondary%20index&f=false>
前記した非特許文献１，２に記載のＭｅｒｃｕｒｙやＭｅｒＤｙでは、属性値に対して、keyと同様にhash関数を適用し、そのhash値のコンシステントハッシュ（Consistent Hashing）等の空間上の位置に該当するサーバに、転置インデックスを格納する。
しかしながら、この非特許文献１，２の手法では、新規データ生成時やデータ更新時において各属性値の転置インデックスを作成してサーバに配置する必要があるため、属性値のパターンにおいては負荷に偏りや集中が発生する可能性がある。属性値は、性別や血液型等、種類が少ないものや、都道府県など極端な偏りがあるものも存在し、そのまま扱うとクラスタ内の負荷の偏りによりスケールしない事態が発生する。例えば、真理値等のような取り得る値の少ない属性値や居住地等のような偏在する属性値では、クラスタ内のサーバ負荷が偏るという問題があった。すなわち、メモリ量の増大もさることながら、書き込みの際の転置インデックス作成自体の負荷でボトルネックになり、スケーラビリティが損なわれる。
しかしながら、この非特許文献１，２の手法では、新規データ生成時やデータ更新時において各属性値の転置インデックスを作成してサーバに配置する必要があるため、属性値のパターンにおいては負荷に偏りや集中が発生する可能性がある。属性値は、性別や血液型等、種類が少ないものや、都道府県など極端な偏りがあるものも存在し、そのまま扱うとクラスタ内の負荷の偏りによりスケールしない事態が発生する。例えば、真理値等のような取り得る値の少ない属性値や居住地等のような偏在する属性値では、クラスタ内のサーバ負荷が偏るという問題があった。すなわち、メモリ量の増大もさることながら、書き込みの際の転置インデックス作成自体の負荷でボトルネックになり、スケーラビリティが損なわれる。
以下、属性値によって転置インデックスが極端に偏り、負荷が集中してしまうことについて具体的に説明する。
図１１の符号（Ａ）に示すように、居住地(都道府県等)のバリエーションはあるものの、東京に住んでいる人口が圧倒的に多い「偏りが大きい属性値」である場合（課題１）や、図１１の符号（Ｂ）に示すように、男性と女性、真理値等のようなバリエーションが少なすぎる「取り得る値の種類が少ない属性値」である場合がある（課題２）。
このような属性値の場合、転置インデックスが極端に偏り、負荷が集中してしまい、スケーラビリティが損なわれる。
図１１の符号（Ａ）に示すように、居住地(都道府県等)のバリエーションはあるものの、東京に住んでいる人口が圧倒的に多い「偏りが大きい属性値」である場合（課題１）や、図１１の符号（Ｂ）に示すように、男性と女性、真理値等のようなバリエーションが少なすぎる「取り得る値の種類が少ない属性値」である場合がある（課題２）。
このような属性値の場合、転置インデックスが極端に偏り、負荷が集中してしまい、スケーラビリティが損なわれる。
図１２に示すように、自然文で記述され、かつ部分文字列検索の対象となり得る「名前」、「趣味」、「備考」として例示される文字列等の分布の場合や、「リンク数」のように量を表され、特定の量の範囲が検索対象となり得る数字等の分布の場合、それぞれが一様分布だったとしても、前方の領域に集中してしまうことが多い（すなわち、ある１つの属性値は一様分布であったとしても複数の属性値が重ね合わせられた場合に所定領域に集中してしまう）場合がある。前方一致等の理由から連続関数を用いるとこのようなことが発生する。この場合、文字列長は、限定的な範囲に分布するため、複数の文字列属性値が存在したとき、hash空間において値が小さい方で分布が重複し、それに伴ってサーバの負荷も偏り易い（課題３）。
このような背景を鑑みて本発明がなされたのであり、本発明は、属性値検索の負荷の平準化を可能とする、プログラムおよびクラスタシステムを提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、属性タグと属性値にkeyを付して、当該属性値を検索するためのhash関数を適用し、得られたhash値のhash空間上の位置に該当するサーバに、転置インデックスを格納するクラスタシステム、を構成する各前記サーバとしてのコンピュータを、前記属性値を検索するためのhash関数に基づいて、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列、のいずれかを含むhash bit列を作成するhash bit列作成手段、少なくとも、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列とを結合する、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列とを結合する結合手段、として機能させるためのプログラムとした。
また、請求項４記載の発明は、属性タグと属性値にkeyを付して、当該属性値を検索するためのhash関数を適用し、得られたhash値のhash空間上の位置に該当するサーバに、転置インデックスを格納するクラスタシステムであって、前記サーバは、前記属性値を検索するためのhash関数に基づいて、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列、のいずれかを含むhash bit列を作成するhash bit列作成手段と、少なくとも、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列とを結合する、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列とを結合する結合手段と、を備えることを特徴とするクラスタシステムとした。
このように、属性値から得られたhash bit列と属性タグから得られた不連続hash bit列、または、属性値から得られたhash bit列とkeyから得られたhash bit列、のいずれかを含むhash bit列を作成し、属性値から得られたhash bit列と属性タグから得られた不連続hash bit列とを結合する、または、属性値から得られたhash bit列とkeyから得られたhash bit列とを結合することで、属性値によって転置インデックスが極端に偏り、負荷が集中してしまうことによるクラスタにおける性能のスケーラビリティの低下を緩和させることができる。
また、請求項２に記載の発明は、前記結合手段は、前記属性値から得られたhash bit列の上位bitに、前記属性タグから得られたhash bit列を結合することを特徴とする請求項１に記載のプログラムとした。
このようにすることで、hash空間における属性タグの分布の位置をランダムにずらすことができる。これにより、属性値が一様分布だったとしても、hash空間で値が小さい範囲の領域に集中してしまうような偏り（課題３）を解消することができ、複数の文字列による分布の重ね合わせを平準化する効果がもたらされる。その結果、サーバの負荷の偏りを緩和させることができる。
また、請求項３に記載の発明は、前記結合手段は、前記属性値から得られたhash bit列の下位bitに、前記keyから得られたhash bit列を結合することを特徴とする請求項１に記載のプログラムとした。
このようにすることで、単一属性において、あるhash値に対して最頻値が鋭いピークを持つ分布であっても、ピークを低くした分布にすることができる。これにより、属性値を特定の範囲内で分散させることができる。属性値の単一分布内の偏り（課題１）や、取り得る値の少なさによる集中化（課題２）に対しても、負荷を平準化することができる。
本発明によれば、属性値検索の負荷の平準化を可能とする、プログラムおよびクラスタシステムを提供することができる。
次に、本発明を実施するための形態（以下、「本実施形態」という）におけるクラスタシステム１等について説明する。
（本実施形態のシステム構成）
本実施形態に係るクラスタシステム１について具体的に説明する。
本実施形態に係るクラスタシステム１について具体的に説明する。
本実施形態に係るクラスタシステム１は、図１に示すように、ネットワークを介して、外部システムであるクライアント２等と接続される。そして、クライアント２からの入力データを受け取り、クラスタシステム１内でデータの保存、更新、検索等を行い、その結果を出力データとして、クライアント２に送信する。
図２は、本実施形態に係るクラスタシステム１を構成するサーバ１１の構成を示す機能ブロック図である。
図２に示すように、サーバ１１は、制御手段１１０、入出力手段２０は、メモリ手段３０、および記憶手段４０を含んで構成される。
図２に示すように、サーバ１１は、制御手段１１０、入出力手段２０は、メモリ手段３０、および記憶手段４０を含んで構成される。
入出力手段２０は、クライアント２や、各サーバ１１との間の情報の入出力を行う。この入出力手段２０は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
メモリ手段３０は、ＲＡＭ（Random Access Memory）等の一次記憶装置からなり、制御手段１１０によるデータ処理に必要な情報を一時的に記憶している。
記憶手段４０は、ハードディスクやフラッシュメモリ等の記憶装置からなり、クラスタシステム１内の各サーバ１１のＩＤ（ＩＰアドレス）等を記憶している。
制御手段１１０は、サーバ１１全体の制御を司り、情報受信手段１１１、構文解析手段１１２、属性タグ情報格納手段１１３、hash bit列作成手段１１４、結合手段１１５、および情報送信手段１１６を含んで構成される。なお、この制御手段１１０は、例えば、記憶手段４０に格納されたプログラムをＣＰＵ（Central Processing Unit）がメモリ手段３０であるＲＡＭに展開し実行することで実現される。
情報受信手段１１１は、入出力手段２０を介して、クライアント２からの入力データ、他のサーバ１１等からの出力データを取得する。
構文解析手段１１２は、情報受信手段１１１から入力データを受け取り、その入力データの内容を構文解析する。例えば、構文解析手段１１２は、その入力データが、（ａ）keyの完全一致検索、（ｂ）keyの範囲検索、（ｃ）属性値（value）の完全一致検索、（ｄ）valueの範囲検索（部分文字列検索を含む）のいずれであるかを解析する。そして、構文解析手段１１２は、その解析結果をhash bit列作成手段１１４に引き渡す。
属性タグ情報格納手段１１３は、属性タグ毎に、属性タグに適用するhash関数、属性値に適用するhash関数、およびkeyに適用するhash関数を記憶手段４０に属性タグ情報として格納する（図３（ａ）参照）。また、各hash関数は、それぞれ何bitのhash値を算出するかを個別に記憶しているものとする。例えば、属性タグ「Location」や「Boolean」毎に、あらかじめ出力bit長が決まったhash関数のセットを格納している（図３（ｂ）参照 ）。
hash bit列作成手段１１４は、記憶手段４０に記憶された属性タグ情報から取得した属性タグ毎のhash関数およびbit長 に基づいて、「属性値から得られた連続hash bit列」（図４の符号（Ａ）参照）と、「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）と、「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）とを作成する。ここでhash値を２値でみる（２進数で表す）と、hash bit列となる。
結合手段１１５は、hash bit列を結合する。具体的には、結合手段１１５は、属性値から得られた連続hash bit列の上位bitに、属性タグから得られた不連続hash bit列を結合し、属性値から得られた連続hash bit列の下位bitに、keyから得られた連続hash bit列を結合する。
情報送信手段１１６は、入出力手段２０を介して、クライアント２や他のサーバ１１に出力データを送信する。
本実施形態は、「属性値を検索するためのhash関数」を、複数のhash bit列の組み合わせにより構成することを特徴とする。例えば、不連続関数（１つの属性値に対して不連続なhash関数(ＭＤ５など)を使うこと）、連続関数（文字コード変換で用いる数値化関数連続なhash関数を使うこと）といった排他的（二者択一的）な使用の仕方ではなく、bit列で結合したhash値を使うようにし、転置インデックス（属性検索用）を作成する。
以下、「属性値を検索するためのhash関数」の各bit列の構成について説明し、次に各bit列の結合手法について説明する。
図４は、「属性値を検索するためのhash関数」のbit列の構成を説明する図である。
図４に示すように、「属性値を検索するためのhash関数」のbit列は、「属性値から得られた連続hash bit列」（図４の符号（Ａ）参照）と、「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）と、「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）と、から構成される。
なお、図４の符号（Ａ）に示す属性値から得られた連続hash bit列は、不連続hash bit列であってもよい。また、各hash bit列のビット長については、図５により後記する。
図４は、「属性値を検索するためのhash関数」のbit列の構成を説明する図である。
図４に示すように、「属性値を検索するためのhash関数」のbit列は、「属性値から得られた連続hash bit列」（図４の符号（Ａ）参照）と、「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）と、「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）と、から構成される。
なお、図４の符号（Ａ）に示す属性値から得られた連続hash bit列は、不連続hash bit列であってもよい。また、各hash bit列のビット長については、図５により後記する。
<属性値から得られた連続hash bit列>（図４の符号（Ａ）参照）
図４の符号（Ａ）に示すように、属性値から得られた連続hash bit列「00000101101101」は、転置インデックス（属性検索用）のhash値である。なお、図４の符号（Ａ）に示す属性値から得られた連続hash bit列は、従来例と同様の転置インデックスのhash値でもある。具体的には、本実施形態では、属性値に対して、keyと同様にhash関数を適用し、そのhash値（図４の符号（Ａ）に示すhash bit列）のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックス（属性検索用）を格納する。
図４の符号（Ａ）に示すように、属性値から得られた連続hash bit列「00000101101101」は、転置インデックス（属性検索用）のhash値である。なお、図４の符号（Ａ）に示す属性値から得られた連続hash bit列は、従来例と同様の転置インデックスのhash値でもある。具体的には、本実施形態では、属性値に対して、keyと同様にhash関数を適用し、そのhash値（図４の符号（Ａ）に示すhash bit列）のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックス（属性検索用）を格納する。
<属性タグから得られた不連続hash bit列>（図４の符号（Ｂ）参照）
図４の符号（Ｂ）に示すように、属性タグから得られた不連続hash bit列「01001100101101」は、属性タグを不連続なＭＤ５等のhash関数に適用して得られたhash値である。一例を挙げる。「居住地」が「東京」であるとすると、属性値は「東京」、属性タグは「居住地」となる。なお、「居住地」が「東京」であることは「属性」となる。この「属性」とは、key に紐付いたデータの中身である。前記図１０を参照して説明すると、図１０のマスターデータｖ０について、ｖ０は属性値（属性）であり、属性値ｖ０がどこのデータかということはkey により関係が紐付けられている。属性値（属性）とkey とは、例えば一対一で関係が紐付けられている。
図４の符号（Ｂ）に示すように、属性タグから得られた不連続hash bit列「01001100101101」は、属性タグを不連続なＭＤ５等のhash関数に適用して得られたhash値である。一例を挙げる。「居住地」が「東京」であるとすると、属性値は「東京」、属性タグは「居住地」となる。なお、「居住地」が「東京」であることは「属性」となる。この「属性」とは、key に紐付いたデータの中身である。前記図１０を参照して説明すると、図１０のマスターデータｖ０について、ｖ０は属性値（属性）であり、属性値ｖ０がどこのデータかということはkey により関係が紐付けられている。属性値（属性）とkey とは、例えば一対一で関係が紐付けられている。
<keyから得られた連続hash bit列>（図４の符号（Ｃ）参照）
図４の符号（Ｃ）に示すように、keyから得られた連続hash bit列「111010101101000」は、keyを連続なhash関数に適用して得られたhash値である。
図４の符号（Ｃ）に示すように、keyから得られた連続hash bit列「111010101101000」は、keyを連続なhash関数に適用して得られたhash値である。
ここで、一般的には、転置インデックスを作成する場合、属性値は属性値で、keyはkeyで使用し、本実施形態のように、属性値にkeyを組み合わせてhash値とすることはない。当然のことながら、属性値から得られた連続hash bit列と属性タグから得られた不連続hash bit列とを結合させるものもなく、属性値から得られた連続hash bit列とkeyから得られた連続hash bit列とを結合させるものもない。
次に、「属性値から得られた連続hash bit列」（図４の符号（Ａ）参照）と、「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）と、「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）と、の各bit列の結合手法について説明する。
上記結合とは、各hash値を文字列レベルで繋げることである。本実施形態では、各hash値をhash bit列で表しており、この場合、あるhash bit列に他のhash bit列を単に繋ぎ合せる。
上記結合とは、各hash値を文字列レベルで繋げることである。本実施形態では、各hash値をhash bit列で表しており、この場合、あるhash bit列に他のhash bit列を単に繋ぎ合せる。
図４の場合、上位桁が属性タグから得られた不連続hash bit列「01001100101101」（図４の符号（Ｂ）参照）、下位桁が属性値から得られた連続hash bit列「00000101101101」（図４の符号（Ａ）参照）であり、図４の符号アに示すように、上位桁のbit列の最後尾に、下位桁のbit列の先頭を繋ぎ合せる。同様に、図４の符号イに示すように、上位桁の属性値から得られた連続hash bit列「00000101101101」（図４の符号（Ａ）参照）の最後尾に、下位桁の「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）の先頭を繋ぎ合せる。なお、上記各hash bit列のビット長は図３において規定されているが、総bit長をhash空間に揃えることを前提として、属性値の検索のされ方に応じて調整される（図５で後記する）。
本実施形態は、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」を元に、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の上位bitに図４の符号（Ｂ）に示す「属性タグから得られた不連続hash bit列」を結合する<手法１>と、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の下位bitに図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」を結合する<手法２>と、がありそれぞれ特有の作用効果を有する。
<手法１>
手法１は、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」に対し、図４の符号（Ｂ）に示す「属性タグから得られた不連続hash bit列」を、上位bitに結合する。
図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の上位bitに図４の符号（Ｂ）に示す「属性タグから得られた不連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
手法１は、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」に対し、図４の符号（Ｂ）に示す「属性タグから得られた不連続hash bit列」を、上位bitに結合する。
図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の上位bitに図４の符号（Ｂ）に示す「属性タグから得られた不連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
すなわち、上位桁である「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）には、なんらかの数値がしかも不連続で入っている。また、この「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）の最上位bit列から順に読み出される。したがって、上記結合された全体を一つの数値としてみた場合、上位桁である「属性タグから得られた不連続hash bit列」は、０から始まらない。
図４の符号ａは、縦軸にデータの頻度を、横軸にhash値をとり、属性タグ１，２，３を上記頻度およびhash値で表した図である。
図４の符号ａの左図に示すように、従来例では、hash空間における属性タグ１，２，３の分布の位置が重なりあう。これに対して、手法１を用いると、図４の符号ａの右図の例に示すように、属性タグ１，２，３毎に分布する範囲（データの最頻値の発生地点）がランダムにずれる。これにより、属性値が一様分布だったとしても、前方の領域（hash空間で値が小さい範囲の領域）に集中してしまう（課題３）を解消することができ、複数の文字列による分布の重ね合わせを平準化する効果がもたらされる。その結果、サーバの負荷の偏りを緩和させることができる。
図４の符号ａの左図に示すように、従来例では、hash空間における属性タグ１，２，３の分布の位置が重なりあう。これに対して、手法１を用いると、図４の符号ａの右図の例に示すように、属性タグ１，２，３毎に分布する範囲（データの最頻値の発生地点）がランダムにずれる。これにより、属性値が一様分布だったとしても、前方の領域（hash空間で値が小さい範囲の領域）に集中してしまう（課題３）を解消することができ、複数の文字列による分布の重ね合わせを平準化する効果がもたらされる。その結果、サーバの負荷の偏りを緩和させることができる。
<手法２>
手法２は、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」に対し、図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」を、下位bitに結合する。
図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の下位bitに図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
手法２は、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」に対し、図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」を、下位bitに結合する。
図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の下位bitに図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
すなわち、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」のみであると、例えば前記図１１（Ｂ）の男性と女性のようにバリエーションが少ない場合、図４の符号ｂの左図に示すように、分布（データの最頻値）が鋭いピークを持つことになる。これに対して、手法２を用いると、図４の符号ｂの右図の例に示すように、図４の符号（Ａ）に示す「属性値から得られた連続hash bit列」の下位bitに図４の符号（Ｃ）に示す「keyから得られた連続hash bit列」が結合されることで、ピークを低くした分布にすることができる。上記の例では、「keyから得られた連続hash bit列」が結合されることによって、男性と女性のデータであってもkeyは異なるので、同じ属性値であってもkeyが異なる場合において一定の分散効果がもたらされる。これにより、属性値を特定の範囲内で分散させることができる。単一分布内の偏り（課題１）や、取り得る値の少なさによる集中化（課題２）に対しても、負荷を平準化することができる。
上記<手法１>と上記<手法２>とは、それぞれ単独で適用してもよく、併用してもよい。上記単独で適用した場合は、<手法１>では（課題３）解決効果、<手法２>では（課題１）および（課題２）解決効果を得ることができる。また、上記<手法１>と上記<手法２>とを併用した場合は、（課題１）〜（課題３）のすべての解決効果を得ることができる。
[実施例]
図５は、属性値の検索のされ方の想定に応じて、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）の各hash bit列のbit長を調整する説明図である。
属性値の検索のされ方の想定に応じて、図５（ａ）〜（ｃ）に示すように、符号（Ａ）の属性値から得られた連続hash bit列、符号（Ｂ）の属性タグから得られた不連続hash bit列、および符号（Ｃ）のkeyから得られた連続hash bit列の各bit長を調整する。但し、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）の各hash bit列において、総bit長はhash空間に揃えるようにする。なお、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）は、図４の符号（Ａ）〜（Ｃ）にそれぞれ対応している。
図５は、属性値の検索のされ方の想定に応じて、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）の各hash bit列のbit長を調整する説明図である。
属性値の検索のされ方の想定に応じて、図５（ａ）〜（ｃ）に示すように、符号（Ａ）の属性値から得られた連続hash bit列、符号（Ｂ）の属性タグから得られた不連続hash bit列、および符号（Ｃ）のkeyから得られた連続hash bit列の各bit長を調整する。但し、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）の各hash bit列において、総bit長はhash空間に揃えるようにする。なお、図５（ａ）〜（ｃ）の符号（Ａ）〜（Ｃ）は、図４の符号（Ａ）〜（Ｃ）にそれぞれ対応している。
<例１>性別、真偽などの属性値の検索の場合（図５（ａ）参照）
性別、真偽などの属性値は、範囲検索等はなく、属性値の種類が少ない特徴がある。
図５（ａ）に示すように、性別、真偽などの属性値は、属性値の種類が少ないので、実質的に符号（Ｂ）の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号（Ｃ）のkeyから得られた連続hash bit列「0010011101010110100」とが支配的になる。符号（Ｂ）の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号（Ｃ）のkeyから得られた連続hash bit列「0010011101010110100」のbit長を長くする調整を行うため、符号（Ａ）の属性値から得られた連続hash bit列「101」のbit長を短くしている。
性別、真偽などの属性値は、範囲検索等はなく、属性値の種類が少ない特徴がある。
図５（ａ）に示すように、性別、真偽などの属性値は、属性値の種類が少ないので、実質的に符号（Ｂ）の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号（Ｃ）のkeyから得られた連続hash bit列「0010011101010110100」とが支配的になる。符号（Ｂ）の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号（Ｃ）のkeyから得られた連続hash bit列「0010011101010110100」のbit長を長くする調整を行うため、符号（Ａ）の属性値から得られた連続hash bit列「101」のbit長を短くしている。
<例２>居住地などある程度定型化された短文字列などの属性値の検索の場合（図５（ｂ）参照）
短文字列などの属性値の検索の場合、図５（ｂ）に示すように、符号（Ａ）の属性値から得られた連続hash bit列「00000101101101」が支配的になる。短文字列などの属性値の検索の場合、この属性値に対して、keyと同様にhash関数を適用し、そのhash値（hash bit列）のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックスを格納することで、効率的な転置インデックスを実現することができる。
短文字列などの属性値の検索の場合、図５（ｂ）に示すように、符号（Ａ）の属性値から得られた連続hash bit列「00000101101101」が支配的になる。短文字列などの属性値の検索の場合、この属性値に対して、keyと同様にhash関数を適用し、そのhash値（hash bit列）のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックスを格納することで、効率的な転置インデックスを実現することができる。
<例３>備考等の自然文の属性値の検索の場合（図５（ｃ）参照）
備考等の自然文の属性値の検索の場合、検索の際に部分一致をされることがある。また、文字数も非常に長大になりがちである。したがって、図５（ｃ）に示すように、符号（Ａ）の備考等の自然文の属性値から得られた連続hash bit列のbit長を長くする。具体的には、備考等の自然文の属性値から得られた連続hash bit列「000001011011010111010」とする。符号（Ａ）の属性値から得られた連続hash bit列のbit長を長くする調整を行うため、符号（Ｃ）のkeyから得られた連続hash bit列「0101101000」のbit長を短くしている。
備考等の自然文の属性値の検索の場合、検索の際に部分一致をされることがある。また、文字数も非常に長大になりがちである。したがって、図５（ｃ）に示すように、符号（Ａ）の備考等の自然文の属性値から得られた連続hash bit列のbit長を長くする。具体的には、備考等の自然文の属性値から得られた連続hash bit列「000001011011010111010」とする。符号（Ａ）の属性値から得られた連続hash bit列のbit長を長くする調整を行うため、符号（Ｃ）のkeyから得られた連続hash bit列「0101101000」のbit長を短くしている。
図６は、hash bit列結合処理を示すフローチャートである。本hash bit列結合処理は、後記する図７の符号ｄ，ｆの処理および図８の符号ｂの処理において実行される。また、属性タグ情報格納手段１１３により、記憶手段４０に属性タグ情報が格納されているものとする。
まず、ステップＳ１で構文解析手段１１２は、情報受信手段１１１から入力データを受け取り、構文解析する。この構文解析により、keyがどこであるか、属性値（value）はどのようなデータがあるかなどが解析される。例えば、Key:aaaが解析されると、マスターデータがどこ置かれるかが分かる。属性タグは、例えば「Location」，「Boolean」などである。
まず、ステップＳ１で構文解析手段１１２は、情報受信手段１１１から入力データを受け取り、構文解析する。この構文解析により、keyがどこであるか、属性値（value）はどのようなデータがあるかなどが解析される。例えば、Key:aaaが解析されると、マスターデータがどこ置かれるかが分かる。属性タグは、例えば「Location」，「Boolean」などである。
ステップＳ２では、制御手段１１０は、属性タグ情報格納手段１１３に格納されたデータを参照して、属性タグ毎のhash関数およびbit長を決定する。
ステップＳ３では、記憶手段４０に記憶された属性タグ情報から取得した属性タグ毎のhash関数 および bit長に基づいて、「属性値から得られた連続hash bit列」（図４の符号（Ａ）参照）と、「属性タグから得られた不連続hash bit列」（図４の符号（Ｂ）参照）と、「keyから得られた連続hash bit列」（図４の符号（Ｃ）参照）とを作成する。
ステップＳ４では、属性値から得られた連続hash bit列の上位bitに、属性タグから得られた不連続hash bit列を結合し、属性値から得られた連続hash bit列の下位bitに、keyから得られた連続hash bit列を結合して本フローを終了する。
≪属性値データの格納（登録）シーケンス≫
次に、図７を参照して、属性値データの格納（登録）シーケンスについて説明する。
次に、図７を参照して、属性値データの格納（登録）シーケンスについて説明する。
まず、クライアント２は、登録したいデータとして、「key:aaa，Location:Tokyo，Boolean:true」（図７の符号ａ参照）を、クラスタシステム１を構成するサーバ（ここでは、一例として説明の便宜上サーバ「＃１」とした）に送信する（ステップＳ１０１）。上記「aaa」はkey、上記「Location」「Boolean」は属性タグ、データの属性は（属性タグ，属性値（value））である。ここで、データの属性は、２つのデータすなわち「Location:Tokyo」「Boolean:true」を例示している。クラスタシステム１は、クライアント２から要求された２つのデータ「Location:Tokyo」「Boolean:true」について、該当するサーバに、転置インデックスを格納することになる。
データを受信したサーバ「＃１」は、keyのaaaにhash関数をかけてその結果に基づいてマスターデータの格納先サーバ（ここではサーバ「＃３」）を決定し（図７の符号ｂ参照）、サーバ「＃３」にデータを送信する（ステップＳ１０２）。
マスターデータの格納先サーバ「＃３」は、例えば隣のサーバ「＃４」にレプリカデータを格納する（図７の符号ｃ参照）（ステップＳ１０３）。
レプリカデータを格納したサーバ「＃４」は、レプリカデータを送信したマスターデータの格納先サーバ「＃３」にＡＣＫを返す（ステップＳ１０４）。
マスターデータの格納先サーバ「＃３」は、例えば隣のサーバ「＃４」にレプリカデータを格納する（図７の符号ｃ参照）（ステップＳ１０３）。
レプリカデータを格納したサーバ「＃４」は、レプリカデータを送信したマスターデータの格納先サーバ「＃３」にＡＣＫを返す（ステップＳ１０４）。
サーバ「＃３」は、クライアント２からサーバ「＃１」を経由して送信されたデータ「key:aaa，Location:Tokyo，Boolean:true」に基づく「Location,Tokyo,aaa」を用いて転置インデックスの格納先を決定する（図７の符号ｄ参照）。上記決定は、具体的には図６のフローを実行して得られた、結合されたhash bit列によるhash空間上の位置に該当するサーバ（ここでは、サーバ「＃５」）に、転置インデックスを格納することである。
データ「Location:Tokyo」における、転置インデックスの格納先は、サーバ「＃５」である。サーバ「＃３」は、転置インデックス格納先サーバ「＃５」にデータ「key:aaa」（図７の符号ｅ参照）を送信する（ステップＳ１０５）。
転置インデックス格納先サーバ「＃５」は、転置インデックスの格納先を送信したサーバ「＃３」にＡＣＫを返す（ステップＳ１０６）。
データ「Location:Tokyo」における、転置インデックスの格納先は、サーバ「＃５」である。サーバ「＃３」は、転置インデックス格納先サーバ「＃５」にデータ「key:aaa」（図７の符号ｅ参照）を送信する（ステップＳ１０５）。
転置インデックス格納先サーバ「＃５」は、転置インデックスの格納先を送信したサーバ「＃３」にＡＣＫを返す（ステップＳ１０６）。
次に、サーバ「＃３」は、クライアント２からサーバ「＃１」を経由して送信されたデータ「key:aaa，Location:Tokyo，Boolean:true」に基づく「Boolean，true，aaa」を用いて転置インデックスの格納先を決定する（図７の符号ｆ参照）。この決定は、前記データ「Location:Tokyo」における、決定（図７の符号ｄ参照）の場合と同様の処理である。
データ「Boolean:true」における、転置インデックスの格納先は、サーバ「＃６」であるとする。サーバ「＃３」は、転置インデックス格納先サーバ「＃６」にデータ「key:aaa」（図７の符号ｇ参照）を送信する（ステップＳ１０７）。
転置インデックス格納先サーバ「＃６」は、転置インデックスの格納先を送信したサーバ「＃３」にＡＣＫを返す（ステップＳ１０８）。
データ「Boolean:true」における、転置インデックスの格納先は、サーバ「＃６」であるとする。サーバ「＃３」は、転置インデックス格納先サーバ「＃６」にデータ「key:aaa」（図７の符号ｇ参照）を送信する（ステップＳ１０７）。
転置インデックス格納先サーバ「＃６」は、転置インデックスの格納先を送信したサーバ「＃３」にＡＣＫを返す（ステップＳ１０８）。
転置インデックス格納先サーバ「＃６」からＡＣＫを受け取ったサーバ「＃３」は、クライアント２からのデータを当初受信したサーバ「＃１」にＡＣＫを返す（ステップＳ１０９）。
そして、サーバ「＃１」は、クライアント２にＡＣＫを返して（ステップＳ１１０）、データの格納（登録）シーケンスを終了する。
そして、サーバ「＃１」は、クライアント２にＡＣＫを返して（ステップＳ１１０）、データの格納（登録）シーケンスを終了する。
このように、属性値データの格納（登録）シーケンスでは、keyを主のhash関数に適用して得られた出力の場所にマスターデータを置き、マスターデータの格納先サーバは、レプリカデータを例えば隣のサーバに置く。そして、マスターデータの格納先サーバは、「Location,Tokyo,aaa」または「Boolean，true，aaa」を用いて、それぞれ、転置インデックスの格納先を決定する。
なお、上記レプリカデータの格納と、「Location,Tokyo,aaa」を用いた転置インデックスの格納先の決定と、「Boolean，true，aaa」を用いた転置インデックスの格納先の決定との時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
なお、上記レプリカデータの格納と、「Location,Tokyo,aaa」を用いた転置インデックスの格納先の決定と、「Boolean，true，aaa」を用いた転置インデックスの格納先の決定との時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
≪属性値データの取得（検索）シーケンス≫
次に、図８および図９を参照して、データの取得（検索）シーケンスについて説明する。
まず、クライアント２は、データの取得（検索）リクエスト「GET Location=Tokyo」を、クラスタシステム１を構成するサーバ「＃１」に送信する（ステップＳ２０１）。
次に、図８および図９を参照して、データの取得（検索）シーケンスについて説明する。
まず、クライアント２は、データの取得（検索）リクエスト「GET Location=Tokyo」を、クラスタシステム１を構成するサーバ「＃１」に送信する（ステップＳ２０１）。
データの取得（検索）リクエストを受信したサーバ「＃１」は、リクエスト毎に処理サーバを決定し（図８の符号ａ参照）、決定した処理サーバ（ここでは、サーバ「＃２」）にその旨を通知する（ステップＳ２０２）。以降、サーバ「＃２」が処理サーバである場合を例に採る。サーバ「＃２」が、当該処理サーバとして処理する期間を、図８および図９のサーバ「＃２」のハッチングで表している。
サーバ「＃２」は、「Location，Tokyo」で転置インデックスが格納されているサーバ集合を特定（ここではサーバ「＃３」「＃４」を想定）する（図８の符号ｂ参照）。上記特定は、具体的には図６のフローを実行して得られた、結合されたhash bit列によるhash空間上の範囲を得て、この範囲に該当するサーバをサーバ集合として特定する。ただし、前記図７の符号ｄ，ｆにおける「決定」では、「key: aaa」が存在したが、この図８の符号ｂにおける「特定」ではkeyはない。そこで、所定のbit列（例えば「0000」〜「1111」）を付与してhash bit列を結合し、hash bit列によるhash空間上の位置に該当するサーバを特定する。
サーバ「＃２」は、まず、前記結合されたhash bit列によるhash空間上の範囲に該当するサーバ「＃３」にkey集合要求を送信する（ステップＳ２０３）。
サーバ「＃３」は、自己が持つ「Location，Tokyo」を基に、サーバ「＃２」に自己が持っているkey集合「key:xxx」「key:yyy」（図８の符号ｃ，ｄ参照）を送信する（ステップＳ２０４）。
サーバ「＃３」は、自己が持つ「Location，Tokyo」を基に、サーバ「＃２」に自己が持っているkey集合「key:xxx」「key:yyy」（図８の符号ｃ，ｄ参照）を送信する（ステップＳ２０４）。
これにより、サーバ「＃２」は、keyサーバ「＃３」からkey集合「key:xxx」「key:yyy」を取得する（図８の符号ｅ参照）。
同様に、サーバ「＃２」は、前記結合されたhash bit列によるhash空間上の範囲に該当するサーバ「＃４」にkey集合要求を送信する（ステップＳ２０５）。
同様に、サーバ「＃２」は、前記結合されたhash bit列によるhash空間上の範囲に該当するサーバ「＃４」にkey集合要求を送信する（ステップＳ２０５）。
サーバ「＃４」は、サーバ「＃２」に自己が持っているkey集合「key:aaa」「key:bbb」（図８の符号ｆ，ｇ参照）を送信する（ステップＳ２０６）。
これにより、サーバ「＃２」は、サーバ「＃４」からkey集合「key:aaa」「key:bbb」を取得する（図８の符号ｈ参照）。
なお、上記サーバ「＃２」がkeyサーバ「＃３」からkey集合「key:xxx」「key:yyy」を取得するシーケンスと、上記サーバ「＃２」が、サーバ「＃４」からkey集合「key:aaa」「key:bbb」を取得するシーケンスとの時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
以上でサーバ「＃２」は、サーバ「＃３」「＃４」からkey集合「key:xxx」「key:yyy」「key:aaa」「key:bbb」を取得できている。
なお、上記サーバ「＃２」がkeyサーバ「＃３」からkey集合「key:xxx」「key:yyy」を取得するシーケンスと、上記サーバ「＃２」が、サーバ「＃４」からkey集合「key:aaa」「key:bbb」を取得するシーケンスとの時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
以上でサーバ「＃２」は、サーバ「＃３」「＃４」からkey集合「key:xxx」「key:yyy」「key:aaa」「key:bbb」を取得できている。
次に、サーバ「＃２」は、key集合リクエスト「GET key=aaa」をサーバ「＃３」に送信する（ステップＳ２０７）。以下の例では、クライアント２にkeyのみならずその実体（実データ）を返す例である。
サーバ「＃３」は、key情報「key:aaa」を基に、マスタ情報「key:aaa ,Location:Tokyo，Boolean:true」（図８の符号ｉ参照）を取得する（図８の符号ｊ参照）。
サーバ「＃３」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２０８）。
サーバ「＃３」は、key情報「key:aaa」を基に、マスタ情報「key:aaa ,Location:Tokyo，Boolean:true」（図８の符号ｉ参照）を取得する（図８の符号ｊ参照）。
サーバ「＃３」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２０８）。
次に、サーバ「＃２」は、key集合リクエスト「GET key=bbb」をサーバ「＃４」に送信する（ステップＳ２０９）。
サーバ「＃４」は、key情報「key:bbb」を基に、マスタ情報「key:bbb ,Location:Tokyo，Boolean:false」（図９の符号ｋ参照）をマスタを取得する。
サーバ「＃４」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１０）。
サーバ「＃４」は、key情報「key:bbb」を基に、マスタ情報「key:bbb ,Location:Tokyo，Boolean:false」（図９の符号ｋ参照）をマスタを取得する。
サーバ「＃４」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１０）。
次に、サーバ「＃２」は、key集合リクエスト「GET key=xxx」をサーバ「＃５」に送信する（ステップＳ２１１）。
サーバ「＃５」は、key情報「key:xxx」を基に、マスタ情報「key:xxx ,Location:Tokyo，Boolean:false」（図９の符号ｌ参照）を取得する。
サーバ「＃５」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１２）。
サーバ「＃５」は、key情報「key:xxx」を基に、マスタ情報「key:xxx ,Location:Tokyo，Boolean:false」（図９の符号ｌ参照）を取得する。
サーバ「＃５」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１２）。
次に、サーバ「＃２」は、key集合リクエスト「GET key=yyy」をサーバ「＃６」に送信する（ステップＳ２１３）。
サーバ「＃６」は、key情報「key:yyy」を基に、マスタ情報「key:yyy ,Location:Tokyo，Boolean:false」（図９の符号ｍ参照）を取得する。
サーバ「＃６」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１４）。
なお、上記で説明した、サーバ「＃２」がサーバ「＃３」「＃４」「＃５」「＃６」の各々からマスタ情報を取得する各々の処理は、時間的順序として非同期であってもよく、同時に実行する処理であってもよい。
サーバ「＃６」は、key情報「key:yyy」を基に、マスタ情報「key:yyy ,Location:Tokyo，Boolean:false」（図９の符号ｍ参照）を取得する。
サーバ「＃６」は、取得したマスタ情報をサーバ「＃２」に送信する（ステップＳ２１４）。
なお、上記で説明した、サーバ「＃２」がサーバ「＃３」「＃４」「＃５」「＃６」の各々からマスタ情報を取得する各々の処理は、時間的順序として非同期であってもよく、同時に実行する処理であってもよい。
そして、サーバ「＃２」は、全部揃えた状態でクライアント２に各サーバ「＃３」「＃４」「＃５」「＃６」から取得したデータ「key:aaa，Location:Tokyo，Boolean:true」（図９の符号ｎ参照）、「key:bbb，Location:Tokyo，Boolean:false」（図９の符号ｏ参照）、「key:xxx，Location:Tokyo，Boolean:false」（図９の符号ｐ参照）、「key:xxx，Location:Tokyo，Boolean:false」（図９の符号ｑ参照）を送信して（ステップＳ２１５）、データの取得（検索）シーケンスを終了する。
以上説明したように、本実施形態のサーバ１１は、属性値を検索するためのhash関数に基づいて、「属性値から得られた連続hash bit列」と、「属性タグから得られた不連続hash bit列」と、「keyから得られた連続hash bit列」とを作成するhash bit列作成手段１１４と、属性値から得られた連続hash bit列の上位bitに、属性タグから得られた不連続hash bit列を結合し、属性値から得られた連続hash bit列の下位bitに、keyから得られた連続hash bit列を結合する結合手段１１５と、を備える。
そして、「属性値から得られた連続hash bit列」に対し、「属性タグから得られた不連続hash bit列」を、上位bitに結合する。および／または、「属性値から得られた連続hash bit列」に対し、「keyから得られた連続hash bit列」を下位bitに結合する。
そして、「属性値から得られた連続hash bit列」に対し、「属性タグから得られた不連続hash bit列」を、上位bitに結合する。および／または、「属性値から得られた連続hash bit列」に対し、「keyから得られた連続hash bit列」を下位bitに結合する。
これにより、転置インデックスのためのhash関数において、hash bit列を結合した値を用いることで、その特性を失わずに分布を平滑化することができる。「属性値から得られた連続hash bit列」の上位bitに結合する「属性タグから得られた不連続hash bit列」は、属性タグ毎に分布する範囲をずらす役割を果たす。これにより、複数の文字列による分布の重ね合わせを平準化する効果がもたらされる。また、「属性値から得られた連続hash bit列」の下位bitに結合する「keyから得られた連続hash bit列」は、同じ属性値であってもkeyが異なる場合において一定の分散効果がもたらす。これにより、単一分布内の偏りや、取り得る値の少なさによる集中化に対しても、負荷を平準化することができる。
なお、上記したように、「属性値から得られた連続hash bit列」は、連続hash bit列でもよいし不連続hash bit列でもよい。「属性値から得られた不連続hash bit列」でも同様な効果を得ることができる。
１ クラスタシステム
２ クライアント
１１ サーバ
２０ 入出力手段
３０ メモリ手段
４０ 記憶手段
１１０ 制御手段
１１１ 情報受信手段
１１２ 構文解析手段
１１３ 属性タグ情報格納手段
１１４ hash bit列作成手段
１１５ 結合手段
１１６ 情報送信手段
２ クライアント
１１ サーバ
２０ 入出力手段
３０ メモリ手段
４０ 記憶手段
１１０ 制御手段
１１１ 情報受信手段
１１２ 構文解析手段
１１３ 属性タグ情報格納手段
１１４ hash bit列作成手段
１１５ 結合手段
１１６ 情報送信手段
Claims (4)
- 属性タグと属性値にkeyを付して、当該属性値を検索するためのhash関数を適用し、得られたhash値のhash空間上の位置に該当するサーバに、転置インデックスを格納するクラスタシステム、を構成する各前記サーバとしてのコンピュータを、
前記属性値を検索するためのhash関数に基づいて、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列、のいずれかを含むhash bit列を作成するhash bit列作成手段、
少なくとも、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列とを結合する、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列とを結合する結合手段、として機能させるためのプログラム。 - 前記結合手段は、
前記属性値から得られたhash bit列の上位bitに、前記属性タグから得られたhash bit列を結合すること
を特徴とする請求項１に記載のプログラム。 - 前記結合手段は、
前記属性値から得られたhash bit列の下位bitに、前記keyから得られたhash bit列を結合すること
を特徴とする請求項１に記載のプログラム。 - 属性タグと属性値にkeyを付して、当該属性値を検索するためのhash関数を適用し、得られたhash値のhash空間上の位置に該当するサーバに、転置インデックスを格納するクラスタシステムであって、
前記サーバは、
前記属性値を検索するためのhash関数に基づいて、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列、のいずれかを含むhash bit列を作成するhash bit列作成手段と、
少なくとも、前記属性値から得られたhash bit列と前記属性タグから得られた不連続hash bit列とを結合する、または、前記属性値から得られたhash bit列と前記keyから得られたhash bit列とを結合する結合手段と、を備えること
を特徴とするクラスタシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014178321A JP6192171B2 (ja) | 2014-09-02 | 2014-09-02 | プログラムおよびクラスタシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014178321A JP6192171B2 (ja) | 2014-09-02 | 2014-09-02 | プログラムおよびクラスタシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2016051453A JP2016051453A (ja) | 2016-04-11 |
| JP6192171B2 true JP6192171B2 (ja) | 2017-09-06 |
Family
ID=55658874
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014178321A Active JP6192171B2 (ja) | 2014-09-02 | 2014-09-02 | プログラムおよびクラスタシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6192171B2 (ja) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5727197A (en) * | 1995-11-01 | 1998-03-10 | Filetek, Inc. | Method and apparatus for segmenting a database |
| US7801871B2 (en) * | 2005-08-09 | 2010-09-21 | Nexsan Technologies Canada Inc. | Data archiving system |
| JP5310399B2 (ja) * | 2009-09-01 | 2013-10-09 | 富士通株式会社 | 索引管理装置の処理方法および索引管理装置 |
| JP5684671B2 (ja) * | 2011-08-05 | 2015-03-18 | 日本電信電話株式会社 | 条件検索データ保存方法、条件検索データベースクラスタシステム、ディスパッチャ、およびプログラム |
| JP5597666B2 (ja) * | 2012-03-26 | 2014-10-01 | 株式会社東芝 | 半導体記憶装置、情報処理システムおよび制御方法 |
-
2014
- 2014-09-02 JP JP2014178321A patent/JP6192171B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2016051453A (ja) | 2016-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10122380B2 (en) | Compression of javascript object notation data using structure information | |
| CN1684464B (zh) | 用于在本地装置和远程装置间更新对象的方法和*** | |
| US20200117733A1 (en) | Blockchain integration layer | |
| KR102148691B1 (ko) | 정보 검색 방법 및 장치 | |
| US10331694B2 (en) | Data sanitization and normalization and geocoding methods | |
| KR20130062889A (ko) | 데이터 압축 방법 및 시스템 | |
| US10275229B2 (en) | Encoded data object notation persistence format | |
| JP6849723B2 (ja) | 情報を生成するための方法及び装置 | |
| US11030242B1 (en) | Indexing and querying semi-structured documents using a key-value store | |
| US11070231B2 (en) | Reducing storage of blockchain metadata via dictionary-style compression | |
| CN110737663B (zh) | 一种数据存储方法、装置、设备及存储介质 | |
| US11138152B2 (en) | Method and system for content agnostic file indexing | |
| US10902069B2 (en) | Distributed indexing and aggregation | |
| US20210109925A1 (en) | Information management device, information management method, and information management program | |
| AU2014353667A1 (en) | A method of generating a reference index data structure and method for finding a position of a data pattern in a reference data structure | |
| US10354748B1 (en) | Storing genetic data in a storage system | |
| US20190278757A1 (en) | Distributed Database Management System with Dynamically Split B-Tree Indexes | |
| US20030188264A1 (en) | Method and apparatus for XML data normalization | |
| US11093525B2 (en) | Transaction merging for offline applications | |
| JP2017511552A (ja) | ストレージ効率がよく、無条件に安全な個人情報の検索 | |
| US11544225B2 (en) | Method and system for content agnostic file indexing | |
| CN110555178B (zh) | 数据代理方法及装置 | |
| JP5684671B2 (ja) | 条件検索データ保存方法、条件検索データベースクラスタシステム、ディスパッチャ、およびプログラム | |
| JP6192171B2 (ja) | プログラムおよびクラスタシステム | |
| Mishra et al. | Fast pattern matching in compressed text using wavelet tree |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160921 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170721 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20170801 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20170804 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6192171 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |