(57)【特許請求の範囲】
【請求項１】
分散データベースの複数のストレージサーバに関連付けられた、ログに含まれるタブレットデータブロック情報を取得する段階と、
前記ログに含まれる前記タブレットデータブロック情報に基づいて、対応するルートテーブルにおけるタブレットデータブロック情報を照会する段階と、
前記ログに含まれる前記タブレットデータブロック情報が、前記ルートテーブルにおける前記タブレットデータブロック情報と整合しているかどうかを判断する段階と、
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合していないと判断した場合、アラームを送信する段階と
を備える方法。
【請求項２】
前記ログに含まれる前記タブレットデータブロック情報を取得する前記段階は、
前記ログをパースする段階と、
前記ログに対応する前記タブレットデータブロック情報を抽出する段階と
を有する、請求項１に記載の方法。
【請求項３】
前記タブレットデータブロック情報は、タブレットデータブロックに対応するテーブル名、タブレットデータブロックに対応する境界、タブレットデータブロックの位置分散、タブレットデータブロックのデータチェックコード、タブレットデータブロックのインデックス、タブレットデータブロックの作成時間およびタブレットデータブロックのサイズのうちの１または複数を含む、請求項１または２に記載の方法。
【請求項４】
前記ログに含まれる前記タブレットデータブロック情報に基づいて、前記対応するルートテーブルにおけるタブレットデータブロック情報を照会する前記段階は、
前記ログに含まれる前記タブレットデータブロック情報に対応するテーブル名を識別する段階と、
前記テーブル名に対応する前記ルートテーブルにおけるタブレットデータブロック情報を照会する段階と
を有する請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記ログに含まれる前記タブレットデータブロック情報が、前記ルートテーブルにおける前記タブレットデータブロック情報と整合しているかどうかを判断する前記段階は、
前記ルートテーブルにおけるタブレットデータブロックに対応する前記タブレットデータブロック情報が、前記ログに含まれるタブレットデータブロックと整合しているかどうかをチェックする段階であって、前記タブレットデータブロック情報は、テーブル名、境界、位置分散、データチェックコード、インデックス、作成時間およびサイズのうちの１または複数を含む、前記ルートテーブルにおけるタブレットデータブロックに対応するチェックする段階
を有する、請求項１から４のいずれか一項に記載の方法。
【請求項６】
複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに保存する段階をさらに備える、請求項１から５のいずれか一項に記載の方法。
【請求項７】
ストレージサーバにより１または複数のログをポーリングする段階と、
前記ストレージサーバにより、新たなデータが前記１または複数のログに現れたと判断する段階と、
前記ストレージサーバにより、前記新たなデータがタブレットデータブロック情報であるかどうかを識別する段階と
をさらに備える、請求項１から６のいずれか一項に記載の方法。
【請求項８】
前記ストレージサーバにより前記１または複数のログをポーリングする前記段階は、
タブレットデータブロックの分割または併合が前記ストレージサーバで発生した場合、前記ストレージサーバの１または複数のローカルログファイルに１個のログデータを生成する段階と、
前記ストレージサーバにより前記１または複数のローカルログファイルを継続的にポーリングして、新たなデータが前記１または複数のローカルログファイルに現れたかどうかをさらに判断する段階と
を有する、請求項７に記載の方法。
【請求項９】
前記ログは、タブレットの複製オペレーション、負荷平均化オペレーション、タブレット分割オペレーションまたはタブレット併合オペレーションに応答して生成される、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記ログに含まれる前記タブレットデータブロック情報に基づいて、前記対応するルートテーブルにおける前記タブレットデータブロック情報を照会する前記段階は、ＳＱＬステートメントを実行して、前記ルートテーブルにおける前記タブレットデータブロック情報を取得する段階を有する、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
プロセッサと、
コンピュータ実行可能命令を格納した非一時的メモリと
を備えるデバイスであって、
前記コンピュータ実行可能命令は、前記プロセッサにより実行された場合、前記デバイスに、
分散データベースの複数のストレージサーバに関連付けられた、ログに含まれるタブレットデータブロック情報を取得するオペレーションと、
前記ログに含まれる前記タブレットデータブロック情報に基づいて、対応するルートテーブルにおけるタブレットデータブロック情報を照会するオペレーションと、
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合しているかどうかを判断するオペレーションと、
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合していないと判断した場合、アラームを送信するオペレーションと
を実行させる、デバイス。
【請求項１２】
前記ログに含まれる前記タブレットデータブロック情報を取得する前記オペレーションは、
前記ログをパースする段階と、
前記ログに対応する前記タブレットデータブロック情報を抽出する段階と
を有する、請求項１１に記載のデバイス。
【請求項１３】
前記タブレットデータブロック情報は、タブレットデータブロックに対応するテーブル名、タブレットデータブロックに対応する境界、タブレットデータブロックの位置分散、タブレットデータブロックのデータチェックコード、タブレットデータブロックのインデックス、タブレットデータブロックの作成時間およびタブレットデータブロックのサイズのうちの１または複数を含む、請求項１１または１２に記載のデバイス。
【請求項１４】
前記ログに含まれる前記タブレットデータブロック情報に基づいて、前記対応するルートテーブルにおける前記タブレットデータブロック情報を照会する前記オペレーションは、
前記ログに含まれる前記タブレットデータブロック情報に対応するテーブル名を識別する段階と、
前記テーブル名に対応する前記ルートテーブルにおけるタブレットデータブロック情報を照会する段階と
を有する、請求項１１から１３のいずれか一項に記載のデバイス。
【請求項１５】
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合しているかどうかを判断する前記オペレーションは、
前記ルートテーブルにおけるタブレットデータブロックに対応する前記タブレットデータブロック情報が、前記ログに含まれるタブレットデータブロックと整合しているかどうかをチェックする段階であって、前記タブレットデータブロック情報は、テーブル名、境界、位置分散、データチェックコード、インデックス、作成時間およびサイズのうちの１または複数を含む、前記ルートテーブルにおけるタブレットデータブロックに対応するチェックする段階
を有する、請求項１１から１４のいずれか一項に記載のデバイス。
【請求項１６】
前記オペレーションは、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存する段階をさらに含む、請求項１１から１５のいずれか一項に記載のデバイス。
【請求項１７】
前記ログは、タブレットの複製オペレーション、負荷平均化オペレーション、タブレット分割オペレーションまたはタブレット併合オペレーションに応答して生成される、請求項１１から１６のいずれか一項に記載のデバイス。
【請求項１８】
前記ログに含まれる前記タブレットデータブロック情報に基づいて、前記対応するルートテーブルにおける前記タブレットデータブロック情報を照会する前記オペレーションは、ＳＱＬステートメントを実行して、前記ルートテーブルにおける前記タブレットデータブロック情報を取得する段階を有する、請求項１１から１７のいずれか一項に記載のデバイス。
【請求項１９】
マージサーバと、
１または複数のログを取得し、
新たなデータが前記１または複数のログに現れたと判断し、
前記新たなデータがタブレットデータブロック情報であるかどうかを識別し、かつ
論理データブロック用のタブレットデータブロック情報を含むログを送信するよう各々が構成される複数の、ストレージサーバと、
複数の前記ストレージサーバに関連付けられた、前記ログに含まれる前記タブレットデータブロック情報を取得し、
前記ログに含まれる前記タブレットデータブロック情報に基づいて、対応するルートテーブルにおけるタブレットデータブロック情報を前記マージサーバに照会し、
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合しているかどうかを判断し、かつ
前記ログに含まれる前記タブレットデータブロック情報が前記ルートテーブルにおける前記タブレットデータブロック情報と整合していないと判断した場合、アラームを送信するよう構成される制御サーバと
を備える分散データベースシステム。
【請求項２０】
前記１または複数のログの前記取得は、タブレットデータブロックの分割または併合が前記ストレージサーバ上で発生した場合、前記ストレージサーバの１または複数のローカルログファイルに１個のログデータを生成する段階と、前記ストレージサーバにより前記１または複数のローカルログファイルを継続的にポーリングして、新たなデータが前記１または複数のローカルログファイルに現れたかどうかをさらに判断する段階とを有する、請求項１９に記載の分散データベースシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願の相互参照  本願は、２０１５年２月２７日に出願された、「Ｍｅｔｈｏｄ  ａｎｄ  Ｅｑｕｉｐｍｅｎｔ  ｆｏｒ  Ｐｒｏｃｅｓｓｉｎｇ  Ｄａｔａ  Ｂｌｏｃｋｓ」という発明の名称の中国特許出願公開第ＣＮ２０１５１００９０１３９．４号明細書、および２０１６年２月４日に出願された、「Ｍｅｔｈｏｄ  ａｎｄ  Ｅｑｕｉｐｍｅｎｔ  ｆｏｒ  Ｐｒｏｃｅｓｓｉｎｇ  Ｄａｔａ  Ｂｌｏｃｋｓ」という発明の名称の国際公開第ＣＮ２０１６／０７３５９４号の優先権の利益を主張する。それらの各々の開示は、ここに、参照によりその全体が組み込まれる。
【技術分野】
【０００２】
開示される実施形態は、通信技術分野に関し、特に、分散データベースにおけるデータブロックを処理する方法、および分散データベースにおけるデータブロックを処理するデバイスに関する。
【０００３】
クラウドコンピューティングが進歩するにつれ、従来のデータベースは、クラウドコンピューティングに関連するビッグデータのサポートにおいて、より一層の困難に直面している。これらの困難に起因して、分散データベースは、急速に発展している。分散データベース技術は、クラウドコンピューティングシステムの重要な要素として成熟しており、また、将来的には様々な産業で広く用いられ、コストが低く、拡張が容易で、可用性が高いデータストレージソリューションをビジネスに提供するであろう。
【０００４】
１つの分散データベースであるＯｃｅａｎＢａｓｅは、ＯｃｅａｎＢａｓｅストレージエンジンを実装することで何万もの汎用ＰＣサーバのためのディスクの管理もするという点で、他の分散データベースと同様に、現在主流の分散データベースである。ＯｃｅａｎＢａｓｅの各ＰＣサーバにおけるディスクは、ストレージエンジンにより、データを格納する複数のストレージブロック（例えば、論理データブロック、タブレットデータブロック、およびそれらと同様のもの）に分割される。あるＯｃｅａｎＢａｓｅデータベースにおいて、１つのタブレットデータブロックは、当該ＯｃｅａｎＢａｓｅデータベースの１つのテーブルのみに属し得、当該データベースにおける１つのテーブルは、当該テーブルに格納されるデータの容量に応じて、複数のタブレットデータブロックを有し得る。つまり、ＯｃｅａｎＢａｓｅデータベースにおけるタブレットデータブロックとテーブルとの間には多対一の関係が存在する。分散データベースのストレージエンジンの基礎的記憶単位であるタブレットデータブロックは、ＰＣサーバ上に多数存在する。分散データベースの高可用性を保証すべく、１つのタブレットデータブロックは、多くのコピーを有し得る。換言すれば、同じデータが多くのタブレットデータブロックに存在し得る。その上、継時的なデータの挿入、削除および更新（ならびに分散データベースシステムの負荷平均化のニーズ）では、タブレットデータブロックは、分割、移行および併合などの複雑なオペレーションにかけられる。これらのオペレーションの失敗は、コピーの消失またはコピーのデータ間の不整合につながる。大規模分散データベースシステムにおける複雑性が高いことに起因して、データの整合性、システムの高可用性、パーティションの耐故障性等に関連する困難な問題が対処されなければならない。したがって、タブレットデータブロックの合理的かつ正確な分散を管理するのは困難である。
【０００５】
結果として、タブレットデータブロックの変化ステータスをリアルタイムでトラッキングすることにより、様々なＰＣサーバのディスク上でのタブレットデータブロックの詳細な分散が正確に取得され得、ＰＣサーバのディスク上でのタブレットデータブロックの分散の合理性を分析するのが容易になる。また、さらなるサービス価値をユーザにもたらすよう、あるＰＣサーバ上またはＰＣサーバの特定のディスク上のタブレットデータブロックの密度に関する早期警告を与えることが可能である。各テーブルにおけるタブレットデータブロックの分散位置も、その有効期間中の各テーブルにおけるタブレットデータブロックの変化ステータスを取得し、かつさらなるサービス価値をユーザに提供するよう、正確に識別されるであろう。さらなるサービス価値をユーザにもたらすよう、分散データベースのデータストレージの全体が包括的に監視され得、データセグメントの記憶位置が正確に見つけられ得る。上記利益に加え、分散データベースにおけるタブレットデータブロックの変化ステータスのリアルタイムトラッキングは、多くの他の利益をもたらし得る。分散データベースにおいてリアルタイムで取得されるタブレットデータブロックについて関連チェックを実行することにより、その後の自動または手動の処理の基礎を提供すべく、タブレットデータブロックに見つかったデータの不整合に基づいてアラームが送信され得、プログラムバグにより引き起こされるタブレットデータブロックの障害または消失が防がれ得る。プログラムバグは、解決のために分散データベースの開発業者にも報告され得、それにより、分散データベースの安定性および高可用性がさらに向上する。
【０００６】
現在、ＯｃｅａｎＢａｓｅデータベースにおけるタブレットデータブロックをトラッキングするための既成の方法は存在しない。トラッキングは通常、タブレットデータブロックの消失またはタブレットデータブロックの不整合が発生した場合、タブレットデータブロックのデータを取得すべくルートテーブルについてＯｃｅａｎＢａｓｅデータベースを手動で探索することにより実行されるか、そうでなければ、手動で検出される。現在のシステムにおいて、様々なテーブルのタブレットデータブロック情報は、タブレットデータブロックの消失またはタブレットデータブロックの不整合が発生したか、そうでなければ、検出された場合、ＯｃｅａｎＢａｓｅルートテーブルシステムテーブルから手動で取得される。ＯｃｅａｎＢａｓｅルートテーブルに格納されるテーブルのタブレットデータブロック情報は、最近のタブレットデータブロック情報にすぎない。換言すれば、既存のシステムは、タブレットデータブロックの現在のステータスデータのみを取得し得るが、タブレットデータブロックの変化ステータスを継時的にトラッキングし得ない。
【０００７】
タブレットデータブロックをチェックする既存の方法は、ＯｃｅａｎＢａｓｅのストレージサーバログを手動でトラバースして、タブレットデータブロックに関連するログを取得する段階と、これらのログの情報を統合し、次に、そのような情報を、ＯｃｅａｎＢａｓｅルートテーブルシステムテーブルにおける対応するテーブルのタブレットデータブロックのデータの関連データと比較する段階とを備える。ＯｃｅａｎＢａｓｅのストレージサーバログの手動トラバースには、極めて非効率的であるという欠点がある。また、ディスクの空き容量の大部分がログファイルにより占められることを防ぐべく、ＯｃｅａｎＢａｓｅは、特定の時点より前に格納されたログファイルを定期的にクリーニングする。ログがクリーニングされる（例えば、削除される）ので、ＯｃｅａｎＢａｓｅのストレージサーバログを手動でトラバースすることにより取得された、タブレットデータブロックのログデータは、不完全になる。これは、チェックの結果が不正確になることにつながり得る。
【０００８】
つまり、現在のシステムは、タブレットデータブロックの変化ステータスを継時的にトラッキングし得ず、現在のシステムにおけるタブレットデータブロックをチェックすることには、極めて非効率で、結果が不正確であるという欠点がある。
【発明の概要】
【０００９】
本開示の複数の実施形態は、タブレットデータブロックの変化ステータスをリアルタイムでトラッキングし得、かつ、タブレットデータブロック情報を効率的かつ正確にチェックし得る、データブロックを処理する方法およびデバイスを提供する。
【００１０】
一実施形態において、ストレージサーバと、制御サーバと、マージサーバとを備えるシステムに適用される、データブロックを処理する方法であって、ストレージサーバにより送信される、タブレットデータブロック情報を含むログを制御サーバが受信した場合、ログに含まれるタブレットデータブロック情報を制御サーバにより取得する段階と、制御サーバにより、ログに含まれるタブレットデータブロック情報に従って、対応するルートテーブルにおけるタブレットデータブロック情報をマージサーバに照会する段階と、制御サーバにより、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合しているかどうかを判断する段階と、制御サーバにより、ログに含まれるタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報を要約および格納する段階と、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないことを判断の結果が示した場合、アラームを送信する段階とを備える方法が提供される。
【００１１】
一実施形態において、制御サーバにより、ログに含まれるタブレットデータブロック情報に従って、対応するルートテーブルにおけるタブレットデータブロック情報をマージサーバに照会する段階は、制御サーバにより、ログに含まれるタブレットデータブロック情報に対応するテーブル名を識別する段階と、制御サーバにより、テーブル名に対応するルートテーブルにおけるタブレットデータブロック情報をマージサーバに照会する段階とを有する。
【００１２】
一実施形態において、制御サーバにより、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合しているかどうかを判断する段階は、制御サーバにより、ルートテーブルにおけるタブレットデータブロックに対応するタブレットデータブロック情報であって、テーブル名、境界、位置分散、データチェックディジット、インデックス、作成時間およびサイズのうちの１または複数を含む、ルートテーブルにおけるタブレットデータブロックに対応するタブレットデータブロック情報が、ログに含まれるタブレットデータブロックと整合しているかどうかをチェックする段階と、ルートテーブルにおけるタブレットデータブロックに対応する情報のいずれかについて何らかの不整合がチェックの結果に見つかった場合、制御サーバにより、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないと判断する段階とを有する。
【００１３】
一実施形態において、制御サーバにより、ログに含まれるタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報を要約および格納する段階は、制御サーバにより、ログに含まれるタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報を要約する段階と、制御サーバにより、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存する段階とを有する。
【００１４】
本開示の一実施形態は、ストレージサーバと、制御サーバと、マージサーバとを備えるシステムに適用される、データブロックを処理する方法であって、以下の段階、つまり、新たなデータが１または複数のログに現れたとストレージサーバが判断した場合、ストレージサーバにより１または複数のログをポーリングする段階と、新たなデータがタブレットデータブロック情報であるかどうかを識別する段階と、異常であった場合、制御サーバが、ログに含まれるタブレットデータブロック情報とマージサーバのルートテーブルにおける（または複数のデバイスに亘って分散した複数のルートテーブルのうちの１つにおける）タブレットデータブロック情報との間の整合性を識別し、当該情報を要約および格納するように、ストレージサーバにより、タブレットデータブロック情報を含むログを制御サーバに送信する段階とを備える方法を提供する。
【００１５】
本開示の一実施形態は、ストレージサーバと、制御サーバと、マージサーバとを備えるシステムに適用される制御サーバであって、ストレージサーバにより送信される、タブレットデータブロック情報を含むログを受信するよう構成される受信モジュールと、ストレージサーバにより送信される、タブレットデータブロック情報を含むログを受信モジュールが受信した場合、ログに含まれるタブレットデータブロック情報を取得するよう構成される取得モジュールと、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報に従って、対応するルートテーブルにおけるタブレットデータブロック情報についてマージサーバに照会するよう構成される照会モジュールと、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報が、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報と整合しているかどうかを判断するよう構成される判断モジュールと、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報と、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報とを要約および格納するよう、かつ、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないことを判断の結果が示した場合、アラームを送信するよう構成される処理モジュールとを備える制御サーバを提供する。
【００１６】
一実施形態において、照会モジュールは、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報に対応するテーブル名を判断するよう、かつ、テーブル名に対応するルートテーブルにおけるタブレットデータブロック情報についてマージサーバに照会するよう特に構成される。
【００１７】
一実施形態において、判断モジュールは、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロックに対応するタブレットデータブロック情報であって、テーブル名、境界、位置分散、データチェックディジット、インデックス、作成時間およびサイズのうちの１または複数を含む、ルートテーブルにおけるタブレットデータブロックに対応するタブレットデータブロック情報が、取得モジュールにより取得された、ログに含まれるタブレットデータブロックと整合しているどうかをチェックするよう、かつ、ルートテーブルにおけるタブレットデータブロックに対応する情報のいずれかについて何らかの不整合がチェックの結果に見つかった場合、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報が、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報と整合していないと判断するようさらに構成される。
【００１８】
一実施形態において、処理モジュールは、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報と、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報とを要約するよう、かつ、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存するようさらに構成される。
【００１９】
本開示の一実施形態は、ストレージサーバと、制御サーバと、マージサーバとを備えるシステムに適用されるストレージサーバであって、ストレージサーバのログをポーリングするよう構成されるポーリングモジュールと、新たなデータがログに現れたとポーリングモジュールが判断した場合、新たなデータがタブレットデータブロック情報であるかどうか識別するよう構成される識別モジュールと、識別モジュールの識別の結果が異常であった場合、制御サーバが、ログに含まれるタブレットデータブロック情報とマージサーバのルートテーブルにおける（または複数のデバイスに亘って分散した複数のルートテーブルのうちの１つにおける）タブレットデータブロック情報との間の整合性を識別し、かつ、情報を要約および格納するように、タブレットデータブロック情報を含むログを制御サーバに送信するよう構成される送信モジュールとを備えるストレージサーバを提供する。
【００２０】
現在のシステムと比較して、開示される実施形態には、少なくとも以下の利点、つまり、様々なテーブルのタブレットデータブロックの継時的な変化ステータスのデータがリアルタイムで取得され得ること、取得されたデータがディスクに永続的に格納されること、および、有効期間中のテーブルのタブレットデータブロックのステータスの変化についてのグラフが、ディスクに永続的に格納されたデータに従って描かれ、それにより、タブレットデータブロックのステータスの変化を追跡するという効果を達成し得ることがある。開示される実施形態において、関連チェックは、タブレットデータブロックに関連する取得された情報に従って、データベースにおける様々なテーブルのタブレットデータブロックについて、リアルタイムで実行され得る。プログラムバグにより引き起こされるタブレットデータブロックの障害および消失についての早期警告は、リアルタイムで効率的かつ正確に送信され得、それにより、現在のシステムに存在する問題、つまり、効率が極めて低く、チェックの結果が不正確であるという欠点を克服し得る。
【図面の簡単な説明】
【００２１】
開示される実施形態における技術的解決法をより明らかに示すべく、実施形態を説明する図面が以下に手短に紹介される。以下に説明される図面は、開示される実施形態のいくつかにすぎない。当業者であれば、創造的な努力をすることなく、叙述される実施形態におけるこれらの図面に従って、他の図面も取得し得る。
【００２２】
【図１】本開示のいくつかの実施形態に従ったデータベースの構造図である。
【００２３】
【図２】本開示のいくつかの実施形態に従った、データブロックを処理する方法のフロー図である。
【００２４】
【図３】本開示のいくつかの実施形態に従った、データブロックを処理する方法のフロー図である。
【００２５】
【図４Ａ】本開示のいくつかの実施形態に従った、ストレージサーバログ用パースデーモンのフロー図である。
【００２６】
【図４Ｂ】本開示のいくつかの実施形態に従った制御サーバの動作を例示するフロー図である。
【００２７】
【図５】本開示のいくつかの実施形態に従った、データベースのデータブロックを処理するデバイスの構造図である。
【００２８】
【図６】本開示のいくつかの実施形態に従った、データベースのデータブロックを処理するデバイスの構造図である。
【発明を実施するための形態】
【００２９】
現在のシステムに存在する問題をより明らかに示すべく、図１は、データベースの構造図を示す。データベースは、例えば、ＯｃｅａｎＢａｓｅデータベースであり得る。図１は、具体的な適用シナリオを示す。適用シナリオにおいて、データベースは、既定の３レベル構造を用いて、各テーブルについてその論理データブロック（すなわち、タブレットデータブロック）の位置情報および他のメタデータをデータベースに格納する。テーブルの３レベルは共に、システムの全ルートテーブルを構成する。いくつかの実施形態において、ルートテーブルは、多数のコンピューティングデバイスまたはサーバに亘って分散され得る。
【００３０】
図１は、ルートテーブルに属さないユーザテーブル（１０２ａ、１０２ｂ）を示す。各ユーザテーブルは、所定のサイズに従って、毎日の併合中に複数のタブレットに分割される。各タブレットは、ユーザテーブルデータのいくつかを格納する。全てのタブレットフラグメントがユーザテーブル全体のデータの全てを構成する。
【００３１】
図１は、ユーザテーブルのメタデータテーブルをさらに示す。当該メタデータテーブルは、ユーザメタテーブル（１０４ａ、１０４ｂ）と称される。各ユーザテーブル（１０２ａ、１０２ｂ）は、１つのユーザメタテーブル（１０４ａ、１０４ｂ）に対応する。ユーザメタテーブルにおける１つのデータ行がユーザテーブルにおける１つのタブレットに対応する。データ行は、ユーザテーブルのタブレットの境界値、位置分散、チェック値およびインデックスなどの情報を格納する。ユーザメタテーブルは、所定のサイズに従って、毎日の併合中に複数のタブレット（１０４ａ、１０４ｂ）に分割され得る。さらに、ユーザメタテーブルにおける各タブレット（１０４ａ、１０４ｂ）は、ユーザメタテーブルデータのいくつかを格納する。
【００３２】
図１は、ユーザメタテーブルのメタデータテーブルをさらに示す。当該メタデータテーブルは、ユーザルートテーブル（１０６ａ、１０６ｂ）と称される。第３レベル（すなわち、ユーザメタテーブル（１０４ａ、１０４ｂ）を含むレベル）の１つのタブレットに対応する各行は、ユーザメタテーブルのタブレットの境界値、位置分散、チェック値およびインデックスなどの情報を格納する。ユーザルートテーブル（１０６ａ、１０６ｂ）は、分割が許可されない１つのタブレットのみを有する。
【００３３】
図１は、全てのユーザルートテーブルへのエントリをさらに示す。エントリは、第１ルートテーブル（１０８）と称される。第２レベルのユーザルートテーブル（１０６ａ、１０６ｂ）に対応する各行は、ユーザルートテーブルに属すタブレットの境界、位置分散、チェック値およびインデックスを含む情報を格納する。第１ルートテーブル（１０８）は、分割が許可されない１つのタブレットのみを有する。
【００３４】
ＯｃｅａｎＢａｓｅデータベースにおいて、タブレットデータブロックは、多くのコピーを有し得る。換言すれば、同じデータが多くのタブレットデータブロックに存在し得る。その上、継時的なデータの挿入、削除および更新（ならびに分散データベースシステムの負荷平均化のニーズ）では、タブレットデータブロックは、分割、移行および併合などの複雑なオペレーションにかけられる。これらのオペレーションの失敗は、コピーの消失またはコピーのデータ間の不整合につながる。したがって、タブレットデータブロックの変化ステータスをリアルタイムでトラッキングすることにより、タブレットデータブロックのステータスを継時的に追跡することが可能である。関連チェックは、タブレットデータブロックに関連する取得された情報に従って、ＯｃｅａｎＢａｓｅデータベース中の様々なテーブルにおけるタブレットデータブロックについて、リアルタイムで実行され得る。プログラムバグにより引き起こされるタブレットデータブロックの障害および消失についての早期警告は、リアルタイムで効率的かつ正確に送信され得る。
【００３５】
とはいうものの、現在のシステムは、タブレットデータブロックの変化ステータスを継時的にトラッキングし得ず、現在のタブレットデータブロックチェック技術は、効率が極めて低く結果が不正確であるという欠点がる。現在のシステムにおけるこの問題を克服すべく、本開示は、本明細書において説明される以下の実施形態を提供する。
【００３６】
現在のシステムがタブレットデータブロックの変化ステータスを継時的に追跡し得えない、またチェック効率が極めて低くチェックの結果が不正確であるという欠点を克服すべく、第１実施形態において、本開示は、データブロックを処理する方法を提供する。
【００３７】
図２は、本開示のいくつかの実施形態に従った、データブロックを処理する方法のフロー図である。図２に示される実施形態は、ストレージサーバと、制御サーバと、マージサーバとを含むシステムに適用され得る。図示される実施形態において、以下の段階は、制御サーバで実行され得る。一実施形態において、ストレージサーバと、制御サーバと、マージサーバとは、プロセッサと、プロセッサにより実行された場合、開示された方法のいくつかまたは全てをデバイスに実行させるコンピュータ実行可能命令を格納した非一時的メモリとを有するデバイスを各々備え得る。
【００３８】
段階Ｓ２０１  ストレージサーバにより送信される、論理データブロック用の、タブレットデータブロック情報を含むログを制御サーバが受信した場合、ログに含まれるタブレットデータブロック情報を制御サーバにより取得する。
【００３９】
一実施形態において、段階Ｓ２０１は、ストレージサーバにより報告される、タブレットデータブロック情報を含むログを制御サーバにより受信する段階と、ログをパースする段階と、ログに対応するタブレットデータブロック情報を抽出する段階とを含む。
【００４０】
タブレットデータブロック情報は、限定されないが、以下の情報、つまり、タブレットデータブロックに対応するテーブル名、タブレットデータブロックに対応する境界、タブレットデータブロックの位置分散、タブレットデータブロックのデータチェックコード、タブレットデータブロックのインデックス、タブレットデータブロックの作成時間およびタブレットデータブロックのサイズのうちの１または複数を含む。
【００４１】
段階Ｓ２０２  ログに含まれるタブレットデータブロック情報に従って、対応するルートテーブルにおけるタブレットデータブロック情報についてマージサーバに照会する。
【００４２】
一実施形態において、段階Ｓ２０２は、ログに含まれるタブレットデータブロック情報に対応するテーブル名を制御サーバにより識別する段階と、制御サーバにより、テーブル名に対応するルートテーブルにおけるタブレットデータブロック情報をマージサーバに照会する段階とを含む。
【００４３】
段階Ｓ２０３  ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合しているかどうかを判断する。
【００４４】
一実施形態において、段階Ｓ２０３は、ルートテーブルにおけるタブレットデータブロックに対応する情報であって、テーブル名、境界、位置分散、データチェックコード、インデックス、作成時間およびサイズのうちの１または複数を含む、ルートテーブルにおけるタブレットデータブロックに対応する情報が、ログに含まれるタブレットデータブロックと整合しているかどうかを制御サーバによりチェックする段階を具体的に含む。
【００４５】
当該情報のいずれかについて何らかの不整合が段階Ｓ２０３のチェックの結果に見つかった場合、方法は、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないと制御サーバにより判断する段階を備え得る。
【００４６】
一方、当該情報のいずれかについて整合性が段階Ｓ２０３のチェックの結果に見つかった場合、方法は、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していると判断する。
【００４７】
一実施形態において、以下の段階Ｓ２０４は、判断の結果が異常であるか正常であるか（例えば、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合しているか整合していないかのそれぞれ）に拘らず、実行される。判断の結果が、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないということであった場合、さらなるステップＳ２０５が実行される必要がある。
【００４８】
段階Ｓ２０４  ログに含まれるタブレットデータブロック情報と、ルートテーブルにおけるタブレットデータブロック情報とを要約および格納する。一実施形態において、段階Ｓ２０４は、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存する段階を含む。
【００４９】
段階Ｓ２０５  アラームを送信する。一実施形態において、アラームは、タブレットデータブロック情報が整合しておらず、即時の処理が必要であり得るとユーザに促すべく送信される。
【００５０】
上記の点を考慮すると、現在のシステムと比較して、タブレットデータブロックのステータスが変化する度に、照会を介して取得されたタブレットデータブロック情報および見つかったタブレットデータブロック情報は、要約され、ディスクに永続的に格納される。したがって、タブレットデータブロックのステータスの変化を追跡することが可能である。開示される実施形態において、取得されたタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報について、多次元チェックがリアルタイムで実行される。早期警告は、取得されたタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報が整合していないとチェックの結果が示す場合、遅れずに送信される。次に、タブレットデータブロックの障害および消失が発生した場合、（自動または手動のいずれかでの）時宜を得た訂正が実行され得、それにより、チェックの効率が高くなると共に、チェックの結果が正確になる。
【００５１】
上記の説明では、制御サーバにより実行される方法の実施形態を説明した。それに応じて、本開示は、ストレージサーバに関連する前述の実施形態の一実装をさらに説明する。
【００５２】
図３は、本開示のいくつかの実施形態に従った、データブロックを処理する方法のフロー図である。図示される方法は、ストレージサーバと、制御サーバと、マージサーバとを含むシステムに適用され得る。方法は、ストレージサーバにより実行される以下の段階を含む。
【００５３】
段階Ｓ３０１  ストレージサーバは、独自のログのうちの１または複数をポーリングする。
【００５４】
一実施形態において、段階Ｓ３０１は、タブレットデータブロックの分割または併合がストレージサーバで発生した場合、ストレージサーバの１または複数のローカルログファイルに１個のログデータを生成する段階と、ストレージサーバにより１または複数のローカルログファイルを継続的にポーリングして、新たなデータが１または複数のローカルログファイルに現れたかどうかをさらに判断する段階とを有する。
【００５５】
段階Ｓ３０２  新たなデータがログに現れたとストレージサーバが判断した場合、新たなデータがタブレットデータブロック情報であるかどうかを識別する。
【００５６】
一実施形態において、段階Ｓ３０２は、新たなデータがストレージサーバのログファイルに生成された場合、新たに生成されたログデータを取得する段階と、新たに生成されたログデータをパースする段階と、新たなデータがタブレットデータブロック情報であるかどうかを識別する段階とを有する。そうである場合、方法は段階Ｓ３０３を実行し得、そうでない場合、方法は段階Ｓ３０１へ戻り得る。
【００５７】
段階Ｓ３０３  ストレージサーバは、タブレットデータブロック情報を含むログを制御サーバに送信する。
【００５８】
段階Ｓ３０３の後、制御サーバは、ログに含まれるタブレットデータブロック情報とマージサーバのルートテーブルにおける（または複数のデバイスに亘って分散した複数のルートテーブルのうちの１つにおける）タブレットデータブロック情報との間の整合性を識別し、当該情報を要約および格納し、それにより、ＯｃｅａｎＢａｓｅデータベースにおけるその有効期間中のあるテーブルのタブレットデータブロックの変化ステータスのその後の閲覧ならびにその後の自動処理または手動処理を容易にする。制御サーバにより実行される処理についての記載は、上記で詳細に説明されており、明確性のために本明細書では反復されない。
【００５９】
一実施形態において、段階Ｓ３０３は、新たに生成されたログデータがタブレットデータブロックログを含む場合、タブレットデータブロックログを制御サーバに報告する段階と、次に、ストレージサーバにより生成されたログデータの読み取りを継続する段階と、新たなログが生成されなかったか、生成されたログがタブレットデータブロックログではなかった場合、ストレージサーバにより生成されたログデータの読み取りを継続する段階とを有する。
【００６０】
一実施形態において、ＯｃｅａｎＢａｓｅのタブレットログは、ＯｃｅａｎＢａｓｅにより定義されるログプロトコルフォーマットに従ってカプセル化される。当該フォーマットに含まれる情報は、タブレットデータブロックログが生成された時刻、タブレットデータブロックに対応するテーブル名、タブレットデータブロックの境界、タブレットデータブロックチェックコードおよびタブレットデータブロックの位置分散などの情報を含む。通常、ＯｃｅａｎＢａｓｅは、ログを用いて、タブレットデータブロックの情報を記録する。なぜなら、ディスクに記録されたログは信頼性が高いからである。これは、ログの信頼性が高いことを理由としてリドゥーログおよびアンドゥ―ログを用いてデータストレージを実装する従来のデータベースに類似している。ＯｃｅａｎＢａｓｅデータベースにおけるタブレットデータブロックの分割動作または併合動作が終了した場合、ＯｃｅａｎＢａｓｅデータベースは、タブレットデータブロックが存在するストレージサーバにタブレットログを生成する。ログは、タブレットの境界、位置分散、チェック値およびインデックスなどの情報を含む、分割中または併合中の対応するタブレットデータブロックの詳細なデータを記録するのに用いられる。タブレットログは、以下の状況において生成される。
【００６１】
タブレットの複製  あるタブレットのコピーの数が閾値未満であった場合、ＯｃｅａｎＢａｓｅデータベースは、テーブルのコピーを含む１つのストレージサーバを移行元として、また、要件を満たす別のストレージサーバを移行先として選択する。テーブルのコピーが移行元から移行先に移行された場合、新しいテーブルのコピーが移行先で生成される。移行先でのストレージサーバログにおける新たに生成されたタブレットの詳細な情報をタブレットログで記録することが必要である。
【００６２】
負荷平均化  あるストレージサーバに含まれるあるテーブルのタブレットの数がある閾値を超えた場合、このストレージサーバは次に移行元として用いられ、要件を満たす別のストレージサーバが移行先として用いられる。移行元におけるテーブルのいくつかのタブレットは、移行先に移行される。新しいテーブルのコピーも移行先で生成される。また、新たに生成されたタブレットの詳細な情報を移行先のストレージサーバログにタブレットログで記録することも必要である。
【００６３】
タブレットの分割  あるテーブルに属すあるタブレットの空き容量が、毎日の併合中、新たに挿入または修正されたデータに対して十分でない場合、そのタブレットは、複数のタブレットに分割される必要があるであろう。複数のタブレットに分割されるタブレットの特定の数は、データ容量に基づいて決定される。古いタブレットが変更処理を受けている間、新しいタブレットは生成されており、タブレットの詳細な情報を移行先のストレージサーバログにタブレットログで記録することが必要である。
【００６４】
タブレットの併合  ディスクの空き容量を最大限効率的に用いるべく、あるテーブルに属すあるタブレットにおけるデータが毎日の併合中に完全に削除された場合、タブレットは、ＯｃｅａｎＢａｓｅシステムによりリクレームされる。タブレットはもはやテーブルに属さず、タブレットの詳細な情報を移行先のストレージサーバログにタブレットログで記録することが必要である。
【００６５】
上記の点を考慮すると、現在のシステムと比較して、タブレットデータブロック情報を含むログは、開示される実施形態において、リアルタイムで取得され得る。次に、制御サーバは、ログに含まれるタブレットデータブロック情報とマージサーバのルートテーブルにおける（または複数のデバイスに亘って分散した複数のルートテーブルのうちの１つにおける）タブレットデータブロック情報との間の整合性を識別すること、ならびに当該情報を要約および格納することが可能になり、それにより、タブレットデータブロックのステータストラッキングのおよび正確なチェックの目標が達成される。
【００６６】
開示される実施形態の技術的解決法をさらに説明すべく、具体的な適用シナリオが以下に提供される。本実施形態は、ストレージサーバと、制御サーバと、マージサーバとを含むシステムに特に適用される。本実施形態において、ストレージサーバ用ログパースデーモンがストレージサーバに導入される。
【００６７】
図４Ａは、本開示のいくつかの実施形態に従ったストレージサーバログ用パースデーモンのフロー図である。ストレージサーバ用のログパースデーモンの手順は以下のとおりである。
【００６８】
段階Ｓ４０１  起動時に、ログパースデーモンは、ストレージサーバにより生成されるログファイルを継続的にポーリングし、ログデータを読み込む。
【００６９】
段階Ｓ４０２  ログパースデーモンは、新しいログデータがストレージサーバのログファイルに生成されたかどうかを判断する。
【００７０】
そうである場合、方法は段階Ｓ４０３を実行し、そうでない場合、方法は段階Ｓ４０１に戻る。
【００７１】
段階Ｓ４０３  ログパースデーモンは、パースを実行して、新しいログデータを取得し、その新しいログデータをパースする。
【００７２】
段階Ｓ４０４  ログパースデーモンは、新しいログデータがタブレットデータブロック情報を含むログを含んでいるかどうかを判断する。
【００７３】
段階Ｓ４０５  ログパースデーモンは、タブレットデータブロック情報を含むログを制御サーバに報告する。報告の終了後、ログパースデーモンは、ストレージサーバにより生成されるログデータの読み取りを継続する。
【００７４】
さらに、タブレットデータブロック情報を含むログをログパースデーモンが制御サーバに報告した後、制御サーバはログを処理する。図４Ｂに示されるように、制御サーバの処理手順は以下のとおりである。
【００７５】
段階Ｓ４０６  制御サーバは、ストレージサーバから報告されるタブレットデータブロック情報を含むログを継続的に監視する。タブレットデータブロック情報は、限定されないが、以下の情報、つまり、タブレットデータブロックに対応するテーブル名、タブレットデータブロックに対応する境界、タブレットデータブロックの位置分散、タブレットデータブロックのデータチェックコード、タブレットデータブロックのインデックス、タブレットデータブロックの作成時間、タブレットデータブロックのサイズのうちの１または複数を含む。
【００７６】
段階Ｓ４０７  制御サーバは、ストレージサーバにより報告されるタブレットデータブロック情報を含むログが現れたかどうかを判断する。
【００７７】
そうである場合、方法は、段階Ｓ４０８を実行し、そうでない場合、方法は段階Ｓ４０６に戻る。
【００７８】
段階Ｓ４０８  制御サーバは、ストレージサーバにより報告されるタブレットデータブロック情報を含むログを受信およびパースし、ログに対応するタブレットデータブロック情報を抽出する。タブレットデータブロック情報は、限定されないが、以下の情報、つまり、タブレットデータブロックに対応するテーブル名、タブレットデータブロックに対応する境界、タブレットデータブロックの位置分散、タブレットデータブロックのデータチェックコード、タブレットデータブロックのインデックス、タブレットデータブロックの作成時間およびタブレットデータブロックのサイズのうちの１または複数を含む。
【００７９】
段階Ｓ４０９  制御サーバは、タブレットデータブロックに対応するテーブル名に従って、マージサーバからのルートテーブルにおけるタブレットデータブロック情報を識別する。ログが受信される度に、ルートテーブルにおけるタブレットデータブロック情報は、照会される。マージサーバを通じてタブレットデータブロック情報についてルートテーブルを照会する段階は、負荷平均化でマージサーバに接続して関連ＳＱＬ（構造化照会言語）ステートメントを実行し、ルートテーブルにおけるタブレットデータブロック情報を取得する段階を有する。
【００８０】
段階Ｓ４１０  制御サーバは、ルートテーブルにおけるタブレットデータブロックに対応する以下の情報、つまり、テーブル名、境界、位置分散、データチェックコード、インデックス、作成時間およびサイズのうちの１または複数が、ログに含まれるタブレットデータブロックと整合しているかどうかをチェックする。
【００８１】
当該情報のいずれかについて何らかの不整合が段階Ｓ４１０のチェックの結果に見つかった場合、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないと制御サーバにより判断する。
【００８２】
一方、当該情報のいずれかについて整合性が段階Ｓ４１０のチェックの結果に見つかった場合、制御サーバは、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していると判断する。
【００８３】
一実施形態において、段階Ｓ４１１は、段階Ｓ４１０の判断結果が正常であるか異常であるかに拘らず、実行される必要がある。当該判断が、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないということであった場合、さらなるステップＳ４１２が実行される必要がある。
【００８４】
段階Ｓ４１１  制御サーバは、ログに含まれるタブレットデータブロック情報と、ルートテーブルにおけるタブレットデータブロック情報とを要約および格納する。一実施形態において、段階Ｓ４１１は、ログに含まれるタブレットデータブロック情報と、ルートテーブルにおけるタブレットデータブロック情報とを制御サーバにより要約する段階と、制御サーバにより、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存し、それにより、ＯｃｅａｎＢａｓｅデータベースにおけるその有効期間中のあるテーブルのタブレットデータブロックの変化ステータスのその後の閲覧を容易にする段階とを有する。
【００８５】
段階Ｓ４１２  制御サーバはアラームを送信する。アラームは、タブレットデータブロック情報が整合しておらず、即時の処理が必要であり得るとユーザに促すべく送信され、それにより、その後の全ての自動処理または手動処理が容易になる。
【００８６】
上記の点を考慮すると、現在のシステムと比較して、開示される実施形態は、既存のシステムがタブレットデータブロックの現在のステータスデータのみを取得し得るという問題を克服しているが、タブレットデータブロックのステータスの変化を追跡し得ない。開示される実施形態において、タブレットデータブロックが変化した場合に生成されるタブレットデータブロック情報を含むログは、タブレットデータブロック情報を取得すべく、リアルタイムで取得およびパースされる。本実施形態において、取得されたタブレットデータブロック情報と、照会を通じて見つかったタブレットデータブロック情報とは、要約され、ディスクに永続的に格納される。タブレットデータブロック情報はタブレットデータブロックのステータスが変化する度に永続的に格納されるので、タブレットデータブロックのステータスの変化が追跡され得る。一方、開示される実施形態は、手動検索により実行されるチェックの効率が低い、また、ログが定期的にクリーニングされ、検索を介して取得されるログデータが不完全であることに起因してチェックの結果が不正確である可能性がある、という現在のシステムにおける問題を克服している。開示される実施形態において、取得されたタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報について、多次元チェックがリアルタイムで実行される。チェックの結果が、取得されたタブレットデータブロック情報とルートテーブルにおけるタブレットデータブロック情報とが整合していないということだった場合、早期警告が遅れずに送信される。タブレットデータブロックの障害および消失が発生した場合、時宜を得た訂正が実行され得、それにより、チェックの効率が高くなると共に、チェックの結果が正確になる。同時に、本実施形態では、取得されたタブレットデータブロック情報と、照会を介して見つかった、ルートテーブルにおけるタブレットデータブロック情報とが要約され、永続的に格納されるので、次に、完全なデータがその後のチェックで取得され得、それにより、チェックの正確性および効率が向上する。
【００８７】
開示された、データブロックを処理する方法と同様に、本開示の一実施形態は、データベースのデータブロックを処理するデバイスをさらに提供する。デバイスは、ストレージサーバと、制御サーバと、マージサーバとを含むシステムに適用される。図５に示されるように、デバイスは、ストレージサーバにより送信されるタブレットデータブロック情報を含むログを受信するよう構成される受信モジュール５０１と、ストレージサーバにより送信されるタブレットデータブロック情報を含むログを受信モジュールが受信した場合、ログに含まれるタブレットデータブロック情報を取得するよう構成される取得モジュール５０２と、取得モジュールにより取得される、ログに含まれるタブレットデータブロック情報に従って、対応するルートテーブルにおけるタブレットデータブロック情報についてマージサーバに照会するよう構成される照会モジュール５０３とを含む。
【００８８】
一実施形態において、照会モジュールは、取得モジュールにより取得される、ログに含まれるタブレットデータブロック情報に対応するテーブル名を識別し、かつ、テーブル名に対応するルートテーブルにおけるタブレットデータブロック情報についてマージサーバに照会するよう構成される。
【００８９】
図５に示されるように、デバイスは、取得モジュールにより取得される、ログに含まれるタブレットデータブロック情報が、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報と整合しているかどうかを判断するよう構成される判断モジュール５０４をさらに含む。
【００９０】
一実施形態において、判断モジュールは、照会モジュールにより見つけられたルートテーブルにおけるタブレットデータブロックに対応する以下の情報、つまり、テーブル名、境界、位置分散、データチェックコード、インデックス、作成時間およびサイズのうちの１または複数が、取得モジュールにより取得された、ログに含まれるタブレットデータブロックと整合しているかどうかをチェックするよう、かつ、情報のいずれかについて何らかの不整合がチェックの結果に見つかった場合、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報が、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報と整合していないと判断するよう特に構成される。
【００９１】
図５に示されるように、デバイスは、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報と、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報とを要約および格納するよう、かつ、ログに含まれるタブレットデータブロック情報がルートテーブルにおけるタブレットデータブロック情報と整合していないことを判断の結果が示した場合、アラームを送信するよう構成される処理モジュール５０５をさらに含む。
【００９２】
一実施形態において、処理モジュール５０５は、取得モジュールにより取得された、ログに含まれるタブレットデータブロック情報と、照会モジュールにより見つけられた、ルートテーブルにおけるタブレットデータブロック情報とを要約するよう、かつ、複数のタブレットデータブロックに対応する複数のテーブル名を複数のキー値として用いて、要約されたタブレットデータブロック情報をディスクに永続的に保存し、それにより、ＯｃｅａｎＢａｓｅデータベースにおけるその有効期間中のあるテーブルのタブレットデータブロックの変化ステータスのその後の閲覧ならびにその後の全ての自動処理または手動処理を容易にするよう特に構成される。
【００９３】
開示された、データブロックを処理する方法と同様に、本開示の一実施形態は、データベースのデータブロックを処理するデバイスをさらに提供する。デバイスは、ストレージサーバと、制御サーバと、マージサーバとを含むシステムに適用される。図６に示されるように、デバイスは、ストレージサーバ自体のログをポーリングするよう構成されるポーリングモジュール６０１と、新たなデータがログに現れたとポーリングモジュールが判断した場合、新たなデータがタブレットデータブロック情報であるかどうかを識別するよう構成される識別モジュール６０２と、識別モジュールの識別の結果が異常であった場合、ログに含まれるタブレットデータブロック情報とマージサーバのルートテーブルにおける（または複数のデバイスに亘って分散した複数のルートテーブルのうちの１つにおける）タブレットデータブロック情報との間の整合性を制御サーバが識別するように、タブレットデータブロック情報を含むログを制御サーバに送信するよう、かつ、当該情報を要約および格納し、それにより、ＯｃｅａｎＢａｓｅデータベースにおけるその有効期間中のあるテーブルのタブレットデータブロックの変化ステータスのその後の閲覧ならびにその後の自動処理または手動処理を容易にするよう構成される送信モジュール６０３とを含む。
【００９４】
上記の点を考慮すると、現在のシステムと比較して、タブレットデータブロックが変化した場合に生成されるタブレットデータブロック情報を含むログは、タブレットデータブロック情報を取得すべく、リアルタイムで取得およびパースされ得る。本実施形態において、取得されたタブレットデータブロック情報と、照会を介して見つかったタブレットデータブロック情報とは、要約されて、ディスクに永続的に格納され、様々な状態にあるタブレットのタブレットデータブロック情報がディスクに永続的に格納される。したがって、タブレットデータブロックのステータスの変化を追跡するという目標を達成することが可能である。一方、本開示において取得されたタブレットデータブロック情報およびルートテーブルにおけるタブレットデータブロック情報について、多次元チェックがリアルタイムで実行され、チェックの結果が、取得されたタブレットデータブロック情報と、ルートテーブルにおけるタブレットデータブロック情報が整合していないということであった場合、早期警告が遅れずに送信される。タブレットデータブロックの障害および消失が発生した場合、時宜を得た訂正が実行され得、それにより、チェックの効率が高くなると共に、チェックの結果が正確になる。同時に、本実施形態では、取得されたタブレットデータブロック情報と、ルートテーブルにおける照会を介して見つかったタブレットデータブロック情報とが、要約され、永続的敵に格納されるので、次に、完全なデータがその後のチェックにおいて取得され得、それにより、チェックの正確性および効率が向上する。
【００９５】
本開示の装置におけるこれらのモジュールは、単一のデバイスに統合され得、または別々に導入され得る。前述のこれらのモジュールは、１つのモジュールにまとめられ得、または複数のサブモジュールにさらに分割され得る。
【００９６】
実施形態についての上記説明を通じて、当業者であれば、開示される実施形態が、ソフトウェアと必要なハードウェアプラットフォームにより実装され得、ハードウェアにおいては全体が確実に実装され得もすることを明確に理解し得る。そのような理解に基づいて、開示される実施形態の技術的解決法の要点、または既存のシステムに寄与する部分が、ソフトウェア製品という形式で具現化され得る。コンピュータソフトウェア製品は、ストレージ媒体に格納され、実施形態において説明される方法を実行するよう（パーソナルコンピュータ、サーバ、ネットワーク、デバイス、またはそれらと同様のものであり得る）コンピュータデバイスに命令するいくつかの命令を含む。当業者であれば、添付図面がいくつかの実施形態の概略図にすぎないこと、および添付図面におけるモジュールまたは処理が、開示される実施形態の実装において必ずしも要求されないことを理解し得る。当業者であれば、一実施形態における装置の複数のモジュールが、実施形態の説明に従って実施形態の装置において分散され得、または本実施形態とは異なる１または複数の装置に配置されるようその分だけ変更され得ることを理解し得る。前述の実施形態における複数のモジュールは、１つのモジュールにまとめられ得、または複数のサブモジュールにさらに分割され得る。実施形態の前述の連続番号は、説明の都合のためのものにすぎず、実施形態間の優先性を示唆するものではない。上記開示は、本開示のいくつかの実施形態にすぎない。しかしながら、本開示はこれらの実施形態に限定されるべきではなく、当業者により予期され得るその変形のいずれも、本開示の保護範囲に入るであろう。
【図１】
0006633642.tif 000002
【図２】
0006633642.tif 000003
【図３】
0006633642.tif 000004
【図４Ａ】
0006633642.tif 000005
【図４Ｂ】
0006633642.tif 000006
【図５】
0006633642.tif 000007
【図６】
0006633642.tif 000008