Abstract: A shared-nothing database system is provided in which parallelism and workload balancing are increased by assigning the rows of each table to “slices”, and storing multiple copies (“duplicas”) of each slice across the persistent storage of multiple nodes of the shared-nothing database system. When the data for a table is distributed among the nodes of a shared-nothing system in this manner, requests to read data from a particular row of the table may be handled by any node that stores a duplica of the slice to which the row is assigned. For each slice, a single duplica of the slice is designated as the “primary duplica”. All DML operations (e.g. inserts, deletes, updates, etc.) that target a particular row of the table are performed by the node that has the primary duplica of the slice to which the particular row is assigned. The changes made by the DML operations are then propagated from the primary duplica to the other duplicas (“secondary duplicas”) of the same slice.

Abstract: Disclosed herein are techniques for storing, within a database system, metadata that indicates an intended usage (IU). Once created, an IU may be assigned to a column to (a) indicate how the column is intended to be used, and (b) affect how the database server behaves when database operations involve values from the column. The IU assigned to a column supplements, but does not replace, the datatype definition for the column. Each IU may have an IU-bundle. The IU-bundle of an IU indicates how the database server behaves with respect to any column that is assigned the IU. For example, the IU-bundle may indicate constraints that the database server must validate during operations on values from columns assigned to the IU. Techniques are also described for implementing multi-column IUs and flexible IUs.

Abstract: Techniques for automatically migrating documents from a document database to a relational database are provided. In one technique, it is determined whether a set of documents, from a document database system, can be stored in a relational database system. If so, one or more entities to be normalized are identified based on a hierarchical structure of the set of documents. One or more scripts are generated based on the identified one or more entities. In a related technique, a set of documents from a document database system is stored. It is validated that the set of documents can be converted to one or more duality views. Data of the set of documents is normalized for storing in a relational database system. A script is generated that, when executed, generates the one or more duality views.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: One or more engine instances are executed on each host to form an engine cluster. A plurality of control instances are executed on a first set of hosts to form a control cluster and comprise a control instance leader and one or more control instance followers. In response to a first host indicating a failure of a neighbor host, a pair-wise focused investigation is initiated to check peer-to-peer connections between the first host and the neighbor host. In response to one or more additional hosts indicating failures of neighbor hosts while the pair-wise focused investigation is being performed, a wide investigation is performed to check connections between the control cluster and the plurality of hosts. One or more hosts are added to an eviction list and an eviction protocol is performed to evict the one or more hosts from the engine cluster using the eviction list.

Abstract: Techniques for automatically selecting a type of vector index are provided. In one technique, in response to determining to generate a vector index based on a base table that stores a plurality of vectors, a number of the plurality of vectors is identified. Based at least on the number of the plurality of vectors, a particular type of vector index is identified from among a plurality of types of vector indexes. Examples of the plurality of types include an HNSW index and an IVF index. A vector index of the particular type is generated for the base table. Another criterion in identifying a type of vector index to generate is the number of neighbors that is a parameter in generating a certain type of vector index.

Abstract: Techniques are described for Transaction Guard to impose at-most-once execution by generating and using the database's native transaction identifier, DB XID. In an implementation, DB XID is unique within a (pluggable) database instance (with local undo) and uniquely identifies a transaction in the database. The Transaction Guard that is extended to use native transaction information determines the commit outcome using the native transaction identifier of the transaction instead of relying on the persistence of the Logical Transaction Identifier (LTXID) in a separate table. Using the native transaction identifier, the Transaction Guard significantly improves performance by eliminating the extra write(s) incurred during commit operations.

Abstract: Techniques for providing a transactionally-consistent Hierarchical Navigable Small Worlds (HNSW) index are described. In one technique, a HNSW index for a plurality of vectors is stored. In response to receiving a set of changes to the plurality of vectors, storing the set of changes in a shared journal table instead of applying the set of changes to the HNSW index. in response to receiving a vector query that includes a query vector, a subset of the set of changes in the shared journal table is identified based on the query vector. Also, based on the query vector and the HNSW index, a subset of the plurality of vectors is identified. A result of the vector query is generated based on the subset of the set of changes and the subset of the plurality of vectors.

Abstract: Techniques for deploying a vector index on multiple nodes of a cluster are provided. In one technique, an instruction is received to create a vector index on a set of vectors that is stored in a vector database that is connected to the multiple nodes. In response, an HNSW index is created based on the set of vectors and the HNSW index is stored on each node. In response to receiving a vector query, a node processes the vector query against its copy of the HNSW index. In another technique, each node retrieves, from a vector database, a respective subset of a set of vectors and generates, based on the respective subset, a respective HNSW index. A vector query is transmitted to each node, which traverses its HNSW index to generate results of the vector query. The results from each node are combined to generate final results.

Abstract: A computer analyzes a relational schema of a database to generate a data entry schema and encodes the data entry schema as JSON. The data entry schema is sent to a database client so that the client can validate entered data before the entered data is sent for storage. From the client, entered data is received that conforms to the data entry schema because the client used the data entry schema to validate the entered data before sending the data. Into the database, the entered data is stored that conforms to the data entry schema. The data entry schema and the relational schema have corresponding constraints on a datum to be stored, such as a range limit for a database column or an express set of distinct valid values. A constraint may specify a format mask or regular expression that values in the column should conform to, or a correlation between values of multiple columns.

Abstract: Disclosed is an approach to autonomously abort a lower priority transaction that is blocking a higher priority transaction, where the lower priority transaction is holding a lock on a resource for which there is contention. Some approaches also provide an efficient way to implement identification of a blocker transaction, which drastically reduces the response time to abort the blocker transaction.

Abstract: One or more engine instances are executed on each host to form an engine cluster. A plurality of control instances are executed on a first set of hosts to form a control cluster and comprise a control instance leader and one or more control instance followers. In response to a first host indicating a failure of a neighbor host, a pair-wise focused investigation is initiated to check peer-to-peer connections between the first host and the neighbor host. In response to one or more additional hosts indicating failures of neighbor hosts while the pair-wise focused investigation is being performed, a wide investigation is performed to check connections between the control cluster and the plurality of hosts. One or more hosts are added to an eviction list and an eviction protocol is performed to evict the one or more hosts from the engine cluster using the eviction list.

Abstract: One or more engine instances are executed on each host to form an engine cluster. A plurality of control instances are executed on a first set of hosts to form a control cluster and comprise a control instance leader and one or more control instance followers. In response to a first host indicating a failure of a neighbor host, a pair-wise focused investigation is initiated to check peer-to-peer connections between the first host and the neighbor host. In response to one or more additional hosts indicating failures of neighbor hosts while the pair-wise focused investigation is being performed, a wide investigation is performed to check connections between the control cluster and the plurality of hosts. One or more hosts are added to an eviction list and an eviction protocol is performed to evict the one or more hosts from the engine cluster using the eviction list.

Abstract: A shared-nothing database system is provided in which parallelism and workload balancing are increased by assigning the rows of each table to “slices”, and storing multiple copies (“duplicas”) of each slice across the persistent storage of multiple nodes of the shared-nothing database system. When the data for a table is distributed among the nodes of a shared-nothing system in this manner, requests to read data from a particular row of the table may be handled by any node that stores a duplica of the slice to which the row is assigned. For each slice, a single duplica of the slice is designated as the “primary duplica”. All DML operations (e.g. inserts, deletes, updates, etc.) that target a particular row of the table are performed by the node that has the primary duplica of the slice to which the particular row is assigned. The changes made by the DML operations are then propagated from the primary duplica to the other duplicas (“secondary duplicas”) of the same slice.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: A Lock-Free Reservation mechanism is provided. When a transaction issues an update that affects a value in a “reservable column” of a row, the database server does not immediately obtain a lock that covers the row. Instead, the database server adds a reservation to a reservation journal. At the time the transaction commits, a lock is obtained and the requested update is made. In one implementation, before adding the reservation to the reservation journal, the database server determines whether making the update would violate any constraints involving the reservable column. In one implementation, the constraint check not only takes into account the current value of the data item that is being updated and the amount of the update, but also pre-existing reservations in the reservation journal that affect the same data item.

Abstract: Disclosed herein are techniques for storing, within a database system, metadata that indicates an intended usage (IU). Once created, an IU may be assigned to a column to (a) indicate how the column is intended to be used, and (b) affect how the database server behaves when database operations involve values from the column. The IU assigned to a column supplements, but does not replace, the datatype definition for the column. Each IU may have an IU-bundle. The IU-bundle of an IU indicates how the database server behaves with respect to any column that is assigned the IU. For example, the IU-bundle may indicate constraints that the database server must validate during operations on values from columns assigned to the IU. Techniques are also described for implementing multi-column IUs and flexible IUs.

Abstract: A computer analyzes a relational schema of a database to generate a data entry schema and encodes the data entry schema as JSON. The data entry schema is sent to a database client so that the client can validate entered data before the entered data is sent for storage. From the client, entered data is received that conforms to the data entry schema because the client used the data entry schema to validate the entered data before sending the data. Into the database, the entered data is stored that conforms to the data entry schema. The data entry schema and the relational schema have corresponding constraints on a datum to be stored, such as a range limit for a database column or an express set of distinct valid values. A constraint may specify a format mask or regular expression that values in the column should conform to, or a correlation between values of multiple columns.