(57)【特許請求の範囲】
【請求項１】
大容量データ処理の方法であって、
ソースファイル命名スキームに従って命名されたソースファイルを受信する工程と、
前記ソースファイルを小ファイル命名スキームに従って命名される複数の小さいファイルに分割するために、前記ソースファイルの前記ファイル名によって、ソースファイル分割サーバーを割り当てる工程と、
前記複数の小さいファイルを処理するために、前記小さいファイルの前記ファイル名によって複数の小ファイル処理サーバーを割り当てる工程であって、各割り当てられた小ファイル処理サーバーは、１つ又はそれ以上のそれぞれの小さいファイルを処理する、複数の小ファイル処理サーバーを割り当てる工程と、から成る方法。
【請求項２】
前記ソースファイルの前記ファイル名によって前記ソースファイル分割サーバーを割り当てる工程は、
前記ソースファイルの前記ファイル名を解析し、ソースファイルシーケンス番号を取得する工程と、
算出工程（（（前記ソースファイルシーケンス番号）％（割り当てに使用可能なサーバー総数））＋１）であって、％は、モジュロ演算子を表わしている算出工程と、
算出結果によって前記ソースファイル分割サーバーを割り当てる工程と、を備えている、請求項１に記載の方法。
【請求項３】
前記小さいファイルの前記ファイル名によって前記複数の小ファイル処理サーバーを割り当てる工程は、
各小さいファイルの前記ファイル名を解析し、小ファイルシーケンス番号を取得する工程と、
算出工程（（（前記小ファイルシーケンス番号）％（割り当てに使用可能なサーバー総数））＋１）であって、％は、モジュロ演算子を表わしている算出工程と、
前記算出結果によって前記小さいファイルを処理するために前記複数の小ファイル処理サーバーの１つを割り当てる工程と、を備えている、請求項１に記載の方法。
【請求項４】
前記ソースファイルの前記ファイル名によって前記ソースファイル分割サーバーを割り当てる工程は、
使用可能なサーバー毎に、前記サーバーによって処理されるデータの種類を設定する工程と、
前記ソースファイルの前記ファイル名を解析し、前記ソースファイルの前記データ種を取得する工程と、
前記ソースファイルに、前記データ種を処理するように設定された前記使用可能なサーバーの１つを割り当てる工程と、を備えている、請求項１に記載の方法。
【請求項５】
前記小さいファイルの前記ファイル名の前記ファイル名によって前記複数の小ファイル処理サーバーを割り当てる工程は、
使用可能なサーバー毎に、前記サーバーによって処理されるデータの種類を設定する工程と、
小さいファイル毎に、前記小さいファイルの前記ファイル名を解析し、前記小さいファイルの前記データ型を取得する工程と、
前記小さいファイルに、前記データ型を処理するように設定された前記使用可能なサーバーの１つを割り当てる工程と、を備えている、請求項１に記載の方法。
【請求項６】
前記ソースファイルを前記複数の小さいファイルへ分割した後、前記方法は、
前記複数の小さいファイルをディスクへ保存する工程を更に備えている、請求項１に記載の方法。
【請求項７】
失敗した場合には、前記ソースファイルを分割する再試行に、前記ソースファイル分割サーバーを割り当てる工程と、
失敗した場合には、前記それぞれ割り当てられた小さいファイルを処理する再試行に、前記複数の小ファイル処理サーバーを割り当てる工程と、を更に備えている、請求項１に記載の方法。
【請求項８】
前記ソースファイルの分割には１回の再試行だけを許可し、前記割り当てられた小さいファイルの処理には複数の再試行を許可する、請求項７に記載の方法。
【請求項９】
分割されるのを待機している前記ソースファイルと、処理されるのを待機している小さいファイルと、を異なるディレクトリの下に入れる工程を更に備えている、請求項１に記載の方法。
【請求項１０】
分割されるのを待機している前記ソースファイルのディレクトリの下のデータの流れは、
前記ソースファイルを、分割されるソースファイル用のディレクトリへ入れる工程と、
前記ソースファイル処理サーバーを割り当てた後、分割されるのを待機している前記ソースファイルをファイル分割用の一時ディレクトリへ入れる工程と、
前記ソースファイルを分割する工程と、
前記ソースファイルが、成功裏に分割された場合には、前記ソースファイルを成功裏に分割されたソースファイルを保存するディレクトリにバックアップし、而して取得された前記小さいファイルを分割後の小さいファイルを保存するディレクトリへ保存する工程、又は前記ソースファイルが、再試行の後分割されなかった場合には、前記ソースファイルを分割されなかったソースファイルを保存するディレクトリにバックアップする工程と、を備えている、請求項９に記載の方法。
【請求項１１】
処理されるのを待機している前記小さいファイルのディレクトリの下のデータの流れは、
前記小さいファイルを分割後の小さいファイルを保存するディレクトリへ保存する工程と、
前記小ファイル処理サーバーを割り当てた後、処理されるのを待機している前記小さいファイルを小さいファイル処理用の一時ディレクトリへ入れる工程と、
前記一時ディレクトリの前記小さいファイルを処理する工程と、
前記１つ又はそれ以上の小さいファイルが、成功裏に処理された場合には、１つ又はそれ以上の前記小さいファイルを成功裏に処理された小さいファイルを保存するディレクトリへバックアップし、前記１つ又はそれ以上の前記小さいファイルが、再処理される必要がある場合には、１つ又はそれ以上の前記小さいファイルを、部分的に不成功に処理された記録を有する小さいファイルを保存するディレクトリへバックアップし、前記１つ又はそれ以上の前記小さいファイルが、再施行後処理できなかった場合には、１つ又はそれ以上の前記小さいファイルを、再施行後処理できなかった小さいファイルを保存するディレクトリへバックアップする、工程と、を備えている、請求項９に記載の方法。
【請求項１２】
大容量データ処理のシステムであって、前記システムは、複数のサーバーを備えており、各サーバーにおいて、
ソースファイル命名スキームに基づいて、分割されるのを待機しているソースファイルが、前記サーバーによって処理されるべきか否かを確定し、肯定的な場合には、分割を起動するのに使用される、及び分割後小ファイル命名スキームに基づいて、処理されるのを待機している小さいファイルが、前記サーバーによって処理されるべきか否かを確定し、肯定的な場合には、処理ユニットを起動するのに使用される、前処理ユニットと、
前記ソースファイルを小さいファイルに分割するのに使用される前記分割ユニットと、
論理処理を前記小さいファイルに実行するのに使用される処理ユニットと、を備えているシステム。
【請求項１３】
前記前処理ユニットは、前記ソースファイルの前記ファイル名のソースファイルシーケンス番号に基づいて、分割されるのを待機している前記ソースファイルが、前記サーバーによって処理されるべきか否かを確定し、且つ前記小さいファイルの前記ファイル名のソースファイルシーケンス番号又は前記小さいファイルの前記ファイル名の小ファイルシーケンス番号に基づいて、処理されるのを待機している前記小さいファイルが、前記サーバーによって処理されるべきか否かを確定している、請求項１２に記載のシステム。
【請求項１４】
前記前処理ユニットは、前記ソースファイルに保存されたデータの種類に基づいて、分割されるのを待機している前記ソースファイルが、前記サーバーによって処理されるべきか否かを確定し、各サーバーにおいて、
前記サーバーによって処理することができる（１つ又は複数の）データの種類を設定するのに使用される設定ユニットを更に備えている、請求項１２に記載のシステム。
【請求項１５】
各サーバーにおいて、
前記小さいファイルをディスクへ保存するのに使用される記憶ユニットを更に備えている、請求項１２に記載のシステム。
【請求項１６】
前記記憶ユニットは、ディレクトリ構造を採用しており、分割される前記ソースファイルと、処理されるのを待機している前記小さいファイルと、を異なるディレクトリの下へ入れる、請求項１５に記載のシステム。
【請求項１７】
各サーバーにおいて、
失敗した場合には前記ソースファイルを分割する、及び／又は失敗した場合には前記小さいファイルを処理する、再試行に使用される再試行ユニットであって、分割には１回の再試行を許可するが、処理には複数の再試行を許可する、再試行ユニットを更に備えている、請求項１２に記載のシステム。
【請求項１８】
大容量データ処理の方法であって、
ソースファイル命名スキームに従ってファイル名をソースファイルに付与する工程と、
前記ソースファイルを複数の小さいファイルに分割するために、前記ソースファイルの前記ファイル名によってソースファイル分割サーバーを割り当てる工程と、
小ファイル命名スキームに従ってファイル名を複数の小さいファイルに付与する工程と、
前記複数の小さいファイルを分散して処理するために、前記小さいファイルの前記ファイル名によって複数の小ファイル処理サーバーを割り当てる工程と、
前記割り当てられた小ファイル処理サーバーによって前記複数の小さいファイルを処理する工程と、から成る方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、データ処理技術に関し、より厳密には大容量データ処理の方法及びシステムに関する。
【背景技術】
【０００２】
データ処理は、一般的に多くの用途において見られる。典型的な筋書きでは、送信側は、或る種のデータを或る種の書式のファイルに保存し、その後そのファイルを受信側へ送信する。ファイルを受信すると、受信側は、ファイル内部の内容を分析し、適宜に論理的処理を実行する。
【０００３】
上記のデータ処理において、ファイルが非常に大きいサイズではなく、且つ受信側が、厳しい処理時間要件を有していない場合には、単一のサーバー又は単一のスレッドを、処理に使用することができる。この様な状況下では、受信側におけるそれらのファイルデータの処理に掛かる時間が、非常に長くなっても、対応するシステムは、まだ通常に作動する場合もある。しかしながら、ファイルが非常に大きい（及び／又はファイルの数が多い）ものであり、且つ受信側が、非常に厳しい処理時間要件を有している（例えば、受信側は、送信側から送信されるファイルのデータが１分又はそれより短い時間以内に完全に処理されることを求める）場合には、単一のサーバー又は単一のスレッドを使用する処理システムは、このニーズを満足することができない可能性がある。
【０００４】
多くの場合では、ファイルデータは、例えば５分毎に１回の間隔で、定期的に送信側から受信側へ転送される。加えて、受信側は、データの最大遅延許容値を有する場合がある。受信側が、対応する時間間隔の間に送信されるデータの処理を完了することができない場合には、悪循環が生じ、前の期間からのデータの未処理と新しいデータの到着は、受信側のデータ遅延を増長させ、最終的にはシステム崩壊を引き起こす場合がある。
【０００５】
その様な大容量データ処理の要望は、多くの大規模利用では普通に見られる。実例には、学校から教育部門の教育機関への生徒のデータ報告、大規模ウェブサイトのウェブログ処理、及び／又はシステム間のデータ同期化などが含まれる。この様な次第で、処理遅延を減らすために、予定時間内に大容量データを処理する方法が求められている。
【発明の概要】
【０００６】
予定時間内に大容量のデータを処理することができないことによって生じる処理遅延に起因するシステム崩壊の問題を解決するために、大容量データ処理の方法及びシステムを開示する。
【０００７】
本開示の１つの態様は、大容量データの処理方法である。当該の方法は、ソースファイルを複数の小さいファイルに分割するのに１つのサーバーを割り当て、小さいファイルを分散して処理するのに複数のサーバーを割り当てる。サーバーの割り当ては、ファイル命名スキームに従って付与されるファイル名に基づいて行うことが可能である。開示される方法は、大容量データファイルの分割及び処理に複数のサーバーを配備し、これによってシステムの処理能力を向上させ、システムが、確実に、予定時間内にファイル処理を終えることができるようにさせる。更に、当該のシステムは、良好な拡張性を約束する。ファイルがより大きくなる、又はファイル数が増えた場合には、需要を満たすために新しいサーバーを追加することができる。システムは、より進歩したサーバーの購入及び以前から操作しているサーバーの再設定及び再配備を行う必要無く線状に拡張することが可能である。
【０００８】
１つの実施形態では、ソースファイルのファイル名によるソースファイル分割サーバーの割り当ては、ソースファイルのファイル名を解析して、ソースファイルのシーケンス番号を取得する工程と、算出工程（（（ソースファイルシーケンス番号）％（割り当てに使用可能なサーバー総数））＋１）であって、％は、モジュロ演算子を表わしている算出工程と、演算結果によってソースファイル分割サーバーを割り当てる工程と、によって行われている。小さいファイルのファイル名による小ファイル処理サーバーの割り当ても、同様に行うことができる。
【０００９】
サーバーは、更に、サーバーによって処理されるデータの種類によって割り当てられてもよい。１つの実施形態では、当該の方法は、各サーバーを、１つのデータの種類を処理するように設定し、ファイルのファイル名を解析してファイルに保存されているデータのデータ種を取得する、及びそのデータのデータ種を処理するように設定されるサーバーにファイルを割り当てる。
【００１０】
ソースファイルを小さいファイルに分割後、当該の方法は、小さいファイルをディスクへ保存してもよい。
【００１１】
１つの実施形態では、当該の方法は、ソースファイル処理サーバーが、失敗した場合にはソースファイルの分割を再試行することができるようにしており、並びに複数の小ファイル処理サーバーが、失敗した場合にはそれぞれ割り当てられた小さいファイルの処理を再試行することができるようにしている。当該の方法は、ソースファイルの分割には１回の再試行だけを許可するが、割り当てられた小さいファイルの処理には複数の再試行を許可することができる。
【００１２】
当該の方法は、分割されるのを待機しているソースファイルと、処理されるのを待機している小さいファイルと、を異なるディレクトリの下に入れることができる。１つの実施形態では、分割されるのを待機しているソースファイルのディレクトリの下のデータの流れは、
ソースファイルを、分割されるソースファイル用のディレクトリへ入れる工程と、
ソースファイル処理サーバーを割り当てた後、分割されるのを待機しているソースファイルをファイル分割用の一時ディレクトリへ入れる工程と、
ソースファイルを分割する工程と、
ソースファイルが、成功裏に分割された場合には、ソースファイルを成功裏に分割されたソースファイルを保存するディレクトリにバックアップし、而して取得された小さいファイルを分割後の小さいファイルを保存するディレクトリへ保存する工程、又はソースファイルが、再試行の後分割されなかった場合には、ソースファイルを分割されなかったソースファイルを保存するディレクトリにバックアップする工程と、を含んでいる。
【００１３】
更に、処理されるのを待機している小さいファイルのディレクトリの下のデータの流れは、
小ファイル処理サーバーを割り当てた後、処理されるのを待機している小さいファイルを小さいファイル処理用の一時ディレクトリへ入れる工程と、
一時ディレクトリの小さいファイルを処理する工程と、
１つ又はそれ以上の小さいファイルが、成功裏に処理された場合には、１つ又はそれ以上の小さいファイルを成功裏に処理された小さいファイルを保存するディレクトリへバックアップし、１つ又はそれ以上の小さいファイルが、再処理される必要がある場合には、１つ又はそれ以上の小さいファイルを、部分的に不成功に処理されたレコードを有する小さいファイルを保存するディレクトリへバックアップし、１つ又はそれ以上の小さいファイルが、再施行後処理できなかった場合には、１つ又はそれ以上の小さいファイルを、再施行後処理できなかった小さいファイルを保存するディレクトリへバックアップする、工程と、を含んでいてもよい。
【００１４】
本開示の別の態様は、大容量データ処理のシステムである。当該のシステムは、複数のサーバーを含んでおり、それぞれのサーバーは、前処理ユニット、分割ユニット、及び処理ユニットを含んでいる。前処理ユニットは、ソースファイル命名スキームに基づいて、分割されるのを待機しているソースファイルが、サーバーによって処理されるべきか否かを確定し、処理される場合には、分割ユニットを起動するのに使用される。前処理ユニットは、更に、分割後の小ファイル命名スキームに基づいて、小さいファイルが、サーバーによって処理されるべきか否かを確定し、処理される場合には、処理ユニットを起動するのに使用される。分割ユニットは、ソースファイルを小さいファイルに分割するのに使用される。処理ユニットは、論理的処理を小さいファイルに対して実行するのに使用される。
【００１５】
１つの実施形態では、前処理ユニットは、そこにおいて、ソースファイルのファイル名のソースファイルシーケンス番号に基づいて、ソースファイルが、サーバーによって処理されるべきか否かを確定し、且つ小さいファイルのファイル名のソースファイルシーケンス番号又は小さいファイルのファイル名の小さいファイルシーケンス番号に基づいて、小さいファイルが、サーバーによって処理されるべきか否かを確定している。
【００１６】
別の開発では、前処理ユニットは、ソースファイルに保存されたデータの種類に基づいて、ソースファイルは、サーバーによって処理されるべきか否かを確定している。この場合では、各サーバーは、サーバーによって処理することができるデータの種類を設定するのに使用される設定ユニットを更に有している。
【００１７】
好ましくは、各サーバーは、ソースファイルの分割から取得された小さいファイルをディスクへ保存するのに使用される記憶ユニットを更に含んでいてもよい。記憶ユニットは、ディレクトリ構造を採用することができ、分割されるのを待機しているファイルと処理されるのを待機しているファイルを異なるディレクトリの下へ入れることができる。
【００１８】
好ましくは、各サーバーは、失敗した場合に、ソースファイルを分割する、及び／又は失敗した場合に、小さいファイルを処理する、再試行に使用される再試行ユニットを更に含んでいてもよい。再試行ユニットは、ソースファイルの分割には１回の再試行を許可するが、小さいファイルの処理には複数の再試行を許可することができる。
【００１９】
本開示の例示的な実施形態の幾つかによれば、開示される方法及びシステムは、幾つかの潜在的利点を有している。
【００２０】
第１に、本開示は、大きいファイルを分散及び並行処理することができる方法及びシステムを提供する。並行戦略の制御の下、複数のサーバーは、大きいデータファイルを同時に分割及び処理するように配備することができ、これによって、システムの処理能力を大きく向上させ、且つシステムが、予定時間内にファイルの処理を確実に終わらせることが可能になる。更に、ファイル命名スキームに基づいてファイルの分割及び処理にサーバーを割り当てる並行戦略により、各ソースファイルは、ただ１つのサーバーによって分割され、且つソースファイルの分割によって取得された各小さいファイルも、同様にただ１つのサーバーによって処理されることが確実となり、結果的にリソース競合を回避することができる。
【００２１】
第２に、本開示は、幾つかの異なる並行戦略を開示する。１つの戦略は、ファイル名のソースファイルシーケンス番号によってサーバーを割り当てる。この戦略は、比較的多数のファイルが存在する時に、サーバー間のバランスを保証することができる。別の戦略は、サーバー毎に、サーバーによって処理されることを許可されるデータの種類を設定し、適切なサーバーを処理を待機しているそれぞれの（１つ又は複数の）ファイルに割り当てる。この後者の戦略は、新しいサーバーが追加される時には、設定表の修正だけが必要とされる。実際の用途の必要に応じて、本開示は、その様な２つの並行戦略の組み合わせを使用して、開示されるシステムが、サーバーの稼働レベルのバランスを最大限に保つことができる。
【００２２】
更に、当該のシステムは、良好な拡張性を約束する。ファイルが大きくなる又はファイル数が増えるにつれ、対応する要求を満足させるために、新しいサーバーを追加することが可能である。具体的には、当該のシステムは、より進歩したサーバーの購入及び以前から操作しているサーバーの再配備を行う必要無く線状に拡張することが可能である。
【００２３】
更に、ディスクＩ／Ｏ（入力／出力）の負荷を減らすために、分割されるのを待機しているファイル及び処理されるのと待機しているファイルを異なるディレクトリの下に入れることができ、その後、全てのファイルは、その中でキャッシュに格納することができる。新しいファイルは、キャッシュのファイルが完全に処理されて初めて読み取られる。
【００２４】
本発明の概要は、下文で示す発明を実施するための形態で更に説明される、選択された概念を簡略化した形態で紹介する目的で提供される。本発明の概要は、特許請求の範囲に記載される対象の重要な特徴又は本質的な特徴を特定することを意図するものではなく、且つ特許請求の範囲に記載される対象の範囲を確定する補助として利用されることを意図するものではない。
【図面の簡単な説明】
【００２５】
【図１】本開示による大容量データ処理の例示的な方法の流れ図である。
【図２】ディレクトリ構造においてファイルを分割する例示的な工程の流れ図である。
【図３】ディレクトリ構造においてファイルを処理する例示的な工程の流れ図である。
【図４】本開示による大容量データ処理システムの論理的構造図である。
【図５】図４のシステムの各サーバーの例示的な内部論理的構造を図示する図である。
【発明を実施するための形態】
【００２６】
本開示の特性をいっそう良く理解できるように、開示される方法及びシステムを、添付の図と例示的な実施形態を用いて更に詳細に説明する。
【００２７】
本開示は、並行又は分散方法で大きいファイルを処理する方法及びシステムを提供する。サーバーを割り当てるのにファイル命名スキームを採用する並行戦略によって、複数のサーバーを、大きいデータファイルを同時に分割及び処理するように配備することができる。結果的に、当該の方法は、システムの処理性能を大幅に改善し、システムが大きいデータファイルの処理を、確実に、予定時間内に終えるようにできる。
【００２８】
例えば、送信側は、或る書式の複数の大きいファイルＦｉｌｅＡを作成し、１つ又はそれ以上のファイルＦｉｌｅＡを順次（例えば、２分毎に）受信側へ送信する。ＦｉｌｅＡは、大きいファイルサイズ（例えば、２００Ｍ）を有している。複数の種類は、製品データや発注データ等のデータ種であり得、それぞれの種類は、複数のデータファイルを有し得る。ファイルＦｉｌｅＡを受信すると、受信側は、その後の、ファイルＦｉｌｅＡの論理処理を実行する。論理処理は、比較的に複雑である場合があり、ファイルＦｉｌｅＡをデータベースに保存する等の多くの関連事項を求める場合がある。
【００２９】
上記の実例では、単一のサーバーの処理性能が、１０Ｍ／分である場合には、２０Ｍのデータしか２分以内に処理することができず、残りの１８０Ｍのデータは未処理のままになる。従って、この場合には、開示される方法が目指すのは、受信側のシステムが、２分以内に全てのファイルＦｉｌｅＡの処理を終えることができるようにすることである。
【００３０】
図１は、本開示による大容量データ処理の例示的な方法の流れ図を示している。上記の実例を用いると、本開示は、ビジネス論理に従って大きいデータファイルを処理するために複数のサーバーによる分散及び並行処理を採用する。複数のサーバーは、同じ処理手順を並行して実行することができる。
【００３１】
この例示的な実施形態の前提条件は、送信側から送信されるファイルＦｉｌｅＡは、統一的なファイル命名規則又はファイル命名スキームを用いて命名されることである。この命名規則に従っていないファイルを処理することはできない。従って、送信側から送信されるファイルは、当該の規則に従って命名されるので、受信側はそのままでファイル名を解析することができる。
【００３２】
以下、送信側から送信されたファイルの処理工程の実例を説明目的で使用する。この説明では、処理が説明される順序は、制限であると解釈されることを意図するものではなく、当該の方法又は代替的な方法を実施するために、記載される処理ブロックの何れをも任意の順序で組み合わせることができる。例示的な処理を以下に記述する。
【００３３】
Ｓ１０１では、送信側から送信されたソースファイルＦｉｌｅＡのファイル名が、解析される。
【００３４】
Ｓ１０２では、ソースファイルＦｉｌｅＡのファイル名の解析結果に基づいて、サーバーが、ソースファイルＦｉｌｅＡを分割するために割り当てられる。
【００３５】
Ｓ１０３では、サーバーが、ソースファイルＦｉｌｅＡを複数の小さいファイルＦｉｌｅＹに分割する。
【００３６】
ファイルが分割される時に、ファイルは、Ｎ個のより小さいＦｉｌｅＹに分割される、Ｎの値（小さいファイルの数）は、実践的な状況によって決められ、主として、処理に使用可能なサーバーの数によって決定される。
【００３７】
Ｓ１０４では、ソースファイルＦｉｌｅＡを分割することによって取得された各々の小さいファイルＦｉｌｅＹは、分割後小ファイル命名規則に従って自動的に命名される。
【００３８】
Ｓ１０５では、小さいファイルＦｉｌｅＹのファイル名が、解析される。
【００３９】
Ｓ１０６では、各小さいファイルＦｉｌｅＹのファイル名の解析結果に基づいて、サーバーが、小さいファイルＦｉｌｅＹを処理するために割り当てられる。
【００４０】
Ｓ１０７では、割り当てられたサーバーが、その後の論理処理を分散して実行する。
【００４１】
ソースファイルと（ソースファイルを分割して取得された）各小さいファイルは、それぞれ独自の命名規則を有している。具体的な詳細を下記に示す。
【００４２】
例示的なソースファイル命名規則は、以下の通りである。
【００４３】
例示のファイル名：ＤａｔｅＴｉｍｅ＿Ｓｅｑｕｅｎｃｅ＿ＤａｔａＴｙｐｅ．ＴＸＴここにおけるファイル名の各パラメータの意味を以下で説明する。
【００４４】
ＤａｔｅＴｉｍｅは、データがエクスポートされた時間を表わしており、１秒までの精度を有している。例示的な対応するフォーマットは、年、月、日、時、分、秒（例えば、２００７０２０９１３３０１０）である。
【００４５】
Ｓｅｑｕｅｎｃｅは、データページングのシーケンス番号（１つのファイルが大きくなり過ぎるのを防ぐために用いられる）を表わしており、ソースファイルシーケンス番号と呼ばれる場合もある。Ｓｅｑｕｅｎｃｅは、００１から始まって増えてゆく３桁を有するように決めてもよい。
【００４６】
ＤａｔａＴｙｐｅは、ファイルに保存されるデータの種類を表わしている。例えば、「ｕｓｅｒ」は、ユーザーデータを表わし、「ｏｒｄｅｒ」は、発注データを表わし、「ｓａｍｐｌｅ」は、製品データを表わしている。
【００４７】
上述のように、各データ種のＤａｔａＴｙｐｅは、複数のデータファイルを有していてもよい。
【００４８】
例示的な分割後の小ファイル命名規則は、以下の通りである。
【００４９】
ファイル名の実例：
ＳｕｂＤａｔｅＴｉｍｅ＿ＤａｔｅＴｉｍｅ＿Ｓｅｑｕｅｎｃｅ＿ＳｕｂＳｅｑｕｅｎｃｅ＿ｒｅｔｒｙＸ＿ＤａｔａＴｙｐｅ．ＴＸＴ、ここにおける各パラメータの意味を以下に記述する。
【００５０】
ＤａｔｅＴｉｍｅ、Ｓｅｑｕｅｎｃｅ及びＤａｔａＴｙｐｅの意味は、ソースファイル用の規格と意味と同じである。
【００５１】
ＳｕｂＤａｔｅＴｉｍｅは、サブファイル（即ち、小さいファイル）がエクスポートされた時間を表わしており、デフォルト値は、ＤａｔｅＴｉｍｅと同じである。しかしながら、再試行後は、ＳｕｂＤａｔｅＴｉｍｅとＤａｔｅＴｉｍｅは、同じではない場合がある。具体的な詳細は再施行に関する後の説明で示す。
【００５２】
ＳｕｂＳｅｑｕｅｎｃｅは、対応するソースファイルの分割後に作成される小さいファイルのシーケンス番号を表わしている。例示的なＳｕｂＳｅｑｕｅｎｃｅは、０００１から始まって増えてゆく４桁を有するように決められる。
【００５３】
ｒｅｔｒｙＸのＸは、対応するファイルを処理するために実際に行われた再試行の数を表わしている。ファイルが、１回目で処理される場合には、Ｘは０である。１回失敗すると、Ｘは１に変更され、Ｘは、その後適宜に増えてゆく。増えてゆく間、ｒｅｔｒｙＸの前にある対応するＳｕｂＤａｔｅＴｉｍｅをそれに合わせて修正するように留意される。例示的な規則は、ＳｕｂＤａｔｅＴｉｍｅを現在のシステム時間＋再試行時間間隔になるように決める。
【００５４】
ソースファイルのＤａｔｅＴｉｍｅは、分割後の小さいファイルのファイル名の中に依然と含まれる。ＤａｔｅＴｉｍｅを保存する主目的は、その後の処理で問題が生じた場合のエラーチェックを可能にするためである。
【００５５】
ブロックＳ１０２及びＳ１０６は、共に、合理的にサーバーを割り当てるために、ファイル名解析結果に依存している。具体的には、サーバーは、ソースファイルを分割し、分割後の小さいファイルを処理するために指名される。サーバーシステム全体の実行という観点から見ると、これは、並行実行の工程である。具体的には、或る１つのサーバーが、ソースファイルの分割に割り当てられる時点で、別のサーバーを先の分割で取得された小さいファイルの処理に割り当てることができる。
【００５６】
本開示は、ソースファイルの分割及び分割後の小さいファイルの処理を行う、２つの例示的な種類の並行戦略を提供する。並行戦略の例示的な原理は、リソース競合を防ぐために、ソースファイルを、１つのサーバーだけが分割することを可能にし、且つ各分割後の小さいファイルを、１つのサーバーだけが処理することを可能にすることである。
【００５７】
１つの例示的な戦略は、数式、
（Ｓｅｑｕｅｎｃｅ／ＳｕｂＳｅｑｕｅｎｃｅ）％（割り当て待機サーバー数）＋１、を使用して、モジュロ演算をファイル名のＳｅｑｕｅｎｃｅ又はＳｕｂＳｅｑｕｅｎｃｅに適用することであり、
ここにおける、「％」は、モジュロ演算子を表わし、「＋１」（１の追加）は、算出結果がゼロにならないようにするものである。
【００５８】
例えば、使用可能なサーバーの数が３であり、ファイル名が、２００７０４２９１６０００１＿００ｘ＿ｏｒｄｅｒ．ｔｘｔであって、００ｘは、Ｓｅｑｕｅｎｃｅを表わしている、と仮定する。
【００５９】
上記の数式を使用すると、ｘ％３＋１が、最初に算出される。結果が１の場合には、対応するファイルは、サーバー１によって処理されるように割り当てられる。結果が２の場合には、ファイルは、サーバー２によって処理されるように割り当てられる。結果が３の場合には、ファイルはサーバー３によって処理されるように割り当てられる。
【００６０】
デフォルト設定では、割り当て用の同じ決定を小さいファイルの処理とソースファイルの分割の両方に使用してもよい。例えば、小さいファイルの処理の割り当て及びソースファイルの分割の割り当ては、共に、対応するファイル名のＳｅｑｕｅｎｃｅに基づいてもよい。しかしながら、サーバー間の更なる均等性を確実にするために、割り当ての決定は、好ましくは、小さいファイルの処理のＳｕｂＳｅｑｕｅｎｃｅに基づく。
【００６１】
サーバーを均等に割り当てるのに、ファイル名のＳｅｑｕｅｎｃｅ又はＳｕｂＳｅｑｕｅｎｃｅに基づく、いかなる他の適切な数式も使用してもよいことを理解されたい。モジュロ演算を利用する上記の数式は、単に、説明のための実例であると意図されているものである。
【００６２】
前述の戦略は、サーバーの比較的均等な割り当てを実現することができる。しかしながら、ファイル数は、常に、使用可能なサービスの数（例えば、本実例では３）の倍数であるわけではないので、サーバー１及びサーバー２は、サーバー３より幾らか多いファイルを処理する可能性がある。更に、比較的に小さいデータ容量を有するファイルは、１つの分割された小さいファイルだけを有する場合があり、而して、この規則に従うと、常にサーバー１によって処理される可能性がある。従って、この戦略は、処理されるべきファイル数が大きい状況に適している。ファイルの数が大きくなればなるほど、サーバー間の均等性が増すことになる。しかしながら、新しいサーバーが追加される場合には、使用可能なサーバーの数は変わり、異なるサーバー割り当てを引き起こし、結果的には、全てのサーバーを再配備する必要がある。
【００６３】
別の戦略では、サーバー毎に、処理することが可能であり、そのサーバーによって処理されることが唯一許可されているＤａｔａＴｙｐｅを設定する。この戦略によれば、システムは設定表を提供しており、設定項目は、処理することが可能であり、そのサーバーによって処理されることが唯一許可されているＤａｔａＴｙｐｅを、サーバー毎に示している。例えば、サーバー１、サーバー２及びサーバー３は、発注データ、ユーザーデータ、及びサンプルデータをそれぞれ処理するように設定されてもよい。これらの設定項目を決める中で、サーバー間のコンフリクトが、設定に存在しないようにすることが要求される場合がある。コンフリクトが存在する場合には、設定エラーについての警告が提供される。
【００６４】
上述の並行戦略のどちらも、ソースファイルを分割するために、及び小さいファイルを処理するために複数のサーバーを同時にうまくスケジュールすることができる。特定用途の要件に応じて、実際的な利用では、２つの戦略のどちらか１つを選択することができる。これらの並行戦略は、相互排他的ではないので、好ましくは、それらが組み合わされる。例えば、複数のサーバーが、ＤａｔａＴｙｐｅとして「発注」を有するファイル（即ち、発注データを有するファイル）の処理に割り当てられる一方、サーバー３は、ユーザーデータだけの処理に割り当てられ、サーバー２は、サンプルデータだけの処理に割り当てられる。これは、サーバー間の処理の均等性を最大化し、且つサーバーの稼働レベル間のバランスを最大化するのを促進する。
【００６５】
図１に示すようなソースファイルの分割及び小さいファイルの処理では、上記の第１の戦略が用いられる場合には、ソースファイルのファイル名は、Ｓｅｑｕｅｎｃｅを取得するために解析され、一方で小さいファイルのファイル名は、Ｓｅｑｕｅｎｃｅ又はＳｕｂＳｅｑｕｅｎｃｅを取得するために解析される。第２の戦略が用いられる場合には、ＤａｔａＴｙｐｅは、ファイル名から取得される。２つの戦略の組み合わせが用いられる場合には、Ｓｅｑｕｅｎｃｅ又はＳｕｂＳｅｑｕｅｎｃｅ、及びＤａｔａＴｙｐｅを同時に取得することができる。どちらの並行戦略が採用されても、どのサーバーがファイルの分割又は処理に使用されるのかは、目的ファイルのファイル名によって決定される。各サーバーは、それ（現在のサーバー）に指定されたファイルの処理だけを行うことができる。
【００６６】
好ましくは、サーバーが、ソースファイルを分割した後、対応する分割後小ファイルはディスクに保存される。小さいファイルを処理する必要がある時には、小さいファイルは、ディスクから取得される。サーバーによるソースファイルの分割によって取得される小さいファイルが、ディスクに完全に書き込まれていない場合には、この小さいファイルは、処理されることが許可されない。小さいファイルが、この状況で処理されると、別のサーバー（小さいファイルを処理するサーバー）によって読み取られる小さいファイルの内容は、完全ではない可能性があるので、この予防措置が必要とされる。
【００６７】
好ましくは、エラーが、分割又は処理の間に生じる場合には、対応する誤りのある部分は、再処理される。更に、多くのファイルが、分割又は処理されるのを待機している場合には、ファイルは時間的順序で処理されることが可能である。
【００６８】
全般的には、複数のサーバーによる分散及び並行処理のこの方法は、特に大きいファイルを処理する時には、システムの処理能力を大きく改善する可能性があり、サーバーの稼働レベルの平衡を最大限に保つことができる。更に、この方法は、良好な拡張性を約束する。具体的には、当該のシステムは、より進歩したサーバーの購入及び以前から操作しているサーバーの再配備を行う必要無く線状に拡張することが可能である。
【００６９】
ファイル走査に起因するディスクＩ／Ｏ負荷を減らすために、本開示は、分割されるファイル及び処理されるファイルを、異なるディレクトリの下に入れ、ファイルをファイルごとに個別のディレクトリでキャッシュに格納することが好ましい。キャッシュのファイルを処理した後、別のファイルを読み取る。処理順序は、ファイル名の自然順序付けに依存している（即ち、時間的に早いＤａｔａＴｙｐｅのファイルが最初に処理される、ファイル名のＤａｔａＴｙｐｅの昇順に従って）。
【００７０】
ファイル処理に関する例示的なディレクトリ構造は、以下のようになる。
【００７１】
／ｒｏｏｔ  ／／ルートディレクトリ
／ｓｏｕｒｃｅ＿ｆｉｌｅ  ／／分割されるソースファイルのディレクトリ
／ｔｍｐ＿ｄｉｖｉｄｅ  ／／ファイル分割時に使用される一時ディレクトリ
／ｈｏｓｔｎａｍｅＡ  ／／現在の分割用サーバーのホスト名
／ｈｏｓｔｎａｍｅＢ  ／／
・・・  ／／これらのディレクトリ名は、サーバーの数によって動的に割り当てられる
／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅ  ／／ソースファイルの分割から取得される小さいファイルの保存
／ｔｍｐ＿ｅｘｅｃｕｔｅ  ／／ビジネス論理に従って或る小さいファイルの処理の間使用される一時ディレクトリ
／ｈｏｓｔｎａｍｅＡ  ／／現在の処理用サーバーのホスト名
／ｈｏｓｔｎａｍｅＢ  ／／
・・・  ／／これらのディレクトリ名は、サーバーの数によって動的に割り当てられる
／ｂａｋ＿ｓｕｃｓ＿ｆｉｌｅ  ／／成功裏に分割されたソースファイルをバックアップする
／２００７０２１２  ／／現在の日付
／ｈｏｕｒ  ／／現在の日付の時間、例えば、１０、２０
／２００７０２１３  ／／
／ｈｏｕｒ  ／／
・・・  ／／現在の日付によって動的に追加する
／ｂａｋ＿ｓｕｃｓ＿ｓｍａｌｌ  ／／成功裏に処理された小さいファイルをバックアップする
／２００７０２１２  ／／現在の日付
／ｈｏｕｒ  ／／現在の日付の時間、例えば、１０、２０
／２００７０２１３  ／／
／ｈｏｕｒ  ／／
・・・  ／／現在の日付によって動的に追加する
／ｂａｋ＿ｅｒｒｏｒ  ／／記録されたが、部分的に処理できなかった小さいファイルをバックアップする
／２００７０２１２  ／／現在の日付
／ｈｏｕｒ  ／／現在の日付の時間、例えば、１０、２０
／２００７０２１３  ／／
／ｈｏｕｒ  ／／
・・・  ／／現在の日付によって動的に追加する
／ｅｒｒｏｒ＿ｄｉｖｉｄｅ  ／／小さいファイルへの分割にエラーを有したソースファイルをバックアップする
／２００７０２１２  ／／現在の日付
／ｈｏｕｒ  ／／現在の日付の時間、例えば、１０、２０
／２００７０２１３  ／／
／ｈｏｕｒ  ／／
・・・  ／／現在の日付によって動的に追加する
／ｅｒｒｏｒ＿ｅｘｅｃｕｔｅ  ／／５回を超える再試行の失敗で不成功に処理された小さいファイルをバックアップする
／２００７０２１２  ／／現在の日付
／ｈｏｕｒ  ／／現在の日付の時間、例えば、１０、２０
／２００７０２１３  ／／
／ｈｏｕｒ  ／／
・・・  ／／現在の日付によって動的に追加する
上記のディレクトリ構造は、説明目的のためだけに、ここでの例示的な実施形態で使用されている。ディレクトリ構造は、自己調整されてもよい。例えば、／ｈｏｕｒディレクトリが必要とされるか否かは、システムによるソースファイルの分割から取得される小さいファイルの数に依存している。オペレーティングシステムには、ファイルの数、ディレクトリツリーの大きさ及びディレクトリの下のファイルの最大数に制限があるので、システムの性能は、１つのディレクトリの下のファイルの数が大きすぎる場合には大きな影響を受ける可能性がある。
【００７２】
実際には、上記のディレクトリ構造を作成する工程は、図１のソースファイルの分割工程及び小さいファイルの処理工程と同期しており、図１に示す工程を反映し得る。ディレクトリ全体のデータの流れを通して。この様な工程は、本質的に、ファイル分割及びファイル処理にデータの流れを含んでいる。具体的な詳細を以下に記述する。
【００７３】
図２は、ディレクトリ構造における大きいソースファイルを分割する例示的な工程を図示している流れ図を示している。この工程を先に記述したディレクトリ構造に関連させながら下文で記述する。
【００７４】
Ｓ２０１では、送信側から伝送されたソースファイルは、ディレクトリ／ｓｏｕｒｃｅ＿ｆｉｌｅの下に入れられる。
【００７５】
Ｓ２０２では、ディレクトリ／ｓｏｕｒｃｅ＿ｆｉｌｅの下で分割されるのを待機しているソースファイルは、ファイル名に基づいてサーバーに割り当てられる。複数のスレッドによる同じソースファイルの分割を回避するために、ファイルは、更に、対応するディレクトリ／ｔｍｐ＿ｄｉｖｉｄｅ／ｈｏｓｔｎａｍｅの下に入れられ、このディレクトリは、好ましくは、割り当てられたサーバーのディレクトリである。この工程を、ファイル名の変更と称する。
【００７６】
Ｓ２０３では、サーバーは、分割されるのを待機しているソースファイルを分割する。ソースファイルが、成功裏に分割される場合には、分割によって取得された小さいファイルは、ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅの下で保存される。成功裏に分割されたソースファイルは、ディレクトリ／ｂａｋ＿ｓｕｃｓ＿ｆｉｌｅの下でバックアップされる。
【００７７】
Ｓ２０４では、上記の分割工程が失敗した場合には、分割の再試行が試みられる。最初の試行が、成功した場合には、工程はＳ２０３に戻り、分割から取得された小さいファイルは、ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅの下で保存される。成功裏に分割されたソースファイルは、ディレクトリ／ｂａｋ＿ｓｕｃｓ＿ｆｉｌｅの下でバックアップされる。再試行も失敗した場合には、ソースファイルは、ディレクトリ／ｅｒｒｏｒ＿ｄｉｖｉｄｅの下でバックアップされる。
【００７８】
図３は、ディレクトリ構造における分割後の小さいファイルを処理する例示的な工程を図示している流れ図を示している。この工程を、先に記述したディレクトリ構造に関連させながら記述する。
【００７９】
Ｓ３０１では、ソースファイルの分割から取得された小さいファイルは、ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅの下に入れられる。
【００８０】
Ｓ３０２では、ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅの下で処理されるのを待機している小さいファイルは、ファイル名に基づいてサーバーに割り当てられる。複数のスレッドによる同じ小さいファイルの処理を回避するために、小さいファイルは、更に、対応するディレクトリ／ｔｍｐ＿ｅｘｅｃｕｔｅ／ｈｏｓｔｎａｍｅの下に入れられ、このディレクトリは、好ましくは、割り当てられたサーバーのディレクトリである。この工程を、ファイル名の変更と称する。
【００８１】
Ｓ３０３では、割り当てられたサーバーは、処理されるのを待機している小さいファイルを論理的に処理する。成功裏に処理される場合には、処理された小さいファイルは、ディレクトリ／ｂａｋ＿ｓｕｃｓ＿ｓｍａｌｌの下で保存される。
【００８２】
Ｓ３０４では、処理にエラーが発生する場合には、再試行が試みられる。許容再試行数は、例えば５に決められてもよい。
【００８３】
処理の再試行を待機している小さいファイルは、ディレクトリ／ｂａｋ＿ｅｒｒｏｒの下でバックアップされる。再試行を試みる時には、工程はＳ３０１へ戻る。具体的には、Ｓ３０３で処理できなかった小さいファイルは、ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅの下に戻され、再び最初に割り当てられたサーバーによって処理される。成功しなかった再試行の数が、許容される再試行の最大数（例えば、５回）を超える場合には、小さいファイルは、ディレクトリ／ｅｒｒｏｒ＿ｅｘｅｃｕｔｅの下でバックアップされる。
【００８４】
例示的な実施形態では、ソースファイルを分割する再試行数と小さいファイルを処理する再試行数は、同じではない。大きいソースファイルの分割にエラーが生じる場合には、分割の再試行が行われる。再試行が分割に更に失敗する場合には、ソースファイルは、「エラーディレクトリ」（即ち、／ｅｒｒｏｒ＿ｄｉｖｉｄｅ）へ直接伝送される。エラーログが、警告が提供されると同時に書き込まれる。しかしながら、小さいファイルのビジネス論理処理に発生するエラーを対処するために、より柔軟な再試行機構が、利用される。ソースファイルを分割するエラー率は、非常に小さいが、その後のビジネス論理処理の失敗は、より頻繁に発生するという理由から、複数の再試行が、小さいファイルの処理に関して許される。
【００８５】
複数の再試行が、小さいファイルに関して試みられ得るので、再試行間隔の表が、設定される。許容再試行数と次の再試行を行うまでの待機に要する期間は、手動で決めてもよい。例えば、許容再試行数は、５に決めてもよい。５回の不成功の再試行が行われた場合には、小さいファイルは処理されずに「エラーディレクトリ」へ伝送される。警告が提供されると同時に、エラーログが、書き込まれる。従って、サーバーが、処理用に特定のファイルを取得する時に、サーバーは、そのファイルのＳｕｂＤａｔｅＴｉｍｅが、現在の時間より前である否かを確定する必要がある。そうである場合には、サーバーは、ファイルを処理する。そうでない場合には、ファイルは処理されない。
【００８６】
上述のように、１つの或るサーバーによるソースファイルの分割から取得される小さいファイルが、ディスクへ完全に書き込まれていない場合には、この小さいファイルは、処理されることが許可されない。ディスクへ完全に書き込まれていない小さいファイルの処理を回避するために、ディレクトリ構造は、利用される。小さいファイルは、最初に一時ディレクトリ／ｓｏｕｒｃｅ＿ｓｍａｌｌｆｉｌｅへ書き込まれる。成功裏に書き込まれると、小さいファイルは、ファイル名を変更され、別のディレクトリ／ｔｍｐ＿ｅｘｅｃｕｔｅ／ｈｏｓｔｎａｍｅへ伝送される。ファイル名の変更は、微小処理であり、修正する必要があるのはファイルポインタだけなので、この工程は、データの整合性を保証するものである。
【００８７】
本開示は、更に大容量データ処理の例示的なシステムを提供する。
【００８８】
図４は、本開示による大容量データ処理の例示的なシステムの論理構造図を示している。
【００８９】
図４に示しているように、システム４００は、複数のサーバー４１０を含む分散構造を採用しており、各サーバーは、ソースファイル４２０を分割する能力とソースファイル４２０の分割から取得される小さいファイル４３０を処理する能力を有している。予定時間内に送信側から受信側へ伝送されるデータを処理する実例という観点から、システム４００は、受信側に配備されており、下文では受信側システムと称する。受信側システム４００の複数のサーバー４１０は、同じ手順を並行して実行することができる。
【００９０】
受信側システム４００の複数のサーバー４１０によって送信側から送られる大きいソースファイルＦｉｌｅＡを並行処理する例示的な工程を、以下に記述する。
【００９１】
大きいファイルＦｉｌｅＡ（４２０）は、最初にディレクトリ／ｓｏｕｒｃｅ＿ｆｉｌｅの下に入れられる。各サーバー４１０は、送信側から送られ、このディレクトリの下に入れられる大きいファイル４２０を常に走査している。前述の並行戦略（ここでは再度説明せず）に基づいて、各サーバーｓｅｒｖｅｒＡ（４１０）は、ファイル４２０が、現在のサーバーによって分割されるべきか否かをファイルのファイル名に基づいて確定する。現在のサーバーによって処理される必要のあるファイルＦｉｌｅＡを取得すると、サーバーｓｅｒｖｅｒＡは、このファイルをＮ個のより小さいファイルＦｉｌｅＹへ分割する。Ｎの値は、実際の状況に依存し、主として、小さいファイルの処理に使用可能なサーバー４１０の数によって確定される。１つの並行戦略に従って、複数のサーバーｓｅｒｖｅｒＸは、ソースファイルの分割から取得される小さいファイルＦｉｌｅＹの何れか（１つ又は複数）が、複数のサーバーｓｅｒｖｅｒＸによって処理されるべきか否かを更に確定する。サーバーｓｅｒｖｅｒＢによって処理されるべき小さいファイルＦｉｌｅＹを取得すると、例えば、サーバーｓｅｒｖｅｒＢは、小さいファイルＦｉｌｅＹのその後の論理処理を実行する。
【００９２】
上記の工程では、リソース競合を防止するために、１つのサーバーだけが、ソースファイルＦｉｌｅＡを分割することを許可され、１つのサーバーだけが、ソースファイルＦｉｌｅＡの分割から取得される小さいファイルＦｉｌｅＹのそれぞれを処理することを許可するようにすることが好ましい。更に、或るサーバーが、繁忙になりすぎている一方、他のサーバーは待機状態にある状況を回避するために、各サーバーの稼働レベルが、最大限度まで平衡を保たれる。これは、本開示で記述している並行戦略によって達成することができる。更に、開示されるシステムは、非常に柔軟であり、良好な拡張性を有しており、或る種類のファイルを処理する各サーバーの独立した設定を支援することができる。幾つかの実施形態では、この様な次第で、新しいサーバーが追加される際、以前に稼働していたサーバーを再設定し、新しい設定で再配備される必要が無い。
【００９３】
好ましくは、小さいファイルの読み取り整合性を確実にするために、ソースファイルが分割された後で、ソースファイルの分割から取得される小さいファイルは、ディスクへ保存される。更に、ファイル分割又はファイル処理にエラーが生じる場合には、エラー部分は再処理される。多くのファイルが分割又は処理されるのを待機している場合には、ファイルは、時間的順序で分割又は処理される。
【００９４】
図５は、システム４００の各サーバーの例示的な内部論理の構造図を示している。サーバー５１０は、前処理ユニットＵ５０１、分割ユニットＵ５０２及び処理ユニット５０３を含んでいる。
【００９５】
前処理ユニットＵ５０１は、ディレクトリ内のファイルが、サーバー５１０によって処理されるべきか否かを確定するために、定期的にディスクのディレクトリを走査するのに使用される。具体的には、前処理ユニットＵ５０１は、ソースファイルが、現在のサーバー５１０によって分割されるべきか否かを確定する。確定は、ソースファイル命名スキームに従って付与されたソースファイルのファイル名に基づいている。回答が肯定的である場合には、前処理ユニットＵ５０３は、分割ユニットＵ５０２を起動してソースファイルを分割させる。前処理ユニットＵ５０１は、更に、小さいファイルが、サーバー５１０によって処理されるべきか否かを確定する。確定は、分割後の小ファイル命名スキームに従って付与された小さいファイルのファイル名に基づいている。そうである場合には、前処理ユニットＵ５０１は、処理ユニットＵ５０２を起動して小さいファイルを処理させる。分割ユニットＵ５０２は、ソースファイルを小さいファイルへ分割するのに使用される。処理ユニットＵ５０３は、上記の確定によって、サーバー５１０によって処理される小さいファイルの論理処理を実行するのに使用される。
【００９６】
上述の並行戦略によれば、第１の戦略が用いられる場合には、前処理ユニットＵ５０１は、ファイルのファイル名のソースファイルシーケンス番号に基づいて、ソースファイルが、サーバー５１０によって処理されるべきか否かを確定し、且つ小さいファイルのファイル名の対応するソースファイルシーケンス番号又は小さいファイルのファイル名の小さいファイルシーケンス番号に基づいて、小さいファイルが、サーバー５１０によって処理されるべきか否かを確定する。
【００９７】
第２の戦略が採用される場合には、前処理ユニットＵ５０１は、ソースファイルに保存されるデータの種類に基づいて、ソースファイルは、サーバー５１０によって分割されるべきか否かを確定する。サーバー５１０は、サーバー５１０によって処理することができるデータの種類を設定するのに使用される設定ユニットＵ５０４を更に含んでいる。確定する間、前処理ユニットＵ５０１は、ソースファイルに保存されたデータのデータ種は、サーバー５１０によって処理することができる型か否かを確定する。
【００９８】
好ましくは、ソースファイルの分割から取得される小さいファイルの読み取り整合性を保証するために、サーバー５１０は、小さいファイルをディスクに保存するのに使用される記憶ユニットＵ５０５を更に含んでいてもよい。更に、ファイル走査に起因するディスクＩＯ負荷を減らすために、記憶ユニットＵ５０５は、ディレクトリ構造を採用しており、分割されるのを待機しているファイル及び処理を待機しているファイルを異なるディレクトリの下に入れている。
【００９９】
好ましくは、サーバーは、作業が失敗した際に、ソースファイルを分割する又は小さいファイルを処理する再試行に使用される再試行ユニットＵ５０６を更に含んでいてもよい。用途の必要にもとづいて、ソースファイルの分割には、１回の再試行が試みられる一方、小さいファイルの処理には、複数の再試行が試みられる場合がある。
【０１００】
結論として、システム４００は、システム４００の処理能力を向上するための複数のサーバー４１０（５１０）による並行実行を支援する。記述された当該のシステム４００は、更に、非常に良好な拡張性も有している。
【０１０１】
図４及び図５から除外されたシステム４００のいかなる詳細部も、図１、図２及び図３で開示される方法の関連部分で見つけることができ、それ故に、ここでは繰り返されていない。
【０１０２】
上記の受信側システム４００に代替する機器構成を使用してもよいものと理解されたい。例えば、サーバー４１０は、一方は送信側に配置され、他方は受信側に配置される２つのグループに分割されてもよい。ソースファイルは、送信側で第１グループのサーバーによって分割され、その結果得られる分割後の小さいファイルは、受信側へ送信され、第２グループのサーバーによって処理される。或いは、システムは、送信側及び受信側を必要としなくてもよく、ファイル分割とファイル処理を行う複数のサーバーを含む１つの側だけを有している。
【０１０３】
上で、本開示の大容量データ処理の方法及びシステムの詳細な説明がなされた。例示的な実施形態は、本開示における本開示の概念及び実施を説明する目的で採用されている。
【０１０４】
本明細書で論じられる潜在的恩恵及び利点は、添付の特許請求の範囲を限定又は制限するものと解釈されるべきではないものと理解されたい。
【０１０５】
対象物は、構造的な特徴及び／又は方法論的活動に特有の専門用語を用いて説明されたが、本特許請求の範囲で画定される対象物は、記述された特有の特徴又は活動に必ずしも限定されるものではないものと理解頂きたい。それどころか、特有の特徴及び活動は、本特許請求の範囲を実施する例示的な形態として開示される。
【図１】
0005438100.tif 000002
【図２】
0005438100.tif 000003
【図３】
0005438100.tif 000004
【図５】
0005438100.tif 000005
【図４】
0005438100.tif 000006