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
現在広く利用されているデータベース(DB)として、RDB(Relational Data Base)が存在する。このRDBの技術は、Row(行)、Column(列)からなる2次元のテーブル構造でデータを表現し、SQL(Structured Query Language)言語等によるクエリに応じて、JOIN(結合)や正規化を実行することで、検索等の処理を実現することができる。様々なアプリケーションは、RDBを用いて作成されることが多く、その理由は多岐に渡るが、特に重要な要素として、単純なkey検索だけでなく、データの属性値(value)でも検索できる機能を有するところが大きいと言える。但し、従来の分散システムでは、単純なkeyを用いたアプリケーションには適用できるが、valueを操作するアプリケーションには適用できないか、できてもスケールしない状況のものが多かった。しかもデータの構造を分散プラットフォーム(PF)用に大きく見直す必要もあった。
分散システムの研究分野でも、上記を鑑み、単純key検索用途のNoSQLから、属性値検索を始めとしたRDB並みの操作能力を持つNewSQLへの検討が多くされつつある。
また、レプリカデータをリンクとして、データ容量の効率性を高めたMerDyという手法も存在する。
MerDyは、転置インデックス(属性検索用)を用いて、属性値による検索を可能にする分散DBにおいて、データの場所を示す識別子(hash値)を付与する。分散DBにおけるデータ配置のサーバへの配置の決定方法としては、データの属性タグや属性値等にhash値をかけて識別子とする。一方、サーバ毎に担当する識別子領域を割り当ててある。
上記別のhash関数は、「属性値を検索するためのhash関数」であり、検索したい属性値に対して適用される上記主のhash関数とは別の、属性値で検索されるh1(v0),h2(v1),h3(v2)である。例えば、h1(v0)は、文字コード変換などの連続hash関数、h2(v1)は、文字数などの連続hash関数、h3(v2)は、SHA1(Secure Hash Algorithm 1)などの不連続なhash関数である。なお、後記する図11および図12において、転置インデックス(属性検索用)のkeyをk1,k2,…で表すことがある。
しかしながら、この非特許文献1,2の手法では、新規データ生成時やデータ更新時において各属性値の転置インデックスを作成してサーバに配置する必要があるため、属性値のパターンにおいては負荷に偏りや集中が発生する可能性がある。属性値は、性別や血液型等、種類が少ないものや、都道府県など極端な偏りがあるものも存在し、そのまま扱うとクラスタ内の負荷の偏りによりスケールしない事態が発生する。例えば、真理値等のような取り得る値の少ない属性値や居住地等のような偏在する属性値では、クラスタ内のサーバ負荷が偏るという問題があった。すなわち、メモリ量の増大もさることながら、書き込みの際の転置インデックス作成自体の負荷でボトルネックになり、スケーラビリティが損なわれる。
図11の符号(A)に示すように、居住地(都道府県等)のバリエーションはあるものの、東京に住んでいる人口が圧倒的に多い「偏りが大きい属性値」である場合(課題1)や、図11の符号(B)に示すように、男性と女性、真理値等のようなバリエーションが少なすぎる「取り得る値の種類が少ない属性値」である場合がある(課題2)。
このような属性値の場合、転置インデックスが極端に偏り、負荷が集中してしまい、スケーラビリティが損なわれる。
本実施形態に係るクラスタシステム1について具体的に説明する。
図2に示すように、サーバ11は、制御手段110、入出力手段20は、メモリ手段30、および記憶手段40を含んで構成される。
図4は、「属性値を検索するためのhash関数」のbit列の構成を説明する図である。
図4に示すように、「属性値を検索するためのhash関数」のbit列は、「属性値から得られた連続hash bit列」(図4の符号(A)参照)と、「属性タグから得られた不連続hash bit列」(図4の符号(B)参照)と、「keyから得られた連続hash bit列」(図4の符号(C)参照)と、から構成される。
なお、図4の符号(A)に示す属性値から得られた連続hash bit列は、不連続hash bit列であってもよい。また、各hash bit列のビット長については、図5により後記する。
図4の符号(A)に示すように、属性値から得られた連続hash bit列「00000101101101」は、転置インデックス(属性検索用)のhash値である。なお、図4の符号(A)に示す属性値から得られた連続hash bit列は、従来例と同様の転置インデックスのhash値でもある。具体的には、本実施形態では、属性値に対して、keyと同様にhash関数を適用し、そのhash値(図4の符号(A)に示すhash bit列)のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックス(属性検索用)を格納する。
図4の符号(B)に示すように、属性タグから得られた不連続hash bit列「01001100101101」は、属性タグを不連続なMD5等のhash関数に適用して得られたhash値である。一例を挙げる。「居住地」が「東京」であるとすると、属性値は「東京」、属性タグは「居住地」となる。なお、「居住地」が「東京」であることは「属性」となる。この「属性」とは、key に紐付いたデータの中身である。前記図10を参照して説明すると、図10のマスターデータv0について、v0は属性値(属性)であり、属性値v0がどこのデータかということはkey により関係が紐付けられている。属性値(属性)とkey とは、例えば一対一で関係が紐付けられている。
図4の符号(C)に示すように、keyから得られた連続hash bit列「111010101101000」は、keyを連続なhash関数に適用して得られたhash値である。
上記結合とは、各hash値を文字列レベルで繋げることである。本実施形態では、各hash値をhash bit列で表しており、この場合、あるhash bit列に他のhash bit列を単に繋ぎ合せる。
手法1は、図4の符号(A)に示す「属性値から得られた連続hash bit列」に対し、図4の符号(B)に示す「属性タグから得られた不連続hash bit列」を、上位bitに結合する。
図4の符号(A)に示す「属性値から得られた連続hash bit列」の上位bitに図4の符号(B)に示す「属性タグから得られた不連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
図4の符号aの左図に示すように、従来例では、hash空間における属性タグ1,2,3の分布の位置が重なりあう。これに対して、手法1を用いると、図4の符号aの右図の例に示すように、属性タグ1,2,3毎に分布する範囲(データの最頻値の発生地点)がランダムにずれる。これにより、属性値が一様分布だったとしても、前方の領域(hash空間で値が小さい範囲の領域)に集中してしまう(課題3)を解消することができ、複数の文字列による分布の重ね合わせを平準化する効果がもたらされる。その結果、サーバの負荷の偏りを緩和させることができる。
手法2は、図4の符号(A)に示す「属性値から得られた連続hash bit列」に対し、図4の符号(C)に示す「keyから得られた連続hash bit列」を、下位bitに結合する。
図4の符号(A)に示す「属性値から得られた連続hash bit列」の下位bitに図4の符号(C)に示す「keyから得られた連続hash bit列」が結合されてhash bit列が作成されることで下記の作用効果がある。
図5は、属性値の検索のされ方の想定に応じて、図5(a)〜(c)の符号(A)〜(C)の各hash bit列のbit長を調整する説明図である。
属性値の検索のされ方の想定に応じて、図5(a)〜(c)に示すように、符号(A)の属性値から得られた連続hash bit列、符号(B)の属性タグから得られた不連続hash bit列、および符号(C)のkeyから得られた連続hash bit列の各bit長を調整する。但し、図5(a)〜(c)の符号(A)〜(C)の各hash bit列において、総bit長はhash空間に揃えるようにする。なお、図5(a)〜(c)の符号(A)〜(C)は、図4の符号(A)〜(C)にそれぞれ対応している。
性別、真偽などの属性値は、範囲検索等はなく、属性値の種類が少ない特徴がある。
図5(a)に示すように、性別、真偽などの属性値は、属性値の種類が少ないので、実質的に符号(B)の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号(C)のkeyから得られた連続hash bit列「0010011101010110100」とが支配的になる。符号(B)の属性タグから得られた不連続hash bit列「010011001011011110010101」と符号(C)のkeyから得られた連続hash bit列「0010011101010110100」のbit長を長くする調整を行うため、符号(A)の属性値から得られた連続hash bit列「101」のbit長を短くしている。
短文字列などの属性値の検索の場合、図5(b)に示すように、符号(A)の属性値から得られた連続hash bit列「00000101101101」が支配的になる。短文字列などの属性値の検索の場合、この属性値に対して、keyと同様にhash関数を適用し、そのhash値(hash bit列)のコンシステントハッシュ等の空間上の位置に該当するサーバに、転置インデックスを格納することで、効率的な転置インデックスを実現することができる。
備考等の自然文の属性値の検索の場合、検索の際に部分一致をされることがある。また、文字数も非常に長大になりがちである。したがって、図5(c)に示すように、符号(A)の備考等の自然文の属性値から得られた連続hash bit列のbit長を長くする。具体的には、備考等の自然文の属性値から得られた連続hash bit列「000001011011010111010」とする。符号(A)の属性値から得られた連続hash bit列のbit長を長くする調整を行うため、符号(C)のkeyから得られた連続hash bit列「0101101000」のbit長を短くしている。
まず、ステップS1で構文解析手段112は、情報受信手段111から入力データを受け取り、構文解析する。この構文解析により、keyがどこであるか、属性値(value)はどのようなデータがあるかなどが解析される。例えば、Key:aaaが解析されると、マスターデータがどこ置かれるかが分かる。属性タグは、例えば「Location」,「Boolean」などである。
次に、図7を参照して、属性値データの格納(登録)シーケンスについて説明する。
マスターデータの格納先サーバ「#3」は、例えば隣のサーバ「#4」にレプリカデータを格納する(図7の符号c参照)(ステップS103)。
レプリカデータを格納したサーバ「#4」は、レプリカデータを送信したマスターデータの格納先サーバ「#3」にACKを返す(ステップS104)。
データ「Location:Tokyo」における、転置インデックスの格納先は、サーバ「#5」である。サーバ「#3」は、転置インデックス格納先サーバ「#5」にデータ「key:aaa」(図7の符号e参照)を送信する(ステップS105)。
転置インデックス格納先サーバ「#5」は、転置インデックスの格納先を送信したサーバ「#3」にACKを返す(ステップS106)。
データ「Boolean:true」における、転置インデックスの格納先は、サーバ「#6」であるとする。サーバ「#3」は、転置インデックス格納先サーバ「#6」にデータ「key:aaa」(図7の符号g参照)を送信する(ステップS107)。
転置インデックス格納先サーバ「#6」は、転置インデックスの格納先を送信したサーバ「#3」にACKを返す(ステップS108)。
そして、サーバ「#1」は、クライアント2にACKを返して(ステップS110)、データの格納(登録)シーケンスを終了する。
なお、上記レプリカデータの格納と、「Location,Tokyo,aaa」を用いた転置インデックスの格納先の決定と、「Boolean,true,aaa」を用いた転置インデックスの格納先の決定との時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
次に、図8および図9を参照して、データの取得(検索)シーケンスについて説明する。
まず、クライアント2は、データの取得(検索)リクエスト「GET Location=Tokyo」を、クラスタシステム1を構成するサーバ「#1」に送信する(ステップS201)。
サーバ「#3」は、自己が持つ「Location,Tokyo」を基に、サーバ「#2」に自己が持っているkey集合「key:xxx」「key:yyy」(図8の符号c,d参照)を送信する(ステップS204)。
同様に、サーバ「#2」は、前記結合されたhash bit列によるhash空間上の範囲に該当するサーバ「#4」にkey集合要求を送信する(ステップS205)。
なお、上記サーバ「#2」がkeyサーバ「#3」からkey集合「key:xxx」「key:yyy」を取得するシーケンスと、上記サーバ「#2」が、サーバ「#4」からkey集合「key:aaa」「key:bbb」を取得するシーケンスとの時間的順序は、非同期であってもよく、同時に実行するシーケンスであってもよい。
以上でサーバ「#2」は、サーバ「#3」「#4」からkey集合「key:xxx」「key:yyy」「key:aaa」「key:bbb」を取得できている。
サーバ「#3」は、key情報「key:aaa」を基に、マスタ情報「key:aaa ,Location:Tokyo,Boolean:true」(図8の符号i参照)を取得する(図8の符号j参照)。
サーバ「#3」は、取得したマスタ情報をサーバ「#2」に送信する(ステップS208)。
サーバ「#4」は、key情報「key:bbb」を基に、マスタ情報「key:bbb ,Location:Tokyo,Boolean:false」(図9の符号k参照)をマスタを取得する。
サーバ「#4」は、取得したマスタ情報をサーバ「#2」に送信する(ステップS210)。
サーバ「#5」は、key情報「key:xxx」を基に、マスタ情報「key:xxx ,Location:Tokyo,Boolean:false」(図9の符号l参照)を取得する。
サーバ「#5」は、取得したマスタ情報をサーバ「#2」に送信する(ステップS212)。
サーバ「#6」は、key情報「key:yyy」を基に、マスタ情報「key:yyy ,Location:Tokyo,Boolean:false」(図9の符号m参照)を取得する。
サーバ「#6」は、取得したマスタ情報をサーバ「#2」に送信する(ステップS214)。
なお、上記で説明した、サーバ「#2」がサーバ「#3」「#4」「#5」「#6」の各々からマスタ情報を取得する各々の処理は、時間的順序として非同期であってもよく、同時に実行する処理であってもよい。
そして、「属性値から得られた連続hash bit列」に対し、「属性タグから得られた不連続hash bit列」を、上位bitに結合する。および/または、「属性値から得られた連続hash bit列」に対し、「keyから得られた連続hash bit列」を下位bitに結合する。
2 クライアント
11 サーバ
20 入出力手段
30 メモリ手段
40 記憶手段
110 制御手段
111 情報受信手段
112 構文解析手段
113 属性タグ情報格納手段
114 hash bit列作成手段
115 結合手段
116 情報送信手段
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列を結合すること
を特徴とする請求項1に記載のプログラム。 - 前記結合手段は、
前記属性値から得られたhash bit列の下位bitに、前記keyから得られたhash bit列を結合すること
を特徴とする請求項1に記載のプログラム。 - 属性タグと属性値に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 |