JP4914117B2 - データ処理システム - Google Patents
データ処理システム Download PDFInfo
- Publication number
- JP4914117B2 JP4914117B2 JP2006142176A JP2006142176A JP4914117B2 JP 4914117 B2 JP4914117 B2 JP 4914117B2 JP 2006142176 A JP2006142176 A JP 2006142176A JP 2006142176 A JP2006142176 A JP 2006142176A JP 4914117 B2 JP4914117 B2 JP 4914117B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- server
- key item
- index
- memory
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
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 (4)
- DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段を備え、
さらに、上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
メモリ上に空のディスティンクト配列を設定すると共に、これに最下位のキー項目に含まれる全ての値から重複するものを削除して所定の順序で整列させた値の類型を充填することにより、メモリ上にディスティンクト・リストを生成する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第4の処理を実行し、
上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とするデータ処理システム。 - DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段を備え、
さらに、上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
メモリ上に空のディスティンクト配列を設定すると共に、これに最下位のキー項目に含まれる全ての値から重複するものを削除して所定の順序で整列させた値の類型を充填することにより、メモリ上にディスティンクト・リストを生成する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第4の処理と、
上記の各ブーリアン配列中のtrueについては、メモリ上に設けた上記ディスティンクト・リストのサイズ以上の桁数のビット配列における対応位置に1をセットすると共に、同ブーリアン配列中のfalseについては、上記ビット配列における対応位置に0をセットすることにより、上記ブーリアン配列をビット配列に変換する第5の処理を実行し、
上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とするデータ処理システム。 - DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段を備え、
さらに、上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第1の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第2の処理と、
メモリ上に空のディスティンクト配列を設定すると共に、これに最下位のキー項目に含まれる全ての値から重複するものを削除して所定の順序で整列させた値の類型を充填することにより、メモリ上にディスティンクト・リストを生成する第3の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けた上記ディスティンクト・リストのサイズ以上の桁数のビット配列における対応位置に1をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に0をセットする第4の処理を実行し、
上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とするデータ処理システム。 - 上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、
上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴とする請求項1〜3の何れかに記載のデータ処理システム。
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 JP2007310845A (ja) | 2007-11-29 |
JP4914117B2 true 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) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5790664B2 (ja) * | 2011-01-25 | 2015-10-07 | 日本電気株式会社 | 情報検索装置 |
WO2013136442A1 (ja) * | 2012-03-13 | 2013-09-19 | 株式会社野村総合研究所 | データ利用システム、時限データの履歴管理システム及びデータ処理システム |
CN105302915B (zh) * | 2015-12-23 | 2019-04-09 | 美林数据技术股份有限公司 | 基于内存计算的高性能数据处理系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07262018A (ja) * | 1994-03-25 | 1995-10-13 | Toshiba Corp | 構造化型知識データベース作成方法 |
AU2003229021C1 (en) * | 2002-05-10 | 2009-09-17 | Oracle International Corporation | Storing and querying relational data in compressed storage format |
JP2005165610A (ja) * | 2003-12-02 | 2005-06-23 | Nomura Research Institute Ltd | トランザクション処理システムおよび方法 |
JP4969151B2 (ja) * | 2006-05-22 | 2012-07-04 | 株式会社野村総合研究所 | データ処理システム |
-
2006
- 2006-05-22 JP JP2006142176A patent/JP4914117B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2007310845A (ja) | 2007-11-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104794123B (zh) | 一种为半结构化数据构建NoSQL数据库索引的方法及装置 | |
US9805079B2 (en) | Executing constant time relational queries against structured and semi-structured data | |
CN104199816B (zh) | 单独可访问数据单元的管理存储 | |
US9047330B2 (en) | Index compression in databases | |
US8924373B2 (en) | Query plans with parameter markers in place of object identifiers | |
CN100390790C (zh) | 存储和访问数据,以及提高数据库查询语言语句性能的方法和机制 | |
CN111046034A (zh) | 管理内存数据及在内存中维护数据的方法和系统 | |
Chavan et al. | Survey paper on big data | |
CN111241108A (zh) | 基于键值对kv系统的索引方法、装置、电子设备和介质 | |
CN112912870A (zh) | 租户标识符的转换 | |
US11880368B2 (en) | Compressing data sets for storage in a database system | |
US20200151148A1 (en) | Web-scale distributed deduplication | |
JP4914117B2 (ja) | データ処理システム | |
CN108182209A (zh) | 一种数据索引方法、及设备 | |
JP4969151B2 (ja) | データ処理システム | |
US7536398B2 (en) | On-line organization of data sets | |
CN102597969A (zh) | 带属性的键值存储的数据库管理装置及其键值存储结构的高速缓存装置 | |
US7822736B2 (en) | Method and system for managing an index arrangement for a directory | |
EP3436988B1 (en) | "methods and systems for database optimisation" | |
JP4920303B2 (ja) | データ処理システム | |
Singh | NoSQL: A new horizon in big data | |
JP2007310844A (ja) | データ処理システム | |
CN114020986B (zh) | 内容检索系统 | |
KR102177792B1 (ko) | 컬럼 별 바이너리 파일 저장 구조를 이용하여 대용량 데이터를 메모리 용량 제약없이 차트로 표시하는 시스템 | |
Pollack et al. | Index Storage Fundamentals |
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 |