Abstract: A schema for a hierarchical data structure may include application specific extensions to the schema applied to a hierarchical data structure. Class may be added to the schema by individual applications granted access to a hierarchical data structure. When an access request for an object of the hierarchical data structure is received, the class may be identified in the schema and applied to process the access request to the object. Different classes may be added by different applications without disrupting the utilization of the schema for accessing the hierarchical data structure of other applications.

Abstract: A system such as a service of a computing resource service provider, a directory service, a directory server, or any suitable system includes executable code that, if executed by one or more processors, causes the system to perform a first stage of a multi-stage deployment of a first directory schema by at least providing a second directory schema to a first computer system, wherein the first computer system is associated with a directory configured according to the first directory schema and causing the first computer system to reconfigure the directory according to the second directory schema The system may also determine, based on a result of reconfiguring the directory, whether to proceed to a second stage of the multi-stage deployment of the first directory schema. The system may be utilized as part of a directory schema update process wherein a multi-stage deployment pipeline is utilized.

Abstract: Updates to a hierarchical data structure may be selectively replicated to other replicas of the hierarchical data structure. An update for a hierarchical data structure may be received and committed to the hierarchical data structure. A determination as to whether any other replicas of the hierarchical data structure have permission to receive the update may be made. For those replicas of the hierarchical data structure with permission to receive the update, the update may be provided to the replicas and committed to the replicas. Different types of replication techniques may be implemented, such as pull-based replication techniques or push-based replication techniques. Replication permissions for objects of the hierarchical data structure may be individually defined, in some embodiments.

Abstract: A fleet node management system may include a metadata store, a plurality of fleet nodes, and one or more metadata mutation devices. The metadata store may be configured to store dynamic metadata. The plurality of fleet nodes may be configured to determine, based on a gossip protocol, whether to continue performance of a function that uses a local version of the metadata. The one or more metadata mutation devices may be configured to determine, based on a global state of the fleet nodes, whether to modify the dynamic metadata for the fleet nodes.

Abstract: Routing data is copied from a primary data store to a local data store of a computing device. As the routing data is being copied by the computing device, changes to the data continue to occur. After copying all or a portion of the data, the computing device uses a value of a global sequence number (GSN) to determine if mutations have been made to the primary data. The routing data in the local data store is not consistent with the routing data stored in the primary data store when the value of the GSN is larger after the copying of the routing data as compared to the initial value of the GSN when the copying started. When changes have been made to the data, the computing device integrates the changes into the local data store before beginning routing operations.

Abstract: Scaling events may be detected for hosting hierarchical data structures. Scaling events may be detected to modify the capacity of a data store for hierarchical data structures to handle changing write workloads, read workloads, or storage capacity. Hierarchical data structures may be moved from one group of storage hosts to another group of storage hosts according to a filtered snapshot that includes the hierarchical data structures to be moved that is provided to the destination storage hosts. Changes made to the hierarchical data structures made at the source storage hosts during the move can be applied to the filtered snapshot so that the hierarchical data structures may be made available at the destination storage hosts inclusive of the changes.

Abstract: A computing resource service provider may store user data in a distributed data storage system. The distributed data storage system may contain one or more storage partitions configured to store based at least in part on prefixes of keys contained in a key-value store, where the size of the keys may vary. The one or more storage partitions may track requests to access data where the requests include a key such that the data may be located by the service provider based at least in part on the key. When a request is received a skew value associated with the key included in the request may be determined. The skew value may be determined based at least in part on the ratio of rate estimators, where the rate estimators represent a weighted average of the movement of the keys in a key space. If the skew value exceeds a threshold the service provider may take mitigating action.

Abstract: A key-value store is adapted to represent hierarchical structures, such as directory structures, to be associated with objects otherwise mapped to a flat keyspace. For example, one or more key-value pairs stored in the key-value store are designated to have a key indicating the name of a hierarchical structure, and an associated value that maps the structure to a namespace (e.g., of a group of objects to be associated with a directory). Inbound requests for operations related to the objects in a given namespace and defining the structure are checked against such “redirecting” key-value pairs, as well as one or more policies associated with the structure, the namespace, the key-value pairs, or some combination thereof, to determine whether the structure is related to the namespace objects and whether one or more requested actions are authorized against that structure.

Abstract: Scaling events may be detected for hosting hierarchical data structures. Scaling events may be detected to modify the capacity of a data store for hierarchical data structures to handle changing write workloads, read workloads, or storage capacity. Hierarchical data structures may be moved from one group of storage hosts to another group of storage hosts according to a filtered snapshot that includes the hierarchical data structures to be moved that is provided to the destination storage hosts. Changes made to the hierarchical data structures made at the source storage hosts during the move can be applied to the filtered snapshot so that the hierarchical data structures may be made available at the destination storage hosts inclusive of the changes.

Abstract: A computing resource service provider may store user data in a distributed data storage system. The distributed data storage system may contain one or more storage partitions configured to store based at least in part on prefixes of keys contained in a key-value store, where the size of the keys may vary. The one or more storage partitions may track requests to access data where the requests include a key such that the data may be located by the service provider based at least in part on the key. When a request is received a skew value associated with the key included in the request may be determined. The skew value may be determined based at least in part on the ratio of rate estimators, where the rate estimators represent a weighted average of the movement of the keys in a key space. If the skew value exceeds a threshold the service provider may take mitigating action.

Abstract: A computing resource service provider may store user data in a distributed data storage system. The distributed data storage system may contain one or more storage partitions configured to store based at least in part on prefixes of keys contained in a key-value store, where the size of the keys may vary. The one or more storage partitions may track requests to access data where the requests include a key such that the data may be located by the service provider based at least in part on the key. When a request is received a counter associated with the prefix included in the request may be incremented, the counter may be configured to decay over time. If the counter exceeds a threshold the service provider may split the prefix associated with the counter and generate new partitions responsible for the split prefix.

Abstract: A key-value store is adapted to represent hierarchical structures, such as directory structures, to be associated with objects otherwise mapped to a flat keyspace. For example, one or more key-value pairs stored in the key-value store are designated to have a key indicating the name of a hierarchical structure, and an associated value that maps the structure to a namespace (e.g., of a group of objects to be associated with a directory). Inbound requests for operations related to the objects in a given namespace and defining the structure are checked against such “redirecting” key-value pairs to determine whether the structure is related to the namespace objects, and if so, the request is internally processed to perform the requested operations against the actual key-value pair(s) associated with the objects without necessitating identification of the objects with a fully qualified name as represented in the flat keyspace.

Abstract: Various embodiments of the present invention enable functions, procedures, and triggers to be written in any of the .NET languages and executed by the RDBMS. User code can access data from the local or other SQL servers using the SQL Programming Model and both the SqlServer or SqlClient implementations respectively. Moreover, to improve upon the previous extensibility mechanism, a set of APIs (commonly known as “the in-process provider” or “inproc provider”) is utilized to provide efficient and easy to use data access while running inproc, a data access API that is an implementation of the ADO.net programming model.

Abstract: Various mechanisms are presented that allow for the coordination of transactions in a managed runtime environment. In one aspect, a runtime environment that is hosted in a database system, includes an application programming interface (API). The API can surface the database transactions as ambient transactions, and present them to some user code. When the user code connects to some remote resource, the ambient transaction can be implicitly propagated to the remoter resource, resulting in coordination of the database transaction with any given transaction running in the remote resource.

Abstract: Systems and methodologies that enhance a Tabular Data Stream (TDS) protocol by enabling clients to send tabular formed data as a single parameter to servers. A Table Valued Parameter (TVP) transporting component enables the client servers to transmit entire database tables as a single parameter; when invoking a server side procedure, for example. As such, values can be passed for functions associated with a stored procedure, and a parameter styled Application Program Interface (API) can be implemented.

Abstract: Various mechanisms are presented that allow for the coordination of transactions in a managed runtime environment. In one aspect, a runtime environment that is hosted in a database system, includes an application programming interface (API). The API can surface the database transactions as ambient transactions, and present them to some user code. When the user code connects to some remote resource, the ambient transaction can be implicitly propagated to the remoter resource, resulting in coordination of the database transaction with any given transaction running in the remote resource.

Abstract: Various embodiments of the present invention enable functions, procedures, and triggers to be written in any of the .NET languages and executed by the RDBMS. User code can access data from the local or other SQL servers using the SQL Programming Model and both the SqlServer or SqlClient implementations respectively. Moreover, to improve upon the previous extensibility mechanism, a set of APIs (commonly known as “the in-process provider” or “inproc provider”) is utilized to provide efficient and easy to use data access while running inproc, a data access API that is an implementation of the ADO.net programming model.

Abstract: The present invention the is directed to systems and methods for hosting the CLR in a DBMS in order to achieve reliability, scalability, security, and robustness for enabled DBMS programming features. Integrating the CLR with a DBMS enables programming features in the database such as stored procedures, functions, triggers, types, and aggregates to be written in any of the programming languages that are compiled into IL code supported by the CLR. For the various embodiments of the present invention, the CLR is hosted inside the DBMS and, instead of making requests directly to the server operating system, the CLR instead interfaces with the DBMS via DBMS APIs for such requests, and only the DBMS directly interfaces with the server operating system to access the server.

Abstract: A system and method are provided for modeling structured, semi-structured, and unstructured data all within a single instance of a user defined type (UDT) within a database store. In particular, the XML data model is extended to fields of a UDT. As a result, the properties of the XML data model—such as document order and document structure—can be preserved within instances of a UDT. Moreover, code representing object behavior (i.e., methods that can be invoked on an object in managed code) can be added to the UDT to operate on an XML field, as well as non-XML fields of the UDT. This enables a framework for adding business logic to XML data. The content model of the XML data can be optionally described using XML schema documents associated with the XML fields of the UDT.

Abstract: A method and apparatus for profiling the bed of a furnace involves the production of a digital image of the bed and background. The digital image is processed to determine transitions in the image which correspond to transitions between the bed and background and thereby to the boundary of the bed. Bed characteristics, such as the bed profile, the bed height, the slope of the bed and the volume of the bed are determined from the processed image. The image may be displayed for use in controlling the performance of a furnace. In addition, the determined bed characteristics may be compared with reference bed characteristics, with the differences being displayed, used in controlling the operation of the furnace, or in activating an indicator, such as an alarm, in the event the reference and determined bed characteristics differ by a threshold amount.