特表 2022-550401 データのアップロード方法、システム、装置及び電子機器

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-12-01

(54)【発明の名称】データのアップロード方法、システム、装置及び電子機器

(51)【国際特許分類】

   G06F 16/182 20190101AFI20221124BHJP

   G06F 16/28 20190101ALI20221124BHJP

   H04L 67/1074 20220101ALI20221124BHJP

【ＦＩ】

G06F16/182 100

G06F16/28

H04L67/1074

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022519757

(86)(22)【出願日】2020-05-15

(85)【翻訳文提出日】2022-03-29

(86)【国際出願番号】 CN2020090654

(87)【国際公開番号】W WO2021082401

(87)【国際公開日】2021-05-06

(31)【優先権主張番号】201911048190.3

(32)【優先日】2019-10-30

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】522021952

【氏名又は名称】京▲東▼科技信息技▲術▼有限公司

(74)【代理人】

【識別番号】110000338

【氏名又は名称】特許業務法人ＨＡＲＡＫＥＮＺＯ ＷＯＲＬＤ ＰＡＴＥＮＴ ＆ ＴＲＡＤＥＭＡＲＫ

(72)【発明者】

【氏名】曹龍

(72)【発明者】

【氏名】馬超

(72)【発明者】

【氏名】孫海波

(72)【発明者】

【氏名】王義

(72)【発明者】

【氏名】趙銘

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175AA01

5B175CA09

(57)【要約】

本出願は、ブロックチェーン技術分野に属するデータのアップロード方法を提供した。前記方法は、ターゲットノードのスレーブサーバにより送信されたブロックアップロード要求を受信することと、前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断することと、前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムにアップロードされていない場合、前記ブロックデータを取得し、且つ前記ブロックデータを前記ブロックデータ記憶システムにおける記憶空間にアップロードすることと、アップロードが成功した場合、前記ターゲットノードにおける軽量ｐｅｅｒに記憶された前記ブロックデータを削除するよう前記スレーブサーバに指示しやすくするために、アップロード成功命令を前記スレーブサーバに送信することとを含む。本発明の実施例の利点として、本発明は、各ノードの履歴帳簿を集中的に記憶するブロックデータ記憶システムを採用し、各ノードが最新の情報データのみを保存することによって、磁気ディスクの占有量を減らすことができ、磁気ディスクの冗長情報も減らすことができる。

【特許請求の範囲】

【請求項1】

データのアップロード方法であって、
ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信することと、
前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断することと、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムにアップロードされていない場合、前記ブロックデータを取得し、前記ブロックデータを前記ブロックデータ記憶システムにおける記憶空間にアップロードすることと、
アップロードに成功した場合、前記ターゲットノードにおける軽量ｐｅｅｒに記憶された前記ブロックデータを削除するように前記スレーブサーバに指示するために、アップロード成功命令を前記スレーブサーバに送信することと、を含む、ことを特徴とするデータのアップロード方法。

【請求項2】

前記方法は、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムに既にアップロードされた場合、前記スレーブサーバに前記軽量ｐｅｅｒのブロックデータを削除するために、前記スレーブサーバにアップロード済みの応答を送信することをさらに含む、ことを特徴とする請求項１に記載の方法。

【請求項3】

前述した、前記ブロックデータを取得することは、
前記ブロックデータ記憶システムと同一のローカルエリアネットワークにある全量ｐｅｅｒから前記ブロックデータを取得することを含む、ことを特徴とする請求項１に記載の方法。

【請求項4】

前述した、前記ブロックデータを取得することは、
前記スレーブサーバと同一のローカルエリアネットワークにある前記軽量ｐｅｅｒから前記ブロックデータを取得することを含む、ことを特徴とする請求項１に記載の方法。

【請求項5】

前記方法は、
前記ブロックアップロード要求から前記ブロックデータの識別子情報を解析することと、
前記識別子情報に基づき、前記ブロックアップロード要求に対応する前記ブロックデータを決定することと、をさらに含む、ことを特徴とする請求項１に記載の方法。

【請求項6】

前述した、前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断することは、
履歴ブロックアップロード要求を記録することと、
前記ブロックアップロード要求に含まれる前記識別子情報が前記履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断することと、
一致すると、前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムに既にアップロードされたと判定することと、を含む、ことを特徴とする請求項５に記載の方法。

【請求項7】

前記方法は、
前記スレーブサーバにより送信されるデータ照会要求を受信することであって、前記データ照会要求は、前記軽量ｐｅｅｒのブロックデータの照会を要求するために用いられることと、
前記ブロックデータ記憶システムが前記データ照会要求に基づき、前記ブロックデータを含むブロック記憶データを検索するように、前記データ照会要求を前記ブロックデータ記憶システムに送信することと、
前記ブロックデータ記憶システムにより送信される前記ブロック記憶データを受信することと、
前記スレーブサーバが前記ブロック記憶データを前記軽量ｐｅｅｒに送信し、前記軽量ｐｅｅｒを介して前記ブロック記憶データから前記ブロックデータを照会するように、前記ブロック記憶データを前記スレーブサーバに送信することと、をさらに含む、ことを特徴とする請求項１に記載の方法。

【請求項8】

データアップロードシステムであって、
ブロックデータを記憶するための軽量ｐｅｅｒと、
ブロックアップロード要求を受信し、前記ブロックデータをブロックデータ記憶システムに送信し、及びアップロード終了後にアップロード成功命令をスレーブサーバに送信するためのサーバと、
前記サーバにより送信される前記ブロックデータを受信し、アップロード終了情報を前記サーバに送信するためのブロックデータ記憶システムと、
前記サーバから前記アップロード成功命令を受信し、前記軽量ｐｅｅｒのブロックデータを削除するためのスレーブサーバと、を含む、ことを特徴とするデータアップロードシステム。

【請求項9】

データのアップロード装置であって、
ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信するための受信モジュールと、
前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断するための判断モジュールと、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムにアップロードされていない場合、前記ブロックデータを取得し、前記ブロックデータを前記ブロックデータ記憶システムにおける記憶空間にアップロードするための取得モジュールと、
アップロードに成功した場合、前記ターゲットノードにおける軽量ｐｅｅｒに記憶された前記ブロックデータを削除するように前記スレーブサーバに指示するために、アップロード成功命令を前記スレーブサーバに送信するための送信モジュールと、を含む、ことを特徴とするデータのアップロード装置。

【請求項10】

メモリと、プロセッサとを有し、前記メモリには、前記プロセッサで実行できるコンピュータプログラムが記憶されており、前記プロセッサが前記コンピュータプログラムを実行する時に上記請求項１乃至７のいずれか１項に記載の方法のステップを実現させる、ことを特徴とする電子機器。

【請求項11】

プロセッサによって実行可能な不揮発性プログラムコードを有するコンピュータ可読媒体であって、前記プログラムコードは、前記プロセッサに前記請求項１乃至７のいずれか1項に記載の方法を実行させる、ことを特徴とするコンピュータ可読媒体。

【発明の詳細な説明】

【発明の詳細な説明】

【0001】

〔関連出願の相互参照〕
本出願は、２０１９年１０月３０日に中国特許局に提出された、出願番号は２０１９１１０４８１９０．３で、「データのアップロード方法、システム、装置、電子機器とコンピュータ可読媒体」を発明名称とする中国特許出願の優先権を主張し、同出願の内容の全ては、本出願に引用して取り込まれる。

【0002】

〔技術分野〕
本出願は、ブロックチェーン技術分野に関し、特にデータのアップロード方法、システム、装置、電子機器とコンピュータ可読媒体に関する。

【0003】

〔背景技術〕
ブロックチェーンとは、暗号学技術、ポイントツーポイントネットワーク、コンセンサスメカニズムと時系列で編成されたブロックチェーンデータ構造によって実現される遡及可能、改ざん不可の分散アカウンティングメカニズムである。ブロックチェーンテクノロジーエコシステムにおけるトランザクションは、各移転を各ノードに分散し且つ確認を取得し、トランザクションを完了することには、各関係者の合意に達することが必要だが、それとともに各ノードに完全な元帳も含まれており、ネットワーク全体の観点から見ると、このように磁気ディスク上の比較的に大きい空間を占有し、ネットワークの通常な作動に不利である。磁気ディスクの占有量を減らすために、本発明は、ブロックデータ記憶システムを採用して履歴帳簿を記憶し、ブロックデータ記憶システムは、汎用ハードウェアで実行するのに適される分散型ファイルシステムとして設計され、高スループット量のデータアクセスを提供することができ、大規模なデータセット上の応用に非常に適している。そのため、本発明は、データのアップロード方法、装置、システムとコンピュータ可読媒体を提供した。

【0004】

〔発明の概要〕
〔課題を解決するための手段〕
本出願の実施例の目的は、ブロックチェーンの複数のノードが比較的に大きな磁気ディスク空間を占有するという問題を解決するために、データのアップロード方法、システム、装置、電子機器とコンピュータ可読媒体を提供することである。具体的な技術案は、以下の通りである。

【0005】

第一の側面では、データのアップロード方法を提供した。

【0006】

ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信することと、
前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断することと、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムにアップロードされていない場合、前記ブロックデータを取得し、前記ブロックデータを前記ブロックデータ記憶システムにおける記憶空間にアップロードすることと、
アップロードに成功した場合、前記ターゲットノードにおける軽量ｐｅｅｒに記憶された前記ブロックデータを削除するよう前記スレーブサーバに指示するために、アップロード成功命令を前記スレーブサーバに送信することと、を含むことを特徴とする。

【0007】

選択的には、前記方法は、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムに既にアップロードされた場合、前記スレーブサーバに前記軽量ｐｅｅｒのブロックデータを削除するために、前記スレーブサーバにアップロードされた応答を送信することをさらに含む。

【0008】

選択的には、前述した、前記ブロックデータを取得することは、
前記ブロックデータ記憶システムと同一のローカルエリアネットワークにある全量ｐｅｅｒから前記ブロックデータを取得することを含む。

【0009】

選択的には、前述した、前記ブロックデータを取得することは、
前記スレーブサーバと同一のローカルエリアネットワークにある前記軽量ｐｅｅｒから前記ブロックデータを取得することを含む。

【0010】

選択的には、前記方法は、
前記ブロックアップロード要求から前記ブロックデータの識別子情報を解析することと、
前記識別子情報に基づき、前記ブロックアップロード要求に対応する前記ブロックデータを決定することと、をさらに含む。

【0011】

選択的には、前述した、前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断することは、
履歴ブロックアップロード要求を記録することと、
前記ブロックアップロード要求に含まれる前記識別子情報が前記履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断することと、
一致すると、前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムに既にアップロードされたと判定することと、を含む。

【0012】

選択的には、前記方法は、
前記スレーブサーバにより送信されるデータ照会要求を受信することであって、前記データ照会要求は、前記軽量ｐｅｅｒのブロックデータの照会を要求するために用いられることと、
前記ブロックデータ記憶システムが前記データ照会要求に基づき、前記ブロックデータを含むブロック記憶データを検索するように、前記データ照会要求を前記ブロックデータ記憶システムに送信することと、
前記ブロックデータ記憶システムにより送信される前記ブロック記憶データを受信することと、
前記スレーブサーバが前記ブロック記憶データを前記軽量ｐｅｅｒに送信し、前記軽量ｐｅｅｒを介して前記ブロック記憶データから前記ブロックデータを照会するように、前記ブロック記憶データを前記スレーブサーバに送信することと、をさらに含む。

【0013】

第二の側面では、データアップロードシステムであって、
ブロックデータを記憶するための軽量ｐｅｅｒと、
ブロックアップロード要求を受信し、前記ブロックデータをブロックデータ記憶システムに送信し、及びアップロード終了後にアップロード成功命令をスレーブサーバに送信するためのサーバと、
前記サーバにより送信される前記ブロックデータを受信し、アップロード終了情報を前記サーバに送信するためのブロックデータ記憶システムと、
前記サーバから前記アップロード成功命令を受信し、前記軽量ｐｅｅｒのブロックデータを削除するためのスレーブサーバと、を含むことを特徴とする。

【0014】

第三の側面では、データのアップロード装置であって、
ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信するための受信モジュールと、
前記ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断するための判断モジュールと、
前記ブロックアップロード要求に対応するブロックデータが前記ブロックデータ記憶システムにアップロードされていない場合、前記ブロックデータを取得し、前記ブロックデータを前記ブロックデータ記憶システムにおける記憶空間にアップロードするための取得モジュールと、
アップロードに成功した場合、前記ターゲットノードにおける軽量ｐｅｅｒに記憶された前記ブロックデータを削除するよう前記スレーブサーバに指示するために、アップロード成功命令を前記スレーブサーバに送信するための送信モジュールと、を含むことを特徴とする。

【0015】

第四の側面では、メモリと、プロセッサとを含む電子機器を提供した。前記メモリには、前記プロセッサ上で実行できるコンピュータプログラムが記憶されており、前記プロセッサが前記コンピュータプログラムを実行する時に上記請求項のいずれか１項に記載の方法のステップを実現させる、ことを特徴とする。

【0016】

第五の側面では、プロセッサが実行可能な不揮発性プログラムコードを有するコンピュータ可読媒体を提供した。前記プログラムコードが前記プロセッサにいずれか一つの前記方法を実行させる、ことを特徴とする。

【0017】

本発明の実施例による上記技術案は、従来技術と比べて、以下の利点を有する。本発明は、各ノードの履歴帳簿を集中的に記憶するブロックデータ記憶システムを採用し、各ノードが最新の情報データのみを保存することによって、磁気ディスクの占有量を減らすことができ、磁気ディスクの冗長情報も減らすことができる。無論、本出願を実施するいずれかの製品又は方法は、必ずしも上述した全ての利点を同時に達成する必要がない。

【0018】

〔図面の簡単な説明〕
ここの添付図面は、明細書に組み込まれ且つ本明細書の一部を構成し、本出願に合致する実施例を示しており、明細書とともに本出願の原理を解釈するために用いられる。

【0019】

本出願の実施例又は従来技術における技術案をより明瞭に説明するために、以下は、実施例又は従来技術の記述において使用される必要な添付図面を簡単に紹介する。創意的な工夫をしない前提で、これらの添付図面に基づき、他の添付図面を得られることは、当業者にとって自明なことである。

【0020】

〔図１〕本出願の実施例による全体的なフレームワーク概略図である。

【0021】

〔図２〕本出願の実施例によるデータアップロードの方法フローチャートである。

【0022】

〔図３〕本出願の実施例によるデータアップロードの方法タイミング図である。

【0023】

〔図４〕本出願の実施例によるデータ照会の方法フローチャートである。

【0024】

〔図５〕本出願の実施例によるデータアップロードの装置構造概略図である。

【0025】

〔図６〕本出願の実施例による電子機器の構造概略図である。

【0026】

〔発明を実施するための形態〕
本出願の実施例の目的、技術案と利点をより明瞭にするために、以下は、本出願の実施例における添付図面と合わせて、本出願の実施例における技術案を明瞭且つ完全に記述する。明らかに、記述された実施例は、本出願の一部の実施例であり、全ての実施例ではない。本出願における実施例に基づき、当業者が創意的な工夫をしない前提で得られた全ての他の実施例は、いずれかも本出願の保護範囲に属する。

【0027】

本出願の実施例は、データアップロードシステムにおけるサーバに用いられるデータのアップロード方法を提供した。図１が示されたように、本発明の実施例は、スレーブサーバと、サーバと、軽量ｐｅｅｒと、全量ｐｅｅｒとブロックデータ記憶システムと、を含むデータアップロードフレームワーク概略図を提供した。そのうち、軽量ｐｅｅｒは、ブロックチェーンにおいて最新のブロックデータを記憶するノードであり、全量ｐｅｅｒは、ブロックチェーンにおいて全てのブロックデータを記憶するノードであり、ブロックチェーン内のノード数が比較的に多い場合、磁気ディスクの大量の空間を占有する。スレーブサーバは、軽量ｐｅｅｒと同一のローカルエリアネットワークに位置しており、軽量ｐｅｅｒのブロックデータ記憶量に基づいてブロックデータをサーバにアップロードすることができ、且つ軽量ｐｅｅｒにおけるブロックデータを削除することができる。サーバは、ブロックデータ記憶システムと同一のローカルエリアネットワークに存在しており、サーバとスレーブサーバとの間に通信情報を互いに伝送し、サーバは、スレーブサーバにより送信されるブロックアップロード要求を受信し、且つ該要求をブロックデータ記憶システムにアップロードするか否かを判断し、サーバが該要求をブロックデータ記憶システムにアップロードする場合、ブロックデータ記憶システムから返されたアップロード成功命令をスレーブサーバに送信して、スレーブサーバに軽量ｐｅｅｒにおけるブロックデータを削除させる。サーバが該要求をブロックデータ記憶システムにアップロードする必要がないと判断する場合、アップロードされた命令をスレーブサーバに送信して、スレーブサーバに軽量ｐｅｅｒにおけるブロックデータを削除させる。

【0028】

以下は、具体的な実施の形態と合わせて、本出願の実施例によるデータのアップロード方法について詳細に説明する。図２が示されたように、具体的なステップは、以下の通りである。

【0029】

ステップ２０１、ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信する。

【0030】

ブロックチェーンは、分散型データ記憶、ポイントツーポイント伝送、コンセンサスメカニズム、暗号化アルゴリズムなどのコンピュータ技術の新型アプリケーションモードであり、ブロックチェーン技術生態におけるトランザクションは、各移転を各ターゲットノードに分散し且つ確認を取得してこのトランザクションが完了できる。ブロックチェーンにおける各ターゲットノードがいずれかも同じブロックデータを保存したため、磁気ディスクの比較的に大きな空間を占めており、システムの長期的な安定運行に不利であるため、ターゲットノードにおける同じブロックデータをアップロードする必要がある。

【0031】

ターゲットノードは、軽量ｐｅｅｒとスレーブサーバとが含まれ、ターゲットノードが軽量ｐｅｅｒのブロックデータをアップロードする前に、スレーブサーバは、ブロックデータに対応するブロックアップロード要求を生成し且つサーバに送信し、サーバは、該ブロックアップロード要求を受信する。

【0032】

ステップ２０２：ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断する。

【0033】

ブロックチェーンには同じブロックデータを含む複数の軽量ｐｅｅｒが存在しており、複数のブロックデータがブロックデータ記憶システムに重複してアップロードされることを防止するために、サーバは、受信したブロックアップロード要求を分析し、ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断する。具体的には、サーバは、ブロックアップロード要求に対応する識別子情報を判断することによって、該ブロックアップロード要求に対応する識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断し、これによってブロックアップロード要求に対応するブロックデータはブロックデータ記憶システムに既にアップロードされたか否かを判定する。そのうち、識別子情報とは、ブロックアップロード要求に対応するブロックデータの特徴、例えば、英語又はデジタルコード、記号、パターンなどであって本発明の実施例では具体的に制限しない。

【0034】

そのうち、ブロックデータ記憶システムは、高スループット量のデータアクセスを提供できる一つの高度なフォールトトレランスのシステムであり、大規模なデータセットの応用に非常に適している。本発明の実施例は、ブロックデータ記憶システムがＨＤＦＳ（Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ、Ｈａｄｏｏｐ分散型ファイルシステム）であることを例にして記述し、ＨＤＦＳファイルサイズがＧＢからＴＢのレベルであるため、ＨＤＦＳは、大きなファイルをサポートするように調整され、それは、とても高いアグリゲーションデータ帯域幅を提供すべきであり、一つのクラスタには、数百個のノードをサポートし、一つのクラスタには、千万レベルのファイルをさらにサポートすべきであり、ＨＤＦＳは、外部にファイル命名空間を開放し、ユーザデータをファイル形式で記憶することを許可する。

【0035】

ステップ２０３：ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムにアップロードされていない場合、ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにおける記憶空間にアップロードする。

【0036】

サーバが、ブロックアップロード要求に含まれる識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致しないと判定した場合、該識別子情報に対応するブロックデータがブロックデータ記憶システムにアップロードされていないことを示し、よって、サーバ、該ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにアップロードする。

【0037】

ステップ２０４：アップロードに成功した場合、ターゲットノードにおける軽量ｐｅｅｒに記憶されたブロックデータを削除することをスレーブサーバに指示するために、アップロード成功命令をスレーブサーバに送信する。

【0038】

サーバがブロックデータをブロックデータ記憶システムにアップロードすることに成功した場合、ブロックチェーン内の軽量ｐｅｅｒとブロックデータ記憶システムには、同じブロックデータが含まれる。磁気ディスクの占有量を減らすために、サーバは、アップロードに成功した後、アップロード成功命令をスレーブサーバへ送り返し、新しいブロックアップロード要求と比較するたに、今回のアップロード成功命令に対応するブロックアップロード要求を履歴ブロックアップロード要求として記録する。スレーブサーバは、アップロード成功命令を受信した後、該軽量ｐｅｅｒに記憶されたブロックデータを削除する。

【0039】

各軽量ｐｅｅｒに記憶されたブロックデータが同じであるため、そのうちの一つの軽量ｐｅｅｒがブロックデータをブロックデータ記憶システムにアップロードした後、該アップロードされたブロックデータの軽量ｐｅｅｒのブロックアップロード要求は、履歴ブロックアップロード要求となる。この状況において、サーバが他の軽量ｐｅｅｒブロックアップロード要求を受信すれば、他の軽量ｐｅｅｒのブロックアップロード要求に含まれるブロックデータの識別子情報が履歴ブロックアップロード要求に含まれるブロックデータの識別子情報と一致するため、サーバが他の軽量ｐｅｅｒのブロックデータがブロックデータ記憶システムに既にアップロードされたと判定し、サーバは、スレーブサーバにアップロードされた応答を送信し、該ブロックデータを再びアップロードする必要がないことを示し、且つブロックアップロード要求を送信した軽量ｐｅｅｒのブロックデータを削除するようにスレーブサーバに指示する。

【0040】

選択的には、本発明の実施例は下記であってもよい。サーバが一つの軽量ｐｅｅｒのブロックデータをブロックデータ記憶システムにアップロードすることに成功した後、該軽量ｐｅｅｒが他のターゲットノード内の軽量ｐｅｅｒに含まれるブロックデータと同じであるため、サーバは、各スレーブサーバに削除命令を自動的に送信して、各スレーブサーバにそれぞれのターゲットノード内の軽量ｐｅｅｒのブロックデータを速やかに削除するようにして、サーバが他のターゲットノードの軽量ｐｅｅｒのブロックアップロード要求を繰り返して受信することを回避し、サーバのデータ計算量を減らし、他のターゲットノードの軽量ｐｅｅｒにそれぞれに対応するブロックアップロード要求の占有するデータ通信量を減らす。

【0041】

本発明の実施例では、ブロックチェーンにはスレーブサーバが存在しており、該スレーブサーバは、軽量ｐｅｅｒと同じローカルエリアネットワークにおり、スレーブサーバは、軽量ｐｅｅｒの領域データ記憶量を監視し、軽量ｐｅｅｒの領域データ記憶量が設定された閾値を超えた場合、スレーブサーバは、ブロックアップロード要求をサーバに送信し、そのうち、ブロックアップロード要求は、ブロックデータをブロックデータ記憶システムへのアップロードを要求するために用いられる。

【0042】

スレーブサーバは、軽量ｐｅｅｒの領域データ記憶量が設定された閾値を超えた場合、ブロックアップロード要求をサーバに送信し、ブロックデータをサーバによってブロックデータ記憶システムにアップロードするようにし、且つ軽量ｐｅｅｒにおけるブロックデータを削除し、磁気ディスク空間占有量を減らす。

【0043】

選択的には、スレーブサーバは、定期的にブロックアップロード要求をサーバに送信し、軽量ｐｅｅｒに記憶された過剰なブロックデータと磁気ディスク空間占有量の浪費を回避することもできる。

【0044】

本発明の実施例では、サーバが該ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにアップロードすることは、二種類の取得方式を含む。

【0045】

取得方式一：サーバは、スレーブサーバと同一のローカルエリアネットワークにある軽量ｐｅｅｒから該ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにアップロードする。

【0046】

取得方式二：サーバは、全量ｐｅｅｒから該ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにアップロードする。全量ｐｅｅｒ、サーバとブロックデータ記憶システムは、同一のローカルエリアネットワークにあり、分量ｐｅｅｒは、スレーブサーバと別のローカルエリアネットワークにあり、そのため、サーバは、同一のローカルエリアネットワークにある全量ｐｅｅｒからブロックデータを取得し、ブロックデータ取得速度を速めることができる。

【0047】

本発明の実施例では、ブロックデータを取得する具体的な方式は、サーバは、スレーブサーバから受信したブロックアップロード要求に従い、該ブロックアップロード要求からブロックデータの識別子情報を解析し、識別子情報に基づき、ブロックチェーンの軽量ｐｅｅｒから識別子情報に対応するブロックデータを取得することである。

【0048】

選択的には、ブロックアップロード要求からブロックデータの識別子情報を解析し、識別子情報に基づき、ブロックアップロード要求に対応するブロックデータを決定する。

【0049】

本発明の実施例では、アップロードする予定の各ブロックデータは、一つのブロックアップロード要求に対応しており、サーバは、ブロックアップロード要求から対応するブロックデータの識別子情報を解析することができ、そのうち、該識別子情報とは、ブロックアップロード要求に対応するブロックデータの特徴、例えば、英語又はデジタルコード、記号、パターンなどであり、本発明の実施例は具体的に制限しない。該識別子情報に基づき、サーバは、ブロックアップロード要求に対応するブロックデータを決定する。

【0050】

選択的には、履歴ブロックアップロード要求を記録し、ブロックアップロード要求に含まれる識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断し、一致すると、ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたと判定する。

【0051】

軽量ｐｅｅｒのブロックデータに対し、各ブロックアップロード要求には該ブロックデータに対応する識別子情報が含まれており、サーバは、ブロックデータをブロックデータ記憶システムにアップロードしたたびに、アップロードしたブロックデータの識別子情報に対応する履歴ブロックアップロード要求を記録する。サーバが新しいブロックアップロード要求を受信すると、該新しいブロックアップロード要求に含まれる識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断し、それによって該識別子情報に対応するブロックデータがブロックデータ記憶システムに曾てアップロードされたか否かを判定し、一致すると判断すれば、ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたと判定する。

【0052】

磁気ディスク空間占有量を減らす目的を達成するために、本発明の実施例に対し、ブロックデータ記憶システムの数は、磁気ディスク内の各軽量ｐｅｅｒの合計数よりも少なくなければならない。この場合、各軽量ｐｅｅｒのブロックデータをブロックデータ記憶システムにアップロードしてこそ、重複するブロックデータが減らされ、磁気ディスクの占有空間を減らすことができる。例をあげると、磁気ディスク内に同じブロックデータを含む１０個の軽量ｐｅｅｒが含まれ、ブロックデータ記憶システムの数が３つである場合、全ての軽量ｐｅｅｒはブロックデータを３つのブロックデータ記憶システムにそれぞれアップロードした後、１０個の軽量ｐｅｅｒにおけるブロックデータが全て削除されると、磁気ディスクには３つの同じブロックデータのみが含まれ、それぞれ３つのブロックデータ記憶システムに存在しており、磁気ディスク空間占有量を減らし、コストを節約することもでき、バックアップの目的を達成し、ブロックデータ紛失を防止することもできる。

【0053】

本発明の実施例は、データ照会方法をさらに提供した。図４が示されたように、以下のステップを含む。

【0054】

ステップ４０１：スレーブサーバにより送信されるデータ照会要求を受信し、そのうち、データ照会要求は、軽量ｐｅｅｒのブロックデータの照会を要求するために用いられる。

【0055】

各軽量ｐｅｅｒがブロックデータをブロックデータ記憶システムに既にアップロードしたため、各軽量ｐｅｅｒは、最新のブロックデータのみを含んでおり、ユーザがブロックデータ記憶システムに既にアップロードされたターゲットブロックデータを照会しようとする場合、スレーブサーバは、ターゲットブロックデータに対応するデータ照会要求をサーバに送信し、そのうち、データ照会要求は、軽量ｐｅｅｒのブロックデータの照会を要求するために用いられる。

【0056】

ステップ４０２：ブロックデータ記憶システムがデータ照会要求に従い、ブロックデータが含まれるブロック記憶データを検索するために、データ照会要求をブロックデータ記憶システムに送信する。

【0057】

サーバは、スレーブサーバにより送信されるデータ照会要求を受信した後、該データ照会要求をブロックデータ記憶システムに送信し、ブロックデータ記憶システムは、該データ照会要求に対応するブロックデータに基づき、ブロックデータが含まれるブロック記憶データを検索し、且つ該ブロック記憶データをサーバに送信する。

【0058】

本発明の実施例は、ＨＤＦＳを例にして、ＨＤＦＳ内部メカニズムは、以下の通りであり、一つのファイルを一つ又は複数のブロックに分割し、これらのブロックは、一組のデータノードに記憶され、名前ノードは、ファイル命名空間のファイルの操作又はディレクトリ操作、例えば、開くこと、閉じること、名前を変更することなどに用いられる。それは、ブロックとデータノードのマッピングを同時に決定し、データノードは、ファイルシステム顧客からの読み書き要求を担当する。ＨＤＦＳは事前に、複数のサーバによりアップロードされたブロックデータを同一の組のデータノードに記憶し、サーバは、スレーブサーバにより送信されるデータ照会要求を受信した後、該データ照会要求をＨＤＦＳに送信し、ＨＤＦＳは、該データ照会要求に対応するブロックデータに基づき、ブロックデータが含まれるブロック記憶データを照会し、且つブロック記憶データをサーバに送信する。

【0059】

ステップ４０３：ブロックデータ記憶システムにより送信されたブロック記憶データを受信する。

【0060】

ブロックデータ記憶システムは、該ブロック記憶データをサーバに送信し、サーバは、ブロックデータ記憶システムにより送信されるブロック記憶データを受信する。

【0061】

ステップ４０４：スレーブサーバがブロック記憶データを軽量ｐｅｅｒに送信し、軽量ｐｅｅｒを介してブロック記憶データからブロックデータを照会するように、ブロック記憶データをスレーブサーバに送信する。

【0062】

スレーブサーバにブロック記憶データを軽量ｐｅｅｒに送信するように、サーバは、ブロック記憶データをスレーブサーバに送信し、ブロック記憶データには複数のブロックデータが含まれるため、軽量ｐｅｅｒは、複数のブロックデータからデータ照会要求に対応するブロックデータを照会し、ブロックデータに対する照会を完了することができる。

【0063】

同じ技術構想に基づき、本出願の実施例は、データアップロードのタイミング図をさらに提供した。図３が示されたように、
ステップＳ３０１：ブロックデータ要求をアップロードする。

【0064】

分量ｐｅｅｒのブロックデータ記憶量が予め設定された記憶量を超えた場合、スレーブサーバは、ブロックアップロード要求をサーバに送信する。

【0065】

ステップＳ３０２：対応するブロックデータを取得する。

【0066】

サーバは、ブロックアップロード要求を受信した後、ブロックアップロード要求に含まれるブロックデータの識別子情報を解析し、サーバが、ブロックアップロード要求に含まれる識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致しないと判定すると、サーバは、全量ｐｅｅｒからブロックアップロード要求に対応するブロックデータを取得する。

【0067】

ステップＳ３０３：ブロックデータをアップロードする。

【0068】

サーバは、該ブロックデータをブロックデータ記憶システムにアップロードし、ブロックデータ記憶システムは、該ブロックデータを受信した後、アップロード成功命令をサーバに送信する。

【0069】

ステップＳ３０４：ブロックアップロード要求を記録する。

【0070】

サーバは、アップロード成功命令を受信すると、該アップロード成功命令に対応するブロックアップロード要求を記録する。

【0071】

ステップＳ３０５：アップロード成功命令を送信する。

【0072】

サーバは、該アップロード成功命令をスレーブサーバに送り返す。

【0073】

ステップＳ３０６：分量ノードブロックデータを削除する。

【0074】

スレーブサーバは、アップロード成功命令を受信した後、軽量ｐｅｅｒのブロックデータを削除する。

【0075】

同じ技術構想に基づき、本出願の実施例は、データアップロードの装置をさらに提供した。図５が示されたように、該装置は、
ターゲットノードのスレーブサーバにより送信されるブロックアップロード要求を受信するための第一の受信モジュール５０１と、
ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたか否かを判断するための判断モジュール５０２と、
ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムにアップロードされていない場合、ブロックデータを取得し、ブロックデータをブロックデータ記憶システムにおける記憶空間にアップロードするための取得モジュール５０３と、
アップロードに成功すれば、ターゲットノードにおける軽量ｐｅｅｒに記憶されたブロックデータを削除するようにスレーブサーバに指示するために、アップロード成功命令をスレーブサーバに送信するための第一の送信モジュール５０４と、を含む。

【0076】

選択的には、第一の送信モジュール５０４はさらに、
ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされた場合、スレーブサーバが軽量ｐｅｅｒのブロックデータを削除するように、スレーブサーバにアップロードされた応答を送信するために用いられてもよい。

【0077】

選択的には、取得モジュール５０３はさらに、
ブロックデータ記憶システムと同一のローカルエリアネットワークにある全量ｐｅｅｒからブロックデータを取得するために用いられてもよい。

【0078】

選択的には、取得モジュール５０３はさらに、
スレーブサーバと同一のローカルエリアネットワークにある軽量ｐｅｅｒからブロックデータを取得するために用いられてもよい。

【0079】

選択的には、取得モジュール５０３は、
ブロックアップロード要求からブロックデータの識別子情報を解析するための解析ユニットと、
識別子情報に基づき、ブロックアップロード要求に対応するブロックデータを決定するための取得ユニットと、を含む。

【0080】

選択的には、判断モジュール５０２は、
履歴ブロックアップロード要求を記録するための記録ユニットと、
ブロックアップロード要求に含まれる識別子情報が履歴ブロックアップロード要求に含まれる履歴識別子情報と一致するか否かを判断するための判断ユニットと、
一致すると判断すれば、ブロックアップロード要求に対応するブロックデータがブロックデータ記憶システムに既にアップロードされたと判定するための判定ユニットと、を含む。

【0081】

選択的には、装置は、
スレーブサーバにより送信されるデータ照会要求を受信するための第二の受信モジュールであって、データ照会要求は、軽量ｐｅｅｒのブロックデータの照会を要求するために用いられる第二の受信モジュールと、
ブロックデータ記憶システムがデータ照会要求に従い、ブロックデータが含まれるブロック記憶データを検索するために、データ照会要求をブロックデータ記憶システムに送信するための第二の送信モジュールと、
ブロックデータ記憶システムにより送信されるブロック記憶データを受信するための第三の受信モジュールと、
スレーブサーバがブロック記憶データを軽量ｐｅｅｒに送信し、軽量ｐｅｅｒによってブロック記憶データからブロックデータを照会するために、ブロック記憶データをスレーブサーバに送信するための第三の送信モジュールと、をさらに含む。

【0082】

本発明の実施例による上記技術案は、従来技術と比べて、以下の利点を有する。本発明は、各ノードの履歴帳簿を集中的に記憶するブロックデータ記憶システムを採用し、各ノードが最新の情報データのみを保存することによって、磁気ディスクの占有量を減らすことができ、磁気ディスクの冗長情報も減らすことができる。

【0083】

同じ技術構想に基づき、本出願の実施例は、軽量ｐｅｅｒと、スレーブサーバと、サーバとブロックデータ記憶システムとを含むデータアップロードシステムをさらに提供した。そのうち、
軽量ｐｅｅｒは、ブロックデータを記憶するために用いられ、
サーバは、ブロックアップロード要求を受信し、ブロックデータをブロックデータ記憶システムに送信し、及びアップロード終了後にアップロード成功命令をスレーブサーバに送信するために用いられ、
ブロックデータ記憶システムは、サーバにより送信されるブロックデータを受信し、アップロード終了情報をサーバに送信するために用いられ、
スレーブサーバは、サーバからアップロード成功命令を受信し、軽量ｐｅｅｒのブロックデータを削除するために用いられる。

【0084】

同じ技術構想に基づき、本発明の実施例は、電子機器をさらに提供した。図６が示されたように、プロセッサ６０１と、通信インタフェース６０２と、メモリ６０３と通信バス６０４とを含み、そのうち、プロセッサ６０１、通信インタフェース６０２、メモリ６０３は、通信バス６０４を介して互いに通信し、
メモリ６０３は、コンピュータプログラムを格納するために用いられ、
プロセッサ６０１は、メモリ６０３に格納されるプログラムを実行する時、データのアップロード方法のステップを実現させるために用いられる。

【0085】

上記電子機器で言及された通信バスは、ペリフェラルコンポーネントインターコネクト基準（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ、ＰＣＩ）バス又は拡張産業標準構造（Ｅｘｔｅｎｄｅｄ Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＥＩＳＡ）バスなどであり得る。該通信バスは、アドレスバス、データバス、制御バスなどに分けらることができる。表示しやすくするために、図には、一本の太い線のみで示されるが、バスが一本又は一種類しかないとの意味ではない。

【0086】

通信インタフェースは、上記電子機器と他の機器との間の通信に用いられる。

【0087】

メモリは、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ）を含んでもよく、不揮発性メモリ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ、ＮＶＭ）、例えば少なくとも一つの磁気ディスクメモリを含んでもよい。選択的には、メモリは、前記プロセッサから離れた少なくとも一つの記憶装置であってもよい。

【0088】

上記のプロセッサは、中央プロセッサ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＣＰＵ）、ネットワークプロセッサ（Ｎｅｔｗｏｒｋ Ｐｒｏｃｅｓｓｏｒ、ＮＰ）などを含む汎用プロセッサであってもよく、デジタルシグナルプロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ、ＤＳＰ）、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、ＦＰＧＡ）又は他のプログラマブルロジックデバイス、ディスクリートゲート又はトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントであってもよい。

【0089】

本発明によるまた別の実施例では、コンピュータ可読記憶媒体をさらに提供した。該コンピュータ可読記憶媒体には、コンピュータプログラムが記憶されており、前記コンピュータプログラムがプロセッサによって実行される時、上記のいずれか一つのデータアップロードの方法のステップを実現させる。

【0090】

本発明によるまた別の実施例では、命令が含まれるコンピュータプログラム製品をさらに提供した。それがコンピュータで実行される時、コンピュータに上記実施例におけるいずれか一つのデータアップロードの方法を実行させる。

【0091】

上記実施例では、ソフトウェア、ハードウェア、ファームウェア又はそれらの任意の組み合わせによって全て又は部分的に実現されてもよい。ソフトウェアを用いて実現する時、コンピュータプログラム製品の形式で全部又は部分的に実現されてもよい。前記コンピュータプログラム製品は、一つ又は複数のコンピュータ命令を含む。コンピュータに前記コンピュータプログラム命令をロード及び実行する時、本発明の実施例に記載のフロー又は機能を全部又は部分的に生成される。前記コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は他のプログラマブル装置であってもよい。前記コンピュータ命令は、コンピュータ可読記憶媒体に記憶され、又は一つのコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよく、例えば、前記コンピュータ命令は、一つのウェブサイト、コンピュータ、サーバ又はデータセンターから有線（例えば、同軸ケーブル、ファイバ、デジタル加入者線（ＤＳＬ））又は無線（例えば赤外、無線、マイクロ波など）方式によって別のウェブサイト、コンピュータ、サーバ又はデータセンターに伝送されてもよい。前記コンピュータ可読記憶媒体は、コンピュータがアクセスできるいずれかの利用可能な媒体、又は一つ又は一つ以上の利用可能な媒体統合を含むサーバ、データセンターなどのデータ記憶機器であってもよい。前記利用可能な媒体は、磁気媒体、（例えば、フレキシブルディスク、ハードディクス、磁気テープ）、光媒体（例えば、ＤＶＤ）、又は半導体媒体（例えば、ソリッドステートハードディクスＳｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ（ＳＳＤ））などであってもよい。

【0092】

なお、説明しておくこととして本明細書では、例えば「第一」と「第二」などのような関係用語は、一つのエンティティ又は操作を別のエンティティ又は操作と区別するためにのみ使用され、これらのエンティティ又は操作の間にいずれかのこのような実際な関係又は順序が存在していることを必ずしも要求又は暗示していない。そして、「含む」、「包含」という用語又はその他の任意の変形は、非排他的な「包含」を意図的にカバーするものであり、それにより、一連の要素を含むプロセス、方法、物品又は機器は、それらの要素を含むだけではなく、明確にリストアップされていない他の要素も含み、又はこのようなプロセス、方法、物品又は機器に固有の要素をさらに含む。それ以上の制限がない場合に、「……を１つ含む」という文章で限定された要素について、前記要素を含むプロセス、方法、物品又は機器には他の同じ要素も存在することを除外しない。

【0093】

上述したのは、本出願の具体的な実施の形態に過ぎず、当業者に本出願を理解又は実現することを可能にする。これらの実施例に対する様々な修正は、当業者にとって自明なことであり、本明細書で定義される一般的な原理は、本出願の精神又は範囲を逸脱しない状況の下で、他の実施例において実現されてもよい。従って、本出願は、本明細書に示されるこれらの実施例に限定されず、本明細書で出願される原理と新規性のある特徴点と一致する最も広い範囲に合致すべきである。

【図面の簡単な説明】

【0094】

ここの添付図面は、明細書に組み込まれ且つ本明細書の一部を構成し、本出願に合致する実施例を示しており、明細書とともに本出願の原理を解釈するために用いられる。

【0095】

本出願の実施例又は従来技術における技術案をより明瞭に説明するために、以下は、実施例又は従来技術の記述において使用される必要な添付図面を簡単に紹介する。創意的な工夫をしない前提で、これらの添付図面に基づき、他の添付図面を得られることは、当業者にとって自明なことである。

【図1】本出願の実施例による全体的なフレームワーク概略図である。

【図2】本出願の実施例によるデータアップロードの方法フローチャートである。

【図3】本出願の実施例によるデータアップロードの方法タイミング図である。

【図4】本出願の実施例によるデータ照会の方法フローチャートである。

【図5】本出願の実施例によるデータアップロードの装置構造概略図である。

【図6】本出願の実施例による電子機器の構造概略図である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】