(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-03-10
(54)【発明の名称】動的適応型パーティション分割
(51)【国際特許分類】
G06F 16/176 20190101AFI20230303BHJP
【ＦＩ】
G06F16/176
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022539389
(86)(22)【出願日】2019-12-27
(85)【翻訳文提出日】2022-07-13
(86)【国際出願番号】 US2019068666
(87)【国際公開番号】W WO2021133405
(87)【国際公開日】2021-07-01
(81)【指定国・地域】
(71)【出願人】
【識別番号】520155228
【氏名又は名称】ヒタチ ヴァンタラ エルエルシー
(74)【代理人】
【識別番号】110000279
【氏名又は名称】弁理士法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】グリマルディ，ケビン カヌエッテ
(72)【発明者】
【氏名】モンゾン， ジョシュア ジェン
(57)【要約】
いくつかの例では、演算装置は、第１時点における第１パーティションのデータの状態の第１スナップショットを格納してもよい。演算装置は、それぞれがデータの一部分を受信する第２パーティション及び第３パーティションであって、それぞれがメトリックスキーマを含む第２パーティション及び第３パーティションを作成してもよいとともに、第１スナップショットの情報に基づいて、メトリックスキーマについての情報を決定してもよい。メトリックスキーマについての情報を決定することの間に、演算装置は、第１パーティションへのライトを受信してもよい。演算装置は、ライトに基づいて第１パーティションを更新し、ライトに基づいてデータ構造に分割更新コマンドを追加してもよい。加えて、演算装置は、分割更新コマンドに基づいて、第２パーティション又は第３パーティションのメトリックスキーマのうちの少なくとも１つを更新してもよい。
【特許請求の範囲】
【請求項1】
システムであって、実行可能命令によって操作を実行するように構成された１又は複数のプロセッサを含み、
前記操作は、
前記１又は複数のプロセッサによって、複数のメタデータオブジェクトを含む第１パーティションを分割する命令を受信することと、
前記１又は複数のプロセッサによって、第１時点における前記複数のメタデータオブジェクトの状態の第１スナップショットを格納することと、
前記１又は複数のプロセッサによって、それぞれが前記メタデータオブジェクトの一部分を受信する第２パーティション及び第３パーティションであって、それぞれがメトリックスキーマを含む前記第２パーティション及び前記第３パーティションを作成することと、
前記１又は複数のプロセッサによって、前記第１スナップショットの情報に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての情報を決定することと、
前記決定することの間に、前記１又は複数のプロセッサによって、前記第１パーティションへのライトを受信することと、
前記１又は複数のプロセッサによって、前記ライトに基づいて前記第１パーティションを更新し、前記ライトに基づいてデータ構造に分割更新コマンドを追加することと、
前記１又は複数のプロセッサによって、前記分割更新コマンドに基づいて前記第２パーティション又は前記第３パーティションの前記メトリックスキーマのうちの少なくとも１つを更新することと、
を含むシステム。
【請求項2】
前記分割更新コマンドは、前記少なくとも１つのメトリックスキーマを、前記第２パーティション又は前記第３パーティションのそれぞれの１つにおける前記ライトを含めることに対応する条件に変更するための情報を含む、請求項１に記載のシステム。
【請求項3】
前記操作は、前記更新分割コマンドを用いて前記メトリックスキーマのうちの前記少なくとも１つを更新する間に、前記第１パーティションへのライトをブロックすることをさらに含む、請求項２に記載のシステム。
【請求項4】
前記操作は、前記第１スナップショットの前記情報に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての前記情報を前記決定することの後に、前記第１パーティションの第２スナップショットを取得することと、
前記第２スナップショットの前記情報及び前記データ構造に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての追加情報を決定することと、
をさらに含む、請求項１に記載のシステム。
【請求項5】
前記操作は、前記第２スナップショットの前記情報及び前記データ構造に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての前記追加情報を前記決定することの間に、前記第１パーティションへの追加ライトを受信することと、
前記追加ライトに基づいて前記第１パーティションを更新し、前記追加ライトに基づいて、追加分割更新コマンドを前記データ構造に追加することと、
前記追加分割更新コマンドに基づいて、前記第２パーティション又は前記第３パーティションの前記メトリックスキーマのうちの少なくとも１つを更新することと、
をさらに含む、請求項４に記載のシステム。
【請求項6】
前記操作は、前記分割更新コマンドに基づいて前記メトリックスキーマが更新された前記第２パーティション又は前記第３パーティションのうちの前記少なくとも１つの前記メタデータオブジェクトの前記一部分を、前記ライトに基づいて更新することをさらに含む、請求項１に記載のシステム。
【請求項7】
前記操作は、ライトを受信するため及び前記第１パーティションに削除のマーク付けを行うために、前記第２パーティション及び前記第３パーティションをアクティブ化することをさらに含む、請求項１に記載のシステム。
【請求項8】
前記操作は、非暗号化ハッシュアルゴリズムを使用して、前記メタデータオブジェクトに前記第１パーティションのそれぞれのキー範囲に割り当てることをさらに含む、請求項１に記載のシステム。
【請求項9】
前記分割する命令は、前記第１パーティションに関連付けされた少なくとも１つの閾値を満たしている前記第１パーティションに少なくとも部分的に基づいて受信され、前記少なくとも１つの閾値は、閾値パーティションサイズ、トラフィック量閾値、応答待ち時間閾値、ディスク又はメモリ使用量閾値、又はネットワーク待ち時間閾値のうちの少なくとも１つを特定する、請求項１に記載のシステム。
【請求項10】
前記ライトは、ライトコマンド、削除コマンド、作成コマンド又は更新コマンドのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項11】
前記システムは、ネットワークストレージと通信状態にあり、
前記メタデータオブジェクトは、前記ネットワークストレージによって格納されているオブジェクトに関する情報を含む請求項１に記載のシステム。
【請求項12】
方法であって、演算装置によって、第１時点における第１パーティションの複数のデータオブジェクトの状態の第１スナップショットを格納することと、
前記演算装置によって、それぞれが前記データオブジェクトの一部分を受信する第２パーティション及び第３パーティションであって、それぞれがメトリックスキーマを含む前記第２パーティション及び前記第３パーティションを作成することと、
前記演算装置によって、前記第１スナップショットの情報に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての情報を決定することと、
前記決定することの間に、１又は複数のプロセッサによって、前記第１パーティションへのライトを受信することと、
前記演算装置によって、前記ライトに基づいて前記第１パーティションを更新し、前記ライトに基づいてデータ構造に分割更新コマンドを追加することと、
前記演算装置によって、前記分割更新コマンドに基づいて前記第２パーティション又は前記第３パーティションの前記メトリックスキーマのうちの少なくとも１つを更新することと、
を含む方法。
【請求項13】
前記分割更新コマンドは、前記少なくとも１つのメトリックスキーマを、前記第２パーティション又は前記第３パーティションのそれぞれの１つにおける前記ライトを含めることに対応する条件に変更するための情報を含む、請求項１３に記載の方法。
【請求項14】
１又は複数のプロセッサによって実行されたときに、１又は複数のプロセッサを操作を実行するように構成する命令を格納する１又は複数の非一時的なコンピュータ可読媒体であって、前記操作は、
演算装置によって、第１時点における第１パーティションのデータの状態の第１スナップショットを格納することと、
前記演算装置によって、それぞれが前記データの一部分を受信する第２パーティション及び第３パーティションであって、それぞれがメトリックスキーマを含む前記第２パーティション及び前記第３パーティションを作成することと、
前記演算装置によって、前記第１スナップショットの情報に基づいて、前記第２パーティション及び前記第３パーティションの前記メトリックスキーマについての情報を決定することと、
前記決定することの間に、前記１又は複数のプロセッサによって、前記第１パーティションへのライトを受信することと、
前記演算装置によって、前記ライトに基づいて前記第１パーティションを更新し、前記ライトに基づいてデータ構造に分割更新コマンドを追加することと、
前記演算装置によって、前記分割更新コマンドに基づいて前記第２パーティション又は前記第３パーティションの前記メトリックスキーマのうちの少なくとも１つを更新することと、
を含む、１又は複数の非一時的なコンピュータ可読媒体。
【請求項15】
前記分割更新コマンドは、前記少なくとも１つのメトリックスキーマを、前記第２パーティション又は前記第３パーティションのそれぞれの１つにおける前記ライトを含めることに対応する条件に変更するための情報を含む、請求項１４に記載の１又は複数の非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【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】
主題は、構造上の特徴及び／又は方法論的な行為に特定の言語で説明してきたが、添付の特許請求の範囲に定義されている主題は、説明されている特定の特徴又は行為に必ずしも限定されないことを理解されたい。もっと正確に言えば、特定の特徴及び行為は、特許請求の範囲を実装する形の例として開示されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【国際調査報告】