A repository of key-value data may store a first object value having an internal structure of a hierarchy of sub-objects. The repository may receive a request to modify the first object, expressed as a projection of locations in the object to be updated and a function that, upon evaluation, returns values to be used to update the projected locations of the object. The repository may determine that the locations specified by the projections correspond to non-overlapping regions of the object and, based on the determination, update the object using the results of evaluating the function.

BACKGROUND

Databases may sometimes be configured to store structured or semi-structured data within a single field. A database may, for example, store a binary file or document in a field at some position within a row of data. When structured or semi-structured data is stored in this manner, conventional database techniques for updating the data in the field may not be adequate, since the database may not be aware of the data's internal structure. Various other techniques have been used to update structured or semi-structured data stored in a database field. However, many of these techniques have aspects that are complex and unwieldy. One of the aspects involves how targets to the update expression are specified.

DETAILED DESCRIPTION

Disclosed herein are systems, methods, and computer program products for performing updates on structured or semi-structured objects, such as a JavaScript Object Notation (“JSON”) objects. Updates to such objects may be based on an update expression that utilizes functional language statements for the “right-hand” side of an update expression, such as the “f(y)” in the update expression “x·y=f(y).” The expressions on the right-hand side of the update expression may specify immutable functions that correspond to projections on the left-hand side of the expression.

The use of functional language elements for the right-hand side of the update expression may be distinguished from the use of procedural languages or declarative languages such as SQL. A procedural or declarative statement would typically process a JSON or other structured object in-place, meaning that a single copy of the object would be loaded into memory and manipulated by a series of operations. When procedural languages are used to specify a query, care must be taken to ensure that operations are expressed in the right order, since changing the order in which the operations are executed can change the results of performing the operations on the object. A similar problem may exist with declarative languages. Using the function-oriented approach described herein, many of these ordering issues may be avoided since the evaluation of any given function (with limited exceptions) does not cause side effects on the target object. The target object is instead only modified once the top-level function in the query has been fully evaluated.

One aspect of using function-based updates involves the “left-hand” side of the update expression. The left-hand side of the update expression “x·y=f(y),” for example, is “x·y.” The left-hand side may indicate which portions or regions of the object are to be updated using the results of evaluating the right-hand side of the update expression. In various instances and embodiments of the present disclosure, projections may be used to specify which portions of an object are to be updated. In these instances and embodiments, there may also be restrictions imposed by the embodiments on the projections that may be employed.

In an example, a distributed database may comprise computing nodes connected to a storage device on which data managed by the database is stored. The computing nodes may further comprise a memory on which computer-executable instructions are stored. When executed by a processor of the computing nodes, the instructions may cause the distributed database to process requests to store, access, and modify data stored on the system.

The distributed database may process a request to update a JSON object held in the memory of the storage device. A JSON object may possess an internal structure that comprises a collection of name-value pairs. The values may themselves be objects, resulting in a nested hierarchy of objects and sub-objects. The distributed database may process the request to modify the JSON object. The request may be expressed as an update expression comprising a left-hand side that represents the target of the update, and a right-hand side that represents one or more functions, which, when evaluated, act as the source of the data used for updating the object.

A component of the distributed database, such as a storage engine or query analyzer, may identify one or more expressions that represent the right-hand side of an update expression. In other words, the expressions may represent the source of the data that is to be used to update the object. The expressions may comprise one or more functions that are to be evaluated in order to obtain the source data for the update.

The storage engine or query analyzer may also identify expressions in the update expression that are indicative of a first portion of an object that is to be modified by processing the update expression. The first portion may refer to a location in a hierarchy of sub-objects that make up the object.

The component of the distributed database may also identify a second portion of the object. The second portion may also be indicative of a portion of the object that is to be modified by processing the update expression. In some instances, the first and second portions of the object may be identified in a projection expression included in the update expression.

The storage engine or query analyzer may also determine that the first portion of the object does not overlap with the second portion. Each portion may represent a region of a sub-hierarchy of objects. If these regions do not overlap (for example, by sharing a common element), the storage engine or query analyzer might update the regions of the object with the results obtained from evaluating the right-hand, or source, side of the update expression.

FIG. 1is a block diagram depicting an example of a system configured as a repository for structured objects. A repository106can include a storage engine108with a translation component110, and a storage device112.

Examples of a repository include database systems such as relational and non-relational databases. In some instances, for example, the repository106may include computing nodes configured as a distributed key-value database system. In a key-value database system, a value may be indexed in the repository106using a corresponding key value. The value may therefore be stored and retrieved using the key value. Note that in many cases, a key may correspond to a collection of values, rather than a single value.

The storage engine108coordinates storing and retrieving data items from the storage device112. The storage engine108may also perform aspects of query processing. A query may specify instructions for storing, retrieving, or modifying data items stored on the storage device112. Aspects of query processing may include performing operations, as described herein, that pertain to operations performed on a particular value. For example, an object O1might be stored in the repository106using a key value K1. A query might be performed on the object O1in which a portion of O1is examined. In some cases, the query might specify that the object O1should be replaced in storage with a new object O2that has been updated based on instructions included in the query.

In the example ofFIG. 1, the object O1is stored on the storage device112in response to object102being inserted, at the direction of client device100, into the repository106. The object102may consist of a hierarchy of sub-objects. Examples of sub-objects include single values, tuples, and nested sub-objects. In one example, the object102may comprise a JSON object. An object may comprise additional sub-objects organized as a hierarchy. The hierarchy may have one or more levels. Where the hierarchy has a single level, it may be equivalent to a list, array, or other similar object. Accordingly, the term “hierarchy” may encompass lists, arrays, or other similar structures.

A request to update the object O1stored on storage device112may be issued by a client device100. The request to update the object O1may comprise two portions, as may be seen in the following example, which is not intended to be limiting. A request to update the object O1might be expressed using the syntax target=source, where target might be a reference to one or more regions of the hierarchy of sub-objects contained within O1, and source is an expression defining how the regions of the target are to be updated.

The target portion of the expression may be referred to as a projection. In the example ofFIG. 1, projection103is expressed as a tuple of two identifiers, (“a·b” and “a·c”). This may indicate that the two regions a·b and a·c of the hierarchy of sub-objects that make up the object O1are the targets of the update request. The identifiers “a·b” and “a·c” may be described as paths. The syntax used to express a path may vary. However, in general terms, a path may comprise information suitable for locating a position in the hierarchy of sub-objects. There may, for example, be a name or other identifier associated with each node of the hierarchy of sub-objects, which may be traversed using the path information.

The source portion of the request may be represented by a function-based query specification104. The function-based query specification104is distinguished from other forms of query specifications such as those that employ procedural or declarative mechanisms. Structured Query Language (“SQL”), for example, is a declarative language in which a query is expressed as a description of the desired result set. A database component typically translates the description from a declarative statement to a set of procedural instructions. The function-based query specification104, in contrast, is expressed as a function of one or more parameters. The parameters may themselves consist of functions of additional parameters. Accordingly, the function-based query specification104may express a hierarchy of functions.

A translation component110of or associated with the storage engine108may parse the projection103and the function-based query specification104in order to identify the target and source of the update. The translation component110may also, in conjunction with the storage engine108, cause a query plan to be formulated and executed. The function-based query specification104may be evaluated, and the results may be applied to the regions of the sub-hierarchy of objects specified by projection103. A new object O2may be formed by copying object O1and changing the portions of the hierarchy of sub-objects specified by the projection103, using the results of evaluating the function-based query specification104.

Projections and function-based query specifications may be further understood in view ofFIG. 2, which is a block diagram depicting an update expression comprising projections and functional expressions.FIG. 2depicts an update expression200written as “SET A·B, A·C=F1(P1), F2(P2).” The target portion of update expression200is “A·B, A·C,” and may be described as a tuple of two values, as a projection of two values, or as two projections—a first projection202and a second projection208. The source portion of update expression200is “F1(P1), F2(P2),” and may be described as a tuple of two functions, or as a first function204of a first parameter206and a second function210of a second parameter212. Note that in this case, the tuple of two functions returns two values, corresponding to the two projections in the target portion of the update expression200.

Projections may be expressed as paths through a hierarchy of sub-objects contained within an object maintained in a repository. A repository, such as a key-value database or a relational database, may maintain structured or semi-structured objects on a storage device. The objects may, for example, be stored in a row or item collection associated with a key value. Requests to update the object may, accordingly, involve accessing the row or item collection and within the object itself.FIG. 3is a block diagram depicting an example of a structured or semi-structured object. Other examples might include arrays, lists, or other structures. Some of these structures may be “flat” hierarchies, such as an array or a list of simple objects, sometimes referred to as values, such as strings, integers, or floating point numbers. An array, list, or other structure may, however, contain a number of nested sub-objects.

In the example ofFIG. 3, an object300may consist of a hierarchy of objects, which may be referred to as sub-objects. By way of example,FIG. 3depicts sub-objects302and304as children in an object hierarchy that has a parent object300as a root. Each object may include additional data in a variety of forms, one example of which is the name-value pairs depicted inFIG. 3as name-value pairs306-312. A name-value pair may be described as a sub-object comprising two sub-objects: a name sub-object and a value sub-object.

The object300, sub-objects302and304, and name-value pairs306-312may be associated with identifiers. In some cases, the object may have an explicit identifier field. In other cases, another field may be used. For example, a property of sub-object302might be used as an identifier. Similarly, a name and/or value of a name-value pair306-312might be used as an identifier. These identifiers may be concatenated or otherwise joined to express a path identifier, which may be used to locate a particular sub-object or a region of the hierarchy of sub-objects having the identified object as its root. This may be seen inFIG. 4, which is a block diagram depicting an example of locating regions of a hierarchy of sub-objects using a path identifier.

FIG. 4depicts a sub-hierarchy of objects400corresponding to the object depicted inFIG. 3. The object404may itself be treated as the root of a hierarchy of sub-objects. In this example, the object404has two children, sub-objects406and408, which in turn contain sub-objects410-412and sub-objects414-416, respectively.

A location in the hierarchy of sub-objects400may be identified by forming a path identifier from identifiers (or other characteristics) of the objects and sub-objects on a path to the location. For example, a path to location “A·B·D”402may be derived from steps through the hierarchy of sub-objects, beginning with the root object404. A path to the root object404might be expressed, in this example, as “A.” Similarly, a path to sub-object406might be expressed as “A·B,” and finally a path to sub-object410as “A·B·D.”

A region of the hierarchy of sub-objects400may also be identified by a path. The region may include the sub-object identified by the path as well as some or all of its children. Typically, all of the descendants of a sub-object may be considered to be part of a region specified by a path to the sub-object.

FIG. 5depicts an example of regions of a sub-hierarchy of objects identified by paths to locations in the sub-hierarchy. In the example ofFIG. 5, a hierarchy of sub-objects518may comprise object500and its sub-objects502-512. A region514of sub-objects referred to by the path identifier “A·B” may include the sub-object502identified by the path “A·B,” as well as all of its descendent sub-objects506-508. A second region516may be identified by the path “A·B·D.”

The region514corresponding to path “A·B” may be said to overlap with the region516corresponding to path “A·B·D.” Regions overlap when they share at least one element in common. In this example, the two regions514and516overlap because they each contain sub-object506.

Referring back toFIG. 1, when storage engine108processes a request to update an object, it may process the request by identifying the target and source portions of the request, identifying and evaluating the projections specified in the target portion, identifying an devaluating the functions specified in the source portion, and then applying the results of those functions to the portions of the object specified in the projections. This may be done by forming a new copy of the object in which the regions identified by the projections have been replaced with the results of evaluating the functions.

Embodiments may, as disclosed herein, ensure that the projections do not specify overlapping portions of the hierarchy of sub-objects. This may be done to increase efficiency of processing related to replacing the regions of the hierarchy of sub-objects. When regions of the hierarchy are overlapped, the functional nature of the source portion of the request to update the object may be disrupted. For example, the order in which the regions are replaced may affect the resulting object if the regions overlap. Accordingly, embodiments may verify that the projections included in a request to update an object do not specify overlapping regions.

FIG. 6is a flow diagram depicting verification of a projection. Although depicted as a sequence of blocks, those of ordinary skill in the art will appreciate that the depicted order should not be construed as limiting the scope of the present disclosure and that at least some of the operations referred to in the depicted blocks may be altered, omitted, reordered, supplemented with additional operations, or performed in parallel. Embodiments of the depicted process may be implemented using various combinations of computer-executable instructions executed by a computing system, such as the computing systems described herein.

Block600depicts receiving a request to update an object stored in a repository. Referring toFIG. 1, the repository106may receive the request and direct storage engine108to process it. Next, block602depicts identifying expressions in the request that are indicative of the function or functions that are to be evaluated. This may involve storage engine108and translation component110parsing textual information included in the request. The operations of block602may be performed in conjunction with the operations of block604, which depicts identifying expressions in the request that are indicative of projections.

As depicted by block606, the storage engine108and translation component110may then identify regions of the hierarchy that correspond to the projection. This may be performed partially during the operations of blocks602-604, by locating path identifiers used as projections on the target side of an update expression. Each path identifier may be further decomposed into one or more identifiers of steps in the path. The path and step information may be utilized in subsequent operations, such as those of block608, to determine if any of the projected regions overlap. Note that, in this context, projected regions refer to the target portion of an update expression. There may be other projections in the request to update the object that are not part of the target, and that therefore may be permitted to specify overlapping regions.

In some instances, the targets of a projection may be determined through full or partial evaluation of an expression. For example, a query might contain a conditional expression that indicates a portion of the hierarchy to be updated if the condition is true. In other cases, evaluation of a case or switch statement might indicate which among multiple possible regions of a hierarchy are to be updated. Accordingly, certain regions of the hierarchy may be potentially overlapping, but whether or not the overlap is to occur may not be known until the expression is at least partially evaluated.

Block608depicts determining if any of the projections in a target portion of a request to update the object correspond to overlapping regions of the object. In some cases, the storage engine108or translation component110may make the determination based on inspection of the identifiers. For example, the identifiers “A·B” and “A·B·D” may be considered overlapping because “D” is identifiable as a child of “B” based on the path identifiers. In some cases, the determination may require further evaluation. This could be the case, for example, when a step in a projection is expressed as a function. For example, a path might be expressed as “A·B·ElementAt(x).” In such cases, the projection may first be evaluated to determine which portion of the hierarchy of sub-objects to which it refers. In some cases, embodiments may determine that projections apply to overlapping regions of the hierarchy. However, as with other types of conditional expressions, whether or the regions overlap may not be determinable until the expression is at least partially evaluated.

As depicted, operations associated with block610may be performed if the projections do not specify any overlapping regions. Block610depicts evaluating the function or functions that make up the source portion of the update request and then applying the results, in some way, to the projected regions of the hierarchy of sub-objects. The results may be applied in a number of ways. Generally speaking, however, the result of the application is an object in which the projected regions have been replaced with the results of evaluating function or functions that make up the source portion of the update request.

The operations of block612may be performed when one or more of the projected regions overlap. As depicted by block612, this may involve determining to not update the object. In some cases and embodiments, further processing may be employed to determine if a conflict exists between the results to be applied to the overlapping regions. For example, if the overlapping regions specified by the paths “A·B” and “A·B·D” are to be updated, there may not be a conflict if the nature of the updates is such that they may be applied in any order. This might occur, for example, if the update to the region “A·B” changed data in a sub-region “A·B·E” but not in the region “A·B·D.” In other cases, the storage engine108or translation component110may simply prohibit all overlapping regions. When detected, the storage engine108or translation component110may determine to not process the request to update the object. The storage engine108or translation component110might also transmit, to client device100, an indication that the request will not be processed.

If a request to update an object contains one or more conditional expressions, such that regions of a hierarchy may potentially overlap, there are at least two possible approaches. In some instances, embodiments may determine to not process an update when a request to update an object contains expressions that may potentially overlap. In other embodiments, evaluation of the object may continue until the conditional expressions may be evaluated and the regions of the hierarchy that will be updated are known. Once the targeted regions are known, an error condition may be raised if the regions overlap.

FIG. 7depicts updating a structured or semi-structured object using projection verification. Although depicted as a sequence of blocks, those of ordinary skill in the art will appreciate that the depicted order should not be construed as limiting the scope of the present disclosure and that at least some of the operations referred to in the depicted blocks may be altered, omitted, reordered, supplemented with additional operations, or performed in parallel. Embodiments of the depicted process may be implemented using various combinations of computer-executable instructions executed by a computing system, such as the computing systems described herein.

Block700depicts receiving a request to update an object stored in a repository of key-value data. The request may, for example, comprise textual information specifying a source and target of the request. The source portion may be specified as one or more functional expressions. As used herein, functional refers to a programmatic technique in which the evaluation of the source portion of the command produces no side effects with respect to the object being acted upon. For example, the update command may refer to an object O1, but the object O1is not modified by evaluation of the source portion of the update request.

Block702depicts identifying, in the request, one or more expressions indicative of new (or equivalently, updated) versions of portions of the hierarchy of sub-objects. These expressions may correspond to the source portion of an update request, as described herein. Identifying the expression may involve parsing textual information included in the update request and thereby locating the source portion.

Block704depicts identifying, in the request, a first projection indicative of a first portion of the hierarchy to update based on the one or more expressions. Similarly, block706depicts identifying a second projection indicative of a second portion of the hierarchy to update based on the one or more expressions. These operations may involve parsing textual information included in the update request, and may be performed in conjunction with the operations depicted by block702.

Block708depicts determining that the first portion of the hierarchy of sub-objects does not overlap with the second portion of the hierarchy of sub-objects. Path information contained in the identified projections may be compared to determine if the paths specify overlapping portions of the hierarchy. In some cases, the projection may be represented as an expression that may be evaluated. The evaluated projection may then be evaluated to determine if the region of the sub-hierarchy that it refers to overlaps with another projection in the update expression.

Block710depicts updating the first and second portions of the hierarchy of sub-objects based on the one or more expressions identified by the operations of block702. This process may be done, in some instances, by loading the original object from a storage device into memory, locating the regions of memory corresponding to the projected portions of the hierarchy of sub-objects, and replacing those regions with the results of the one or more expressions. The new version of the object may then be written to storage to replace the prior version of the object.

The operations of block710are performed partially in response to the determination, as depicted by block708, that the first portion of the hierarchy of sub-objects does not overlap with the second portion. Embodiments may therefore proceed with updating the first and second portions of the hierarchy of sub-objects when the portions do not overlap. If they do overlap, embodiments may instead determine to not complete processing of the update request.

Another aspect of the operations depicted by block710may involve determining that the data types associated with the results of evaluating the right-hand side of the expressions is compatible with the types associated with the left-hand side. In other words, the region of the hierarchy indicated by the projections may be compared, with respect to type compatibility, to results that may be produced by evaluating the right-hand side of the expression. A data type associated with the result of evaluating the right-hand side expressions may be compared to one or more types associated with the projection and the region of the hierarchy that it corresponds to. If the two are compatible, the hierarchy may be updated. If the two data types are not compatible, the request to update the object may be rejected.

Aspects of the invention may be further illustrated byFIG. 8, which is a flow diagram depicting a method for projecting update targets in a structured or semi-structured object. Although depicted as a sequence of blocks, those of ordinary skill in the art will appreciate that the depicted order should not be construed as limiting the scope of the present disclosure and that at least some of the operations referred to in the depicted blocks may be altered, omitted, reordered, supplemented with additional operations, or performed in parallel. Embodiments of the depicted process may be implemented using various combinations of computer-executable instructions executed by a computing system, such as the computing systems described herein.

Block800depicts receiving a request to update a structured or semi-structured object stored on a storage device. The object, being structured or semi-structured, may comprise a hierarchy of sub-objects.

Block802depicts identifying a first portion of the hierarchy of sub-updates to update with a first result of evaluating expressions associated with the request to update the object. The expressions may correspond to the source portion of the request to update the object.

Block804depicts identifying a second portion of the hierarchy of sub-objects to update with a second result of evaluating the expressions. Note that the source portion of the request to update the object may produce a number of values, which may be mapped to the projections of the target portion of the request.

Block806depicts updating the first and second portions of the hierarchy of sub-objects partly in response to determining that the first portion of the hierarchy of sub-objects does not overlap with the second portion of the hierarchy of sub-objects. The updating may, in some instances, be performed on a copy of the object loaded into memory. The updated object may then be returned to a calling device, used to replace the prior version of the object, or added to a storage device as a new object.

FIG. 9is a diagram depicting an example of a distributed computing environment on which aspects of the present invention may be practiced. Various users900amay interact with various client applications, operating on any type of computing device902a, to communicate over communications network904with processes executing on various computing nodes910a,910b, and910cwithin a data center920. Alternatively, client applications902bmay communicate without user intervention. Communications network904may comprise any combination of communications technology, including the Internet, wired and wireless local area networks, fiber optic networks, satellite communications, and so forth. Any number of networking protocols may be employed.

Communication with processes executing on the computing nodes910a,910b, and910c, operating within data center920, may be provided via gateway906and router908. Numerous other network configurations may also be employed. Although not explicitly depicted inFIG. 9, various authentication mechanisms, web service layers, business objects, or other intermediate layers may be provided to mediate communication with the processes executing on computing nodes910a,910b, and910c. Some of these intermediate layers may themselves comprise processes executing on one or more of the computing nodes. Computing nodes910a,910b, and910c, and processes executing thereon, may also communicate with each other via router908. Alternatively, separate communication paths may be employed. In some embodiments, data center920may be configured to communicate with additional data centers, such that the computing nodes and processes executing thereon may communicate with computing nodes and processes operating within other data centers.

Computing node910ais depicted as residing on physical hardware comprising one or more processors916, one or more memories918, and one or more storage devices914. Processes on computing node910amay execute in conjunction with an operating system or alternatively may execute as a bare-metal process that directly interacts with physical resources, such as processors916, memories918, or storage devices914.

Computing nodes910band910care depicted as operating on virtual machine host912, which may provide shared access to various physical resources, such as physical processors, memory, and storage devices. Any number of virtualization mechanisms might be employed to host the computing nodes.

The various computing nodes depicted inFIG. 9may be configured to host web services, database management systems, business objects, monitoring and diagnostic facilities, and so forth. A computing node may refer to various types of computing resources, such as personal computers, servers, clustered computing devices, and so forth. A computing node may, for example, refer to various computing devices, such as cell phones, smartphones, tablets, embedded device, and so on. When implemented in non-virtualized form, computing nodes are generally associated with one or more memories configured to store computer-readable instructions and one or more processors configured to read and execute the instructions. A hardware-based computing node may also comprise one or more storage devices, network interfaces, communications buses, user interface devices, and so forth. Computing nodes also encompass virtualized computing resources, such as virtual machines implemented with or without a hypervisor, virtualized bare-metal environments, and so forth. A virtualization-based computing node may have virtualized access to hardware resources as well as non-virtualized access. A virtualization-based computing node therefore also encompasses the physical hardware needed to execute the virtualization resources. A computing node may be configured to execute an operating system as well as one or more application programs. In some embodiments, a computing node might also comprise bare-metal application programs.

In at least some embodiments, a server that implements a portion or all of one or more of the technologies described herein may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media.FIG. 10depicts a general-purpose computer system that includes or is configured to access one or more computer-accessible media. In the illustrated embodiment, computing device1000includes one or more processors1010a,1010b, and/or1010n(which may be referred herein singularly as a processor1010or in the plural as the processors1010) coupled to a system memory1020via an input/output (“I/O”) interface1030. Computing device1000further includes a network interface1040coupled to I/O interface1030.

In some embodiments, a graphics processing unit (“GPU”)1012may participate in providing graphics rendering and/or physics processing capabilities. A GPU may, for example, comprise a highly parallelized processor architecture specialized for graphical computations. In some embodiments, processors1010and GPU1012may be implemented as one or more of the same type of device.

System memory1020may be configured to store instructions and data accessible by processor(s)1010. In various embodiments, system memory1020may be implemented using any suitable memory technology, such as static random access memory (“SRAM”), synchronous dynamic RAM (“SDRAM”), nonvolatile/Flash®-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory1020as code1025and data1026.

Network interface1040may be configured to allow data to be exchanged between computing device1000and other device or devices1060attached to a network or networks1050, such as other computer systems or devices, for example. In various embodiments, network interface1040may support communication via any suitable wired or wireless general data networks, such as types of Ethernet networks, for example. Additionally, network interface1040may support communication via telecommunications/telephony networks, such as analog voice networks or digital fiber communications networks, via storage area networks, such as Fibre Channel SANs (storage area networks), or via any other suitable type of network and/or protocol.

A compute node, which may be referred to also as a computing node, may be implemented on a wide variety of computing environments, such as tablet computers, personal computers, smartphones, game consoles, commodity-hardware computers, virtual machines, web services, computing clusters, and computing appliances. Any of these computing devices or environments may, for convenience, be described as compute nodes or as computing nodes.