Abstract: Methods, systems, apparatuses, and computer program products are provided for coordinating a distributed database transaction. A transaction driver, such as a client machine, may initiate a distributed transaction. The transaction driver may transmit to a transaction coordinator a driver report that includes identifying information related to the distributed transaction, including an identification of participants involved in the transaction. The coordinator may determine whether participant reports, which include a status of the portion of the distributed database transaction of a particular participant, are received from each of the participants. Participant reports may also identify participants that are descendants of the reporting participant. The transaction coordinator may store, in a table, information to track the progress of the distributed transaction. Using the table, an outcome of the distributed transaction may be determined and transmitted to one or more of the involved participants.

Abstract: Embodiments of the present disclosure are directed a distributed storage system that supports query data. One embodiment provides, at a front-end node, a method comprising receiving a query regarding data stored in an object, obtaining information identifying data nodes at which blocks of the object are stored, sending, to a first data node, a query regarding data in a first block, and receiving results for the query regarding the data in the first block comprising an incomplete record. The method further comprises sending, to a second data node, a query regarding data in a second block comprising the incomplete record, the second block being stored on a different physical device than the first block, and receiving results for the query regarding the data in the second block. The method further comprises outputting the results for the queries regarding the data in the first block and the data in the second block.

Abstract: A system that maps files into multiple parts and initiates storage of each part within a respective storage provider. The mapping facilitates this by correlating each of the multiple parts to a corresponding storage provider which may be different than the storage provider that stores a different part of the same file. The system then initiates storage of the multiple parts of the file in each of their corresponding storage provider in accordance with the mapping, and using a storage-provider-facing API. Similarly, retrieval and/or editing of a partial file may be accomplished by referencing the mapping, and using the same API issued to the appropriate storage provider. Each storage provider is capable of interfacing with the system using this same API.

Abstract: Examples are disclosed that relate to querying data in a distributed storage system. One example provides, at a front-end node, a method comprising receiving a query regarding data stored in an object, obtaining information identifying data nodes at which blocks of the object are stored, sending, to a first data node, a query regarding data in a first block, and receiving results for the query regarding the data in the first block comprising an incomplete record. The method further comprises sending, to a second data node, a query regarding data in a second block comprising the incomplete record, the second block being stored on a different physical device than the first block, and receiving results for the query regarding the data in the second block. The method further comprises outputting the results for the queries regarding the data in the first block and the data in the second block.

Abstract: One example provides, at a front-end node of a distributed storage system, a method comprising receiving a query regarding data stored in an object, obtaining information identifying data nodes at which blocks of the object are stored, sending, to a first data node, a query regarding data in a first block, and receiving results for the query regarding the data in the first block comprising an incomplete record. The method further comprises sending, to a second data node, a query regarding data in a second block comprising the incomplete record, the second block being stored on a different physical device than the first block, and receiving results for the query regarding the data in the second block. The method further comprises outputting the results for the queries regarding the data in the first block and the data in the second block.

Abstract: Storing an incoming data stream using successive files that are consecutively populated. The appropriate file to populate a given data stream portion into is determined by mapping the data stream offset to a file, and potentially also an address within that file. The successive files may be the same size, so that the file can be identified based on the data stream address (or offset) without the use of an index. Furthermore, the files may be easily named by having that size be some multiple of a binary power of bytes. That way, the files themselves can be automatically and named and identified by using the more significant bit or bits of the data stream offset to uniquely identify the file and establish ordering of the files. Replication may occur from a primary to a secondary store by transmitting the offset, and the actual data to be stored.

Abstract: Examples are disclosed that relate to querying data in a distributed storage system. One example provides, at a front-end node, a method comprising receiving a query regarding data stored in an object, obtaining information identifying data nodes at which blocks of the object are stored, sending, to a first data node, a query regarding data in a first block, and receiving results for the query regarding the data in the first block comprising an incomplete record. The method further comprises sending, to a second data node, a query regarding data in a second block comprising the incomplete record, the second block being stored on a different physical device than the first block, and receiving results for the query regarding the data in the second block. The method further comprises outputting the results for the queries regarding the data in the first block and the data in the second block.

Abstract: Methods, systems, apparatuses, and computer program products are provided for coordinating a distributed database transaction. A transaction driver, such as a client machine, may initiate a distributed transaction. The transaction driver may transmit to a transaction coordinator a driver report that includes identifying information related to the distributed transaction, including an identification of participants involved in the transaction. The coordinator may determine whether participant reports, which include a status of the portion of the distributed database transaction of a particular participant, are received from each of the participants. Participant reports may also identify participants that are descendants of the reporting participant. The transaction coordinator may store, in a table, information to track the progress of the distributed transaction. Using the table, an outcome of the distributed transaction may be determined and transmitted to one or more of the involved participants.

Abstract: Storing an incoming data stream using successive files that are consecutively populated. The appropriate file to populate a given data stream portion into is determined by mapping the data stream offset to a file, and potentially also an address within that file. The successive files may be the same size, so that the file can be identified based on the data stream address (or offset) without the use of an index. Furthermore, the files may be easily named by having that size be some multiple of a binary power of bytes. That way, the files themselves can be automatically and named and identified by using the more significant bit or bits of the data stream offset to uniquely identify the file and establish ordering of the files. Replication may occur from a primary to a secondary store by transmitting the offset, and the actual data to be stored.

Abstract: A system that maps files into multiple parts and initiates storage of each part within a respective storage provider. The mapping facilitates this by correlating each of the multiple parts to a corresponding storage provider which may be different than the storage provider that stores a different part of the same file. The system then initiates storage of the multiple parts of the file in each of their corresponding storage provider in accordance with the mapping, and using a storage-provider-facing API. Similarly, retrieval and/or editing of a partial file may be accomplished by referencing the mapping, and using the same API issued to the appropriate storage provider. Each storage provider is capable of interfacing with the system using this same API.

Abstract: Storing historical/previous values of a field of a relational database in the same table. The previous values can be conveniently used to revert back to any of such previously stored values. Thus, for each update/modify operation, the present value is stored as a previous value. In one embodiment, the previous values are stored in a VARRAY associated with each field. The indexed entries of the VARRAY store the present as well as previous values of the field.

Abstract: Storing historical/previous values of a field of a relational database in the same table. The previous values can be conveniently used to revert back to any of such previously stored values. Thus, for each update/modify operation, the present value is stored as a previous value. In one embodiment, the previous values are stored in a VARRAY associated with each field. The indexed entries of the VARRAY store the present as well as previous values of the field.

Abstract: Storing historical/previous values of a field of a relational database in the same table. The previous values can be conveniently used to revert back to any of such previously stored values. Thus, for each update/modify operation, the present value is stored as a previous value. In one embodiment, the previous values are stored in a VARRAY associated with each field. The indexed entries of the VARRAY store the present as well as previous values of the field.

Abstract: RDF store database designs and efficient techniques for converting SPARQL queries to SQL queries are described that provide faster triplet access, and which can reduce the computational overhead and cost associated with storing large volumes of RDF metadata. In various embodiments RDF data can be stored in de-normalized tables tailored to provide efficient query and storage performance. The provided query conversion techniques provide reliable and efficient query performance.

Abstract: RDF store database designs and efficient techniques for converting SPARQL queries to SQL queries are described that provide faster triplet access, and which can reduce the computational overhead and cost associated with storing large volumes of RDF metadata. In various embodiments RDF data can be stored in de-normalized tables tailored to provide efficient query and storage performance. The provided query conversion techniques provide reliable and efficient query performance.

Abstract: Ensuring that desired transactions are serviced in a timely manner in a database server. Resources are reserved ahead for transaction classes of interest, and the corresponding information is stored in a resource reservation table. In one embodiment, each transaction instance is admitted for servicing only if the reservation table indicates that sufficient resources are reserved for the transaction at the time instance the transaction is received. Resources may be reserved for specific transaction instances by using a label value, which would be contained in each transaction for which the time slot is reserved.

Abstract: RDF store database designs and efficient techniques for converting SPARQL queries to SQL queries are described that provide faster triplet access, and which can reduce the computational overhead and cost associated with storing large volumes of RDF metadata. In various embodiments RDF data can be stored in de-normalized tables tailored to provide efficient query and storage performance. The provided query conversion techniques provide reliable and efficient query performance.

Abstract: RDF store database designs and efficient techniques for converting SPARQL queries to SQL queries are described that provide faster triplet access, and which can reduce the computational overhead and cost associated with storing large volumes of RDF metadata. In various embodiments RDF data can be stored in de-normalized tables tailored to provide efficient query and storage performance. The provided query conversion techniques provide reliable and efficient query performance.

Abstract: A user may merely need to specify various states of transactions and actions to be performed upon reaching a state for the corresponding transaction, and a front end block may automatically perform an action when the corresponding state is reached. Each action may indicate any necessary movement of data to a new storage portion. As a result, a programmer can be shielded from various details (e.g., which database to store the data in, data format conversions) in (developing the code for) processing the transactions.

Abstract: Ensuring that desired transactions are serviced in a timely manner in a database server. Resources are reserved ahead for transaction classes of interest, and the corresponding information is stored in a resource reservation table. In one embodiment, each transaction instance is admitted for servicing only if the reservation table indicates that sufficient resources are reserved for the transaction at the time instance the transaction is received. Resources may be reserved for specific transaction instances by using a label value, which would be contained in each transaction for which the time slot is reserved.