(57)【要約】      （修正有）【課題】標準的なＤＢＭＳシステムによって課されるオーバーヘッドを除去するコード処理およびデータ技術を提供する。【解決手段】方法は、記憶のための中間フォーマットでデータを記憶し、中間データフォーマットを２つのデータボリュームのプロダクションデータフォーマットに変換し、２つのデータボリュームを１つのデータボリュームにマージする。【選択図】図５
2020115345.tif 000002
【特許請求の範囲】
【請求項１】
記憶のための中間フォーマットデータでデータを記憶することと、
前記中間データフォーマットを少なくとも２つのデータボリュームのプロダクションデータフォーマットに変換することと、
前記少なくとも２つのデータボリュームを１つのデータボリュームにマージすることと、を含むデータ処理方法。
【請求項２】
前記少なくとも２つのデータボリュームは、データインデックスおよびデータレコードを含む、請求項１に記載のデータ処理方法。
【請求項３】
前記データインデックスは、中間フォーマットからプロダクションフォーマットに変換され、前記データレコードファイル内の前記データレコードへの固定長データポインタと共に、インデックスファイル内にバイナリフォーマットで配置される、請求項２に記載のデータ処理方法。
【請求項４】
前記変換は、暗号学的アルゴリズム処理を使用することによって実行される、請求項１に記載のデータ処理方法。
【請求項５】
各データレコードボリュームが、データレコード長とオプションで整合性チェックサムとの少なくとも１つを記述するヘッダを含む、請求項２に記載のデータ処理方法。
【請求項６】
前記インデックスファイル上で探索を実行し、ポインタからデータ位置を取得し、該ポインタに関連付けられた値を、データボリューム長と次の順次データレコードのためのポインタに関連付けられた値とのうちの選択された１つから差し引くことにより、前記少なくとも２つのデータボリュームが検索される、請求項２に記載のデータ処理方法。
【請求項７】
記憶のための中間データフォーマットデータでデータを記憶する記憶ユニットと、
前記中間データフォーマットを少なくとも２つのデータボリュームのプロダクションデータフォーマットに変換する変換器ユニットと、
前記２つのデータボリュームを１つのデータボリュームにマージするマージャユニットと、を含むデータシステム。
【請求項８】
前記少なくとも２つのデータボリュームは、データインデックスおよびデータレコードファイルを含む、請求項７に記載のデータシステム。
【請求項９】
前記データインデックスは、中間フォーマットからプロダクションフォーマットに変換され、前記データレコードファイル内の前記データレコードへの固定長データポインタと共に、インデックスファイル内にバイナリフォーマットで配置される、請求項８に記載のデータシステム。
【請求項１０】
前記変換は、暗号学的アルゴリズム処理を使用することによって実行される、請求項７に記載のデータシステム。
【請求項１１】
各データボリュームは、データレコード長とオプションで整合性チェックサムとを記述するヘッダを含む、請求項７に記載のデータシステム。
【請求項１２】
前記インデックスファイル上で探索を実行し、ポインタからデータ位置を取得し、該ポインタに関連付けられた値を、データボリューム長と次の順次データレコードのためのポインタに関連付けられた値とのうちの選択された１つから差し引くことにより、前記少なくとも２つのデータボリュームが検索される、請求項７に記載のデータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、コード処理およびデータ技術に関する。
【背景技術】
【０００２】
大きなセットの静的な読み取り専用データ(数兆個のレコード)に対して単一キーでの検索を実行する必要がある場合、従来のＤＢＭＳ（データベース管理システム）では、応答時間だけでなく、サーバー間でデータを同期したりバックアップを実行したりするのに必要な時間を満たすものになっていない。
【０００３】
大量の静的データに対して単一キーでの読み取り専用検索という単純なタスクが与えられたとしても、同時制御、アクセス制御、トランザクション処理、およびログ記録を含む（これらに限定されない）標準的なＤＢＭＳの内部メカニズムがパフォーマンスを鈍らせる。
【発明の概要】
【０００４】
以下の簡略化された概要は、本開示に記載される種々の実施形態のいくつかの態様の基本的理解のために提供される。本概要は、本開示の広範囲にわたる概観ではない。請求項に係る発明の鍵となる要素または重要な要素を特定することも、発明の範囲の輪郭を示すことも意図していない。以下の概要は、本開示に記載される実施形態において使用されるいくつかの概念を簡略化した形式で、それらの実施形態のより詳細な説明に対する前置きとして提示しているに過ぎない。
【０００５】
本開示に記載されるいくつかの実施形態の目的は、標準的なＤＢＭＳ(データベース管理システム)システムによって課されるオーバーヘッドを除去するためのシステムおよび方法をアレンジすることである。これは、記憶のための中間フォーマットでデータを記憶することと、中間データフォーマットを２つのデータボリュームのプロダクションデータフォーマットに変換することと、２つのデータボリュームを１つのデータボリュームにマージすることとを含むデータ処理方法によって達成される。
【０００６】
本開示に記載されるいくつかの実施形態の焦点は、記憶のための中間フォーマットでデータを記憶する記憶ユニットと、中間データフォーマットを２つのデータボリュームのプロダクションデータフォーマットに変換する変換器ユニットと、２つのデータボリュームを１つのデータボリュームにマージするマージャユニットとを含むデータシステムでもある。
【０００７】
本明細書に記載される実施形態は、記憶のための中間フォーマットでデータを記憶し、中間データフォーマットを２つのデータボリュームの生産データフォーマットに変換することに基づいてよい。本明細書に記載される実施形態はまた、２つのデータボリュームを１つのデータボリュームにマージすることに基づいてよい。
【０００８】
本明細書に記載される実施形態の利点は、標準的なデータベース管理システムを使用するよりも著しく高い性能速度を可能にすることができることである。
【図面の簡単な説明】
【０００９】
本開示の例示的および非限定的な実施形態およびそれらの利点は、添付の図面を参照して以下により詳細に説明される。
【００１０】
【図１】パスポート番号（passport  number）と氏名（full  name）から構成されるサンプルデータを表す。
【図２】図１に示すパスポートのＭＤ５  ｓｕｍである記録キーを付加した図１からのサンプルデータを表す。
【図３】ｒａｗフォーマットで記憶された図１および図２の結果データを表す。
【図４】プロダクションフォーマット(バンク０ｆのみ表示、１６進ダンプ)にパックされた結果データを表す。
【図５】図１から図４のデータを処理するためのデータシステムフローチャートを表す。
【発明を実施するための形態】
【００１１】
本明細書に記載される実施形態は、標準的なデータベース管理システム（ＤＢＭＳ）によって課されるオーバーヘッドを除去するためのシステムおよび方法に関する。この方法は、ハッシュ値、すなわちハッシュキーの均一な分布を達成するために暗号学的メッセージダイジェストを使用することと、インデックス検索の労力の一部をファイルシステム自体に中継することとを含む。これは、作業の一部がファイルシステムに渡されることを意味する。ファイル名にハッシュの一部を使用することで、ハッシュ全体をデータベースに保存する場合に比べて、バンクのサイズをより小さくすることができる。さらに、各ファイル名がファイルの名前を必要とするため、このスペースは本質的にフリーである。言い換えると、ハッシュの一部がファイルシステムのファイル割り当てテーブルで使用されてよい。
【００１２】
好ましくは、データセットをデータバンクに分割し、データキーの一部をファイルおよびディレクトリの名前に記憶し、インデックス探索タスクの一部をファイルシステムに委任する。データ更新は、好ましくは、サービス中断なしでバッチに対して実行される。
【００１３】
開示されるデータ記憶方法は、３つのフェーズを含むことができる。データ捕捉は、可能な限り高速なデータ記録を保証する中間（ｒａｗフォーマット：raw  format）フォーマットでデータを記憶する。データパッキングは、捕捉されたデータを、高速クエリを実行できるプロダクション準備の整った(production-ready)フォーマット（プロダクションフォーマット：production  format）に変換する。中間フォーマットが処理され保存される場合、可能な限り高速なルックアップテーブル（ＬＵＴ）のために、プロダクションフォーマットが達成される。データマージは、少なくとも２つの存在するデータボリュームを１つのボリュームにマージする。
【００１４】
本特許出願に記載されるデータ記憶方法は、大きなデータセット対して高性能クエリを送達するために従来技術のＤＢＭＳソリューションの欠陥を克服する。本特許出願に記載されるデータセットは、サービス中断なしに更新可能な単一のキーおよび可変データフィールドを特徴とする。データは、異なるコンピュータ環境およびプラットフォームにおけるコーディング実装を可能にするポータブルフォーマットで記憶される。
【００１５】
１つの例示的な実施形態では、データ捕捉メカニズムの目的は、将来的なプロセスおよびマージのために可能な限り高速なデータ記憶を提供することである。従って、データ捕捉は、無制限の数のマシンで実行され、後の段階でまとめてマージされ、次いで、プロダクションに移されてよい。
【００１６】
データセットは２つのフィールドで構成される。すなわち、データインデックスとデータレコードである。データインデックスは、インデックスの均一な分布を提供することを目的として、好みの暗号学的アルゴリズムを使用してメッセージダイジェストに変換される。データレコードは好ましくは固定長を有さないが、実施形態によっては所定の最大長に制限されてもよい。
【００１７】
１つの例示的な実施形態では、データ収集による情報は、データバンクと呼ばれる個々のフラットファイルに記憶される。これらのデータバンクは、データインデックスの最初のＮ（アドレッシング）ニブルにちなんでおり、例えば、プレーンテキスト情報またはバイナリ形式の情報を含むことができ、データレコードごとに１行である。行は、データインデックス、その後にデータレコード全体が続く。
【００１８】
情報は異なるインスタンスで取得でき、ｒａｗフォーマットの情報は、例えば、コロンで区切られたフィールドを使用する、あるいはＪＳＯＮフォーマットですべて表現することによって、単純にデータバンクをまとめて連結するだけでマージできる。これは重複情報をもたらす可能性があるが、任意の重複情報はデータパッキング中に除去される。
【００１９】
図１及び図２に示された例示的な１つの例示的な実施形態では、単純なパスポート番号（passport  number）およびフルネーム(full  name)のデータ構造が与えられ、所望のキーはパスポート番号としてよい。データインデックス（パスポート番号）は、ＭＤ５暗号学的アルゴリズムを使用してメッセージダイジェストに変換することができる。
【００２０】
２ニブルのデータバンクのアドレッシングで、passportsという名前のデータボリュームを含むpeopleという名前のデータベースボリュームに情報が保存されると仮定すると、図２のデータは、図３で提示するように２つのデータバンクにｒａｗフォーマットで記録されてよい。２ニブルを使用すると、パスポートのデータボリュームに対して最大２５６個のデータバンクをもたらすことになる。
【００２１】
別の例示的な実施形態では、データパッキングの処理は、ｒａｗフォーマットのデータボリュームをプロダクションフォーマットに変換する。この処理中、データバンクはソートされ、重複したレコードを除去し、次いで、データバンクは、インデックスとデータの２つのファイルに変換されてよく、それらに対して.indexおよび.dataのファイル拡張子がこの説明においては使用される。
【００２２】
データインデックスは、１６進数（ＡＳＣＩＩ）からバイナリに変換され、.dataのファイル内のデータレコードへの固定長データポインタと共にインデックスファイルに置かれる。バンク名に存在するインデックスからのニブルは、インデックスファイルから削除してよい。サイズの小さいインデックスファイルが与えられると、シークタイムを高速にするためにそれらをＲＡＭにコピーすることができる。データファイルはすべてのデータレコードの連結を含む。各レコードは、好ましくは、レコード長およびオプションで整合性チェックサムを記述するヘッダを含む。
【００２３】
１つの例示的な実施形態では、データポインタは３２ビットに設定され、最大データバンクサイズ４Ｇｂを可能にし、レコード長はシングルバイトであり、最大データレコードサイズ２５６バイトを可能にし、データチェックサムはシングルバイトに設定される。
【００２４】
図３のｒａｗフォーマットを使用して、バンク０ｆをとると、データバンクは以下のようになる。すなわち、０ｆバンクは、0f.dataのファイル内に記憶された２つのレコードを含む。これら２つのレコードは、図４の0f.dataのファイルのコンテンツ（Contents）に表示されている。データレコードの前には、レコードサイズとチェックサムを宣言する２バイトのヘッダがある。両方のレコードは８バイト長であり、チェックサムはそれぞれ９７とｃ６（１６進数）である。
【００２５】
バンクのインデックスファイル0f.indexには、レコードキーの残りの１５バイト（最初のバイトはファイル名にあることに注意）を含み、その後に、データファイル内のレコードの開始についての３２ビット（４バイト）ポインタが続く（それぞれバイト０とバイト１０である）。
【００２６】
別の例示的な方法では、データマージは、送信元データボリュームを宛先データボリュームに結合することを含んでよい。マージは、個々のデータバンクを単に連結するだけで、ｒａｗフォーマットのデータボリューム上で実行することができる。
【００２７】
プロダクションフォーマットのデータボリュームのバイナリマージは、データボリューム内のデータバンクを処理することと、それらを、宛先ボリューム内に単一性（unity）を有する一時データバンクにマージすることを含むことができる。データバンクがマージされると、それは宛先データバンクに移される。これにより、サービスを中断する必要なくデータを更新することができる。
【００２８】
２つのデータバンクのマージは、バンク上の各レコードを処理し、重複をスキップしてそれらをマージされたバンクに順番に書き込むことによって実行してよい。
【００２９】
データレコードの検索は、対応するデータバンクに対するインデックスファイル内で補間探索または対数探索などの特定の探索アルゴリズムを使用して探索を実行することと、ポインタからデータ位置を取得することと、次のレコードのポインタ（または最後のレコードの場合はデータファイル長）からポインタを差し引くことによってデータ長を取得することと、を含んでよい。
【００３０】
図５は、本開示の例示的かつ非限定的な実施形態によるデータシステムフローチャートを表す。データシステムは、記憶のための中間フォーマットでデータを記憶する記憶ユニット１００と、中間データフォーマットを少なくとも２つのデータボリュームの生産データフォーマットに変換する変換器ユニット１０２とを含んでよい。変換は、例えば、暗号学的アルゴリズム処理を使用して実行することができる。少なくとも２つのデータボリュームとは、例えば、データインデックスおよびデータレコードとしてよい。１つの例示的な実施形態では、データインデックスは、データレコードのファイル内のデータレコードへの固定長データポインタと共に、インデックスファイル内にバイナリ形式で配置され得る。データインデックスは、中間フォーマットからプロダクションフォーマットに変換することができる。
【００３１】
データシステムは、少なくとも２つのデータボリュームを１つのデータボリュームにマージするマージャユニット１０４をさらに含む。１つの例示的な実施形態では、データインデックスファイル上で探索を実行し、所与のポインタからデータ位置を取得し、次のデータレコードのポインタの値から所与のポインタの値を差し引くことによって、あるいは所与のポインタがデータボリューム内の最後のポインタである場合、データボリューム長から所与のポインタの値を差し引くことによって、データ長を取得することによってデータレコードが検索される。各データレコードボリュームは、データレコード長とオプションで整合性チェックサムとを記述するヘッダを含んでよい。
【００３２】
データシステム、例えば、ユニット１００、１０２および１０４は、アルゴリズムを使用し、本発明による方法を実施するために、例えばプロセッサベースのコンピュータおよびマイクロプロセッサの技術によって実施することができる。
【００３３】
上記に与えられた説明において提供された特定の例は、添付の特許請求の範囲の範囲および／または適用可能性を制限するものと解釈されるべきではない。
【図１】
2020115345.tif 000003
【図２】
2020115345.tif 000004
【図３】
2020115345.tif 000005
【図４】
2020115345.tif 000006
【図５】
2020115345.tif 000007
【手続補正書】
【提出日】令和2年3月9日(2020.3.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記憶のための中間フォーマットでデータを記憶することと、
記憶された前記データを前記中間フォーマットから少なくとも２つのデータボリュームのプロダクションフォーマットに変換することと、
前記少なくとも２つのデータボリュームを１つのデータボリュームにマージすることと、を含むデータ処理方法。
【請求項２】
前記少なくとも２つのデータボリュームは、データインデックスおよびデータレコードを含む、請求項１に記載のデータ処理方法。
【請求項３】
前記データインデックスは、中間フォーマットからプロダクションフォーマットに変換され、データファイル内の前記データレコードへの固定長データポインタと共に、インデックスファイル内にバイナリフォーマットで配置される、請求項２に記載のデータ処理方法。
【請求項４】
前記変換は、暗号学的アルゴリズム処理を使用することによって実行される、請求項１に記載のデータ処理方法。
【請求項５】
各データレコードボリュームが、データレコード長とオプションで整合性チェックサムとの少なくとも１つを記述するヘッダを含む、請求項２に記載のデータ処理方法。
【請求項６】
前記インデックスファイル上で探索を実行し、ポインタからデータ位置を取得し、該ポインタに関連付けられた値を、データボリューム長と次の順次データレコードのためのポインタに関連付けられた値とのうちの選択された１つから差し引くことにより、前記少なくとも２つのデータボリュームが検索される、請求項３に記載のデータ処理方法。
【請求項７】
記憶のための中間フォーマットでデータを記憶する記憶ユニットと、
記憶された前記データを前記中間フォーマットから少なくとも２つのデータボリュームのプロダクションフォーマットに変換する変換器ユニットと、
前記２つのデータボリュームを１つのデータボリュームにマージするマージャユニットと、を含むデータシステム。
【請求項８】
前記少なくとも２つのデータボリュームは、データインデックスおよびデータレコードファイルを含む、請求項７に記載のデータシステム。
【請求項９】
前記データインデックスは、中間フォーマットからプロダクションフォーマットに変換され、データファイル内の前記データレコードへの固定長データポインタと共に、インデックスファイル内にバイナリフォーマットで配置される、請求項８に記載のデータシステム。
【請求項１０】
前記変換は、暗号学的アルゴリズム処理を使用することによって実行される、請求項７に記載のデータシステム。
【請求項１１】
各データボリュームは、データレコード長とオプションで整合性チェックサムとの少なくとも１つを記述するヘッダを含む、請求項７に記載のデータシステム。
【請求項１２】
前記インデックスファイル上で探索を実行し、ポインタからデータ位置を取得し、該ポインタに関連付けられた値を、データボリューム長と次の順次データレコードのためのポインタに関連付けられた値とのうちの選択された１つから差し引くことにより、前記少なくとも２つのデータボリュームが検索される、請求項９に記載のデータシステム。
【外国語明細書】
2020115345000001.pdf