本申请是国际申请日为2012年6月27日的、名称为“用于实施可扩展数据存储服务的系统和方法”的发明专利申请no.201280037292.5(pct/us2012/044371)的分案申请。本申请涉及一种用于实施可扩展数据存储服务的系统和方法。
背景技术：
：：多个前沿技术组织正投资构建出售“软件即服务”的技术。这些服务向客户端或订户提供对共享存储装置(例如，数据库系统)和/或计算资源的访问。在多层电子商务系统内，可以将不同资源分配给订户和/或来自整个机器的订户应用、cpu、存储器、网络带宽和i/o能力。出于多种原因中的任何一种(包括安全问题、灾难预防和恢复问题、数据局部性和可用性问题等)，代表用户管理大量数据的数据库系统可以在通常在不同位置中的两个或更多个机器上分布和/或复制所述数据。可以用任何数量的方式配置这些机器，包括配置成共享资源池。客户端应用与数据库服务器之间的交互通常包括读操作(只读查询)、写操作(用来存储数据)和可使用读取-修改-写入工作流程而概念化的更新操作。附图说明图1是示出被配置来实施基于网络服务的数据存储服务的系统架构的一个实施方案的方框图。图2a至图2c是示出根据一个实施方案的网络服务平台的各种组件的方框图。图3a和图3b是示出根据一个实施方案的将数据作为项目存储在多个表格中的方框图。图4是示出根据一个实施方案的包括数值属性的三个项目的方框图，所述数值属性被指定为存储所述三个项目的表格的主键。图5是示出用于代表存储服务客户端创建由数据存储服务维护的表格的方法的一个实施方案的流程图。图6是示出用于响应于通过网络服务api接收的请求而创建表格的方法的一个实施方案的流程图。图7是示出用于生成表格元数据的方法的一个实施方案的流程图。图8是示出createtable工作流程的一个实施方案的流程图。图9是示出用于响应于更新项目的请求而更新项目的方法的一个实施方案的流程图。图10是示出用于使用支持条件更新和/或多个输出选项的api来更新项目的方法的一个实施方案的流程图。图11是示出用于将在非关系数据存储装置中维护的表格分区的方法的一个实施方案的流程图。图12是示出用于执行查询的方法的一个实施方案的流程图。图13是示出用于执行查询的方法的另一实施方案的流程图。图14是示出用于执行表格扫描操作的方法的一个实施方案的流程图。图15是示出根据一个实施方案的用于执行已指定扫描或响应限制的查询或扫描操作的方法的流程图。图16是示出根据一个实施方案的用于提供数据存储服务的系统的数据模型的部分的方框图。图17是示出用于使用优选吞吐量模型来代表数据存储服务客户端创建并管理表格的方法的一个实施方案的流程图。图18是示出用于当维护或修改既定吞吐量水平时为针对特定表格的请求服务的方法的一个实施方案的流程图。图19是示出用于当由数据存储服务代表存储服务客户端维护的表格的分区“有效”时移动所述分区的副本的方法的一个实施方案的流程图。图20是示出用于使用物理拷贝机制移动副本的方法的一个实施方案的流程图。图21是示出用于响应于划分由数据存储服务维护的表格的分区的请求而划分所述分区的方法的一个实施方案的流程图。图22是示出用于响应于检测异常而移动由数据存储服务维护的表格的分区的方法的一个实施方案的流程图。图23是示出用于响应于检测到存储节点上的热点而移动或划分由数据存储服务维护的表格的分区的方法的一个实施方案的流程图。图24是示出用于代表一个或多个存储服务客户端维护并管理多个表格的方法的一个实施方案的流程图。图25是示出根据一个实施方案的可以适用于实施数据存储服务的计算节点的方框图。虽然本文中已通过以多个实施方案和说明性附图为实例的方式描述实施方案，但是本领域那些技术人员应认识到实施方案不限于已描述的实施方案或附图。应了解，附图和附图的详述不旨在将实施方案限于所公开的特定形式，而恰恰相反，本发明将涵盖落在如由所附权利要求定义的精神和范围内的所有修改、等效物和替代。本文中使用的标题是仅出于组织目的且并非意指用来限制描述或权利要求的范围。如本申请全文中使用，以允许意义(即，意指具有……的可能)而非强制意义(即，意指必须)使用单词“可以(may)”。类似地，单词“包括(include)”、“包括(including)”和包括(includes)意指包括但不限于。具体实施方式可以以各种组合且在各种实施方案中采用本文中描述的系统和方法以实施向存储服务客户端(例如，用户、订户或代表用户或订户访问数据存储服务的客户端应用)提供数据存储服务的基于网络的服务。如本文中详述，在一些实施方案中，服务可以支持代表客户端在非关系数据存储装置(例如，非关系数据库)中维护表格的无缝扩展。在一些实施方案中，服务可以通过复制而提供高水平的持续性和可用性。在一些实施方案中，服务本身可能不一定强加最大表格大小或最大吞吐量的限制，且即使是具有大规模扩展的表格也不一定需要客户端分区。服务可以支持响应于检测到各种异常(例如，故障或错误状况、热点或表格大小和/或服务请求吞吐量中的增加)而对数据进行自动现场再分区，和/或对数据进行显式(例如，积极主动和/或订户起始的)现场再分区以支持规划或期望的表格大小和/或吞吐量增加。换句话说，在一些实施方案中，服务可以响应于接收到存储、检索、修改或删除可扩展表格中的项目的一个或多个请求而开始对表格再调整(扩展)和/或再分区。在各种实施方案中，本文中描述的服务可以支持灵活的纲目、多个可用一致性模型、各种服务水平和/或商业模型选项、多个索引选项和/或多个查询类型。在一些实施方案中，存储服务客户端(例如，用户、订户或客户端应用)可以通过使用相对较小(且相对简易)的api集的网络服务接口与服务进行交互，使得服务的客户端在很大程度上从数据库管理的负担中解脱。服务可以展现出服务请求中的低等待时间。与一些先前数据存储服务不同的是，服务可以低成本支持可预测性能，同时支持多重租赁和自动热管理。在各种实施方案中，本文中描述的数据存储服务可以提供应用程序接口(api)，其包括支持对由所述服务代表存储服务客户端维护的表格中的数据进行下列操作中的一些或所有：放置(或存储)项目、获取(或检索)具有指定主键的一个或多个项目、删除项目、更新单个项目中的属性、使用索引查询项目和扫描整个表格(例如，列出整个表格的项目)，从而视情况筛选返回的项目。在一些实施方案中，除了支持最终一致读取操作以外，服务(和/或实施服务的底层系统)还可以支持强一致性模型。在一些实施方案中，经由api作出的服务请求可以包括一个或多个用户优选(诸如优选一致性模型、优选服务请求吞吐量水平或请求保证的服务请求吞吐量水平)的指示。在其它实施方案中，这些用户优选中的一些或所有可以在创建表格时被指定，或可以是客户端专用、账号专用、各种表格类型专用或由全系统默认值指定，而非基于预请求指定。api可以支持极端扩展和/或支持的可预测性能多于由先前数据存储系统和服务提供的可预测性能。在一些实施方案中，服务(和/或底层系统)可以强加上限于个别项目的大小，以(例如)允许服务将项目的全部内容存储在底层数据存储系统中的单个分区中。这又可以促进对项目执行自动更新且不大幅减小吞吐量，且使得可以更加容易地将项目内容维护在稳定工作集中。换句话说，在一些实施方案中，限制个别项目的大小可以促进系统中的强一致性和高性能两者。图1中示出被配置来实施诸如本文中描述的基于网络服务的数据存储服务的系统架构的一个实施方案。应注意，在给定组件的一个或多个实例可以存在的情况中，可以以单数或复数参考下文中的所述组件。然而，任何一种形式的使用不旨在排除另一种形式。在各种实施方案中，图1中示出的组件可以作为可由计算机硬件(例如，微处理器或计算机系统)直接或间接执行的指令直接实施于计算机硬件内，或使用这些技术的组合而加以实施。例如，图1的组件可以由包括多个计算节点(或简称为节点)(诸如图22中示出且下文论述的计算机节点实施方案)的分布式系统实施。在各种实施方案中，给定存储服务系统组件的功能可以由特定计算节点实施或可以在多个计算节点上分布。在一些实施方案中，给定计算节点可以实施一个以上存储服务系统组件的功能。一般来说，存储服务客户端110a至110n可以包括可配置来经由网络120将网络服务请求提交给网络服务平台130的任何类型的客户端。例如，给定存储服务客户端110可以包括网络浏览器的合适版本或插件模块或被配置来执行为对由网络浏览器提供以向存储服务客户端(例如，客户端应用、用户和/或订户)提供对由网络服务平台130提供的数据存储服务访问的执行环境的扩充或在所述执行环境内执行的其它类型的代码模块。替代地，存储服务客户端110可以包括应用，诸如数据库应用、媒体应用、办公室应用或可以利用持久性存储资源的任何其它应用。在一些实施方案中，这种应用可以包括用于生成并处理网络服务请求且无需对所有类型的基于网络的数据实施全浏览器支持的充足协议支持(例如，超文本传输协议(http)的合适版本)。即，存储服务客户端110可以是被配置来与网络服务平台130直接交互的应用。在各种实施方案中，存储服务客户端110可以被配置来根据表述性状态转移(rest)样式网络服务架构、基于文档或消息的网络服务架构或另一合适的网络服务架构生成网络服务请求。在一些实施方案中，存储服务客户端110可以被配置来以对其他应用透明的方式向所述应用提供对基于网络服务的存储的访问。例如，存储服务客户端110可以被配置来与操作系统或文件系统集成在一起以根据本文中描述的存储模型的合适变体提供存储。然而，操作系统或文件系统可以对应用呈现不同存储接口，诸如文件、目录和/或文件夹的常规的文件系统层次。在这样的实施方案中，应用可以不需要进行修改而利用本文中描述的存储系统服务模型。相反地，可以由代表在操作系统环境内执行的应用的存储服务客户端110和操作系统或文件系统来协调与网络服务平台130的对接细节。存储服务客户端110可以经由网络120将网络服务请求传达到网络服务平台130并从网络服务平台130接收响应。在各种实施方案中，网络120可以包括在客户端110与平台130之间建立基于网络的通信所必需的联网硬件和协议的任何合适的组合。例如，网络120可以大体上包括共同地实施互联网的各种电信网络和服务供应商。网络120也可以包括专用网络，诸如局域网(lan)或广域网(wan)和公共或专用无线网。例如，给定客户端110和网络服务平台130均可以被分别配备在本身具有内部网络的企业内。在这样的实施方案中，网络120可以包括在给定客户端110与互联网之间和互联网与网络服务平台130之间建立联网链路所必需的硬件(例如，调制解调器、路由器、交换机、加载均衡器、代理服务器等)和软件(例如，协议堆栈、审计软件、防火墙/安全软件等)。应注意，在一些实施方案中，存储服务客户端110可以使用专用网络而非公共互联网来与网络服务平台130进行通信。例如，客户端110可以被配备在与本文中描述的数据存储服务(和/或底层系统)相同的企业内。在这种情况下，客户端110可以完全通过专用网络120(例如，可以使用基于互联网的通信协议但不可公共访问的lan或wan)与平台130进行通信。一般来说，网络服务平台130可以被配置来实施一个或多个服务端点，服务端点被配置来接收并处理网络服务请求，诸如访问由数据存储服务代表客户端/用户维护的表格和/或存储在所述表格中的项目和属性的请求。例如，网络服务平台130可以包括被配置来实施各种服务端点且适当地接收并处理针对所述端点的基于http的网络服务请求的硬件和/或软件。在一个实施方案中，网络服务平台130可以实施为被配置来从客户端110接收网络服务请求并将其转发到共同地实施数据存储系统的各种组件以用于处理的服务器系统。在其它实施方案中，网络服务平台130可以被配置为实施加载均衡和被配置来动态地管理处理负载的大型网络服务请求的其它请求管理特征的多个相异系统(例如，集群拓扑中)。如图1中示出，网络服务平台130可以包括前端模块140(除了其它方面以外，其还可以被配置来接收、认证、解析、抑制和/或调度服务请求)、一个或多个管理组件或自动管理实体150(如下文更详细描述，其可以被配置来提供各种可见度和/或控制功能)和多个存储节点实体(示为160a至160n)，其中的每个可以代表客户端/用户或代表数据存储服务(和其底层系统)本身维护并管理一个或多个表格。根据各种实施方案下文更详细地描述由这些类型的组件中的每个提供的功能中的一些。在各种实施方案中，网络服务平台130可以被配置来支持不同类型的网络服务请求。例如，在一些实施方案中，平台130可以被配置来实施特定网络服务应用程序接口(api)，其支持对由数据存储服务系统代表客户端/用户维护并管理的表格(和/或存储在所述表格中的数据)进行各种操作。下文更详细地描述由这种api支持的操作的实例。除了充当客户端的网络服务请求的可寻址端点以外，在一些实施方案中，网络服务平台130还可以实施各种客户端管理特征。例如，平台130可以通过(诸如)追踪以下各项来协调网络服务(包括存储资源)的客户端使用的计量和审计：请求客户端110的身份、客户端请求的次数和/或频率、代表客户端110存储或检索的表格和/或项目的大小、由客户端110使用的总存储带宽、由客户端110请求的存储类别和/或任何其它可测量的客户端使用参数。平台130也可以实施财务审计和计费系统，或可以维护可以由用于报告和计费客户端使用活动的外部系统查询并处理的使用数据的数据库。在一些实施方案中，平台130可以包括封锁管理程序和/或引导程序配置(未示出)。在各种实施方案中，可以在被配置来执行本文中描述的功能的一个或多个计算节点上实施数据存储服务。在一些实施方案中，可以由网络服务平台(诸如图1中的网络服务平台130)实施服务，网络服务平台是由多个计算节点组成，多个计算节点中的每个可以执行本文中描述的功能中的一个或多个。计算节点的各种集合可以被配置来提供自动管理集群、数据存储服务专用的资源集群和外部资源的集合(在一些实施方案中，其可以由其它网络服务或应用共享)的功能。在一些实施方案中，与系统交互以提供本文中描述的功能的外部资源可以包括如图1中示为简易工作流程组件170的简易工作流程组件。简易工作流程组件170可以提供框架，其它组件通过所述框架与简易工作流程系统交互。在一些实施方案中，网络服务平台130可以包括构建在所述框架的顶部上的访问api(未示出)。这个接口可以允许系统实施适用于数据存储服务希望经历的使用模式的api。在一些实施方案中，系统中使用简易工作流程组件170的组件或模块可以包括这些接口而非与由简易工作流程组件170的提供的接口直接对接。在一些实施方案中，除了简易工作流程组件170以外，网络服务平台130还可以依赖于一个或多个外部资源，诸如外部存储服务180和/或其它外部(且在一些情况下共享的)外部资源。在一些实施方案中，简易工作流程组件170可以用来执行分布式操作，诸如扩充超出特定分区复制组的那些分布式操作。图2a至图2c示出根据一个实施方案的可以包括在网络服务平台130的多种类型的组件中的每个中的各种元件或模块。如图2a中示出，前端模块140可以包括被配置来对服务请求执行解析和/或抑制(示为210)、对服务请求执行认证和/或计量(示为215)、调度服务请求(示为225)和/或维护分区映射缓存(示为230)的一个或多个模块。除了这些组件专用模块以外，前端模块140还可以包括共同地实施网络服务平台130的多种类型的计算节点共用的组件，诸如消息总线(示为235)和/或动态配置模块(示为240)。在其它实施方案中，前端模块140中可以包括更多、更少或不同元件，或网络服务平台130的另一组件中或被配置来与网络服务平台130交互以提供本文中描述的数据存储服务的组件中可以包括示为包括在前端模块140中的元件中的任何一个。如图2b中示出，自动管理实体150可以包括被配置来向系统管理员提供可见度和控制(示为245)或执行热均衡(示为250)和/或异常控制(示为255)、资源分配(示为260)的一个或多个模块。自动管理实体150也可以包括管理主控台265，系统管理员可以通过管理主控台265与数据存储服务(和/或底层系统)交互。在一些实施方案中，管理主控台265可以是数据存储服务的可见度和控制的主要点(例如，由系统管理员进行配置或再配置)。例如，管理主控台265可以实施为相对较瘦客户端，其在功能上向系统管理员和/或其它特权用户提供显示和控制，且可以通过其来观察和/或更新系统状态指示符、元数据和/或操作参数。除了这些组件专用模块以外，自动管理实体150也可以包括共同地实施网络服务平台130的不同类型的计算节点共用的组件，诸如消息总线(示为235)和/或动态配置模块(示为240)。在其它实施方案中，自动管理实体150中可以包括更多、更少或不同元件，或网络服务平台130的另一组件中或被配置来与网络服务平台130交互以提供本文中描述的数据存储服务的组件中可以包括示为包括在自动管理实体150中的元件中的任何一个。如图2c中示出，存储节点实体160可以包括被配置来提供分区管理(示为270)、实施复制和故障转移程序(示为275)和/或将应用程序接口(api)提供给底层存储装置(示为280)的一个或多个模块。如这个实例中示出，每个存储节点实体160可以包括存储引擎285，其可以被配置来代表一个或多个客户端/用户将一个或多个表格(和相关表格数据)维护(即，存储和管理)在存储装置280(在一些实施方案中，其可以是非关系数据库)中。除了这些组件专用模块以外，存储节点实体160还可以包括共同地实施网络服务平台130的不同类型的计算节点共用的组件，诸如消息总线(示为235)和/或动态配置模块(示为240)。在其它实施方案中，存储节点实体160中可以包括更多、更少或不同元件，或网络服务平台130的另一组件中或被配置来与网络服务平台130交互以提供本文中描述的数据存储服务的组件中可以包括示为包括在存储节点实体160中的元件中的任何一个。以本文中描述的数据存储服务为基础的系统可以代表存储服务客户端(例如，客户端应用、用户和/或订户)将数据存储在包括具有一个或多个属性的项目的表格中。在一些实施方案中，数据存储服务可以给客户端/用户呈现数据模型，在数据模型中代表客户端/用户维护的每个表格包括一个或多个项目且每个项目包括属性集合。项目的属性可以是按任何次序的名称值对的集合。在一些实施方案中，项目中的每个属性可以具有名称、类型和值。一些属性可以是单值，使得属性名称被映射到单个值，而其它属性可以是多值，使得属性名称被映射到两个或更多个值。在一些实施方案中，属性的名称可以总是字符串，但是其值可以是字符串、数字、字符串集或数集。以下是属性的所有实例："imageid"＝1、"title"＝"flower"、"tags"＝{"flower"、"jasmine"、"white"}、"ratings"＝{3,4,2}。项目可以通过给每个项目指派主键值(其可以包括一个或多个属性值)来管理，且这个主键值也可以用来唯一识别所述项目。在一些实施方案中，可以在表格中的项目上定义大量属性，但是每个项目可以包括这些属性的稀疏集(其中指定用于一个项目的特定属性与相同表格中的另一项目的属性无关)，且可以选用除了主键属性以外的所有属性。换句话说，不同于传统的数据库，由数据存储服务(和底层存储系统)维护的表格除了其依赖于主键以外可以不具有预定义纲目。注意在一些实施方案中，如果属性包括在项目中，那么其值不能是空值或不能为空(例如，属性名称和值不能是空的字符串)，且在单个项目内，其属性名称可以是唯一的。数据存储系统中可以采用各种类型以支持按已排序索引排序数据。在一些实施方案中，数据存储服务可以仅支持少数种类型(例如，字符串和十进制数)，且所有属性值必须具有标量或集合(多个值)类型。例如，在一些实施方案中，服务(和/或实施服务的底层系统)可以仅支持两种标量数据类型：字符串和数字(例如，十进制数)。在此类实施方案中，可以将日期编码为整数(例如，unix纪元时间戳)而非使用“日期”数据类型来编码日期。在其它实施方案中，可以支持更多、更少或不同数据类型。如上文提及，在一些实施方案中，属性名称可以总是数据类型“字符串”。在一些实施方案中，服务(和/或底层系统)可以支持源于所支持标量类型的多值类型，如下列实例：scalartype:＝{n|s}multivaluedtype:＝{ns|ss}在这个实例中，n表示数字，s表示字符串，ns表示数集，且ss表示字符串集。在各种实施方案中，类型“字符串”的属性可以是键的部分或索引的部分，且字符串的最大大小可以受限于索引键的大小(例如，范围键累积1024个字节或每个散列键累积2048个字节)或项目大小(例如，64k)。在各种实施方案中，类型“数字”的属性可以用来存储精确值十进制和整数，且可以具有可变宽度编码。在一些实施方案中，可被这种类型的属性占据的空间量可以限于预定量。也应注意，在各种实施方案中，数字可以具有精度p(指示可被存储的有效位的最大数字)和/或标度s(指示从十进制小数点到最低有效位的位数)。在一些情况下，数字的精度和标度可以由服务自动地推断，且所述数字可以使用适当存储大小。在一些实施方案中，可以在数字开始处使用负号来指定负数，但是可以不存储指定在数字前面的正号。在不同实施方案中，可以存储或可以不存储前导零和/或尾随零。以下是可以由本文中描述的服务(和底层系统)采用的数字格式的实例：number_format＝[+|-][{integer}][{.integer}]如上文提及，项目可以包括一个或多个属性。每个属性可以具有两个部分：属性名称(例如，utf8字符串)和属性值(其可以表达为类型和值对象的组合，其中类型描述值的类型)。在一些实施方案中，单值属性可以具有名称和标量值，且属性的类型可以编码在属性值中，如以下实例：{"my-string-attr":{"s":"my-string-value"}}#字符串类型{"my-number-attr":{"n":123456.7}}#数字类型在一些实施方案中，多值属性可以具有名称和指定类型的一个或多个值。在此类实施方案中，值可以是唯一的，如下列实例：{"size":{"ss":「"xl","l","m","s"]}#字符串集{"singledigitprimes":{"ns":[2,3,5,7]}#数集在一些实施方案中，本文中描述的系统可以采用稍微受限的索引和/或查询模型以为用户/订户或客户端应用提供大量(即，几乎无限制的)扩展、可预测性和简易性。例如，在一些实施方案中，可以仅由主键索引并分区数据(例如，在底层数据库中进行分区)。在此类实施方案中，用于索引用户表格中的数据的主键可以在代表用户创建表格时由用户指定。此后，用户的数据的分区可以由系统处理，且从用户提取出来。在一些实施方案中，用于索引数据的主键可以由单个属性散列键组成。在其它实施方案中，用于索引和/或分区数据的主键可以是包括散列键组件和另一组件(有时候在本文中称作范围键组件)的组合键。如本文中更详细地描述，在各种实施方案中，可以支持对索引的属性进行查询，且可以提供全表格扫描功能(例如，支持检修)。在一些实施方案中，用户可以基于除了主键的属性以外的一个或多个属性定义表格的次级索引，且然后可以使用用户定义的索引查询项目。例如，在一些实施方案中，系统可以支持(例如，使用createindexapi)实时创建次级索引的创建，且这些次级索引可以基于存储要求(例如，增加或降低数据量)和/或读/写通信量而自动地扩展。在一些实施方案中，此类次级索引可以随着更新表格中的项目而异步地更新。如先前提及，在一些实施方案中，由数据存储服务维护的每个表格中的项目数可以没有预定义限制。从概念上来说，每个项目可以被认为是属性名称到对应属性值的映射。使用这种类比，映射中的每个条目是属性。在各种实施方案中，每个项目可以包括键属性、正零或更多非键属性。在一些实施方案中，键属性必须是单值属性，而非键属性可以是单值属性或多值属性。以下是具有5个属性的项目的实例：pictureid(字符串类型)、customerid(数字类型)、title(字符串类型)和tags(多值字符串属性)。在各种实施方案中，服务(和/或底层系统)可以强加限制表格名称、项目、属性值、主键值和/或属性名称的预定大小。例如，在一些实施方案中，可以限制所有属性名称的总大小和项目中的值(例如，行大小)。图3a和图3b示出根据一个实施方案的将数据存储在多个表格中。如图3a示出且如上所述，多个表格(示为表格320a至320n)中的每个可以存储多个项目。在已示出的实例中，表格320a存储项目321a至321n，且表格320n存储项目322a至322n。如图3b中示出，存储在表格中的项目中的每个可以包括多个属性，且属性中的每个可以包括属性名称和标量或集合类型值。在这个实例中，项目321a(存储在表格320a中)包括值是1的数值“imageid”属性、值是20100915的数值“日期”属性、名称是“标题”且值是“flower”的字符串属性和名称是“标签”且值是包括字符串“flower”、“jasmine”和“white”的集合的字符串属性。在这个实例中，项目321b(也存储在表格320a中)包括值是2的数值“imageid”属性、名称是“分级”且值是包括数值3、4和2的集合的数值属性、名称是“标题”且值是“credenza”的字符串属性、值是1024的数值“宽度”属性和值是768的数值“深度”属性。在这个实例中，项目321n(也存储在表格320a中)包括值是n的数值“imageid”属性、值是20110327的数值“日期”属性和名称是“标签”且值是包括字符串“france”和“architecture”的集合的字符串属性。注意，即使项目321a、321b和321n全部存储在相同表格(表格320a)中，它们也不会全部包括相同的属性集合。相反地，每个项目包括来自指定用于存储在表格320a中的项目集合的所有属性中的属性的稀疏集。在一些实施方案中，除了用户数据以外，诸如本文中描述的那些表格的表格还可以用来存储并管理系统元数据。上述稀疏填充的项目可以由下表1中的网格表示进一步示出。注意，下表1的网格形式仅仅是用于示出以下事实的便捷机制：单个表格中的各项目可以包括表格中的项目集合中包括的项目属性的不同子集。这并不意指暗示本文中描述的在非关系数据库系统中维护的表格或项目本身的任何特定结构。因此，表格1的行和列的选择和布置可以被视为任意且仅为了说明目的。如本文中描述，由本文中描述的系统维护的表格可以不具有固定纲目。因此，项目可以不包括未包括在其中的属性的占位符(即，空元素)，且可以将属性(和其值)添加到一个或多个项目而无需将其添加到所有其它项目。表格1—稀疏填充的项目属性的实例在一些实施方案中，由数据存储服务代表客户端/用户维护的表格可以具有识别其项目的主键。在各种实施方案中，可以对一个属性定义主键(且主键可以是如上所述的单值)或对多个属性定义主键(即，其可以是如上所述的组合主键)。因为主键属性唯一地识别表格内的项目，所以主键属性可以不可变，可以具有固定类型，且可以强制用于每个项目。在一些实施方案中，主键是经索引的表格的唯一部分，且当创建表格时可以指定索引类型。例如，当创建项目的表格时，可以将属性指定为表格的主键属性(或可以指定两个属性用于组合主键)。表格中的所有项目必须包括指定用于主键的属性，且数据存储服务(和/或底层系统)可以确保对于表格中的每个项目来说所述属性名称的值(或值组合)是唯一的。例如，如果尝试添加具有与现有项目相同的主键值的新项目，那么新项目可以替换表格中的现有项目。图4示出根据一个实施方案的可以存储在表格中且其中名称是“imageid”的数值属性被指定为主键的三个项目。在这个实例中，项目410a包括imageid属性(其具有值1)和用于至少三个其它属性(例如，日期属性、标题属性和标签属性)的值。类似地，项目410b包括imageid属性(其具有值2)和用于至少三个其它属性(例如，专辑属性、分级属性和标签属性)的值。在这个实例中，项目410c包括imageid属性(其具有值3)和用于至少三个其它属性(例如，日期属性、价格属性和作者属性)的值。在这个实例中，存储在表格中的项目可以根据其主键值来索引。换句话说，这些项目中的每个可以单独由其主键值唯一识别，且检索项目(其已由其主键值识别)的操作可以包括检索项目其它属性中的一些或所有的值。如上文提及，数据存储服务(和/或底层系统)可以基于主键创建索引。索引类型可以取决于表格是否使用简易主键或组合主键。例如，数据存储服务可以将主键索引为散列索引或散列和范围索引，如下文：·hash-a可以是字符串或数字。简易主键可以具有一个索引值：散列索引，其可以是字符串或数字。·range-a范围可以是字符串或数字。范围可以允许排序表格项目使得数据查询可基于范围而细化结果。组合主键可以包括索引的两个值：散列索引(有时候在本文中称作散列键值)和范围索引(有时候在本文中称作范围键值)。简易主键可以足以用于表格数据的数据收集和不频繁扫描(例如，使用下文描述的扫描api)。组合主键可以允许更精确地组织表格数据，且可以允许使用下文描述的queryapi以进行更有效的数据检索。下列地址表格(表格2)示出使用单个属性作为主键以唯一地识别表格中的每个项目。表格2-使用简易主键(字符串)在这个实例中，每个项目中需要主键(称作userid的属性)且对于每个项目来说其类型(“字符串”)是固定的。然而，每个项目也可以包括额外属性的任何组合。在一些实施方案中，数据存储系统可以被配置来确保userid的值对于表格中的每个项目来说是唯一的。如上文提及，在一些实施方案中，属性值不能是空值或空的。在此类实施方案中，属性不存在于表格中直到其具有与其相关联的值为止/除非属性具有与其相关联的值，否则属性不存在于表格中。下列表格(表格3)指定数值属性(在这种情况下，imageid)作为主键，通过主键可以唯一地识别表格中的项目：表格3-使用简易主键(数字)在这个实例中，每个项目中需要主键imageid且对于每个项目来说其类型(“数字”)是固定的，但是每个项目可以包括其它属性的任何组合。如在先前实例中，在一些实施方案中，数据存储系统可以被配置来确保imageid的值对于表格中的每个项目来说是唯一的。如上文提及，在一些实施方案中，属性值不能是空值或空的。在此类实施方案中，属性不存在于表格中直到其具有与其相关联的值为止/除非属性具有与其相关联的值，否则属性不存在于表格中。图5中的流程图示出用于创建由数据存储服务代表存储服务客户端维护的表格的方法的一个实施方案。如510处示出，在这个实例中，所述方法可以包括实施数据存储服务的系统的组件(例如，前端模块或底层系统的另一组件)接收代表用户创建表格的服务请求。所述请求可以指定表格的名称和表格的简易或组合主键。在一些实施方案中，所述请求也可以包括针对表格的最终表格大小的估计和/或工作量(即，通信量)的估计，和/或请求的容量或吞吐量通信量。在一些实施方案中，这种信息(如果包括在请求中)可以用来确定表格的初始大小和/或表格的分区的初始数量。在其它实施方案中，客户端或订户账号信息(例如，优选)或特定存储服务客户端(例如，特定用户、订户或客户端应用)的历史数据可以用来确定所创建的表格的初始大小和/或分区数量。如这个实例中示出，所述方法可以包括确定系统中是否已经存在请求中指定表格名称的有效表格(如520)。如果是(示为520的肯定退出)，那么所述方法可以包括返回错误指示(如525)。如果不存在具有指定表格名称的有效表格(示为520的否定退出)，那么所述方法可以包括系统开始在非关系数据存储装置(例如，非关系数据库或其它存储结构)中创建新表格(具有指定表格名称)(如530)。在一些实施方案中，可以解析所述请求以确定各种服务选项。例如，所述请求可以包括一个或多个用户优选的指示，诸如优选服务请求吞吐量水平或请求保证的服务请求吞吐量水平。在一些实施方案中，存储在新创建的表格中的数据可以包括在创建表格的请求中，而在其它实施方案中，存储在表格中的数据可以包括在接收到创建表格的请求之后由数据存储系统接收的一个或多个服务请求中。在各种实施方案中，由数据存储服务维护的表格可以不存在预定大小限制或纲目。在一些实施方案中，响应于(通过包括将存储在表格中的数据的任何数量的服务请求)接收将存储在表格中的数据，系统可以被配置来确定将存储在表格中的数据量是否太多而不能存储在系统中的单个分区中。例如，在一些实施方案中，虽然系统可以不强加限制可存储在表格中的项目数(和/或大小)，但是其可以强加预定限制于可存储在非关系数据存储装置中的每个分区中的项目数(和/或大小)。在一些实施方案中，用户输入可以指示是否在表格实施为单个分区时希望存在针对表格的太多数据或太多通信量而不能使系统具有合理的性能。如果是(示为540的肯定退出)，那么所述方法可以包括系统根据指定主键创建存储表格数据的两个或更多个分区(如550)。例如，在主键是简易键的实施方案中，可以使用项目中的每个的主键值的散列表来对数据分区。在主键是组合键的实施方案中，可以首先由散列键组件的散列表对数据分区且然后由范围键组件来对数据分区。例如，如果范围键组件表示数值识别符(通过其对具有相同散列键组件值的项目排序)，那么可以按前n个项目的范围键组件值的次序将所述前n个项目置于一个分区中(其中n是小于可存储在单个分区中的项目数的数字)，且可以将接下来的n个项目置于另一分区中，以此类推。如果将存储在表格中的数据量或针对表格的通信量对于表格来说并非太多以作为单个分区存储在系统中(示为540的否定退出)，那么所述方法可以包括系统创建存储表格数据的单个分区(如560)。此后，系统可以被配置来响应于工作量和/或系统状态的改变和/或响应于从用户/订户或客户端应用接收到各种服务请求而代表客户端/用户以编程方式(即，自动地)管理非关系数据存储装置中的表格(如570)。例如，在一些实施方案中，系统可以被配置来监视系统硬件的状态、服务请求吞吐量的任何改变、任何表格大小增加(或降低)和/或传入服务请求的频率或目标的任何改变，且按要求或响应于接收自存储服务客户端的显式服务请求而自动地(例如，以编程方式)扩展、再配置和/或再分区表格。本文中描述的数据存储服务(和/或底层系统)可以提供用于请求将代表存储服务客户端维护的表格、项目和/或属性作为目标的各种操作的应用程序接口(api)。在一些实施方案中，服务(和/或底层系统)可以提供控制平面api和数据平面api两者。例如，数据存储服务可以提供执行以下操作中的任何一个或所有的api的集合：·创建或删除表格。·请求某个表格或多个表格的当前状态，包括主键和创建信息。·将项目置于(存储在)表格中。·经由主键获取(检索)一个或多个项目(和/或其属性)。·从表格中删除项目。·更新单个项目中的属性。·使用范围索引和比较运算符查询项目。·扫描整个表格，视情况使用比较运算符筛选返回的项目。由数据存储服务(和/或底层系统)提供的控制平面api可以用来操控表格级别的条目，诸如表格和索引。(当与数据平面api相比时)可以相对较不频繁地调用这些api。在一些实施方案中，由服务提供的控制平面api可以用来创建表格、删除表格和/或描述表格。在一些实施方案中，对表格级别的条目执行更新的控制平面api可以调用异步工作流程以执行所请求的操作。(例如，经由describetablesapi)请求“描述”信息的方法可以简单地返回由服务代表客户端/用户维护的表格的当前已知状态。由数据存储服务(和/或底层系统)提供的数据平面api可以用来执行项目级别操作，诸如存储、删除、检索和/或更新项目和/或其属性，或跨表格中的多个项目执行基于索引的搜索类型操作，诸如查询和扫描。在不同实施方案中，由本文中描述的服务提供的api可以支持以一个或多个行业标准或专有数据交换格式编码的请求和响应参数。例如，在各种实施方案中，请求和响应可以遵循人类可读(例如，基于文字的)数据互换标准(例如，javascript对象符号或json)，或可以使用二进制编码来表示(在一些情况下，其可能比基于文字的表示法更加紧凑)。在各种实施方案中，系统可以为本文中描述的api的输入参数中的一个或多个供应默认值(例如，全系统默认值、用户专用默认值或账号专用默认值)。如上文提及，由服务支持的控制平面api可以包括对表格执行更新的api(例如，createtableapi和/或deletetableapi)。在各种实施方案中，这些api可以调用异步工作流程以执行所请求的操作。此外，所述服务可以支持返回当前已知状态(例如，describetablesapi)的方法。在一些实施方案中，通常使用的模型可以使客户端(例如，使用createtableapi)请求进行动作，且然后经由对应描述api轮询其完成(例如，describetables)。在各种实施方案中，createtableapi可以用来创建具有指定主索引(即，主键)的表格。在一些实施方案中，响应于接收到经由这个api代表存储服务客户端创建表格的请求，所述服务可以引发(和/或实施所述服务的底层系统可以调用)立即返回(即，无需等待完成工作流程)的异步createtable工作流程。在此类实施方案中，可以随后通过经由describetablesapi核对表格的状态来确定工作流程的成功。例如，由所述服务代表客户端/用户管理的每个表格可以处于以下表格状态之一，且可以响应于describetables请求而返回每个表格的状态的指示：创建-其中创建表格有效-其中存在表格删除-其中删除表格图6中的流程图示出用于响应于通过网络服务api接收的请求而创建表格的方法的一个实施方案。如这个实例中示出，所述方法可以包括实施数据存储服务的系统接收代表用户创建表格的服务请求(如610)。所述请求可以包括要创建的表格的名称且可以为表格指定简易主键或组合键。响应于接收到所述请求且如果尚不存在具有指定表格名称的有效表格，那么系统可以生成表格的元数据(如620)。根据一个实施方案，图7中示出且下文详细描述表格元数据的生成。在创建表格的元数据之后，所述方法可以包括系统调用异步createtable工作流程(例如，系统的组件可以向createtable方法发出调用)(如630)。图8中示出且下文描述这种工作流程的一个实施方案。在一些实施方案中，可以立即(即，在完成createtable工作流程之前，或在一些情况下在createtable工作流程开始创建表格的程序之前)从createtable工作流程返回响应。在一些实施方案中，在调用createtable工作流程之后，系统可以继续进行其它工作，而非等待完成createtable工作流程。例如，系统(或其组件)或应用(代表用户)可以被配置来定期或偶尔核对新表格的状态以查看其是否处于“有效”状态(如640)。在一些实施方案中，这可能涉及使用本文中描述的describetablesapi发出服务请求。可以重复地核对表格的状态直到其状态为“有效”为止(示为640的否定退出到640的输入的反馈环路)。一旦表格状态为“有效”，就可以将表格创建程序视为完成(如650)。在一些实施方案中，createtableapi的输入参数可以包括tablename(其可以是包括要创建的表格的名称的字符串)和这个api的keyschema(其可以描述要创建的表格的主键)。在一些实施方案中，keyschema可以包括描述简易或组合主键的数组。例如，简易主键可以包括单个散列键，而组合键可以包括散列键和范围键。在一个实施方案中，主键的索引类型可以是hash或range，且主键的每个属性可以包括名称(其可以是包括属性的名称的字符串)、属性值的数据类型(例如，n或s)和属性值。如先前提及，在不同实施方案中，createtable请求可以以json请求格式或另一合适的格式提出。以下是创建带有具有两个属性的组合主索引的表格的请求的实例：folderid(字符串类型的散列索引)和datecreated(日期的范围，每个表示为数字)。示例性请求格式：在一些实施方案中，createtableapi的输出参数可以包括tablename(例如，包括所创建的表格的名称的字符串)、tablestatus(例如，具有值“creating”的字符串)、keyschema(例如，描述主键的数组，主键可以是简易散列键或包括范围)和datecreated(其可以是指示创建表格时的日期和/或时间的字符串或数字)。如先前提及，在不同实施方案中，对createtable请求的响应可以以json响应格式或另一合适的格式提出。在一些实施方案中，如果尝试创建已经存在的表格(例如，具有相同名称、主键和/或键纲目的表格)，那么可以由所述服务返回错误状况(例如，resourceinuse错误状况)的指示。以下是接收自数据存储服务且对应于createtable请求的响应的实例。示例性响应格式：如上文提及，在一些实施方案中，响应于接收到(例如，使用createtableapi)代表存储服务客户端/用户创建表格的请求，数据存储服务(和/或底层系统)可以生成与表格相关联的元数据并调用异步createtable工作流程以创建表格。在一些实施方案中，可以存在存储和/或维护与表格创建相关联的元数据的多个表格，且可以在创建新表格时更新这些表格中的一个或多个。例如，在各种实施方案中，系统可以维护下列表格中的任何一个或所有：·tables表格：这个表格可以将每个表格的清单和表格的当前状态(例如，创建、有效、删除等)维护在系统中。在一些实施方案中，这个表格的主键可以包括subscriberid属性(其可以用来识别将代表其维护表格的用户)和tablename属性(其可以指定将创建的表格的名称)。当为新表格创建条目时，可以将表格状态设置成“创建挂起(creationpending)”，其可以指示已接受创建表格，但是仍未调用工作流程来创建表格。·订户表格：这个表格可以维护代表单个客户端(即，用户/订户或客户端应用)维护的表格的总数的计数，且也可以指示所述表格中有多少表格处于状态有效、创建和/或删除中的每个中。在一些实施方案中，如上所述，这个表格的主键可以包括subscriberid属性。在一些实施方案中，可以将这个表格视为tables表格的次级索引。可以响应于createtable工作流程的调用而使表格的总数的计数和/或处于创建状态的表格数量的计数递增。·分区表格：这个表格可以维护特定表格的所有分区的清单，且可以指示其位置。在一些实施方案中，这个表格的主键可以包括tableid属性和partitionid属性。·节点表格：这个表格可以维护节点的清单，且可以指示托管在节点中的每个上的分区。在一些实施方案中，这个表格的主键可以包括nodeid属性。在一些实施方案中，可以将这个表格视为分区表格的次级索引。图7中的流程图示出用于生成所创建表格的表格元数据的方法的一个实施方案。如上所述，这种方法可以由实施数据存储服务的系统响应于接收到代表用户创建表格的请求而调用，其中所述请求指定表格名称和简易或组合主键。表格名称对于给定用户或整个给定订户账号来说可以是唯一的。如这个实例中示出，一旦调用所述方法(如710)，其就可以包括为表格创建唯一表格识别符(如720)。例如，系统的组件可以被配置来创建在整个系统上唯一的表格识别符。如这个实例中示出，所述方法可以包括决定将要创建的分区的数量和创建对应的分区识别符(如730)。例如，系统的组件可以被配置来应用(例如，用户/订户或客户端应用的)历史使用数据、由用户/订户提供的未来使用的评估和/或其它准则以确定表格的分区的适当数量并为每个分区创建分区识别符，分区识别符在整个系统上唯一的。在一些实施方案中，所述方法可以包括在(诸如上文描述的)tables表格中为新表格创建条目和将新表格的状态设置成“创建挂起”(如740)。所述方法也可以包括使维护在系统中的表格的总数的计数和/或系统中处于创建挂起状态的表格数量的计数递增(如750)。如这个实例中示出，一旦为表格生成元数据且更新一个或多个元数据表格以反映新表格的挂起创建，所述方法就可以包括调用createtable工作流程(如760)。如图8的810处示出，在一些实施方案中，可以将表格名称、表格识别符和/或分区识别符作为所述程序的输入全部传递到createtable工作流程。注意，这(和/或本文中描述的任何其它服务请求)可以包括识别特定订户的输入参数，诸如accountid参数。在此类实施方案中，可以将这个输入参数的值传递到响应于接收到服务请求而调用的任何工作流程(例如，createtable工作流程)。注意，在其它实施方案中，可以不同于上述实例来组织由数据存储服务代表一个或多个存储系统客户端维护的表格的元数据。例如，在其它实施方案中，系统可以采用更多、更少或不同元数据表格，与这个实例相比元数据表格可以存储更多或更少元数据和/或与这个实例中描述的类型的元数据相比元数据表格可以存储不同类型的不同元数据。也应注意，在一些实施方案中，当接收到创建表格的请求时可以将所述请求放在队列中且在某个时间段之前(例如，当调用createtable工作流程以执行表格创建时)可以不生成或存储所述表格的元数据。如先前提及，被配置来实施本文中描述的数据存储服务的系统可以依赖于使用简易工作流程服务执行的一个或多个工作流程。在一些实施方案中，createtable工作流程可以为新表格分配一个或多个分区、为分区中的每个创建两个或更多个副本以及响应于创建表格而更新适当的元数据。图8中的流程图示出这个工作流程的一个实施方案。在一些实施方案中，所述工作流程可能旨在自我修复。在此类实施方案中，如果程序在完成之前失败，那么可以一次或多次再运行整个工作流程直到程序成功为止。例如，可以响应于故障而一次又一次重试图8中示出的操作中的每个。注意在这个实例中，假设仅在确定不存在具有指定表格名称的有效表格之后方才调用所述工作流程。如这个实例中示出，所述工作流程可以包括将表格的状态更新成“创建”以反映工作流程目前工作以创建表格的事实(如820)。在一些实施方案中，表格状态可以自动更新成“创建”。在此类实施方案中，如果多个工作流程尝试执行这个相同的表格创建操作，那么只有一个工作流程将会成功，因此在这种情况下允许系统避免出现竞争状况。所述工作流程也可以包括确定是否存在包括指定用于新表格的表格名称的任何旧的分区(如830)。例如，如果过去已尝试指定这个表格名称的创建操作(且所述创建操作失败)，那么系统中可能仍保留应在继续进行createtable工作流程的剩余部分之前删除的残余分区。在一些实施方案中，所述工作流程可以包括查询与这个表格名称相关联的任何分区的元数据(例如，tables表格)。例如，在系统中可能存在创建具有这个表格名称的表格的先前失败尝试的残余物，包括一个或多个元数据表格中的表格的元数据。对于发现的每个分区，可能存在多个副本，且可以从上面驻留这些副本的存储节点物理地删除这些副本中的每个(如835)。在发现不存在与指定表格名称相关联的分区时(例如，如果先前未尝试进行这个表格创建操作且这个表格创建操作失败)(示为830的否定退出)或一旦删除此类残余物，所述工作流程就可以为新表格创建一个或多个分区(如840)。如先前描述，在一些实施方案中，所创建的分区数量可以基于用户输入、历史数据和/或全系统默认值、客户端专用默认值或应用专用默认值。如图8中示出，为新表格创建分区可以包括选择上面存储分区中的每个的多个副本的节点、创建多个副本和更新分区元数据(例如，更新分区表格使其包括新创建的副本并指示其位置)。在一些实施方案中，选择上面存储副本的节点可以包括查询元数据以找到上面可存储副本的健全节点和使用各种合适的分配算法中的任何一种将副本分配到健全节点中的各个节点。在一些实施方案中，系统可以支持两种或更多种灵活和/或可扩充分配算法，包括(但不限于)选择具有最可用的存储空间的节点、选择经历工作量最小的节点(例如，接收最少服务请求的节点)或随机选择节点(这可以最小化所有新分区通向负载最小的节点的羊群效应)。如图8中所示，createtable工作流程可以包括(例如，在节点表格中)为新创建的表格更新节点相关的元数据(如850)。例如，所示工作流程可以包括从分区表格(其在840中更新)中读取新创建的副本的所有节点位置和将新创建的副本中的每个添加到节点表格的适当条目。一旦创建表格的分区(和其副本)且更新适当元数据以反映新表格的创建，所述工作流程就可以包括将新创建的表格的状态更新成“有效”(如860)。在一些实施方案中，将新创建的表格的状态更新成“有效”可以包括使上述订户表格中处于创建状态的表格数量的计数递减。如上文提及，在一些实施方案中，如果图8中示出的操作中的任何一个失败，那么它们可以重试多达预定最大尝试次数。例如，在一个实施方案中，未成功的任何createtable工作流程步骤可以重试多达10次，且可以在多次尝试之间采用指数回退。在一些实施方案中，如果所述工作流程步骤在最大尝试次数之后的确未成功完成，那么可以将所创建的表格的状态重设成创建挂起以指示没有任何工作流程当前工作于创建该表格。在这样的情况下，系统可以执行或可以不执行未成功尝试期间创建的任何残留副本的清理。例如，在一些实施方案中，可以将这种清理留给后续createtable工作流程。在一些实施方案中，清扫器工作流程可以定期(例如，每隔30分钟一次)运行，以及可以扫描tables表格以确定是否有任何表格当前处于状态创建挂起中。如果有且如果从清扫器工作流程上一次扫描tables表格以来仍未更新这个表格的状态，那么清扫器工作流程可以假设这个表格的创建失败且可以尝试调用新的createtable工作流程来创建表格。createtableapi的使用可以通过下列实例(即，通过下文的伪代码)来示出。在第一实例中，请求创建名称是“商品”的表格，其中主键是散列值“id”且其中表格中的每个id值必须是数字：在第二实例中，请求创建名称是“商品”的表格，其中主键是散列和范围键(即，组合键)。在这个实例中，主键包括散列值“id”(其中表格中的每个id值必须是数字)，且也包括添加到“歌曲”的主键的范围(其中每首歌曲是字符串)。在这个实例中，在请求创建表格之后，使用createtableapi重复地调用describetablesapi以轮询服务器直到创建新的表格且新的表格有效为止。//轮询并休眠直到表格准备就绪。在一些实施方案中，存储服务客户端(例如，用户、订户或访问服务的客户端应用)可以能够创建多个表格。在一些这样的实施方案中，系统可以强加预定限制于客户端可创建的表格数量。这种限制可以保护系统和/或客户端/用户使得失控程序不能无意地创建大量表格的可能性。在采用这种限制的一些实施方案中，可以由系统管理员或其它特权用户(例如，经由如上所述的管理主控台)撤销所述限制。在一些实施方案中，所有表格可以由根用户(例如，表格拥有者或其它特权客户)拥有，且这个根用户可以能够将api级别许可指派到各种表格以允许和/或约束其它用户(例如，子用户)对所述表格进行的操作。例如，在一些实施方案中，个别用户可以由根用户识别符和子用户识别符的组合来定义如下：user＝{root|sub-user}。在一些实施方案中，除了表格级以外还可以以项目级和/或属性级定义访问控制筛选器，或可以以项目级和/或属性级代替以表格级定义访问控制筛选器。在各种实施方案中，deletetableapi可以用来删除表格和表格的所有索引。在一些实施方案中，如果是deletetableapi的目标的表格在接收到代表存储服务客户端删除所述表格的请求时处于创建状态，那么服务可以返回错误的指示(例如，400“resourceinuse”错误指示)。如果表格在接收到所述请求时处于有效状态，那么服务可以引发(和/或实施所述服务的底层系统可以调用)立即返回的异步deletetable工作流程(即，无需等待完成所述工作流程)。在此类实施方案中，可以随后通过经由describetablesapi核对表格的状态来确定工作流程的成功。例如，如果响应于describetables请求而返回的表格的状态的指示是“删除”，那么可以进行删除操作。在一些实施方案中，在这种情况下将不会返回错误指示。一旦完成删除程序，对describetables请求的响应就可以不再包括已删除表格的条目。在一些实施方案中，deletetableapi的输入参数可以包括tablename(其可以是包括要删除的表格的名称的字符串)。在一些实施方案中，deletetableapi的输出参数可以包括tablename(例如，包括被删除的表格的名称的字符串)、tablestatus(例如，具有值“deleting”的字符串)、keyschema(例如，描述主键的数组)和datecreated(其可以是指示创建表格时的日期和/或时间的字符串或数字)。如上所述，在一些实施方案中，keyschema可以包括描述简易或组合主键的数组。例如，简易主键可以包括单个散列键，而组合键可以包括散列键和范围键。在一个实施方案中，主键的索引类型可以是hash或range，且主键的每个属性可以包括名称(其可以是包括属性的名称的字符串)、属性值的数据类型(例如，n或s)和属性值。如先前提及，在不同实施方案中，deletetable请求和/或响应可以以json请求/响应格式或另一合适的格式提出。根据一个实施方案，下文发现对数据存储服务的请求和接收自数据存储服务且对应于deletetableapi的响应的实例。示例性请求格式：示例性响应格式：在各种实施方案中，describetablesapi可以用来枚举(例如，列举)关于属于给定存储服务客户端的表格的信息。例如，响应于接收代表用户描述属于所述用户的表格的请求，数据存储系统可以返回请求中指定的任何表格或(如果没有指定表格)属于所述用户的所有表格的主键信息和/或状态。在一些实施方案中，describetablesapi的输入参数可以包括tablenames参数(其可以是包括要描述的表格的名称的字符串的清单)和/或lasttablename参数(其可以是包括在超过对可包括在响应中的表格数量的预定限制时继续列举其表格信息的表格的名称的字符串)。例如，在一些实施方案中，如果要返回的表格数量超过预定限制，那么可以提前终止查询(即，不描述请求作为目标的所有表格)且可以返回由查询考虑的最后表格的名称。在此类实施方案中，这个最后表格的名称随后可以用来继续从所述点向上查询。在一些实施方案中，如果tablenames参数是空的(或未用其他方式指定)，那么可以在对describetables请求的一个或多个响应中描述属于用户的所有表格。在一些实施方案中，describetablesapi的输出参数可以包括tables参数(其可以包括给定用户拥有的表格的清单和关于所述表格中的每个的信息)和/或lasttablename参数(其可以指示返回关于其信息的最后表格的名称(如果表格的数量超过关于可响应于单个describetables调用而返回其信息的表格的最大数量))。在一些实施方案中，对于响应中列举的每个表格，可以包括下列信息中的任何一个或所有：tablename(例如，包括表格的名称的字符串)、tablestatus(例如，具有值“creating”、“active”或“deleting”的字符串)、keyschema(例如，描述主键的数组)和datecreated(其可以是指示创建表格时的日期和/或时间的字符串或数字)。如上所述，在一些实施方案中，keyschema可以包括描述简易或组合主键的数组。例如，简易主键可以包括单个散列键，而组合键可以包括散列键和范围键。在一个实施方案中，主键的索引类型可以是hash或range，且主键的每个属性可以包括名称(其可以是包括属性的名称的字符串)、属性值的数据类型(例如，n或s)和属性值。在一些实施方案中，如果不存在describetables请求中指定的表格中的一个或多个，那么可以响应于请求而返回错误指示(例如，400“resourcenotfound”错误指示)。正如由数据存储服务提供的其它api，在不同实施方案中，describetables请求和/或响应可以以json请求/响应格式或另一合适的格式提出。根据一个实施方案，下文发现对数据存储服务的请求和接收自数据存储服务且对应于describetablesapi的响应的实例。示例性请求格式：示例性响应格式：如上文提及，本文中描述的数据存储服务(和/或底层系统)可以提供用于执行项目级操作的各种数据平面api(诸如putitemapi、getitemapi、deleteitemapi和/或updateitemapi)和用于跨表格中的多个项目执行一个或多个基于索引的寻求/遍历操作的各种数据平面api(诸如queryapi和/或scanapi)。在一些实施方案中，putitemapi可以用来将新的(单个)项目插入到表格中。在一些实施方案中，这个api可以用来执行条件放置操作。例如，如果表格中尚不存在项目(根据主键的指定值)，那么这个api可以用来将项目插入到所述表格中，或如果所述项目具有某些属性值(例如，指定主键)，那么所述项目可以用来替换表格中的单个现有项目。更具体地说，在一些实施方案中，这个api可以用来用新的属性完全替换现有项目的(除了主键以外的)所有属性以创建“新”项目。在此类实施方案中，数据存储系统可以保证自动地执行这个替换操作。换句话说，系统可以用保证仅用其所有新属性或其所有先前属性就可观察到项目而在过渡状态中(例如，先前属性和新属性混合)无法观察所述项目的方式来执行替换操作。在一些实施方案中，如果没有指定条件放置操作，那么putitemapi可以是幂等api。换句话说，即使以相同输入参数值多次调用putitemapi，使用putitemapi的非条件形式作出的请求也可以只将指定新项目精确地插入到表格中一次。在一些实施方案中，putitemapi的输入参数可以包括tablename(其可以是包括要插入或替换项目的表格的名称的字符串)、item参数(其可以将一个或多个属性名称映射到各自属性值)、expected参数(其可以为条件放置指定属性名称到各自属性值的映射)和/或returnvalues参数(其可以是指示(如果有)应将哪些值作为操作的结果(例如，“none”、“all_old”或“all_new“)返回的字符串)。在一些实施方案中，如果指定returnvalues参数值“none”，那么这个api可以不返回值。如果指定returnvalues参数值“all_old”，那么这个api可以返回由putitem操作重写的项目的先前内容。如果指定returnvalues参数值“all_new“，那么这个api可以在putitem操作之后返回所述项目的内容。注意在一些实施方案中，包括在item参数中的映射必须包括如定义用于指定表格的主键属性。在一些实施方案中，包括在expected参数中的每个属性可以包括expectedattributevalue(其可以是具有值“exists”或“value”的字符串)、attributevalue(其可以指示用于条件评估的属性的值或可以具有空白或空值)和/或exists参数(其可以指示要评估的条件是是否当前为现有项目指定包括在expected参数中的属性)。在这个实例中，如果将expectedattributevalue设置成“value”，那么必须为attributevalue供应值，而如果将expectedattributevalue设置成“exists”，那么attributevalue应是空值或空白的。如果不满足请求中经由putitemapi指定的条件(例如，如果一个或多个属性的期望值不匹配存储在表格中的值)，那么可以由数据存储系统返回错误指示(例如，conditionalcheckfailed)。在不同实施方案中，putitem请求可以以json请求格式或另一合适的格式提出。以下是仅在项目尚不包括填充“标签”字段的条件下将所述项目存储在表格中的putitem请求的实例。本质上，这个实例示出具有put-if-absent语义的放置操作。示例性请求格式：在一些实施方案中，putitemapi的输出参数可以包括属性参数(其可以将一个或多个属性名称映射到其各自值)。在上述实例中，仅当输入参数returnvalues并非“none”时才可以返回这个映射。以下是接收自数据存储服务且对应于其中将returnvalues指定为"all_old"的putitem请求的响应的实例。示例性响应格式：putitemapi的使用可以通过下列实例(即，通过下文的伪代码)来进一步示出。在第一实例中，请求将主键是散列值“id”的新项目添加到名称是“my-table2”的表格。在这个实例中，项目包括id值(是数字)和额外属性类别、子类别、颜色和大小(其中的每个指定一个或多个字符串)的值。在第二实例中，请求使用putitemapi替换现有项目。在这个实例中，请求用具有新属性的项目替换现有项目(具有主键值id＝1的项目)。注意，通过将returnvalues参数设置成“all_old“，这个请求指定应返回项目的旧属性。在各种实施方案中，deleteitemapi可以用来删除表格中的单个项目，其中项目是由其主键识别。在一些实施方案中，这个api可以用来执行条件删除操作。例如，如果项目存在或如果项目具有某些属性值(例如，除了指定主键以外的特定属性值)，那么这个api可以用来删除所述项目。在一些实施方案中，如果未指定条件放置操作，那么deleteitemapi可以是幂等api。换句话说，即使以相同输入参数值多次调用deleteitemapi，使用deleteitemapi的非条件形式作出的请求也可以只能造成系统精确地删除表格中的指定新项目一次。在这些和其它实施方案中，尝试删除不存在项目可能不会造成错误状况，且可能不会造成返回错误指示。在一些实施方案中，deleteitemapi的输入参数可以包括tablename(其可以是包括要从其中删除项目的表格的名称的字符串)、key(其可以指定识别要删除的项目的简易/单个或组合主键)、expected参数(其可以为条件删除指定属性名称到各自属性值的映射)和/或returnvalues(其可以是指示(如果有)应将哪些值作为操作的结果(例如，“none”、“all_old”)返回的字符串)。在一些实施方案中，如果指定returnvalues参数值“none”，那么这个api可以不返回值。如果指定returnvalues参数值“all_old”，那么这个api可以返回由这个操作删除的项目的内容。例如，当指定“all_old”时，这个api的输出参数可以包括attributes参数(其可以包括已删除项目的所有属性的属性名称与其各自值之间的映射)。在一些实施方案中，包括在expected参数中的每个属性可以包括expectedattributevalue(其可以是具有值“exists”或“value”的字符串)、attributevalue(其可以指示属性的值或可以具有空白或空值)和/或exists参数(其可以指示要评估的条件是是否当前为现有项目指定包括在expected参数中的属性)。如果不满足请求中经由deleteitemapi指定的条件(例如，如果一个或多个属性的期望值不匹配存储在表格中的值)，那么可以由数据存储系统返回错误指示(例如，conditionalcheckfailed)。在一些实施方案中，在不同实施方案中，deleteitem请求和/或响应可以以json请求/响应格式或另一合适的格式呈现。根据一个实施方案，下文发现删除项目的请求和接收自数据存储服务且对应于deleteitemapi的响应的实例。示例性请求格式：示例性响应格式：注意在上文示出的实例中，所述请求未指定returnvalues参数值，但是返回旧的属性值。这示出returnvalues参数的默认值是"all_old"的实施方案。在其它实施方案中，这个参数的默认值可以是不同值(例如，"all_new"或"none")，或这个参数可以没有默认值(即，其可以是强制输入参数)。在各种实施方案中，getitemsapi可以用来就一个或多个项目的给定主键而检索所述一个或多个项目(即，返回所述项目的一个或多个属性)。在一些实施方案中，可响应于单个getitems请求而检索的项目数可能受到限制，和/或所检索的项目必须全部存储在相同表格中。例如，在一个实施方案中，可以响应于单个getitems请求而返回最大为8个项目的属性。在一些实施方案中，可以从表格中并行检索多个项目，这可以最小化等待时间。在各种实施方案中，数据存储服务(和/或底层系统)可以支持投影和/或一致读取(未受到等待时间惩罚)。在一些实施方案中，系统可以默认支持最终一致性模型，这可以造成服务请求的吞吐量较高。在以单个getitems请求来请求多个项目的一些实施方案中，将不会返回目标表格中不存在的项目。在这种情况下，可以返回或可以不返回任何错误消息以指示不返回所请求项目中的一个或多个。在一些实施方案中，getitemsapi的输入参数可以包括tablename(其可以是包括要从其中删除项目的表格的名称的字符串)、keys参数(其可以指定识别要检索的项目的简易/单个或组合主键的清单)、attributestoget参数(其可以是作为字符串的属性名称的数组)和/或consistentread参数(其可以是指示将是否发出一致读取的布尔值)。在一些实施方案中，如果未指定属性名称，那么可以返回定义用于所识别项目的所有属性值。在一些实施方案中，如果未发现指定属性中的任何一个的值，那么结果中将不会出现对应属性名称。在一些实施方案中，如果将consistentread参数设置成真，那么将发出一致读取操作。否则，将执行最终一致读取操作。注意在一些实施方案中，严格一致读取(例如，对于所述读取consistentread参数的值是真)可能针对给定副本组的主副本，而经执行具有最终一致性的读取可能针对给定副本组的副本中的任何一个。如先前提及，在一些实施方案中，可响应于单个getitems请求而检索的项目数可以限于预定数量。getitemsapi的输出参数可以包括items参数，其可以是项目的数组，项目中的每个包括所请求属性和其值的映射(如果为项目指定任何一个，即，非空)。注意在一些实施方案中，可以不以任何特定方式排序数组中的项目。在此类实施方案中，所请求属性的清单中包括主键可以提供一种识别对应于每个检索项目的属性和/或确定所请求项目中的哪一个被(和/或未被)发现并检索的方式。在一些实施方案中，虽然可以应用表格9中列举且本文中描述的错误指示符中的一个或多个，但是这个api可以不存在任何具体定义的错误指示。根据一个实施方案，下文发现使用getitemsapi检索多个项目的请求和接收自数据存储服务且对应于所述请求的响应的实例。示例性请求格式：示例性响应格式：在各种实施方案中，可以由数据存储服务(和/或底层系统)提供updateitemapi。这个api可以用来在项目尚不存在时插入所述项目，或用来在属性级别操控现有项目(例如，修改其属性中的一个或多个的值)。例如，更新项目可以包括插入、替换和/或删除现有项目的各种属性。在一些实施方案中，更新项目可以包括使具有数字类型的属性的值自动递增或递减。虽然上述putitemapi可以用来替换现有项目的所有属性值，但是本文中描述的updateitemapi可以提供更细的替换操作。换句话说，这个api可以用来修改现有项目的属性值的子集和/或修改定义用于现有项目的属性集。图9中的流程图示出用于响应于更新项目的请求而更新项目的方法的一个实施方案。如910处示出，在这个实例中，所述方法可以包括接收更新非关系数据库中的表格(代表数据存储服务客户端维护的表格)中的项目的服务请求。如在先前实例中，updateitem请求可以包括表格名称和主键(其可以共同地识别是更新请求目标的项目)和指示所请求的更新的一个或多个其它输入参数值。如果所述请求指示应给项目添加项目属性(如920)，那么包括在所述请求中的属性可以被添加到所述项目且可以被指派也包括在所述请求中的值(如925)。例如，响应于包括用于尚不存在于项目中的特定属性名称的put动作的updateitem请求，可以将对应于put动作的属性名称值对添加到项目。类似地，响应于包括用于尚不存在于项目中的标量数值属性或集合类型属性的add动作的updateitem请求，可以将对应于add动作的属性名称值对添加到项目。如这个实例中示出，如果所述请求指示应替换项目中的项目属性的值(如930)，那么包括在所述请求中的属性的值可以由也包括在所述请求中的值替换(如935)。例如，响应于包括用于尚不存在于项目中的特定属性名称的put动作的updateitem请求，可以用与所述请求中的put动作相关联的属性名称值对中指定的值来更新所述属性的值。如图9中示出，如果所述请求指示应从项目中移除项目属性(如940)，那么可以从所述项目中移除所述属性和其值(如945)。例如，响应于包括用于存在于项目中的标量类型属性的delete动作的updateitem请求，可以从所述项目中移除所述属性和其值。类似地，响应于包括用于存在于项目中的集合类型属性的delete动作的updateitem请求，如果所述请求未指定属性的集合中的值的任何一个，那么可以从所述项目中移除所述属性和其整个值集合。如这个实例中示出，如果所述请求指示应给项目属性的值集合添加或从项目属性的值集合中移除一个或多个值(如950)，那么可以给所述集合添加或从所述集合中移除包括在所述请求中的属性的指定值(如955)。例如，响应于包括用于已经存在于项目中的集合类型属性名称的add动作的updateitem请求，可以给项目中的属性的值集合添加与所述请求中的add动作相关联的属性名称值对中指定的一个或多个值。相反地，响应于包括用于已经存在于项目中的集合类型属性名称的delete动作的updateitem请求，可以从项目中的属性的值集合中移除与所述请求中的delete动作相关联的属性名称值对中指定的一个或多个值。如果所述请求指示应递增或递减项目中的属性的值(如960)，那么包括在所述请求中的属性的值可以自动递增或递减某个量，这个量也可以包括在所述请求中(如965)。例如，响应于包括用于已经存在于项目中的标量数值属性名称的add动作的updateitem请求，所述项目的值可以自动地递增所述请求中指定的量(例如，如果指定量是正数)或自动地递减达所述请求中指定的量(例如，如果指定量是负数)。在其它实施方案中，数值属性的值总是可以递增或递减默认量，或可以在请求中未指定值递增或递减的量时递增或递减默认量。如图9中的970处示出，一旦执行updateitem请求中指定的任何有效更新，就可以完成所述方法。然而，如果指定更新中的任何一个是无效的(例如，如果丢失任何输入参数或其值是错误类型，等等)，那么所述方法可以包括返回一个或多个错误指示。在一些实施方案中，即使请求中指定的其它更新是无效的，也可以执行请求中指定的任何有效更新。在其它实施方案中，如果指定更新中的任何一个是无效的，那么将不会执行更新中的任何一个。如上文提及，在一些实施方案中，单个updateitem服务请求可以指定施加多次更新于单个项目的各种属性。因此，如果单个服务请求中指定对应类型的多次更新中的两次，那么可以多次执行图9中示出的更新操作(例如，925、935、945、955、965)中的每个。此外，单个请求可以指示应对各自项目属性执行不同类型的更新。因此，可以响应于单个updateitem请求而执行图9中示出的更新操作(例如，925、935、945、955、965)中的多个操作。这在图9中由从925到930的反馈、从935到940的反馈、从945到950的反馈和从955到960的反馈来加以示出。在各种实施方案中，由数据存储服务(和/或底层系统)提供的updateitemapi可以执行条件更新。在此类实施方案中，这个api可以用来有条件地插入项目(例如，如果项目尚不存在，那么创建项目)，或(例如，只有在项目的属性匹配任何指定期望值时，方能)有条件地替换(即，更新)项目。更新项目可以包括插入、更新和/或删除现有项目的各种属性。在一些实施方案中，数据存储系统可以视情况为使用这个api替换/更新的项目返回旧的属性值。在一些实施方案中，updateitemapi的输入参数可以包括tablename(其可以是包括其中存储要更新项目的或其中要有条件地插入项目的表格的名称的字符串)、key参数(其可以指定识别要有条件地更新或插入的项目的简易/单个或组合主键)、attributeupdates参数(其可以是将一个或多个指定属性名称中的每个映射到各自attributeupdate结构的数组)、expected参数(其可以为条件放置指定属性名称到各自属性值的映射)和/或returnvalues参数(其可以是指示(如果有)应将哪些值作为操作的结果(例如，“none”，“all_old”、“update_old”、“all_new”或“updated_new”)返回的字符串)。每个attributeupdate结构可以包括attributevalue参数(其可以为对应属性指定更新值)和action参数(其可以是指定要采取的动作的字符串(例如，“put”、“add”或“delete”)。当支持add动作时，add动作可以允许数值属性值自动地递增或递减指定量。注意，因为可以为要修改的每个属性指定各自action参数值，所以可以使用单个updateitem操作来施加不同动作于updateitem请求作为目标的属性中的每个。例如，响应于单个updateitem请求，数据存储系统可以删除指定项目的一个或多个属性值、使指定项目的一个或多个其它属性值递增或递减和/或用指定的新值替换一个或多个其它属性值。在一些实施方案中，action参数的默认值(例如，如果未指定任何值)可以是“put”。注意，因为每个项目必须具有不变主键，所以不能使用updateitemapi来修改或删除是所述键的部分的属性。换句话说，attributeupdates参数不能包括对任何主键属性的参考。也应注意，当指定action参数值是“delete”时，可以任选attributevalue参数。在一些实施方案中，包括在expected参数中的每个属性可以包括expectedattributevalue(其可以是具有值“exists”或“value”的字符串)、attributevalue(其可以指示属性的值或可以具有空白或空值)和/或exists参数(其可以指示要评估的条件是是否当前为现有项目指定包括在expected参数中的属性)。如果不满足请求中经由updateitemapi指定的条件(例如，如果一个或多个属性的期望值不匹配存储在表格中的值)，那么可以由数据存储装置返回错误指示(例如，conditionalcheckfailed)。在一些实施方案中，如果指定returnvalues参数值“none”，那么这个api可以不返回任何值。如果指定returnvalues参数值“all_old”，那么这个api可以返回在执行updateitem操作之前updateitem操作作为目标的项目的内容(即，所有属性值)。如果指定returnvalues参数值“update_old”，那么可以仅返回任何已更新属性的先前值(而非所有属性值)。如果指定returnvalues参数值“all_new”，那么可以返回目标项目的新版本的所有属性(即，在执行updateitem操作之后所述项目的所有属性值)。如果指定returnvalues参数值“update_new”，那么可以仅返回任何已更新属性的新值(而非所有属性值)。图10中的流程图示出用于使用支持条件更新和/或多个输出选项的api来更新项目的方法的一个实施方案。如这个实例中示出，所述方法可以包括接收更新非关系数据库中的表格(代表数据存储服务客户端维护的表格)中的项目的服务请求。如在先前实例中，updateitem请求可以包括表格名称和主键(其可以共同地识别是更新请求目标的项目)和指示所请求的更新的一个或多个其它输入参数值。如果更新请求并非以项目中的任何属性值为条件(示为1020的否定退出)，那么可以执行请求中指定的更新(如1050)。然而，如果更新请求是以项目中匹配请求中指定的对应值的一个或多个属性值为条件(例如，如果updateitem请求的输入包括指定要满足的一个或多个条件的expected结构)(示为1020的肯定退出)，那么所述方法可以包括确定是否满足指定条件中的每个。如这个实例中示出，可以在执行请求中指定的更新之前评估指定条件中的每个(如1030)。如果满足给定条件(示为1030的肯定退出)，但是所述请求指定额外条件(示为1040的肯定退出)，那么可以评估所述额外条件(示为从1040到1030的反馈)。如果满足给定条件(示为1030的肯定退出)且所述请求未指定任何额外条件(示为1040的否定退出)，那么可以执行所请求更新(如1050)。如果不满足指定条件中的任何一个(示为1030的否定退出)，那么可以不执行所请求更新。如这个实例中示出，如果服务请求指定应输出项目的属性的更新前和/或更新后的值(示为1060的肯定退出)，那么所述方法可以包括返回所述项目的更新前和/或更新后的属性值(如1070)，且可以完成更新项目操作(如1080)。例如，如果将updateitem请求的returnvalues参数设置成“all_old”、“update_old”、“all_new”或“updated_new”，那么可以响应于完成项目更新程序而返回对应旧和/或新的属性值。如果将returnvalues参数设置成“none”或未指定用于请求，那么可以不返回任何属性值。注意，如果不满足指定条件中的任何一个，那么所述响应可以包括一个或多个错误指示(诸如本文中描述的那些指示)，而不论所述响应中是否返回旧和/或新的属性值中的任何一个。根据一个实施方案，下表中总结了对在对应属性值上指定可能的action参数值中的响应。表格4-将现有项目作为目标的更新动作表格5-将不存在的项目作为目标的更新动作注意，在一些实施方案中，为标量属性的删除类型更新供应属性值可能出现错误。在一些实施方案中，为集合类型属性的删除类型更新供应空集合可能出现错误。在一些实施方案中，集合类型属性的删除类型更新和/或集合类型属性的添加类型更新的供应值的类型必须匹配现有值类型。如上所述，add动作可以仅对类型数字的标量属性或集合类型属性有效，且可以对标量字符串类型无效。如上表中所示，在一些实施方案中，当updateitem请求作为目标的项目不存在且使用至少一个put或add动作参数值实行更新动作时，可以创建项目。然而，如果updateitem操作是将不存在项目作为目标且仅指定delete动作，那么将不会创建新项目。在不同实施方案中，正如由数据存储服务提供的其它api，updateitem请求和/或响应可以以json请求/响应格式或另一合适的格式呈现。根据一个实施方案，下文发现对数据存储服务的请求和接收自数据存储服务且对应于updateitemapi的响应的实例。示例性请求格式：示例性响应格式：在这个实例中，指定更新是以rating属性的不存在和以是“flower”的title属性的值为条件。响应于确定这些条件均评估为真，对title和tags属性进行指定更新。注意在这个实例中，将包括returnvalues参数的updateitem请求设置成update_new。因此，所述响应仅包括经定义用于指定更新操作作为目标的属性的新值(即，“title”属性的新值和“tags”属性的新值)。如先前提及，在主键是简易键的实施方案中，可以使用代表存储服务客户端维护的表格中的项目中的每个的主键值的散列表来分区所述项目，而在主键是组合键的实施方案中，可以首先由散列键组件的散列表来分区数据且然后由范围键组件来分区数据。图11示出根据一个实施方案的用于使用简易和/或组合键分区表格数据的方法的一个实施方案。如1110处示出，在这个实例中，所述方法可以包括数据存储服务(或实施数据存储的底层系统的组件，诸如存储节点实体或管理组件)开始对代表存储服务客户端在非关系数据存储装置中维护的表格进行分区。如果表格中的多个项目共享散列键属性值(示为1120的肯定退出)，那么所述方法可以包括数据存储装置首先取决于表格中具有给定散列键属性值的项目的范围键属性值的散列表且然后取决于所述项目的范围键属性值来将所述项目分成两个或更多个分区(例如，数据库分区)(如1140)。换句话说，如果表格的主键是包括散列键组件(其值可以用来识别一组项目)和范围键组件(其值可以用来排序具有相同散列键属性值的项目并唯一地识别所述项目中的每个)的组合键，那么散列键属性值和范围键属性值均可以用来分区表格中的项目。例如，对于具有相同散列键属性值的一组项目，所述组中的前n个项目(由其各自范围键属性值排序)可以被指派到一个分区，所述组中的接下来的m个项目可以被指派到第二分区，以此类推。注意在一些实施方案中，每个分区可以包括共享一个散列键属性值的项目的部分且也可以包括具有其它散列键属性值的其它项目。如果表格中的项目均没有共享散列键属性值(示为1120的否定退出)，那么所述方法可以包括数据存储装置取决于表格中的项目的各自散列键属性值的散列表将所述项目分成两个或更多个分区(如1130)。例如，如果表格的主键是包括散列键组件(其值可以用来唯一地识别表格中的项目中的每个)的简易键，那么可以取决于散列键属性值的散列表但不取决于任何其它项目属性值来分区表格中的项目(即，将所述项目指派给多个分区之一)。在一些实施方案中，如果主键是组合键，但是表格中的项目均不共享散列键属性值(即，如果每个项目具有唯一散列键属性值)，那么数据存储装置可以分区项目如同主键是简易键一样(即，其可以仅使用散列键属性值分区表格中的项目)。一旦数据存储装置将所有项目指派到分区，数据存储装置就可以将分区中的每个存储在各自存储节点(例如，各自计算节点或存储装置)上(如1150)。在一些实施方案中，单个表格的每个分区可以存储在不同存储节点上，而在其它实施方案中，分区中的两个或更多个可以维护在相同存储节点上。注意在一些实施方案中，可以预确定给定表格的项目被分区的分区数量(例如，其可以基于用户输入/优选或客户端的历史数据、账号或表格类型)，而在其它实施方案中，可以随着分区操作的进展(例如，基于散列结果的每个范围中的项目数和/或范围键属性值的每个范围中的项目数)确定给定表格的项目被分区的分区数量。也应注意，因为分区是基于散列结果，所以可以稍微使可以在可用分区中指派和分布多组项目的次序随机化。在一些情况下，例如，如果一些项目的存取频率远大于其它项目或一些项目组包括的项目数高于其它组，那么初始分区可以造成热点。在此类情况下，可以执行再分区操作以(例如，关于数据量和/或服务请求通信量)将项目更均匀地分布在可用分区中。也应注意，在一些实施方案中，可以使用单个散列键组件和两个或更多个范围键组件分区表格中的项目。下表6示出使用类似于图11中示出的方法的方法对表格中的项目进行分区的实例。在这个实例中，散列键属性是“用户名”属性且范围键属性是“消息id”属性。表格存储与三个用户名(bob、sue和phil)中的每个相关联的多个消息。如表格6中示出，给定表格的一些分区可以仅包括具有相同散列键属性值的项目。在这个实例中，由分区id值a识别的分区仅存储具有散列键属性值“bob”的消息。注意，这个分区未存储bob的所有消息，仅存储具有消息id值(即，范围键属性值)1至199的消息。bob的另一组消息(具有范围键属性值200至299的那些消息)存储在由分区id值b识别的分区中。这个分区也存储具有散列键属性值“sue”的消息，具体地说具有范围键值1至50的那些消息。bob的又一组消息(具有范围键属性值300至399的那些消息)存储在由分区id值c识别的分区中。这个分区也存储具有散列键属性值“phil”的消息，具体地说具有范围键值1至100的那些消息。表格6在上述实例中，检索bob的所有消息的请求可以检索来自分区a的消息1至199(其可以维护在特定存储节点上)、来自分区b的消息200至299(其可以维护在不同存储节点上)和来自分区c的消息300至399(其可以维护在另外一个存储节点上)。如下文更详细地描述，在一些实施方案中，(例如，如果达到响应限制)，可以提前终止检索所有这些消息的请求，且可以响应于后续请求而检索剩余消息。在一些实施方案中，本文中描述的数据存储服务(和/或底层系统)可以提供用于代表存储服务客户端搜索维护在表格中的数据的两个不同api：scanapi和queryapi。在一些实施方案中，scanapi可以用来请求进行扫描整个表格的操作。scan请求可以指定施加一个或多个筛选器于扫描操作的结果(例如，以细化在完成扫描之后返回到请求器的值)。在一些实施方案中，服务(和/或底层系统)可以强加限制扫描结果，且可以在筛选结果之前施加限制。例如，在一些实施方案中，系统可以使用分页(例如，就评估或返回的项目数或扫描或返回的数据量将扫描或查询程序分成具有预定最大大小的不同片段)以快速对扫描和/或查询作出响应。例如，为了扫描大于预定最大大小(例如，1mb)或所得数据集大于预定最大大小(例如，1mb)的表格，可能需要执行多个扫描或查询操作以按1mb增量扫描整个表格。如果表格数据均不满足指定筛选准则，那么扫描操作可能不返回任何结果。在一些实施方案中，queryapi可以支持比较操作以将搜索程序限于匹配所供应查询条件(例如，以项目的属性为条件)的数据。例如，query请求可以用来寻找表格中匹配请求中指定的参数的所有数据，直到预定义限制为止(如果系统强加这种限制)。在一些实施方案中，query请求可以总是返回结果，但是系统可以在查询条件(即，属性筛选准则)不匹配结果中的任何一个时返回空白值。在各种实施方案中，queryapi可以用来在代表存储服务客户端(例如，用户、顾客、订户或客户端应用)维护的表格中查询存储在所述表格中的信息。在一些实施方案中，可以基于主索引(根据指定散列键，且在一些情况下根据满足指定范围键预测的单个范围键值)执行查询。在其它实施方案中，主键可以包括单个散列键组件和两个或更多个范围键组件。在一些实施方案中，queryapi的输入参数可以包括tablename(其可以是包括存储要更新的项目或要有条件地插入项目的表格的名称的字符串)、attributestoget参数(其可以是要返回值的属性的数组)、limit参数(其可以是指定响应于单个查询请求而返回的结果的最大数的整数)、consistentread参数(其可以是指示是否将发出一致读取的布尔值)、count参数(其可以是指示是否应返回匹配查询的项目的计数(而非所述项目的属性值)的布尔值)、hashkeyvalue(其可以为主键的散列组件指定attributevalue且可以强制性约束查询)、rangekeycondition(其可以指定约束主键的rangekey组件，且可以结合hashkeyvalue识别查询请求的一个或多个目标)、scanindexforward参数(其可以是指示是否向前或向后遍历索引的布尔值)和/或lastevaluatedkey参数(其可以在查询是可响应于单个查询请求而返回属性的项目数的预定限制已被超过的查询的延续时指定主键值用作所述查询的开始点)。在一些实施方案中，rangekeycondition参数可以取决于表格中的项目的范围键组件的值来指定要评估的数学或逻辑表达式。rangekeycondition参数可以包括comparisonoperator参数和一个或多个attributevalue。例如，在一个实施方案中，comparisonoperator可以是下列运算符之一：“eq”(即，等于)、“gt”(即，大于)、“ge”(即，大于或等于)、“lt”(即，小于)、“le”(即，小于或等于)、"beginswith"或"between"。在此类实施方案中，如果comparisonoperator是“eq”、“gt”、“ge”、“lt”、“le”或"beginswith"之一，那么attributevalue参数中仅可以包括一个值，而如果comparisonoperator是"between"，那么attributevalue参数中可以包括两个值。注意在一些实施方案中，可以按字典编辑对具有类型“字符串”(例如，具有表示为二进制字符串的utf8字符串)的属性进行指定比较，且可以按数值对具有类型“数字”的属性进行指定比较。在一些实施方案中，可以包括指定用于"between"运算符的所述两个值，其中第一值小于第二值。"beginswith"运算符可以是仅对标量字符串有效的前置运算符。在一些实施方案中，attributestoget参数可以包括属性类型和其名称。在一些实施方案中，如果未对查询请求指定属性名称(且如果count参数是“假”)，那么可以返回匹配查询条件的项目的所有属性。在一些实施方案中，如果count参数是“真”，那么可以不对响应于查询请求而由数据存储系统返回的匹配项目数施加任何预定义限制。(在单个查询请求中)将count参数设置成“真”和提供attributestoget的清单可能无效，且可能造成数据存储系统返回错误指示(例如，验证错误的指示)。在一些实施方案中，如果将consistentread参数设置成真，那么将发出一致读取操作。否则，将执行最终一致读取操作。如上文提及，如果匹配单个查询请求的项目数超过limit参数的值，那么当达到限制时可以终止查询。在这种情况下，数据存储系统可以为多个匹配项目返回属性值，直到返回limit参数的值为止，且可以包括可以用来(例如，通过包括lastevaluatedkey作为后续查询请求的输入)继续进行查询的延续令牌(即，这个lastevaluatedkey参数)。注意在一些实施方案中，数据存储系统可以支持使用queryapi对响应于查询请求而返回的匹配项目数进行全系统限制和/或(即，使用上述limit参数)对匹配项目数进行请求专用限制。在一些这样的实施方案中，当满足这些限制中的任何一个时(例如，如果在满足请求专用限制之前满足全系统限制，或反之亦然)可以终止查询并将延续令牌返回到请求器。在一些实施方案中，query请求的返回参数可以包括items参数(其可以包括匹配指定查询条件的项目的清单和/或项目相关属性值)、count参数(其可以指示响应中的项目数)和/或lastevaluatedkey参数(如上所述，其可以指定在达到对可以响应于单个查询请求而返回关于其信息的项目的数量的预定限制之前的查询期间评估的最后项目的主键值)。如上文提及，如果已超过对可响应于单个查询请求而返回关于其信息的项目的数量的预定限制，那么lastevaluatedkey参数可以用作查询的延续的开始点。注意在一些实施方案中，对于queryapi，响应中总是可以返回count参数而不论是否也返回匹配项目(和/或其属性)。正如由数据存储服务提供的其它api，在不同实施方案中，query请求和/或响应可以以json请求/响应格式或另一合适的格式呈现。根据一个实施方案，下文发现对数据存储服务的请求和接收自数据存储服务且对应于queryapi的响应的实例。根据一个实施方案，下文实例示出可以用来为单个顾客(即，customerid是“12345678”的顾客)检索来自称作“pictures”的表格的所有项目(其具有介于"***"与"****"之间的分级)的查询和对所述查询请求作出的响应。示例性请求格式：示例性响应格式图12中的流程图示出用于执行如由本文中描述的api指定的查询的方法的一个实施方案。如1210处示出，在这个实例中，所述方法可以包括接收执行针对非关系数据库中的表格(例如，代表数据存储服务客户端维护的表格)中的一个或多个项目的查询的服务请求。如在先前实例中，所述请求可以包括表格名称(其可以识别是查询请求的目标的表格)和主键值。如果指定主键值是单个属性散列键值(例如，如果所识别表格的主键是取决于单个属性的值的简易主键时)，查询可以将由表格名称和主键值的组合唯一地识别的单个项目作为目标。在这种情况下(示为1220的肯定退出)，所述方法可以包括取决于指定散列键值使查询针对表格中包括所述项目的单个分区。在这种情况下，所述方法也可以包括返回包括所识别的单个项目的一个或多个属性值的响应(如1250)。如本文中所述，如果指定主键值是组合键值(例如，如果所识别表格的主键是取决于散列键值和范围键值的组合主键)，那么查询可以针对匹配指定散列键值和指定范围键条件的一个或多个项目。在这个实例中，如果所述请求指定散列键属性值和单个范围键属性值(例如，如果所述请求包括范围键条件指定范围键值等于特定值)(示为1240的肯定退出)，那么所述方法可以再次包括取决于指定散列键值使查询针对表格中包括所述项目的单个分区和返回包括所识别的单个项目的一个或多个属性值的响应(如1250)。在这个实例中，如果所述请求指定散列键属性值和可以匹配多个范围键属性值的范围键条件(示为1240的否定退出)，那么所述方法可以包括取决于指定散列键值和范围键条件使查询针对表格的一个或多个分区(如1260)。例如，如果匹配指定散列键值的项目(例如，范围键值落在给定范围内的项目)中的一些存储在表格的一个分区上，但是匹配指定散列键值的其它项目(例如，范围键值落在不同范围内的项目)存储在表格的另一分区上，那么可以使查询针对多个分区(且在一些情况下，上面托管所述分区的多个机器)以识别匹配指定散列键值和指定范围键条件两者的所有项目。在这种情况下，所述方法可以包括返回包括匹配散列键值和范围键条件两者的一个或多个项目的一个或多个属性值的响应(如1270)，其中可以从不同分区(且在一些情况下，不同机器)中检索匹配散列键值和范围键条件两者的所述一个或多个项目中的一些。注意，针对单个项目(例如，为简易主键指定散列键值或指定散列键值和单个范围键值的一个项目(如1240的肯定退出))的查询可以实施类似于对应getitem请求的功能的功能，其中支持参数个数和类型的一定变动。在一些实施方案中，可以由queryapi提供getitemapi的功能(如上所述)，而在其它实施方案中，可以由不同api(例如，getitemapi和queryapi)提供本文中描述的getitem功能和本文中描述的query功能。根据一个实施方案，图13中的流程图示出用于执行如由本文中描述的api指定的查询的方法的更详细实例。如1310处示出，在这个实例中，所述方法可以包括接收执行针对非关系数据库中的表格(例如，代表数据存储服务客户端维护的表格)中的一个或多个项目的查询的服务请求。如在先前实例中，所述请求可以包括表格名称(其可以识别是查询的目标的表格)和主键值。如本文中所述，在这个实例中，指定主键值是组合键值(即，所识别表格的主键是取决于散列键值和范围键值的组合主键)，且所述查询可以将匹配请求中指定的散列键值和范围键条件的多个项目作为目标。如1320处示出，所述方法可以包括解析所述请求以确定请求中指定的散列值和范围值。所述方法可以包括取决于指定散列值和范围值使查询针对包括查询的初始目标的分区和从所述分区中检索关于查询的一个或多个目标的信息(例如，查询作为目标的项目的属性值)(如1330)。例如，在一些实施方案中，匹配特定散列键值的项目可以由其范围键值在表格中加以排序。在此类实施方案中，指定散列键值和匹配指定范围键条件的第一范围键值的组合可以唯一地识别表格中匹配查询条件的第一项目。在此类实施方案中，可以首先使查询针对包括由这个组合识别的项目的分区。在一些情况下，查询针对的第一分区上可以存在匹配指定散列键值和指定范围键条件的一个或多个额外项目，且可以响应于查询而返回所有这些目标(即，项目本身和/或其属性值的指定子集)。在一些情况下，匹配指定散列键值和指定范围键条件两者的项目中的一些可以存储在表格中除了查询针对的第一分区以外的一个或多个分区上。如果是(示为1340的否定退出)，那么查询可以针对所述一个或多个其它分区，且可以检索这些额外查询目标(如1350)。例如，匹配指定散列键值和指定范围键条件两者的项目数可以大于存储在表格的每个分区中的项目数。在另一实例中，由于在表格中排序项目并将项目存储在表格中和/或将项目指派到各个分区的次序(例如，在项目以特定次序排序并根据其范围键值指派到特定分区的实施方案中)，目标项目可以跨分区边界。在这些和其它情况下，所述方法可以包括返回包括匹配散列键值和范围键条件两者的一个或多个项目的一个或多个属性值的响应(如1370)，其中可以从不同分区(且在一些情况下，不同物理计算节点或存储装置)中检索匹配散列键值和范围键条件两者的所述一个或多个项目中的一些。然而，如图13中示出，如果匹配指定散列键值和指定范围键条件两者的所有项目存储在查询针对的第一分区上(示为1340的肯定退出)，那么所述方法可以包括返回包括匹配散列键值和范围键条件两者的一个或多个项目的一个或多个属性值的响应(如1360)，其中从最初目标分区(且因此，单个物理计算节点或存储装置)中检索匹配散列键值和范围键条件两者的所述一个或多个项目中的所有项目。queryapi的使用可以通过下列实例(即，下文的伪代码)来进一步示出。在第一实例中，请求对表格执行查询操作以检索存储在表格中开始于单词“the”且与单个顾客id编号相关联的所有电影标题。这个实例假设表格具有基于属性“id”和“电影标题”的组合主键。这个query请求可以用来对主键散列值2(例如，顾客id＝2)检索具有开始于“the”的范围值的所有项目(即，开始于“the”的电影标题)。如上文提及，在一些实施方案中，可以限制由单次查询(在筛选之前)返回的项目数(例如，限于1mb数据)。在此类实施方案中，如果查询需要返回1mb以上数据，那么可以基于具有最后返回值的项目的主键设置第二次查询。queryapi可以使用lastevaluatedkey参数中返回的值作为第二次查询的开始点。例如，由截断查询返回的lastevaluatedkey参数可以存储在变量中且作为exclusivestartkey输入参数值提供给下一次查询。下文的示例性伪代码示出这个系列操作。如本文中所述，可以将组合主键索引为散列索引和范围索引。这种多部键可以维持第一索引值与第二索引值之间的等级。例如，在下文示为表格7的地址表格使用顾客的userid作为散列值且使用表格中输入地址的年份作为识别地址表格中的每个项目的范围。表格中的所有条目必须具有userid和年份，而每个userid/年份主键可具有其它属性的任何集合。表格7在这个实例中，userid是散列索引，且仅支持对等式作出比较(即，值的精确匹配)。在这个实例中，年份是范围索引。因此，可以施加各种比较运算符于年份以在对表格执行查询时约束搜索。例如，query请求可以用来检索2010年之前的年份的bob的所有地址信息(即，查询指定年份属性值小于2010的条件)。这次查询将返回年份2009和2004的bob的地址信息，如表格7的第五个和第六个条目所示。注意，对于其它表格(诸如下文示出的表格8)，范围键可以是字符串类型属性，诸如电影标题。在这个实例中，表格可以由具有相同userid的项目的标题属性值(即，其范围键值)的值以字母表次序排序所述项目，且每个userid/标题对可以唯一地识别表格中的单个项目。表格8在各种实施方案中，scanapi可以用来通过跨表格执行全扫描来代表存储服务客户端检索存储在表格中的一个或多个项目和属性。可以通过指定筛选器来限制返回的项目。在一些实施方案中，scanapi支持的语义可以比上述queryapi更丰富。例如，它可以支持比较运算符，诸如"contains"、"isnull"、"in"等。在一些实施方案中，scanapi的输入参数可以包括支持用于上述queryapi的相同输入参数中的一些。例如，输入参数可以包括tablename(其可以是包括存储要更新的项目或要有条件地插入项目的表格的名称的字符串)、attributestoget参数(其可以是要返回值的属性的数组)、limit参数(其可以是指定响应于单个查询请求而返回的结果的最大数的整数)、count参数(其可以是指示是否应返回匹配查询的项目的计数(而非所述项目的属性值)的布尔值)和/或lastevaluatedkey参数(其可以在扫描操作是可响应于单个scan请求而返回信息的项目数的预定限制已被超过的扫描操作的延续时指定主键值用作所述扫描操作的开始点)。scanapi输入参数也可以包括scanfilter参数，其可以指定施加筛选器于结果集合。如下文所述，scanfilter可以将一个或多个attibutename值映射到对应scancondition结构。在一些实施方案中，项目要匹配筛选器可能需要满足所有指定扫描条件且所述扫描条件包括在结果集合中。在一些实施方案中，每个scancondition结构可以指定匹配的条件且对应attributesvalues参数可以包括将与扫描条件进行比较的属性值的清单。在一些实施方案中，可以使用具有下列值之一的comparisonoperator参数指定扫描条件：“eq”(即，等于)、“ne”(即，不等于)、“gt”(即，大于)、“ge”(即，大于或等于)、“lt”(即，小于)、“le”(即，小于或等于)、"notnull"(即，属性存在)、"null"(即，属性不存在)、“contains”(即，多值属性包括指定值)、“notcontains”(即，多值属性不包括指定值)、"beginswith"、“in”(即，属性匹配指定值之一)或"between"。在一些实施方案中，如果comparisonoperator是“eq”、“gt”、“ge”、“lt”、“le”或"beginswith"之一，那么attributevalues参数中可以包括单个标量值。如果comparisonoperator是“in”，那么所有指定属性值可以是标量且是相同类型。如果comparisonoperator是"between"，那么attributevalues参数中可以包括两个值。如果comparisonoperator是“contains”或“notcontains”，那么attributevalues参数可以是多值或标量字符串(例如，对于标量字符串属性，所述比较可以转化成对子字符串匹配的搜索)。如果comparisonoperator是"null"或"notnull"，那么attributevalues参数可以是空白的(或空值)，且为attributevalues参数提供任何值可以造成返回错误指示。注意在一些实施方案中，可以按字典编辑对具有类型“字符串”(例如，具有表示为二进制字符串的utf8字符串)的属性进行指定比较，且可以按数值对具有类型“数字”的属性进行指定比较。在一些实施方案中，可以包括指定用于"between"运算符的所述两个值，其中第一值小于第二值。"beginswith"运算符可以是仅对标量字符串有效的前置运算符。在一些实施方案中，attributestoget参数可以包括属性类型和其名称。在一些实施方案中，如果未对扫描请求指定属性名称(且如果count参数是“假”)，那么可以返回匹配扫描条件的项目的所有属性。在一些实施方案中，如果count参数是“真”，那么可以不对响应于扫描请求而由数据存储系统返回的匹配项目数施加任何预定义限制。(在单个扫描请求中)将count参数设置成“真”和提供attributestoget的清单可能无效，且可能造成数据存储系统返回错误指示(例如，验证错误的指示)。如上文提及，如果匹配单个扫描请求的项目数超过limit参数的值，那么当达到限制时可以终止扫描操作。在这种情况下，数据存储系统可以为多个匹配项目返回属性值，直到返回limit参数的值为止，且可以包括可以用来(例如，通过包括lastevaluatedkey作为后续扫描请求的输入)继续进行扫描操作的延续令牌(即，这个lastevaluatedkey参数)。注意在一些实施方案中，数据存储系统可以支持使用scanapi对响应于扫描请求而返回的匹配项目数进行全系统限制和/或(即，使用上述limit参数)对匹配项目数进行请求专用限制。在一些这样的实施方案中，当满足这些限制中的任何一个时(例如，如果在满足请求专用限制之前满足全系统限制，或反之亦然)可以终止扫描操作并将延续令牌返回到请求器。注意在一些实施方案中，如上所述，响应于scan请求而执行的扫描程序可能并非一致读取操作。换句话说，扫描结果中可以不包括当发生扫描时已“扫描”的数据的变化。另一方面，如上所述，响应于query请求而执行的查询程序可以默认是最终一致读取操作，且可以支持指定应将查询执行为一致读取操作的选项。注意，在一些情况下，最终一致读取可能未反映最近完成的putitem或updateitem操作的结果。在一些实施方案中，scan请求的返回参数可以包括items参数(其可以包括项目的数组，其中的每个包括匹配指定扫描条件的属性值的映射)、count参数(其可以指示响应中表示的项目数)、scannedcount参数(其可以指示响应于scan请求而扫描的项目数)和/或lastevaluatedkey参数(如上所述，其可以指定在达到对响应于单个扫描请求而返回属性的项目数的预定限制之前的扫描操作期间评估的最后项目的主键值)。如上文提及，如果已超过对可响应于单个扫描请求而返回关于其信息的项目的数量的预定限制，那么lastevaluatedkey参数的值可以用作扫描操作的延续的开始点。注意在一些实施方案中，对于scanapi，响应中总是可以返回count参数而不论是否也返回匹配项目(和/或其属性)。正如由数据存储服务提供的其它api，在不同实施方案中，scan请求和/或响应可以以json请求/响应格式或另一合适的格式呈现。根据一个实施方案，下文发现对数据存储服务的请求和接收自数据存储服务且对应于scanapi的响应的实例。根据一个实施方案，下文实例示出可以用来检索存储在称作“pictures”的表格中的所有项目(其创建于“2009-12-12t10:30:30z”之后且具有分级"*"或"*****"(例如，最佳和最坏可用分级值))的标题和创建日期和对应响应。示例性请求格式示例性响应格式图14中的流程图示出用于执行表格扫描操作(诸如由本文中描述的scanapi定义的一个表格扫描操作)的方法的一个实施方案。注意在一些实施方案中，扫描整个表格可以涉及扫描两个或更多个分区，这些分区可以托管在两个或更多个物理计算节点或存储装置上。如1410处示出，在这个实例中，所述方法可以包括接收扫描非关系数据库中的表格(例如，代表数据存储服务客户端维护的表格)并返回一个或多个项目和/或其属性的服务请求。如在先前实例中，扫描请求可以包括表格名称(其可以识别是扫描请求的目标的表格)。请求也可以指定要返回值的一个或多个属性和/或一个或多个条件(通过其筛选或排序扫描操作的结果)。如果所述请求指定筛选准则(示为1420的肯定退出)，那么所述方法可以包括扫描表格和对筛选准则评估项目(如1430)。如上所述，筛选准则可以为表格中的项目的各种属性指定值、条件或值的范围。如果项目的属性值满足指定筛选准则(示为1440的肯定退出)，且所述请求指定响应中要返回值的一个或多个属性(示为1450的肯定退出)，那么项目中的指定属性的值可以包括在扫描请求的结果集合中(如1460)。如果项目的属性值满足指定筛选准则(示为1440的肯定退出)，但是所述请求未指定响应中要返回值的任何属性(示为1450的否定退出)，那么项目中的所有属性的值可以包括在扫描请求的结果集合中(如1470)。如果项目的属性值不满足指定筛选准则(示为1440的否定退出)，那么项目(即，其属性值)可以不包括在扫描请求的结果集合中。如果要处理更多项目(即，对指定筛选准则扫描和/或评估更多项目)且仍不满足扫描限制(例如，对可扫描或可响应于单个扫描请求而返回结果的项目数的预定限制)(示为1480的肯定退出)，那么可以对表格中的额外项目重复示为1440、1450、1460、1470和/或1480的操作直到没有更多项目要检查为止或直到达到这种扫描限制为止。这在图14中由从1480到1440的反馈加以示出。如图14中示出，一旦处理了表格中的所有项目或满足了响应于单个扫描请求而扫描和/或返回的项目数的预定限制(示为1480的否定退出)，所述方法就可以包括返回对请求器的响应(如1490)。如1490中所示且下文更详细地描述，在一些情况下，响应于单个scan请求而返回到请求器的结果可以仅包括满足指定准则的项目和/或属性值的部分。如果所述请求未指定任何筛选准则(示为1420的否定退出)，但是所述请求指定要返回值的一个或多个属性(示为1425的肯定退出)，那么结果集合可以包括表格中的所有项目的指定属性的值。换句话说，在这种情况下，这个扫描操作的完整的结果集合将包括表格中的所有项目的指定属性的值。然而，应注意，在一些实施方案中，响应于单个扫描请求可能不会返回(或甚至不一定找到)所有这些结果(例如，如果对响应于单个扫描请求而扫描和/或返回的项目数的预定限制已被指定用于所述请求或由全系统或客户端专用参数指定)。例如，表格中的第一项目的指定属性的值可以包括在结果集合中(如1435)，且如果有其它项目要处理且仍未达到扫描限制(示为1455的肯定退出)，那么一个或多个其它项目的指定属性可以包括在结果集合中。这在图14中由从1455到1425的反馈加以示出。一旦将所有项目的指定属性添加到结果集合或达到扫描限制(示为1455的否定退出)，那么可以将包括结果集合的至少一部分的响应返回到请求器(如1490)。类似地，如果所述请求未指定任何筛选准则(示为1420的否定退出)且所述请求未指定要返回值的任何属性(示为1425的否定退出)，那么结果集合可以包括表格中的所有项目的所有属性的值。换句话说，在这种情况下，这个扫描操作的完整的结果集合将包括表格中的所有项目的所有属性的值。例如，表格中的第一项目的所有属性的值可以包括在结果集合中(如1445)，且如果有其它项目要处理且仍未达到扫描限制(示为1455的肯定退出)，那么一个或多个其它项目的所有属性可以包括在结果集合中。这再次在图14中由从1455到1425的反馈加以示出。在这种情况下，一旦将所有项目的所有属性添加到结果集合或达到扫描限制(示为1455的否定退出)，那么可以将包括结果集合的至少一部分的响应返回到请求器(如1490)。如这个实例中示出，在一些实施方案中，响应于单个扫描请求可能不会返回(或甚至不一定找到)扫描操作的所有结果。上述scanapi和queryapi的使用可以通过下列实例(即，通过下文的伪代码)来进一步示出。在第一实例中，请求扫描表格，且所述请求指定要返回扫描项目的id值。在第二实例中，请求扫描表格并筛选结果以返回具有小于10的主键id值的所有项目。如上文提及，如果在找到、收集和返回请求的完整结果之前满足了响应于单个scan或query请求而扫描和/或返回的项目数的预定限制，那么可以提前终止操作且响应可以仅包括在达到预定限制之前检索的项目和/或属性值。在一些实施方案中，响应可以包括可用作可以被发出来继续扫描或查询表格并根据原始scan或query请求的参数返回额外项目和/或属性的后续scan或query请求的输入的信息。例如，响应可以包括lastevaluatedkey参数值或另一延续令牌，其然后可以被包括作为后续scan或query请求的对应输入参数值。在一些情况下，可能需要按次序执行两个或更多个后续scan或query请求以为扫描或查询操作找到和/或收集并返回完整的结果集合。图15示出根据一个实施方案的用于执行指定了扫描或响应限制的查询或扫描操作的方法。如1510处示出，在这个实例中，所述方法包括接收针对非关系数据库中的表格(例如，由数据存储服务代表一个或多个存储服务客户端维护的表格)中的一个或多个项目的查询或扫描请求。如这个实例中示出，所述请求可以取决于指定请求参数(例如，查询条件、散列键属性值、范围键条件、扫描条件等)而针对表格的给定分区(如1515)。如果由所述请求评估的项目满足所述请求的条件或参数，那么所述项目的一个或多个属性(例如，所有属性的值或所述请求中指定的任何属性的值)可以包括在所述请求的结果集合中(如1520)。如果不满足所述请求的扫描或响应限制(示为1525的否定退出)且如果分区中存在满足所述请求的条件或参数的更多项目(示为1530的肯定退出)，那么可以将满足所述请求条件或参数的另一项目(如果存在)的一个或多个属性值添加到结果集合。这在图15中由从1530到1520的反馈加以示出。如果不满足所述请求的扫描或响应限制(示为1525的否定退出)，但是当前检查的分区中不存在满足所述请求的条件或参数的更多项目(示为1530的否定退出)且有更多分区要查询或扫描(示为1535的肯定退出)，那么所述方法可以包括使所述请求针对另一分区以继续扫描或查询操作。这在图15中由从1535到1515的反馈加以示出。在这个实例中，所述方法可以包括一次或多次重复1515至1535中示出的操作、将满足所述请求条件或参数的其它项目(如果有)的一个或多个属性值添加到结果集合。这在图15中由从1530到1520的反馈加以示出。如果扫描或查询操作在达到所述请求的扫描或响应限制之前完成(示为1535的否定退出)，那么所述方法可以包括将包括完整的结果集合和成功地完成扫描或查询操作的指示的响应返回到请求器(如1540)。在某个时刻，如果达到所述请求的扫描或响应限制(示为1525的肯定退出)，那么所述方法可以包括提前终止扫描或查询操作(即，在找到和/或收集完整的结果集合之前)和将包括部分结果(在达到扫描或响应限制之前收集在结果集合中的结果)和延续令牌(诸如lastevaluatedkey参数值)的响应返回到请求器。这在图15中于1545处加以示出。如果仍有更多项目要检查(示为1550的肯定退出)，那么可以开始后续查询或扫描操作(包括延续令牌作为其输入参数之一)。这个后续查询或扫描操作将在终止先前操作的点处开始扫描或查询表格(如1560中所示)。如果在达到限制并终止操作之后没有更多项目要检查(示为1550的否定退出)，那么可以完成扫描或查询操作(如1570)。上文已描述可以由本文中的数据存储系统中支持的api中的各种api返回的错误指示中的一些。下文的表格9中列出其它错误指示。表格9-错误清单注意在一些实施方案中，由服务支持的api中的任何一个可以返回下列错误指示，而这些api中的特定api可以返回其它错误指示。●invalidpurametervalue●missingparametervalue●internalfailure●serviceunavailable在一些实施方案中，本文中描述为用于代表数据存储服务客户端维护并管理表格(包括本文中描述的元数据表格中的任何一个)的元数据中的任何一个或所有可以存储在与存储客户端和/或用户表格的存储装置相同的可扩展数据存储装置(例如，相同非关系数据库)中。在此类实施方案中，系统可以包括或采用一个或多个自举机制以辅助初始化数据存储服务(和/或实施数据存储服务的底层系统)，本文中描述了其中的一些。图16示出根据一个实施方案的用于这个系统的数据模型的一部分。在这个实例中，各种计算节点(在数据模型中简单地表示为“节点1610”)可以存储用户数据(例如，存储在代表用户维护的表格中)和/或系统数据，包括由数据存储服务使用的元数据(诸如上文描述的元数据)。因此，数据模型的每个节点1610可以包括节点类型(示为节点类型1615)的指示符。例如，在一个实施方案中，每个节点可以被指定为“存储节点”、“请求路由器”、“自动管理”节点或“分段”节点。在一些实施方案中，“存储节点”可以将用户数据存储在由数据存储服务维护的一个或多个表格中，但是元数据(例如，存储在tables表格、订户表格、分区表格或节点表格中的一个或多个中的数据)可以托管在其它类型的节点(例如，“自动管理”节点和/或“分段”节点)上。在其它实施方案中，这种元数据可以存储在一个或多个“存储节点”上，其中的一些也可以存储用户数据。如图16中示出，每个节点1610也可以包括节点的识别符(示为node-id1620)和一个或多个其它元素(示为1630)。如图16中示出，关于每个副本的信息可以在数据模型中被表示为副本1640。数据模型中的每个副本1640可以包括上面托管副本的节点的识别符(再次示为node-id1620)和指示包括在所述副本中的分区的一个或多个分区识别符(示为partition-id1635)。在这个实例中，每个分区可以在数据模型中被表示为分区1650且可以包括其partition-id1655。如图16中由各种一对多映射示出，每个节点可以托管多个副本，且每个分区可以包括在多个副本中。在一些实施方案中，本文中描述的系统可以支持“完全无共享”类型架构中的用户表格的无缝扩展。例如，在一些实施方案中，每个分区可以被实施为完全独立并行计算单元。在此类实施方案中，系统可以不提供跨分区的分布式协作或支持批量“放置(put)”操作和/或多语义事务。在一些实施方案中，只要工作量分布跨分区充分展开，分区数量的增加就可以造成服务请求的可用表格大小较大和/或吞吐量容量增加。如本文中所述，在一些实施方案中，现场再分区(无论是否以编程方式/自动或显式起始)可以用来适应工作量变化。换句话说，在一些实施方案中，当继续接收并处理针对受影响的分区的服务请求(即，未使源分区离线)时可以执行再分区(包括分区移动、分区划分和其它再分区操作)。在不同实施方案中，数据存储服务(和/或底层系统)可以支持各种服务供应和/或吞吐量模型。例如，在一些实施方案中，服务可以支持既定吞吐量供应和/或尽力而为服务供应。在一些实施方案中，存储服务客户端(例如，访问服务的客户端应用、用户或订户)可以根据各种商业模型、订购类型和/或支付模型在由服务供应的多个吞吐量选项之间指定优选。例如，在一些实施方案中，客户端/用户可以通过创建特定表格的请求的参数指示所述表格的优选吞吐量模型。在其它实施方案中，客户端/用户可以为由数据存储服务代表客户端/用户创建并维护的所有表格指定默认吞吐量模型。通过均支持既定吞吐量模型和尽力而为吞吐量模型(不保证吞吐量)两者，系统可以允许客户端/用户根据其要求和/或负担来平衡性能和成本。提供既定吞吐量供应的数据存储服务(和底层系统)可以被配置来响应于针对代表客户端/用户维护的表格的通信量而为所述表格的创建、扩大和管理预分配容量和/或资源，且不会忽略上面维护表格的存储节点的资源和/或容量。在一些实施方案中，在既定吞吐量模型下由服务(和底层系统)维护的表格可以维护在更快(且通常更昂贵)的存储器(诸如高性能介质(例如，快闪存储器或固态驱动器或ssd介质))中，以在为来自客户端/用户的请求服务时提供极低等待时间。例如，系统可以将快速/本地存储器的高比率提供到主(例如，磁盘)存储器以维护所述表格(和其各个分区)(且使快速/本地存储器的高比率专用于主(例如，磁盘)存储器以维护所述表格(和其各个分区))。虽然在既定吞吐量模型下分配到给定表格的存储器在一些情况下可能未充分利用(至少某些时刻)，但是客户端/用户可以估价由既定吞吐量模型提供的可预测性能超过专用多于所述表格中可能总是需要的资源的额外(且在一些情况下浪费)成本。注意在各种实施方案中，可以就服务请求将表格作为目标时所作出的工作来指定用于给定表格(或客户端/用户)的既定吞吐量水平。例如，对表格进行的读取访问可能仅需要一次i/o访问(例如，读取表格的数据文件)，而对表格进行的写入访问(例如，添加、删除或修改表格中的项目或项目属性的访问)可能需要至少两次i/o访问(例如，记录写入访问且然后执行访问)。此外，如本文中所述，一些个别服务请求可以读取和/或写入表格中的多个项目和/或项目属性。因此，可以就规格化逻辑工作单元在时间上的测量(诸如就“每秒钟的逻辑服务请求单元”)指定既定吞吐量水平，而非就每秒钟的i/o操作次数(iops)或每秒钟的服务请求次数(即，api调用)指定既定吞吐量。在一个实例中，造成读取访问将表格中的单个项目作为目标的服务请求可以被认为需要(或消耗)一个逻辑服务请求单元，而造成写入访问将表格中的单个项目作为目标的服务请求可以被认为需要(或消耗)两个或三个逻辑服务请求单元。在另一实例中，可以为读取请求和写入请求指定不同的吞吐量水平，或可以基于由读取请求和写入请求访问的项目的大小来使由所述请求消耗的逻辑服务请求单元规格化。一般来说，可以就逻辑服务请求单元使由包括多个读取和/或写入访问的服务请求(例如，可以返回从0至1mb数据的任何大小数据的查询或扫描请求)作出的工作模型化，这可以取决于为所述请求服务所需要的逻辑工作单元的数量和/或由所述请求中的每个访问的一个或多个项目的大小。在各种实施方案中，当为所述请求服务时实际执行的物理i/o操作(例如，存储器访问)的次数可以是固定的或变化为所述请求服务时所需要(或消耗)的逻辑服务请求单元的数量的倍数。例如，在一些实施方案中，当为给定请求服务时执行的物理i/o操作次数的数量级可以是为所述请求服务时所需要(或消耗)的逻辑服务请求单元的数量的两倍。在一些实施方案中，在既定吞吐量模型下接收服务的客户端/用户可以积极主动地请求和/或购买额外容量或资源，期望增加表格大小和/或服务请求通信量。例如，客户端/用户可以(例如，在创建表格的服务请求中)为针对表格的通信量指定每秒钟10,000个逻辑服务请求单元的既定吞吐量水平。作为响应，数据存储服务(和底层系统)可以自动地为表格创建20个分区，且可以保留足够的资源和/或容量以支持20个分区中的每个针对每秒钟500个逻辑服务请求单元。在一些实施方案中，这可以转化为对物理存储器(例如，磁盘)进行数量级大约为1000次的i/o操作。在系统被配置来提供最初请求的既定吞吐量水平之后，客户端/用户可以请求临时或永久增加或降低既定吞吐量水平，且作为响应，系统可以被配置来自动地将资源/容量添加到保留用于表格的资源/容量或从保留用于表格的资源/容量中移除资源/容量以修改保留的资源/容量的量，使得其与所请求的修改相当。在一些实施方案中，提供既定吞吐量模型的系统可以允许选用突发以支持通信量在既定吞吐量水平以外短期增加或上升。例如，系统可以被配置来自动地接受额外逻辑服务请求单元和为额外逻辑服务请求单元服务直到预定突发允许水平为止(在此之后，可以接受或可以不接受额外逻辑服务请求单元和为额外逻辑服务请求单元服务)，且可以为表格保留足够的资源以能够处理等于既定吞吐量水平加上突发允许水平的通信量。在其它实施方案中，系统可以仅适当地接受额外逻辑服务请求单元和为额外逻辑服务请求单元服务(例如，如果资源和容量可用)，但是并不对为所述额外逻辑服务请求单元服务做任何保证。在其它实施方案中，系统可以严格地限制在对应于既定吞吐量水平的量下接受和服务的逻辑服务请求单元，在此之后可以抑制额外服务请求。在一个实例中，客户端/用户可以在需求按计划或预期临时突发或上升(例如，由于出售、促销、宣传、新品发布或可以引发针对表格或其分区的活动增加的其它事件)之前或响应于观察到需求逐渐逼近当前既定吞吐量水平而请求增加表格的既定吞吐量水平。在另一实例中，在准备并观察到给定表格的需求临时增加时，客户端/用户可以提交使既定吞吐量水平恢复到其初始水平或与正在按预期发展的需求相当的新水平(例如，表格的“新标准”)的请求。在一些实施方案中，数据存储服务(和底层系统)可以允许客户端/用户在需求下降之后(无论是否按计划)“重新协商”表格的既定吞吐量水平，这可以允许客户端/用户减小与使多于随后将需要的资源/容量的资源/容量的量反向相关联的成本。在一些实施方案中，数据存储服务(和底层系统)可以允许客户端/用户请求在期望较高性能(即，较低等待时间)的高需求的初始周期之后在尽力而为吞吐量模型下而非既定吞吐量模型下管理给定表格。在此类实施方案中，可以(例如，基于客户端/用户估计的需求、历史数据或全系统、账号专用或客户端专用默认值)解除分配/不保留分配给或保留用于表格的资源/容量的部分，且可以适当地处理将所述表格作为目标的随后接收到的服务请求(在资源/容量可用时)。提供尽力而为吞吐量供应的数据存储服务(和底层系统)可以被配置来在更多传统的旋转介质(例如，磁盘介质)上运行，这可以造成存储成本较低但等待时间较高。当在尽力而为吞吐量模型下管理表格时，系统可以被配置来自动对通信量或数据存储量的增加作出响应(即，不加重客户端/用户的管理负担或不需要其介入)，且可以抑制至少一些服务请求直到实行努力尝试处理所述增加为止。例如，在一些实施方案中，系统可以被配置来在响应于工作量变化而添加分区和/或响应于通信量和/或数据量的增加而再分区由服务代表存储服务客户端(例如，用户、订户或客户端应用)管理的数据时抑制传入服务请求的至少一部分。虽然尽力而为吞吐量模型的成本对于客户端/用户来说可能较低，但是其无法与快速变化的工作量同步。换句话说，在针对尽力而为吞吐量模型下管理的给定表格的工作量可快速改变的情形下，(与将工作量未超过既定吞吐量水平或工作量的变化可预测且在需求增加之前通过修改既定吞吐量水平来积极主动地处理的既定吞吐量模型下管理的表格作为目标的应用的性能相比)将给定表格作为目标的应用的总性能受损。图17中的流程图示出用于根据指定吞吐量模型代表数据存储服务客户端(例如，用户、订户或客户端应用)创建并管理表格的方法的一个实施方案。如1710处示出，在这个实例中，所述方法可以包括实施数据存储服务的系统的组件接收在非关系数据库中创建表格(例如，代表数据存储服务的客户端/用户维护的表格)的服务请求。在一些实施方案中，客户端/用户可以对服务(或底层数据存储装置)提交创建表格的服务请求，所述表格符合包括用于指定当为针对表格的请求服务时使用的吞吐量模型(例如，尽力而为吞吐量模型或既定吞吐量模型)的参数的api。在此类实施方案中，请求也可以包括寻求承诺的所请求吞吐量水平的指示。在一些实施方案中，数据存储服务(和底层系统)可以支持对当代表客户端/用户创建新表格时使用的吞吐量模型使用全系统、账号专用或客户端专用默认值。在一些这样的实施方案中，创建表格的请求可以不包括吞吐量模型优选的指示，但是可以包括寻求承诺的所请求吞吐量水平的指示。如果客户端/用户指定了既定吞吐量模型的优选(示为1715的肯定退出)，那么所述方法可以包括系统预分配足够的容量和/或资源以支持针对这个表格和/或代表所述用户维护的任何其它表格的通信量的所请求既定吞吐量水平(如1730)。例如，如果客户端/用户是已支付接收特定吞吐量承诺的特权的订户，那么系统可以预分配足够的资源和/或容量以满足所述承诺。注意在一些实施方案中，与分配给在尽力而为吞吐量模型下管理的表格的存储器相比，分配给在既定吞吐量模型下管理的表格的存储器可以包括更快速(且更昂贵)的存储器。如果客户端/用户随后请求增加吞吐量的承诺或请求减小既定吞吐量水平(如1750)，那么系统可以被配置来给所述表格分配或解除分配容量和/或资源以与对既定吞吐量水平作出的所请求修改相当(如1770)。例如，在一些实施方案中，客户端/用户可以能够支付吞吐量的临时或永久增加(因此修改所请求的既定吞吐量水平)，且因此系统可以被配置来(例如，响应于客户端/用户的账号信息的改变)再分配资源和/或容量。在一些实施方案中，可以由创建表格的客户端/用户或另一特权用户(即，被授权改变表格的配置的用户)根据包括用于配置和/或再配置由数据存储服务代表客户端/用户维护的表格的一个或多个参数的api作出这个请求。在一些实施方案中，在请求临时增加容量和/或资源之后，客户端/用户可以就容量和/或资源请求(并接收)降低支持水平。如果用户未指定既定吞吐量的优选(例如，如果表格创建请求中指定尽力而为模型或当代表客户端/用户创建新表格时使用的吞吐量模型的全系统、账号专用或客户端专用默认值指示当管理针对表格的请求时应应用尽力而为吞吐量模型)(示为1715的否定退出)，那么所述方法可以包括系统分配容量和/或资源以支持针对表格的通信量的初始量和/或分布(如1740)。例如，如果用户是未支付接收特定吞吐量承诺的特权的订户但是指示尽力而为吞吐量模型足够满足其要求的订户，那么系统可以基于尽力而为吞吐量模型分配初始量的资源和/或容量。在各种实施方案中，分配给新表格的资源和/或容量的初始量可以取决于这个和/或其它客户端/用户的服务请求的历史数量和/或模式、由客户端/用户预测的服务请求的数量或分布(在一些实施方案中，其可以指定于表格创建请求中)、最初分配给新创建的表格的资源和/或容量的全系统、账号专用或客户端专用默认值和/或其它因素。注意，在一些实施方案中，可以维护在尽力而为吞吐量模型下管理的表格的存储器可能比维护在尽力而为吞吐量模型下管理的表格的存储器更加便宜(且更缓慢)。如果系统检测到通信量和/或数据量增加(例如，如果通信量增加造成系统不能为所有请求服务或存储的数据量接近所分配容量)(示为1725的肯定退出)，那么系统可以被配置来抑制请求直到额外容量和/或资源可置于适当位置以支持通信量或数据量增加为止或除非额外容量和/或资源可置于适当位置以支持通信量或数据量增加，否则系统可被配置来抑制请求(如1740)。例如，响应于检测到针对一个或多个表格(或其分区)的通信量或表格中逼近表格(或其分区)的当前分配容量的数据量增加，那么系统可以被配置来自动地添加分区、移动分区或尝试以其它方式再分区表格和/或一个或多个其它表格中的数据以在增加通信量或数据量水平时为客户端/用户服务。类似地，如果系统检测到通信量和/或数据量降低(例如，维持一段时间)(示为1725的否定退出)，那么系统可以被配置来移除或解除分配表格的容量和/或资源使得专用于表格的容量和/或资源的量更加符合所观察到的需求(如1760)。例如，响应于检测到针对表格(或其一个或多个分区)的通信量(或保持充分低于可由当前分配的资源和容量支持的水平的通信量)或表格(或其一个或多个分区)中充分低于表格或其分区的当前分配的容量(且已持续至少预定时间段)的数据量降低，系统可以被配置来自动地移除一个或多个分区、将多个分区折叠成单个分区、对一个或多个分区解除存储器或吞吐量容量的分配或尝试以其它方式再分区表格中的数据以使分配给表格的资源和容量更好地匹配所观察到的需求。如图17中示出，虽然通信量和/或数据量保持在可使用最初分配的容量和/或资源以合理的性能服务的范围内(示为1725和1745的否定退出)，但是数据存储服务(和底层系统)可维持表格的初始容量和资源(如1780)。注意在各种实施方案中，可以按次序重复图17中示出的任何或所有操作以创建并随后维护由数据存储服务管理的表格，同时使表格保持有效。注意在一些实施方案中，可以由最初分配资源且随后响应于改变由客户端/用户给出的条件和/或请求而修改所述分配的自动管理实体执行以下各项中的任何一个或所有：检测到工作量或数据量的变化、抑制传入服务请求和/或修改分区数量和/或所分配、保留或可用于给定表格的资源/容量的量。如上文提及，在使用既定吞吐量模型管理表格的各种实施方案中，系统可以允许修改所述表格的既定吞吐量水平，例如其可以允许临时和/或永久改变既定吞吐量水平。图18是示出用于为针对特定表格的请求服务同时维持或修改既定吞吐量水平的方法的一个实施方案的流程图。如1810处示出，在这个实例中，数据存储服务(或底层数据存储装置)可以在既定吞吐量模型下代表客户端/用户管理表格。注意在一些实施方案中，与分配给在尽力而为吞吐量模型下管理的表格的存储器相比，分配用于在既定吞吐量模型下管理的表格的存储器可以包括更快速(且更昂贵的)存储器。在这个实例中，如果在某个时刻所观察到的需求(就当为将表格或其各个分区作为目标的请求服务时的吞吐量来说)超过既定吞吐量水平(示为1820的肯定退出)且如果系统支持吞吐量中的一定量的突发和/或上升(例如，直到预定突发允许水平为止)(示为1830的肯定退出)，那么所述方法可以包括系统为额外需求的至少一部分服务(为额外吞吐量服务直到预定突发允许为止)(如1840)。在这个实例中，假设为表格保留额外资源以满足既定吞吐量水平和预定突发允许水平。在其它实施方案中，可以仅适当地支持吞吐量中的突发或上升(例如，如果并非保留用于表格的资源和/或容量正好可用)。如图18中示出，如果所观察到的需求超过既定吞吐量水平(示为1820的肯定退出)，但是系统不支持吞吐量中的突发和/或上升(示为1830的否定退出)且没有存在足够多的可用资源来为额外需求的至少一部分服务(示为1835的否定退出)，那么所述方法可以包括系统抑制针对表格的服务请求以匹配既定吞吐量水平(如1845)。在一些实施方案中，如果需求超过既定吞吐量水平(示为1820的肯定退出)且系统不支持吞吐量中的突发和/或上升(示为1830的否定退出)，但是存在足够多的可用资源来为额外需求的至少一部分服务(示为1835的肯定退出)，那么所述方法可以包括系统为额外需求的至少一部分服务(如1840)。换句话说，在一些实施方案中，可以适当地但是不一定保证为任何额外需求(超过既定吞吐量水平的需求)服务。如上文提及，在一些实施方案中，为超过吞吐量水平的请求服务(无论是否通过用于允许突发/上升的策略或适当地)可以在用于提供既定吞吐量水平的费用以外对客户端/用户账号造成额外费用。如这个实例中示出，如果所观察到的需求没有超过既定吞吐量水平(示为1820的否定退出)，但是接收到指示增加既定吞吐量水平的请求的服务请求(如1850)，那么所述方法可以包括系统添加一个或多个分区和/或额外资源/容量以支持按请求增加既定吞吐量水平(如1855)。例如，如果客户端/用户希望临时或永久增加需求(就当为将表格作为目标的请求服务时的吞吐量来说)，那么在一些实施方案中客户端/用户可以积极主动地请求增加既定吞吐量水平使得系统将处理需求增加而不需要等待其对需求增加作出反应。在一些实施方案中，如果希望(或观察到)暂时地或响应于在增加需求的时段之后降低需求而增加需求，那么客户端/用户可以请求降低既定吞吐量水平(例如，降低到先前既定吞吐量水平或不同“新标准”既定吞吐量水平)。在这种情况下(1860处所示)，系统可以被配置来移除一个或多个分区、将多个分区折叠成单个分区、对一个或多个分区解除存储器或吞吐量容量的分配和/或尝试再分区表格中的数据以使分配给表格的资源和容量更好地匹配降低的既定吞吐量水平(如1865)。注意在一些实施方案中，如果客户端/用户希望针对表格(和/或其各个分区)的需求在表格有效的剩余时间内保持相对较低的水平，那么客户端/用户可以在降低既定吞吐量水平的请求中指示其不再需要或希望对表格的吞吐量水平作出任何承诺(或对应保证)。换句话说，所述请求可以指示既定吞吐量水平为零，这可以有效地指示当随后为针对表格的请求服务时使用尽力而为吞吐量模型而非既定吞吐量模型来管理表格的请求。这在图18中由1870的肯定退出和元件1880加以示出。注意在一些实施方案中，与维护在尽力而为吞吐量模型下管理的表格的存储器相比，维护在尽力而为吞吐量模型下管理的表格的存储器可能更加便宜(且更缓慢)。如果降低既定吞吐量水平的请求没有指示客户端/用户不再需要或希望对表格的吞吐量水平作出承诺(或对应保证)(示为1870的否定退出)，那么系统可以继续使用既定吞吐量模型(例如，根据当前既定吞吐量水平)来管理表格(如1875)。注意在各种实施方案中，可以按次序重复图18中示出的任何或所有操作以创建并随后维护由数据存储服务管理的表格，同时使表格保持有效。在各种实施方案中，可能存在可能需要将分区(或其副本)(例如)从一个机器复制到另一机器的情形。例如，如果特定分区存在三个副本(每个托管在不同物理或逻辑机器上)且机器之一出现故障，那么托管在所述机器上的副本可能需要由另一机器上的分区的新副本替换。在另一实例中，如果托管一个或多个表格的多个分区的特定机器经历繁重的通信量，那么可以尝试(使用复制操作)将被频繁访问的分区之一移动到经历较少通信量的机器以更加均匀地分布系统工作量并改善性能。在一些实施方案中，本文中描述的数据存储服务(和/或底层系统)可以使用将整个分区从一个机器复制到另一机器而非逐行复制分区数据的快照(如在传统逻辑数据库分区复制操作中)的物理复制机制(例如，物理文件系统机制)执行分区移动。虽然分区已被复制，但是可以记录将分区作为目标的写入操作。在复制操作期间，可以由追赶程序以周期性间隔(例如，在一系列核对点)对分区施加任何记录写入操作。一旦将整个分区复制到目的地机器，就可以由最终追赶程序对目的地分区执行任何剩余的记录写入操作(即，自从最后核对点之后执行的任何写入操作)。因此，与传统分区移动机制不同的是，目的地分区中的数据在完成分区移动之后可以一致。图19中的流程图示出用于当由数据存储服务代表存储服务客户端维护的表格的分区“有效”时移动(或复制)所述分区的副本的方法的一个实施方案。在这个实例中，所述方法可以包括实施数据存储服务的系统的组件接收移动分区的副本的请求(如1910)。例如，系统可以包括从客户端/用户或系统管理员接收移动副本的显式请求，或可以响应于检测到异常(如下文更加详细地描述)而在系统中自动地生成这个请求。如1920处示出，响应于接收到移动分区的请求，系统可以被配置来在分区有效时(即，分区的一个或多个副本继续接受针对所述分区的请求并为所述请求服务时)创建新的副本(其可以被称作目的地副本)。在一些实施方案中，创建目的地副本可以包括选择上面将创建目的地副本的计算节点或存储装置、将存储器分配在用于目的地副本的计算节点或存储装置上、创建或更新与分区和/或目的地副本相关联的元数据和/或执行适用于创建目的地副本的其它功能。如这个实例中示出，所述方法可以包括在分区的副本有效时系统使用文件复制机制或另一物理复制机制将被移动的副本复制到目的地副本(如1930)。换句话说，可以使用复制副本数据的物理位置的操作而非使用逻辑复制操作(例如，基于逐行读取并复制表格数据的操作)来将副本复制到新的目的地副本。如1940处示出，在执行物理复制操作之后，所述方法可以包括系统执行追赶操作以调解副本数据的任何变化，所述变化是在复制操作期间作出但是仍未在新的副本中反映出来。下文更加详细地描述这个追赶操作。一旦创建并填满目的地副本，所述方法就可以包括引导通信量使其远离所复制的副本并朝向新的目标副本(如1950)。在一些实施方案中，用于数据存储服务的底层数据存储装置(例如，非关系数据库)的存储引擎可以将副本数据存储在数据库文件中，且每个副本(和数据库文件)可以与恢复日志相关联。在此类实施方案中，当接收到修改副本数据的服务请求时，可以在将所述服务请求应用于副本之前将所述服务请求记录到恢复日志中。在节点故障或系统崩溃的情况下，可以将记录到恢复日志中的变化再应用于副本数据的先前快照或核对点以恢复副本的内容。如上文提及，在一些实施方案中，数据存储服务(和其底层系统)可以支持采用物理复制机制的副本移动。在一些这样的实施方案中，物理复制机制可以采用这种日志，其可以确保移动到新的目的地的副本数据一致。图20示出用于使用如上所述的物理复制机制移动副本的方法的一个实施方案。在这个实例中，所述方法开始将副本数据从其当前物理存储位置复制到对应物理目的地位置(如2010)。在一些实施方案中，物理复制操作可以包括通过网络将页面从一个物理存储装置(例如，磁盘存储装置)复制到目的地存储装置。如2020处示出，如上所述，在物理复制操作期间，可以在将被移动的副本作为目标的写入操作应用于被复制的副本之前记录所述写入操作。在各种实施方案中，可以给每个记录的写入操作(或写入操作组)指派日志序列号。在一些实施方案中，可以以周期性核对点间隔将记录的变化应用于被复制的副本。在图20中示出的实例中，当经过预定核对点间隔时(示为2030的肯定退出)，可以将自从最后核对点以后记录的所有修改(例如，写入操作)应用于被复制的副本。因为在复制副本时应用这些更新，所以这些修改中的一些(例如，在将副本数据的给定部分复制到目的地之前应用于数据的所述部分的修改)由于复制操作将会在目的地副本中反映出来。在复制操作之后目的地副本中不一定反映其它修改(例如，在将副本数据的给定部分复制到目的地之后应用于数据的所述部分的修改)。如图20中示出，所述方法可以包括当其未完成时(示为2050的否定退出、元件2060和到2020的反馈)继续将副本数据从当前物理存储位置复制到对应物理目的地位置。所述方法可以包括每当经过核对点间隔时(示为2030的肯定退出)时继续记录写入操作(如2020)并将记录的写入操作应用于被复制的副本(如2040)。一旦完成物理复制操作(示为2050的肯定退出)，所述方法就可以包括执行追赶操作，其中目的地副本中尚未反映出来的任何记录的写入操作应用于目的地副本(如2070)。此后，可以将对副本的访问引导远离源副本并引导朝向新的目的地副本。例如，可以将副本作为目标的任何写入操作记录到目的地副本的恢复日志中，且随后将所述写入操作应用于目的地副本(例如，在下一个周期性核对点处)。在一些实施方案中，在副本移动到其新的目的地之后，可以复制(或直接使用)记录源副本的修改的日志以用于目的地副本的恢复日志。在一些实施方案中，可以在分区划分操作中采用上述分区移动程序。例如，因为分区较大(例如，当其变得太大而不适合一个机器时和/或为了使分区大小保持足够小以在机器出现故障时(使用大量并行处理)快速重建托管在单个机器上的分区)，所以可以划分分区。当分区变得太“热”时(即，当与其它分区相比其经历的通信量远大于通信量的平均量时)也可以划分分区。例如，如果给定分区的工作量突然和/或大幅改变，那么系统可以被配置来快速对改变作出反应。在一些实施方案中，对于应用和客户端/用户来说，本文中描述的分区划分程序可能是透明的，这可以允许自动地(即，不需要客户端/用户介入或开始)扩展数据存储服务。注意在一些实施方案中，因为系统可以利用上述文件复制程序来进行副本移动，所以在集群中移动分区的副本可能比划分分区更快。另一方面，划分分区可能需要在逻辑上将一个底层数据结构(例如，一个平衡树(b-tree))中的分区数据分成两个这样的数据结构(例如，两个b-tree)，一般来说这比上述移动整个副本的效率更低。因此，在一些实施方案中，分区划分程序可以包括创建分区的额外副本，且此后仅管理每个分区上的分区数据的一半。例如，如果要划分的给定分区存在三个副本，那么分区划分程序可以包括(例如，使用上述分区移动程序)创建整个分区的三个额外副本。可以将这些所得的六个副本划分成每组均具有三个分区的两个组，其中每个组可以负责使用将责任划分在多组副本之间的操作来处理针对原始分区数据的一半的服务请求。例如，在划分责任的操作之后，针对原始分区的指定部分中的数据的服务请求可以被给定副本接受且可以由给定副本服务，而将原始分区的剩余数据作为目标的服务请求则可能被所述副本拒绝。在一些实施方案中，可以最终移除不由给定副本负责的分区数据(例如，使得分配到其不再支持的数据副本的存储器可以随后用来将新项目存储在副本中)，或存储分区数据的存储器可以被系统收回(例如，使得分配到其不再支持的数据副本的存储器可以随后由另一分区使用)。移除不被支持的数据或收回存储器可以通过后台任务来执行且不影响数据存储系统的性能，且对于客户端/用户来说可以是透明的。在一些实施方案中，可以由分区id识别每个分区，分区id可以是在创建分区时指派的唯一编号(例如，guid)。分区也可以具有每当(例如，响应于添加或移除副本，但是不一定响应于主要的故障转移)分区经历再配置时递增的版本编号。当划分分区时，可以创建两个新的分区，其中的每个可以具有各自新的分区id，且可以不再使用原始分区id。在一些实施方案中，可以响应于条件改变而由系统使用划分工具或程序来划分分区。例如，自动管理实体的计划任务可以监控分区大小和“热量”(例如，针对每个分区的通信量)，且可以应用确定何时使用划分工具/程序来执行划分的策略。在一些实施方案中，划分工具和自动管理实体可以通过采用封锁管理程序来避免同时尝试进行两次划分。在一些实施方案中，监控组件可以提供满足划分工具/程序的划分准则的分区清单。所述准则可以基于分区大小和热量，其中热量可以由内部测量的度量(诸如iops)、外部测量的度量(诸如等待时间)和/或其它因素追踪。在一些实施方案中，划分工具/程序可以从监控组件接收划分分区的请求，所述请求包括要划分的分区的分区id和版本编号和新分区/副本的位置的机器清单(例如，被认为少量加载的相同集群或存储仓(silo)中的机器)。包括版本编号作为划分工具/程序的输入可以确保划分工具/程序不会尝试划分自从上一次针对划分准则评估分区以来已经历一次或多次再配置的分区，因为划分工具/程序可以在版本编号不匹配时拒绝所述请求。图21中的流程图示出用于划分由数据存储服务代表数据存储客户端维护的表格的分区的方法的一个实施方案。在这个实例中，所述方法可以包括实施数据存储服务的系统的组件接收划分分区的请求(如2110)。例如，系统可以从客户端/用户或系统管理员接收划分分区的显式请求，或可以响应于检测到异常(如下文更详细地描述)而在系统中自动生成这样的请求。如上所述，在一些实施方案中，划分分区可以涉及创建分区的额外副本，且然后将总数个副本中的一半指定为原始分区的各自部分的管理程序。因此，如2120处示出，响应于接收到划分分区的请求，系统可以被配置来在源分区的原始副本中的一个或多个有效时(即，这些副本中的一个或多个继续接受针对分区的请求并为所述请求服务时)开始创建所述一个或多个新的分区(其可以被称作目的地分区)。如2130处示出，所述方法可以包括使用物理复制机制(诸如上文描述的机制)将源分区复制到目的地副本。例如，在一些实施方案中，系统可以被配置来使用文件复制机制将表格分区数据从分区的原始副本之一复制到目的地分区中的一个或多个。所述方法也可以包括(一旦新的副本被填满)(例如，通过执行如上所述的追赶操作)更新新的副本。如这个实例中示出，所述方法可以包括传播特殊的“写入”命令(即，“划分”命令)以划分分区并指定每个副本处理划分分区的一个部分(如2140)。在一些实施方案中，当划分分区副本的命令传播到上面托管六个副本的存储节点时，系统可以简单地使源副本脱离使用。划分命令可以命令通过指定由复制操作产生的副本中的每个副本属于单词的第一半或单词的第二半来将所述副本划分为两半，因此形成两个新的副本组。注意，在一些实施方案中，特殊的“划分”命令可以不需要任何特殊的持续性。如这个实例中示出，一旦传播了“划分”命令并建立了两个新的副本组，所述方法就可以包括新的副本组中的每个选择新的主副本(如2150)。随后，分区的所得副本中的一半(例如，原始副本或分区的所得副本的另一子集)可以处理针对原始分区的一个部分的请求，且其它副本(例如，目的地副本或分区的所得副本的另一子集)可以处理针对原始分区的剩余部分的请求(如2160)。例如，副本中的每个可以拒绝对现在其新的较小范围(即，其不再负责的数据的一半)以外的数据的请求，且可以返回副本(或上面托管副本的节点)不再托管所述数据的指示。如上所述，在一些实施方案中，系统可以被配置来对所得划分分区副本的未使用部分执行逻辑收回(如2170)。例如，由于接收到将新项目存储在分区中的请求，可以将这些新项目存储在表格中(在副本复制操作之后)拥有存储在原始分区中的项目但现在被管理为不同分区的部分(即，由划分创建的两个分区中的另一个)的位置中。在一些实施方案中，系统可以采用后台程序以在逻辑上释放所得分区副本中的每个内的空间，但是如果将更多项目(根据其散列键属性值和/或范围键属性值而指派到新的分区副本)添加到表格，那么随后可以消耗所述空间。在一些实施方案中，可以执行物理存储器收回操作，这可以将在划分之前先前分配到大的分区副本的存储器的部分返回到操作系统。在此类实施方案中，也可以执行消除分段操作。如上文提及，在一些实施方案中，可以响应于在实施数据存储服务的系统中检测到异常而自动地(例如，以编程方式)开始图19中示出且上文描述的分区移动程序。图22中的流程图示出用于响应于检测到异常而移动由数据存储服务代表存储服务客户端维护的表格的分区的方法的一个实施方案。如2210处示出，在这个实例中，所述方法可以包括系统的组件检测托管表格的分区的副本的物理计算节点或存储装置上的故障或错误。在一些实施方案中，如果托管在上面检测到错误或故障的节点上的分区副本是其副本组的主副本，那么所述方法可以包括为副本组选择新的主副本(如2220)。在这个实例中，所述方法可以包括系统在源分区副本有效时(即，分区的副本中的一个或多个继续接受针对分区的请求并为所述请求服务时)开始创建替换分区副本(如2230)。如这个实例中示出，所述方法可以包括使用物理复制机制将源分区副本复制到新创建的替换分区副本(如2240)，和执行追赶操作以调解分区数据中仍未在新创建的替换分区副本中反映出来的任何变化(如2250)。例如，可以使用复制分区数据的物理位置的操作而非使用逻辑复制操作(例如，基于逐行读取并复制表格数据的操作)来将源分区副本复制到替换分区副本。在各种实施方案中，(例如)取决于已检测到的错误的类型和/或严重性，错误机器上的分区副本可以用作源分区副本，或(工作机器上)相同分区的另一副本可以用作源分区副本。如上文提及，在一些实施方案中，可以响应于在实施数据存储服务的系统中检测到异常而自动地(例如，以编程方式)开始上文描述且图19和图20中示出的分区移动程序和图21中示出且上文描述的分区划分程序。例如，如果作为数据存储服务的基础的系统中的特定计算节点或存储装置上产生热点，那么系统可以被配置来划分和/或移动存储在所述计算节点或存储装置上的一个或多个分区副本。图23中的流程图示出用于响应于检测到热点而划分或移动由数据存储服务代表存储服务客户端维护的表格的分区的副本的方法的一个实施方案。如2310处示出，在这个实例中，所述方法可以包括系统的组件检测托管表格的分区的特定副本的物理计算节点或存储装置上的热点。换句话说，系统可以检测到与系统中的其它计算节点或存储装置相比，所述计算节点或存储装置正经历大量通信量。在一些情况下，这个繁重通信量中的所有或部分可能针对特定分区副本本身，而在其它情况下，繁重通信量可能针对托管在所述计算节点或存储装置上的其它分区副本、表格或应用。如这个实例中示出，响应于检测到热点，系统可以被配置来尝试移动和/或划分特定分区以(诸如)通过减小等待时间、增加系统的总吞吐量或以其它方式改善数据存储服务的性能来降低热点的影响。如果热点是由于将单个分区作为目标的通信量而产生(示为2315的肯定退出)，那么所述方法可以包括开始划分所述分区。在一些实施方案中，系统可以被配置来在源分区的原始副本中的一个或多个有效时(即，这些副本中的一个或多个继续接受针对分区的请求并为所述请求服务时)开始创建一个或多个新的分区(其可以被称作目的地分区)(如2320)。例如，系统可以被配置来在加载量小于上面检测到热点的计算节点或存储装置的计算节点或存储装置上创建一个或多个目的地副本。如2330处示出，所述方法可以包括使用(诸如上文描述的)物理复制机制将源分区副本复制到目的地副本。例如，在一些实施方案中，系统可以被配置来使用文件复制机制将表格分区数据从分区的原始副本(例如，托管在加载量多的计算节点或存储装置上的分区副本或托管在不同计算节点或存储装置上的特定分区的副本中的另一个副本)复制到目的地副本中的一个或多个。所述方法也可以包括(一旦新的副本被填满)(例如，通过执行如上所述的追赶操作)更新新的副本(如2340)。在这个实例中，所述方法可以包括传播特殊的“划分”命令以划分分区并指定每个副本处理划分分区的一个部分(如2360)。在传播“划分”命令之后，分区的所得副本(即，一个新的副本组)中的一半可以处理针对原始分区的一个部分的请求，且其它副本(即，第二新的副本组)可以处理针对原始分区的剩余部分的请求。如2380处示出，所述方法可以包括为新的副本组中的每个选择新的主副本(如2380)。如上所述，在一些实施方案中，系统可以被配置来对所得划分分区副本的未使用部分(未示出)执行逻辑收回。在此类实施方案中，由于接收到将新项目存储在分区中的请求，可以将这些新项目存储在表格中拥有存储在原始分区中的项目但现在被管理为不同分区的部分(即，由划分创建的两个新的副本组中的另一个)的位置中。如图23中示出，如果热点并非由于将单个分区作为目标的通信量而产生(例如，如果其是由于针对托管在计算节点或存储装置上的多个分区副本、表格或应用的通信量而产生)，那么所述方法可以包括开始移动分区副本之一以从高通信量节点中移除所述分区副本。这在图23中由2315的否定退出加以示出。在这种情况下，所述方法可以包括在被移动的副本是其副本组的主副本时为副本组选择新的主副本(如2330)。如这个实例中示出，所述方法可以包括当副本被移动的分区的一个或多个副本有效时在另一计算节点或存储装置上创建新的副本(如2350)。在一些实施方案中，可以使用(诸如本文中描述的)物理复制机制将被移动的分区副本复制到这个新的目的地副本，且可以在一旦复制完成时就使用追赶机制更新目的地副本(如2370)。一旦目的地副本随着更新而被填满，就可以从高通信量节点中移除被复制到新目的地的分区副本(如2390)。随后，针对所述分区的通信量可能针对另一节点(加载量较小的节点)上的目的地副本。注意，在一些实施方案中，响应于在实施数据存储服务的系统中的计算节点或存储装置上检测到热点，系统可以执行分区划分和一个或多个副本移动两者。例如，在划分经历繁重通信量的分区之后，也可以使用本文中描述的物理复制机制将划分分区中托管在热节点上的副本从热节点移动到新的托管节点。此外，如果由分区划分造成的新的副本组中的任何一个中的其它副本中的任何一个托管在热节点上，那么其也可以被移动到其它节点。注意在一些实施方案中，可以响应于检测到表格大小增加而应用类似于图23中示出的用于移动和/或划分分区的方法的方法。例如，随着将更多项目添加到给定表格，这种方法可以用来添加新的分区(和其对应副本)，且因此自动扩展表格。图24中的流程图示出用于代表一个或多个存储服务客户端维护并管理多个表格的方法的一个实施方案。如2410处示出，在这个实例中，所述方法可以包括当为来自一个或多个存储服务客户端的请求服务时在实施数据存储服务的系统中检测到异常。在一些实施方案中，系统可以被配置来诸如通过扩展表格、移动分区、划分分区和/或采取本文中未描述的其它动作自动地(例如，以编程方式)响应各种类型的异常的检测。例如，如果检测到故障或错误节点(例如，计算节点或存储装置)(如2420)，那么系统可以被配置来用新的节点替换故障或错误节点和/或将托管在故障或错误节点上的任何或所有分区复制到新的节点(如2425)。如先前提及，如果故障或错误节点托管分区副本(所述分区副本是其副本组的主副本)，那么系统也可以被配置来在将分区复制到新的节点之后选择新的主副本。如果检测到热点或表格大小增加(如2430)，那么系统可以被配置来(例如，在除了上面检测到热点的计算节点或存储装置以外的计算节点或存储装置上)添加一个或多个新的分区和对应副本且移动和/或划分新的分区或副本中的一个或多个中的、托管在加载量较多的计算节点或存储装置上的数据(如2435)。类似地，如果系统检测到由于通信量增加或如果数据量增加超过表格的目标容量而不满足或可能不满足尽力而为吞吐量目标(或另一用户优选)(如2440)，那么系统可以被配置来抑制传入服务请求同时尝试修正所述情形。此外，系统可以被配置来(例如，在除了上面检测到热点的计算节点或存储装置以外的计算节点或存储装置上)添加一个或多个新的分区和对应副本且移动和/或划分新的分区或副本中的一个或多个中的、托管在加载量较多的计算节点或存储装置上的数据(如2445)。类似地，如果(例如，由表格拥有人)明确地请求进行现场再分区(如2450)，那么所述系统可以被配置来相应地添加或移除一个或多个新的分区和对应副本，或移动和/或划分新的分区或副本中的一个或多个中的、托管在加载量较多的计算节点或存储装置上的数据(如2455)。如果检测到另一类型的异常(示为2420、2430、2440和2450的否定输出)且系统响应和/或返回所述异常的指示符(如2460)或一旦随着响应上述异常之一而开始系统(如2425、2435、2445或2455)，那么系统可以继续为传入请求服务(如2465)。在一些实施方案中，系统可以被配置来继续进行操作(例如，继续为传入服务请求服务)(如2465)直到检测到额外异常为止，或除非检测到额外异常，否则系统可以被配置来继续进行操作。这在图24中由从2470到2465的反馈加以示出。如果检测到任何额外异常(示为2470的肯定退出)，那么可以由系统按次序重复示为2420至2460的操作中的任何一个或所有以代表数据存储服务客户端维护并管理表格。这在图24中由从2470到2420的反馈加以示出。注意在一些实施方案中，图24中示出的操作中的任何一个或所有可以在数据存储服务进行操作时由后台任务积极主动(且自动地)执行，且不一定必须响应于接收到任何特定服务请求而执行。可就以下条款描述本公开的各种实施方案：1.一种系统，其包括：多个计算节点，其共同地实施数据存储服务，每个包括至少一个处理器和存储器；其中所述多个计算节点包括：前端模块，其提供网络服务接口(通过网络服务接口接收服务请求)且被配置来解析并调度服务请求以进行处理；管理组件，其被配置来分配系统中的资源、监控系统的状态和检测当为服务请求服务时系统中经历的异常；和多个存储节点，其共同地实施非关系数据存储装置；其中响应于所述前端模块接收到代表存储服务客户端创建表格的服务请求且其中所述服务请求指定表格名称和主键，通过主键分区并索引存储在表格中的项目：所述前端模块被配置来将所述服务请求调度到所述多个存储节点之一；响应于接收到所述服务请求，所述多个存储节点中的所述一个存储节点被配置来在非关系数据存储装置中创建可扩展表格，其中所述可扩展表格被配置来存储多个项目，多个项目中的每个包括主键的值，且其中所述可扩展表格不具有预定大小限制；且在创建所述可扩展表格之后，所述管理组件被配置来响应于在系统中检测到异常或响应于接收到存储、检索、修改或删除所述可扩展表格中的项目的一个或多个服务请求而以编程方式造成所述可扩展表格被调整大小或分区。2.根据条款1所述的系统，其中创建所述可扩展表格包括开始执行异步表格创建工作流程；且其中响应于接收到描述由数据存储服务维护的一个或多个表格的服务请求，所述非关系数据存储装置被配置来返回关于所述一个或多个表格的信息，其中关于所述一个或多个表格的所述信息包括指示是否由所述异步表格创建工作流程成功创建所述可扩展表格的信息。3.根据条款1所述的系统，其中响应于接收到将多个项目存储在所述可扩展表格中的一个或多个服务请求，所述管理组件被配置来：确定所述多个项目是否能存储在所述可扩展表格的单个分区中；且响应于确定所述多个项目不能存储在所述可扩展表格的单个分区中，执行所述以编程方式分区可扩展表格。4.根据条款1所述的系统，其中所述主键包括被指定为散列键属性的单个属性；且其中分区所述可扩展表格包括取决于所述可扩展表格中的项目的各自散列键属性值将所述项目分成两个或更多个分区。5.根据条款1所述的系统，其中创建表格的所述服务请求还包括一个或多个用户优选的指示，其中所述一个或多个用户优选包括优选服务请求吞吐量水平或请求保证的服务请求吞吐量水平；且其中所述管理组件被配置来响应于检测到不满足所述用户优选中的一个或多个而以编程方式造成所述可扩展表格被调整大小或分区。6.根据条款1所述的系统，其中以编程方式造成所述可扩展表格被分区是响应于所述前端模块接收到数量增加的请求而执行，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目。7.一种方法，其包括：由计算机执行：接收在非关系数据存储装置中创建表格的请求，其中所述请求指定所述表格的识别符和索引存储在所述表格中的项目的主键；且响应于所述接收：在所述非关系数据存储装置中创建可扩展表格，其中所述可扩展表格被配置来存储多个项目，多个项目的每个包括所述主键的值，且其中所述可扩展表格不具有预定大小限制；且响应于接收到访问所述可扩展表格的一个或多个请求而以编程方式执行调整所述可扩展表格的大小或分区所述可扩展表格中的至少一个。8.根据条款7所述的方法，其中访问可扩展表格的所述一个或多个请求包括存储、检索、修改或删除所述可扩展表格中的项目的一个或多个请求。9.根据条款7所述的方法，其中创建所述可扩展表格包括：搜集反映所述多个计算节点中的一个或多个的状态的信息；和取决于所搜集的信息确定将在一个或多个计算节点中的哪一个计算节点上创建所述可扩展表格。10.根据条款7所述的方法，其中创建所述可扩展表格包括开始执行异步表格创建工作流程；且其中所述方法还包括：接收描述维护在所述非关系数据存储装置中的一个或多个表格的请求；和响应于接收到描述一个或多个表格的所述请求，返回关于所述一个或多个表格的信息，其中关于所述一个或多个表格的所述信息包括指示是否由所述异步表格创建工作流程成功创建所述可扩展表格的信息。11.根据条款7所述的方法，其还包括：接收将多个项目存储在所述可扩展表格中的一个或多个请求；和响应于接收到所述一个或多个请求：确定所述多个项目是否能存储在所述可扩展表格的单个分区中；且响应于确定所述多个项目不能存储在所述可扩展表格的单个分区中，执行所述以编程方式分区所述可扩展表格。12.根据条款7所述的方法，其中所述主键包括被指定为散列键属性的单个属性；其中存储在所述可扩展表格中的项目中的每个包括所述散列键属性的各自值；且其中以编程方式分区所述可扩展表格包括取决于所述可扩展表格中的项目的各自散列键属性值的散列表将所述项目分成两个或更多个分区。13.根据条款7所述的方法，其中所述主键包括被指定为散列键属性的属性和被指定为范围键属性的另一属性；其中存储在所述可扩展表格中的项目中的每个包括所述散列键属性的各自值和所述范围键属性的各自值；其中所述范围键属性值唯一地识别所述可扩展表格中具有相同散列键属性值的所有项目中的特定项目，其中具有相同散列键的项目是根据项目各自范围键属性值来排序；且其中以编程方式分区所述可扩展表格包括取决于可扩展表格中具有相同散列键属性值的项目的各自范围键属性值将所述项目分成两个或更多个分区。14.根据条款7所述的方法，其中所述以编程方式分区所述可扩展表格包括将所述可扩展表格分成两个或更多个分区和将所述两个或更多个分区中的每个存储在所述多个计算节点中的不同计算节点上。15.根据条款7所述的方法，其中所述以编程方式分区所述可扩展表格包括当所述可扩展表格的分区的一个或多个副本继续接受并处理请求时移动或划分所述分区。16.根据条款7所述的方法，其中所述以编程方式分区所述可扩展表格是响应于接收到数量增加的请求而执行，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目；或响应于接收到数量减少的请求而执行，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目。17.根据条款7所述的方法，其中创建表格的所述请求还包括一个或多个用户优选的指示，其中所述一个或多个用户优选包括优选服务请求吞吐量水平或请求保证的服务请求吞吐量水平；且其中所述以编程方式执行调整所述可扩展表格的大小或分区所述可扩展表格中的至少一个是响应于检测到不满足所述用户优选中的一个或多个而执行。18.根据条款7所述的方法，其还包括：接收到从所述可扩展表格检索一个或多个项目的请求，其中所述请求包括优选一致性模型的指示；和响应于接收到检索所述一个或多个项目的所述请求，以与优选一致性模型一致的方式返回所述一个或多个项目。19.根据条款7所述的方法，其中所述创建包括：生成与所述可扩展表格相关联的元数据；和将另一可扩展表格中的元数据存储在所述非关系数据存储装置中。20.一种非临时计算机可读存储介质，其存储当在一个或多个计算机上执行时造成所述一个或多个计算机执行以下各项的程序指令：接收代表存储服务客户端创建表格的服务请求，其中所述服务请求指定所述表格的识别符和索引存储在所述表格中的项目的主键；且响应于所述接收：在所述非关系数据存储装置中创建可扩展表格，其中所述可扩展表格被配置来存储多个项目，多个项目的每个包括所述主键的值，且其中所述可扩展表格不具有预定大小限制；且响应于接收到将多个项目存储在所述可扩展表格中的一个或多个服务请求：确定所述多个项目是否能存储在所述可扩展表格的单个分区内；且响应于确定所述多个项目不能存储在所述可扩展表格的单个分区内，分区所述可扩展表格。21.根据条款20所述的存储介质，其中当在所述一个或多个计算机上执行所述程序指令时，所述程序指令还造成所述一个或多个计算机执行：在分区所述可扩展表格之后，响应于接收到存储、检索、修改或删除所述可扩展表格中的项目的一个或多个服务请求而执行调整所述可扩展表格的大小或再分区所述可扩展表格中的至少一个。22.根据条款21所述的存储介质，其中所述再分区所述可扩展表格是响应于接收到数量增加的请求而执行，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目；或响应于接收到数量减少的请求而执行，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目。23.根据条款20所述的存储介质，其中创建所述可扩展表格包括：搜集反映所述多个计算节点中的一个或多个的状态的信息；取决于所搜集的信息确定将在一个或多个计算节点中的哪一个计算节点上创建所述可扩展表格；和创建各自分区以将所述可扩展表格的至少一个子集存储在所述一个或多个计算节点中的每个上。24.根据条款20所述的存储介质，其中创建所述可扩展表格包括开始执行异步表格创建工作流程；且其中响应于接收到描述维护在所述所述非关系数据存储装置中的一个或多个表格的服务请求，所述程序指令还造成所述一个或多个计算机执行返回关于所述一个或多个表格的信息，其中关于所述一个或多个表格的所述信息包括指示是否已由所述异步表格创建工作流程成功地创建所述可扩展表格的信息。25.根据条款20所述的存储介质，其中所述主键包括被指定为散列键属性的单个属性；其中存储在所述可扩展表格中的项目中的每个包括所述散列键属性的各自值；且其中所述分区所述可扩展表格包括取决于所述可扩展表格中的项目的各自散列键属性值的散列表将所述项目分成两个或更多个分区。26.根据条款20所述的存储介质，其中所述分区所述可扩展表格包括将所述可扩展表格分成两个或更多个分区和将所述两个或更多个分区中的每个存储在所述多个计算节点中的不同计算节点上。27.根据条款20所述的存储介质，其中所述主键包括被指定为散列键属性的属性和被指定为范围键属性的另一属性；其中存储在所述可扩展表格中的项目中的每个包括所述散列键属性的各自值和所述范围键属性的各自值；其中所述范围键属性值唯一地识别来自所述可扩展表格中具有相同散列键属性值的所有项目中的特定项目，其中具有相同散列键的项目是根据项目各自范围键属性值来排序；且其中分区所述可扩展表格包括取决于所述可扩展表格中具有相同散列键属性值的项目的各自范围键属性值将所述项目分成两个或更多个分区。28.一种系统，其包括：多个计算节点，每个包括至少一个处理器和存储器，其中所述多个计算节点被配置来实施数据存储服务；其中响应于接收到代表存储服务客户端创建表格的服务请求，且其中所述服务请求指定所述表格的识别符和索引存储在所述表格中的项目的主键，所述数据存储服务被配置来在非关系数据存储装置中创建可扩展表格；其中所述可扩展表格被配置来存储多个项目，多个项目的每个包括所述主键的值；其中所述可扩展表格不具有预定大小限制；且其中创建所述可扩展表格包括开始执行异步表格创建工作流程。29.根据条款28所述的系统，其中响应于接收到描述由所述数据存储服务维护的一个或多个表格的服务请求，所述数据存储服务被配置来返回关于所述一个或多个表格的信息；且其中关于所述一个或多个表格的所述信息包括指示是否已由所述异步表格创建工作流程成功地创建所述可扩展表格的信息。30.根据条款28所述的系统，其中所述数据存储服务还被配置来响应于接收到存储、检索、修改或删除所述可扩展表格中的项目的一个或多个服务请求而以编程方式执行调整所述可扩展表格的大小或分区所述可扩展表格中的至少一个。31.根据条款28所述的系统，其中响应于接收将多个项目存储在所述可扩展表格的一个或多个服务请求，所述数据存储服务被配置来：确定所述多个项目是否能存储在所述可扩展表格的单个分区内；且响应于确定所述多个项目不能存储在所述可扩展表格的单个分区内，执行所述以编程方式分区所述可扩展表格。32.根据条款28所述的系统，其中所述数据存储服务还被配置来响应于接收到数量增加的请求而执行以编程方式分区所述可扩展表格，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目；或响应于接收到数量减少的请求而执行以编程方式分区所述可扩展表格，所述请求是将以下项作为目标：所述可扩展表格中的项目、所述可扩展表格的特定分区中的项目或存储在与所述可扩展表格中的项目的至少一个子集相同的计算节点上的项目。33.根据条款28所述的系统，其中所述主键包括被指定为散列键属性的单个属性和被指定为范围键属性的另一属性；其中存储在所述可扩展表格中的项目中的每个包括所述散列键属性的各自值和所述范围键属性的各自值；以及其中所述范围键属性值唯一地识别来自所述可扩展表格中具有相同散列键属性值的所有项目中的特定项目，其中具有相同散列键的项目是根据项目各自范围键属性值来排序；且其中所述数据存储服务还被配置来取决于所述可扩展表格中具有相同散列键属性值的项目的各自范围键属性值将所述项目分成两个或更多个分区。34.根据条款28所述的系统，所述创建所述可扩展表格还包括：搜集反映所述多个计算节点中的一个或多个的状态的信息；取决于所搜集的信息确定将在一个或多个计算节点中的哪一个计算节点上创建所述可扩展表格；和创建各自分区以将所述可扩展表格的至少一个子集存储在所述一个或多个计算节点中的每个上。35.根据条款28所述的系统，其中响应于接收到从所述可扩展表格检索一个或多个项目的请求且其中所述请求包括优选一致性模型的指示，所述数据存储服务被配置来以与所述优选一致性模型一致的方式返回所述一个或多个项目。图25中示出可以适用于实施采用本文中描述的技术的数据存储服务的一个计算节点。计算节点2500可以包括提供实施这种数据存储服务的系统的组件中的任何一个或所有的功能，或在不同实施方案中，类似于或不同于计算节点2500的多个计算节点可以共同地提供这种功能。例如，在各种实施方案中，一个或多个计算节点2500可以实施任何数量的存储服务客户端110、前端模块140、任何数量的自动管理实体150、任何数量的存储装置(诸如存储节点实体160)和/或网络服务平台130的任何其它组件、自动管理集群或与网络平台130交互的外部资源(诸如简易工作流程组件170或外部存储服务180)。在包括多个计算节点2500的一些实施方案中，所有计算节点2500可以包括相同或类似硬件组件、软件组件和功能，而在其它实施方案中，包括被配置来实施本文中描述的功能的计算系统的计算节点2500可以包括各种各样的硬件组件、软件组件和功能。在一些实施方案中，共同地实施数据存储服务的多个计算节点2500可以是大型共享资源系统或网格计算系统的组件。在所示出的实施方案中，计算节点2500包括经由输入/输出(i/o)接口2530耦接到系统存储器2520的一个或多个处理器2510。计算节点2500还包括耦接到i/o接口2530的网络接口2540和一个或多个输入/输出装置2550。如上文提及，在一些实施方案中，给定节点可以实施代表诸如本文中描述的数据存储服务客户端管理和维护(例如，非关系数据库中)表格中的数据的系统的一个以上组件的功能。在各种实施方案中，计算节点2500可以是包括一个处理器2510的单处理器系统或包括多个(例如，两个、四个、八个或另一合适的数量)处理器2510的多处理器系统。处理器2510可以是能够执行指令的任何合适的处理器。例如，在各种实施方案中，处理器2510可以是实施各种指令集架构(isa)(诸如x86、powerpc、sparc或mipsisa)或任何其它合适的isa中的任何一个的通用或嵌入式处理器。在多处理器系统中，处理器2510中的每个可以通常但并非必须实施相同isa。类似地，在诸如共同地实施数据存储服务的一个分布式计算系统的分布式计算系统中，计算节点中的每个可以实施相同isa，或个别计算节点和/或节点的副本组可以实施不同isa。在一些实施方案中，系统存储器2520可以包括非临时计算机可读存储介质，其被配置来存储可由处理器2510访问的程序指令和/或数据。在各种实施方案中，系统存储器2520可以使用任何合适的存储器技术(诸如静态随机访问存储器(sram)、同步动态ram(sdram)、非易失性/快闪型存储器或任何其它类型的存储器)来实施。在所示出的实施方案中，实施诸如上文描述的所希望功能的程序指令和数据被示出分别存储在系统存储器2520内作为程序指令2525且存储在数据存储装置2535内。例如，程序指令2525可以包括当在处理器2510上执行时实施以下各项中的任何一个或所有的程序指令：存储服务客户端110、前端模块140(其可以包括用户接口)、自动管理实体150、存储节点实体160、管理主控台265、请求路由器、分级主机、一个或多个元数据表格、简易工作流程组件170、外部存储服务180和/或提供本文中描述的数据存储服务的系统的任何其它组件、模块或子模块。程序指令2525也可以包括被配置来实施系统(其实施本文中未描述的数据存储服务)的额外功能的程序指令。在各种实施方案中，数据存储装置2535可以包括以下各项的集合：由数据存储服务代表其客户端/用户维护的数据和/或由实施如本文中描述的这种服务的计算系统使用的元数据(包括(但不限于)代表服务的客户端/用户管理并维护的表格、元数据表格、业务规则、分区映射、路由表、索引、命名空间和/或其分区、服务水平协议参数值、订户优选和/或账号信息、性能数据和/或资源使用数据)。在其它实施方案中，可以在不同类型的计算机可读介质上或与系统存储器2520或计算节点2500分开的类似介质上接收、发送或存储如本文中描述用于实施采用上述技术的数据存储服务的程序指令和/或数据。一般来说，计算机可读介质可以包括存储介质或存储器介质，诸如磁性或光学介质，例如经由i/o接口2530耦接到计算节点2500的磁盘或cd/dvd-rom。存储在计算机可读存储介质上的程序指令和数据可以由传输介质或信号(诸如电信号、电磁信号或数字信号，其可以经由诸如可以经由网络接口2540实施的通信介质(诸如网络和/或无线链路)传达)传输到计算节点2500以由处理器2510a执行。在一个实施方案中，i/o接口2530可以被配置来协调处理器2510、系统存储器2520和计算节点中的任何周边装置(包括网络接口2540或其它周边接口，诸如输入/输出装置2550)之间的i/o通信量。在一些实施方案中，i/o接口2530可以执行任何必要的协议、时序或其它数据变换以将来自一个组件(例如，系统存储器2520)的数据信号转换成适合由另一组件(例如，处理器2510)使用的格式。在一些实施方案中，i/o接口2530可以包括支持通过各种类型的周边总线(诸如(例如)周边组件互连(pci)总线标准或通用串行总线(usb)标准的变体)附接的装置。在一些实施方案中，i/o接口2530的功能可以被划分成两个或更多个分离组件，诸如(例如)北桥和南桥。此外，在一些实施方案中，i/o接口2530(诸如到系统存储器2520的接口)的功能中的一些或所有可以直接并入到处理器2510中。网络接口2540可以被配置来允许在计算节点2500与附接到网络的其它装置(诸如其它计算机系统、通信装置、输入/输出装置或外部存储装置)之间或在提供共享计算服务的系统中的其它节点之间进行数据交换。在各种实施方案中，网络接口2540可以支持经由以下各项进行通信：有线或无线通用数据网络(诸如(例如)任何合适的类型的以太网络)；电信/电话网络，诸如模拟语音网络或数字光纤通信网络；存储区域网络，诸如光纤通道san；或任何其它合适的类型的网络和/或协议。在一些实施方案中，输入/输出装置2550可以包括一个或多个显示终端、键盘、小键盘、触摸板、扫描装置、语音或光学识别装置或适用于由一个或多个计算节点2500输入或检索数据的任何其它装置。多个输入/输出装置2550可以存在于计算节点2500中或可以分布在被配置来实施数据存储服务的系统的各个计算节点上。在一些实施方案中，类似输入/输出装置可与计算节点2500分离且可以通过有线或无线连接(诸如通过网络接口2540)与系统的一个或多个计算节点交互。在不同实施方案中，存储服务客户端(例如，用户、订户和/或客户端应用)可以以各种方式与诸如本文中描述的数据存储服务交互，以(诸如)提交服务请求(包括(但不限于)存储、检索和/或更新表格中的项目的请求或再分区表格的请求)和接收结果。例如，所述服务的一些订户可以物理访问计算节点2500，且如果是，那么可以与各种输入/输出装置2550交互以提供和/或接收信息。替代地，其它客户端/用户可以使用客户端计算系统以(诸如)经由网络接口2540(例如，经由互联网和/或万维网)远程访问系统。此外，提供服务的系统的计算节点中的一些或所有可以(例如，响应于用户请求)经由一个或多个输入/输出装置2550将各种反馈或其它一般类型的信息提供给客户端/用户。本领域那些技术人员将明白，计算节点2500仅仅是说明性且不旨在限制实施方案的范围。特别地说，计算系统和装置可以包括可执行所指示功能的硬件或软件的任何组合，包括计算机、网络装置、互联网电器、pda、无线电话、传呼机等。在一些实施方案中，计算节点2500也可以连接到未示出的其它装置。此外，在一些实施方案中，由所示出的组件提供的功能可以组合在较少组件中或分布在额外组件中。类似地，在一些实施方案中，可以不提供所示出的组件中的一些的功能和/或可以使用其它额外功能。本领域那些技术人员也将应明白，虽然各个项目被示出为当使用时存储在存储器中或存储装置上，但是为了存储器管理和数据整合的目的，这些项目或其部分可以在存储器与其它存储装置之间传送。替代地，在其它实施方案中，软件组件中的一些或所有可以在另一装置上的存储器上执行且经由计算机间通信与所示出的计算系统进行通信。系统组件或数据结构中的一些或所有也可以(例如，作为指令或结构化数据)存储在计算机可读存储介质或由适当驱动器读取的便携式物件上(其的各种实例已在上文加以描述)。在一些实施方案中，存储在与计算节点2500分离的计算机可读存储介质上的指令可以经由(经由诸如网络和/或无线链路的通信介质传达的)传输介质或信号(诸如电信号、电磁信号或数字信号)传输到计算节点2500。各种实施方案还可以包括接收、发送或存储根据前文描述在计算机可读存储介质上实施的指令和/或数据。因此，不同实施方案可以用其它计算机系统配置来实践。注意，虽然本文中描述的多个实例针对包括非关系数据库的系统中的各种技术的应用，但是在其它实施方案中这些技术可以应用于使用不同存储模式实施非关系数据存储装置的系统中。本领域那些技术人员将明白，在一些实施方案中，可以以替代性方式(诸如在更多软件模块或程式之间进行划分或合并成较少模块或程式)提供由上文论述的方法提供的功能。类似地，在一些实施方案中，所示出的方法可以提供的功能多于或少于所描述的功能(诸如当其它所示出的方法分别反而缺少或包括这种功能时或当更改所提供的功能的量时)。此外，虽然各种操作可以被示出为以特定方式(例如，串行或并行)和/或按特定次序执行，但是本领域那些技术人员将明白，在其它实施方案中可以按其它次序和以其它方式执行操作。本领域那些技术人员也将明白，上文论述的数据结构可以以不同方式(诸如通过将单个数据结构划分成多个数据结构或通过将多个数据结构合并成单个数据结构)而结构化。类似地，在一些实施方案中，所示出的数据结构可以存储的信息多于或少于所描述的信息(诸如当其它所示出的数据结构分别反而缺少或包括这种信息时或当更改所存储的信息的量或类型时)。如附图中描绘且本文中描述的各种方法表示方法的说明性实施方案。在各种实施方案中，所述方法可以实施于软件、硬件或其组合中。类似地，在各种实施方案中，可以改变任何方法的次序，且可以添加、重排序、组合、省略、修改(等)各种元件。从前文中将明白，虽然本文中已为了示出目的而描述了特定实施方案，但是可以在不违背所附权利要求及其中叙述的元件的精神和范围的情况下作出各种修改。此外，虽然下文以某些权利要求形式呈现某些方面，但是发明人预期呈任何可用权利要求形式的各个方面。例如，虽然仅一些方面当前可以被叙述为具体实施于计算机可读存储介质中，但是同样也可以这样具体实施其它方面。本领域一般技术人员在得益于本公开之后应明白可以作出各种修改和改变。这旨在包括所有这样的修改和改变，且因此上文描述被视为说明性而非限制性意义。当前第1页12当前第1页12