JP2007310845A - データ処理システム - Google Patents
データ処理システム Download PDFInfo
- Publication number
- JP2007310845A JP2007310845A JP2006142176A JP2006142176A JP2007310845A JP 2007310845 A JP2007310845 A JP 2007310845A JP 2006142176 A JP2006142176 A JP 2006142176A JP 2006142176 A JP2006142176 A JP 2006142176A JP 2007310845 A JP2007310845 A JP 2007310845A
- Authority
- JP
- Japan
- Prior art keywords
- data
- server
- key item
- value
- key
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【解決手段】DBサーバ14とAPサーバ12を備えたデータ処理システム10。APサーバ12は、メモリ26と、DBサーバ14に対しテーブルのキー項目に係るデータの読み出しを指令するデータ処理部22と、DBサーバ14から送信されたデータを圧縮し、メモリ26にインデックスとして格納するインデックス生成部24を備える。
【効果】テーブルのキー項目の内容がAPサーバ12のメモリ26上にキャッシュされているため、DBサーバ14に検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだSQL文の発行が可能となり、DBサーバ14におけるレンジスキャンの低減が可能。
【選択図】図1
Description
また、処理速度の向上を図るため、複数のAPサーバを並列配置させることで負荷を分散させることも行われている。
もちろん、データベースシステムのベンダ各社は、様々な技術を駆使してソフトウェア及びハードウェアの両面からDBサーバ自体の高速化を図ってきており、その結果一定の成果は上がっているが、その分システムの価格が上昇することは否めない。
また、今後ともクライアントサーバ型システムに担わされるデータベースの規模が増大を続ける限り、いずれはディスクI/O(データの読み書き)速度が壁となり、DBサーバの性能アップでは対応できない時期が来るものと予想される。
すなわち、図2に示すテーブルを例に説明すると、APサーバがSQL文を発行する際に日付、店Cd(店コード)、商品Cd(商品コード)のキー項目の値を全て指定してやれば、目的のレコードが一意に決まるためDBサーバは即座に必要なデータにアクセス可能となる。
これに対し、SQL文中で日付、店Cdのみを指定してデータの抽出を命令した場合、DBサーバは指定された日付、商品Cdに係る全てのレコードを先頭レコードから走査して該当のレコードを抽出する必要が生じ、その分時間を要することとなる。
しかしながら、キー項目の数が多くなり、その組合せパターンが複雑化する場合には一次インデックス、二次インデックス…というように予想される検索パターンに対応したインデックスファイルを多数準備する必要が生じ、かえってディスクI/Oが増加する結果となる。
ロードバランサ16と各APサーバ12間、及び各APサーバ12とDBサーバ14間はネットワークによって接続されている。
また、各APサーバ12に対しては、イントラネット18やインターネット等のネットワーク及びロードバランサ16を介して多数のクライアント端末20が接続されている。
各APサーバ12のハードディスク27には、OS及びこのシステム専用のアプリケーションプログラムがセットアップされており、APサーバ12のCPUがこれらのプログラムに従って動作することにより、上記のデータ処理部22及びインデックス生成部24が実現される。
データベース管理システム28は、データベース30を管理し、データベース30に格納されたデータの入出力、更新、および所定の演算などを行う。
これらの中、日付、店Cd、商品Cdのデータ項目は、各レコードを特定するためのキー項目であり、扱いフラグ、在庫数、売上数のデータ項目は、各レコードの属性項目である。
また、日付は最上位のキー項目に相当し、店Cd、商品Cdは下位キー項目に相当する(商品コードは最下位のキー項目)。
まず、APサーバ12のデータ処理部22が起動すると(S10)、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする(S11)。
この際データ処理部22は、例えば図2のテーブルに格納された各レコードを、日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
インデックス生成部24は、各レコードの日付及び店コードの値を、先行するレコードの日付及び店コードの値と比較する(S13)。
ここで、先行レコードに係るデータとの重複が認められた場合(S14のYES)、インデックス生成部24は当該データを削除した後、先行レコードに係るデータを参照する型に置き換える(S16)。
これに対し、先行レコードに係るデータとの重複が認められない場合(S14のNO)、インデックス生成部24は当該日付及び店コードをそのまま(実データとして)メモリ26に格納する(S15)。
図示の通り、日付(20060315)及び店コード(600)のデータは先頭レコードについてのみ実データとして残されており、他のレコードの日付及び店コードはこれらの値を参照する形式で表現されている。
また、商品コードの「491234567890」、「491234567891」、「491234567892」及び「491234567893」に関しては、何れも先行データとの重複が存在しないため、そのまま実データとして残されている。
この場合、日付「20060315」及び商品コードの「491234567891」、「491234567893」については重複するデータが先行のデータグループに存在するため(図5(a))、インデックス生成部24はこれらを削除すると共に、先行グループの実体データを参照する型に置き換える(S16)。
また、店コード「601」については重複するデータが先行グループに存在しないため、先頭レコードに係る店コードはそのまま実データとして維持されるのに対し(S15)、次のレコードの店コードはこれを参照する型に置き換えられる(S16)。
このように、重複するデータについては一の実データのみを残し、他はこれを参照する型に置き換えることにより、大幅なデータ量の削減効果が得られるため、比較的大規模なテーブルであっても、APサーバ12のメモリ26上にそのキー項目値の存在を示すデータをキャッシュすることが可能となる。
APサーバ12のデータ処理部22は、定期的にS11〜S18の処理を実行することにより、インデックスデータの内容をアップデートする。
例えば、クライアント端末20から日付及び店コードのみを指定した検索リクエストが送信された場合であっても、APサーバ12のメモリ26上には「日付×店」配下の商品コードが全てキャッシュされているため、データ処理部22は当該「日付×店」に係る商品コードを全て取得可能となる。
これに対しDBサーバ14は、該当のレコードをデータベース30から抽出し、APサーバ12に送信する。
これを受けたデータ処理部22は、所定の形式に加工した上で、クライアント端末20に送信する(S22)。
この結果、DBサーバ14においてレンジスキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
まず図7は、テーブルのインデックス情報を、APサーバ12のハードディスク27内にフォルダ−ファイル形式で表現した例を示している。
この場合、データ処理部22からテーブルのキー項目データを受け取ったインデックス生成部24は、ハードディスク27の「Cache」フォルダ配下に「Shohin tbl」フォルダを生成し、その中に上位キー項目である日付に対応した「20060315」、「20060316」、「20060317」のフォルダを順に生成し、各フォルダに下位キー項目である店コードに対応した「600」、「601」、「602」のファイル名を有するテキストファイルを格納する。
また、各テキストファイルには、インデックス生成部24によって日付×店コード配下の商品コードが記述されている。
まず、APサーバ12のデータ処理部22が起動すると(S30)、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする(S31)。
この際データ処理部22は、上記と同様、図2のテーブルに格納された各レコードを日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
インデックス生成部24は、各レコードの日付と店コードに重複する値が存在するか否かをチェックし、重複がある場合には一つの日付及び一つの店コードを残し、他のデータを除去した後、メモリ26に各データを格納する(S33)。
図9は、メモリ26に格納されたデータのイメージを示すものであり、(a)は2006年3月15日の店コード:600店に係るグループのデータに対応している。図示の通り、日付(20060315)及び店コード(600)のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
また、(g)は2006年3月17日の店コード:601店に係るグループのデータに対応している。
この結果、図10に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目が、APサーバ12のメモリ26上に木構造のインデックスデータとして形成される(S35)。
この結果、比較的容量の小さいAPサーバ12のメモリ26上に、より効率的にインデックスデータをキャッシュすることが可能となる。
まず、S40〜S43において、図8のS30〜33と同一の処理がAPサーバ12のデータ処理部22及びインデックス生成部24によって実行され、DBサーバ14が管理するテーブルのキー項目値が、日付×店コードのグループ単位でメモリ26に格納される。
図12は、インデックス生成部24によってメモリ26に格納されたデータグループのイメージを示すものであり、(a)は2006年3月15日の店コード:600店に係るグループのデータに対応している。図示の通り、日付(20060315)及び店コード(600)のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
図12(a)の場合には、店コード及び商品コードの双方について重複する先行データが存在しないため、メモリ26上のデータはそのまま維持される(S46)。
図12(b)は、2006年3月15日の店コード:601店に係るグループのデータに対応しており、この場合には商品コードの「491234567891」及び「491234567893」の双方について重複するデータが先行のデータグループ(図12(a))に存在するため、インデックス生成部24はこれらを削除すると共に、先行商品コードの実体データを参照する型に置き換える(S47)。
これに対し、店コード「601」については重複するデータが先行のデータグループに存在しないため、インデックス生成部24は当該店コードをそのまま維持する(S46)。
因みに、図12(c)は2006年3月16日の店コード:600店に係るグループのデータに対応しており、店コード及び商品コードの全データについて先行データが存在しているため、インデックス生成部24によって実データが削除されると共に、先行する実データの参照型に置き換えられている。
この結果、図13に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる(S49)。
図2のテーブルにおいては、各レコード毎に日付及び店コードのデータを備えていたが、図13に示したデータ構造の場合、上位キー項目である日付については一切の重複がない形で集約され、また下位キー項目である店コード及び商品コードについても参照型を使うことで各グループを通じて一切の重複が存在しない形で表現されているため、データ容量の大幅な圧縮が達成されている。
以下、図14のフローチャートに従い、参照型データへの他の変換手順を説明する。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図8のS30〜S34と同一の処理が実行される結果、図9に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される(S50〜S54)。
このように、重複データを削除した後に参照型のデータに置き換えることにより、データ量を低減しつつ各レコードのソートが可能な状態となる。
この結果、図13に示したのと同様、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる(S61)。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図8のS30〜S34と同一の処理が実行される結果、図9に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される(S70〜S74)。
この結果、図19に示すように、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含まない木構造のデータとしてキャッシュされる(S75)。
この結果、木構造に含まれる商品コードの全類型が重複することなく昇順に整列配置されたディスティンクト・リスト(DistinctList)が、メモリ26上に生成される。
この結果、図20に示すように、木構造のデータ中に含まれる全ての商品コードが、ディスティンクト・リスト34の参照型データとして表現される。
以上の結果、APサーバ12のメモリ26上に、参照型のデータを含む木構造のデータが形成される。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図11のS40〜S49の処理が実行され、メモリ26上に参照型データを含む木構造のインデックスが形成されることが前提となる。
ここでインデックス生成部24は、図22に示すように、上記と同様の手順に従い、商品コードのディスティンクト・リスト34をメモリ26上に生成する(S90)。
商品コードを参照型で表現した場合、32ビットシステムでは1参照当たり4バイトのメモリを消費することになるが(64ビットシステムでは8バイト)、ブーリアン型の場合には1バイトで特定の商品コードの存在を表現できるため、データ容量の圧縮効果をより高めることが可能となる。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図11のS40〜S49及び図21のS90〜S93の処理が実行され、メモリ26上に参照型及びブーリアン配列を含む木構造のインデックス(図25)が形成されることが前提となる。
このビット配列は、図27に示すように、8桁の二値データ(1または0)を備えており、各桁には下から1、2、4、8、16、32、64、−128の定数が割り当てられている。
ここでインデックス生成部24は、ブーリアン配列のある桁に「true」が格納されている場合には、ビット配列の対応の桁に「1」をセットし、「false」が格納されている場合には「0」をセットする。
図27(b)の場合には、商品コードの存在がブーリアン値のfalse, true, false, trueで表現されているため、インデックス生成部24がビット配列の上4桁に「0101」をセットすると共に、下4桁に「該当する値なし」ということで「0」をセットする様子を示している。この「01010000」のビット配列は、上記した各桁の定数を適用することにより、「80」という数値を表していることになる。
図27(c)の場合には、商品コードの存在がブーリアン値のtrue, false, true, trueで表現されているため、インデックス生成部24がビット配列の上4桁に「1011」をセットすると共に、下4桁に「該当する値なし」ということで「0」をセットする様子を示している。この「10110000」のビット配列は、上記した各桁の定数を適用することにより、「−80」という数値を表していることになる。
図28(b)の場合には、商品コードの存在がブーリアン値のtrue, false, false, false, false, false, false, falseで表現されているため、インデックス生成部24がビット配列の最初の桁に「1」をセットすると共に、残りの桁に「0」をセットする様子を示している。この「10000000」のビット配列は、上記した各桁の定数を適用することにより、「−127」という数値を表していることになる。
例えば、2006年3月15日の600店における商品コードとして「11110000」のビット配列が関連付けられていた場合、ここから「true, true,true, true, false, false, false, false」のブーリアン配列が導かれ、これをディスティンクト・リスト34と対比することにより、「491234567890」、「491234567891」、「491234567892」、「491234567893」の具体的な商品コードを特定することが可能となる(下4桁のfalseはディスティンクト・リスト34のサイズと合致しないため、無視される)。
これに対し、8桁のビット配列を用いた場合には、上記の通り1バイトで8つの状態を表示可能となり、メモリの使用量を劇的に抑制可能となる。
図30はその具体例を示すものであり、ブーリアン配列が12桁である場合には1〜8桁までを第1のビット配列によって表現し、9〜12桁までが第2のビット配列によって表現される。
この場合、データ処理部22は第1のビット配列を参照することによってブーリアン配列の上8桁を特定し、また第2のビット配列を参照することによってブーリアン配列の下4桁を特定する。
その後、データ処理部22はディスティンクト・リスト34を参照することにより、具体的な商品コードを特定する。
すなわち、インデックス生成部24は、ディスティンクト・リスト34の各要素と各商品コードの値を、商品コードの上位キー項目である店コードを共通にする兄弟単位で順番にマッチングさせていき、ディスティンクト・リスト34の要素と一致する場合には、当該商品コードを削除すると共に、メモリ26上に設けた所定桁数のビット配列における対応位置に1をセットし、ディスティンクト・リストの値が存在しない場合には0を対応位置にセットする。
この場合もデータ処理部22は、メモリ26上に形成されたビット配列の各桁の値(1または0)とディスティンクト・リスト34を参照することにより、商品コードの値を取得する。
12 APサーバ
14 DBサーバ
16 ロードバランサ
18 イントラネット
20 クライアント端末
22 データ処理部
24 データ圧縮部
26 メモリ
28 データベース管理システム
30 データベース
32 ディスティンクト配列
34 ディスティンクト・リスト
36 商品コードの配列
Claims (12)
- DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段とを備えたことを特徴とするデータ処理システム。 - 上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、
上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信されたデータ中において値が相互に重複するものが存在する場合に、一つの値のみを実データとしてメモリ上に残し、他の値については上記実データを参照する型に変換する処理を実行し、参照型データを含む表形式のインデックスを生成することを特徴とする請求項1に記載のデータ処理システム。
- 上記インデックス生成手段が、少なくとも最上位のキー項目毎に対応のフォルダをAPサーバのディスク上に生成する第1の処理と、
各最上位のキー項目に包含される1または複数の中位キー項目に対応したファイルを生成し、対応のフォルダに格納する第2の処理と、
各中位のキー項目に包含される1または複数の下位キー項目の値を対応のファイルに記述する第3の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第1の処理と、
残された最上位のキー項目を一つの根の元に結合させることにより、木構造のインデックスをAPサーバのメモリ上に生成する第2の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第1の処理と、
値が相互に重複する下位のキー項目については、一の値のみを実データとしてAPサーバのメモリ上に残し、他の値については上記実データを参照する型に変換する第2の処理と、
残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する第3の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記のデータ圧縮手段が、上記DBサーバから送信された各レコードの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第1の処理と、
各レコードの下位のキー項目の値と先行レコードの同キー項目の値とを順次比較し、先行レコードの値と重複する値を削除すると共に、先行レコードの値を参照する型に変換する第2の処理と、
残された上位キー項目同士を一つの根の元に結合させ、参照型を含む木構造のデータを生成する第3の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第1の処理と、
各レコードを下位のキー項目の値に基づいて所定の順序で整列させ、下位のキー項目の値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第2の処理と、
各レコードを少なくとも最上位のキー項目の値に基づいて所定の順序で整列させる第3の処理と、
最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のデータを生成する第4の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第1の処理と、
残された最上位のキー項目を一つの根の元に結合させて木構造のデータを生成する第2の処理と、
上記木構造のデータに含まれる最下位のキー項目の類型を抽出し、これらを要素として充填させたディスティンクト・リストをメモリ上に生成する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と上記木構造のデータに含まれる最下位のキー項目の各値とをマッチングし、最下位のキー項目の各値をディスティンクト・リスト中の対応の要素を参照する型に変換する第4の処理を実行することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第4の処理を実行し、
上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第4の処理と、
上記のブーリアン配列をビット配列に変換する第5の処理を実行し、
上記キー項目値取得手段が、各ビット配列をブーリアン配列に変換し、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項1に記載のデータ処理システム。 - 上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたビット配列における対応位置に1をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に0をセットする第4の処理を実行し、
上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項1に記載のデータ処理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006142176A JP4914117B2 (ja) | 2006-05-22 | 2006-05-22 | データ処理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006142176A JP4914117B2 (ja) | 2006-05-22 | 2006-05-22 | データ処理システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2007310845A true JP2007310845A (ja) | 2007-11-29 |
JP4914117B2 JP4914117B2 (ja) | 2012-04-11 |
Family
ID=38843609
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006142176A Expired - Fee Related JP4914117B2 (ja) | 2006-05-22 | 2006-05-22 | データ処理システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4914117B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012101706A1 (ja) * | 2011-01-25 | 2012-08-02 | 日本電気株式会社 | 情報検索装置 |
WO2013136442A1 (ja) * | 2012-03-13 | 2013-09-19 | 株式会社野村総合研究所 | データ利用システム、時限データの履歴管理システム及びデータ処理システム |
CN105302915A (zh) * | 2015-12-23 | 2016-02-03 | 西安美林数据技术股份有限公司 | 基于内存计算的高性能数据处理*** |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07262018A (ja) * | 1994-03-25 | 1995-10-13 | Toshiba Corp | 構造化型知識データベース作成方法 |
JP2005165610A (ja) * | 2003-12-02 | 2005-06-23 | Nomura Research Institute Ltd | トランザクション処理システムおよび方法 |
JP2005531051A (ja) * | 2002-05-10 | 2005-10-13 | オラクル・インターナショナル・コーポレイション | リレーショナルデータを圧縮格納フォーマットに格納および問合せすること |
JP2007310842A (ja) * | 2006-05-22 | 2007-11-29 | Nomura Research Institute Ltd | データ処理システム |
-
2006
- 2006-05-22 JP JP2006142176A patent/JP4914117B2/ja not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07262018A (ja) * | 1994-03-25 | 1995-10-13 | Toshiba Corp | 構造化型知識データベース作成方法 |
JP2005531051A (ja) * | 2002-05-10 | 2005-10-13 | オラクル・インターナショナル・コーポレイション | リレーショナルデータを圧縮格納フォーマットに格納および問合せすること |
JP2005165610A (ja) * | 2003-12-02 | 2005-06-23 | Nomura Research Institute Ltd | トランザクション処理システムおよび方法 |
JP2007310842A (ja) * | 2006-05-22 | 2007-11-29 | Nomura Research Institute Ltd | データ処理システム |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012101706A1 (ja) * | 2011-01-25 | 2012-08-02 | 日本電気株式会社 | 情報検索装置 |
WO2013136442A1 (ja) * | 2012-03-13 | 2013-09-19 | 株式会社野村総合研究所 | データ利用システム、時限データの履歴管理システム及びデータ処理システム |
CN105302915A (zh) * | 2015-12-23 | 2016-02-03 | 西安美林数据技术股份有限公司 | 基于内存计算的高性能数据处理*** |
CN105302915B (zh) * | 2015-12-23 | 2019-04-09 | 美林数据技术股份有限公司 | 基于内存计算的高性能数据处理*** |
Also Published As
Publication number | Publication date |
---|---|
JP4914117B2 (ja) | 2012-04-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104794123B (zh) | 一种为半结构化数据构建NoSQL数据库索引的方法及装置 | |
US9805079B2 (en) | Executing constant time relational queries against structured and semi-structured data | |
US9047330B2 (en) | Index compression in databases | |
US8924373B2 (en) | Query plans with parameter markers in place of object identifiers | |
CN111046034A (zh) | 管理内存数据及在内存中维护数据的方法和*** | |
CN107247778A (zh) | 用于实施可扩展数据存储服务的***和方法 | |
CN102893281A (zh) | 信息搜索设备、信息搜索方法、计算机程序和数据结构 | |
CN104199816A (zh) | 单独可访问数据单元的管理存储 | |
EP3767486B1 (en) | Multi-record index structure for key-value stores | |
US8832046B2 (en) | Encoded data processing | |
CN112912870A (zh) | 租户标识符的转换 | |
CN111241108A (zh) | 基于键值对kv***的索引方法、装置、电子设备和介质 | |
JP4914117B2 (ja) | データ処理システム | |
CN108182209A (zh) | 一种数据索引方法、及设备 | |
JP4969151B2 (ja) | データ処理システム | |
JP4562749B2 (ja) | 文書の圧縮格納方法及び装置 | |
CN102597969A (zh) | 带属性的键值存储的数据库管理装置及其键值存储结构的高速缓存装置 | |
US20220365905A1 (en) | Metadata processing method and apparatus, and a computer-readable storage medium | |
US7822736B2 (en) | Method and system for managing an index arrangement for a directory | |
JP4850581B2 (ja) | データ処理システム | |
EP3436988B1 (en) | "methods and systems for database optimisation" | |
Singh | NoSQL: A new horizon in big data | |
Pollack et al. | Index Storage Fundamentals | |
JP2003157249A (ja) | 文書の圧縮格納方法 | |
JP2024514672A (ja) | アペンド専用データ構造を用いるリスト・ベースのデータ検索 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090306 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20111006 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111018 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111213 |
|
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: 20120117 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120120 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150127 Year of fee payment: 3 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |