Abstract: Techniques and constructs that improve annotating target columns of a target database by performing automated annotation of the target columns using sources. The techniques include calculating a similarity score between a target column and columns extracted from a table that is included in a source. The similarity score is calculated based at least in part on a similarity between a value in the target column of the target database and a column value of the extracted column from the table and on a similarity between an identity of the target column of the target database and column identities of the extracted columns from the table. In some examples, the techniques calculate similarity scores for one or more extracted columns and annotate the target column based on the similarity scores.

Abstract: The subject disclosure is directed towards components in different server clusters, e.g., comprising software components such as components of a distributed computing system. Components are available for use by distributed computing system applications, yet managed by the distributed computing system runtime such that only a single instance can be activated and exist within communicating (non-partitioned) clusters. Also described is recovery from a situation in which no longer partitioned clusters each have created the same component.

Abstract: The subject disclosure is directed towards components in different server clusters, e.g., comprising software components such as components of a distributed computing system. Components are available for use by distributed computing system applications, yet managed by the distributed computing system runtime such that only a single instance can be activated and exist within communicating (non-partitioned) clusters. Also described is recovery from a situation in which no longer partitioned clusters each have created the same component.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset.

Abstract: The subject matter described herein relates to managing data with flexible schema. A method, computer storage medium, and system are provided for managing data with flexible schema. In one embodiment, the method comprises providing a logical view for logical tables of a database; and managing mappings between the logical tables and a physical table according to predefined mapping constraints, each of the logical tables mapped as a part of the physical table. The mapping constraints at least specify that (i) a logical column in the logical tables is mapped to at least one physical column in the physical table, and (ii) distinct logical columns in one of the logical tables are mapped to distinct physical columns in the physical table. As a result, schema evolution may be done with minimized data migration.

Abstract: The subject matter described herein relates to managing data with flexible schema. A method, computer storage medium, and system are provided for managing data with flexible schema. In one embodiment, the method comprises providing a logical view for logical tables of a database; and managing mappings between the logical tables and a physical table according to predefined mapping constraints, each of the logical tables mapped as a part of the physical table. The mapping constraints at least specify that (i) a logical column in the logical tables is mapped to at least one physical column in the physical table, and (ii) distinct logical columns in one of the logical tables are mapped to distinct physical columns in the physical table. As a result, schema evolution may be done with minimized data migration.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset. A class variable may be associated with storage devices of a stripeset to identify the type of data that the stripeset can store. The class variable may be increased (or otherwise modified) when a computer stores data of a different class in the stripeset.

Abstract: Described is programmatic access to persistent XML and relational data from applications based upon explicit mappings between object classes, XML schema types, and relations. The mappings are used in data access, that is, they drive query and update processing. A query may be processed into a query for accessing the XML data and another query for second type for accessing the relational data. Mappings support strongly-typed classes and loosely-typed classes, and may be conditional upon other data, may decouple query and update translation performed at runtime from schema translation used at compile time, and/or may be compiled into transformations that produce objects from XML data and transformations that produce XML data from objects. Mappings may be generated automatically or provided by the developer.

Abstract: Concept expansion using tables, such as web tables, can return entities belonging to a concept based on an input of the concept and at least one seed entity that belongs to the concept. A concept expansion frontend can receive the concept and seed entity and provide them to a concept expansion framework. The concept expansion framework can expand the coverage of entities for concepts, including tail concepts, using tables by leveraging rich content signals corresponding to concept names. Such content signals can include content matching the concept that appear in captions, early headings, page titles, surrounding text, anchor text, and queries for which the page has been clicked. The concept expansion framework can use the structured entities in tables to infer exclusive tables. Such inference differs from previous label propagation methods and involves modeling a table-entity relationship. The table-entity relationship reduces semantic drift without using a reference ontology.

Abstract: Techniques and constructs that improve annotating target columns of a target database by performing automated annotation of the target columns using sources. The techniques include calculating a similarity score between a target column and columns extracted from a table that is included in a source. The similarity score is calculated based at least in part on a similarity between a value in the target column of the target database and a column value of the extracted column from the table and on a similarity between an identity of the target column of the target database and column identities of the extracted columns from the table. In some examples, the techniques calculate similarity scores for one or more extracted columns and annotate the target column based on the similarity scores.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset. A class variable may be associated with storage devices of a stripeset to identify the type of data that the stripeset can store. The class variable may be increased (or otherwise modified) when a computer stores data of a different class in the stripeset.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset. A class variable may be associated with storage devices of a stripeset to identify the type of data that the stripeset can store. The class variable may be increased (or otherwise modified) when a computer stores data of a different class in the stripeset.

Abstract: Described is programmatic access to persistent XML and relational data from applications based upon explicit mappings between object classes, XML schema types, and relations. The mappings are used in data access, that is, they drive query and update processing. A query may be processed into a query for accessing the XML data and another query for second type for accessing the relational data. Mappings support strongly-typed classes and loosely-typed classes, and may be conditional upon other data, may decouple query and update translation performed at runtime from schema translation used at compile time, and/or may be compiled into transformations that produce objects from XML data and transformations that produce XML data from objects. Mappings may be generated automatically or provided by the developer.

Abstract: The subject disclosure is directed towards components in different server clusters, e.g., comprising software components such as components of a distributed computing system. Components are available for use by distributed computing system applications, yet managed by the distributed computing system runtime such that only a single instance can be activated and exist within communicating (non-partitioned) clusters. Also described is recovery from a situation in which no longer partitioned clusters each have created the same component.

Abstract: The subject matter described herein relates to managing data with flexible schema. A method, computer storage medium, and system are provided for managing data with flexible schema. In one embodiment, the method comprises providing a logical view for logical tables of a database; and managing mappings between the logical tables and a physical table according to predefined mapping constraints, each of the logical tables mapped as a part of the physical table. The mapping constraints at least specify that (i) a logical column in the logical tables is mapped to at least one physical column in the physical table, and (ii) distinct logical columns in one of the logical tables are mapped to distinct physical columns in the physical table. As a result, schema evolution may be done with minimized data migration.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset. A class variable may be associated with storage devices of a stripeset to identify the type of data that the stripeset can store. The class variable may be increased (or otherwise modified) when a computer stores data of a different class in the stripeset.

Abstract: A sequence of storage devices of a data store may include one or more stripesets for storing data stripes of different lengths and of different types. Each data stripe may be stored in a prefix or other portion of a stripeset. Each data stripe may be identified by an array of addresses that identify each page of the data stripe on each included storage device. When a first storage device of a stripeset becomes full, the stripeset may be shifted by removing the full storage device from the stripeset, and adding a next storage device of the data store to the stripeset. A class variable may be associated with storage devices of a stripeset to identify the type of data that the stripeset can store. The class variable may be increased (or otherwise modified) when a computer stores data of a different class in the stripeset.

Abstract: Aspects of the subject matter described herein relate to automating evolution of schemas and mappings. In aspects, mappings between a conceptual model and a store model are updated automatically in response to a change that occurs to the conceptual model. For example, when a change occurs to the conceptual model, a local scope of the change is determined. The local scope indicates mappings that are most similar to the type(s) affected by the change. Based on the local scope, a pattern of mappings between the conceptual model and the store model is determined. Using this pattern and the nature of the change, the mappings are updated according to the pattern. In addition, the store model and data thereon may be updated in a manner to preserve existing data that is not to be deleted in response to the change.

Abstract: Architecture that includes an ordered and shared log of indexed transaction records represented as multi-version data structures of nodes and node pointers. The log is a sole monolithic source of datastore state and is used for enforcing concurrency control. The architecture also includes a transaction processing component that appends transaction records to the log from concurrent transactions executing on different processors. Each node of a record is assigned a log address.