Abstract: A received query is analyzed to provide a set of potential bushy tree operation plans that include the creation of one or more “sub-joins” that provide intermediate resultant “sub-tables”, and using these sub-tables as operands in the other predicates of the query. The received query is analyzed to identify “satellite” tables and “seed” tables. A satellite table is a table of the database that is filtered by a selective predicate, and is connected to only one other table in the database via at least one linking predicate, and a seed table is a table of the database that is connected to a satellite table and at least one other table. Multiple candidate operation plans are formulated as bushy trees that include a sub-join of each seed table and its connected satellite table. A least cost operation plan is selected for execution from among these candidate operation plans and the conventional least cost linear operation plan based on the costs associated with each operation plan.

Abstract: A method includes receiving a user-defined extension configured to operate on data from a content database and comprising code expressed in a first programming language, the user-defined extension comprising at least one unresolved object and a function calling the at least one unresolved object. On a first pass through the user-defined extension code, each respective unresolved object is bound to a respective placeholder object such that the function calls each respective placeholder object and each respective placeholder object is mapped to the respective unresolved object, and delaying evaluation of the user-defined extension code until a second pass through the user-defined extension code. On the second pass, machine code corresponding to a compiled version of the user-defined extension is obtained by sequentially obtaining machine code for each respective unresolved object as each respective placeholder is called in the function.

Abstract: A method for generating code for queries in a database system includes obtaining a user query in a first programming language, the user query comprising at least one query parameter for selecting data from a content database. The method includes obtaining machine code corresponding to a compiled version of the user query. Obtaining the machine code includes generating code in a second programming language corresponding to a compiled version of the user query, generating byte code defining a plurality of functions corresponding to a compiled version of the code in the second programming language, and obtaining the machine code corresponding to the compiled version of the user query based on the byte code. The method further comprises executing the machine code using the at least one query parameter, thereby returning a result satisfying the at least one query parameter. A related non-transitory computer-readable medium and system are also provided.

Abstract: A set of six atomic primitives are provided for a database management system that may be used in combination to provide all of the common features and functions of a clustered database, including data failover, auto-healing, and elastic scaling. These six atomic primitives include CREATE, DROP, DETACH, ATTACH, COPY, and PROMOTE. Of particular note, it is shown that by maintaining appropriate metadata, including the status of each instance of each partition in the cluster, the versatility and reliability of this set of primitives is sufficient to implement each of the aforementioned data failover, auto-healing, and elastic scaling functions with high efficiency using a minimal number of these primitives. Each primitive is atomic (such that the cluster clearly in one state or another) and online (a workload of reads and writes is uninterrupted while the primitive runs), and each primitive is scoped to a single partition of data, thereby enabling parallel processing.

Abstract: A received query is analyzed to provide a set of potential bushy tree operation plans that include the creation of one or more “sub-joins” that provide intermediate resultant “sub-tables”, and using these sub-tables as operands in the other predicates of the query. The received query is analyzed to identify “satellite” tables and “seed” tables. A satellite table is a table of the database that is filtered by a selective predicate, and is connected to only one other table in the database via at least one linking predicate, and a seed table is a table of the database that is connected to a satellite table and at least one other table. Multiple candidate operation plans are formulated as bushy trees that include a sub-join of each seed table and its connected satellite table. A least cost operation plan is selected for execution from among these candidate operation plans and the conventional least cost linear operation plan based on the costs associated with each operation plan.

Abstract: A set of six atomic primitives are provided for a database management system that may be used in combination to provide all of the common features and functions of a clustered database, including data failover, auto-healing, and elastic scaling. These six atomic primitives include CREATE, DROP, DETACH, ATTACH, COPY, and PROMOTE. Of particular note, it is shown that by maintaining appropriate metadata, including the status of each instance of each partition in the cluster, the versatility and reliability of this set of primitives is sufficient to implement each of the aforementioned data failover, auto-healing, and elastic scaling functions with high efficiency using a minimal number of these primitives. Each primitive is atomic (such that the cluster clearly in one state or another) and online (a workload of reads and writes is uninterrupted while the primitive runs), and each primitive is scoped to a single partition of data, thereby enabling parallel processing.

Abstract: A database is partitioned into a plurality of sorted runs, wherein each sorted run includes a set of sorted segments of data records. One of the sorted runs preferably includes more than half of the records of the database, and the other sorted runs are progressively smaller. A query is processed by searching each of the sorted runs. Writes are effected by appending a new sorted run to the database. Sorted merges are used to combine the smaller sorted runs. Deletions are effected by marking the deleted record in the sorted run. Modifications are effected by deleting the original record and writing the modified record to the database. The larger sorted runs are only re-sorted or merged when the sorted run includes a substantial number of deletions. Two merge queues are maintained to enable rapid merges of the smaller sorted runs while a merger of larger sorted runs are occurring.

Abstract: A system and method for executing query plans preprocesses a user's queries to identify and extract select parameters of the query, creates a skeletal query with reference to the extracted parameters, creates and compiles an executable version of the skeletal query, then executes the compiled version of the skeletal query using the particular parameters in the current query. The compiled version of the parameterized skeletal query is stored, and when another query is submitted that matches the skeletal query (but with potentially different parameters), the previously compiled skeleton query is executed with the parameters of this latter query.

Abstract: A database durability implementation records only committed transactions in a log file. A pair of log files and a pair of snapshot files are maintained. When a snapshot of the database is completed, the ‘current’ log becomes the ‘prior’ log and the other log becomes the ‘current’ log. After the next snapshot is completed, the prior log and prior snapshot may be deleted. Transactions that are not committed are not recorded in the current log, thereby avoiding the need to undo aborted transactions. If a given change is reflected in a completed snapshot, it does not appear in either of the logs; if the change is not yet reflected in a completed snapshot, it is guaranteed to be stored in one of the logs. During recovery, the system assesses both snapshots. The most recent of the completed snapshots is used, and the corresponding log(s) is (are) applied.

Abstract: A distributed query system includes a distributed collection of dynamically created compiled queries. As each client submits a query, a parameterized query skeleton is identified, which identifies the general form of the query, and the parameters associated with the particular query. If a compiled form of the skeletal query is available within the distributed system, it is executed with the parameters of the current query. If the compiled form of the skeletal query is not available within the distributed system, a compiled form is created, and the location of this compiled skeletal query is stored for subsequent access by this client, or other clients. The executable compiled skeletal queries may be stored at each client system, or in a commonly available server storage system.

Abstract: A distributed query system includes a distributed collection of dynamically created compiled queries. As each client submits a query, a parameterized query skeleton is identified, which identifies the general form of the query, and the parameters associated with the particular query. If a compiled form of the skeletal query is available within the distributed system, it is executed with the parameters of the current query. If the compiled form of the skeletal query is not available within the distributed system, a compiled form is created, and the location of this compiled skeletal query is stored for subsequent access by this client, or other clients. The executable compiled skeletal queries may be stored at each client system, in a commonly available server storage system, or within one or more database servers. A routing system may be provided to efficiently route parameterized queries to the appropriate location(s) of the compiled skeletal query.

Abstract: A distributed query system includes a distributed collection of dynamically created compiled queries. As each client submits a query, a parameterized query skeleton is identified, which identifies the general form of the query, and the parameters associated with the particular query. If a compiled form of the skeletal query is available within the distributed system, it is executed with the parameters of the current query. If the compiled form of the skeletal query is not available within the distributed system, a compiled form is created, and the location of this compiled skeletal query is stored for subsequent access by this client, or other clients. The executable compiled skeletal queries may be stored at each client system, in a commonly available server storage system, or within one or more database servers. A routing system may be provided to efficiently route parameterized queries to the appropriate location(s) of the compiled skeletal query.

Abstract: A system and method for executing query plans preprocesses a user's queries to identify and extract select parameters of the query, creates a skeletal query with reference to the extracted parameters, creates and compiles an executable version of the skeletal query, then executes the compiled version of the skeletal query using the particular parameters in the current query. The compiled version of the parameterized skeletal query is stored, and when another query is submitted that matches the skeletal query (but with potentially different parameters), the previously compiled skeleton query is executed with the parameters of this latter query.

Abstract: A database durability implementation records only committed transactions in a log file. A pair of log files and a pair of snapshot files are maintained. When a snapshot of the database is completed, the ‘current’ log becomes the ‘prior’ log and the other log becomes the ‘current’ log. After the next snapshot is completed, the prior log and prior snapshot may be deleted. Transactions that are not committed are not recorded in the current log, thereby avoiding the need to undo aborted transactions. If a given change is reflected in a completed snapshot, it does not appear in either of the logs; if the change is not yet reflected in a completed snapshot, it is guaranteed to be stored in one of the logs. During recovery, the system assesses both snapshots. The most recent of the completed snapshots is used, and the corresponding log(s) is (are) applied.

Abstract: A distributed query system includes a distributed collection of dynamically created compiled queries. As each client submits a query, a parameterized query skeleton is identified, which identifies the general form of the query, and the parameters associated with the particular query. If a compiled form of the skeletal query is available within the distributed system, it is executed with the parameters of the current query. If the compiled form of the skeletal query is not available within the distributed system, a compiled form is created, and the location of this compiled skeletal query is stored for subsequent access by this client, or other clients. The executable compiled skeletal queries may be stored at each client system, or in a commonly available server storage system.