QUERY RESPONSE BASED ON A JOURNAL DATABASE AND A BACKUP DATABASE

Abstract

In some examples, a system replicates a write event to a journal database. The write event involves a modification of a source database containing data points arranged in a multidimensional space. The write event replication adds a journal data point to the journal database. This journal data point contains the write data from the write event and metadata indicating a write operation associated with that data. Based on receiving a restore query associated with restoring data from the source database, the system, according to a filter in the restore query, receives a first result from the journal database and a second result from the backup database. The system then combines the first and second results to produce a restore result as the response to the restore query.

Description

background

[0001] Data stored in databases can be accessed by querying those databases. Various database technologies exist, including relational databases, vector databases, graph databases, and other types of databases. Brief description of the drawings

[0002] Some embodiments of the present disclosure are described with reference to the following figures. Fig. is a block diagram of an arrangement that includes a source vector database, a journal vector database, a backup vector database, a replication controller, and a backup controller, according to some examples. Fig. This is a block diagram of an example for creating a restored vector database using the journal vector database and the backup vector database, according to some examples. Fig. is a block diagram of a storage medium that stores machine-readable instructions according to some examples. Fig. This is a block diagram of a system, based on some examples. Fig. This is a flowchart of a process, based on some examples.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated to make the example shown clearer. Furthermore, the drawings contain examples and / or embodiments that correspond to the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. Detailed description

[0004] Certain types of databases allow you to search for data points within the database that are similar to one or more of the data points specified in the query. An example of such a database is a vector database, in which the data is organized as vectors in a multidimensional space. A vector in the vector database represents a corresponding object. In some cases, the multidimensional space can encompass a large number of dimensions. A vector contains attributes that correspond to these dimensions. Each vector is positioned at a location in the multidimensional space based on the values ​​of the attributes within the vector. Vectors that are closer together in the multidimensional space represent more similar objects than vectors that are farther apart.

[0005] To protect the integrity of data in a vector database, data replication techniques can be used. In some cases, write events containing write data to modify the vector database (the "source vector database") can be replicated to a journal (also called a log). At a later time, the write events replicated to the journal can be applied (also called a "replay") to a backup vector database, which contains copies of the vectors in the source vector database. Replaying the write events in the journal results in an update of the backup vector database.

[0006] To recover data in the event of data corruption or loss in the source vector database, some recovery techniques first apply all write events in the journal to the backup vector database (playback) before performing a recovery operation to restore data from the backup vector database. However, applying the journal write events to the backup vector database can be relatively time-consuming, especially if the journal contains a large number of entries. Furthermore, applying the journal write events to the backup vector database can be irreversible, meaning the backup vector database might not be able to be restored to a previous state.

[0007] In accordance with some implementations of this disclosure, when restoring data from a source database containing data points in a multidimensional space, a restore query can be made by a requester (e.g., a user, program, or machine) to see what data is present in a target version of the source database. The restore query causes the retrieval of contents from a journal database and a backup database to create the target version of the source database.In response to the restore query, a restore agent retrieves initial restore data from the journal database (the initial restore data contains journal data points in the journal database that satisfy the restore query) and secondary restore data from the backup database (the secondary restore data contains backup data points in the backup database that satisfy the restore query). The restore agent then combines the initial and secondary restore data to produce result restore data that can be presented to the requester without first applying any existing journal database entries to the backup database. The restore query can search for a subset of the data points to be restored in the source database.For example, a series of transactions (at different times) may have been performed that involve writes to the source database. The recovery query can include a transaction identifier that identifies a transaction, and in response to the recovery query, the recovery agent restores data points up to the transaction identified by the recovery query.

[0008] In this context, a "database" can refer to a data storage device. A "data point" can refer to a collection of attributes that are set to corresponding values ​​to represent an object. An "object" can refer to a person, an animal, a thing, a concept, or any other element. An example of a data point in a multidimensional space is a vector in a vector database. Other types of databases can also use data points arranged in a multidimensional space.

[0009] Fig. Figure 1 is a block diagram of an example arrangement comprising a source vector database 102, a journal vector database 104, and a backup vector database 106. Although some of the examples discussed here relate to vector databases, it should be noted that in other examples, techniques or mechanisms according to some implementations of this disclosure may be applied to other types of databases that store data points in a multidimensional space.

[0010] Although the example in Fig. While example 102 shows a single source vector database, other examples may contain multiple source vector databases. Similarly, other examples may contain multiple backup vector databases and / or multiple journal vector databases. A "source" vector database is a vector database that is intended to be protected from data loss or corruption by replicating the vector database data to a different storage structure.

[0011] A "journal" vector database is a vector database that stores vectors from the source vector database that have undergone write operations (e.g., deletions, additions, and modifications) in corresponding journal entries. A journal entry also contains metadata that provides information about the type of write operation applied to the vector in the journal entry. The journal entries can be applied to a backup vector database. Applying the journal entries to the backup vector database updates the vectors in the backup vector database based on the journal entries to reflect write operations performed on the source vector database.

[0012] A "backup" vector database is a vector database that stores copies of vectors from the source vector database. If the journal vector database is not empty, the backup vector database is outdated with respect to the source vector database; in other words, at least one vector in the backup vector database is outdated with respect to at least one corresponding vector in the source vector database.

[0013] Vector databases are useful in various applications. For example, vector databases, in conjunction with machine learning, can be used to process and analyze data with a large number of dimensions (attributes). Machine learning using vector databases can be applied to natural language processing, image classification, and text analysis. Other application examples for vector databases include document search, such as finding images, videos, documents, and so on. Vector databases can also be used to detect anomalies or identify malware.

[0014] The example arrangement of Fig. This also includes a Replication Controller 108 and a Backup Controller 110. Although they are shown as two separate controllers, in other examples the Replication Controller 108 and the Backup Controller 110 can be integrated into a single controller. In further examples, the functions of the Replication Controller and / or the Backup Controller 110 can be distributed across additional controllers.

[0015] As used here, a “control unit” can refer to one or more hardware processing circuits, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry. Alternatively, a “controller” can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) that can be executed on the one or more hardware processing circuits.

[0016] Source vector database 102 stores vectors V1-V6. Although in Fig. While a specific number of vectors is represented, it should be noted that in other examples, a different number of vectors may be present in the source vector database 102, the journal vector database 104, and the backup vector database 106. The backup vector database 106 also contains a copy of each of the vectors V1-V6.

[0017] Various write operations can be performed with respect to the source vector database 102. Fig. This shows an example of three write events, including a delete event 112, a change event 114, and an add event 116. The delete event 112 deletes vector V5, the change event 114 modifies vector V6 with an updated vector V6-R, and the add event 116 adds a new vector VN to the source vector database 102.

[0018] The replication controller 108 replicates (at 109) write events, including delete events 112, change events 114, and add events 116, to the journal vector database 104 via a network 120. Replication is performed via a journal write agent 125 in the backup controller 110. A write event can include an input / output (I / O) operation to write data to the source vector database 102. The I / O operations of write events can be part of one or more transactions. A "transaction" can refer to any collection of one or more I / O operations. A requester (e.g., a person, a program, or a machine) accessing the source vector database 102 can specify the start and end points of a transaction. Thus, a transaction has a start point and an end point.Each transaction is identified by a transaction identifier, which can be a numeric or alphanumeric value used to distinguish one transaction from another. Some transactions are executed sequentially, while others can be executed in parallel. In some examples, the transaction identifiers are incremental indices that identify successive transactions as they are initiated.

[0019] The replication controller 108 replicates I / O operations from transactions to the journal vector database 104. A replicated I / O operation (a write event) is added as a journal entry to the journal vector database 104. In the example of Fig. Three journal entries, 132, 134, and 136, were added to journal vector database 104 as a result of the replication (at 109) of the delete event 112, the change event 114, and the add event 116. Each journal entry contains a vector that is the subject of a write event, as well as metadata associated with the corresponding I / O operation. For example, in the example of Fig. Journal entry 132 contains vector V5 and metadata 142, which may contain information about the type of I / O operation (in this case a delete I / O operation) and a transaction identifier to identify the transaction to which the I / O operation belongs.

[0020] Journal entry 134 contains the updated vector V6-R and metadata 144 with information specifying a modification I / O operation and a transaction identifier of the transaction to which the modification I / O operation belongs. Journal entry 136 contains the new vector VN and metadata 146 with information specifying an addition I / O operation and a transaction identifier identifying the transaction to which the addition I / O operation belongs.

[0021] Note that prior to the application of journal entries to backup vector database 106, write events represented by the journal entries in journal vector database 104 are not reflected in backup vector database 106.

[0022] The backup controller 110 contains the journal write agent 125 to write journal entries to the journal vector database 104 in response to replication requests from the replication controller 108. A replication request can include a request to replicate one or more write events to the journal vector database 104. The journal write agent 125 generates write commands to write the corresponding journal entries to the journal vector database 104. An "agent" in an ECU can refer to a part of the ECU's hardware processing circuitry or to machine-readable instructions executed by the ECU.

[0023] Backup controller 110 contains a replay agent 122, which is designed to apply the journal entries in journal vector database 104 to backup vector database 106 (at 124). Replay agent 122 can apply the journal entries to backup vector database 106 (at 124) in response to a user request or another trigger (such as a periodic trigger associated with the periodic application of journal entries to backup vector database 106, or any other type of trigger). In some examples, the journal entries associated with a particular transaction are applied to backup vector database 106 in the same order in which the journal entries were added to journal vector database 104. After the journal entries in journal vector database 104 have been applied to backup vector database 106, the journal entries can be removed from journal vector database 104.

[0024] The backup controller 110 also includes a recovery agent 126, which can restore vectors based on the contents of the journal vector database 104 and the backup vector database 106. In some examples, the recovery agent 126 includes a recovery application programming interface (API) 128, which is accessible to client devices, such as a client device 130. The recovery API 128 contains various routines that can be called by the client device 130 to perform a database recovery operation. For example, in response to a request from a user or other entity on the client device 130, the client device 130 can call a routine of the recovery API 128 to initiate the database recovery operation.The called routine of the recovery API 128 can send a recovery request to the journal vector database 104 and the backup vector database 106 to retrieve entries that satisfy the recovery request.

[0025] A "restore query" refers to a database query submitted to retrieve data for restoration in a target version of the source vector database 102. The restore query may contain a filter specifying one or more criteria (or predicates). All entries in journal vector database 104 and backup vector database 106 that meet the filter are retrieved to produce a restore result containing the target version of the source vector database 102. Entries in journal vector database 104 that meet the restore query filter may contain zero or more journal entries. Entries in backup vector database 106 that meet the restore query filter may contain zero or more copies of vectors.

[0026] In other examples, the recovery agent 126, instead of the recovery API 128, may contain a different type of interface that client devices can access to initiate recovery requests.

[0027] In some examples, the client device 130 includes a recovery user interface (UI) 150, such as a graphical user interface (GUI), a command-line interface, or another type of interface. A user of the client device 130 can enter requests into the recovery interface 150 to initiate a database recovery operation. In response to the requests entered into the recovery user interface 150, the client device 130 calls a routine of the recovery API 128 to perform the database recovery.

[0028] Once the recovery agent 126 has created a recovered vector database (which is the target version of the source vector database 102 sought by the recovery request), the recovery agent 126 sends information about the recovered database 152 to the client device 130, which can be viewed in the recovery interface 150. The recovered database information 152 may include a name (or other identifier) ​​of the recovered vector database. The user of the client device 130 can then make database queries against the recovered vector database to view its contents (as displayed in the recovery UI 150).In this way, the user can determine whether the recovered vector database is indeed a suitable version of the source vector database 102 that he can use for the recovery of the source vector database 102.

[0029] Fig. Figure 1 is a block diagram of an example for retrieving a recovered vector database 202 using the journal vector database 104 and the backup vector database 106. The recovery agent 126 receives a request 204 to initiate a database recovery operation, for example, from the client device 130. Fig. In response to request 204, the recovery agent 126 sends a recovery query 206 to the journal vector database 104 and the backup vector database 106. For example, the recovery query 206 might include a filter that searches for vectors of transactions up to a specific transaction. In other words, vectors that meet the filter are those within the specified transaction and all transactions prior to that specific transaction.

[0030] In the example of Fig. It was assumed that vectors V5 and V6 were originally written to source vector database 102 in transaction TR1, and that delete event 112 (which deletes V5) and add event 116 (which adds VN) occurred in transaction TR2 after TR1. Furthermore, vectors V1-V4 are added to source vector database 102 in one or more transactions after transaction TR2, and change event 114 is performed in a transaction after transaction TR2.

[0031] The filter in recovery query 206 can search for vectors of transactions up to TR2, which in this example include transactions TR1 and TR2. In such an example, in response to recovery query 206, journal vector database 104 outputs journal entries 132 and 136, which satisfy the filter in recovery query 206, as part of a first result 208 obtained from journal vector database 104. In response to recovery query 206, backup vector database 106 outputs copies of vectors V5 and V6, which satisfy the filter in recovery query 206, as part of a second result 210.

[0032] Recovery Agent 126 then merges (at 212) the first result 208 and the second result 210. As part of the merge, Recovery Agent 126 determines the types of I / O operations to perform based on the metadata in journal entries 132 and 136 of the first result 208. In the example shown, the metadata of journal entry 132 indicates that vector V5 is deleted, and the metadata of journal entry 134 indicates that vector VN is added. The recovered vector database 202 contains vector V6 and vector VN; vector V5 is not included in the recovered vector database 202 because vector V5 was deleted.

[0033] Recovery agent 126 then sends recovered database information (e.g., 152 in Fig. ), which relate to the restored vector database 202, to the client device 130. A user (or other entity) on the client device 130 can perform database queries with respect to the restored vector database 202.

[0034] Fig. is a block diagram of a non-transient machine-readable or computer-readable storage medium 300 on which machine-readable instructions are stored which, when executed, cause a system to perform various tasks. The system can be implemented with one or more computers and can, for example, be the replication controller 108 and the backup controller 110 of Fig. contain.

[0035] The machine-readable instructions contain instructions for replicating journal write events (302) to replicate a write event to a journal database, such as the journal vector database 104 or another type of journal database. The write event involves a change (adding, modifying, or deleting) to a source database (e.g., the source vector database 102). Fig. or another type of source database) that contains data points arranged in a multidimensional space. The position of a data point in the multidimensional space is based on the values ​​of the attributes contained in the data point. When the write event is replicated, a journal data point is added to the journal database. The journal data point (e.g., journal entry 132, 134, or 136 of Fig. The journal data point contains write data of the write event and metadata indicating a write operation associated with that write data. The journal data point metadata can specify the type of write operation, selected from a delete, add, or modify operation. One or more journal data points from the journal database must be backed up to a backup database (e.g., backup vector database 106 of [reference missing]). Fig. or another type of backup database) that stores copies of the data points of the source database.

[0036] The machine-readable instructions contain instructions for querying journal and backup databases (304) to obtain, based on receiving a restore query associated with restoring data from the source database, a first result from the journal database and a second result from the backup database, according to a filter in the restore query. The first result may contain zero or more journal data points from the journal database, and the second result may contain zero or more copies of data points from the backup database.

[0037] The machine-readable instructions contain merge instructions 306 to merge the first and second results to produce a recovery result in response to the recovery query. The recovery result can contain a recovered database that can be accessed with one or more database queries.

[0038] In some examples, the machine-readable instructions can reproduce the one or more journal data points in the journal database in the backup database by applying one or more write operations (e.g., add operations, modify operations, or delete operations) indicated by the one or more journal data points to the backup database.

[0039] In some examples, the filter in the recovery query specifies a subset of the data points to be recovered in the source database, e.g., data points in transactions up to a specific transaction identified by a transaction identifier in the recovery query filter.

[0040] In some examples, if the filter in the recovery query includes a transaction identifier that identifies an initial transaction, the first result obtained from the journal database contains journal data points associated with the initial transaction (and any previous transaction(s) prior to the initial transaction), and the second result obtained from the backup database contains copies of data points associated with the initial transaction (and any previous transaction(s) prior to the initial transaction).

[0041] In some examples, the machine-readable instructions, in response to the restore query, can retrieve an initial journal data point from the journal database, which is associated with a delete event that removes an initial data point from the source database, and retrieve a copy of the initial data point from the backup database. As part of the merge process, the machine-readable instructions can exclude the copy of the initial data point from the restore result based on the initial journal data point.

[0042] In some examples, the machine-readable instructions, in response to the restore query, can retrieve an initial journal data point from the journal database, associated with an add event that adds a new data point to the source database, and retrieve initial copies of data points from the backup database. These initial copies of the source database data points do not include the new data point. As part of the merge process, the machine-readable instructions can add the new data point to the restore result based on the initial journal data point.

[0043] In some examples, in response to the restore query, the machine-readable instructions can retrieve an initial journal data point from the journal database, associated with a modification event that modifies an initial data point in the source database, and retrieve copies of data points from the source database from the backup database, with the retrieved copies of data points from the source database containing the initial data point. As part of the merge process, the machine-readable instructions can modify the initial data point according to the initial journal data point and include the modified initial data point in the restored database.

[0044] In some examples, the recovery query is generated based on a client device's access to an interface. One example of such an interface is the Recovery API 128. Fig. .

[0045] In some examples, the recovery result includes a recovered database, and the machine-readable instructions can display recovered database information related to the recovered database on a client device user interface. The machine-readable instructions can also receive a database query based on user interface input, retrieving data from the recovered database.

[0046] In some examples, the recovery result is generated without first restoring journal data points from the journal database to the backup database.

[0047] Fig. This is a block diagram of a System 400, which can be implemented with one or more computers. The System 400 includes a Hardware Processor 402 (or multiple hardware processors). A hardware processor can be a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry.

[0048] The System 400 includes a storage medium 404 on which machine-readable instructions are stored that can be executed on the hardware processor 402 to perform various tasks. Machine-readable instructions executable on a hardware processor can refer to instructions that can be executed on a single hardware processor or on multiple hardware processors.

[0049] The machine-readable instructions in storage medium 404 contain instructions 406 for replicating a write event to a journal database, where the write event involves a modification of a source database containing data points arranged in a multidimensional space. Replicating the write event adds a journal data point to the journal database, and the journal data point contains write data from the write event and metadata indicating a write operation associated with that write data. One or more journal data points from the journal database are to be reproduced in a backup database that stores copies of the data points from the source database.

[0050] The machine-readable instructions in the storage medium 404 contain instructions 408 for querying journal and backup databases to obtain, based on the receipt of a recovery query associated with the recovery of data from the source database, a first result from the journal database and a second result from the backup database according to a filter in the recovery query.

[0051] The machine-readable instructions in storage medium 404 contain instructions for creating a recovered database 410 by merging the first and second results to produce a recovered database in response to the recovery query. Merging the first and second results involves applying a write operation specified by metadata of a journal data point in the journal database.

[0052] In some examples, the first result includes fewer than all journal data points in the journal database.

[0053] In some examples, the recovery query is received in response to a request to a client device, and the machine-readable instructions can provide the client device with recovered database information related to the recovered database. The machine-readable instructions can also receive a database query from the client device to extract data from the recovered database.

[0054] Fig. This is a block diagram of a process 500 according to some examples, which is controlled, for example, by the replication controller 108 and the backup controller 110. Fig. can be carried out.

[0055] Process 500 involves replicating (at 502) a write event to a journal vector database, wherein the write event involves a modification of a source vector database containing vectors arranged in a multidimensional space, the position of a vector in the multidimensional space being based on values ​​of attributes contained in the vector, the replication of the write event to the journal vector database adding a journal entry, the journal entry containing write data of the write event and metadata indicating a write operation associated with the write data, and one or more journal entries being reproduced from the journal vector database to a backup vector database that stores copies of the vectors of the source vector database.

[0056] Based on receiving a recovery query associated with restoring data from the source vector database, process 500 involves retrieving (at 504) a first result from the journal vector database and a second result from the backup vector database according to a filter in the recovery query, where the first result contains a first journal entry from the journal vector database and the second result contains a copy of a vector from the backup vector database.

[0057] Process 500 involves merging (at 506) the first result and the second result to produce a recovered vector database in response to the recovery query, wherein merging the first result and the second result involves applying a write operation specified by metadata of the first journal entry.

[0058] Examples of a client device (e.g., 130 in Fig. ) can be any or a combination of the following devices: a desktop computer, a notebook, a smartphone, or any other type of electronic device.

[0059] A “network” (e.g., 120 in Fig. ) can refer to a local area network (LAN), a wide area network (WAN), the Internet, a storage area network (SAN), or any other type of communication structure.

[0060] A storage medium (e.g., 300 in Fig. in Fig.The storage device may include any or a combination of the following: a semiconductor storage device such as dynamic or static random-access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; a magnetic disk such as a hard disk, floppy disk, and removable disk; another magnetic medium, including tape; an optical medium such as a compact disc (CD) or digital video disc (DVD); or some other type of storage device. It should be noted that the instructions described above may be provided on a single computer- or machine-readable storage medium, or alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system, possibly with multiple nodes.Such a computer- or machine-readable storage medium or media are considered part of an article (or manufactured item). An article or manufactured item can refer to any single component produced or to multiple components. The storage medium or media can be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded for execution over a network.

[0061] In this disclosure, the use of the term "a," "an," or "the" includes the plural forms unless the context clearly indicates otherwise. Similarly, the terms "includes," "including," "comprises," "have," or "have," when used in this disclosure, specify the presence of the elements indicated but do not exclude the presence or addition of other elements.

[0062] The foregoing description includes numerous details to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may involve modifications and variations of the details described above. It is intended that the accompanying claims cover such modifications and variations.

Claims

[1] Non-transitory machine-readable storage medium containing instructions which, when executed, cause a system to: Replacing a write event to a journal database, wherein the write event involves a modification of a source database comprising data points arranged in a multidimensional space, wherein a position of a data point in the multidimensional space is based on values ​​of attributes contained in the data point, wherein the replication of the write event adds a journal data point to the journal database, wherein the journal data point comprises write data of the write event and metadata indicating a write operation associated with the write data, and wherein one or more journal data points are to be reproduced from the journal database to a backup database that stores copies of the data points of the source database; Based on receiving a restore query associated with restoring data from the source database, a first result is obtained from the journal database and a second result from the backup database, according to a filter in the restore query; and Merging the first result and the second result to generate a recovery result in response to the recovery request. [2] Non-transitory machine-readable storage medium according to claim 1, wherein the recovery result comprises a recovered database which can be accessed by one or more database queries. [3] Non-transitory machine-readable storage medium according to claim 1, wherein the source database comprises a source vector database, and the data points of the source vector database comprise vectors, wherein the journal database comprises a journal vector database, and wherein the backup database comprises a backup vector database. [4] Non-transitory machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the system to: Reproducing one or more journal data points in the backup database by applying one or more write operations, indicated by the one or more journal data points, to the backup database. [5] Non-transitory machine-readable storage medium according to claim 1, wherein the filter in the recovery query specifies a subset of the data points to be recovered in the source database. [6] Non-transitory machine-readable storage medium according to claim 5, wherein the filter in the recovery query comprises a transaction identifier that identifies a first transaction, wherein the first result obtained from the journal database comprises journal data points associated with the first transaction, and the second result obtained from the backup database comprises copies of data points associated with the first transaction. [7] Non-transitory machine-readable storage medium according to claim 6, wherein the first result obtained from the journal database further comprises journal data points associated with one or more transactions prior to the first transaction, and the second result obtained from the backup database further comprises data points associated with the one or more transactions prior to the first transaction. [8] Non-transitory machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the system to: in response to the recovery request, A first journal data point is obtained from the journal database, which is associated with a deletion event that deletes a first data point from the source database, and Retrieve a copy of the first data point from the backup database; and As part of the merge, the copy of the first data point from the recovery result is to be excluded based on the first journal data point. [9] Non-transitory machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the system to: in response to the recovery request, to obtain an initial journal data point from the journal database, which is associated with an add event that adds a new data point to the source database, and copies of data points from the source database are obtained from the backup database, whereby the obtained copies of data points from the source database do not include the new data point; and As part of the merge process, add the new data point to the recovery result based on the first journal data point. [10] Non-transitory machine-readable storage medium according to claim 1, wherein the recovery query is generated based on access to an interface by a client device. [11] Non-transitory machine-readable storage medium according to claim 10, wherein the recovery result comprises a recovered database and the instructions, upon execution, cause the system to: to present restored database information on a user interface (UI) of the client device that relates to the restored database; and Based on an input at the user interface, a database query is received that retrieves data from the restored database. [12] Non-transitory machine-readable storage medium according to claim 1, wherein the recovery result is generated without first restoring journal data points in the journal database to the backup database. [13] System comprising the following: a processor; and a non-transitory storage medium that stores instructions that can be executed on the processor to: Replacing a write event to a journal database, wherein the write event involves a modification of a source database comprising data points arranged in a multidimensional space, wherein the location of a data point in the multidimensional space is based on values ​​of attributes contained in the data point, wherein the replication of the write event adds a journal data point to the journal database, wherein the journal data point comprises write data of the write event and metadata indicating a write operation associated with the write data, and wherein one or more journal data points are to be reproduced from the journal database to a backup database that stores copies of the data points of the source database; Based on receiving a restore query associated with restoring data from the source database, a first result is obtained from the journal database and a second result from the backup database, according to a filter in the restore query; and Merging the first result and the second result to produce a recovered database in response to the recovery query, wherein merging the first result and the second result involves applying a write operation specified by metadata of a journal data point in the journal database. [14] System according to claim 13, wherein the first result comprises fewer than all journal data points in the journal database. [15] System according to claim 13, wherein the recovery query is received in response to a request at a client device and the instructions are executable on the processor to: Providing information about the restored database to the client device that relates to the restored database; and Receive a database query from the client device to extract data from the restored database. [16] System according to claim 13, wherein the source database comprises a source vector database, and the data points of the source vector database comprise vectors, wherein the journal database comprises a journal vector database, and wherein the backup database comprises a backup vector database. [17] System according to claim 13, wherein the instructions are executable on the processor to: in response to the recovery request, A first journal data point is obtained from the journal database, which is associated with a deletion event that deletes a first data point from the source database, and Retrieve a copy of the first data point from the backup database; and As part of the merge, the copy of the first data point from the restored database is to be excluded based on the first journal data point. [18] System according to claim 13, wherein the instructions are executable on the processor to: in response to the recovery request, to obtain an initial journal data point from the journal database that is associated with a change event that modifies an initial data point in the source database, and copies of data points from the source database are obtained from the backup database, wherein the obtained copies of data points from the source database contain the first data point; and As part of the merging process, modify the first data point to match the first journal data point and include the modified first data point in the restored database. [19] Procedure comprising the following: Replacing a write event into a journal vector database by a system comprising a hardware processor, wherein the write event involves a modification of a source vector database comprising vectors arranged in a multidimensional space, wherein a position of a vector in the multidimensional space is based on values ​​of attributes contained in the vector, wherein the replication of the write event adds a journal entry to the journal vector database, wherein the journal entry comprises write data of the write event and metadata indicating a write operation associated with the write data, and wherein one or more journal entries are to be reproduced from the journal vector database to a backup vector database that stores copies of the vectors of the source vector database; based on receiving a recovery query associated with restoring data from the source vector database, obtaining a first result from the journal vector database and a second result from the backup vector database by the system according to a filter in the recovery query, wherein the first result comprises a first journal entry from the journal vector database, and the second result comprises a copy of a vector from the backup vector database; and The system combines the first result and the second result to produce a recovered vector database in response to the recovery query, wherein the combining of the first result and the second result involves the application of a write operation specified by metadata of the first journal entry. [20] Method according to claim 19, wherein the first result comprises fewer than all journal entries in the journal vector database.

Images