特許 5798248 規模変更可能なデータ記憶サービスを実装するためのシステムおよび方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】5798248

(24)【登録日】2015年8月28日

(45)【発行日】2015年10月21日

(54)【発明の名称】規模変更可能なデータ記憶サービスを実装するためのシステムおよび方法

(51)【国際特許分類】

   G06F 12/00 20060101AFI20151001BHJP

   G06F 17/30 20060101ALI20151001BHJP

【ＦＩ】

   G06F12/00 513A

   G06F12/00 545A

   G06F17/30 140

【請求項の数】15

【全頁数】93

(21)【出願番号】特願2014-518955(P2014-518955)

(86)(22)【出願日】2012年6月27日

(65)【公表番号】特表2014-525082(P2014-525082A)

(43)【公表日】2014年9月25日

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

(87)【国際公開番号】WO2013003443

(87)【国際公開日】20130103

【審査請求日】2014年1月17日

(31)【優先権主張番号】13/170,031

(32)【優先日】2011年6月27日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507303550

【氏名又は名称】アマゾン・テクノロジーズ・インコーポレーテッド

(74)【代理人】

【識別番号】100064621

【弁理士】

【氏名又は名称】山川 政樹

(74)【代理人】

【識別番号】100098394

【弁理士】

【氏名又は名称】山川 茂樹

(72)【発明者】

【氏名】シヴァスブラマニアン，スワミナサン

(72)【発明者】

【氏名】ステファニ，ステファノ

(72)【発明者】

【氏名】ブラゴハイン，チランジーブ

(72)【発明者】

【氏名】ブラックマン，ランデ，エイ

(72)【発明者】

【氏名】ラス，ティモシー，アンドリュー

(72)【発明者】

【氏名】ブラッドフォード，レイモンド，エス

(72)【発明者】

【氏名】マクアリスター，グラント，エイ，エム

(72)【発明者】

【氏名】クレスザ，ジャクブ

(72)【発明者】

【氏名】ハミルトン，ジェームズ

(72)【発明者】

【氏名】カブレラ，ルイス，フェリペ

【審査官】 加内 慎也

(56)【参考文献】

【文献】 特開２００９−１８１５４６（ＪＰ，Ａ）

【文献】 特開２００７−０８６９５１（ＪＰ，Ａ）

【文献】 米国特許第０６７２１７４９（ＵＳ，Ｂ１）

【文献】 特開２００６−２９３９８１（ＪＰ，Ａ）

【文献】 特開２００２−３４２２６９（ＪＰ，Ａ）

【文献】 特開２００６−３０２３０７（ＪＰ，Ａ）

【文献】 特開２００２−０２４１９２（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０５３５９４（ＷＯ，Ａ１）

【文献】 Sahri et al.，Scalable Web Services Interface for SD-SQL Server，２００８年，InfoScale '08，ＵＲＬ，http://www.cse.scu.edu/~tschwarz/Papers/InfoScale.pdf

【文献】 Litwin et al.，An Architecture for a Scalable Distributed DBS:Application to SQL Server 2000，２００２年，Second International Workshop on Cooperative Internet Computing (CIC 2002)，ＵＲＬ，http://www.lamsade.dauphine.fr/~litwin/sd-sql-server2_tr3.pdf

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

コンピュータによって、
要求が、テーブルの識別子、および前記テーブルの中に記憶されたアイテムにインデックス作成する一次キーを特定する、非リレーショナルデータ記憶部の中で前記テーブルを作成する要求を受信することと、
前記受信に応答して、
規模変更可能なテーブルが、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、前記規模変更可能なテーブルが、所定のサイズ制限を持たない、前記非リレーショナルデータ記憶部の中で前記規模変更可能なテーブルを作成することと、
前記規模変更可能なテーブルにアクセスする１つ以上の要求の受信に応答して、あるいは非リレーショナルデータ記憶部を実装するシステムにおける異常の検出に応答して、前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うことと、
を行うことを含む、方法。

【請求項2】

前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含み、
前記方法はさらに、
前記非リレーショナルデータ記憶部の中で維持された１つ以上のテーブルを記述する要求を受信することと、
１つ以上のテーブルを記述する前記要求の受信に応答して、前記１つ以上のテーブルに関する情報が、前記非同期テーブル作成ワークフローによって前記規模変更可能なテーブルの作成が成功したかどうかを示す情報を含む、前記１つ以上のテーブルに関する前記情報を返すことと、
を含む、請求項１に記載の方法。

【請求項3】

前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上の要求を受信することと、
前記１つ以上の要求の受信に応答して、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定することと、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルをプログラムで区分することを行うことと、
をさらに含む、請求項１に記載の方法。

【請求項4】

前記一次キーは、ハッシュキー属性として指定される単一の属性を備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値を備え、
前記規模変更可能なテーブルをプログラムで区分することは、それらのそれぞれのハッシュキー属性値のハッシュに依存して、前記規模変更可能なテーブルの中の前記アイテムを２つ以上の区分に分割することを含む、
請求項１に記載の方法。

【請求項5】

前記一次キーは、ハッシュキー属性として指定される属性と、範囲キー属性として指定される別の属性とを備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値と、前記範囲キー属性のそれぞれの値とを備え、
前記範囲キー属性値は、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中の全てのアイテムの中から、特定のアイテムを一意的に識別し、前記同一のハッシュキーを有する前記アイテムは、それらのそれぞれの範囲キー属性値に従って順序付けられ、
前記規模変更可能なテーブルをプログラムで区分することは、それらのそれぞれの範囲キー属性値に依存して、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中のアイテムを２つ以上の区分に分割することを含む、
請求項１に記載の方法。

【請求項6】

前記規模変更可能なテーブルをプログラムで区分することは、前記規模変更可能なテーブルを２つ以上の区分に分割することと、複数のコンピューティングノードのうちの異なるものの上に、前記２つの区分のそれぞれを記憶することとを含む、請求項１に記載の方法。

【請求項7】

前記規模変更可能なテーブルをプログラムで区分することは、区分の１つ以上の複製が要求を受け入れて処理し続けている間に、前記規模変更可能なテーブルの前記区分を移動させること、または分割することを含む、請求項１に記載の方法。

【請求項8】

前記規模変更可能なテーブルをプログラムで区分することは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求の受信に応答して、あるいは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、減少する数の要求の受信に応答して行われる、請求項１に記載の方法。

【請求項9】

テーブルを作成する前記要求はさらに、１つ以上のユーザ選好の指示を備え、前記１つ以上のユーザ選好は、好ましいサービス要求スループットレベル、または保証が要求されるサービス要求スループットレベルを備え、
前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うことは、前記ユーザ選好のうちの１つ以上が満たされていないという検出に応答して行われる、
請求項１に記載の方法。

【請求項10】

それぞれ、少なくとも１つのプロセッサと、メモリとを備える、複数のコンピューティングノードを備える、システムであって、前記複数のコンピューティングノードは、データ記憶サービスを実装するように構成され、
記憶サービスクライアントの代わりにテーブルを作成するサービス要求の受信に応答して、前記サービス要求は、前記テーブルの識別子、および前記テーブルの中に記憶されたアイテムにインデックス作成する一次キーを特定し、前記データ記憶サービスは、非リレーショナルデータ記憶部の中で規模変更可能なテーブルを作成するように構成され、
前記規模変更可能なテーブルは、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、
前記規模変更可能なテーブルは、所定のサイズ制限を持たず、
前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含み、
さらに、前記データ記憶サービスにおける異常の検出に応答して、前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行う、
システム。

【請求項11】

前記データ記憶サービスはさらに、前記規模変更可能なテーブルの中のアイテムを記憶する、読み出す、修正する、または削除する１つ以上のサービス要求の受信に応答して、前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うように構成される、請求項１０に記載のシステム。

【請求項12】

前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上のサービス要求の受信に応答して、前記データ記憶サービスは、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定し、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルをプログラムで区分するように構成される、
請求項１０に記載のシステム。

【請求項13】

前記データ記憶サービスはさらに、前記規模変更可能なテーブルをプログラムで区分することが、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求の受信に応答して、あるいは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、減少する数の要求の受信に応答して行われるように、構成される、請求項１０に記載のシステム。

【請求項14】

前記一次キーは、ハッシュキー属性として指定される単一の属性と、範囲キー属性として指定される別の属性とを備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値と、前記範囲キー属性のそれぞれの値とを備え、
前記範囲キー属性値は、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中の全てのアイテムの中から、特定のアイテムを一意的に識別し、前記同一のハッシュキーを有する前記アイテムは、それらのそれぞれの範囲キー属性値に従って順序付けられ、
前記データ記憶サービスはさらに、それらのそれぞれの範囲キー属性値に依存して、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中のアイテムを２つ以上の区分に分割するように構成される、
請求項１０に記載のシステム。

【請求項15】

規模変更可能なテーブルを作成することはさらに、
前記複数のコンピューティングノードのうちの１つ以上の状態を反映する情報を収集することと、
前記収集された情報に依存して、前記規模変更可能なテーブルを作成する１つ以上のコンピューティングノードを判定することと、
前記１つ以上のコンピューティングノードのそれぞれの上に前記規模変更可能なテーブルの少なくともサブセットを記憶するためのそれぞれの区分を作成することと、
を含む、請求項１０に記載のシステム。

【発明の詳細な説明】

【背景技術】

【0001】

いくつかの先導的技術機関が、「サービスとしてのソフトウェア」を販売する技術を構築することに投資している。そのようなサービスは、共有記憶装置（例えば、データベースシステム）および／またはコンピューティングリソースへのアクセスをクライアントまたは加入者に提供する。多層電子商取引システム内で、異なるリソースが、加入者および／またはマシン全体からのそれらのアプリケーションに、ＣＰＵに、メモリに、ネットワーク帯域幅に、およびＩ／Ｏ能力に割り付けられてもよい。

【0002】

ユーザの代わりに大量のデータを管理するデータベースシステムは、セキュリティ問題、防災および復旧問題、データ局所性および可用性問題等を含む、いくつかの理由のうちのいずれかで、しばしば異なる場所において、２つ以上のマシンにわたってそのデータを分散させ、および／または複製してもよい。これらのマシンは、共有リソースプールとしての方法を含む、任意の数の方法で構成されてもよい。

【0003】

クライアントアプリケーションとデータベースサーバとの間の相互作用は、典型的には、読み取り・修正・書き込みワークフローを使用して概念化することができる、読み取り動作（読取専用クエリ）、（データを記憶する）書き込み動作、および更新動作を含む。

【図面の簡単な説明】

【0004】

【図1】ウェブサービスベースのデータ記憶サービスを実装するように構成される、システムアーキテクチャの一実施形態を図示するブロック図である。

【図2A】一実施形態による、ウェブサービスプラットフォームの種々の構成要素を図示するブロック図である。

【図2B】一実施形態による、ウェブサービスプラットフォームの種々の構成要素を図示するブロック図である。

【図2C】一実施形態による、ウェブサービスプラットフォームの種々の構成要素を図示するブロック図である。

【図3A】一実施形態による、複数のテーブルの中のアイテムとしてのデータの記憶を図示するブロック図である。

【図3B】一実施形態による、複数のテーブルの中のアイテムとしてのデータの記憶を図示するブロック図である。

【図4】一実施形態による、アイテムが記憶されているテーブルの一次キーとして指定されている、数値属性を含有する、３つのアイテムを図示するブロック図である。

【図5】記憶サービスクライアントの代わりに、データ記憶サービスによって維持されるテーブルを作成するための方法の一実施形態を図示するフロー図である。

【図6】ウェブサービスＡＰＩを通して受信される要求に応答して、テーブルを作成するための方法の一実施形態を図示するフロー図である。

【図7】テーブルメタデータを生成するための方法の一実施形態を図示するフロー図である。

【図8】ＣｒｅａｔｅＴａｂｌｅワークフローの一実施形態を図示するフロー図である。

【図9】そうする要求に応答して、アイテムを更新するための方法の一実施形態を図示するフロー図である。

【図10】条件付き更新および／または複数の出力オプションをサポートするＡＰＩを使用して、アイテムを更新するための方法の一実施形態を図示するフロー図である。

【図11】非リレーショナルデータ記憶部の中で維持されたテーブルを区分するための方法の一実施形態を図示するフロー図である。

【図12】クエリを行うための方法の一実施形態を図示するフロー図である。

【図13】クエリを行うための方法の別の実施形態を図示するフロー図である。

【図14】テーブルスキャン動作を行うための方法の一実施形態を図示するフロー図である。

【図15】一実施形態による、スキャンまたは応答制限が特定されている、クエリまたはスキャン動作を行うための方法を図示するフロー図である。

【図16】一実施形態による、データ記憶サービスを提供するシステムのデータモデルの一部分を図示するブロック図である。

【図17】好ましいスループットモデルを使用して、データ記憶サービスクライアントの代わりにテーブルを作成および管理するための方法の一実施形態を図示するフロー図である。

【図18】コミットメント型スループットレベルを維持または修正しながら、特定のテーブルを対象とした要求を果たすための方法の一実施形態を図示するフロー図である。

【図19】区分が「ライブである」間に、記憶サービスクライアントの代わりに、データ記憶サービスによって維持されているテーブルの区分の複製を移動させるための方法の一実施形態を図示するフロー図である。

【図20】物理的コピー機構を使用して、複製を移動させるための方法の一実施形態を図示するフロー図である。

【図21】そうする要求に応答して、データ記憶サービスによって維持されているテーブルの区分を分割するための方法の一実施形態を図示するフロー図である。

【図22】異常の検出に応答して、データ記憶サービスによって維持されているテーブルの区分を移動させるための方法の一実施形態を図示するフロー図である。

【図23】記憶ノード上のホットスポットの検出に応答して、データ記憶サービスによって維持されているテーブルの区分を移動させる、または分割するための方法の一実施形態を図示するフロー図である。

【図24】１つ以上の記憶サービスクライアントの代わりに、複数のテーブルを維持および管理するための方法の一実施形態を図示するフロー図である。

【図25】一実施形態による、データ記憶サービスの実装に好適であり得る、コンピューティングノードを図示するブロック図である。

【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】

【表1】

【0034】

いくつかの実施形態では、クライアント／ユーザの代わりにデータ記憶サービスによって維持されるテーブルは、そのアイテムを識別する一次キーを有してもよい。一次キーは、種々の実施形態では、１つの属性に（上記で説明されるように単一値であってもよい）、またはいくつかの属性に定義されてもよい（すなわち、上記で説明されるように複合一次キーであってもよい）。キー属性は、不変であり得、固定タイプを有してもよく、テーブル内のアイテムを一意的に識別するため、あらゆるアイテムに強制的であり得る。いくつかの実施形態では、一次キーは、インデックス作成されるテーブルの一部のみであり、インデックスタイプは、テーブルが作成されるときに特定されてもよい。例えば、アイテムのテーブルが作成されるとき、属性がテーブルの一次キー属性として指定されてもよい（または２つの属性が複合一次キーのために指定されてもよい）。テーブルの中の全てのアイテムは、一次キーのために指定された属性（複数可）を含まなければならず、データ記憶サービス（および／または基礎的システム）は、これらの属性名の値（または値の組み合わせ）がテーブルの中の各アイテムに一意的であることを確実にしてもよい。例えば、既存のアイテムと同一の一次キー値を有する新しいアイテムを追加しようとする場合、新しいアイテムは、テーブルの中の既存のアイテムに取って代わってもよい。

【0035】

図４は、一実施形態による、「ｉｍａｇｅＩＤ」と名付けられた数値属性が一次キーとして指定されている、テーブルの中に記憶され得る３つのアイテムを図示する。この実施例では、アイテム４１０ａは、（１という値を有する）ｉｍａｇｅＩＤ属性と、少なくとも３つの他の属性（すなわち、ｄａｔｅ属性、ｔｉｔｌｅ属性、およびｔａｇｓ属性）の値とを含む。同様に、アイテム４１０ｂは、（２という値を有する）ｉｍａｇｅＩＤ属性と、少なくとも３つの他の属性（例えば、ａｌｂｕｍ属性、ｒａｔｉｎｇ属性、およびｔａｇｓ属性）の値とを含む。この実施例では、アイテム４１０ｃは、（３という値を有する）ｉｍａｇｅＩＤ属性と、少なくとも３つの他の属性（例えば、ｄａｔｅ属性、ｐｒｉｃｅ属性、およびａｕｔｈｏｒ属性）の値とを有する。この実施例では、テーブルに記憶されたアイテムは、それらの一次キー値に従ってインデックス作成されてもよい。言い換えれば、これらのアイテムのそれぞれは、その一次キー値のみによって一意的に識別されてもよく、その一次キー値によって識別されているアイテムを読み出す動作は、その他の属性のうちのいくつかまたは全ての値を読み出すことを含んでもよい。

【0036】

上述のように、データ記憶サービス（および／または基礎的システム）は、一次キーに基づいてインデックスを作成してもよい。インデックスのタイプは、テーブルが単純一次キーを使用するか、または複合一次キーを使用するかどうかに依存してもよい。例えば、データ記憶サービスは、以下のようなハッシュインデックスまたはハッシュおよび範囲インデックスのいずれかとして一次キーにインデックス作成してもよい。
・ハッシュ−ハッシュは、文字列または数字であってもよい。単純一次キーは、文字列または数字であり得る、ハッシュインデックスである、１つのインデックス値を有してもよい。
・範囲−範囲は、文字列または数字であってもよい。範囲は、データクエリが範囲に基づいて結果を精緻化することができるように、テーブルアイテムが選別されることを可能にしてもよい。複合一次キーは、ハッシュインデックス（本明細書ではハッシュキー値と呼ばれることもある）および範囲インデックス（本明細書では範囲キー値と呼ばれることもある）といった、インデックスの２つの値を含有してもよい。

【0037】

単純一次キーが、データ収集および（例えば、以下で説明されるスキャンＡＰＩを使用した）テーブルデータの低頻度スキャンのために十分であり得る。複合一次キーは、テーブルデータがより正確に組織化されることを可能にしてもよく、より効率的なデータ検索のための以下で説明されるＱｕｅｒｙ ＡＰＩの使用を可能にしてもよい。以下のアドレステーブル（表２）は、テーブルの中の各アイテムを一意的に識別するための一次キーとしての単一の属性の使用を例証する。

【0038】

【表2】

【0039】

この実施例では、ＵｓｅｒＩＤと呼ばれる属性である、一次キーが、あらゆるアイテムにおいて要求され、そのタイプ（「文字列」）が、あらゆるアイテムに対して固定される。しかしながら、各アイテムはまた、追加の属性の任意の組み合わせを含んでもよい。データ記憶システムは、いくつかの実施形態では、ＵｓｅｒＩＤの値がテーブルの中の各アイテムに一意的であることを確実にするように構成されてもよい。上述のように、いくつかの実施形態では、属性値は、空値または空白になり得ない。そのような実施形態では、属性は、それと関連付けられる値を有するまで／持たない限り、テーブルの中に存在しない。以下のテーブル（表３）は、テーブルの中のアイテムが一意的に識別され得る、一次キーとしての数値属性（この場合はＩｍａｇｅＩＤ）を指定する。

【0040】

【表3】

【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】

条件付き更新および／または複数の出力オプションをサポートするＡＰＩを使用して、アイテムを更新するための方法の一実施形態が、図１０でフロー図によって図示されている。この実施例で図示されるように、本方法は、非リレーショナルデータベース内のテーブル（例えば、データ記憶サービスクライアントの代わりに維持されるテーブル）の中のアイテムを更新するサービス要求を受信することを含んでもよい。以前の実施例の場合のように、ＵｐｄａｔｅＩｔｅｍ要求は、テーブル名および一次キー（更新要求の標的であるアイテムを集合的に識別し得る）と、要求されている更新（複数可）を示す１つ以上の他の入力パラメータ値とを含んでもよい。更新要求がアイテムにおける任意の属性値を条件としない場合、１０２０からの否定の出口として示され、１０５０の場合のように、要求において特定される更新（複数可）が行われてもよい。しかしながら、更新要求が、要求において特定される値に対応して合致する、アイテムにおける１つ以上の属性値を条件とする場合（例えば、ＵｐｄａｔｅＩｔｅｍ要求への入力が、満たされるべき１つ以上の条件を特定するＥｘｐｅｃｔｅｄ構造を含む場合）、１０２０からの肯定の出口として示され、本方法は、特定された条件のそれぞれが満たされているかどうかを判定することを含んでもよい。

【0096】

この実施例で図示されるように、特定された条件のそれぞれは、要求において特定される更新を行う前に（１０３０の場合のように）評価されてもよい。所与の条件が満たされている（１０３０からの肯定の出口として示される）が、要求に対して特定された追加の条件がある（１０４０からの肯定の出口として示される）場合、追加の条件が評価されてもよい（１０４０から１０３０へのフィードバックとして示される）。所与の条件が満たされており（１０３０からの肯定の出口として示される）、要求に対して特定された追加の条件がない（１０４０からの否定の出口として示される）場合、１０５０の場合のように、要求された更新が行われてもよい。特定された条件のうちのいずれかが満たされていない場合、１０３０からの否定の出口として示され、要求された更新（複数可）が行われなくてもよい。

【0097】

この実施例で図示されるように、アイテムの属性の更新前および／または更新後値が出力されるべきであるとサービス要求が特定する場合、１０６０からの肯定の出口として示され、本方法は、１０７０の場合のように、アイテムの更新前および／または更新後属性値を返すことを含んでもよく、１０８０の場合のように、アイテム更新動作が完了してもよい。例えば、ＵｐｄａｔｅＩｔｅｍ要求のＲｅｔｕｒｎＶａｌｕｅｓパラメータが「Ａｌｌ＿Ｏｌｄ」、「Ｕｐｄａｔｅ＿Ｏｌｄ」、「Ａｌｌ＿Ｎｅｗ」、または「Ｕｐｄａｔｅｄ＿Ｎｅｗ」に設定された場合、対応する古いおよび／または新しい属性値が、アイテム更新プロセスの完了に応答して返されてもよい。ＲｅｔｕｒｎＶａｌｕｅｓパラメータが「Ｎｏｎｅ」に設定された、または要求に対して特定されていない場合、いかなる属性値も返されなくてもよい。特定された条件のうちのいずれかが満たされなかった場合、古いおよび／または新しい属性値のうちのいずれかが応答において返されるか否かにかかわらず、応答は、本明細書で説明されるもの等の１つ以上のエラー指示を含んでもよいことに留意されたい。対応する属性値上の可能なＡｃｔｉｏｎパラメータ値のそれぞれの仕様への応答が、一実施形態に従って以下の表で要約される。

【0098】

【表4】

【0099】

【表5】

【0100】

いくつかの実施形態では、スカラー属性の削除タイプ更新の属性値を供給することがエラーであり得ることに留意されたい。いくつかの実施形態では、セットタイプ属性の削除タイプ更新の空白セットを供給することがエラーであり得る。いくつかの実施形態では、セットタイプ属性の削除タイプ更新および／またはセットタイプ属性の追加タイプ更新の供給値（複数可）のタイプは、既存の値タイプに合致しなければならない。上記で説明されるように、ＡＤＤアクションは、数字タイプのスカラー属性のみに、またはセットタイプ属性のみに有効であり得、かつスカラー文字列タイプに無効であり得る。

【0101】

上記の表で示されるように、ＵｐｄａｔｅＩｔｅｍ要求によって標的にされるアイテムが存在せず、更新動作が少なくとも１つのＰＵＴまたはＡＤＤ Ａｃｔｉｏｎパラメータ値を用いて実行されるとき、いくつかの実施形態では、アイテムが作成されてもよい。しかしながら、ＵｐｄａｔｅＩｔｅｍ動作が存在しないアイテムを標的にし、ＤＥＬＥＴＥアクションのみを特定する場合、新しいアイテムは作成されないであろう。

【0102】

データ記憶サービスによって提供される他のＡＰＩと同様に、ＵｐｄａｔｅＩｔｅｍ要求および／または応答は、異なる実施形態では、ＪＳＯＮ要求／応答形式または別の好適な形式で提示されてもよい。ＵｐｄａｔｅＩｔｅｍ ＡＰＩに対応する、データ記憶サービスへの要求およびデータ記憶サービスから受信される応答の実施例が、一実施形態に従って以下で見出される。

要求形式例：
｛
ＵｐｄａｔｅＩｔｅｍ｛
“ＴａｂｌｅＮａｍｅ”：“Ｐｉｃｔｕｒｅｓ”，
“Ｋｅｙ”：［１，２００９−１２−１２Ｔ１０：３０：３０Ｚ］，
“ＡｔｔｒｉｂｕｔｅＵｐｄａｔｅｓ”：｛
“Ｔｉｔｌｅ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅ”：｛“Ｓ”：“Ｓｕｎ Ｆｌｏｗｅｒ”｝，“Ａｃｔｉｏｎ”：“ＰＵＴ”｝
“Ｔａｇｓ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅ”：｛“Ｓ”：［“Ｆｌｏｗｅｒ”，“Ｓｕｎ”］｝，“Ａｃｔｉｏｎ”：“ＡＤＤ”｝
｝，
“Ｅｘｐｅｃｔｅｄ”：｛
“Ｔｉｔｌｅ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅ”：｛“Ｓ”：“ｆｌｏｗｅｒ”｝｝，
“Ｒａｔｉｎｇ”：｛“Ｅｘｉｓｔｓ”：ｆａｌｓｅ｝
｝，
“ＲｅｔｕｒｎＶａｌｕｅｓ”：“ＵＰＤＡＴＥＤ＿ＮＥＷ”
｝
｝
応答形式例：
｛
“Ａｔｔｒｉｂｕｔｅｓ”：｛
“Ｔｉｔｌｅ”：｛“Ｓ”：“Ｓｕｎ Ｆｌｏｗｅｒ”｝
“Ｔａｇｓ”：｛“Ｓ”：“Ｆｌｏｗｅｒ”，“Ｓｕｎ”｝，

｝
｝

【0103】

この実施例では、特定更新は、Ｒａｔｉｎｇｓ属性の非存在、および「ｆｌｏｗｅｒ」であるＴｉｔｌｅ属性の値を条件とした。これらの条件の両方が真と評価されたという判定に応答して、特定更新がＴｉｔｌｅおよびＴａｇｓ属性に行われた。この実施例では、ＵｐｄａｔｅＩｔｅｍ要求が、Ｕｐｄａｔｅｄ＿Ｎｅｗに設定されたＲｅｔｕｒｎＶａｌｕｅｓパラメータを含んだことに留意されたい。したがって、応答は、特定更新動作によって標的にされた属性に定義された新しい値（すなわち、「Ｔｉｔｌｅ」属性および「Ｔａｇｓ」属性の新しい値）のみを含んだ。

【0104】

前述のように、一次キーが単純キーである実施形態では、記憶サービスクライアントの代わりに維持されているテーブルの中のアイテムが、アイテムのそれぞれの一次キー値のハッシュを使用して区分されてもよい一方で、一次キーが複合キーである実施形態では、データは、最初に、ハッシュキー構成要素のハッシュによって、次いで、範囲キー構成要素によって区分されてもよい。図１１は、一実施形態による、単純および／または複合キーを使用してテーブルデータを区分するための方法の一実施形態を図示する。１１１０で図示されるように、この実施例では、本方法は、データ記憶サービス（あるいは記憶ノードインスタンスまたは管理構成要素等のデータ記憶部を実装する基礎的システムの構成要素）が、記憶サービスクライアントの代わりに非リレーショナルデータ記憶部上に維持されたテーブルの区分を開始することを含んでもよい。

【0105】

テーブルの中の複数のアイテムがハッシュキー属性値を共有する場合、１１２０からの肯定の出口として示され、本方法は、１１４０の場合のように、データ記憶部が、最初に、それらの範囲キー属性値のハッシュに、次いで、それらの範囲キー属性値に依存して、所与のハッシュキー属性値を有するテーブルの中のアイテムを２つ以上の区分（例えば、データベース区分）に分割することを含んでもよい。言い換えれば、テーブルに対する一次キーが、値がアイテムのグループを識別するために使用され得る、ハッシュキー構成要素と、値が同一のハッシュキー属性値を有するアイテムを順序付け、これらのアイテムのそれぞれを一意的に識別するために使用され得る、範囲キー構成要素とを含む、複合キーである場合、ハッシュキー属性値および範囲キー属性値の両方は、テーブルの中のアイテムを区分するために使用されてもよい。例えば、同一のハッシュキー属性値を有するアイテムのグループについて、グループの中の最初のｎ個のアイテム（それらのそれぞれの範囲キー属性値によって順序付けられたとき）は、１つの区分に割り当てられてもよく、グループの中の次のｍ個のアイテムは、第２の区分に割り当てられても良い、等である。いくつかの実施形態では、各区分は、１つのハッシュキー属性値を共有するアイテムの一部分を含んでもよく、また、他のハッシュキー属性値を有する他のアイテムも含んでもよいことに留意されたい。

【0106】

テーブルの中のアイテムのうちのいずれもハッシュキー属性値を共有しない場合、１１２０からの否定の出口として示され、本方法は、１１３０の場合のように、データ記憶部が、それらのそれぞれのハッシュキー属性値に依存して、テーブルの中のアイテムを２つ以上の区分に分割することを含んでもよい。例えば、テーブルに対する一次キーが、値がテーブルの中のアイテムのそれぞれを一意的に識別するために使用され得る、ハッシュキー構成要素を含む、単純キーである場合、テーブルの中のアイテムは、ハッシュキー属性値のハッシュに依存するが、いかなる他のアイテム属性値にも依存せず、区分されてもよい（すなわち、複数の区分のうちの１つに割り当てられる）。いくつかの実施形態では、一次キーが複合キーであるが、テーブルの中のアイテムのうちのいずれもハッシュキー属性値を共有しない場合（すなわち、各アイテムが一意的なハッシュキー属性値を有する場合）、データ記憶部は、一次キーが単純キーであるかのようにアイテムを区分してもよい（すなわち、ハッシュキー属性値のみを使用して、テーブルの中のアイテムを区分してもよい）。

【0107】

いったんデータ記憶部がアイテムの全てを区分に割り当てると、１１５０の場合のように、データ記憶部は、それぞれの記憶ノード（例えば、それぞれのコンピューティングノードまたは記憶デバイス）上に区分のそれぞれを記憶してもよい。いくつかの実施形態では、単一のテーブルの各区分が、異なる記憶ノード上に記憶されてもよい一方で、他の実施形態では、区分のうちの２つ以上が、同一の記憶ノード上で維持されてもよい。いくつかの実施形態では、所与のテーブルのアイテムが区分される区分の数が、あらかじめ定められてもよい（例えば、ユーザ入力／選好、あるいはクライアント、アカウント、またはテーブルタイプの履歴データに基づいてもよい）一方で、他の実施形態では、所与のテーブルのアイテムが区分される区分の数は、例えば、ハッシュ結果の各範囲内のアイテムの数、および／または範囲キー属性値の各範囲内のアイテムの数に基づいて、区分動作が進行するにつれて判定されてもよいことに留意されたい。また、区分化がハッシュ結果に基づくため、アイテムのグループが利用可能な区分の間で割り当てられ、分配され得る順序は、いくぶんランダム化されてもよいことに留意されたい。場合によっては、例えば、いくつかのアイテムが、他のアイテムよりもはるかに頻繁にアクセスされる、またはいくつかのアイテムのグループが、他のグループよりも多数のアイテムを含む場合、初期区分化が、ホットスポットをもたらし得る。そのような場合において、（例えば、データ量および／またはサービス要求トラフィックに対して）利用可能な区分の間でアイテムをより均等に分配するために、再区分動作が行われてもよい。また、いくつかの実施形態では、テーブルの中のアイテムは、単一のハッシュキー構成要素および２つ以上の範囲キー構成要素を使用して区分されてもよいことに留意されたい。

【0108】

以下の表６は、図１１で図示されるものに類似する方法を使用した、テーブルの中のアイテムの区分化の実施例を図示する。この実施例では、ハッシュキー属性は、「Ｕｓｅｒ ｎａｍｅ」属性であり、範囲キー属性は、「Ｍｅｓｓａｇｅ ＩＤ」属性である。テーブルは、３つのユーザ名（Ｂｏｂ、Ｓｕｅ、およびＰｈｉｌ）のそれぞれと関連付けられる複数のメッセージを記憶する。表６で図示されるように、所与のテーブルのいくつかの区分は、同一のハッシュキー属性値を有するアイテムのみを含んでもよい。この実施例では、ＡというＰａｒｔｉｔｉｏｎ ＩＤ値によって識別される区分は、ハッシュキー属性値「Ｂｏｂ」を有するメッセージのみを記憶する。この区分は、Ｂｏｂのメッセージの全てではなく、Ｍｅｓｓａｇｅ ＩＤ値（すなわち、範囲キー属性値）１〜１９９を有するメッセージのみを記憶することに留意されたい。Ｂｏｂのメッセージの別のグループ（範囲キー属性値２００〜２９９を伴うもの）は、ＢというＰａｒｔｉｔｉｏｎ ＩＤ値によって識別される区分の中に記憶される。この区分はまた、「Ｓｕｅ」というハッシュキー属性値を有するメッセージ、具体的には、１〜５０という範囲キー値を有するメッセージも記憶する。Ｂｏｂのメッセージのさらに別のグループ（範囲キー属性値３００〜３９９を伴うもの）は、ＣというＰａｒｔｉｔｉｏｎ ＩＤ値によって識別される区分の中に記憶される。この区分はまた、「Ｐｈｉｌ」というハッシュキー属性値を有するメッセージ、具体的には、１〜１００という範囲キー値を有するメッセージも記憶する。

【0109】

【表6】

【0110】

上記の実施例では、Ｂｏｂのメッセージの全てを読み出す要求は、区分Ａからメッセージ１〜１９９（特定の記憶ノード上で維持され得る）、区分Ｂからメッセージ２００〜２９９（異なる記憶ノード上で維持され得る）、および区分Ｃからメッセージ３００〜３９９（さらに別の記憶ノード上で維持され得る）を読み出してもよい。以下でさらに詳細に説明されるように、いくつかの実施形態では、これらのメッセージの全てを読み出す要求は、（例えば、応答制限に達した場合）早く終了させられてもよく、残りのメッセージが、後続の要求に応答して読み出されてもよい。

【0111】

いくつかの実施形態では、本明細書で説明されるデータ記憶サービス（および／または基礎的システム）は、Ｓｃａｎ ＡＰＩおよびＱｕｅｒｙ ＡＰＩといった、記憶サービスクライアントの代わりにテーブルの中で維持されたデータを検索するための２つの異なるＡＰＩを提供してもよい。いくつかの実施形態では、Ｓｃａｎ ＡＰＩは、テーブル全体をスキャンする動作を要求するために使用されてもよい。Ｓｃａｎ要求は、例えば、完了したスキャンに続いて要求側に返される値を精緻化するように、スキャン動作の結果に適用される１つ以上のフィルタを特定してもよい。いくつかの実施形態では、サービス（および／または基礎的システム）は、スキャン結果に制限を課してもよく、制限は、結果がフィルタにかけられる前に適用されてもよい。例えば、いくつかの実施形態では、本システムは、スキャンおよび／またはクエリに迅速に応答するために、ページネーションを使用してもよい（例えば、評価または返されるアイテムの数に関して、あるいはスキャンまたは返されるデータの量に関して、所定の最大サイズを有する明確に異なる断片に、スキャンまたはクエリプロセスを分割する）。例えば、所定の最大サイズ（例えば、１ＭＢ）よりも大きい、または結果として生じるデータセットが所定の最大サイズ（例えば、１ＭＢ）よりも大きい、テーブルをスキャンするために、１ＭＢ増分で、テーブル全体をスキャンするように複数のスキャンまたはクエリ動作が行われる必要があり得る。いずれのテーブルデータも特定フィルタ条件を満たさない場合、スキャン動作が結果を返さない可能性があり得る。いくつかの実施形態では、Ｑｕｅｒｙ ＡＰＩは、供給されたクエリ条件（例えば、アイテムの属性への条件）に合致するデータに検索条件を限定するように、比較動作をサポートしてもよい。例えば、既定の制限まで（そのような制限がシステムによって課される場合）、要求において特定されるパラメータに合致するテーブルの中の全てのデータを見出すために、Ｑｕｅｒｙ要求が使用されてもよい。いくつかの実施形態では、Ｑｕｅｒｙ要求は、常に結果を返してもよいが、本システムは、クエリ条件（すなわち、属性フィルタ条件）が結果のうちのいずれにも合致しない場合に空白値を返してもよい。

【0112】

種々の実施形態では、Ｑｕｅｒｙ ＡＰＩは、テーブルに記憶された情報について、記憶サービスクライアント（例えば、ユーザ、顧客、加入者、またはクライアントアプリケーション）の代わりに維持されるそのテーブルに問い合わせるために使用されてもよい。いくつかの実施形態では、クエリは、一次インデックスに基づいて（特定ハッシュキー、場合によっては、特定範囲キー術語を満たす単一の範囲キー値に従って）行われてもよい。他の実施形態では、一次キーは、単一のハッシュキー構成要素、および２つ以上の範囲キー構成要素を含んでもよい。いくつかの実施形態では、Ｑｕｅｒｙ ＡＰＩの入力パラメータは、ＴａｂｌｅＮａｍｅ（更新されるアイテムが記憶される、またはアイテムが条件付きで挿入される、テーブルの名前を含む文字列であり得る）、ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔパラメータ（値が返される、属性の配列であり得る）、Ｌｉｍｉｔパラメータ（単一のクエリ要求に応答して返される結果の最大数を特定する整数であり得る）、ＣｏｎｓｉｓｔｅｎｔＲｅａｄパラメータ（一貫した読み取りが発行されるであろうかどうかを示すブール値であり得る）、Ｃｏｕｎｔパラメータ（これらのアイテムの属性値よりもむしろ、クエリに合致するアイテムのカウントが返されるべきかどうかを示す、ブール値であり得る）、ＨａｓｈＫｅｙＶａｌｕｅ（一次キーのハッシュ構成要素のＡｔｔｒｉｂｕｔｅＶａｌｕｅを特定し得る、かつクエリへの強制的制約であり得る）、ＲａｎｇｅＫｅｙＣｏｎｄｉｔｉｏｎ（一次キーのＲａｎｇｅＫｅｙ構成要素への制約を特定し得る、かつＨａｓｈＫｅｙＶａｌｕｅと組み合わせて、クエリ要求の１つまたは複数の標的を識別し得る）、ＳｃａｎＩｎｄｅｘＦｏｒｗａｒｄパラメータ（インデックスを前方に横断するか後方に横断するかどうかを示すブール値であり得る）、および／またはＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ（クエリが、単一のクエリ要求に応答して属性を返すことができるアイテム数への所定の制限を超えた、クエリの継続である場合、クエリの開始点として使用される一次キー値を特定し得る）を含んでもよい。

【0113】

いくつかの実施形態では、ＲａｎｇｅＫｅｙＣｏｎｄｉｔｉｏｎパラメータは、テーブルの中のアイテムの範囲キー構成要素の値に依存して評価される、数式または論理式を特定してもよい。ＲａｎｇｅＫｅｙＣｏｎｄｉｔｉｏｎパラメータは、ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒパラメータ、および１つ以上のＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを含んでもよい。例えば、一実施形態では、ＣｏｍｐａｒｉｔｉｏｎＯｐｅｒａｔｏｒは、「ＥＱ」（すなわち、〜に等しい）、「ＧＴ」（すなわち、〜よりも大きい）、「ＧＥ」（すなわち、〜以上）、「ＬＴ」（すなわち、〜未満）、「ＬＥ」（すなわち、〜以下）、「ＢＥＧＩＮＳ ＷＩＴＨ」、または「ＢＥＴＷＥＥＮ」等の演算子のうちの１つであってもよい。そのような実施形態では、ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが、「ＥＱ」、「ＧＴ」、「ＧＥ」、「ＬＴ」、「ＬＥ」、または「ＢＥＧＩＮＳ ＷＩＴＨ」のうちの１つである場合、１つだけの値がＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータに含まれてもよい一方で、ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが「ＢＥＴＷＥＥＮ」である場合、２つの値がＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータに含まれてもよい。いくつかの実施形態では、特定比較が、タイプ「文字列」を有する（例えば、２進文字列として表されるＵＴＦ８文字列を伴う）属性については辞書式で、およびタイプ「数字」を有する属性については数値的に行われてもよいことに留意されたい。いくつかの実施形態では、「ＢＥＴＷＥＥＮ」演算子に対して特定される２つの値は、包含的であり得、第１の値が第２の値よりも小さい。「ＢＥＧＩＮＳ ＷＩＴＨ」演算子は、スカラー文字列のみに有効である前置演算子であってもよい。

【0114】

ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔパラメータは、いくつかの実施形態では、それらの名前とともに属性タイプを含んでもよい。いくつかの実施形態では、属性名がクエリ要求に対して特定されていない場合（およびＣｏｕｎｔパラメータが「偽」である場合）、クエリ条件に合致するアイテムの全ての属性が返されてもよい。いくつかの実施形態では、Ｃｏｕｎｔパラメータが「真」である場合、クエリ要求に応答してデータ記憶システムによって返される合致アイテムの数へのいかなる既定の制限も適用されなくてもよい。Ｃｏｕｎｔパラメータを「真」に設定し、（単一のクエリ要求の中で）ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔのリストを提供することは、無効であり得、データ記憶システムがエラー指示（例えば、検証エラーの指示）を返してもよい。いくつかの実施形態では、ＣｏｎｓｉｓｔｅｎｔＲｅａｄパラメータが真に設定された場合、一貫した読み取り動作が発行されるであろう。そうでなければ、最終的に一貫した読み取り動作が行われるであろう。上述のように、単一のクエリ要求に合致するアイテムの数がＬｉｍｉｔパラメータの値を超える場合、クエリは、制限に達したときに終了させられてもよい。この場合、データ記憶システムは、最大でＬｉｍｉｔパラメータの値までの合致アイテムの数の属性値を返してもよく、（例えば、後続のクエリ要求の入力として、このＬａｓｔＥｖａｌｕａｔｅｄＫｅｙを含むことによって）クエリを継続するために使用され得る、継続トークン（すなわち、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ）を含んでもよい。いくつかの実施形態では、データ記憶システムは、Ｑｕｅｒｙ ＡＰＩを使用したクエリ要求に応答して返される合致アイテムの数へのシステム全体の制限、および／または合致アイテムの数への要求特有の制限をサポートしてもよい（すなわち、上記で説明されるＬｉｍｉｔパラメータを使用する）ことに留意されたい。いくつかのそのような実施形態では、これらの制限のうちのいずれか一方が満たされたときに（例えば、要求特有の制限を満たす前にシステム全体の制限が満たされた場合、またはその逆も同様）、クエリが終了させられ、継続トークンが要求側に返されてもよい。

【0115】

いくつかの実施形態では、Ｑｕｅｒｙ要求のリターンパラメータは、Ｉｔｅｍｓパラメータ（特定されたクエリ条件に合致する、アイテムのリストおよび／またはそれらの関連属性値を含み得る）、Ｃｏｕｎｔパラメータ（応答においてアイテムの数を示し得る）、および／またはＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ（上記で説明されるように、単一のクエリ要求に応答して情報を返すことができる、アイテムの数への所定の制限に達する前に、クエリ中に評価される最後のアイテムの一次キー値を特定し得る）。上述のように、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙは、単一のクエリ要求に応答して情報を返すことができる、アイテムの数への所定の制限を超えた場合に、クエリの継続における開始点として使用されてもよい。いくつかの実施形態では、Ｃｏｕｎｔパラメータは、常に、合致アイテム（および／またはそれらの属性）も返されるかどうかにかかわらず、Ｑｕｅｒｙ ＡＰＩへの応答において返されてもよいことに留意されたい。データ記憶サービスによって提供される他のＡＰＩと同様に、Ｑｕｅｒｙ要求および／または応答は、異なる実施形態では、ＪＳＯＮ要求／応答形式または別の好適な形式で提示されてもよい。Ｑｕｅｒｙ ＡＰＩに対応する、データ記憶サービスへの要求およびデータ記憶サービスから受信される応答の実施例が、一実施形態に従って以下で見出される。以下の実施例は、一実施形態による、「＊＊＊」から「＊＊＊＊」の間の評定を有する、１人の顧客（すなわち、ＣｕｓｔｏｍｅｒＩｄが「１２３４５６７８」である顧客）のために、「Ｐｉｃｔｕｒｅｓ」と呼ばれるテーブルから全てのアイテムを読み出すために使用され得るクエリ、およびそのクエリ要求への応答を図示する。

要求形式例：
｛
Ｑｕｅｒｙ｛
“ＴａｂｌｅＮａｍｅ”：“Ｐｉｃｔｕｒｅｓ”，
“ＱｕｅｒｙＦｉｌｔｅｒ”：｛
“ＣｕｓｔｏｍｅｒＩｄ”：（“ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓ”：［｛“Ｓ”：“１２３４５６７８”｝］，
“ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ”：“ＥＱ”｝，
“Ｒａｔｉｎｇｓ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓ”：［｛“Ｓ”：“＊＊＊”｝，｛“Ｓ”：“＊＊＊＊”｝
“ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ”：“ＢＥＴＷＥＥＮ”｝｝
｝
｝
｝

応答形式例：
｛
“Ｉｔｅｍｓ”：［｛“ＣｕｓｔｏｍｅｒＩｄ”：｛“Ｓ”：“１２３４５６７８”｝，
“Ｔｉｔｌｅ”：｛“Ｓ”：“ｓｕｎ ｆｌｏｗｅｒ”｝，
“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｓ”：“２０１００２０５Ｔ００：００：００Ｚ”｝，
“Ｒａｔｉｎｇｓ”：｛“Ｓ”：“＊＊＊”｝｝，
｛“ＣｕｓｔｏｍｅｒＩｄ”：｛“Ｓ”：“１２３４５６７８”｝，
“Ｔｉｔｌｅ”：｛“Ｓ”：“ｊａｓｍｉｎｅ”｝，
“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｄ”：“２０１００２０６Ｔ００：００：００Ｚ”｝，
“Ｒａｔｉｎｇｓ”：（“Ｓ”：“＊＊＊＊”｝｝，
｛“ＣｕｓｔｏｍｅｒＩｄ”：｛“Ｓ”：“１２３４５６７８”｝，
“Ｔｉｔｌｅ”：｛“Ｓ”：“ｌｕｐｉｎｅ”｝，
“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｄ”：“２０１００３０１Ｔ００：００：００Ｚ”｝，
“Ｒａｔｉｎｇｓ”：｛“Ｓ”：“＊＊＊”｝｝
］，
“Ｃｏｕｎｔ”：３，
“ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙ”：［｛“Ｓ”：“１２３４５６７８”｝，｛“Ｓ”：“＊＊＊”｝］
｝

【0116】

本明細書で説明されるＡＰＩによって特定されるように、クエリを行うための方法の一実施形態が、図１２でフロー図によって図示されている。１２１０で図示されるように、この実施例では、本方法は、非リレーショナルデータベース内のテーブル（例えば、データ記憶サービスクライアントの代わりに維持されるテーブル）の中の１つ以上のアイテムを対象とする、クエリを行うサービス要求を受信することを含んでもよい。以前の実施例の場合のように、要求は、テーブル名（クエリ要求の標的であるテーブルを識別し得る）および一次キー値を含んでもよい。特定一次キー値が、単一の属性ハッシュキー値である場合（すなわち、識別されたテーブルに対する一次キーが、単一の属性の値に依存する単純一次キーである場合）、クエリは、テーブル名および一次キー値の組み合わせによって一意的に識別される、単一のアイテムを標的にしてもよい。この場合、１２２０からの肯定の出口として示され、本方法は、特定されたハッシュキー値に依存して、そのアイテムを含むテーブルの単一の区分にクエリをダイレクトすることを含んでもよい。この場合、本方法はまた、１２５０の場合のように、識別された単一のアイテムの１つ以上の属性値を含む応答を返すことを含んでもよい。

【0117】

特定一次キー値が、複合キー値である場合（すなわち、識別されたテーブルに対する一次キーが、ハッシュキー値および範囲キー値に依存する複合一次キーである場合）、クエリは、本明細書で説明されるように、特定されたハッシュキー値および特定された範囲キー条件に合致する、１つまたは複数のアイテムを標的にしてもよい。この実施例では、要求が、ハッシュキー属性値および単一の範囲キー属性値を特定する場合（例えば、要求が、範囲キー値が特定の値に等しいことを特定する、範囲キー条件を含む場合）、１２４０からの肯定の出口として示され、本方法は、再度、１２５０の場合のように、特定されたハッシュキー値に依存して、そのアイテムを含むテーブルの単一の区分にクエリをダイレクトし、識別された単一のアイテムの１つ以上の属性値を含む応答を返してもよい。

【0118】

この実施例では、要求が、ハッシュキー属性値、および複数の範囲キー属性値に合致し得る範囲キー条件を特定する場合、１２４０からの否定の出口として示され、本方法は、１２６０の場合のように、特定されたハッシュキー値および範囲キー条件に依存して、テーブルの１つ以上の区分にクエリをダイレクトすることを含んでもよい。例えば、特定されたハッシュキー値に合致するアイテムのうちのいくつか（例えば、範囲キー値が所与の範囲内に入るアイテム）が、テーブルの１つの区分上で記憶されるが、特定されたハッシュキーに合致する他のアイテム（例えば、範囲キー値が異なる範囲内に入るアイテム）が、テーブルの別の区分上に記憶される場合、特定されたハッシュキー値および特定された範囲キー条件の両方に合致するアイテムの全てを識別するために、クエリは、複数の区分（場合によっては、区分がホストされる複数のマシン）を対象としてもよい。この場合、本方法は、１２７０の場合のように、ハッシュキー値および範囲キー条件の両方に合致する１つ以上のアイテムの１つ以上の属性値を含む、応答を返すことを含んでもよく、ハッシュキー値および範囲キー条件の両方に合致する１つ以上のアイテムのうちのいくつかは、異なる区分（場合によっては、異なるマシン）から読み出されてもよい。

【0119】

単一のアイテムを対象とするクエリ（例えば、１２４０からの肯定の出口の場合のように、単純一次キーのハッシュキー値を特定する、またはハッシュキー値および単一の範囲キー値を特定するもの）は、パラメータの数およびタイプのいくらかの変動がサポートされた状態で、対応するＧｅｔＩｔｅｍ要求のものと類似する機能性を実装してもよいことに留意されたい。いくつかの実施形態では、（上記で説明されるような）ＧｅｔＩｔｅｍ ＡＰＩの機能性が、Ｑｕｅｒｙ ＡＰＩによって提供されてもよい一方で、他の実施形態では、本明細書で説明されるＧｅｔＩｔｅｍ機能性および本明細書で説明されるＱｕｅｒｙ機能性は、異なるＡＰＩ（例えば、ＧｅｔＩｔｅｍ ＡＰＩおよびＱｕｅｒｙ ＡＰＩ）によって提供されてもよい。

【0120】

一実施形態によると、本明細書で説明されるＡＰＩによって特定されるように、クエリを行うための方法のさらに詳細な実施例が、図１３でフロー図によって図示されている。１３１０で図示されるように、この実施例では、本方法は、非リレーショナルデータベース内のテーブル（例えば、データ記憶サービスクライアントの代わりに維持されるテーブル）の中の１つ以上のアイテムを対象とする、クエリを行うサービス要求を受信することを含んでもよい。以前の実施例の場合のように、要求は、テーブル名（クエリの標的であるテーブルを識別し得る）および一次キー値を含んでもよい。この実施例では、特定された一次キー値は、複合キー値であり（すなわち、識別されたテーブルに対する一次キーは、ハッシュキー値および範囲キー値に依存する複合一次キーである）、クエリは、本明細書で説明されるように、要求において特定されるハッシュキー値および範囲キー条件に合致する複数のアイテムを標的にしてもよい。１３２０で図示されるように、本方法は、要求において特定されるハッシュおよび範囲値を判定するように要求を解析することを含んでもよい。

【0121】

本方法は、１３３０の場合のように、特定されたハッシュおよび範囲値に依存して、クエリの初期標的を含む区分にクエリをダイレクトし、その区分からクエリの１つ以上の標的に関する情報（例えば、クエリによって標的にされるアイテムの属性値）を読み出すことを含んでもよい。例えば、いくつかの実施形態では、特定のハッシュキー値に合致するアイテムが、それらの範囲キー値によって、テーブルの中で順序付けられてもよい。そのような実施形態では、特定されたハッシュキー値および特定された範囲キー条件に合致する第１の範囲キー値の組み合わせは、クエリ条件に合致するテーブルの中の第１のアイテムを一意的に識別してもよい。そのような実施形態では、クエリは、最初に、この組み合わせによって識別されるアイテムを含有する区分を対象としてもよい。場合によっては、特定されたハッシュキー値および特定された範囲キー条件に合致する、１つ以上の追加のアイテムが、クエリが対象とする第１の区分上に存在してもよく、これらの標的の全て（すなわち、アイテム自体および／またはそれらの属性値の特定サブセット）が、クエリに応答して返されてもよい。

【0122】

場合によっては、特定されたハッシュキー値および特定された範囲キー条件の両方に合致するアイテムのうちのいくつかが、クエリが対象とした第１の区分以外のテーブルの１つ以上の区分上に記憶されてもよい。該当する場合、１３４０からの否定の出口として示され、１３５０の場合のように、クエリが１つ以上の他の区分を対象としてもよく、これらの追加のクエリ標的が読み出されてもよい。例えば、特定されたハッシュキー値および特定された範囲キー条件の両方に合致するアイテムの数は、テーブルの各区分の中に記憶されたアイテムの数よりも大きくてもよい。別の実施例では、（例えば、アイテムが特定の順序で選別され、それらの範囲キー値に従って特定の区分に割り当てられる実施形態において）アイテムがテーブルの中で選別されて記憶され、および／または種々の区分に割り当てられる順序により、標的アイテムは、区分境界を越えてもよい。これらおよび他の場合において、本方法は、１３７０の場合のように、ハッシュキー値および範囲キー条件に合致する１つ以上のアイテムの１つ以上の属性値を含む、応答を返すことを含んでもよく、ハッシュキー値および範囲キー条件の両方に合致する１つ以上のアイテムのうちのいくつかは、異なる区分（場合によっては、異なる物理的コンピューティングノードまたは記憶デバイス）から読み出されてもよい。

【0123】

しかしながら、図１３で図示されるように、特定されたハッシュキー値および特定された範囲キー条件の両方に合致するアイテムの全てが、クエリが対象とした第１の区分上に記憶される場合、１３４０からの肯定の出口として示され、本方法は、１３６０の場合のように、ハッシュキー値および範囲キー条件の両方に合致する１つ以上のアイテムの１つ以上の属性値を含む、応答を返すことを含んでもよく、ハッシュキー値および範囲キー条件の両方に合致する１つ以上のアイテムの全ては、最初に標的にされた区分（したがって、単一の物理的コンピューティングノードまたは記憶デバイス）から読み出される。

【0124】

Ｑｕｅｒｙ ＡＰＩの使用は、以下の実施例を介して（すなわち、以下の擬似コードによって）さらに例証されてもよい。第１の実施例では、単語「Ｔｈｅ」で始まり、単一の顧客ＩＤ番号と関連付けられる、テーブルに記憶された映画の題名の全てを読み出すために、テーブルにクエリ動作を行うように、要求が行われる。この実施例は、属性「ＩＤ」および「ｍｏｖｉｅ ｔｉｔｌｅｓ」に基づく、複合一次キーを伴うテーブルを仮定する。このＱｕｅｒｙ要求は、「Ｔｈｅ」で始まる範囲値（すなわち、「Ｔｈｅ」で始まる映画の題名）を有する、一次ハッシュ値２（例えば、顧客ＩＤ＝２）について、全てのアイテムを読み出すために使用されてもよい。

ｒｅｓｕｌｔｓ＝Ｑｕｅｒｙ（‘ｈａｓｈｒａｎｇｅ−ｔａｂｌｅ’，ａｒｒａｙ（ＮＵＭＢＥＲ＝＞２），ａｒｒａｙ（
‘ＲａｎｇｅＫｅｙＣｏｎｄｉｔｉｏｎ’＝＞ａｒｒａｙ（
‘ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ’＝＞ＢＥＧＩＮＳ＿ＷＩＴＨ，
‘ＡｔｔｒｉｂｕｔｅＶａｌｕｅＬｉｓｔ’＝＞ａｒｒａｙ（ａｒｒａｙ（ＳＴＲＩＮＧ＝＞“Ｔｈｅ”））
）
））；

【0125】

上述のように、いくつかの実施形態では、（フィルタにかける前に）単一のクエリによって返されるアイテムの数は、（例えば、１ＭＢのデータに）限定されてもよい。そのような実施形態では、クエリが１ＭＢよりも多くのデータを返す必要がある場合、最後に返された値を伴うアイテムの一次キーに基づいて、第２のクエリが設定されてもよい。Ｑｕｅｒｙ ＡＰＩは、第２のクエリの開始点として、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータにおいて返される値を使用してもよい。例えば、途切れたクエリによって返されるＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ値が、変数に記憶され、Ｅｘｃｌｕｓｉｖｅ ＳｔａｒｔＫｅｙ入力パラメータ値として次のクエリに提供されてもよい。以下の擬似コード例が、この一連の動作を例証する。

／／ｆｉｒｓｔ ｑｕｅｒｙ
ｒｅｓｕｌｔｓ＝ｑｕｅｒｙ（‘ｈａｓｈｒａｎｇｅ−ｔａｂｌｅ’，ａｒｒａｙ（ＮＵＭＢＥＲ＝＞１），ａｒｒａｙ（‘Ｌｉｍｉｔ’＝＞２））；

／／ｒｅｔｒｉｅｖｅ ｔｈｅ ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙ
ｌａｓｔＥｖａｌｕａｔｅｄＫｅｙ＝ｒｅｓｕｌｔｓ−＞ｂｏｄｙ−＞ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙ；

／／ｃｒｅａｔｅ ＥｘｃｌｕｓｉｖｅＳｔａｒｔＫｅｙ
ｅｘｃｌｕｓｉｖｅＳｔａｒｔＫｅｙ＝ａｒｒａｙ（‘ＨａｓｈＫｅｙＥｌｅｍｅｎｔ’＝＞ａｒｒａｙ（ＮＵＭＢＥＲ＝＞
（ｉｎｔ）ｌａｓｔＥｖａｌｕａｔｅｄＫｅｙ−＞ＨａｓｈＫｅｙＥｌｅｍｅｎｔ−＞Ｎ），
‘ＲａｎｇｅＫｅｙＥｌｅｍｅｎｔ’＝＞ａｒｒａｙ（ＳＴＲＩＮＧ＝＞
（ｓｔｒｉｎｇ）ｌａｓｔＥｖａｌｕａｔｅｄＫｅｙ−＞ＲａｎｇｅＫｅｙＥｌｅｍｅｎｔ−＞Ｓ）
）；

／／ｐｅｒｆｏｒｍ ａｎｏｔｈｅｒ ｑｕｅｒｙ ｐｒｏｖｉｄｉｎｇ ｔｈｅ ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙ ａｓ ｔｈｅ ＥｘｃｌｕｓｉｖｅＳｔａｒｔＫｅｙ
／／ｆｏｒ ｔｈｅ ｓｅｃｏｎｄ ｑｕｅｒｙ
ｒｅｓｕｌｔｓ＝ｑｕｅｒｙ（‘ｈａｓｈｒａｎｇｅ−ｔａｂｌｅ’，
ａｒｒａｙ（ＮＵＭＢＥＲ＝＞１），
ａｒｒａｙ（‘Ｌｉｍｉｔ’＝＞２，
‘ＥｘｃｌｕｓｉｖｅＳｔａｒｔＫｅｙ’＝＞ＥｘｃｌｕｓｉｖｅＳｔａｒｔＫｅｙ）
）；

【0126】

本明細書で示されるように、複合一次キーは、ハッシュおよび範囲インデックスとしてインデックス作成されてもよい。このマルチパートキーは、第１および第２のインデックス値の間の階級を維持してもよい。例えば、表７として以下で例証されるアドレステーブルは、アドレステーブルの中の各アイテムを識別するために、ハッシュ値としての顧客のＵｓｅｒＩＤ、およびアドレスが範囲としてテーブルに入力された年を使用する。テーブルの中の全ての入力が、ＵｓｅｒＩＤおよび年を有さなければならない一方で、各ＵｓｅｒＩＤ／年の複合キーは、任意の一式の他の属性を有することができる。

【0127】

【表7】

【0128】

この実施例では、ＵｓｅｒＩＤは、ハッシュインデックスであり、同等性についての（すなわち、値の正確な合致についての）比較のみをサポートする。この実施例では、年は、範囲インデックスである。したがって、テーブルにクエリを行うときに検索を制約するように、種々の比較演算子が、年に適用されてもよい。例えば、Ｑｕｅｒｙ要求は、２０１０より前の年についてＢｏｂのアドレス情報の全てを読み出すために使用されてもよい（すなわち、Ｙｅａｒ属性値が２０１０未満であるという条件を特定するクエリ）。そのようなクエリは、表７の第５および第６の入力で示されるように、２００９年および２００４年についてＢｏｂのアドレス情報を返すであろう。以下で例証される表８等の他のテーブルについては、範囲キーは、映画の題名等の文字列タイプ属性であってもよいことに留意されたい。この実施例では、テーブルは、それらのＴｉｔｌｅ属性値の値（すなわち、それらの範囲キー値）によってアルファベット順で、同一のＵｓｅｒＩＤを有するアイテムを選別してもよく、各ＵｓｅｒＩＤ／Ｔｉｔｌｅペアは、テーブルの中の単一のアイテムを一意的に識別してもよい。

【0129】

【表8】

【0130】

種々の実施形態では、Ｓｃａｎ ＡＰＩは、テーブルにわたって完全スキャンを行うことによって、記憶サービスクライアントの代わりにテーブルの中に記憶された１つ以上のアイテムおよび属性を読み出すために使用されてもよい。返されるアイテムは、フィルタを特定することによって限定されてもよい。いくつかの実施形態では、Ｓｃａｎ ＡＰＩは、上記で説明されるＱｕｅｒｙ ＡＰＩよりも豊富なセマンティックスをサポートしてもよい。例えば、それは、「ＣＯＮＴＡＩＮＳ」、「ＩＳ ＮＵＬＬ」、「ＩＮ」等の比較演算子をサポートしてもよい。

【0131】

いくつかの実施形態では、Ｓｃａｎ ＡＰＩの入力パラメータは、上記で説明されるＱｕｅｒｙ ＡＰＩに対してサポートされる同一の入力パラメータのうちのいくつかを含んでもよい。例えば、入力パラメータは、ＴａｂｌｅＮａｍｅ（更新されるアイテムが記憶される、またはアイテムが条件付きで挿入される、テーブルの名前を含む文字列であり得る）、ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔパラメータ（値が返される、属性の配列であり得る）、Ｌｉｍｉｔパラメータ（単一のクエリ要求に応答して返される結果の最大数を特定する整数であり得る）、Ｃｏｕｎｔパラメータ（これらのアイテムの属性値よりもむしろ、クエリに合致するアイテムのカウントが返されるべきかどうかを示す、ブール値であり得る）、および／またはＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ（スキャン動作が、単一のＳｃａｎ要求に応答して情報を返すことができるアイテム数への所定の制限を超えた、スキャン動作の継続である場合、スキャン動作の開始点として使用される一次キー値を特定し得る）を含んでもよい。Ｓｃａｎ ＡＰＩ入力パラメータはまた、結果セットに適用されるフィルタを特定し得る、ＳｃａｎＦｉｌｔｅｒパラメータを含んでもよい。ＳｃａｎＦｉｌｔｅｒは、以下で説明されるように、１つ以上のＡｔｔｉｂｕｔｅＮａｍｅ値を対応するＳｃａｎＣｏｎｄｉｔｉｏｎ構造にマップしてもよい。いくつかの実施形態では、特定されたスキャン条件の全ては、アイテムがフィルタに合致し、結果セットに含まれるために、満たされる必要があり得る。

【0132】

いくつかの実施形態では、各ＳｃａｎＣｏｎｄｉｔｉｏｎ構造は、合致する条件を特定してもよく、対応するＡｔｔｒｉｂｕｔｅｓＶａｌｕｅｓパラメータは、スキャン条件との比較が行われるであろう、属性値のリストを含んでもよい。いくつかの実施形態では、スキャン条件は、「ＥＱ」（すなわち、〜に等しい）、「ＮＥ」（すなわち、〜に等しくない）、「ＧＴ」（すなわち、〜よりも大きい）、「ＧＥ」（すなわち、〜以上）、「ＬＴ」（すなわち、〜未満）、「ＬＥ」（すなわち、〜以下）、「ＮＯＴ ＮＵＬＬ」（すなわち、属性が存在する）、「ＮＵＬＬ」（すなわち、属性が存在しない）、「ＣＯＮＴＡＩＮＳ」（すなわち、多値属性が特定値を含有する）、「ＮＯＴ ＣＯＮＴＡＩＮＳ」（すなわち、多値属性が特定値を含有しない）、「ＢＥＧＩＮＳ ＷＩＴＨ」、「ＩＮ」（すなわち、属性が特定値のうちの１つに合致する）、または「ＢＥＴＷＥＥＮ」等の値のうちの１つを有する、ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒパラメータを使用して特定されてもよい。いくつかの実施形態では、ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが、「ＥＱ」、「ＧＴ」、「ＧＥ」、「ＬＴ」、「ＬＥ」、または「ＢＥＧＩＮＳ ＷＩＴＨ」のうちの１つである場合、単一のスカラー値がＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータに含まれてもよい。ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが「ＩＮ」である場合、特定属性値の全てが、スカラーおよび同一タイプであってもよい。ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが「ＢＥＴＷＥＥＮ」である場合、２つの値がＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータに含まれてもよい。ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが「ＣＯＮＴＡＩＮＳ」または「ＮＯＴ ＣＯＮＴＡＩＮＳ」である場合、ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータは、多値またはスカラー文字列であってもよい（例えば、スカラー文字列属性については、比較が部分文字列合致の検索に変換してもよい）。ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒが「ＮＵＬＬ」または「ＮＯＴ ＮＵＬＬ」である場合、ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータは、空白（または空値）であってもよく、ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓパラメータの任意の値を提供することにより、エラー指示の返信をもたらし得る。いくつかの実施形態では、特定比較が、タイプ「文字列」を有する（例えば、２進文字列として表されるＵＴＦ８文字列を伴う）属性については辞書式で、およびタイプ「数字」を有する属性については数値的に行われてもよいことに留意されたい。いくつかの実施形態では、「ＢＥＴＷＥＥＮ」演算子に対して特定される２つの値は、包含的であり得、第１の値が第２の値よりも小さい。「ＢＥＧＩＮＳ ＷＩＴＨ」演算子は、スカラー文字列のみに有効である前置演算子であってもよい。

【0133】

ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔパラメータは、いくつかの実施形態では、それらの名前とともに属性タイプを含んでもよい。いくつかの実施形態では、属性名がスキャン要求に対して特定されていない場合（およびＣｏｕｎｔパラメータが「偽」である場合）、スキャン条件に合致するアイテムの全ての属性が返されてもよい。いくつかの実施形態では、Ｃｏｕｎｔパラメータが「真」である場合、スキャン要求に応答してデータ記憶システムによって返される合致アイテムの数へのいかなる既定の制限も適用されなくてもよい。Ｃｏｕｎｔパラメータを「真」に設定し、（単一のスキャン要求の中で）ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔのリストを提供することは、無効であり得、データ記憶システムがエラー指示（例えば、検証エラーの指示）を返してもよい。上述のように、単一のスキャン要求に合致するアイテムの数がＬｉｍｉｔパラメータの値を超える場合、スキャン動作は、制限に達したときに終了させられてもよい。この場合、データ記憶システムは、最大でＬｉｍｉｔパラメータの値までの合致アイテムの数の属性値を返してもよく、（例えば、後続のスキャン要求の入力として、このＬａｓｔＥｖａｌｕａｔｅｄＫｅｙを含むことによって）スキャン動作を継続するために使用され得る、継続トークン（すなわち、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ）を含んでもよい。いくつかの実施形態では、データ記憶システムは、Ｓｃａｎ ＡＰＩを使用したスキャン要求に応答して返される合致アイテムの数へのシステム全体の制限、および／または合致アイテムの数への要求特有の制限をサポートしてもよい（すなわち、上記で説明されるＬｉｍｉｔパラメータを使用する）ことに留意されたい。いくつかのそのような実施形態では、これらの制限のうちのいずれか一方が満たされたときに（例えば、要求特有の制限を満たす前にシステム全体の制限が満たされた場合、またはその逆も同様）、スキャン動作が終了させられ、継続トークンが要求側に返されてもよい。

【0134】

いくつかの実施形態では、上記で説明されるように、Ｓｃａｎ要求に応答して行われるスキャンプロセスは、一貫した読み取り動作ではなくてもよいことに留意されたい。言い換えれば、スキャンが行われている間にすでに「スキャンされている」データの変更は、スキャン結果に含まれなくてもよい。一方で、上記で説明されるように、Ｑｕｅｒｙ要求に応答して行われるクエリ動作は、デフォルトで、最終的に一貫した読み取り動作であってもよく、かつクエリが一貫した読み取り動作として行われるべきであることを指定するオプションをサポートしてもよい。最終的に一貫した読み取り動作は、場合によっては、最近完了したＰｕｔＩｔｅｍまたはＵｐｄａｔｅＩｔｅｍ動作の結果を反映しない場合があることに留意されたい。

【0135】

いくつかの実施形態では、Ｓｃａｎ要求のリターンパラメータは、Ｉｔｅｍｓパラメータ（それぞれが特定されたスキャン条件に合致する属性値のマップを含む、アイテムの配列を含み得る）、Ｃｏｕｎｔパラメータ（応答において表されるアイテムの数を示し得る）、ＳｃａｎｎｅｄＣｏｕｎｔパラメータ（Ｓｃａｎ要求に応答してスキャンされるアイテムの数を示し得る）、および／またはＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ（上記で説明されるように、単一のスキャン要求に応答して属性が返される、アイテムの数への所定の制限に達する前に、スキャン動作中に評価される最後のアイテムの一次キー値を特定し得る）を含んでもよい。上述のように、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータの値は、単一のスキャン要求に応答して情報を返すことができる、アイテムの数への所定の制限を超えた場合に、スキャン動作の継続における開始点として使用されてもよい。いくつかの実施形態では、Ｃｏｕｎｔパラメータは、常に、合致アイテム（および／またはそれらの属性）も返されるかどうかにかかわらず、Ｓｃａｎ ＡＰＩに対する応答において返されてもよいことに留意されたい。

【0136】

データ記憶サービスによって提供される他のＡＰＩと同様に、Ｓｃａｎ要求および／または応答は、異なる実施形態では、ＪＳＯＮ要求／応答形式または別の好適な形式で提示されてもよい。Ｓｃａｎ ＡＰＩに対応する、データ記憶サービスへの要求およびデータ記憶サービスから受信される応答の実施例が、一実施形態に従って以下で見出される。以下の実施例は、一実施形態による、「２００９−１２−１２Ｔ１０：３０：３０Ｚ」の後に作成され、かつ「＊」または「＊＊＊＊＊」という評定（例えば、利用可能な最高および最悪の評定値）を有する、「Ｐｉｃｔｕｒｅｓ」と呼ばれるテーブルに記憶された全てのアイテムの題名および作成日を読み出すために使用され得る、スキャン要求、および対応する応答を例証する。

要求形式例：
｛
“ＴａｂｌｅＮａｍｅ”：“Ｐｉｃｔｕｒｅｓ”，
“ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔ”：［“Ｔｉｔｌｅ”，“ＤａｔｅＣｒｅａｔｅｄ”］，
“ＭａｘＩｔｅｍｓＴｏＳｃａｎ”：１０００，
“Ｆｉｌｔｅｒ”：｛
“ＤａｔｅＣｒｅａｔｅｄ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓ”：［｛“Ｓ”：“２００９−１２−１２Ｔ１０：３０：３０Ｚ”｝］，
“ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ”：“ＧＴ”｝，
“Ｒａｔｉｎｇ”：｛“ＡｔｔｒｉｂｕｔｅＶａｌｕｅｓ”：［｛“Ｓ”：“＊”｝，｛“Ｓ”：“＊＊＊＊＊”｝］，
“ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ”：“ＩＮ”｝
｝
｝
｝
応答形式例：
｛
“Ｉｔｅｍｓ“：［
｛“Ｔｉｔｌｅ”：｛“Ｓ”：“ｓｕｎ ｆｌｏｗｅｒ”｝，“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｓ”：“２０１００２０５Ｔ００：００：００Ｚ”｝｝，
｛“Ｔｉｔｌｅ”：｛“Ｓ”：“ｊａｓｍｉｎｅ”｝，“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｓ”：“２０１００２０６Ｔ００：００：００Ｚ”｝｝，
｛“Ｔｉｔｌｅ”：｛“Ｓ”：“ｌｕｐｉｎｅ”｝，“ＤａｔｅＣｒｅａｔｅｄ”：｛“Ｄ”：“２０１００３０１Ｔ００：００：００Ｚ”｝｝，
］，
］，
“Ｃｏｕｎｔ”：３，
“ＳｃａｎｎｅｄＣｏｕｎｔ”：２００，
“ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙ”：［｛“Ｓ”：“ｓｏｍｅ−ｃｕｓｔｏｍｅｒ”｝，｛“Ｓ”：“Ｄａｆｆｏｄｉｌｓ”｝］
｝

【0137】

本明細書で説明されるＳｃａｎ ＡＰＩによって定義されるもの等のテーブルスキャン動作を行うための方法の一実施形態が、図１４でフロー図によって図示されている。いくつかの実施形態では、テーブル全体をスキャンすることは、２つ以上の物理的コンピューティングノードまたは記憶デバイス上でホストされ得る、２つ以上の区分をスキャンすることを伴ってもよいことに留意されたい。１４１０で図示されるように、この実施例では、本方法は、非リレーショナルデータベース内のテーブル（例えば、データ記憶サービスクライアントの代わりに維持されるテーブル）をスキャンし、１つ以上のアイテムおよび／またはそれらの属性を返すサービス要求を受信することを含んでもよい。以前の実施例の場合のように、スキャン要求は、テーブル名（スキャン要求の標的であるテーブルを識別し得る）を含んでもよい。要求はまた、値が返される１つ以上の属性、および／またはスキャン動作の結果がフィルタにかけられる、または選別される、１つ以上の条件を特定してもよい。要求がフィルタ基準を特定する場合、１４２０からの肯定の出口として示され、本方法は、１４３０の場合のように、テーブルをスキャンし、フィルタ基準に対してアイテムを評価することを含んでもよい。上記で説明されるように、フィルタ基準は、テーブルの中のアイテムの種々の属性の値、条件、または値の範囲を特定してもよい。アイテムの属性値が特定フィルタ条件を満し（１４４０からの肯定の出口として示される）、要求が、値が応答において返される、１つ以上の属性を特定する（１４５０からの肯定の出口として示される）場合、アイテムにおける特定属性の値が、１４６０の場合のように、スキャン要求に対する結果セットに含まれてもよい。

【0138】

アイテムの属性値が特定フィルタ条件を満たす（１４４０からの肯定の出口として示される）が、要求が、値が応答において返される、いかなる属性も特定しない（１４５０からの否定の出口として示される）場合、アイテムにおける属性の全ての値が、１４７０の場合のように、スキャン要求に対する結果セットに含まれてもよい。アイテムの属性値が特定フィルタ条件を満たさない場合、１４４０からの否定の出口として示され、アイテム（すなわち、その属性値）は、スキャン要求に対する結果セットに含まれなくてもよい。処理されるアイテムがさらにあり（すなわち、スキャンされる、および／または特定フィルタ基準に対して評価されるアイテムがさらにあり）、スキャン制限（例えば、スキャンすることができる、または単一のスキャン要求に応答して結果を返すことができる、アイテムの数への所定の制限）がまだ満たされていない場合、１４８０からの肯定の出口として示され、調査されるアイテムがなくなるまで、またはそのようなスキャン制限に達するまで、１４４０、１４５０、１４６０、１４７０、および／または１４８０として図示される動作が、テーブルの中の追加のアイテムに対して繰り返されてもよい。これは、図１４で１４８０から１４４０へのフィードバックによって図示されている。図１４で図示されるように、いったんテーブルの中のアイテムの全てが処理され、あるいは単一のスキャン要求に応じてスキャンおよび／または返されるアイテムの数への所定の制限が満たされると、１４８０からの否定の出口として示され、本方法は、１４９０の場合のように、要求を要求側に返すことを含んでもよい。１４９０に示され、以下でさらに詳細に説明されるように、単一のＳｃａｎ要求に応答して要求側に返される結果は、場合によっては、特定基準を満たすアイテムおよび／または属性値の一部分のみを含んでもよい。

【0139】

要求がいかなるフィルタ基準も特定しない（１４２０からの否定の出口として示される）が、要求が、値が返される１つ以上の属性を特定する（１４２５からの肯定の出口として示される）場合、結果セットは、テーブルの中のアイテムの全ての特定属性の値を含んでもよい。言い換えれば、この場合、このスキャン動作に対する完全な一式の結果は、テーブルの中のアイテムの全ての特定属性の値を含むであろう。しかしながら、いくつかの実施形態では、（例えば、単一のスキャン要求に応答して、スキャンおよび／または返されるアイテムの数への所定の制限が、要求に対して、あるいはシステム全体またはクライアント特有のパラメータによって特定された場合）単一のスキャン要求に応答して、これらの結果のうちの全てを返せるわけではない（または必ずしも発見できるわけでもない）ことに留意されたい。例えば、テーブルの中の第１のアイテムの特定属性の値は、（１４３５の場合のように）結果セットに含まれてもよく、他の処理するアイテムがあり、スキャン制限にまだ達していない（１４５５からの肯定の出口として示される）場合、１つ以上の他のアイテムの特定の属性が、結果セットに含まれてもよい。これは、図１４で１４５５から１４２５へのフィードバックによって図示されている。いったんアイテムの全ての特定属性が結果セットに追加され、またはスキャン制限に達すると（１４５５からの否定の出口として示される）、１４９０の場合のように、結果セットの少なくとも一部分を含む応答が、要求側に返されてもよい。同様に、要求がいかなるフィルタ基準も特定せず（１４２０からの否定の出口として示される）、要求が、値が返されるいかなる属性も特定しない（１４２５からの否定の出口として示される）場合、結果セットは、テーブルの中のアイテムの全ての属性の全ての値を含んでもよい。言い換えれば、この場合、このスキャン動作に対する完全な一式の結果は、テーブルの中のアイテムの全ての属性の全ての値を含むであろう。例えば、テーブルの中の第１のアイテムの属性の全ての値は、（１４４５の場合のように）結果セットに含まれてもよく、他の処理するアイテムがあり、スキャン制限にまだ達していない（１４５５からの肯定の出口として示される）場合、１つ以上の他のアイテムの属性の全てが、結果セットに含まれてもよい。再度、これは、図１４で１４５５から１４２５へのフィードバックによって図示されている。この場合、いったんアイテムの全ての属性の全てが結果セットに追加され、またはスキャン制限に達すると（１４５５からの否定の出口として示される）、１４９０の場合のように、結果セットの少なくとも一部分を含む応答が、要求側に返されてもよい。この実施例で図示されるように、いくつかの実施形態では、単一のスキャン要求に応答して、スキャン動作の結果のうちの全てを返えせるわけではない（または必ずしも発見できるわけでもない）。

【0140】

上記で説明されるＳｃａｎおよびＱｕｅｒｙ ＡＰＩの使用は、以下の実施例を介して（すなわち、以下の擬似コードによって）さらに例証されてもよい。第１の実施例では、テーブルをスキャンするように要求が行われ、要求は、スキャンされたアイテムのＩＤ値が返されることを特定する。第２の実施例では、テーブルをスキャンするように、および結果をフィルタにかけて１０未満の一次キーＩＤ値を有する全てのアイテムを返すように、要求が行われる。

Ｓｃａｎ（‘ｍｙ−ｔａｂｌｅ’，ａｒｒａｙ（
‘ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔ’＝＞‘ＩＤ’
）
）；

Ｓｃａｎ（‘ｍｙ−ｔａｂｌｅ’，ａｒｒａｙ（
‘ＡｔｔｒｉｂｕｔｅｓＴｏＧｅｔ’＝＞‘ＩＤ’，
‘ＳｃａｎＦｉｌｔｅｒ’＝＞ａｒｒａｙ（／／ＷＨＥＲＥ
‘ＩＤ’＝＞ａｒｒａｙ（
‘ＣｏｍｐａｒｉｓｏｎＯｐｅｒａｔｏｒ’＝＞ＬＥＳＳ＿ＴＨＡＮ，
‘ＡｔｔｒｉｂｕｔｅＶａｌｕｅＬｉｓｔ’＝＞ａｒｒａｙ（
ａｒｒａｙ（ＮＵＭＢＥＲ＝＞１０）
）
）
）
）；

【0141】

上述のように、要求に対する完全な結果を発見、収集、および返す前に、単一のＳｃａｎまたはＱｕｅｒｙ要求に応答してスキャンおよび／または返されるアイテムの数への所定の制限が満たされた場合、動作は早く終了させられてもよく、応答は、所定の制限に達する前に読み出されたアイテムおよび／または属性値のみを含んでもよい。いくつかの実施形態では、応答は、テーブルをスキャンし、またはテーブルに問い合わせを行い、元のＳｃａｎまたはＱｕｅｒｙ要求のパラメータに従って追加のアイテムおよび／または属性を返し続けるように発行され得る、後続のＳｃａｎまたはＱｕｅｒｙ要求への入力として使用可能な情報を含んでもよい。例えば、応答は、ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ値、または別の継続トークンを含んでもよく、それは、次いで、後続のＳｃａｎまたはＱｕｅｒｙ要求の対応する入力パラメータ値として含まれてもよい。場合によっては、スキャンまたはクエリ動作に対する完全な一式の結果を発見および／または収集して返すために、２つ以上の後続のＳｃａｎまたはＱｕｅｒｙ要求が行われる必要があり得る。

【0142】

図１５は、一実施形態による、スキャンまたは応答制限が特定されている、クエリまたはスキャン動作を行うための方法を図示する。１５１０で図示されるように、この実施例では、本方法は、非リレーショナルデータベース内のテーブル（例えば、１人以上のデータ記憶サービスクライアントの代わりにデータ記憶サービスによって維持されるテーブル）の中の１つ以上のアイテムを対象とする、クエリまたはスキャン要求を受信することを含んでもよい。この実施例で図示されるように、要求は、１５１５の場合のように、特定要求パラメータ（例えば、クエリ条件、ハッシュキー属性値、範囲キー条件、スキャン条件等）に依存して、テーブルの所与の区分を対象としてもよい。要求によって評価されるアイテムが、要求の条件またはパラメータを満たす場合、そのアイテムの１つ以上の属性（例えば、全ての属性の値、または要求において特定される任意の属性の値）が、１５２０の場合のように、要求に対する結果セットに含まれてもよい。要求に対するスキャンまたは応答制限が満たされていない場合、１５２５からの否定の出口として示され、および要求の条件またはパラメータを満たすアイテムが区分の中にさらにある場合、１５３０からの肯定の出口として示され、該当する場合、要求条件またはパラメータを満たす、別のアイテムの１つ以上の属性値が、結果セットに追加されてもよい。これは、図１５で１５３０から１５２０へのフィードバックによって図示されている。

【0143】

要求に対するスキャンまたは応答制限が満たされていない（１５２５からの否定の出口として示される）が、要求の条件またはパラメータを満たす、現在調査されているアイテムが区分の中にもはやなく（１５３０からの否定の出口として示される）、問い合わせられる、またはスキャンされる区分がさらにある（１５３５からの肯定の出口として示される）場合、本方法は、スキャンまたはクエリ動作を継続するように、要求を別の区分にダイレクトすることを含んでもよい。これは、図１５で１５３５から１５１５へのフィードバックによって図示されている。この実施例では、本方法は、１５１５〜１５３５で図示される動作を１回以上繰り返し、該当する場合、要求条件またはパラメータを満たす、他のアイテムの１つ以上の属性値を、結果セットに追加することを含んでもよい。これは、図１５で１５３０から１５２０へのフィードバックによって図示されている。要求についてスキャンまたは応答制限に達する前に、スキャンまたはクエリ動作が完了する場合、１５３５からの否定の出口として示され、本方法は、１５４０の場合のように、完全な一式の結果、およびスキャンまたはクエリ動作の完了が成功したという指示を含む、応答を要求側に返すことを含んでもよい。

【0144】

何らかの時点で、要求についてスキャンまたは応答制限に達した場合、１５２５からの肯定の出口として示され、本方法は、早く（すなわち、完全な一式の結果を発見および／または収集する前に）スキャンまたはクエリ動作を終了させ、部分的結果（スキャンまたは応答制限に達する前に結果セットの中で収集されたもの）および継続トークン（ＬａｓｔＥｖａｌｕａｔｅｄＫｅｙパラメータ値等）を含む、応答を要求側に返すことを含んでもよい。これは、１５４５において図１５で図示されている。依然として、調査されるアイテムがさらにある場合、１５５０からの肯定の出口として示され、その入力パラメータのうちの１つとして継続トークンを含む、後続のクエリまたはスキャン動作が開始されてもよい。この後続のクエリまたはスキャン動作は、１５６０で示されるように、以前の動作が終了させられた時点で、テーブルをスキャンすること、またはテーブルに問い合わせることを開始するであろう。制限に達し、動作を終了させた後に、調査されるアイテムがもはやない場合、１５５０からの否定の出口として示され、スキャンまたはクエリ動作が、１５７０の場合のように、完了してもよい。

【0145】

本明細書のデータ記憶システムにおいてサポートされるＡＰＩのうちの種々のものによって返され得る、エラー指示のうちのいくつかが、上記で説明されている。その他は、以下の表９に記載される。

【0146】

【表9】

【0147】

いくつかの実施形態では、以下のエラー指示が、サービスによってサポートされるＡＰＩのうちのいずれかによって返されてもよい一方で、他のエラー指示は、これらのＡＰＩのうちの特定のものによって返されてもよいことに留意されたい。
・ＩｎｖａｌｉｄＰａｒａｍｅｔｅｒＶａｌｕｅ
・ＭｉｓｓｉｎｇＰａｒａｍｅｔｅｒＶａｌｕｅ
・ＩｎｔｅｒｎａｌＦａｉｌｕｒｅ
・ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ

【0148】

いくつかの実施形態では、データ記憶サービスクライアントの代わりにテーブル（本明細書で説明されるメタデータテーブルのうちのいずれかを含む）を維持および管理する際に使用されるものとして本明細書で説明されるメタデータのうちのいずれかまたは全ては、クライアント／ユーザテーブルが記憶されるものと同一の規模変更可能なデータ記憶部（例えば、同一の非リレーショナルデータベース）の中に記憶されてもよい。そのような実施形態では、本システムは、データ記憶サービスの初期化を支援する１つ以上のブートストラッピング機構（および／またはデータ記憶サービスを実装する基礎的システム）を含み、または採用してもよく、そのうちのいくつかが本明細書で説明される。図１６は、一実施形態による、そのようなシステムのデータモデルの一部分を図示する。この実施例では、種々のコンピューティングノード（データモデルにおいて単純に「ノード１６１０」として表される）は、上記で説明されるもの等のデータ記憶サービスによって使用されるメタデータを含む、（例えば、ユーザの代わりに維持されるテーブルの中の）ユーザデータおよび／またはシステムデータを記憶してもよい。したがって、データモデルの各ノード１６１０は、ノードタイプ１６１５として知られているノードのタイプの指標を含んでもよい。例えば、一実施形態では、各ノードは、「記憶ノード」、「要求ルータ」、「自己管理」ノード、または「ステージング」ノードとして指定されてもよい。いくつかの実施形態では、「記憶ノード」は、データ記憶サービスによって維持される１つ以上のテーブルの中にユーザデータを記憶してもよいが、メタデータ（例えば、Ｔａｂｌｅｓテーブル、Ｓｕｂｓｃｒｉｂｅｒｓテーブル、Ｐａｒｔｉｔｉｏｎｓテーブル、またはＮｏｄｅｓテーブルのうちの１つ以上の中に記憶されたデータ）は、他のタイプのノード（例えば、「自己管理」ノードおよび／または「ステージング」ノード）上でホストされてもよい。他の実施形態では、そのようなメタデータは、１つ以上の「記憶ノード」上で記憶されてもよく、そのうちのいくつかもまた、ユーザデータを記憶してもよい。図１６で図示されるように、各ノード１６１０はまた、ノードの識別子（ノードｉｄ１６２０として示される）および１つ以上の他の要素（１６３０として示される）を含んでもよい。

【0149】

図１６で図示されるように、各複製に関する情報は、データモデルにおいて複製１６４０として表されてもよい。データモデルにおける各複製１６４０は、複製がホストされるノードの識別子（ノードｉｄ１６２０として示される）、およびこれらの複製に含まれる区分を示す１つ以上の区分識別子（区分ｉｄ１６３５として示される）を含んでもよい。この実施例では、各区分は、データモデルにおいて区分１６５０として表されてもよく、その区分ｉｄ１６５５を含んでもよい。種々の１対多数のマッピングによって図１６で図示されるように、各ノードは、複数の複製をホストしてもよく、各区分は、複数の複製に含まれてもよい。

【0150】

いくつかの実施形態では、本明細書で説明されるシステムは、「完全シェアードナッシング」タイプのアーキテクチャにおいて、ユーザテーブルのシームレスな規模変更をサポートしてもよい。例えば、いくつかの実施形態では、各区分は、完全に独立した並列計算ユニットとして実装されてもよい。そのような実施形態では、本システムは、区分にわたる分散協調を提供しなくてもよく、あるいはバッチ「ｐｕｔ」動作および／またはマルチステートメントトランザクションをサポートしなくてもよい。いくつかの実施形態では、作業負荷分配が区分にわたって十分に拡散されている限り、区分の数の増加は、より大きい使用可能テーブルサイズおよび／またはサービス要求のための増加したスループット容量をもたらしてもよい。本明細書で説明されるように、いくつかの実施形態では、作業負荷変化に適応するために、（プログラム的／自動的であろうと、明示的に開始されようと）ライブ再区分化が採用されてもよい。言い換えれば、いくつかの実施形態では、影響を受けた区分を対象とするサービス要求が受信および処理され続けている間に（すなわち、ソース区分をオフラインにすることなく）再区分化（区分移動、区分分割、および他の再区分化動作を含む）が行われてもよい。

【0151】

異なる実施形態では、データ記憶サービス（および／または基礎的システム）は、種々のサービス供給および／またはスループットモデルをサポートしてもよい。例えば、いくつかの実施形態では、サービスは、コミットメント型スループット供給および／またはベストエフォート型供給をサポートしてもよい。いくつかの実施形態では、記憶サービスクライアント（例えば、サービスへのアクセスを有するクライアントアプリケーション、ユーザ、または加入者）は、種々のビジネスモデル、購読タイプ、および／または支払モデルに従って、サービスによって供給される複数のスループットオプション間の選好を特定してもよい。例えば、クライアント／ユーザは、いくつかの実施形態では、テーブルを作成する要求のパラメータを通して、特定のテーブルの好ましいスループットモデルを示してもよい。他の実施形態では、クライアント／ユーザは、それらの代わりにデータ記憶サービスが、作成および維持される全てのテーブルのデフォルトスループットモデルを特定してもよい。コミットメント型スループットモデルおよびベストエフォート型スループットモデル（いかなるスループット保証も行われない）の両方をサポートすることによって、本システムは、それらの必要性および／または予算に従って、クライアント／ユーザが性能と費用との間のトレードオフを行うことを可能にしてもよい。

【0152】

コミットメント型スループット供給を提供するデータ記憶サービス（および基礎的システム）は、テーブルを対象とするトラフィックに応答して、クライアント／ユーザの代わりに維持されるテーブルの作成、成長、および管理のための容量および／またはリソースを事前に割り付けるように、ならびにテーブルが維持される記憶ノード（複数可）のリソースおよび／または容量をオーバーブッキングしないように構成されてもよい。いくつかの実施形態では、コミットメント型スループットモデルの下でサービス（および基礎的システム）によって維持されるテーブルが、クライアント／ユーザからの要求を果たすときに極めて低い待ち時間を提供するために、高性能メディア（例えば、フラッシュメモリあるいはソリッドステートドライブまたはＳＳＤ、メディア）等のより高速（かつしばしばより高価な）メモリの中で維持されてもよい。例えば、本システムは、これらのテーブル（およびその種々の区分）の維持のために、メイン（例えば、ディスク）メモリに対する高速／ローカルメモリの高い比率を提供し（かつ専用にし）てもよい。コミットメント型スループットモデルの下で所与のテーブルに割り付けられたメモリが、場合によっては、（少なくともいくらかの時間）十分に活用されない場合がある一方で、クライアント／ユーザは、常にそのテーブルに必要であり得るよりも多くのリソースを専用にする追加の（場合によっては無駄な）費用よりも、コミットメント型スループットモデルによって得られる予測可能な性能を重視してもよい。

【0153】

種々の実施形態では、所与のテーブル（またはクライアント／ユーザ）に対するコミットメント型スループットレベルは、サービス要求がテーブルを標的にするときに行われる作業に関して特定されてもよいことに留意されたい。例えば、テーブルへの読み取りアクセスが、（例えば、テーブルのデータファイルを読み出すために）１回だけの入出力アクセスを必要としてもよい一方で、テーブルへの書き込みアクセス（例えば、テーブルの中のアイテムまたはアイテム属性を追加、削除、または修正するアクセス）は、（例えば、書き込みアクセスを記録するため、次いで、アクセスを行うために）少なくとも２回の入出力アクセスを必要としてもよい。加えて、本明細書で説明されるように、いくつかの個別サービス要求は、テーブルの中の複数のアイテムおよび／またはアイテム属性を読み取り、および／または書き込んでもよい。したがって、１秒あたりの入出力動作（ＩＯＰＳ）の数または１秒あたりのサービス要求の数（すなわち、ＡＰＩ呼び出し）に関して、コミットメント型スループットを特定するよりもむしろ、コミットメント型スループットレベルは、「１秒あたりの論理サービス要求単位」に関して等、経時的な正規化された論理作業単位の測定に関して特定されてもよい。一実施例では、テーブルの中の単一のアイテムを標的にする読み取りアクセスをもたらすサービス要求が、１つの論理サービス要求単位を必要とする（または消費する）と見なされてもよい一方で、テーブルの中の単一のアイテムを標的にする書き込みアクセスをもたらすサービス要求は、２つまたは３つの論理サービス要求単位を必要とする（または消費する）と見なされてもよい。別の実施例では、スループットレベルは、読み取り要求および書き込み要求に対して異なって特定されてもよく、または読み取り要求および書き込み要求によって消費される論理サービス要求単位は、これらの要求によってアクセスされるアイテムのサイズに基づいて正規化されてもよい。一般に、複数の読み取りおよび／または書き込みアクセスを含む、サービス要求（例えば、０〜１ＭＢのいずれかのデータを返し得るクエリまたはスキャン要求）によって行われる作業は、これらの要求を果たすために必要とされる論理作業単位の数に、および／またはこれらの要求のそれぞれによってアクセスされる１つまたは複数のアイテムのサイズに依存し得る、論理サービス要求単位に関してモデル化されてもよい。種々の実施形態では、要求を果たすときに実際に行われる物理的入出力動作（例えば、メモリアクセス）の数は、要求を果たすときに必要とされる（または消費される）論理サービス要求単位の数の固定または可変倍数であってもよい。例えば、いくつかの実施形態では、所与の要求を果たすときに行われる物理的入出力動作の数は、要求を果たす際に必要とされる（または消費される）論理サービス要求単位の数の約２倍であってもよい。

【0154】

いくつかの実施形態では、コミットメント型スループットモデルの下でサービスを受信するクライアント／ユーザは、テーブルサイズおよび／またはサービス要求トラフィックの増加を予想して、追加の容量またはリソースを積極的に要求および／または購入してもよい。例えば、クライアント／ユーザは、テーブルを対象とするトラフィックについて、１秒あたり１０，０００の論理サービス要求単位のコミットメント型スループットレベルを（例えば、テーブルを作成するサービス要求において）特定してもよい。それに応答して、データ記憶サービス（および基礎的システム）は、テーブルに対して２０の区分を自動的に作成してもよく、２０の区分のそれぞれを対象とした１秒あたり５００の論理サービス要求単位をサポートするのに十分なリソースおよび／または容量を保存してもよい。いくつかの実施形態では、これは、物理的メモリ（例えば、ディスク）にとって約１０００回の入出力動作に変換してもよい。本システムが最初に要求されたコミットメント型スループットレベルを提供するように構成された後、クライアント／ユーザは、コミットメント型スループットレベルの一時的または永久的増加または減少を要求してもよく、それに応答して、本システムは、リソース／容量をテーブルのために保存されたものに自動的に追加し、またはテーブルのために保存されたものからリソース／容量を除去して、要求された修正に相応するように、保存されたリソース／容量の量を修正するように構成されてもよい。いくつかの実施形態では、コミットメント型スループットモデルを提供するシステムが、コミットメント型スループットレベルを超えるトラフィックの短期増加または急増をサポートするように、随意的なバースティングを可能にしてもよい。例えば、本システムは、所定のバースト許容レベルまで、追加の論理サービス要求単位を自動的に受け入れて果たすように構成されてもよく（その後、追加の論理サービス要求単位を受け入れて果たしてもよく、またはそうしなくてもよい）、テーブルがバースト許容レベルを加えたコミットメント型スループットレベルに等しいトラフィックを取り扱うことができるために十分なリソースを保存してもよい。他の実施形態では、本システムは、日和見的に（例えば、リソースおよび容量が利用可能である場合に）追加の論理サービス要求単位を受け入れて果たすのみであってもよいが、これらの追加の論理サービス要求単位を果たす任意の保証を伴わない。なおも他の実施形態では、本システムは、コミットメント型スループットレベルに対応する量で受け入れられ、果たされる論理サービス要求単位の上限を厳密に定め、その後、追加のサービス要求が抑制されてもよい。

【0155】

一実施例では、クライアント／ユーザは、（例えば、テーブルまたはその区分を対象とする増加した活動をトリガし得る、販売、販促、告知、新発売、または他の事象による）需要の計画または予期された一時的バーストまたは急増に先だって、または需要が現在のコミットメント型スループットレベルに近づいているという観察に応答して、テーブルに対するコミットメント型スループットレベルの増加を要求してもよい。別の実施例では、所与のテーブルに対する需要の一時的増加の準備をし、観察した後、クライアント／ユーザは、コミットメント型スループットレベルを、その初期レベルに、または前進する予期された需要に相応する新しいレベル（例えば、テーブルに対する「新しい正常」）に戻す要求を提出してもよい。いくつかの実施形態では、データ記憶サービス（および基礎的システム）は、クライアント／ユーザが、（計画されているか否かにかかわらず）需要の降下に続いて、テーブルに対するコミットメント型スループットレベルを「再交渉」することを可能にしてもよく、それは、クライアント／ユーザが、後に必要とされるであろうよりも大量のリソース／容量の保存と関連付けられる費用を削減することを可能にしてもよい。いくつかの実施形態では、データ記憶サービス（および基礎的システム）は、より高い性能（すなわち、より低い待ち時間）が所望される、高需要の初期期間に続いて、コミットメント型スループットモデルよりもむしろベストエフォート型スループットモデルの下で、所与のテーブルが管理されることを、クライアント／ユーザが要求することを可能にしてもよい。そのような実施形態では、テーブルに割り付けられた、またはテーブルのために保存されたリソース／容量の一部分が、（例えば、クライアント／ユーザ推定需要、履歴データ、あるいはシステム全体、アカウント特有、またはクライアント特有のデフォルトに基づいて）割り付け／保存を解除されてもよく、テーブルを標的にする、後に受信されたサービス要求が、（リソース／容量が利用可能である際に）日和見的に取り扱われてもよい。

【0156】

ベストエフォート型スループット供給を提供するデータ記憶サービス（および基礎的システム）は、より低い記憶費用をもたらし得るが、より高い待ち時間をもたらし得る、より従来的な回転メディア（例えば、ディスクメディア）上で作動するように構成されてもよい。ベストエフォート型スループットモデルの下でテーブルを管理するとき、本システムは、（すなわち、クライアント／ユーザに管理負担を課すことなく、またはそれらの介入を必要とすることなく）トラフィックまたはデータ記憶量の増加に自動的応答するように構成されてもよく、増加を取り扱おうとする努力が実行されるまで、少なくともいくつかのサービス要求を抑制してもよい。例えば、いくつかの実施形態では、本システムは、トラフィックおよび／またはデータ量の増加に応答した、作業負荷変化および／または記憶サービスクライアント（例えば、ユーザ、加入者、またはクライアントアプリケーション）の代わりにサービスによって管理されているデータの再区分に応答して、区分を追加しながら、着信サービス要求の少なくとも一部分を抑制するように構成されてもよい。ベストエフォート型スループットモデルは、クライアント／ユーザにとってより少ない費用がかかり得る一方で、急速に変化する作業負荷について行くことができない場合がある。言い換えれば、ベストエフォート型スループットモデルの下で管理される所与のテーブルを対象とする作業負荷が急速に変化し得る状況で、所与のテーブルを標的にするアプリケーションの全体的な性能が劣り得る（作業負荷がコミットメント型スループットレベルを超えない、または作業負荷の変化が予測可能であり、かつ増加した需要に先だってコミットメント型スループットレベルを修正することによって積極的に取り扱われる、コミットメント型スループットモデルの下で管理されるテーブルを標的にするアプリケーションの性能と比較して）。

【0157】

特定スループットモデルに従って、データ記憶サービスクライアント（例えば、ユーザ、加入者、またはクライアントアプリケーション）の代わりにテーブルを作成および管理するための方法の一実施形態が、図１７でフロー図によって図示されている。１７１０で図示されるように、この実施例では、本方法は、非リレーショナルデータベース内のテーブル（例えば、データ記憶サービスのクライアント／ユーザの代わりに維持されるテーブル）を作成するサービス要求を受信する、データ記憶サービスを実装するシステムの構成要素を含んでもよい。いくつかの実施形態では、クライアント／ユーザは、テーブルを対象とする要求を果たすときに使用されるスループットモデル（例えば、ベストエフォート型スループットモデルまたはコミットメント型スループットモデル）を特定するためのパラメータを含む、ＡＰＩに一致するテーブルを作成するように、サービス要求をサービス（または基礎的データ記憶部）に提出してもよい。そのような実施形態では、要求はまた、コミットメントが求められる、要求されたスループットレベルの指示を含んでもよい。いくつかの実施形態では、データ記憶サービス（および基礎的システム）は、クライアント／ユーザの代わりに新しいテーブルを作成するときに使用されるスループットモデルに対するシステム全体、アカウント特有、またはクライアント特有のデフォルトの使用をサポートしてもよい。いくつかのそのような実施形態では、テーブルを作成する要求は、スループットモデル選好の指示を含まなくてもよいが、コミットメントが求められる、要求されたスループットレベルの指示を含んでもよい。

【0158】

クライアント／ユーザがコミットメント型スループットモデルの選好を特定した場合、１７１５からの肯定の出口として示され、本方法は、１７３０の場合のように、そのユーザの代わりに維持されている、このテーブルおよび／または任意の他のテーブルを対象とするトラフィックに対する要求されたコミットメント型スループットレベルをサポートするように、本システムが十分な容量および／またはリソースを事前に割り付けることを含んでもよい。例えば、クライアント／ユーザが、特定のスループットコミットメントを受信する特権の代金を支払った加入者である場合、本システムは、そのコミットメントを満たすように十分なリソースおよび／または容量を事前に割り付けてもよい。いくつかの実施形態では、コミットメント型スループットモデルの下で管理されるテーブルに割り付けられたメモリは、ベストエフォート型スループットモデルの下で管理されるテーブルに割り付けられたメモリよりも高速の（かつ高価な）メモリを含んでもよいことに留意されたい。クライアント／ユーザが、１７５０の場合のように、後に、増加したスループットへのコミットメントを要求する、またはコミットメント型スループットレベルの低減を要求する場合、本システムは、１７７０の場合のように、そのテーブルがコミットメント型スループットレベルへの要求された修正に相応するために、容量および／またはリソースを割り付け、または割り付けを解除するように構成されてもよい。例えば、いくつかの実施形態では、クライアント／ユーザは、スループットの一時的または永久的増加の代金を支払うことが可能であり得（したがって、コミットメント型スループットの要求されたレベルを修正する）、本システムは、それに従って（例えば、クライアント／ユーザのアカウント情報の変化に応答して）リソースおよび／または容量を再び割り付けるように構成されてもよい。いくつかの実施形態では、そのような要求は、クライアント／ユーザの代わりにデータ記憶サービスによって維持されるテーブルを構成および／または再構成するための１つ以上のパラメータを含むＡＰＩに従って、テーブルを作成するクライアント／ユーザによって、または別の特権ユーザ（すなわち、テーブルの構成の変更を行う権限があるユーザ）によって行われてもよい。いくつかの実施形態では、容量および／またはリソースの一時的増加の要求に続いて、クライアント／ユーザは、容量および／またはリソースに関して減少したレベルのサポートを要求（および受信）してもよい。

【0159】

ユーザがコミットメント型スループットの選好を特定していない場合（例えば、ベストエフォート型モデルがテーブル作成要求において特定される、あるいはクライアント／ユーザの代わりに新しいテーブルを作成するときに使用されるスループットモデルに対するシステム全体、アカウント特有、またはクライアント特有のデフォルトが、テーブルを対象とする要求を管理するときにベストエフォート型スループットモデルが適用されるべきであると示す場合）、１７１５からの否定の出口として示され、本方法は、１７４０の場合のように、本システムが、テーブルを対象とするトラフィックの初期量および／または分配をサポートするように、容量および／またはリソースを割り付けることを含んでもよい。例えば、ユーザが、特定のスループットコミットメントを受信する特権の代金を支払っていないが、ベストエフォート型スループットモデルがユーザの必要性に十分であると示している加入者である場合、本システムは、ベストエフォート型スループットモデルに基づいて、初期量のリソースおよび／または容量を割り付けてもよい。種々の実施形態では、新しいテーブルに割り付けられるリソースおよび／または容量の初期量は、このクライアント／ユーザおよび／または他のクライアント／ユーザに対するサービス要求の履歴量および／またはパターン、クライアント／ユーザによって予測されるサービス要求の量または分配（いくつかの実施形態ではテーブル作成要求において特定され得る）、新たに作成されたテーブルに最初に割り付けられるリソースおよび／または容量に対するシステム全体、アカウント特有、またはクライアント特有のデフォルト、および／または要因に依存し得る。いくつかの実施形態では、ベストエフォート型スループットモデルの下で管理されるテーブルが維持されるメモリは、ベストエフォート型スループットモデルの下で管理されるテーブルが維持されるメモリよりも安価（かつ低速）であり得ることに留意されたい。

【0160】

本システムが、データのトラフィックおよび／または量の増加を検出した場合（例えば、増加したトラフィックが、システムが要求の全てを果たすことをできなくさせる、または記憶されるデータの量が割り付けられた容量に近づく場合）、１７２５からの肯定の出口として示され、本システムは、１７４０の場合のように、トラフィックまたはデータ量の増加をサポートするように、追加の容量および／またはリソースを定位置に置くことができるまで、または置くことができない限り、要求を抑制するように構成されてもよい。例えば、１つ以上のテーブル（またはその区分）を対象とする増加したトラフィック、あるいはテーブル（またはその区分）に対する現在割り付けられている容量に近づいているテーブルの中のデータの量の検出に応答して、本システムは、増加したトラフィックまたはデータ容量レベルで、クライアント／ユーザにサービス提供しようとして、自動的に区分を追加し、区分を移動させ、または別様にテーブルの中および／または１つ以上の他のテーブルの中のデータを再区分するように構成されてもよい。

【0161】

同様に、本システムが（例えば、持続期間にわたって）トラフィックおよび／またはデータの量の減少を検出した場合、１７２５からの否定の出口として示され、本システムは、１７６０の場合のように、テーブル専用の容量および／またはリソースの量が観察された需要とより一致するように、テーブルに対する容量および／またはリソースを除去し、または割り付けを解除するように構成されてもよい。例えば、テーブル（またはその１つ以上の区分）を対象とする減少したトラフィック（または現在割り付けられているリソースおよび容量によってサポートすることができるレベルを十分に下回ったままであるトラフィック）、あるいはテーブルまたはその区分（複数可）に対する現在割り付けられている容量を十分に下回る（かつ少なくとも所定の期間にわたって十分に下回っている）テーブル（またはその１つ以上の区分）の中のデータの量の検出に応答して、本システムは、テーブルに割り付けられているリソースおよび容量を観察された需要により良く合致させようとして、自動的に１つ以上の区分を除去し、複数の区分を単一の区分に崩し、１つ以上の区分に対するメモリまたはスループット容量の割り付けを解除し、または別様にテーブルの中のデータを再区分するように構成されてもよい。図１７で図示されるように、トラフィックおよび／またはデータ量は、最初に割り付けられた容量および／またはリソースを使用して、合理的な性能でサービス提供することができる範囲内にとどまり、１７２５および１７４５からの否定の出口として示されるが、データ記憶サービス（および基礎的システム）は、１７８０の場合のように、テーブルに対する初期容量およびリソースを維持してもよい。

【0162】

種々の実施形態では、図１７で図示される動作のうちのいずれかまたは全ては、テーブルがアクティブなままである間に、データ記憶サービスによって管理されるテーブルを作成し、後に維持するために、繰り返されてもよいことに留意されたい。いくつかの実施形態では、作業負荷またはデータ量の変化を検出すること、着信サービス要求を抑制すること、および／または所与のテーブルに対して割り付けられた、保存された、または利用可能である区分の数および／またはリソース／容量の量を修正することのうちのいずれかまたは全ては、クライアント／ユーザによって行われる条件および／または要求の変更に応答して、最初にリソースを割り付け、後にこれらのリソースを修正する、自動管理インスタンスによって行われてもよいことに留意されたい。

【0163】

上述のように、コミットメント型スループットモデルを使用してテーブルが管理される、種々の実施形態では、本システムは、これらのテーブルに対するコミットメント型スループットレベルへの修正を可能にしてもよく、例えば、コミットメント型スループットレベルにおける一時的および／または永久的変化を可能にしてもよい。図１８は、コミットメント型スループットレベルを維持または修正しながら、特定のテーブルを対象とした要求を果たすための方法の一実施形態を図示するフロー図である。１８１０で図示されるように、この実施例では、データ記憶サービス（または基礎的データ記憶部）は、コミットメント型スループットモデルの下でクライアント／ユーザの代わりにテーブルを管理してもよい。いくつかの実施形態では、コミットメント型スループットモデルの下で管理されるテーブルに割り付けられたメモリは、ベストエフォート型スループットモデルの下で管理されるテーブルに割り付けられたメモリよりも高速の（かつ高価な）メモリを含んでもよいことに留意されたい。この実施例では、何らかの時点で、（テーブルまたはその種々の区分を標的にする要求を果たすときのスループットに関して）観察された需要が、コミットメント型スループットレベルを超える場合（１８２０からの肯定の出口として示される）、および（例えば、所定のバースト許容レベルまでの）いくらかの量のスループットのバースティングおよび／または急増が、本システムによってサポートされる場合（１８３０からの肯定の出口として示される）、本方法は、１８４０の場合のように、本システムが、追加の需要の少なくとも一部分を提供する（所定のバースト許容レベルまでの追加のスループットを提供する）ことを含んでもよい。この実施例では、コミットメント型スループットレベルおよび所定のバースト許容レベルを満たすように、追加のリソースがテーブルのために保存されることが仮定される。他の実施形態では、スループットのバースティングまたは急増は、日和見的に（例えば、テーブルのために保存されていないリソースおよび／または容量が偶然に利用可能である場合）サポートされるのみであってもよい。

【0164】

図１８で図示されるように、観察された需要が、コミットメント型スループットレベルを超える（１８２０からの肯定の出口として示される）が、スループットのバースティングおよび／または急増が、本システムによってサポートされておらず（１８３０からの否定の出口として示される）、追加の需要の少なくとも一部分を提供するために利用可能である十分なリソースがない場合（１８３５からの否定の出口として示される）、本方法は、１８４５の場合のように、本システムが、コミットメント型スループットレベルに合致するように、テーブルを対象とするサービス要求を抑制することを含んでもよい。いくつかの実施形態では、需要が、コミットメント型スループットレベルを超え（１８２０からの肯定の出口として示される）、スループットのバースティングおよび／または急増が、本システムによってサポートされていない（１８３０からの否定の出口として示される）が、追加の需要の少なくとも一部分を提供するために利用可能である十分なリソースがある場合（１８３５からの肯定の出口として示される）、本方法は、１８４０の場合のように、本システムが、追加の需要の少なくとも一部分を提供することを含んでもよい。言い換えれば、いくつかの実施形態では、任意の追加の需要（コミットメント型スループットレベルを超える需要）は、日和見的に提供されてもよいが、保証されなくてもよい。上述のように、（バースト／急増を許容するためのポリシーを通してであろうと、日和見的であろうと）コミットメント型スループットレベルを超える要求を果たすことにより、いくつかの実施形態では、コミットメント型スループットレベルを提供するための料金を超えたクライアント／ユーザアカウントへの追加の料金をもたらし得る。

【0165】

この実施例で図示されるように、観察された需要が、コミットメント型スループットレベルを超えない（１８２０からの否定の出口として示される）が、（１８５０の場合のように）増加したコミットメント型スループットレベルに対する要求を示すサービス要求が受信される場合、本方法は、１８５５の場合のように、本システムが、コミットメント型スループットレベルの要求された増加をサポートするように、１つ以上の区分および／または追加のリソース／容量を追加することを含んでもよい。例えば、クライアント／ユーザが、（テーブルを標的にする要求を果たすときのスループットに関して）需要の一時的または永久的増加を期待する場合、クライアント／ユーザは、いくつかの実施形態では、増加した需要に応答することを待たずに、本システムが増加した要求を取り扱うように、コミットメント型スループットレベルの増加を積極的に要求してもよい。

【0166】

いくつかの実施形態では、増加した需要が一時的であると期待（または観察）される場合、あるいは増加した需要の期間に続いて減衰する需要に応答して、クライアント／ユーザは、コミットメント型スループットレベルが（例えば、以前のコミットメント型スループットレベルまで、または異なる「新しい正常」コミットメント型スループットレベルまで）減少させられることを要求してもよい。この場合、１８６０で示されるように、本システムは、１８６５の場合のように、テーブルに割り付けられるリソースおよび容量を、減少したコミットメント型スループットレベルにより合致させようとして、１つ以上の区分を除去し、複数の区分を単一の区分に崩し、１つ以上の区分に対するメモリまたはスループット容量の割り付けを解除し、および／またはテーブルの中のデータを再区分するように構成されてもよい。

【0167】

いくつかの実施形態では、テーブル（および／またはその種々の区分）を対象とする需要が、テーブルがアクティブである残りの時間にわたって比較的低レベルにとどまることを、クライアント／ユーザが期待する場合、クライアント／ユーザは、減少したコミットメント型スループットレベルに対する要求において、テーブルに対するスループットレベルへのいかなるコミットメント（または対応する保証）ももはや必要としていない、または所望していないことを示してもよいことに留意されたい。言い換えれば、要求は、テーブルを対象とする要求を後に果たすときに、コミットメント型スループットモデルよりもむしろベストエフォート型スループットモデルを使用してテーブルを管理する要求を効果的に示し得る、ゼロというコミットメント型スループットレベルを示してもよい。これは、１８７０からの肯定の出口および要素１８８０によって図１８で図示されている。いくつかの実施形態では、ベストエフォート型スループットモデルの下で管理されるテーブルが維持されるメモリは、ベストエフォート型スループットモデルの下で管理されるテーブルが維持されるメモリよりも安価（かつ低速）であり得ることに留意されたい。クライアント／ユーザがテーブルに対するスループットレベルへのコミットメント（および対応する保証）をもはや必要としていない、または所望していないことを、減少したコミットメント型スループットレベルに対する要求が示さない場合、１８７０からの否定の出口として示され、本システムは、１８７５の場合のように、コミットメント型スループットモデルを使用して（例えば、現在のコミットメント型スループットレベルに従って）テーブルを管理し続けてもよい。

【0168】

種々の実施形態では、図１８で図示される動作のうちのいずれかまたは全ては、テーブルがアクティブなままである間に、データ記憶サービスによって管理されるテーブルを作成し、後に維持するために、繰り返されてもよいことに留意されたい。

【0169】

種々の実施形態では、例えば、１つのマシンから別のマシンへ、区分（またはその複製）がコピーされる必要があり得る、状況があってもよい。例えば、それぞれ異なる物理的または論理的マシン上でホストされる、特定の区分の３つの複製があり、マシンのうちの１つが故障する場合、そのマシン上でホストされた複製が、別のマシン上の区分の新しいコピーに置換される必要があり得る。別の実施例では、１つ以上のテーブルの複数の区分をホストする特定マシンが激しいトラフィックを体験する場合、システム作業負荷をより均等に分配し、性能を向上させようとして、大量にアクセスされた区分のうちの１つが、（コピー動作を使用して）より少ないトラフィックを体験しているマシンへ移動させられてもよい。いくつかの実施形態では、本明細書で説明されるデータ記憶サービス（および／または基礎的システム）は、（従来の論理的データベース区分コピー動作の場合のように）区分データのスナップショットを行ごとにコピーするよりもむしろ、１つのマシンから別のマシンへ区分全体をコピーする、物理的コピー機構（例えば、物理的ファイルシステム機構）を使用して、区分移動を行ってもよい。区分がコピーされている間に、区分を標的にする書き込み動作が記録されてもよい。コピー動作中に、任意の記録された書き込み動作が、周期的な間隔で（例えば、一連のチェックポイントで）追い上げプロセスによって区分に適用されてもよい。いったん区分全体が宛先マシンにコピーされると、任意の残りの記録された書き込み動作（すなわち、最後のチェックポイント以降に行われた任意の書き込み動作）が、最終追い上げプロセスによって宛先区分に行われてもよい。したがって、従来の区分移動機構と違って、宛先区分の中のデータは、区分移動の完了後に一貫性があり得る。

【0170】

区分が「ライブである」間に、記憶サービスクライアントの代わりに、データ記憶サービスによって維持されているテーブルの区分の複製を移動させる（またはコピーする）ための方法の一実施形態が、図１９でフロー図によって図示されている。この実施例では、本方法は、１９１０の場合のように、区分の複製を移動させる要求を受信するデータ記憶サービスを実装する、システムの構成要素を含んでもよい。例えば、本システムは、クライアント／ユーザまたはシステム管理者から、複製を移動させる明示的な要求を受信してもよく、またはそのような要求は、（以下でさらに詳細に説明されるように）異常の検出に応答して、本システムにおいて自動的に生成されてもよい。１９２０で図示されるように、区分を移動させる要求の受信に応答して、本システムは、区分が「ライブである」間に（すなわち、区分の１つ以上の複製が、区分を対象とする要求を受け入れて果たし続けている間に）、新しい複製（宛先複製と呼ばれ得る）を作成するように構成されてもよい。いくつかの実施形態では、宛先複製を作成することは、宛先複製を作成するコンピューティングノードまたは記憶デバイスを選択すること、宛先複製に対するコンピューティングノードまたは記憶デバイス上のメモリを割り付けること、区分および／または宛先複製と関連付けられるメタデータを作成または更新すること、および／または宛先複製を作成するために適切な他の機能を果たすことを含んでもよい。

【0171】

この実施例で図示されるように、本方法は、１９３０の場合のように、区分の複製がライブである間に、本システムが、ファイルコピー機構または別の物理的コピー機構を使用して、宛先複製へ移動させられている複製をコピーすることを含んでもよい。言い換えれば、複製は、論理的コピー動作（例えば、行ごとにテーブルデータを読み取ってコピーする動作）を使用するよりもむしろ、複製データの物理的位置をコピーする動作を使用して、新しい宛先複製にコピーされてもよい。１９４０で図示されるように、物理的コピー動作を行った後に、本方法は、本システムが、コピー動作中に行われたが、新しいコピーではまだ反映されていない、複製データへの任意の変更を調整するように、追い上げ動作を行うことを含んでもよい。この追い上げ動作は、以下でさらに詳細に説明される。いったん宛先複製が作成されてデータ投入されると、本方法は、１９５０の場合のように、コピーされた複製から離し、新しい指定複製に向かって、トラフィックをダイレクトすることを含んでもよい。

【0172】

いくつかの実施形態では、データ記憶サービス（例えば、非リレーショナルデータベース）の基礎的データ記憶部のための記憶エンジンは、データベースファイルの中に複製データを記憶してもよく、各複製（およびデータベースファイル）は、回復ログと関連付けられてもよい。そのような実施形態では、複製データを修復するサービス要求が受信されたとき、複製に適用される前に回復ログの中に記録されてもよい。ノード障害またはシステムクラッシュの場合、回復ログに記録される変更は、複製のコンテンツを回復させるように、複製データの以前のスナップショットまたはチェックポイントに再適用されてもよい。上述のように、いくつかの実施形態では、データ記憶サービス（およびその基礎的システム）は、物理的コピー機構を採用する複製移動をサポートしてもよい。いくつかのそのような実施形態では、物理的コピー機構は、新しい宛先へ移動させられる複製データが一貫していることを確実にし得る、そのようなログを採用してもよい。図２０は、上記で説明されるような物理的コピー機構を使用して、複製を移動させるための方法の一実施形態を図示する。この実施例では、本方法は、２０１０の場合のように、その現在の物理的記録位置から対応する物理的宛先位置へ、複製データをコピーし始める。いくつかの実施形態では、物理的コピー動作は、ネットワーク上で１つの物理的記憶デバイス（例えば、ディスク記憶装置）から宛先記憶デバイスへ、ページをコピーすることを含んでもよい。

【0173】

２０２０で図示されるように、物理的コピー動作中に、移動させられている複製を標的にする書き込み動作は、上記で説明されるように、コピーされている複製に適用される前に記録されてもよい。種々の実施形態では、各記録された書き込み動作（または書き込み動作群）は、ログシーケンス番号が割り当てられてもよい。いくつかの実施形態では、記録された変更は、周期的チェックポイント間隔でコピーされている複製に適用されてもよい。図２０で図示される実施例では、所定のチェックポイント間隔が経過するとき、２０３０からの肯定の出口として示され、最後のチェックポイント以降に記録された修正の全て（例えば、書き込み動作）が、コピーされている複製に適用されてもよい。複製がコピーされている間にこれらの更新が適用されるため、これらの修正のうちのいくつかは、コピー動作（例えば、複製データの所与の部分が宛先にコピーされる前に、データのその部分に適用された修正）の結果として、宛先複製において反映されるであろう。他の修正は、コピー動作（例えば、複製データの所与の部分が宛先にコピーされた後に、データのその部分に適用された修正）に続いて、宛先複製において反映されなくてもよい。

【0174】

図２０で図示されるように、本方法は、完了していない間に、現在の物理的記録位置から対応する物理的宛先位置へ複製データをコピーし続けることを含んでもよい（２０５０からの否定の出口、要素２０６０、および２０２０へのフィードバックとして示される）。本方法は、（２０２０の場合のように）書き込み動作を記録し、チェックポイント間隔が経過するたびに（２０３０からの肯定の出口として示される）（２０４０の場合のように）記録された書き込み動作をコピーされている複製に適用し続けることを含んでもよい。いったん物理的コピー動作が完了すると（２０５０からの肯定の出口として示される）、本方法は、２０７０の場合のように、宛先複製においてまだ反映されていない、任意の記録された書き込み動作が宛先複製に適用される、追い上げ動作を行うことを含んでもよい。その後、複製へのアクセスは、ソース複製から離してダイレクトされ、新しい宛先複製に向かってダイレクトされてもよい。例えば、複製を標的にする任意の書き込み動作が、宛先複製のための回復ログの中に記録され、後に、（例えば、次の周期的チェックポイントで）宛先複製に適用されてもよい。いくつかの実施形態では、その新しい宛先への複製の移動に続いて、ソース複製への修正が記録されたログは、宛先複製のための回復ログにコピーされてもよい（または直接使用されてもよい）。

【0175】

いくつかの実施形態では、上記で説明される区分移動プロセスは、区分分割動作で採用されてもよい。例えば、区分は、大きいため、例えば、大きくなりすぎて１つのマシン上に適合できないときに、および／またはマシン故障の場合に（多数の並行プロセスを使用して）単一のマシン上でホストされる区分を迅速に再構築するほど十分小さく区分サイズを保つために、分割されてもよい。区分はまた、過剰に「ホット」になるときに（すなわち、他の区分と比較して、平均よりもはるかに大量のトラフィックを体験するときに）分割されてもよい。例えば、作業負荷が所与の区分に対して突然および／または劇的に変化する場合、本システムは、変化に迅速に応答するように構成されてもよい。いくつかの実施形態では、本明細書で説明される区分分割プロセスは、アプリケーションおよびクライアント／ユーザにトランスペアレントであり得、それは、データ記憶サービスが自動的に（すなわち、クライアント／ユーザ介入または開始を必要とすることなく）規模変更されることを可能にしてもよい。

【0176】

いくつかの実施形態では、本システムが、複製移動のために上記で説明されるファイルコピープロセスを利用してもよいため、クラスタの中の区分の複製を移動させることは、区分を分割することよりも迅速であり得ることに留意されたい。一方で、区分を分割することは、上記で説明されるように、１つの基礎的データ構造（例えば、１つのＢツリー）の中の区分データを、２つのそのようなデータ構造（例えば、２つのＢツリー）に論理的に分割することを要求してもよく、それは概して、複製全体の移動よりも効率的でない。したがって、いくつかの実施形態では、区分分割プロセスは、区分の追加の複製を作成し、その後、各複製上の区分データの半分のみを管理することを含んでもよい。例えば、分割される所与の区分の３つの複製がある場合、区分分割プロセスは、（例えば、上記で説明される区分移動プロセスを使用して）区分全体の３つの追加のコピーを作成することを含んでもよい。これらの結果として生じる６つの複製は、３つの区分の２つのグループに分割されてもよく、そのそれぞれは、複製のグループ間で責任を分割する動作を使用して、元の区分データの半分を対象とするサービス要求を取り扱う責任を負わされ得る。例えば、責任を分割する動作に続いて、元の区分の指定部分の中のデータを対象とするサービス要求が、所与の複製によって受け入れられ、果たされてもよい一方で、元の区分の残りのデータを標的にするサービス要求は、その複製によって拒絶されてもよい。いくつかの実施形態では、所与の複製が責任を持たない区分データは、最終的に除去されてもよく（例えば、もはやサポートしていないデータの複製に割り付けられたメモリが、複製の中に新しいアイテムを記憶するために後に使用され得るように）、またはそれが記憶されたメモリは、本システムによって再生利用されてもよい（例えば、もはやサポートしていないデータの複製に割り付けられたメモリが、別の区分によって後に使用され得るように）。サポートされていないデータの除去またはメモリの再生利用は、データ記憶システムの性能に影響を及ぼすことなく、バックグラウンドタスクによって行われてもよく、かつクライアント／ユーザにトランスペアレントであり得る。

【0177】

いくつかの実施形態では、各区分は、区分が作成されるときに割り当てられる一意的な番号（例えば、ＧＵＩＤ）であり得る、区分ＩＤによって識別されてもよい。区分はまた、区分が再構成を受けるたびに（例えば、必ずしもマスタフェイルオーバーに応答するわけではないが、複製の追加または除去に応答して）増分される、バージョン番号を有してもよい。区分が分割されるとき、２つの新しい区分が作成されてもよく、そのそれぞれは、それぞれの新しい区分ＩＤを有してもよく、元の区分ＩＤがもはや使用されなくてもよい。いくつかの実施形態では、変化する条件に応答して、分割ツールまたはプロセスを使用して、区分が本システムによって分割されてもよい。例えば、自動管理インスタンスのスケジュールに入れられたタスクが、区分サイズおよび「熱」（例えば、各区分を対象とするトラフィック）を監視してもよく、分割を行うために分割ツール／プロセスを使用するときを判定するポリシーを適用してもよい。いくつかの実施形態では、分割ツールおよび自動管理インスタンスは、ロックマネージャを採用することによって、２つの分割を同時に試行することを回避してもよい。

【0178】

いくつかの実施形態では、監視構成要素が、分割基準を満たす区分のリストを、分割ツール／プロセスに提供してもよい。基準は、区分サイズおよび熱に基づいてもよく、熱は、（ＩＯＰＳ等の）内部で測定された測定基準、（待ち時間等の）外部から測定された測定基準、および／または他の要因によって追跡されてもよい。いくつかの実施形態では、分割ツール／プロセスは、分割する区分の区分ＩＤおよびバージョン番号と、新しい区分／複製の場所（複数可）のためのマシン（例えば、軽負荷であることが分かっている同一のクラスタまたは貯蔵サイロの中のマシン）のリストとを含む、監視構成要素から区分を分割する要求を受信してもよい。分割ツール／プロセスへの入力としてバージョン番号を含むことにより、バージョン番号が合致しない場合に分割ツール／プロセスが要求を拒絶し得るため、分割ツール／プロセスは、分割基準に対して評価された最後の時以来、１回以上の再構成をすでに受けている区分を分割しようとしないことを確実にしてもよい。

【0179】

記憶サービスクライアントの代わりにデータ記憶サービスによって維持されているテーブルの区分を分割するための方法の一実施形態が、図２１でフロー図によって図示されている。この実施例では、本方法は、２１１０の場合のように、区分を分割する要求を受信するデータ記憶サービスを実装する、システムの構成要素を含んでもよい。例えば、本システムは、クライアント／ユーザまたはシステム管理者から、区分を分割する明示的な要求を受信してもよく、またはそのような要求は、（以下でさらに詳細に説明されるように）異常の検出に応答して、本システムにおいて自動的に生成されてもよい。上記で説明されるように、いくつかの実施形態では、区分を分割することは、区分の追加の複製を作成し、次いで、元の区分のそれぞれの部分のマネージャとして、複製の総数の半分を指定することを含んでもよい。したがって、２１２０で図示されるように、区分を分割する要求の受信に応答して、本システムは、ソース区分の元の複製のうちの１つ以上がライブである間に（すなわち、これらの複製のうちの１つ以上が、区分を対象とする要求を受け入れて果たし続けている間に）１つ以上の新しい区分（宛先区分と呼ばれ得る）の作成を開始するように構成されてもよい。２１３０で図示されるように、本方法は、（上記で説明されるもの等の）物理的コピー機構を使用して、ソース区分を宛先複製にコピーすることを含んでもよい。例えば、本システムは、いくつかの実施形態では、ファイルコピー機構を使用して、区分の元の複製のうちの１つから宛先複製のうちの１つ以上の区分へ、テーブル区分データをコピーするように構成されてもよい。本方法はまた、（例えば、上記で説明されるように、追い上げ動作を行うことによって）新しい複製を（いったんデータ投入されると）最新にすることを含んでもよい。

【0180】

この実施例で図示されるように、本方法は、２１４０の場合のように、区分を分割するように、および分割された区分の一部分を取り扱うものとして各複製を指定するように、特別な「書き込み」コマンド（すなわち、「分割」コマンド）を伝搬することを含んでもよい。いくつかの実施形態では、本システムは、区分複製を分割するコマンドが、６つの複製がホストされる記憶ノードに伝搬されている間に、ソース複製を短期間に使用されていない状態にしてもよい。分割コマンドは、単語の第１の半分または単語の第２の半分に属するものとして各複製を指定することによって、半分に分割するようにコピー動作に起因する複製に命令し、したがって、２つの新しい複製グループを形成してもよい。いくつかの実施形態では、特別な「分割」コマンドは、いかなる特別な耐久性も必要としなくてもよいことに留意されたい。

【0181】

この実施例で図示されるように、いったん「分割」コマンドが伝搬され、２つの新しい複製グループが確立されると、本方法は、２１５０の場合のように、新しい複製グループのそれぞれが、新しいマスタを選択することを含んでもよい。後に、２１６０の場合のように、区分に対する結果として生じる複製（例えば、元の複製または区分に対する結果として生じる複製の別のサブセット）の半分が、元の区分の一部分を対象とする要求を取り扱ってもよく、他の複製（例えば、宛先複製または区分に対する結果として生じる複製の別のサブセット）は、元の区分の残りを対象とする要求を取り扱ってもよい。例えば、複製のそれぞれは、その新しくより小さい範囲外にあるデータ（すなわち、それがもはや責任を持たないデータの半分）に対する要求を拒絶してもよく、複製（または複製がホストされるノード）がそのデータをもはやホストしていないという指示を返してもよい。上記で説明されるように、いくつかの実施形態では、本システムは、２１７０の場合のように、結果として生じる分割区分複製の未使用部分の論理的再生利用を行うように構成されてもよい。例えば、区分の中に新しいアイテムを記憶する要求が受信されると、これらの新しいアイテムは、（複製コピー動作に続いて）元の区分の中に記憶されたアイテムを保持したが、異なる区分の一部（すなわち、分割によって作成された２つの区分のうちの他方）として管理されている、テーブルの中の位置に記憶されてもよい。いくつかの実施形態では、本システムは、結果として生じる区分複製のそれぞれの内側のスペースを論理的に解放するためにバックグラウンドプロセスを採用してもよいが、そのスペースは、より多くのアイテムが、それらのハッシュキー属性値および／または範囲キー属性値に従って、新しい区分複製に割り当てられるテーブルに追加された場合に、後に消費されてもよい。いくつかの実施形態では、オペレーティングシステムへの分割の前に、より大きい区分複製に以前に割り付けられた、メモリの一部分を返却し得る、物理的メモリ再生利用動作が行われてもよい。そのような実施形態では、デフラグ動作も行われてもよい。

【0182】

上述のように、図１９で図示され、上記で説明される区分移動プロセスは、いくつかの実施形態では、データ記憶サービスを実装するシステムにおける異常の検出に応答して、自動的に（例えば、プログラムで）開始されてもよい。異常の検出に応答して、記憶サービスクライアントの代わりにデータ記憶サービスによって維持されているテーブルの区分を移動させるための方法の一実施形態が、図２２でフロー図によって図示されている。２２１０で図示されるように、この実施例では、本方法は、システムの構成要素が、テーブルの区分の複製をホストしている物理的コンピューティングノードまたは記憶デバイス上の故障または障害を検出することを含んでもよい。いくつかの実施形態では、障害または故障が検出されたノード上でホストされる区分複製が、その複製グループに対するマスタであった場合、本方法は、２２２０の場合のように、複製グループに対する新しいマスタを選択することを含んでもよい。この実施例では、本方法は、２２３０の場合のように、ソース区分複製がライブである間に（すなわち、区分の複製のうちの１つ以上が、区分を対象とする要求を受け入れて果たし続けている間に）、本システムが、代替区分複製の作成を開始することを含んでもよい。

【0183】

この実施例で図示されるように、本方法は、（２２４０の場合のように）物理的コピー機構を使用して、ソース区分複製を新たに作成された代替区分複製にコピーし、（２２５０の場合のように）新たに作成された代替区分複製においてまだ反映されていない区分データへの任意の変更を調整するように、追い上げ動作を行うことを含んでもよい。例えば、ソース区分複製は、論理的コピー動作（例えば、行ごとにテーブルデータを読み取ってコピーする動作）を使用するよりもむしろ、区分データの物理的位置をコピーする動作を使用して、代替区分複製にコピーされてもよい。種々の実施形態では、障害のあるマシンの区分複製は、ソース区分複製として使用されてもよく、または（作業マシン上の）同一の区分に対する別の複製は、例えば、検出された障害のタイプおよび／または重大度に応じて、ソース区分複製として使用されてもよい。

【0184】

上述のように、上記で説明され、図１９および２０で図示される区分移動プロセス、および図２１で図示され、上記で説明される区分分割プロセスは、いくつかの実施形態では、データ記憶サービスを実装するシステムにおける異常の検出に応答して、自動的に（例えば、プログラムで）開始されてもよい。例えば、ホットスポットが、データ記憶サービスの基礎にある本システム内の特定のコンピューティングノードまたは記憶デバイス上で発生する場合、本システムは、そのコンピューティングノードまたは記憶デバイス上に記憶された１つ以上の区分複製を分割し、および／または移動させるように構成されてもよい。ホットスポットの検出に応答して、記憶サービスクライアントの代わりにデータ記憶サービスによって維持されているテーブルの区分の複製を分割する、または移動させるための方法の一実施形態が、図２３でフロー図によって図示されている。２３１０で図示されるように、この実施例では、本方法は、システムの構成要素が、テーブルの区分の特定の複製をホストしている物理的コンピューティングノードまたは記憶デバイス上のホットスポットを検出することを含んでもよい。言い換えれば、本システムは、システム内の他のコンピューティングノードまたは記憶デバイスと比較して、コンピューティングノードまたは記憶デバイスが、高レベルのトラフィックを体験していることを検出してもよい。場合によっては、この激しいトラフィックの全てまたは一部分が、特定の区分複製自体を対象としてもよい一方で、他の場合においては、激しいトラフィックは、コンピューティングノードまたは記憶デバイス上でホストされている他の区分複製、テーブル、またはアプリケーションを対象としてもよい。

【0185】

この実施例で図示されるように、ホットスポットの検出に応答して、本システムは、待ち時間を削減すること、システムにおける全体的なスループットを増加させること、または別様にデータ記憶サービスの性能を向上させること等によって、ホットスポットの効果を低減させようとして、特定の区分を移動させ、および／または分割するように構成されてもよい。ホットスポットが、単一の区分を標的にするトラフィックによるものである場合、２３１５からの肯定の出口として示され、本方法は、その区分の分割を開始することを含んでもよい。いくつかの実施形態では、本システムは、２３２０の場合のように、ソース区分の元の複製のうちの１つ以上がライブである間に（すなわち、これらの複製のうちの１つ以上が、区分を対象とする要求を受け入れて果たし続けている間に）、１つ以上の新しい区分（宛先区分と呼ばれ得る）を作成するように構成されてもよい。例えば、本システムは、ホットスポットが検出されたものほど高負荷ではないコンピューティングノードまたは記憶デバイス上で１つ以上の宛先複製を作成するように構成されてもよい。２３３０で図示されるように、本方法は、（上記で説明されるもの等の）物理的コピー機構を使用して、ソース区分複製を宛先複製にコピーすることを含んでもよい。例えば、本システムは、いくつかの実施形態では、ファイルコピー機構を使用して、区分の元の複製のうちの１つ（例えば、高負荷のコンピューティングノードまたは記憶デバイス上でホストされる区分複製、あるいは異なるコンピューティングノードまたは記憶デバイス上でホストされる特定の区分の複製のうちの別の１つ）から宛先複製のうちの１つ以上へ、テーブル区分データをコピーするように構成されてもよい。本方法はまた、２３４０の場合のように、（例えば、上記で説明されるように、追い上げ動作を行うことによって）新しい複製を（いったんデータ投入されると）最新にすることを含んでもよい。

【0186】

この実施例では、本方法は、２３６０の場合のように、区分を分割するように、および分割された区分の一部分を取り扱うものとして各複製を指定するように、特別な「分割」コマンドを伝搬することを含んでもよい。「分割」コマンドの伝搬後、区分に対する結果として生じる複製の半分（すなわち、１つの新しい複製グループ）は、元の区分の一部分を対象とする要求を取り扱ってもよく、他の複製（すなわち、第２の新しい複製グループ）は、元の区分の残りを対象とする要求を取り扱ってもよい。２３８０で図示されるように、本方法は、２３８０の場合のように、新しい複製グループのそれぞれに対する新しいマスタを選択することを含んでもよい。上記で説明されるように、いくつかの実施形態では、本システムは、結果として生じる分割区分複製の未使用部分の論理的再生利用を行うように構成されてもよい（図示せず）。そのような実施形態では、区分の中に新しいアイテムを記憶する要求が受信されると、これらの新しいアイテムは、元の区分複製の中に記憶されたアイテムを保持したが、異なる区分の一部（分割によって作成された２つの新しい複製グループのうちの他方）として現在管理されている、テーブルの中の位置に記憶されてもよい。

【0187】

図２３で図示されるように、ホットスポットが、単一の区分を標的にするトラフィックによるものではない場合（例えば、コンピューティングノードまたは記憶デバイス上でホストされている複数の区分複製、テーブル、またはアプリケーションを対象とするトラフィックによるものである場合）、本方法は、高トラフィックノードから区分複製のうちの１つを除去するように、それの移動を開始することを含んでもよい。これは、２３１５からの否定の出口によって図２３で図示されている。この場合、本方法は、（２３３０の場合のように）移動させられている複製が、その複製グループに対するマスタであった場合、複製グループに対する新しいマスタを選択することを含んでもよい。この実施例で図示されるように、本方法は、２３５０の場合のように、複製が移動させられている、区分の１つ以上の複製がライブである間に、別のコンピューティングノードまたは記憶デバイス上で新しい複製を作成することを含んでもよい。いくつかの実施形態では、２３７０の場合のように、移動させられている区分複製は、（本明細書で説明されるもの等の）物理的コピー機構を使用して、この新しい宛先複製にコピーされてもよく、宛先複製は、いったんコピーが完成すると、追い上げ機構を使用して最新にされてもよい。いったん宛先複製がデータ投入され、最新にされると、２３９０の場合のように、新しい宛先にコピーされた区分複製が、高トラフィックノードから除去されてもよい。後に、その区分を対象とするトラフィックは、他のノード（あまり高負荷ではないノード）上の宛先複製を対象としてもよい。

【0188】

いくつかの実施形態では、データ記憶サービスを実装するシステム内のコンピューティングノードまたは記憶デバイス上のホットスポットの検出に応答して、本システムは、区分分割および１回以上の複製移動（複数可）の両方を行ってもよいことに留意されたい。例えば、激しいトラフィックを体験している区分を分割した後、ホットノード上でホストされた分割区分に対する複製はまた、本明細書で説明される物理的コピー機構を使用して、ホットノードから新しいホストノードへ移動させられてもよい。加えて、区分分割に起因する新しい複製グループのうちのいずれか一方の中の他の複製のうちのいずれかが、ホットノード上でホストされる場合、それらはまた、他のノードへ移動させられてもよい。いくつかの実施形態では、区分を移動させ、および／または分割するための図２３で図示される方法に類似する方法が、増加するテーブルサイズの検出に応答して適用されてもよいことに留意されたい。例えば、より多くのアイテムが所与のテーブルに追加されるにつれて、新しい区分（およびその対応する複製）を追加するため、したがって、テーブルの自動規模変更を提供するために、そのような方法が使用されてもよい。

【0189】

１つ以上の記憶サービスクライアントの代わりに、複数のテーブルを維持および管理するための方法の一実施形態が、図２４でフロー図によって図示されている。２４１０で図示されるように、この実施例では、本方法は、１人以上の記憶サービスクライアントからの要求を果たしながら、データ記憶サービスを実装するシステムにおいて異常を検出することを含んでもよい。いくつかの実施形態では、本システムは、テーブルを規模変更すること、区分を移動させること、区分を分割すること、および／または本明細書で説明されていない他のアクションを講じること等によって、種々のタイプの異常の検出に自動的に（例えば、プログラムで）応答するように構成されてもよい。例えば、故障した、または障害のあるノード（例えば、コンピューティングノードまたは記憶デバイス）が検出された場合（２４２０の場合のように）、本システムは、故障した、または障害のあるノードを新しいノードと交換するように、および／または、故障した、または障害のあるノード上でホストされるいずれかまたは全ての区分を新しいノードにコピーするように、構成されてもよい（２４２５の場合のように）。前述のように、故障した、または障害のあるノードが、その複製グループに対するマスタであった区分複製をホストした場合、本システムはまた、区分を新しいノードにコピーした後に、新しいマスタを選択するように構成されてもよい。

【0190】

ホットスポットまたは増加するテーブルサイズが検出された場合（２４３０の場合のように）、本システムは、（例えば、ホットスポットが検出されたもの以外のコンピューティングノードまたは記憶デバイス上で）１つ以上の新しい区分および対応する複製を追加するように、ならびに新しい区分または複製のうちの１つ以上において高負荷のコンピューティングノードまたは記憶デバイス上でホストされたデータを移動させ、および／または分割するように構成されてもよい（２４３５の場合のように）。同様に、ベストエフォート型スループット標的（または別のユーザ選好）が満たされていない、または増加するトラフィックにより満たされない危険があることを本システムが検出した場合、あるいはデータ量がテーブルの標的容量を超えて増加している場合（２４４０の場合のように）、本システムは、状況を訂正しようとしながら、着信サービス要求を抑制するように構成されてもよい。再度、本システムは、（例えば、ホットスポットが検出されたもの以外のコンピューティングノードまたは記憶デバイス上で）１つ以上の新しい区分および対応する複製を追加するように、ならびに新しい区分または複製のうちの１つ以上において高負荷のコンピューティングノードまたは記憶デバイス上でホストされたデータを移動させ、および／または分割するように構成されてもよい（２４４５の場合のように）。同様に、２４５０の場合のように、ライブ再区分が（例えば、テーブル所有者によって）明示的に要求された場合、本システムは、それに従って、１つ以上の新しい区分および対応する複製を追加または除去するように、あるいは新しい区分または複製のうちの１つ以上において高負荷のコンピューティングノードまたは記憶デバイス上でホストされたデータを移動させ、および／または分割するように構成されてもよい（２４５５の場合のように）。

【0191】

別のタイプの異常が検出され（２４２０、２４３０、２４４０、および２４５０の否定の出力として示される）、本システムが、その異常の指標に応答した、および／または指標を返した場合（２４６０の場合のように）、またはいったん本システムが上記で説明される異常のうちの１つへの応答として始動すると（２４２５、２４３５、２４４５、または２４５５の場合のように）、本システムは、２４６５の場合のように、着信要求を果たし続けてもよい。いくつかの実施形態では、本システムは、追加の異常が検出されるまで、または検出されない限り、２４６５の場合のように、動作を継続するように（例えば、着信サービス要求を果たし続けるように）構成されてもよい。これは、２４７０から２４６５へのフィードバックによって図２４で図示される。任意の追加の異常が検出された場合、２４７０からの肯定の出口として示され、２４２０〜２４６０として示される動作のうちのいずれかまたは全ては、データ記憶サービスクライアントの代わりにテーブルを維持および管理するために、システムによって繰り返されてもよい。これは、２４７０から２４２０へのフィードバックによって図２４で図示される。いくつかの実施形態では、データ記憶サービスが動作中である間に、図２４で図示される動作のうちのいずれかまたは全ては、バックグラウンドタスクによって積極的（および自動的）に行われてもよく、必ずしも任意の特定のサービス要求の受信に応答して行われなくてもよいことに留意されたい。

【0192】

以下の付記を考慮して、本開示の種々の実施形態を説明することができる。

付記１．
データ記憶サービスを集合的に実装する、それぞれ、少なくとも１つのプロセッサと、メモリとを備える、複数のコンピューティングノードを備え、
前記複数のコンピューティングノードは、
それを通してサービス要求が受信される、ウェブサービスインターフェースを提供し、処理するためにサービス要求を解析および発送するように構成される、フロントエンドモジュールと、
システム内のリソースを割り付けるように、前記システムの状態を監視するように、およびサービス要求が果たされている間に前記システムにおいて体験される異常を検出するように構成される、管理構成要素と、
非リレーショナルデータ記憶部を集合的に実装する、複数の記憶ノードと、
を備え、
前記フロントエンドモジュールが記憶サービスクライアントの代わりにテーブルを作成するサービス要求を受信することに応答して、前記サービス要求は、前記テーブルの中に記憶されたアイテムを区分してインデックス作成する、テーブル名および一次キーを特定し、
前記フロントエンドモジュールは、前記サービス要求を前記複数の記憶ノードのうちの１つに発送するように構成され、
前記サービス要求の受信に応答して、前記複数の記憶ノードのうちの前記１つは、前記非リレーショナルデータ記憶部の中で規模変更可能なテーブルを作成するように構成され、前記規模変更可能なテーブルは、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、前記規模変更可能なテーブルは、所定のサイズ制限を持たず、
前記規模変更可能なテーブルが作成された後、前記管理構成要素は、前記システムにおける異常の検出に応答して、あるいは前記規模変更可能なテーブルの中のアイテムを記憶する、読み出す、修正する、または削除する１つ以上のサービス要求の受信に応答して、プログラムで前記規模変更可能なテーブルをサイズ決定または区分させるように構成される、
システム。

付記２．
前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含み、
前記データ記憶サービスによって維持される１つ以上のテーブルを記述するサービス要求の受信に応答して、前記非リレーショナルデータ記憶部は、前記１つ以上のテーブルに関する情報を返すように構成され、前記１つ以上のテーブルに関する前記情報は、前記非同期テーブル作成ワークフローによって前記規模変更可能なテーブルの作成が成功したかどうかを示す情報を含む、
付記１に記載のシステム。

付記３．
前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上のサービス要求の受信に応答して、前記管理構成要素は、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定し、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルをプログラムで区分することを行うように構成される、
付記１に記載のシステム。

付記４．
前記一次キーは、ハッシュキー属性として指定される単一の属性を備え、
前記規模変更可能なテーブルを区分することは、それらのそれぞれのハッシュキー属性値のハッシュに依存して、前記規模変更可能なテーブルの中の前記アイテムを２つ以上の区分に分割することを含む、
付記１に記載のシステム。

付記５．
テーブルを作成する前記サービス要求はさらに、１つ以上のユーザ選好の指示を備え、前記１つ以上のユーザ選好は、好ましいサービス要求スループットレベル、または保証が要求されるサービス要求スループットレベルを備え、
前記管理構成要素は、前記ユーザ選好のうちの１つ以上が満たされていないという検出に応答して、プログラムで前記規模変更可能なテーブルをサイズ決定または区分させるように構成される、
付記１に記載のシステム。

付記６． プログラムで前記規模変更可能なテーブルを区分させることは、前記フロントエンドモジュールが、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求を受信することに応答して行われる、付記１に記載のシステム。

付記７．
コンピュータによって、
要求が、テーブルの識別子、および前記テーブルの中に記憶されたアイテムにインデックス作成する一次キーを特定する、非リレーショナルデータ記憶部の中で前記テーブルを作成する要求を受信することと、
前記受信に応答して、
規模変更可能なテーブルが、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、前記規模変更可能なテーブルが、所定のサイズ制限を持たない、前記非リレーショナルデータ記憶部の中で前記規模変更可能なテーブルを作成することと、
前記規模変更可能なテーブルにアクセスする１つ以上の要求の受信に応答して、前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うことと、
を含む、方法。

付記８． 前記規模変更可能なテーブルにアクセスする前記１つ以上の要求は、前記規模変更可能なテーブルの中のアイテムを記憶する、読み出す、修正する、または削除する１つ以上の要求を含む、付記７に記載の方法。

付記９． 前記規模変更可能なテーブルを作成することは、
前記複数のコンピューティングノードのうちの１つ以上の状態を反映する情報を収集することと、
前記収集された情報に依存して、前記規模変更可能なテーブルを作成する１つ以上のコンピューティングノードを判定することと、
を含む、付記７に記載の方法。

付記１０． 前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含み、
前記方法はさらに、
前記非リレーショナルデータ記憶部の中で維持された１つ以上のテーブルを記述する要求を受信することと、
１つ以上のテーブルを記述する前記要求の受信に応答して、１つ以上のテーブルに関する情報が、前記非同期テーブル作成ワークフローによって前記規模変更可能なテーブルの作成が成功したかどうかを示す情報を含む、前記１つ以上のテーブルに関する前記情報を返すことと、
を含む、付記７に記載の方法。


付記１１． 前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上の要求を受信することと、
前記１つ以上の要求の受信に応答して、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定することと、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルをプログラムで区分することを行うことと、
をさらに含む、付記７に記載の方法。

付記１２． 前記一次キーは、ハッシュキー属性として指定される単一の属性を備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値を備え、
前記規模変更可能なテーブルをプログラムで区分することは、それらのそれぞれのハッシュキー属性値のハッシュに依存して、前記規模変更可能なテーブルの中の前記アイテムを２つ以上の区分に分割することを含む、
付記７に記載の方法。


付記１３． 前記一次キーは、ハッシュキー属性として指定される属性と、範囲キー属性として指定される別の属性とを備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値と、前記範囲キー属性のそれぞれの値とを備え、
前記範囲キー属性値は、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中の全てのアイテムの中から、特定のアイテムを一意的に識別し、前記同一のハッシュキーを有する前記アイテムは、それらのそれぞれの範囲キー属性値に従って順序付けられ、
前記規模変更可能なテーブルをプログラムで区分することは、それらのそれぞれの範囲キー属性値に依存して、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中のアイテムを２つ以上の区分に分割することを含む、
付記７に記載の方法。

付記１４． 前記規模変更可能なテーブルをプログラムで区分することは、前記規模変更可能なテーブルを２つ以上の区分に分割することと、複数のコンピューティングノードのうちの異なるものの上に、前記２つの区分のそれぞれを記憶することとを含む、付記７に記載の方法。

付記１５． 前記規模変更可能なテーブルをプログラムで区分することは、区分の１つ以上の複製が要求を受け入れて処理し続けている間に、前記規模変更可能なテーブルの前記区分を移動させること、または分割することを含む、付記７に記載の方法。

付記１６． 前記規模変更可能なテーブルをプログラムで区分することは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求の受信に応答して、あるいは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、減少する数の要求の受信に応答して行われる、付記７に記載の方法。

付記１７． テーブルを作成する前記要求はさらに、１つ以上のユーザ選好の指示を備え、前記１つ以上のユーザ選好は、好ましいサービス要求スループットレベル、または保証が要求されるサービス要求スループットレベルを備え、
前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うことは、前記ユーザ選好のうちの１つ以上が満たされていないという検出に応答して行われる、
付記７に記載の方法。

付記１８．
要求が、好ましい一貫性モデルの指示を含む、前記規模変更可能なテーブルから１つ以上のアイテムを読み出す要求を受信することと、
前記１つ以上のアイテムを読み出す前記要求の受信に応答して、前記好ましい一貫性モデルと一致する方式で前記１つ以上のアイテムを返すことと、
をさらに含む、付記７に記載の方法。

付記１９． 前記作成することは、
前記規模変更可能なテーブルと関連付けられるメタデータを生成することと、
前記非リレーショナルデータ記憶部内の別の規模変更可能なテーブルの中に前記メタデータを記憶することと、
を含む、付記７に記載の方法。

付記２０． １つ以上のコンピュータ上で実行されたときに、前記１つ以上のコンピュータに、
サービス要求が、テーブルの識別子、および前記テーブルの中に記憶されたアイテムにインデックス作成する一次キーを特定する、記憶サービスクライアントの代わりに前記テーブルを作成するサービス要求を受信することと、
前記受信に応答して、
前記規模変更可能なテーブルが、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、前記規模変更可能なテーブルが、所定のサイズ制限を持たない、非リレーショナルデータ記憶部の中で前記規模変更可能なテーブルを作成することと、
前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上のサービス要求の受信に応答して、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定することと、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルを区分することと、
を行わせる、プログラム命令を記憶する、非一過性のコンピュータ可読媒体。

付記２１． 前記１つ以上のコンピュータ上で実行されたとき、前記プログラム命令はさらに、前記１つ以上のコンピュータに、
前記規模変更可能なテーブルを区分した後、前記規模変更可能なテーブルの中のアイテムを記憶する、読み出す、修正する、または削除する１つ以上のサービス要求の受信に応答して、前記規模変更可能なテーブルのサイズ決定または再区分化のうちの少なくとも１つを行うことを行わせる、
付記２０に記載の記憶媒体。

付記２２． 前記規模変更可能なテーブルの前記再区分化は、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求の受信に応答して、あるいは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、減少する数の要求の受信に応答して行われる、付記２１に記載の記憶媒体。

付記２３． 前記規模変更可能なテーブルを作成することは、
前記複数のコンピューティングノードのうちの１つ以上の状態を反映する情報を収集することと、
前記収集された情報に依存して、前記規模変更可能なテーブルを作成する１つ以上のコンピューティングノードを判定することと、
前記１つ以上のコンピューティングノードのそれぞれの上に前記規模変更可能なテーブルの少なくともサブセットを記憶するためのそれぞれの区分を作成することと、
を含む、付記２０に記載の記憶媒体。

付記２４．
前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含み、
前記非リレーショナルデータ記憶部の中で維持された１つ以上のテーブルを記述するサービス要求の受信に応答して、前記プログラム命令はさらに、前記１つ以上のコンピュータに、前記１つ以上のテーブルに関する情報を返すことを行わせ、前記１つ以上のテーブルに関する前記情報は、前記非同期テーブル作成ワークフローによって前記規模変更可能なテーブルの作成が成功したかどうかを示す情報を含む、
付記２０に記載の記憶媒体。

付記２５．
前記一次キーは、ハッシュキー属性として指定される単一の属性を備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値を備え、
前記規模変更可能なテーブルを区分することは、それらのそれぞれのハッシュキー属性値のハッシュに依存して、前記規模変更可能なテーブルの中の前記アイテムを２つ以上の区分に分割することを含む、
付記２０に記載の記憶媒体。

付記２６． 前記規模変更可能なテーブルを区分することは、前記規模変更可能なテーブルを２つ以上の区分に分割することと、複数のコンピューティングノードのうちの異なるものの上に、前記２つ以上の区分のそれぞれを記憶することとを含む、付記２０に記載の記憶媒体。

付記２７．
前記一次キーは、ハッシュキー属性として指定される属性と、範囲キー属性として指定される別の属性とを備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値と、前記範囲キー属性のそれぞれの値とを備え、
前記範囲キー属性値は、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中の全てのアイテムの中から、特定のアイテムを一意的に識別し、前記同一のハッシュキーを有する前記アイテムは、それらのそれぞれの範囲キー属性値に従って順序付けられ、
前記規模変更可能なテーブルを区分することは、それらのそれぞれの範囲キー属性値に依存して、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中のアイテムを２つ以上の区分に分割することを含む、
付記２０に記載の記憶媒体。

付記２８．
それぞれ、少なくとも１つのプロセッサと、メモリとを備える、複数のコンピューティングノードを備える、システムであって、前記複数のコンピューティングノードは、データ記憶サービスを実装するように構成され、
記憶サービスクライアントの代わりにテーブルを作成するサービス要求の受信に応答して、前記サービス要求は、前記テーブルの識別子、および前記テーブルの中に記憶されたアイテムにインデックス作成する一次キーを特定し、前記データ記憶サービスは、非リレーショナルデータ記憶部の中で規模変更可能なテーブルを作成するように構成され、
前記規模変更可能なテーブルは、それぞれが前記一次キーの値を含む、複数のアイテムを記憶するように構成され、
前記規模変更可能なテーブルは、所定のサイズ制限を持たず、
前記規模変更可能なテーブルを作成することは、非同期テーブル作成ワークフローの実施を開始することを含む、
システム。

付記２９．
前記データ記憶サービスによって維持された１つ以上のテーブルを記述するサービス要求の受信に応答して、前記データ記憶サービスは、前記１つ以上のテーブルに関する情報を返すように構成され、
前記１つ以上のテーブルに関する前記情報は、前記非同期テーブル作成ワークフローによって前記規模変更可能なテーブルの作成が成功したかどうかを示す情報を含む、
付記２８に記載のシステム。

付記３０． 前記データ記憶サービスはさらに、前記規模変更可能なテーブルの中のアイテムを記憶する、読み出す、修正する、または削除する１つ以上のサービス要求の受信に応答して、前記規模変更可能なテーブルのサイズ決定または区分化のうちの少なくとも１つをプログラムで行うように構成される、付記２８に記載のシステム。

付記３１．
前記規模変更可能なテーブルの中に複数のアイテムを記憶する１つ以上のサービス要求の受信に応答して、前記データ記憶サービスは、
前記複数のアイテムを、前記規模変更可能なテーブルの単一の区分の中に記憶することができるかどうかを判定し、
前記複数のアイテムを前記規模変更可能なテーブルの単一の区分の中に記憶することができないという判定に応答して、前記規模変更可能なテーブルをプログラムで区分するように構成される、
付記２８に記載のシステム。

付記３２． 前記データ記憶サービスはさらに、前記規模変更可能なテーブルをプログラムで区分することが、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、増加する数の要求の受信に応答して、あるいは、前記規模変更可能なテーブルの中のアイテム、前記規模変更可能なテーブルの特定の区分の中のアイテム、または前記規模変更可能なテーブルの中の前記アイテムの少なくともサブセットと同一のコンピューティングノード上に記憶されたアイテムを標的にする、減少する数の要求に応答して行われるように、構成される、付記２８に記載のシステム。

付記３３．
前記一次キーは、ハッシュキー属性として指定される単一の属性と、範囲キー属性として指定される別の属性とを備え、
前記規模変更可能なテーブルの中に記憶された前記アイテムのそれぞれは、前記ハッシュキー属性のそれぞれの値と、前記範囲キー属性のそれぞれの値とを備え、
前記範囲キー属性値は、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中の全てのアイテムの中から、特定のアイテムを一意的に識別し、前記同一のハッシュキーを有する前記アイテムは、それらのそれぞれの範囲キー属性値に従って順序付けられ、
前記データ記憶サービスはさらに、それらのそれぞれの範囲キー属性値に依存して、同一のハッシュキー属性値を有する前記規模変更可能なテーブルの中のアイテムを２つ以上の区分に分割するように構成される、
付記２８に記載のシステム。

付記３４． 規模変更可能なテーブルを作成することはさらに、
前記複数のコンピューティングノードのうちの１つ以上の状態を反映する情報を収集することと、
前記収集された情報に依存して、前記規模変更可能なテーブルを作成する１つ以上のコンピューティングノードを判定することと、
前記１つ以上のコンピューティングノードのそれぞれの上に前記規模変更可能なテーブルの少なくともサブセットを記憶するためのそれぞれの区分を作成することと、
を含む、付記２８に記載のシステム。

付記３５．
前記規模変更可能なテーブルから１つ以上のアイテムを読み出す要求の受信に応答して、前記要求は、好ましい一貫性モデルの指示を含み、前記データ記憶サービスは、前記好ましい一貫性モデルと一致する方式で前記１つ以上のアイテムを返すように構成される、
付記２８に記載のシステム。

【0193】

本明細書で説明される技法を採用するデータ記憶サービスの実装に好適であり得る、１つのコンピューティングノードが、図２５で図示されている。コンピューティングノード２５００は、そのようなデータ記憶サービスを実装するシステムの構成要素のうちのいずれかまたは全てを提供する機能性を含んでもよく、あるいはコンピューティングノード２５００に類似する、またはそれとは異なる複数のコンピューティングノードは、異なる実施形態で、この機能性を集合的に提供してもよい。例えば、種々の実施形態では、１つ以上のコンピューティングノード２５００は、任意の数の記憶サービスクライアント１１０、フロントエンドモジュール１４０、任意の数の自動管理インスタンス１５０、任意の数の記憶デバイス（記憶ノードインスタンス１６０等）、および／またはウェブサービスプラットフォーム１３０、自動管理クラスタ、またはウェブサービスプラットフォーム１３０と相互作用する外部リソース（単純ワークフロー構成要素１７０または外部記憶サービス１８０等）の任意の他の構成要素を実装してもよい。複数のコンピューティングノード２５００を含む、いくつかの実施形態では、コンピューティングノード２５００の全てが、同一または類似ハードウェア構成要素、ソフトウェア構成要素、および機能性を含んでもよい一方で、他の実施形態では、本明細書で説明される機能性を実装するように構成されるコンピューティングシステムを備える、コンピューティングノード２５００は、多種多様のハードウェア構成要素、ソフトウェア構成要素、および機能性を含んでもよい。いくつかの実施形態では、データ記憶サービスを集合的に実装する複数のコンピューティングノード２５００は、より大型の共有リソースシステムまたはグリッドコンピューティングシステムの構成要素であってもよい。

【0194】

図示した実施形態では、コンピューティングノード２５００は、入出力（Ｉ／Ｏ）インターフェース２５３０を介してシステムメモリ２５２０に連結される、１つ以上のプロセッサ２５１０を含んでもよい。コンピューティングノード２５００はさらに、Ｉ／Ｏインターフェース２５３０に連結されるネットワークインターフェース２５４０と、１つ以上の入出力デバイス２５５０とを含む。上述のように、いくつかの実施形態では、所与のノードは、本明細書で説明されるもの等の、データ記憶サービスクライアントの代わりにテーブルの中で（例えば、非リレーショナルデータベースの中で）データを管理および維持する、システムの１つよりも多くの構成要素の機能性を実装してもよい。種々の実施形態では、コンピューティングノード２５００は、１つのプロセッサ２５１０を含むユニプロセッサシステム、またはいくつかのプロセッサ２５１０（例えば、２、４、８、または別の好適な数）を含むマルチプロセッサシステムであってもよい。プロセッサ２５１０は、命令を実行することが可能である任意の好適なプロセッサであってもよい。例えば、種々の実施形態では、プロセッサ２５１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ ＩＳＡ等の種々の命令セットアーキテクチャ（ＩＳＡ）のうちのいずれか、あるいは任意の他の好適なＩＳＡを実装する、汎用または組み込みプロセッサであってもよい。マルチプロセッサシステムでは、プロセッサ２５１０のそれぞれは、必ずではないが一般的に、同一のＩＳＡを実装してもよい。同様に、データ記憶サービスを集合的に実装するもの等の分散コンピューティングシステムでは、コンピューティングノードのそれぞれは、同一のＩＳＡを実装してもよく、あるいは個々のコンピューティングノードおよび／またはノードの複製グループは、異なるＩＳＡを実装してもよい。

【0195】

いくつかの実施形態では、システムメモリ２５２０は、プロセッサ（複数可）２５１０によってアクセス可能なプログラム命令および／またはデータを記憶するように構成される、非一過性のコンピュータ可読記憶媒体を含んでもよい。種々の実施形態では、システムメモリ２５２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意の他のタイプのメモリ等の任意の好適なメモリ技術を使用して実装されてもよい。図示した実施形態では、上記で説明されるもの等の所望の機能を実装するプログラム命令およびデータは、それぞれ、プログラム命令２５２５およびデータ記憶装置２５３５としてシステムメモリ２５２０内に記憶されて示されている。例えば、プログラム命令２５２５は、プロセッサ（複数可）２５１０上で実行されたときに、記憶サービスクライアント１１０、フロントエンドモジュール１４０（ユーザインターフェースを含み得る）、自動管理インスタンス１５０、記憶ノードインスタンス１６０、管理コンソール２６５、要求ルータ、ステージングホスト、１つ以上のメタデータテーブル、単純ワークフロー構成要素１７０、外部記憶サービス１８０、および／または本明細書で説明されるデータ記憶サービスを提供するシステムの任意の他の構成要素、モジュール、またはサブモジュールのうちのいずれかまたは全てを実装する、プログラム命令を含んでもよい。プログラム命令２５２５はまた、本明細書で説明されていないデータ記憶サービスを実装するシステムの追加の機能性を実装するように構成される、プログラム命令を含んでもよい。

【0196】

データ記憶装置２５３５は、種々の実施形態では、そのクライアント／ユーザの代わりにデータ記憶サービスによって維持されるデータの集合、および／または本明細書で説明されるように、そのようなサービスを実装するコンピューティングシステムによって使用されるメタデータ（限定されないが、サービスのクライアント／ユーザの代わりに管理および維持されるテーブル、メタデータテーブル、ビジネスルール、区分マップ、ルーティングテーブル、インデックス、ネームスペースおよび／またはその区分、サービスレベル合意パラメータ値、加入者選好および／またはアカウント情報、性能データ、および／またはリソース使用データを含む）を含んでもよい。他の実施形態では、上記で説明される技法を採用するデータ記憶サービスを実装するための本明細書で説明されるようなプログラム命令および／またはデータが、受信され、送信され、または異なるタイプのコンピュータ可読媒体上で、あるいはシステムメモリ２５２０またはコンピューティングノード２５００から分離した類似媒体上で記憶されてもよい。一般的に言えば、コンピュータ可読媒体は、磁気または光学媒体、例えば、Ｉ／Ｏインターフェース２５３０を介してコンピューティングノード２５００に連結されたディスクまたはＣＤ／ＤＶＤ−ＲＯＭ等の記憶媒体またはメモリ媒体を含んでもよい。コンピュータ可読記憶媒体上に記憶されたプログラム命令およびデータは、ネットワークインターフェース２５４０を介して実装され得るようなネットワークおよび／または無線リンク等の通信媒体を介して伝えられ得る、電気、電磁、またはデジタル信号等の伝送媒体または信号によって、プロセッサ２５１０ａによる実行のためにコンピューティングノード２５００に伝送されてもよい。

【0197】

一実施形態では、Ｉ／Ｏインターフェース２５３０は、ネットワークインターフェース２５４０または入出力デバイス２５５０等の他の周辺インターフェースを含む、コンピューティングノードの中で、プロセッサ（複数可）２５１０、システムメモリ２５２０、および任意の周辺デバイスの間のＩ／Ｏトラフィックを協調させるように構成されてもよい。いくつかの実施形態では、Ｉ／Ｏインターフェース２５３０は、１つの構成要素（例えば、システムメモリ２５２０）からのデータ信号を、別の構成要素（例えば、プロセッサ２５１０）による使用のために好適な形式に変換するように、任意の必要なプロトコル、タイミング、または他のデータ変換を行ってもよい。いくつかの実施形態では、Ｉ／Ｏインターフェース２５３０は、例えば、ペリフェラルコンポーネントインターコネクト（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ；ＰＣＩ）バス標準またはユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ；ＵＳＢ）標準の変形型等の種々のタイプの周辺バスを通して取り付けられたデバイスのサポートを含んでもよい。いくつかの実施形態では、Ｉ／Ｏインターフェース２５３０の機能は、例えば、ノースブリッジおよびサウスブリッジ等の２つ以上の別個の構成要素に分割されてもよい。また、いくつかの実施形態では、システムメモリ２５２０へのインターフェース等のＩ／Ｏインターフェース２５３０の機能性のうちのいくつかまたは全てが、プロセッサ２５１０に直接組み込まれてもよい。

【0198】

ネットワークインターフェース２５４０は、コンピューティングノード２５００とネットワークに取り付けられた他のデバイス（他のコンピュータシステム、通信デバイス、入出力デバイス、または外部記憶デバイス等）との間で、または共有コンピューティングサービスを提供するシステム内の他のノードの間で、データが交換されることを可能にするように構成されてもよい。種々の実施形態では、ネットワークインターフェース２５４０は、任意の好適なタイプのイーサネット（登録商標）ネットワーク等の有線または無線一般データネットワークを介した、例えば、アナログ音声ネットワークまたはデジタルファイバ通信ネットワーク等の電気通信／電話ネットワークを介した、ファイバチャネルＳＡＮ等の記憶領域ネットワークを介した、または任意の他の好適なタイプのネットワークおよび／またはプロトコルを介した、通信をサポートしてもよい。

【0199】

入出力デバイス２５５０は、いくつかの実施形態では、１つ以上の表示端末、キーボード、キーパッド、タッチパッド、スキャンデバイス、音声または光学認識デバイス、あるいは１つ以上のコンピューティングノード２５００によってデータを入力する、または読み出すために好適である任意の他のデバイスを含んでもよい。複数の入出力デバイス２５５０は、コンピューティングノード２５００の中に存在してもよく、またはデータ記憶サービスを実装するように構成されるシステムの種々のコンピューティングノード上で分配されてもよい。いくつかの実施形態では、類似の入出力デバイスは、コンピューティングノード２５００から分離していてもよく、ネットワークインターフェース２５４０上等で有線または無線接続を通してシステムの１つ以上のコンピューティングノードと相互作用してもよい。

【0200】

記憶サービスクライアント（例えば、ユーザ、加入者、および／またはクライアントアプリケーション）は、サービスに対する要求を提出するため（限定されないが、テーブルの中のアイテムを記憶する、読み出す、および／または更新する要求、あるいはテーブルを再区分する要求を含む）、および結果を受信するため等に、異なる実施形態において種々の方法で、本明細書で説明されるもの等のデータ記憶サービスと相互作用してもよい。例えば、サービスへの一部の加入者が、コンピューティングノード２５００への物理的アクセスを有してもよく、該当する場合、情報を提供および／または受信するように、種々の入出力デバイス２５５０と相互作用してもよい。代替として、他のクライアント／ユーザは、ネットワークインターフェース２５４０を介して（例えば、インターネットおよび／またはワールドワイドウェブを介して）遠隔等で、システムにアクセスするためにクライアントコンピューティングシステムを使用してもよい。加えて、サービスを提供するシステムのコンピューティングノードのうちのいくつかまたは全ては、（例えば、ユーザ要求に応答して）１つ以上の入出力デバイス２５５０を介して、種々のフィードバックまたは他の一般タイプの情報をクライアント／ユーザに提供してもよい。

【0201】

当業者であれば、コンピューティングノード２５００が例証的にすぎず、実施形態の範囲を限定することを目的としていないと理解するであろう。具体的には、コンピューティングシステムおよびデバイスは、コンピュータ、ネットワークデバイス、インターネットアプライアンス、ＰＤＡ、無線電話、ポケットベル等を含む、指示された機能を果たすことができるハードウェアまたはソフトウェアの任意の組み合わせを含んでもよい。コンピューティングノード２５００はまた、いくつかの実施形態では、図示されていない他のデバイスに接続されてもよい。加えて、図示した構成要素によって提供される機能性は、いくつかの実施形態では、より少ない構成要素に組み込まれ、または追加の構成要素の中で分配されてもよい。同様に、いくつかの実施形態では、図示した構成要素のうちのいくつかの機能性は、提供されなくてもよく、および／または他の追加の機能性が利用可能であり得る。

【0202】

当業者であればまた、種々のアイテムが、使用されている間にメモリの中または記憶装置上に記憶されるものとして図示されているが、これらのアイテムまたはそれらの部分は、メモリ管理およびデータ完全性の目的でメモリと他の記憶デバイスとの間で転送されてもよいことも理解するであろう。代替として、他の実施形態では、ソフトウェア構成要素のうちのいくつかまたは全てが、別のデバイス上のメモリの中で実行し、コンピュータ間通信を介して、図示したコンピューティングシステムと通信してもよい。システム構成要素またはデータ構造のうちのいくつかまたは全てはまた、その種々の実施例が上記で説明される、適切なドライブによって読み取られる、コンピュータ可読記憶媒体または携帯用部品上に（例えば、命令または構造化データとして）記憶されてもよい。いくつかの実施形態では、コンピューティングノード２５００から分離しているコンピュータ可読記憶媒体上に記憶された命令は、ネットワークおよび／または無線リンク等の通信媒体を介して伝えられる、電気、電磁、またはデジタル信号等の伝送媒体または信号を介して、コンピューティングノード２５００に伝送されてもよい。種々の実施形態はさらに、コンピュータ可読記憶媒体上で、先述の説明に従って実装される、命令および／またはデータを受信、送信、または記憶することを含んでもよい。したがって、異なる実施形態が、他のコンピュータシステム構成を用いて実践されてもよい。

【0203】

本明細書で説明されるいくつかの実施例は、非リレーショナルデータベースを含むシステムにおける種々の技法の適用を対象とする一方で、他の実施形態では、これらの技法は、異なる記憶パラダイムを使用して非リレーショナルデータ記憶部が実装される、システムで適用されてもよいことに留意されたい。

【0204】

当業者であれば、いくつかの実施形態では、上記で論議される方法によって提供される機能性は、より多くのソフトウェアモジュールまたはルーチンの間で分割されること、あるいはより少ないモジュールまたはルーチンに整理統合されること等の代替的な方法で提供されてもよいことを理解するであろう。同様に、いくつかの実施形態では、代わりに、他の図示した方法が、それぞれ、そのような機能性を欠いている、または含んでいるとき、あるいは提供される機能性の量が変更されるとき等に、図示した方法は、説明されるよりも多いまたは少ない機能性を提供してもよい。加えて、種々の動作が、特定の方式で（例えば、直列または並列で）、および／または特定の順序で行われるものとして図示されてもよい一方で、当業者であれば、他の実施形態では、動作が、他の順序で、および他の方式で行われてもよいことを理解するであろう。当業者であればまた、上記で論議されるデータ構造が、単一のデータ構造を複数のデータ構造に分割させることによって、または複数のデータ構造を単一のデータ構造に整理統合させることによって等、異なる方式で構造化されてもよいことも理解するであろう。同様に、いくつかの実施形態では、代わりに、他の図示したデータ構造が、それぞれ、そのような情報を欠いている、または含んでいるとき、あるいは記憶される情報の量またはタイプが変更されるとき等に、図示したデータ構造は、説明されるよりも多いまたは少ない情報を記憶してもよい。図で描写され、本明細書で説明される種々の方法は、方法の例証的実施形態を表す。本方法は、種々の実施形態では、ソフトウェアで、ハードウェアで、またはそれらの組み合わせで実装されてもよい。同様に、種々の実施形態では、任意の方法の順序が変更されてもよく、種々の要素が、追加され、並べ替えられ、組み合わせられ、省略され、修正される等してもよい。

【0205】

先述の内容から、例証の目的で、具体的実施形態が本明細書で説明されているが、添付の請求項およびその中に記載される要素の精神および範囲から逸脱することなく、種々の修正が行われてもよいことが理解されるであろう。加えて、ある態様が、ある請求形態で以下に提示されるが、発明者らは、任意の利用可能な請求形態で種々の態様を考慮している。例えば、いくつかの態様のみが、現在、コンピュータ可読記憶媒体で具現化されるものとして記載されてもよいが、他の態様も同様にそのように具現化されてもよい。本開示の利益を有する当業者に明白となるように、種々の修正および変更が行われてもよい。全てのそのような修正および変更を包含し、したがって、上記の説明が、制限的な意味よりもむしろ例証的な意味で見なされることが意図される。

【図1】

【図2A】

【図2B】

【図2C】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】