Using probabilistic data structures to reduce requests

Abstract

Disclosed are techniques involving providing and using probabilistic data structures to at least reduce requests between database nodes. In various embodiments, a first database node processes a database transaction involving writing a set of database records to a cache in a memory of the first database node. As part of processing the database transaction, the first database node may insert a set of database keys corresponding to the set of database records in a set of probabilistic data structures. The first database node may send the set of probabilistic data structures to a second database node to enable the second database node to determine whether to request database records associated with the database keys from the first database node.

Description

Background Art Technical Field

[0002] The disclosure relates generally to database systems, and more particularly, to reducing calls / requests between database nodes using probabilistic data structures.

[0003] Description of Related Technology

[0004] Modern database systems routinely implement management systems that enable users to store collections of information in an organized manner that can be efficiently accessed and manipulated. In some cases, these management systems maintain a log structured merge tree (LSM tree) with multiple levels, each level storing information as key-value pairs. LSM trees typically include two high-level components: an in-memory cache and a persistent store. In operation, a database system initially writes database records to an in-memory cache before later flushing them to persistent storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram illustrating example elements of a system having a database node including a probabilistic data structure according to some embodiments.

[0006] Figure 2A is a block diagram illustrating example elements of a probabilistic data structure according to some embodiments.

[0007] Figure 2B is a block diagram illustrating example elements of a cache line structure of a probabilistic data structure according to some embodiments.

[0008] Figure 3 is a block diagram illustrating example elements of a transaction engine capable of inserting database keys in a cache line structure according to some embodiments.

[0009] Figure 4 is a block diagram illustrating example elements of interaction between database nodes having a probabilistic data structure according to some embodiments.

[0010] Figure 5 is a block diagram illustrating example elements of a transaction engine that processes long-running transactions according to some embodiments.

[0011] Figure 6 is a flow chart illustrating an example method involving generating and providing a set of probabilistic data structures according to some embodiments.

[0012] Figure 7 is a flow chart illustrating an example method involving the use of a set of probabilistic data structures according to some embodiments.

[0013] Figure 8is a flow chart illustrating an example method involving processing long-running transactions according to some embodiments.

[0014] Fig. 9 is a block diagram illustrating an example computer system according to some embodiments.

[0015] The disclosure includes references to "one embodiment" or "an embodiment." The appearance of the phrase "in one embodiment" or "in an embodiment" does not necessarily refer to the same embodiment. The particular features, structures, or characteristics may be combined in any suitable manner consistent with the disclosure.

[0016] In the disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. The formula—[the entity] is configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, the formula is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform some tasks even if the structure is not currently being operated. "A network interface configured to communicate over a network" is intended to cover, for example, an integrated circuit having circuits that perform that function during operation, even if the integrated circuit in question is not currently being used (e.g., a power source is not connected to it). Thus, an entity described or recited as "configured to" perform some tasks refers to a physical thing, such as a device, a circuit, a memory storing program instructions executable to implement a task, etc. The phrase is not used herein to refer to something intangible. Thus, the "configured to" construct is not used herein to refer to a software entity such as an application programming interface (API).

[0017] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA would not be considered "configured to" perform some particular function, although it may be "configurable to" perform that function, and may be "configured to" perform that function after being programmed.

[0018] As used herein, the terms "first," "second," and the like are used as labels for the nouns that precede them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise specified. For example, in a processor having eight processing cores, the terms "first" and "second" processing cores may be used to refer to any two of the eight processing cores. In other words, the first and second processing cores are not limited to processing cores 0 and 1, for example.

[0019] As used herein, the term "based on" is used to describe one or more factors that influence a determination. The term does not exclude the possibility that additional factors may influence a determination. That is, a determination may be based only on specified factors or on specified factors as well as other unspecified factors. Consider the phrase "determining A based on B." The phrase specifies that B is a factor used to determine A or influences the determination of A. The phrase does not exclude that the determination of A may also be based on some other factor, such as C. The phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is therefore synonymous with the phrase "based at least in part on." DETAILED DESCRIPTION

[0020] In some implementations, a database system that maintains an LSM tree writes records to a memory cache of the LSM tree before writing these records to a persistent storage associated with the LSM tree. In some methods, the database system includes a single database node responsible for writing records to the LSM tree. In other methods, the database system includes multiple database nodes that write records to the LSM tree while also reading records from the LSM tree. These database nodes may share a common persistent storage, but each has its own in-memory cache. However, in this scenario, records written to its in-memory cache by a database node are not visible to other database nodes until these records are refreshed to the common persistent storage. The inventors have recognized that this arrangement leads to certain inefficiencies. Consider a first database node that is processing a transaction involving access to the latest version of a particular record. The record may be stored in a memory cache of a second database node and is therefore not visible to the first database node. As a result, the first database node must issue a request to the second database node in order to determine whether the second database node has the latest version of the record.

[0021] In many cases, the size of the in-memory cache of a database node may be very small (e.g., 2GB or 10GB), and therefore only a limited number of records can be stored at any point in time. As a result, even if a database node generates many record requests, many (if not most) of these requests will not result in records being returned. Therefore, although the requested record is not usually present in the in-memory cache of a second database node, the first database node still needs to issue a request to the second database node to see if the record exists. The inventors have recognized that this slows down the overall operation of the database system because the database nodes spend a lot of time issuing record requests to each other, even if these requests do not usually result in records being returned. The public text solves this technical problem of consuming too many resources due to sending too many requests between database nodes for records that are not usually present in other database nodes.

[0022] The disclosure describes techniques for implementing a probabilistic data structure that enables a database node to determine whether to request a database record from another database node. As used herein, the term "probabilistic data structure" refers to a data structure that stores information indicating that a particular item does not exist or may exist at a particular location within a system. For example, a probabilistic data structure may store information indicating that a database record for a particular database key does not exist or may exist in a cache in the memory of a certain database node. Bloom filters, cuckoo filters, structures associated with hyperlogs, and surf attempts are all examples of probabilistic data structures.

[0023] In various embodiments described below, the system includes multiple database nodes that can write database records to their own local memory cache before refreshing those database records to a persistent storage shared by those database nodes. When writing database records to the memory cache, in various embodiments, the database node inserts the database key of the database record into the probabilistic data structure. As used herein, the phrase "inserting the database key into the probabilistic data structure" broadly refers to modifying the information in the probabilistic data structure based on the database key. The database key itself does not have to be stored in the probabilistic data structure. For example, a set of hash functions can be applied to the database key to derive a set of hash values. These hash values ​​can be used to set the bits in the probabilistic data structure.

[0024] In order to insert the database key into the probabilistic data structure, in various embodiments, the database node applies a set of hash functions to derive a set of corresponding hash values. One of the hash values ​​can be used to select a portion or "cache line" within the probabilistic data structure. The remaining hash values ​​can be used to set the bits within the cache line to represent the database key. During operation, the database node can insert various database keys into one or more probabilistic data structures. In some embodiments, the database node inserts the database key into the probabilistic data structure until a threshold number of keys have been inserted into the probabilistic data structure (the threshold can correspond to some maximum size of the data structure; this can be a system design choice or configuration setting in various embodiments). The database node can then create another probabilistic data structure and begin inserting the database key therein. Therefore, in various cases, the database node can create a stack of probabilistic data structures, each of which is associated with a different set of database keys.

[0025] The database node can provide the probabilistic data structure from the stack to the second database node. In some embodiments, the database node provides the probabilistic data structure from the stack as a part of the response to the request for the database record associated with the specified database key from the second database node. In some embodiments, the database node can only provide those probabilistic data structures created or changed since the second database node last received the probabilistic data structure to the second database node. For example, when the second database node initially communicates with the first database node, the first database node can provide all probabilistic data structures from its stack. Afterwards, the first database node can add a new probabilistic data structure to the stack. When the second database node sends a request for the database record to the first database node, the first database node can provide a new probabilistic data structure, but does not provide other probabilistic data structures from the stack as a part of the response to the request.

[0026] The database node receiving the probabilistic data structure can use those probabilistic data structures to determine whether to request a database record from another database node (e.g., the owner of those probabilistic data structures). During operation, the database node can receive a request to process a database transaction, which involves accessing a database record of a specified database key. However, the specified database key may fall within the key space managed by the second database node. In this way, the previous database node (the first database node) can check the probabilistic data structure associated with the second database node to determine whether it should request a database record from the second database node. In order to check the probabilistic data structure, in some embodiments, the first database node applies the same set of hash functions used by the second database node to insert the database key into the probabilistic data structure to the specified database key. If the hash value derived for the specified database key matches the bit set in the probabilistic data structure, the first database node can determine that there may be a database record for the specified database key at the second database node; otherwise, the first database node determines that there is no database record for the key at the second database node.

[0027] These techniques may be superior to existing methods because they allow database nodes to communicate in a more efficient manner involving reducing the number of database record requests sent between database nodes. In previous methods, a database node would issue a request for a database record to another database node if the database key for the record fell within the key space of another database node. By using the probabilistic data structures discussed in the open text, a database node can determine whether to issue a request for a database record to another database node. If the probabilistic data structure does not have an information set indicating a particular database key, the database node knows that the database record for the particular database key does not exist at the other database node, and therefore does not have to issue a request to the other database node.

[0028] These techniques may also provide additional advantages. In various cases, a database system may have multiple processors that interact with cache lines that may correspond to probabilistic data structures. When inserting a database key into a probabilistic data structure in a non-single cache line approach, multiple hash values ​​for the key may map to different cache lines. Updating bits of the probabilistic data structure may occur through an atomic compare and swap operation that requires a processor to obtain ownership of a cache line while preventing other processors from updating the cache line. As a result, when a key hash value maps to multiple cache lines, the processor must contend for ownership of these cache lines multiple times in a concurrent system. This may result in more processor stalls (waiting for ownership of cache lines) and reduce the performance of inserting keys into the probabilistic data structure. In a single cache line approach, all key hash values ​​map to the same hardware cache line. This allows the processor to seek ownership of only a single cache line instead of multiple cache liens. Therefore, the processor may spend less time waiting for the ability to insert a database key. Reference will now be made to Figure 1 Exemplary applications of these techniques are discussed.

[0029] Now turn to Figure 1 , a block diagram of system 100 is shown. System 100 includes a set of components that can be implemented via hardware or a combination of hardware and software routines. In the illustrated embodiment, system 100 includes a database 110 and a set of database nodes 120A-C. As further described, database nodes 120A-C each include an in-memory cache 130 (which stores corresponding database records 135A-C) and a set of probabilistic data structures 140. In some embodiments, system 100 can be implemented in a manner different from that shown. For example, system 100 can include more or fewer database nodes 120.

[0030] In various embodiments, system 100 implements platform services that allow users of the service to develop, run, and manage applications. As an example, system 100 can be a multi-tenant system that provides various functions to multiple users / tenants hosted by a multi-tenant system. Therefore, system 100 can execute software routines from various different users (e.g., providers and tenants of system 100), and provide code, web pages, and other data to users, databases (e.g., database 110), and other entities associated with system 100. As shown, system 100 includes database nodes 120A-C, which interact with database 110 to store and access the data of users associated with system 100.

[0031] In various embodiments, database 110 is a collection of information organized in a manner that allows access, storage and manipulation of this information. Therefore, database 110 may include support software that allows database node 120 to perform operations (e.g., access, storage, etc.) on the information in database 110. As shown, database 110 is shared between database nodes 120A-C so that the database record 135 written by a database node 120 can be accessed by other database nodes 120. In some embodiments, database 110 is connected together on a network (e.g., storage connection network (SAN)) and configured as a single or multiple storage device for redundant storage information to prevent data loss. These storage devices can store data durably, and therefore database 110 can be used as persistent storage.

[0032] In various embodiments, database 110 implements a portion of a log structured merge tree (LSM tree) having multiple levels of database records 135. As previously described, the LSM tree can include two high-level portions: an in-memory portion and a disk portion. One or more levels of the LSM tree can include database records 135 written to the in-memory cache 130. The remaining levels of the LSM tree can include database records 135 written to database 110. Thus, in-memory caches 130A-C can facilitate the in-memory portion of the LSM tree, while database 110 facilitates the disk portion of the LSM tree.

[0033] In various embodiments, database node 120 is hardware, software or a combination thereof that can provide database services such as data storage, data retrieval and data manipulation. These database services can be provided to other components within system 100 or components outside system 100. As shown, database node 120B receives database transaction request 105--the request may be received from an application server (not shown) attempting to access a set of database records 135. As an example, database transaction request 105 can specify an SQL SELECT command that selects one or more rows from one or more database tables. The content of the row can be defined in database record 135, and therefore database node 120 can return one or more database records 135 corresponding to one or more table rows selected. In some cases, database transaction request 105 can instruct database node 120 to write one or more database records 135 for LSM tree. In various embodiments, before refreshing these database records to database 110, database node 120 initially writes database record 135 to its memory cache 130.

[0034] In various embodiments, the in-memory cache 130 is a buffer that stores data in memory (eg, random access memory (RAM)) of the database node 120. TM Memstore may be an example of an in-memory cache 130. As mentioned, a database node 120 may initially write a database record 135 (e.g., in the form of a key-value pair) to its in-memory cache 130. In some cases, the latest / most up-to-date version of a row in a database table may be found in a database record 135 stored in the in-memory cache 130. However, in various embodiments, a database record 135 written to the in-memory cache 130 of a database node 120 is not visible to other database nodes 120. That is, those other database nodes 120 do not know what information is stored in the in-memory cache 130 of the database node 120 without asking. In order to determine whether the in-memory cache 130 is storing a database record 135 associated with a particular key, in some cases, the database node 120 may issue a database record request 122 to the database node 120 of the in-memory cache 130. Such a database record request 122 may include a particular key, and if there is a database record corresponding to the particular key, the database node 120 may return the database record 135.

[0035] In many cases, one database node 120 may return a database record response 124 to another database node 120, where the response does not include a database record 135. This may be because, in various embodiments, the in-memory cache 130 is relatively small in size, and thus the chance that a database record 135 corresponding to a particular key is in the in-memory cache 130 may be relatively low. Therefore, in various embodiments, a database node 120 uses a probabilistic data structure 140 to reduce the amount of database record requests 122 that it issues to another database node 120 that provides those particular probabilistic data structures 140.

[0036] In various embodiments, the probabilistic data structure 140 is a data structure that stores information indicating the probability that a database record 135 exists in the in-memory cache 130 for a corresponding database key. As mentioned, the database node 120 may receive a database transaction request 105 that may involve writing one or more database records 135 to its in-memory cache 130. In some embodiments, when writing the database record 135 to its in-memory cache 130, the database node 120 inserts the database key corresponding to the database record 135 into the probabilistic data structure 140. To insert the database key into the probabilistic data structure 140, in various embodiments, the database node 120 performs one or more hash functions on the database key to derive a set of hash values. These hash values ​​may be used to select a portion of the probabilistic data structure 140 and set information bits within the portion.

[0037] The database node 120 receiving the probabilistic data structure 140 may perform the same one or more hash functions on a database key to determine whether the appropriate bit has been set for the database key. If the appropriate bit has been set for the database key, the database node 120 may determine that a database record 135 for the database key may exist at the in-memory cache 130 of the database node 120 that has been provided with the probabilistic data structure 140. If the appropriate bit has not been set for the database key, the database node 120 may determine that a database record 135 for the database key may not exist at the in-memory cache 130 of the other database node 120. If the database record 135 may exist, then in various embodiments, the database node 120 sends a database record request 122 for the potential database record 135 to another database node 120.

[0038] Now turn to Figure 2A, a block diagram of an example probabilistic data structure 140 is shown. In the illustrated embodiment, the probabilistic data structure 140 includes a cache line structure 210, a key range 220, a number of key values ​​230, an active transaction count 240, an oldest transaction commit number 250, a latest transaction commit number 260, a state 270, and an identifier value 275. In some embodiments, the probabilistic data structure 140 can be implemented in a manner different from that shown. As an example, the probabilistic data structure 140 can include an identifier value. When a database node 120 clears the probabilistic data structure 140, it can provide the identifier value of the probabilistic data structure 140 to another database node 120 so that the other database node 120 can clear its own copy of the probabilistic data structure 140.

[0039] In various embodiments, the cache line structure 210 is a data structure capable of storing information that indicates, for a database key, one of two data points: 1) a database record for the database key is not stored at the in-memory cache 130 associated with the probabilistic data structure 140, or 2) a database record for the database key may be stored at the in-memory cache 130. In various embodiments, the cache line structure 210 includes a plurality of cache lines, each of which may be a series of bits that may be set based on a database key inserted into the cache line structure 210. Based on which bits have been set in a particular cache line, a database node 120 may determine whether a database record for a particular database key may be stored at the in-memory cache 130 of another database node 120. Figure 2B Examples of cache line structure 210 are discussed in more detail.

[0040] In various embodiments, a key range 220 is a set of data values ​​that defines a range of database keys that have been inserted into a probabilistic data structure 140. A database node 120 may use a key range 220 to determine whether to check a probabilistic data structure 140 to see whether a database record 135 for a certain database key may exist at another database node 120. Consider an example in which a database node 120B receives three probabilistic data structures 140 from a database node 120A. The database node 120B may wish to determine whether a database record 135 exists in the in-memory cache 130A for a particular database key identified in a database transaction processed by the database node 120B. Therefore, the database node 120B may check the key range 220 of each of the three probabilistic data structures 140 to determine whether the particular database key falls within the key range 220. If the key range 220 does not include the particular database key, this may allow the database node 120B to save processing resources and time by not checking the cache line structure 210 of the probabilistic data structure 140. In some embodiments, multiple probabilistic data structures 140 may have overlapping key ranges 220 .

[0041] In various embodiments, the number of key values ​​230 is a data value indicating the number of database keys that have been inserted into the probabilistic data structure 140. In some cases, the number of key values ​​230 may be approximately the number of database keys that have been inserted. This may be due to the fact that the value 230 is incremented without any synchronization, and therefore some increments may be lost due to the lack of synchronization. In various embodiments, the probabilistic data structure 140 is capped after a specified number of database keys have been inserted. By capping the number of database keys that can be inserted, the false positive rate of the probabilistic data structure 140 (i.e., the rate at which the probabilistic data structure 140 indicates that a database record 135 is located in the in-memory cache 130 but the database record is not actually present - therefore, the database record 135 "may" be located in the in-memory cache 130) can be maintained at a target rate (e.g., 1%), because the insertion of database keys can incrementally increase the false positive rate. Therefore, the number of key values ​​230 can be used to determine whether a specified number of database keys have been inserted. After the number of key values ​​230 identifies values ​​that match or exceed a specified number of database keys, the database node 120 may prevent the insertion of additional database keys and may generate another probabilistic data structure 140 for database key insertions.

[0042] In various embodiments, the active transaction count 240 is a data value indicating the number of transactions that are still active after inserting at least one database key into the probabilistic data structure 140. For example, the database node 120 may receive a database transaction request 105 to perform a database transaction. As part of processing the database transaction, the database node 120 may insert the database key into the probabilistic data structure 140. In response to inserting the database key, in various embodiments, the database node 120 increments the active transaction count 240. Continuing with the example, the database node 120 may receive another database transaction request 105 to perform a second database transaction. As part of processing the second database transaction, the database node 120 may insert the database key into the probabilistic data structure 140. In response to inserting the database key, the database node 120 may increment the active transaction count 240 to indicate two active transactions that have inserted at least one key into the probabilistic data structure 140. In response to committing the first database transaction, in various embodiments, the database node 120 then decrements the active transaction count 240. When the second database transaction commits, the database node 120 may decrement the active transaction count 240 again. In various embodiments, a database transaction may be committed, wherein the database node 120 acknowledges that the database transaction has been completed. As a result of committing the transaction, database records 135 associated with the committed transaction may be available to other database nodes 120 via record requests 122. When a database transaction is aborted, the active transaction count 240 may also be decremented.

[0043] Although the active transaction count 240 identifies a value greater than zero, in various embodiments, the probabilistic data structure 140 cannot be purged. That is, the purge engine can reclaim the probabilistic data structure 140 only after there are no active database transactions associated with the probabilistic data structure 140.

[0044] In various embodiments, the oldest transaction commit number 250 is a data value indicating the oldest committed transaction (in time) that inserted at least one database key into the probabilistic data structure 140. That is, when a database node 120 commits a transaction, a transaction commit number may be assigned to the transaction, which may be based on when the transaction was committed. Thus, a transaction that is committed earlier than another transaction has a smaller / lower transaction commit number. In various embodiments, the oldest transaction commit number 250 is used by the database node 120 to determine whether to check the database key of the probabilistic data structure 140. For example, if the database node 120 is processing a transaction snapshot having a value less than the oldest transaction commit number 250, the database node 120 may not check the corresponding probabilistic data structure 140.

[0045] In various embodiments, the latest transaction commit number 260 is a data value indicating the latest committed transaction (in time) that inserted at least one database key into the probabilistic data structure 140. The first database node 120 can use the latest transaction commit number 260 to determine which probabilistic data structures 140 to send to the second database node 120. For example, when the second database node 120 sends a request for database records to the first database node 120, the request can identify a transaction commit number. The transaction commit number can correspond to the latest latest transaction commit number 260 of the probabilistic data structure 140 that the second database node 120 previously received from the first database node 120. The first database node 120 can send a response including a probabilistic data structure 140 having a latest transaction commit number 260 that is greater than the transaction commit number specified in the request of the second database node 120.

[0046] In various embodiments, state 270 is a data value indicating which stage the probabilistic data structure 140 is in during its life cycle. In various embodiments, there are three different stages in the life cycle of the probabilistic data structure 140: open, closed and unused. The probabilistic data structure 140 can initially start at the "open" stage of its life cycle, and therefore has an "open" state 270. When in the "open" stage of its life cycle, the probabilistic data structure 140 can be used for inserting the database key generated by the database transaction currently running. In various embodiments, after the database key of a specified number has been inserted into the probabilistic data structure 140, its state 270 is updated to "closed". When in the "closed" stage, the probabilistic data structure 140 can continue to be used by the database node 120, but can no longer insert the database key therein. As a result, the database transaction currently running can continue to be inserted into the new probabilistic data structure 140.

[0047] In various embodiments, the identifier value 275 is a value that identifies the probabilistic data structure 140 from other probabilistic data structures 140. In various cases, the identifier value 275 can enable the database node 120 to refresh the obsolete copy of the probabilistic data structure 140, because the probabilistic data structure 140 can be updated and shared many times during its existence. As an example, after the probabilistic data structure 140 has been provided to another database node 120, the transaction may continue to insert the key into the probabilistic data structure 140. If the updated probabilistic data structure 140 is shared with another database node 120 again, the other database 120 can use the identifier value 275 to identify the older version of the probabilistic data structure 140, so that it can be replaced with an updated version. In some embodiments, the database node 120 can include the identifier value 275 as a part of the database record request 122, so that the receiving database node 120 can determine whether the corresponding probabilistic data structure 140 has been updated and should be returned as a part of the database record response 124.

[0048] In some embodiments, after the latest transaction commit number 260 of the probabilistic data structure 140 exceeds the refresher transaction commit number (which can identify the latest transaction flushed to the database 110), the purge engine executing on the corresponding database node 120 begins the process of retiring the probabilistic data structure 140. The purge engine can transition the probabilistic data structure 140 to an "unused" state. Therefore, the state 270 can be updated to reflect that the probabilistic data structure 140 is in an unused state.

[0049] Now turn to Figure 2B, a block diagram of an example cache line structure 210 is shown. In the illustrated embodiment, the cache line structure 210 includes cache lines 280A-D, each having a corresponding cache line portion 285. In some embodiments, the cache line structure 210 can be implemented differently than shown. Although the cache lines 280A-D are depicted as unconnected, in some embodiments, the cache lines 280A-D are part of a contiguous segment of memory, where a given cache line 280 can be identified by an offset value and can span a set number of bytes in the segment.

[0050] In various embodiments, each of the cache lines 280 is a collection of bits that can be set to insert a database key into a portion of the probabilistic data structure 140. Thus, the cache line portion 285 can be a bit value. In various embodiments, the cache lines 280 are hardware constructs; however, in other embodiments, the cache lines 280 can be implemented in software. As shown, there are five cache line portions 285 (i.e., five bits) per cache line 280, but in other embodiments the number of bits per cache line 280 may be different. In some cases, the number of bits per cache line 280 may be based on the desired size of the cache line structure 210 and the desired false alarm rate. As described with respect to Figure 3 Discussed in more detail, an initial hash function may be performed to generate a hash value that may be used to select a cache line 280 (e.g., cache line 280A), and then a set of hash functions may be performed to generate hash values ​​that may be used to set bits of that cache line 280 (e.g., setting bits of portions 285A and 285C). The number of bits that are set may be based on the characteristics of the system 100. For example, the system 100 may provide an instruction that allows simultaneous loading from 8 different locations. Thus, 8 bits may be set within the cache line 280 for a given database key in order to benefit from the characteristics of the instruction.

[0051] Now turn to Figure 3 , a block diagram of an example transaction engine 310 is shown. In the illustrated embodiment, the transaction engine 310 includes a hash function 315. As further described, the transaction engine 310 interacts with the in-memory cache 130 and the cache line structure 210. In some embodiments, the transaction engine 310 may be implemented differently than shown.

[0052] In various embodiments, the transaction engine 310 is a set of software routines executable to process database transactions, which may include inserting a database record 135 into the in-memory cache 130 and inserting a corresponding database key 320 into the cache line structure 210 of the probabilistic data structure 140. Figure 4As discussed in more detail, as part of processing a database transaction, the transaction engine 310 may issue database record requests 122 to other transaction engines 310 at other database nodes 120 to potentially receive database records 135 from caches 130 in other memories.

[0053] As depicted, the transaction engine 310 may receive a database transaction request 105. In various cases, processing the database transaction request 105 may involve writing one or more database records 135 to the in-memory cache 130. As the database records 135 are written to the in-memory cache 130, in various embodiments, the transaction engine 310 inserts the corresponding database keys 320 into the cache line structure 210. In some embodiments, the transaction engine 310 may perform a batch insert of the database keys 320 for the transaction into the probabilistic data structure 140 and then initiate a transaction commit—in some cases, the batch insert is performed as part of a pre-commit phase, where the database node 120 performs a set of actions before ultimately committing the transaction.

[0054] In order to insert the database key 320 into the cache line structure 210, the transaction engine 310 can perform a set of hash functions 315 on the database key 320 to derive a set of hash values. In various embodiments, the hash function 315 is a function that can be executed to map data of any size (e.g., the database key 320) to a fixed size value. For example, the hash function 315 can correspond to a hash function found in the MurmurHash family. When the database key 320 is inserted into the cache line structure 210, the transaction engine 310 can initially perform a hash function 315 on the database key 320 to derive a hash value that can be used to select a cache line 280. As shown, the transaction engine 310 performs a hash function 315A on the database key 320 to derive a hash value 330A. The hash value 330A is used to select a cache line 280C. As a result, the transaction engine 310 can set a bit within the cache line 280C. To determine which bits to set, transaction engine 310 may perform additional hash functions 315 to derive additional hash values ​​for setting bits in cache line 280. As shown, transaction engine 310 performs hash functions 315B and 315C on database key 320 to derive hash values ​​330B and 330C, respectively. Hash values ​​330B and 330C are used to set bits within cache line 280C.

[0055] In some embodiments, information indicating a database key range may be inserted into a cache line structure 210. The transaction engine 310 may perform the process discussed above on a prefix portion shared between database keys in a database key range. As a result, the prefix portion may be inserted into the cache line structure 210. The database node 120 may further determine whether to request a database record associated with a key range from another database node 120 by examining the insertion of the prefix portion in the probabilistic data structure 140 received from the other database node 120.

[0056] Now turn to Figure 4 , a block diagram of example database nodes 120A and 120B is shown. In the illustrated embodiment, database nodes 120A and 120B include an in-memory cache 130, probabilistic data structures 140A-C, and a transaction engine 310. As shown, probabilistic data structures 140A and 140B are local to database node 120A because they are generated by database node 120A, while probabilistic data structure 140C is local to database node 120B because it is generated by database node 120B. The illustrated embodiment may be implemented differently than shown—for example, database nodes 120A and 120B may include a purge engine.

[0057] As previously described, database node 120 can provide database services (e.g., data storage) to tenants (e.g., organizations) of system 100. The data of a tenant can define a key space associated with the tenant. In some embodiments, the key space can be divided into multiple key space partitions, each key space partition assigned to a corresponding database node 120. Therefore, database node 120 can only write database records that fall within its assigned key space to its memory cache 130. As a result, the probabilistic data structure 140 generated by database node 120 can correspond to its assigned key space. Therefore, as an example, probabilistic data structures 140A and 140B correspond to the key space of database node 120A, and probabilistic data structure 140C corresponds to the key space of database node 120B.

[0058] When a database node 120 wishes to access a database record 135, it may determine to which keyspace the database record 135 belongs based on its corresponding database key 320. If the database record 135 belongs to the database node 120's own keyspace, it may check its own in-memory cache 130 for the database record 135, and then continue to the database 110 if the record 135 is not in its own in-memory cache 130. If the database record 135 belongs to the keyspace of another database node 120 (e.g., to database node 120A), the previous database node 120 (e.g., database node 120B) may determine whether it has a probabilistic data structure 140 that can be checked for information indicating the database key 320 of the database record.

[0059] Initially, database node 120B may not have any probabilistic data structures 140 from database node 120A. Database node 120B may therefore issue a database record request 122 that identifies a particular database key 320 of a database record 135. In various embodiments, as a side effect of the database record lookup, database node 120A may return a probabilistic data structure 140 to database node 120B as part of a database record response 124. The probabilistic data structure 140 may be returned even if the database record 135 is not found at the in-memory cache 130 of database node 120A. In some embodiments, database node 120B is able to issue a probabilistic data structure specific request for a probabilistic data structure 140 to database node 120A. Database node 120A may initially only generate probabilistic data structure 140A, and therefore, may return it to database node 120B as part of a database record response 124 to the database record request 122.

[0060] Later, database node 120B may wish to access another database record 135 that belongs to the key space assigned to database node 120A. In some embodiments, database node 120B checks probabilistic data structure 140A (which it previously received), determines whether the database key 320 of the database record falls within the key range 220 of probabilistic data structure 140A, and whether the transaction snapshot associated with the database record 135 occurred earlier than the oldest transaction commit associated with probabilistic data structure 140A, which may be identified by oldest transaction commit number 250. In various cases, database node 120B may check one or another or additional parameters to determine whether the probabilistic data structure 140 should be checked.

[0061] If applicable, database node 120B may check probabilistic data structures 140A to determine the likelihood that a database record 135 associated with a particular database key 320 exists at the in-memory cache 130 of database node 120A. If there is a chance, database node 120B may send a database record request 122 to database node 120A. In some embodiments, database record request 122 specifies the latest transaction commit number 260. Database node 120A may use commit number 260 to determine whether any new probabilistic data structures 140 have been created since database node 120B last issued a database record request 122. If there are new probabilistic data structures 140 (e.g., database node 120A may have created probabilistic data structures 140B), those probabilistic data structures 140 may be returned via database record response 124.

[0062] As mentioned, the database node 120 may initially write the database record 135 into its memory cache 130 before flushing the database record 135 to the database 110. The database node 120 may flush the database record 135 to a specific transaction commit number or epoch. In various embodiments, when flushing the database record 135 to the database 110, the database node 120 may clear the probabilistic data structures 140 whose latest transaction commit number 260 is less than the clearing transaction commit number. For example, the probabilistic data structure 140A may be associated only with transaction "A". Therefore, when all database records 135 associated with transaction A are flushed to the database 110, the database node 120A may clear the probabilistic data structure 140A so that the probabilistic data structure 140A is no longer provided to other database nodes 120. In some embodiments, the database node 120 notifies other database nodes 120 about the cleared probabilistic data structures 140 so that if those other database nodes 120 previously received copies of those probabilistic data structures 140, they no longer use those probabilistic data structures 140. In various embodiments, when database records 135 are flushed to database 110, an indication of the purge transaction commit number may be written to a directory accessible to all database nodes 120. Thus, database nodes 120 can read from the directory to determine that certain probabilistic data structures 140 are not in use because they have been purged—the purging database nodes 120 do not have to communicate directly with other database nodes 120 to let them know about the purged probabilistic data structures 140. Database nodes 120 can remove stale probabilistic data structures 140 from their storage.

[0063] Now turn to Figure 5, shows a block diagram of a transaction engine 310 interacting with example probabilistic data structures 140A-C. The illustrated embodiment may be implemented differently than shown—for example, there may be more probabilistic data structures 140 than shown.

[0064] In some embodiments, the database node 120 handles long-running transactions differently than non-long-running transactions. As mentioned, when the database node 120 initially inserts the database key 320 for the transaction into the probabilistic data structure 140, the database node 120 may register the transaction with the probabilistic data structure 140 by incrementing the active transaction count 240 of the probabilistic data structure 140. Although the active transaction count 240 is not zero, the probabilistic data structure 140 may not be cleared from the database node 120. This may lead to problems where long-running transactions prevent the probabilistic data structure 140 from being cleared and the database node 120 runs out of allocated space to create new probabilistic data structures 140. In particular, long-running transactions (e.g., transactions that last more than 2 hours) may write to multiple probabilistic data structures 140 that cannot be cleared when the long-running transactions have not yet been committed. In some cases, there may be multiple long-running transactions that, for example, prevent thousands of probabilistic data structures 140 from being cleared for hours. Therefore, because the database node 120 may not be able to clear those probabilistic data structures 140 for a period of time, it may not have enough space to allocate new probabilistic data structures 140. Therefore, in some embodiments, the database node 120 handles long-running transactions differently than non-long-running transactions.

[0065] When starting to process a database transaction, the database node 120 can initially insert the database key 320 for the database transaction into the probabilistic data structure 140. For example, as depicted, the transaction engine 310 inserts the database key 320 into the probabilistic data structure 140A. However, if the database node 120 determines that the database transaction should be classified as a long-running database transaction, the database node 120 can suspend the database key insertion of the database transaction until the pre-commit stage. In order to determine whether a database transaction should be classified as a long-running transaction, the database node 120 can use various standards. In various embodiments, if the database transaction duration is longer than (or exceeds) a specified amount of time, the database transaction can be classified as a long-running transaction. For example, if the database node 120 has processed a database transaction for 120 seconds, the database transaction can be classified as a long-running transaction. In some embodiments, if the database transaction has inserted a key into the probabilistic data structure 140 of a specified number, the database transaction can be classified as a long-running transaction. As an example, if, while processing a database transaction, a database node 120 has inserted a database key 320 into 10 different probabilistic data structures 140, the database transaction may be classified as a long-running transaction.

[0066] Once the database node 120 has determined that the database transaction is a long-running database transaction, in various embodiments, the database node 120 deregisters the database transaction from the probabilistic data structures 140 that it has touched. To deregister the database transaction from a given probabilistic data structure 140, the database node 120 may decrement the active transaction count 240 of the given probabilistic data structure 140. This may allow the given probabilistic data structure 140 to be purged faster than waiting for the long-running database transaction to commit. After determining that the database transaction is a long-running transaction, the database node 120 may stop inserting database keys 320 into the probabilistic data structure 140 for the transaction until the database node 120 has initiated a pre-commit phase for the transaction. In various embodiments, the transaction is committed by the database node 120 after writing all database records 135 to its in-memory cache 130 for the transaction—the commit may be made in relation to its in-memory cache 130. In some embodiments, rather than stopping key insertion for a long-running database transaction, the database node 120 may start writing database keys 320 to a single probabilistic data structure 140. The database node 120 may allow the probabilistic data structure 140 to exceed a threshold number of keys that would otherwise be permitted—that is, the database node 120 may allow the probabilistic data structure 140 to overflow rather than creating a new probabilistic data structure 140 .

[0067] In various embodiments, before a database node 120 commits a long-running database transaction, the database node 120 performs a batch insert of all database keys 320 associated with the transaction into a new set of probabilistic data structures 140. The database node 120 can then provide the new set of probabilistic data structures 140 to another database node 120 as part of a response to a database transaction request 105 as previously discussed. In some embodiments, the database node 120 can resume inserting database keys 320 for a database transaction, rather than restarting inserting all database keys 320 for the database transaction.

[0068] Now turn to Figure 6 , a flow chart of method 600 is shown. Method 600 is an embodiment of a method for performing by a first database node (e.g., database node 120A) to provide a probabilistic data structure (e.g., probabilistic data structure 140) to a second database node (e.g., database node 120B). Method 600 can be performed by executing a set of program instructions stored on a non-transient computer-readable medium. In some embodiments, method 600 may include more or fewer steps. As an example, method 600 may include the following steps: a first database node writes one or more of a set of database records (e.g., database records 135) from its in-memory cache (e.g., in-memory cache 130A) to a persistent storage (e.g., database 110) shared between the first and second database nodes. The first database node may determine whether to clear one or more probabilistic data structures in response to writing those database records to persistent storage.

[0069] Method 600 begins at step 610, where a first database node processes a database transaction involving writing a set of database records to a cache in a memory of the first database node. The processing may include inserting a set of database keys (e.g., database key 320) corresponding to a set of database records into a set of probabilistic data structures. In some embodiments, inserting a given database key into a given probabilistic data structure includes applying a hash function (e.g., hash function 315) to the given database key to derive a hash value (e.g., hash value 330) corresponding to a specific one of a plurality of cache lines included in the given probabilistic data structure (e.g., cache line 280). Thus, the first database node may insert the given database key into a specific cache line. Inserting a given database key into a specific cache line may include applying a set of hash functions (e.g., hash function 315) to the given database key to derive a set of hash values ​​and setting a set of bits of a specific cache line (e.g., bits of cache line portion 285) based on the set of hash values.

[0070] The first database node may insert a plurality of database keys from a set of database keys into a first probabilistic data structure in the set of probabilistic data structures. In some cases, in response to the first probabilistic data structure including a defined threshold number of database keys (e.g., 20,000 keys), the first database node may insert the remaining database keys from the set of database keys into a second different one of the set of probabilistic data structures. In some cases, at least one probabilistic data structure in the set of probabilistic data structures may be associated with database keys from a plurality of different transactions.

[0071] In step 620, the first database node sends the set of probabilistic data structures to the second database node to enable the second database node to determine whether to request a database record associated with a database key from the first database node. After sending the set of probabilistic data structures to the second database node, the first database node may add one or more additional probabilistic data structures to the set of probabilistic data structures. The first database node may then receive a database record request (e.g., database record request 122) for the latest version of the database record associated with the particular database key from the second database node. The first database node may include the one or more additional probabilistic data structures in a response (e.g., database record response 124) to the database record request.

[0072] In some embodiments, a given probabilistic data structure is associated with metadata indicating a latest transaction commit corresponding to the given probabilistic data structure (e.g., latest transaction commit number 260). In some cases, before including one or more additional probabilistic data structures in the response, the first database node may determine to include the one or more additional probabilistic data structures based on each of the one or more additional probabilistic data structures being associated with a respective final latest transaction commit corresponding to a later point in time than a particular transaction commit specified in the database record request.

[0073] In some embodiments, a given probabilistic data structure is associated with metadata (e.g., an active transaction count 240) that indicates the number of active transactions that have inserted a database key into the given probabilistic data structure. The first database node can determine whether a given probabilistic data structure can be cleared based on whether the number of active transactions indicates that there are active transactions for the given probabilistic data structure. In some cases, at least two of the group of probabilistic data structures can each include a corresponding database key inserted as part of processing a database transaction. Thus, in response to committing a database transaction associated with an in-memory cache, the first database node can decrement the number of active transactions associated with the probabilistic data structure for each of the at least two probabilistic data structures.

[0074] Now turn to Figure 7 , a flow chart of method 700 is shown. Method 700 is an embodiment of a method performed by a first database node (e.g., database node 120A) to determine whether to request a database record (e.g., database record 135) from a second database node (e.g., database node 120B). Method 700 can be performed by executing a set of program instructions stored on a non-transitory computer-readable medium. In some embodiments, method 700 may include more or fewer steps. As an example, method 700 may include a step in which a first database node provides a database record (received from a second database node) to an application system as part of processing a transaction request (e.g., database transaction request 105) received from an application system.

[0075] Method 700 begins at step 710, where a first database node receives a set of probabilistic data structures (e.g., probabilistic data structures 140) from a second database node that can be used to determine whether a given database record is not stored in an in-memory cache (e.g., in-memory cache 130B) of the second database node. In step 720, the first database node receives a request (e.g., database transaction request 105) to process a database transaction involving a particular database key (e.g., database key 320).

[0076] In step 730, the first database node determines whether to request the latest version of the database record associated with the particular database key from the second database node based on the set of probabilistic data structures. In some embodiments, the given probabilistic data structure includes multiple cache lines. In this way, the first database node can apply a hash function (e.g., hash function 315) to the particular database key to derive a hash value (e.g., hash value 330). Based on the hash value, the first database node can select one of the multiple cache lines of the given probabilistic data structure. The first database node can then determine whether the information stored in the cache line indicates a particular database key.

[0077] In response to determining that the information stored in the cache line does not indicate a particular database key, the first database node may request a latest version of a database record from a persistent storage (e.g., database 110) shared by the first and second database nodes. In response to determining that the information stored in the cache line indicates a particular database key, the first database node may send a request for the latest version of the database record to the second database node (e.g., database record request 122). Thus, the first database node may receive a response (e.g., database record response 124) from the second database node. In some cases, the request to the second database node may identify a latest transaction commit associated with a set of probabilistic data structures. Thus, the response may include a set of additional probabilistic data structures, each of which is associated with a transaction commit that occurred after the latest transaction commit identified by the request.

[0078] Now turn to Figure 8 , a flow chart of method 800 is shown. Method 800 is an embodiment of a method performed by a database node (e.g., database node 120) to process long-running database transactions. Method 800 can be performed by executing a set of program instructions stored on a non-transitory computer-readable medium. In some embodiments, method 800 may include more or fewer steps. As an example, method 800 may include a step in which a database node sends a set of probabilistic data structures (e.g., probabilistic data structures 140) to another database node to enable the other database node to determine whether to request a database record (e.g., database record 135) associated with a particular database key (e.g., database key 320) from the database node.

[0079] Method 800 begins at step 810, where a database node receives a request (e.g., database transaction request 105) to perform a database transaction involving writing a set of database records (e.g., database records 135) to an in-memory cache (e.g., in-memory cache 130) of the database node and inserting a set of corresponding database keys (e.g., database keys 320) into a probabilistic data structure. In step 820, the database node performs the database transaction.

[0080] In step 822, as part of performing a database transaction, for each probabilistic data structure in which at least one database key is inserted for a database transaction, the database node registers the database transaction with the probabilistic data structure. In various cases, registration is performed to prevent the probabilistic data structure from being deleted when registering a database transaction. In some embodiments, a specific probabilistic data structure in the probabilistic data structure includes metadata (e.g., active transaction count 240), which specifies the number of active transactions in which the database key has been inserted into a specific probabilistic data structure. Although the number of active transactions indicates that there is at least one active transaction, deletion of a specific probabilistic data structure can be prevented. In some cases, performing a database transaction includes inserting at least one database key into a specific probabilistic data structure. In this way, a database node can register a database transaction with a specific probabilistic data structure, including updating metadata to increment the number of active transactions.

[0081] In step 824, as part of performing the database transaction, the database node determines that the duration of the database transaction exceeds a specified amount of time (e.g., 30 seconds). In some embodiments, the database node determines that a specified number (e.g., 10) of probabilistic data structures have been written as part of performing the database transaction.

[0082] In step 826, as part of performing the database transaction, in response to the determination, the database node deregisters the database transaction from each probabilistic data structure for which the database transaction was previously registered. Deregistering a database transaction from a particular probabilistic data structure may include updating metadata to decrement the number of active transactions. The decrement may result in the number of active transactions being zero. Thus, after determining that deregistering a database transaction from a probabilistic data structure has resulted in the metadata being updated to reflect the absence of an active transaction, the database node may delete the particular probabilistic data structure.

[0083] In response to the determination, the database node may delay inserting the database keys of the database transaction into the probabilistic data structure until the database node has initiated a pre-commit phase of the database transaction. In some cases, in response to initiating the pre-commit phase of the database transaction, the database node may restart inserting a set of database keys of the database transaction into a set of probabilistic data structures. In some cases, in response to initiating the pre-commit phase of the database transaction, the database node may resume inserting the set of database keys of the database transaction into a set of probabilistic data structures. Before committing the database transaction, the database node may delete at least one of the probabilistic data structures in which the database transaction is cancelled. In some embodiments, in response to the determination, the database node inserts the remaining database keys of the set of database keys into a single probabilistic data structure.

[0084] Exemplary Computer System

[0085] Now turn to Fig. 9 , depicts a block diagram of an exemplary computer system 900 in which system 100, database 110, and / or database node 120 may be implemented. Computer system 900 includes a processor subsystem 980 coupled to system memory 920 and I / O interface 940 via an interconnect 960 (e.g., a system bus). I / O interface 940 is coupled to one or more I / O devices 950. Computer system 900 may be any of a variety of types of devices, including, but not limited to, a server system, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a tablet computer, a handheld computer, a workstation, a network computer, a consumer device such as a mobile phone, a music player, or a personal data assistant (PDA). Although for convenience, the computer system 900 is not limited to a computer system. Fig. 9 A single computer system 900 is shown in FIG. 9 , but system 900 may also be implemented as two or more computer systems operating together.

[0086] Processor subsystem 980 may include one or more processors or processing units. In various embodiments of computer system 900, multiple instances of processor subsystem 980 may be coupled to interconnect 960. In various embodiments, processor subsystem 980 (or each processor unit within 980) may include a cache or other form of onboard memory.

[0087] The system memory 920 can be used to store program instructions that can be executed by the processor subsystem 980 to enable the system 900 to perform various operations described herein. The system memory 920 can be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDORAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. The memory in the computer system 900 is not limited to the main memory such as memory 920. On the contrary, the computer system 900 can also include other forms of storage devices, such as cache memory in the processor subsystem 980 and auxiliary storage devices (e.g., hard drives, storage arrays, etc.) on the I / O device 950. In some embodiments, these other forms of storage devices can also store program instructions that can be executed by the processor subsystem 980. In some embodiments, program instructions that implement the database 110, database node 120, in-memory cache 130, and probabilistic data structure 140 when executed can be included / stored in the system memory 920.

[0088] According to various embodiments, the I / O interface 940 can be any of various types of interfaces configured to be coupled to other devices and communicate with other devices. In one embodiment, the I / O interface 940 is a bridge chip (e.g., a south bridge) from the front end to one or more back-end buses. The I / O interface 940 can be coupled to one or more I / O devices 950 via one or more corresponding buses or other interfaces. Examples of I / O devices 950 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs or their associated controllers), network interface devices (e.g., to local area networks or wide area networks) or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, the computer system 900 is coupled to a network via a network interface device 950 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0089] The implementation of the subject matter of the present application includes but is not limited to the following embodiments 1 to 20.

[0090] 1. A method comprising:

[0091] processing, by a first database node, a database transaction involving writing a set of database records to a cache in memory of the first database node, wherein the processing includes inserting a set of database keys corresponding to the set of database records into a set of probabilistic data structures; and

[0092] The set of probabilistic data structures is sent by the first database node to a second database node to enable the second database node to determine whether to request a database record associated with a database key from the first database node.

[0093] 2. The method of embodiment 1, wherein inserting a given one of the set of database keys into a given one of the set of probabilistic data structures comprises:

[0094] applying, by the first database node, a hash function to the given database key to derive a hash value corresponding to a particular one of a plurality of cache lines included in the given probabilistic data structure; and

[0095] The given database key is inserted, by the first database node, into the particular cache line of the given probabilistic data structure.

[0096] 3. The method of embodiment 2, wherein inserting the given database key into the particular cache line of the given probabilistic data structure comprises:

[0097] applying, by the first database node, a set of hash functions to the given database key to derive a set of hash values; and

[0098] A set of bits of the particular cache line is set by the first database node based on the set of hash values.

[0099] 4. The method of embodiment 1, wherein inserting the set of database keys comprises:

[0100] inserting, by the first database node, a database key from the set of database keys into a first probabilistic data structure from the set of probabilistic data structures; and

[0101] In response to the first probabilistic data structure including a defined threshold number of database keys, the first database node inserts remaining database keys of the set of database keys into a different second probabilistic data structure of the set of probabilistic data structures.

[0102] 5. The method of embodiment 1, wherein a given one of the set of probabilistic data structures is associated with metadata indicating a number of active transactions that have inserted a database key into the given probabilistic data structure, wherein the method further comprises:

[0103] Determining, by the first database node, whether the given probabilistic data structure can be cleared based on whether the number of active transactions indicates that there are active transactions for the given probabilistic data structure.

[0104] 6. The method of embodiment 5, wherein at least two of the set of probabilistic data structures each include a respective database key inserted as part of processing the database transaction, and wherein the method further comprises:

[0105] In response to committing the database transaction associated with the in-memory cache, the first database node decrements, for each of the at least two probabilistic data structures, a number of active transactions associated with the probabilistic data structure.

[0106] 7. The method according to embodiment 1, further comprising:

[0107] After sending the set of probabilistic data structures to the second database node, the first database node adds one or more additional probabilistic data structures to the set of probabilistic data structures;

[0108] receiving, by the first database node from the second database node, a database record request for a latest version of a database record associated with a particular database key; and

[0109] The one or more additional probabilistic data structures are included by the first database node in response to the database record request.

[0110] 8. The method of embodiment 7, wherein a given one of the set of probabilistic data structures is associated with metadata, the metadata indicating a most recent transaction commit corresponding to the given probabilistic data structure, wherein the method further comprises:

[0111] Prior to the including, the first database node determines to include the one or more additional probabilistic data structures based on each of the one or more additional probabilistic data structures being associated with a corresponding latest transaction commit, wherein the latest transaction corresponds to a point in time later than a specific transaction commit specified in the database record request.

[0112] 9. The method according to embodiment 1, further comprising:

[0113] writing, by the first database node, one or more database records in the set of database records from the cache in the memory to a persistent storage shared between the first and second database nodes; and

[0114] In response to the write, the first database node determines whether to clear a given one of the set of probabilistic data structures.

[0115] 10. The method of embodiment 1, wherein at least one probabilistic data structure in the set of probabilistic data structures is associated with database keys from multiple different transactions.

[0116] 11. A non-transitory computer-readable medium having program instructions stored thereon, the program instructions enabling a first computer system to perform operations comprising:

[0117] processing a database transaction involving writing a set of database records to a cache in a memory of the first computer system, wherein the processing includes inserting a set of database keys corresponding to the set of database records into a set of probabilistic data structures; and

[0118] The set of probabilistic data structures is sent to a second computer system to enable the second computer system to determine whether to request a database record associated with a particular database key from the first computer system.

[0119] 12. The non-transitory computer readable medium of embodiment 11, wherein inserting a given one of the set of database keys into a given one of the set of probabilistic data structures comprises:

[0120] applying a hash function to the given database key to derive a hash value;

[0121] selecting one of a plurality of cache lines of the given probabilistic data structure based on the hash value; and

[0122] Inserts the given database key into the selected cache line.

[0123] 13. The non-transitory computer readable medium of embodiment 11, wherein inserting the set of database keys into the set of probabilistic data structures comprises:

[0124] inserting a plurality of database keys of the set of database keys into a first probabilistic data structure of the set of probabilistic data structures capable of including at least a threshold number of database keys; and

[0125] After the first probabilistic data structure reaches the threshold number, additional database keys in the set of database keys are inserted into a second probabilistic data structure in the set of probabilistic data structures.

[0126] 14. The non-transitory computer readable medium of embodiment 11, wherein a particular one of the set of probabilistic data structures includes metadata specifying an active transaction count, the metadata indicating a number of active transactions that have inserted database keys into the particular probabilistic data structure, wherein processing the database transaction involves inserting at least one database key into the particular probabilistic data structure, and wherein the operations further comprise:

[0127] In response to committing the database transaction, the active transaction count of the particular probabilistic data structure is decremented.

[0128] 15. The non-transitory computer readable medium of embodiment 11, wherein the operations further comprise:

[0129] writing the set of database records from a cache in a memory of the first computer system to a persistent storage shared between the first and second computer systems, and

[0130] In response to writing the set of database records to persistent storage, a determination is made whether to clear one or more of the set of probabilistic data structures.

[0131] 16. A method comprising:

[0132] receiving, by the first database node from the second database node, a set of probabilistic data structures that can be used to determine whether a given database record is not stored in a cache in memory of the second database node;

[0133] receiving, by the first database node, a request to process a database transaction involving a particular database key; and

[0134] A determination is made, by the first database node, based on the set of probabilistic data structures, whether to request a latest version of a database record associated with a particular database key from a second database node.

[0135] 17. The method of embodiment 16, wherein a given one of the set of probabilistic data structures comprises a plurality of cache lines, and wherein the determining comprises:

[0136] applying, by the first database node, a hash function to the particular database key to derive a hash value;

[0137] Based on the hash value, the first database node selects one of a plurality of cache lines of a given probabilistic data structure; and

[0138] A determination is made, by the first database node, whether information stored in the cache line indicates a particular database key.

[0139] 18. The method of embodiment 17, further comprising:

[0140] In response to determining that the information stored in the cache line does not indicate the particular database key, the first database node requests a latest version of the database record from persistent storage shared by the first and second database nodes.

[0141] 19. The method of embodiment 17, further comprising:

[0142] In response to determining that the information stored in the cache line indicates a particular database key, the first database node sends a request for a latest version of the database record to the second database node; and

[0143] A response is received from the second database node by the first database node.

[0144] 20. A method according to embodiment 19, wherein the request identifies the most recent transaction commit associated with the set of probabilistic data structures, and wherein the response includes a set of additional probabilistic data structures, each of which is associated with the most recent transaction commit that occurred after the most recent transaction commit identified by the request.

[0145] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the disclosure, even if only a single embodiment is described for a particular feature. Unless otherwise stated, the feature examples provided in the disclosure are intended to be illustrative rather than restrictive. The above description is intended to cover such substitutions, modifications, and equivalents that are obvious to those skilled in the art having the benefit of the disclosure.

[0146] The scope of the disclosure includes any feature or combination of features disclosed herein (explicitly or implicitly) or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be made during the course of the present application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with features of the independent claims, and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations listed in the appended claims.

Claims

1. A method for reducing requests using a probabilistic data structure, comprising: processing, by a first database node, a database transaction involving writing a set of database records to a cache in a memory of the first database node, wherein the processing includes inserting a set of database keys corresponding to the set of database records into a set of probabilistic data structures; sending, by the first database node, the set of probabilistic data structures to a second database node to enable the second database node to determine whether to request a database record associated with a database key from the first database node; After sending the set of probabilistic data structures to the second database node, the first database node adds one or more additional probabilistic data structures to the set of probabilistic data structures; receiving, by the first database node from the second database node, a database record request for a latest version of a database record associated with a particular database key; and The one or more additional probabilistic data structures are included in response to the database record request by the first database node.

2. The method of claim 1 , wherein inserting a given one of the set of database keys into a given one of the set of probabilistic data structures comprises: applying, by the first database node, a hash function to the given database key to derive a hash value corresponding to a particular one of a plurality of cache lines included in the given probabilistic data structure; and The given database key is inserted, by the first database node, into the particular cache line of the given probabilistic data structure.

3. The method of claim 2, wherein inserting the given database key into the particular cache line of the given probabilistic data structure comprises: applying, by the first database node, a set of hash functions to the given database key to derive a set of hash values; and A set of bits of the particular cache line is set by the first database node based on the set of hash values.

4. The method of any one of claims 1 to 3, wherein inserting the set of database keys comprises: inserting, by the first database node, a database key from the set of database keys into a first probabilistic data structure from the set of probabilistic data structures; and In response to the first probabilistic data structure including a defined threshold number of database keys, the first database node inserts remaining database keys of the set of database keys into a different second probabilistic data structure of the set of probabilistic data structures.

5. The method of claim 1 , wherein a given one of the set of probabilistic data structures is associated with metadata indicating a number of active transactions that have inserted a database key into the given probabilistic data structure, wherein the method further comprises: A determination is made, by the first database node, whether the given probabilistic data structure can be cleared based on whether the number of active transactions indicates that there are active transactions for the given probabilistic data structure.

6. The method of claim 5, wherein at least two of the set of probabilistic data structures each include a respective database key inserted as part of processing the database transaction, and wherein the method further comprises: In response to committing a database transaction associated with the in-memory cache, the first database node decrements, for each of the at least two probabilistic data structures, a number of active transactions associated with the probabilistic data structure.

7. The method of claim 1 , wherein a given one of the set of probabilistic data structures is associated with metadata, the metadata indicating a most recent transaction commit corresponding to the given probabilistic data structure, wherein the method further comprises: Prior to the including, the first database node determines to include the one or more additional probabilistic data structures based on each of the one or more additional probabilistic data structures being associated with a corresponding latest transaction commit, wherein the latest transaction corresponds to a point in time later than a specific transaction commit specified in the database record request.

8. The method according to claim 1, further comprising: writing, by the first database node, one or more database records in the set of database records from the memory cache to a persistent storage shared between the first and second database nodes; and In response to the write, the first database node determines whether to clear a given one of the set of probabilistic data structures.

9. The method of claim 1, wherein at least one probabilistic data structure in the set of probabilistic data structures is associated with database keys from a plurality of different transactions.

10. A computer system comprising: at least one processor; and A memory having program instructions stored thereon, wherein the program instructions can be executed by the at least one processor to perform the method according to any one of claims 1 to 9.

11. A computer readable medium having program instructions stored thereon, wherein the program instructions can cause a first computer system to perform the following operations: processing a database transaction involving writing a set of database records to a cache in a memory of the first computer system, wherein the processing includes inserting a set of database keys corresponding to the set of database records into a set of probabilistic data structures; sending the set of probabilistic data structures to a second computer system to enable the second computer system to determine whether to request a database record associated with a particular database key from the first computer system; adding one or more additional probabilistic data structures to the set of probabilistic data structures after sending the set of probabilistic data structures to the second computer system; receiving from the second computer system a database record request for a latest version of a database record associated with a particular database key; and The one or more additional probabilistic data structures are included in response to the database record request.

12. The computer-readable medium of claim 11 , wherein inserting a given one of the set of database keys into a given one of the set of probabilistic data structures comprises: applying a hash function to the given database key to derive a hash value; selecting one of a plurality of cache lines of the given probabilistic data structure based on the hash value; and Inserts the given database key into the selected cache line.

13. The computer-readable medium of claim 11 or 12, wherein inserting the set of database keys into the set of probabilistic data structures comprises: inserting a plurality of database keys from the set of database keys into a first probabilistic data structure from the set of probabilistic data structures capable of including at least a threshold number of database keys; and After the first probabilistic data structure reaches the threshold number, additional database keys in the set of database keys are inserted into a second probabilistic data structure in the set of probabilistic data structures.

14. The computer-readable medium of claim 11, wherein: A particular one of the set of probabilistic data structures comprises metadata specifying an active transaction count, the metadata indicating a number of active transactions that have inserted database keys into the particular probabilistic data structure, wherein processing the database transaction involves inserting at least one database key into the particular probabilistic data structure, and wherein the operations further comprise: In response to committing the database transaction, the active transaction count of the particular probabilistic data structure is decremented.

Images