特許 6560308 データ記憶サービスを実装するシステム及び方法

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

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

(11)【特許番号】6560308

(24)【登録日】2019年7月26日

(45)【発行日】2019年8月14日

(54)【発明の名称】データ記憶サービスを実装するシステム及び方法

(51)【国際特許分類】

   G06F 16/182 20190101AFI20190805BHJP

   G06F 16/27 20190101ALI20190805BHJP

   G06F 9/50 20060101ALI20190805BHJP

【ＦＩ】

   G06F16/182

   G06F16/27

   G06F9/50 150D

【請求項の数】15

【全頁数】92

(21)【出願番号】特願2017-156531(P2017-156531)

(22)【出願日】2017年8月14日

(62)【分割の表示】特願2015-163040(P2015-163040)の分割

【原出願日】2012年6月27日

(65)【公開番号】特開2017-199439(P2017-199439A)

(43)【公開日】2017年11月2日

【審査請求日】2017年9月5日

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

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

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

(73)【特許権者】

【識別番号】507303550

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

(74)【代理人】

【識別番号】100098394

【弁理士】

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

(74)【代理人】

【識別番号】100064621

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

【審査官】 圓道 浩史

(56)【参考文献】

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

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

【文献】 米国特許出願公開第２００２／００５９４２７（ＵＳ，Ａ１）

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

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

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

【文献】 鈴木 幸市 Koichi SUZUKI，要素技術とキーワードで学ぶデータベースの仕組み ＲＤＢＭＳ解剖学，ＤＢ Ｍａｇａｚｉｎｅ，日本，株式会社翔泳社，２００４年１１月 １日，第１４巻 第９号，ｐ．１９９−２０３

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