CN104239357A - Concurrent request processing for database transactions - Google Patents

Abstract

A request processor that can receive a transaction request for a transaction to be run using data from a database and can classify a first transaction request of the transaction request as a simple transaction request and a second transaction request of the transaction request as Complex transaction requests. The key-value store engine may run the first transaction satisfying the first transaction request using a key-value store determined prior to receipt of the first transaction request and based on precomputed results of the data, and may update the A key-value Δ reflecting the change to the key-value store caused by the first transaction. The relational storage engine may cause the at least one processor to run a second transaction that satisfies the second transaction's request using the relational storage comprising the subset of data, and may update to reflect changes, if any, to the relational storage caused by the second transaction The relationship Δ. A synchronizer can run a synchronization of key-value stores and relational stores based on key-value Δ and relationship Δ.

Description

Concurrent request processing for database transactions

technical field

This specification deals with transactional request processing for databases.

Background technique

Various types of databases are commonly used to store, manage, access or utilize data. In associated database operations, data can be read, created, updated, deleted, compared, merged, or manipulated.

In practice, a given database may be accessed by many different users in an overlapping or parallel fashion. For example, many users can submit overlapping transaction requests to the same database within a given period of time. In this scenario, it is important that the data within the database remain current, accurate, and consistent. For example, data modifications made by a first user must be completed and made available before using the same data to satisfy a request from a second user, in order to ensure that the second user receives timely and accurate results.

Thus, a transaction request from a user can be delayed until a previous transaction request related to the same data has been completed. In some cases, the resulting delay experienced by a given user may be minimal or insignificant. However, in scenarios such as those discussed above where a large number of parallel transaction requests are received, users may experience unsatisfactory or unacceptable accumulated delays.

For example, specifically, web-based applications such as electronic commerce (e-commerce) or social networking applications may enable millions of users to simultaneously attempt to access one or more databases supporting the respective web-based application. The difficulties described above may therefore be a significant problem in such scenarios. As a result, users (eg, customers) of such web-based applications may be dissatisfied, and merchants providing web-based applications may experience a loss in customer loyalty and profitability.

Contents of the invention

According to one general aspect, a system may include instructions recorded on a computer-readable medium and executable by at least one processor. The system may include a request processor configured to cause the at least one processor to receive a transaction request for a transaction to be executed using data of the database, and further configured to cause the at least one processor to receive a transaction request for the transaction request The first transaction request is classified as a simple transaction request, and the second transaction request of the transaction request is classified as a complex transaction request. The system may include a key-value store engine configured to cause the at least one processor to operate using a key-value store determined prior to receiving the first transaction request and based on a pre-computed result of the data A first transaction that satisfies the first transaction request and is further configured to update the key value Δ(delta), if any, to reflect changes to the key-value store caused by the first transaction. The system may include a relational storage engine configured to cause the at least one processor to execute a second transaction that satisfies the second transaction request using the relational storage comprising the subset of data, and further configured to, if any, The relation Δ is updated to reflect the change in the relational store caused by the second transaction. The system may include a synchronizer configured to cause the at least one processor to perform a synchronization of the key-value store and the relational store based on the key-value Δ and the relationship Δ.

Implementations may include one or more of the following features. For example, the transaction request may be received from at least one application at a database layer including a database.

The request processor may be configured to classify the first transaction request and the second transaction request based on a classification criterion characterizing their likelihood of satisfaction using the pre-computed results of the key-value store. The result calculator may be configured to cause the at least one processor to calculate a pre-computed result of the key-value store based on a predicted likelihood of future transaction requests to be received by the request processor. The synchronizer may be configured to cause the result calculator to update the precomputed result based on the key value Δ and relation Δ in conjunction with the synchronization.

The key-value store engine may be configured to determine a key associated with the first transaction request and perform a lookup of the corresponding value within the key-value store. The key-value store engine may include an invalidation notifier configured to update relation Δ based on an update of key value Δ. The synchronizer may be configured to update the relation store based on the relation Δ and updates received from the key-value store engine's invalidation notifier, and thereafter clear the contents of the relation Δ.

The relational storage engine may include an invalidation notifier configured to update the key value Δ based on an update of the relation Δ. The synchronizer may be configured to update the key-value store based on the key-value Δ and updates received from an invalidation notifier of the relational storage engine, and thereafter clear the contents of the key-value Δ.

The request handler, key-value store engine, relational store engine and synchronizer can be implemented in the main memory of the system. The relational storage engine may be configured to cause the at least one processor to update a transaction record stored in the non-volatile memory and to update the database with any changes to the database caused by the running of the first transaction or the second transaction .

According to another general aspect, a computer-implemented method for executing instructions stored on a computer-readable storage medium may include receiving a transaction request for a transaction to be performed using data from a database, a first transaction request for the transaction request A transaction request is classified as a simple transaction request, and a second transaction request of the transaction request is classified as a complex transaction request. The method may include running a first transaction that satisfies the first transaction request using a key-value store determined prior to receiving the first transaction request and based on precomputed results of the data, using a relational store that includes a subset of the data to A second transaction is run that satisfies the second transaction's request, and updates the key value Δ, if any, to reflect the changes to the key value store caused by the first transaction. The method may include updating the relation Δ, if any, to reflect changes to the relational store caused by the second transaction, and running a synchronization of the key-value store and the relational store based on the key-value Δ and relation Δ.

Implementations may include one or more of the following features. For example, updating the key value Δ may include updating the relationship Δ based on the key value Δ, and updating the relationship Δ may include updating the key value Δ based on the relationship Δ. The synchronizing may include updating precomputed results in conjunction with the synchronizing based on the key value Δ and relation Δ.

According to another general aspect, a computer program product tangibly embodied on a non-transitory computer-readable storage medium may include instructions. The instructions, when executed, may be configured to receive a transaction request for a transaction to be executed using data from a database, classify a first transaction request of the transaction request as a simple transaction request, and a second transaction request of the transaction request Classified as a complex transaction request. Said instructions, when executed, may be configured to run a first transaction that satisfies the first transaction request using a key-value store determined prior to receiving the first transaction request and based on precomputed results of the data, and using a key-value store that satisfies the first transaction request using A relational store of the subset of data is used to run a second transaction that satisfies the request of the second transaction. Said instructions, when executed, may be configured to update the key value Δ, if any, reflecting changes to the key-value store caused by the first transaction, and to update the key value Δ, if any, reflecting changes to the relational store caused by the second transaction. Changed relationship Δ, and based on the key value Δ and relationship Δ to run the synchronization of the key-value store and the relational store.

Implementations may include one or more of the following features. For example, in updating the key value Δ, when the instruction is executed, it can be configured to update the relation Δ based on the key value Δ, and in updating the relation Δ, when the instruction is executed, it can be configured to update the relation Δ based on the relation Δ Update key value Δ.

The synchronizing may include updating the relationship store based on the relationship Δ and updates received from the key-value store, and thereafter clearing the contents of the relationship Δ. The synchronizing may include updating the key-value store based on the key-value Δ and updates received from the relational store, and thereafter clearing the contents of the key-value Δ.

The synchronizing may include updating precomputed results in conjunction with the synchronizing based on the key value Δ and relation Δ. The transaction request may be received from at least one application at a database layer including a database.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

Description of drawings

Figure 1 is a block diagram of a system for managing parallel database transaction requests.

FIG. 2 is a block diagram showing details of an example implementation of the system of FIG. 1 .

FIG. 3 is a flowchart illustrating example operation of the system of FIGS. 1 and 2 .

FIG. 4 is a flow diagram illustrating example pre-request calculation results for use in the system of FIG. 1 .

FIG. 5 is a block diagram of a B-tree data structure used in an example implementation of the system of FIG. 1 .

FIG. 6 is a flowchart illustrating additional example operations of the systems of FIGS. 1 and 2 .

FIG. 7 is a flowchart illustrating example operations for updating the precomputed results of FIG. 4 .

Figure 8 is a block diagram of an example implementation of the system of Figures 1, 2 using a distributed, scaled architecture.

Detailed ways

FIG. 1 is a block diagram of a system 100 for managing parallel database transaction requests. In the example of FIG. 1 , database 102 is shown supporting transactional requests received from applications 104 . As noted above, applications 104 may receive a large number of parallel transaction requests. In the example of FIG. 1 , as described in detail below, such parallel transactional requests are separated at the database layer of system 100 such that different types of transactional requests are managed differently within the database layer. As a result of these and related features, transaction requests can be satisfied immediately and efficiently by the system 100 as a whole, even when a large number of transaction requests are received within a short period of time.

In the example of FIG. 1 , database 102 and application 104 will be understood to represent virtually any type of known or future implementation of an architecture in which a front-end application interacts with a user (or other source of a transaction request) (directly or indirectly) interaction, including receiving transaction requests that require support from one or more backend databases. For purposes of illustration and description, in the example embodiments that follow, database 102 is generally described as a relational database, such as may store data using one or more relational tables in which a single table row represents a corresponding data record and a single The table columns represent the corresponding data types.

Of course, as mentioned, database 102 may represent any type of database not inconsistent with the features and techniques described herein, such as, for example, an object-oriented database. Such databases are typically associated with a database management technology(s) or database management system (DBMS) and associated languages such as, in the case of relational databases, Structured Query Language (SQL).

Similarly, application 104 may represent any application that may access database 102 . Also for purposes of illustration and example, applications 104 may be described herein in terms of Internet applications (eg, e-commerce or social networking applications). For example, application 104 may represent a business application (eg, for providing chain management, customer relationship management, or enterprise resource planning) by which store employees may access inventory, customer, or financial data records.

Also in FIG. 1 , result calculator 106 may be configured to access database 102 and generate the contents of key-value store 108 . In the example of FIG. 1 , the contents of key-value store 108 may be stored as key-value pairs so that key-value store engine 110 can easily perform a lookup using a particular key to quickly and precisely locate an associated value. Additionally, the contents of key-value store 108 may be stored using one or more suitable data structures, such as those described below with reference to FIG. 5 .

The operation of result calculator 106 in populating key-value store 108 is described in detail below with reference to FIG. 4 . Furthermore, the operation of result calculator 106 in the context of updating key-value store 108 over time during operation of system 100 is provided below with reference to FIG. 7 .

In general, however, result calculator 106 may be understood to identify specific operations and calculations to be performed with database 102 in order to prepare key-value store 108 each time prior to receiving a transaction request requiring such a result. In doing so, result calculator 106 may predict transaction requests, or types of transaction requests, that will be received via application 104 , and may precompute and store results for such predicted transaction requests as key-value store 108 . For example, outcome calculator 106 may predict future receipt of a particular transaction request, or type of transaction request, based on the frequency or relative frequency of previously received such transaction requests.

Additionally, or alternatively, result calculator 106 may predict future transaction requests based on characteristics or aspects of database 102 and/or application 104 . For example, data that is newly stored to database 102 may be more likely to be included in calculations performed by result calculator 106 than data that has been included in database 102 for a predefined minimum time. In another example where application 104 represents an e-commerce related application, it may happen that certain categories of items for sale are predicted to be the subject of transaction requests in the short term, so that result calculator 106 may use The calculation of association is performed on the data of the database 102 related to a commodity for sale.

As a specific, simplified example, it may happen that database 102 is an inventory database and application 104 represents an inventory management application. In such an arrangement, it may happen that transaction requests are frequently received requesting specific information about items for sale or categories of items for sale. For example, such a transaction request may specify a request for the quantity of such an item sold within a certain time period (eg, within a certain number of years). In such a scenario, the result calculator 106 may pre-compute the corresponding result for storage within the key-value store 108, for example, where a particular key may be generated using a suitable hashing algorithm and is utilized such Uniquely identified by the transaction result of a particular such instance of a transaction request. Thus, when a matching transaction request is received by key-value store engine 110, key-value store engine 110 can again use a suitable hashing algorithm to quickly identify the corresponding key for the requested transaction result, and can thereafter perform A lookup within the value store 108 for the desired transaction result.

As described in more detail below, many types of common transaction requests received by applications 104 may thus be satisfied through use of key-value store engine 110 and key-value store 108 . For example, by way of illustration only, a transaction request requesting a simple read of a precomputed value can be satisfied very quickly. Similarly, read operations using simple combinations of two or more pre-stored values or results can also be satisfied quickly. In addition, simple write operations (eg, create or insert operations) can be performed using the key-value store engine 110, as also described in more detail below.

Thus, as just described, a large number of transaction requests received by applications 104 can be satisfied quickly and accurately with key-value store engine 110 and key-value store 108 . Nonetheless, applications 104 may receive many types of transaction requests that may be difficult, impractical, or impossible to satisfy using key-value store engine 110 .

Thus, in the example of FIG. 1, relational storage engine 112 is included in system 100 of FIG. Such a transaction request may not be satisfied. In particular, some transaction requests may require logically complex and/or detailed and lengthy calculations to be performed using data from the database 102 . In other examples, it may happen that it is difficult or impossible to predict some transaction requests before they are received, so that it may not be practical or possible for the result calculator 106 to generate related results. Furthermore, it may happen that large chunks of data stored using the key-value store 108 may be optimized at a particular size beyond which precomputed results by the result calculator 106 provide diminished or negligible actual positive returns (net positive return).

Thus, relational data store 114 may represent a replicated version or subset of database 102 and may be stored using the same or a modified format as underlying database 102 . For example, in the relational database scenario discussed above where database 102 represents one or more relational tables, relational data store 114 may similarly be stored as one or more relational tables using rows and columns corresponding to underlying database 102 . As a result, relational storage engine 112 can virtually apply any transaction requests received from application 104 against relational data store 114 , which application 104 can be applied against database 102 .

In operation, request handler 116 may be configured to receive a plurality of transaction requests that may be received by application 104 . Request processor 116 may consult taxonomy 117 to decide whether to route a particular transaction request to key-value store engine 110 or relational store engine 112 .

Generally speaking, for example, as described in more detail below with reference to FIG. Transaction requests can be sent to relational storage engine 112 . For example, in the most straightforward scenario, simple transaction requests might be identified as those requesting only query/read operations, and/or perhaps basic write operations (eg, create or insert operations). At the same time, complex transaction requests may be defined as those transaction requests that require more extensive computation and/or manipulation relative to the data contained within the underlying database 102 as such data is represented within the relational data store 114 .

On the other hand, as can be understood from the above discussion of key-value store 108 and relational data store 114, simple transaction requests identified by taxonomy can be understood as those transaction requests that can most likely be included within key-value store 108, Whereas complex transaction requests may be identified as those transaction requests that may require access to relational data store 114 for successful completion. Thus, the configuration of taxonomy 117 may depend on the underlying settings of the operation of result calculator 106 in computing the contents of key-value store 108 . For example, if result calculator 106 is configured to include a particular type of data within key-value store 108, transaction requests that may relate to such data may be more likely to be classified by classification criteria 117 as being sent to key-value store engine 110 A simple transaction request. Accordingly, certain operations of request processor 116 in classifying incoming transaction requests for routing to key-value store engine 110 or relational store engine 112 may be understood to be, at least in part, relevant on the user side of system 100 of FIG. The design configuration thing.

Thus, as described in more detail below, for example, with reference to FIGS. The storage engine 110 is configured to use the key-value store 108 to satisfy the transaction request. For information only, taxonomy 117 may access the operation of result calculator 106 and/or key-value store 108 such that request processor 116 may have a high expectation or certainty that a transaction request will be satisfied by key-value store engine 110 . However, for reasons discussed herein, it may also happen that request processor 116 routes transaction requests that may not be satisfied by using key-value store 108 to key-value store engine 110 . In this case, key-value store engine 110 and/or request processor 116 may be configured to route such transaction requests further to relational store engine 112 .

Additionally, as referenced above, request processor 116 may also receive a second transaction request that may be routed to relational storage engine 112 based on classification criteria 117 . Thereafter, relational storage engine 112 may use relational data store 114 to satisfy routed transaction requests.

As described in more detail below with reference to FIG. 2 , main memory may be used to run the operations of key-value store engine 110 and relational store engine 112 in order to increase the overall efficiency of system 100 . In general, however, main memory is implemented using volatile storage media such that a crash or other interruption of the hardware or software used to implement system 100 may result in undesired loss of data. Accordingly, the database 102 itself may be stored using an underlying non-volatile storage medium, as described below also with reference to FIG. 2 . Then, in the context of the volatile storage medium of the main memory, a transaction record 118 reflecting all data transactions run may be maintained. Thus, database 102 can be updated as needed/required using transaction records 118 . Then, in the event of a hardware/software crash or other system interruption, the data of database 102 will not be lost and can be updated with transaction records 118 until the point in time of the failure or other interruption. As a result, the current system 100 , including relational data store 114 and key-value store 108 , up to the point in time of a crash or other disruption, can generally be recreated and regenerated.

As can be appreciated from the description above, and as described in more detail below, transaction requests executed by key-value store engine 110 may result in changes in the contents of key-value store 108 . Similarly, transactional requests executed by relational storage engine 112 may result in changes in the contents of relational data store 114 . For example, a transaction request received by request handler 116 and routed to key-value store engine 110 may result in a change to a given data record of key-value store 108 . Then, subsequent transaction requests related to the same data record and received by the request handler 116 and routed to the key-value store engine 110 must reflect the updated value of the data record in question in order to provide the application 104 with a current and accurate response.

Similarly, later received transactional requests processed by relational storage engine 112 must reflect earlier updates to relational data store 114 resulting from earlier received transactional requests processed by relational storage engine 112 . Additionally, but similarly, in the context of key-value store 108 , transaction requests received by relational storage engine 112 must also be handled in a manner that takes into account updates to data records caused by key-value store engine 110 . Similarly, but conversely, transactional requests processed by key-value store engine 110 must reflect earlier changes made to relational data store 114 as a result of processing earlier transactional requests by relational store engine 112 .

Accordingly, as shown in the example of FIG. 1 , synchronizer 119 may be configured to interact with key-value store engine 110 and relational store engine 112 to thereby guarantee simultaneity between key-value store 108 and relational data store 114 desired timing and level. For example, synchronizer 119 may be configured to run a full synchronization between key-value store 108 and relational data store 114 at defined intervals, to thereby reflect and include any and all data modifications that are not reflected due to just It is necessary to run all transaction requests at the completion of the previous synchronization operation. Additionally, or alternatively, synchronizer 119 may be configured to perform such synchronization in response to a request or other operation of key-value storage engine 110 and/or relational storage engine 112 . For example, synchronizer 119 may process synchronization after a certain number of transaction requests have been managed, and/or in association with processing a particular transaction request or class of transaction requests that may imply or require such synchronization.

To facilitate operations utilizing synchronizer 119, and generally to ensure that current, accurate results are provided to transaction requests received from applications 104, key-value store engine 110 may include key-value delta 120, which is configured to track Storage engine 110 processes any changes to key-value store 108 resulting from transaction requests. For example, a transaction request processed by key-value store engine 110 may result in a new data record being inserted within key-value store 108 . The key-value store engine 110 can simply store the created data record using the key-value Δ 120 without modifying the contents of the key-value store 108 (or the contents of the relational data store 114 or database 102) at that time.

Similarly, transaction requests to delete results within key-value store 108 may be reflected within key-value Δ 120 . Specifically, in the latter example, it is not necessary to actually delete a particular data record from key-value store 108 . Instead, deleted data records can simply be marked as invalid using the key value Δ120. Then, as referenced above, it is necessary to ensure that the relational storage engine 112 does not utilize or attempt to access the data records so deleted thereafter. Accordingly, the invalidation notifier 122 of the key-value storage engine 110 may be configured to notify the relational storage engine 112 of the deletion/invalidation of the data record in question. More specifically, for example, as described in detail below with reference to FIG. The transactional requests received by the applications 104 provide current, accurate responses in terms of updates that may affect the operation of the relational storage engine 112 .

Similarly, relational store engine 112 may maintain relation Δ 124 that reflects any updates to relational store 114 that result from processing transaction requests by relational store engine 112 and that have not yet been reflected in relational data store 114 by operations of synchronizer 119 within. Also similar to the operation of the invalidation notifier 122, the relational storage engine 112 may include an invalidation notifier 126, which may also be configured to notify the invalidation of specific data to the key-value storage engine 110, so as to thereby ensure that the key-value storage engine 110 Inaccurate or stale responses are not provided to transaction requests received from applications via request handler 116 .

Thus, in operation, key-value store engine 110 may satisfy a transaction request from request processor 116 using key-value store 108 and thereafter update key-value Δ 120 to reflect any resulting changes to key-value store 108 . If desired, invalidation notifier 122 may notify relational storage engine 112 of such changes to be reflected within relational data 124 thereafter. Relational store engine 112 may thus utilize relational delta 124 and use relational data store 114 to satisfy subsequent requests received from request processor 116 . A similar description may apply to the relational store engine 112, i.e., the relational data store 114 may be used to process transaction requests, and the key-value store engine 110 may be notified via the invalidation notifier 126 that the relation is fully, wholly, or partially reflected in the relation Δ 124 Any resulting changes to the relational data store 114 of .

For example, as also described below with reference to FIG. 6, the operation of the invalidation notifiers 122, 126 may vary slightly as a matter of design choice. For example, in some implementations, when key value Δ120 is updated, invalidation notifier 122 may notify relation Δ124 of the update in question, and may thereby cause an actual update to the corresponding data record within relation Δ124, thereby reflecting Underlying update to key value Δ120.

However, in other example embodiments, the invalidation notifier 122 may simply identify the relevant, modified data of the key value Δ 120 and/or the key value store 108 such that the relationship Δ 124 may simply track the fact that the identified data has changed , without actually knowing its updated value at that time. In the latter example, when a transaction request is received by relational storage engine 112 associated with invalid/modified data within relation Δ124 identified by invalidation notifier 122, relational storage engine 112 may trigger synchronizer 119 to Key-value store 108 and relational data store 114 are partially or fully synchronized using respective key-value Δ 120 and relationship Δ 124 . In such an example, then, it can be appreciated that the operation of the synchronizer 119 could potentially be triggered by a particular type or number of notifications sent by either or both of the invalidation notifiers 122, 126.

Accordingly, key-value store engine 110 and relational store engine 112 are able to provide fast and precise responses in a specialized and efficient manner that enables management of the large number of parallel transaction requests received by applications 104 . When doing so, key-value store engine 110 and relational store engine 112 may use key-value Δ 120 and relation Δ 124 , respectively, to also track changes to key-value store 108 and relational data store 114 , respectively. Synchronizer 119 may update relationship data store 114 and key-value store 108 after a certain period of time, and/or in response to some other stimulus, at which time it may be desirable or necessary to erase key-value Δ120 and/or relationship Δ124 some or all. As can be appreciated, and as also described in detail below, the synchronizer 119 can be facilitated in this regard by the earlier operation of the invalid notifiers 122, 126 in identifying specific data to be included in the synchronization operation of the synchronizer 119. operation. Furthermore, because all components 108-119 can be implemented in main memory, their operation can be very rapid and efficient in satisfying transactional requests received by application 104, even in the presence of a large number of concurrent transactional requests.

As shown in FIG. 1 , system 100 may be implemented using at least one computing device 128 , which may itself include at least one processor 128A and at least one computer-readable storage medium 128B. That is, for example, system 100 may be implemented using two or more computing devices 128 that operate partially or fully in communication with each other and in parallel. Similarly, two or more processors operating in parallel may be utilized in order to increase the speed and efficiency of the operation of system 100 .

As referenced above, and as described and illustrated in more detail below with reference to FIG. 2 , computer-readable storage media 128B may represent at least two different types of computer memory. For example, computer-readable storage medium 128B may represent a first, non-volatile memory for storing database 102 in transaction log 118 . Meanwhile, the computer-readable storage medium 128B may also typically represent a second, volatile memory provided as a main memory of at least one computing device 128 . As also described and illustrated with reference to FIG. 2, such main memory may be utilized to implement and operate any of the components 108-119 of the system 100 of FIG.

While the system 100 of FIG. 1 is shown using a number of discrete, individual modules, it will be appreciated that such illustration is for purposes of illustration and describing the operation of the system 100 only. Accordingly, it is also to be appreciated that any two or more components of system 100 may be combined for operation as a single component. Similarly, but conversely, any single component shown in system 100 of FIG. 1 may be divided into two or more subcomponents in various example embodiments. For example, some or all of synchronizer 119 may be split and included within corresponding portions of key-value store engine 110 and relational store engine 112 . By way of another example, some functionality of the request processor 116 may be included within the operation of the key-value store engine 110 because, for example, as referenced above, transactional requests routed through the key-value store engine 110 may not be able to use the key-value store 108 is satisfied, but must thereafter be satisfied by the relational storage engine 112 using the relational data store 114 .

FIG. 2 is a block diagram illustrating an example use of different types of memory during implementation of the system 100 of FIG. 1 . In the example of FIG. 2 , user 202 (representing one or more users) is shown providing transaction requests to database system 204 . As shown, memory 206 represents an example of volatile, main memory used to implement key-value store engine 110 , relational store engine 112 , and synchronizer 119 . Of course, although not specifically shown in the example of FIG. Various internal and related components of the data store 114).

Meanwhile, a second memory 208 is shown for implementing transaction logging 118 and underlying database 102 . As shown, memory 208 may include non-volatile memory such as a hard disk or solid state drive (SSD), for example.

Thus, the operations of key-value store engine 110 , relational store engine 112 , and synchronizer 119 may be performed in a fast, efficient manner using memory 206 as described. To guard against the inherent instability of memory 206 , relational storage engine 112 may continually update transaction records 118 to reflect all transactions performed using memory 206 , as shown and described. Thus, in the event of a system crash or other failure, only the transaction records 118 and the contents of the database 102 can be used to reproduce the current state of the system at the time of the outage.

Furthermore, in practice, transaction record 118 may be constantly updated, for reference only, but it may not be necessary or desirable to reflect such changes within database 102 synchronously. Instead, transaction records 118 may not collect transactions for a period of time, and/or until some threshold number of transactions, after which synchronization of transaction records 118 and database 102 occurs, and the contents of transaction records 118 may be purged.

FIG. 3 is a flowchart 300 illustrating example operations of the system 100 of FIG. 1 . In the example of FIG. 3, operations 302-316 are shown as separate, sequential operations. However, it can be appreciated that any two or more of operations 302-316 may be implemented in a partially or fully overlapping or parallel fashion, and/or in a nested, iterative, branching, or looping fashion. Furthermore, within such variations, it can be appreciated that additional or alternative operations not specifically shown in the example of FIG. 3 may be included, while one or more of operations 302-316 may be omitted.

In the example of FIG. 3 , as referenced above, a transaction request for a transaction to be run using data of a database may be received ( 302 ). For example, request handler 116 may receive a transaction request through application 104 , eg, as a result of an interaction between application 104 and user 202 of FIG. 2 .

A first transaction request of the transaction requests may be classified as a simple transaction request (304). For example, as described, request processor 116 may consult taxonomy 117 to determine that the first transaction request is likely or must be satisfied using the contents of key-value store 108 . As described, this classification may be based on actual knowledge of the key-value store 108, and/or may be based on the nature and type of the first transaction request. For example, as described, any transactional request that specifically is a direct create/read/update/delete of data as it may be included within key-value store 108 may be classified as a simple transactional request.

Meanwhile, a second transaction request of the transaction requests may be classified as a complex transaction request (306). For example, request processor 116 may determine based on classification criteria 117 that the second transaction request requires a logical combination of two or more data records or data tables, or may otherwise require computationally intensive processing that is unlikely or unsatisfactory using key-value store 108 . calculation. Specifically, for example, any such transaction request that may require one or more data rows (or an entire data table) to be locked until a second transaction request is completed will likely be classified as a complex transaction request.

Also in FIG. 3 , a first transaction that satisfies the first transaction request can be run using a key-value store determined prior to receipt of the first transaction request and based on precomputed results of the data (308). For example, key-value store engine 110 may satisfy a first transaction request using key-value store 108, wherein, as described, the key content of key-value store 108 may have been stored in database 102 for use by result calculator 106 (and/or stored in Data in the relational data store 114) is computed previously.

A second transaction that satisfies the second transaction request can be executed using the relational store that includes the subset of data (310). For example, relational storage engine 112 may use relational data store 114 to satisfy the second transaction request.

The key value Δ, if any, may be updated to reflect the change to the key value store caused by the first transaction (312). For example, key-value store engine 110 may update key-value Δ 120 based on any changes to key-value store 108 resulting from execution of the first transaction request.

Similarly, the relationship Δ, if any, may be updated to reflect the change to the relationship store caused by the second transaction (314). For example, relational store engine 112 may use relational data store 114 to update relation Δ 124 based on the execution of the second transaction.

Finally, in the example of FIG. 3 , a synchronization of the key-value store and the relational store can be run based on the key-value Δ and relationship Δ ( 316 ). For example, synchronizer 119 may update relational data store 114 with key value Δ 120 and relation Δ 124 . Similarly, synchronizer 119 may use key value Δ 120, relation Δ 124, and result calculator 106 (as described in more detail below with reference to FIG. 7, to the extent that results to be stored within key value store 108 must be recalculated) to update the key-value store 108.

FIG. 4 is a flowchart 400 illustrating example operation of the result calculator 106 of FIG. 1 . That is, for example, flowchart 400 illustrates operations of result calculator 106 that may be executed to populate key-value store 108 from which future transaction requests expected to be received may be satisfied.

In the example of FIG. 4, all necessary transaction data may be loaded by the result calculator 106 (402). For example, result calculator 106 may access database 102 to utilize data that is expected to be the subject of many or some future transaction requests. For example, result calculator 106 may analyze transaction records 118 to determine the relative frequency of transaction requests or types of transaction requests, and may extrapolate therefrom to determine which data or type of data to extract from database 102 .

Similarly, result calculator 106 may determine the type of calculation to be performed on the extracted data, and may thereafter run calculations based on the data (404). Furthermore, over time, result calculator 106 may monitor the use of key-value store 108 during operation of system 100 to thereby judge the relative success of selection of data and associated calculations performed during population of key-value store 108 . Thus, for example, during future updates of the key-value store 108, the result calculator 106 will be more likely to select data and associated computations that have been frequently utilized by the key-value store engine 110 during execution of transaction requests based on the key-value store 108 .

Finally in FIG. 4, the key-value store 108 may be used to store the calculation results (406). In an example implementation, calculation results may be stored in a manner that enables fast and precise lookup of desired results within key-value store 108 by key-value store engine 110 . Specifically, for example, FIG. 5 illustrates a B-tree data structure that may be utilized to populate the contents of the key-value store 108 . As shown, the B-tree data structure of FIG. 5 includes a number of nodes 502-520 arranged in a hierarchical fashion. Thus, looking up any particular data item from within the data structure of FIG. 5 can occur rapidly because the distributed nature of the data structure implies that accessing any particular data item will require traversing at most a relatively small number of levels of the hierarchical data structure.

More specifically, as shown, each node may include multiple keys and associated data items, and each item may also be associated with the next underlying node and associated key/data item of the data structure. Therefore, even if the overall data volume of the data structure of FIG. Hierarchy to locate expectations.

In an example implementation, result calculator 106 may populate key-value store 108 with a suitable hashing algorithm such that key-value store engine 110 may access the desired value from key-value store 108 using the same hashing algorithm. In such a scenario, result calculator 106 may implement the data structure of FIG. 5 using a number of different computing devices using a hashing algorithm, as described in more detail below with reference to FIG. 8 . Accordingly, the amount of data in any given one of such computing devices may be limited to acceptable or desired levels. Furthermore, many separate transaction requests can be run concurrently so that the computational burden can be distributed among different parallel computing devices.

For example, during access of the key-value store 108 by the key-value store engine 110, the key-value store engine 110 would simply be required to use a suitable hashing algorithm to find the relevant nodes related to a particular transaction request. Then, depending on the underlying nature of the transaction request in question, the key-value store engine 110 would simply be required to overlap, add, or remove corresponding nodes. When the key-value store 108 is implemented using main memory, as shown in the example of FIG. 2 , then, for example, the available memory space for implementing the key-value store 108 may be pre-allocated using a memory pool. Furthermore, accessing the key-value store 108 in such an example implementation may operate as a direct memory access without requiring resources at the underlying operating system level.

Furthermore, in the context of key-value store 108, many different variations and optimizations can be implemented when using the data structure of FIG. 5 . For example, as referenced above, result calculator 106 may be configured to populate key-value store 108 with pre-computed results that are considered likely to be frequently accessed by incoming transaction requests. However, despite this, it may happen that at least some data of the key-value store 108 is not accessed very frequently. Therefore, in order to save the data requirements of the key-value store 108, such B-tree nodes of the data structure of FIG. . In a more particular example, key-value store engine 110 may monitor the hit rate of each node of the B-tree of FIG. 5 and, over time, may determine which such node is relatively and frequently utilized. Such nodes can then be moved to relational data store 114 , perhaps along with a synchronization operation by synchronizer 119 . Such updates to relational data store 114 may then be recorded using transaction records 118 and ultimately reflected within database 102, as described.

FIG. 6 is a flowchart 600 illustrating a more detailed example operation of the systems of FIGS. 1 and 2 . In the example of FIG. 6, a transaction request may be accepted (602). For example, request processor 116 may receive a transaction request from application 104 for classifying it as a simple or complex transaction request based on classification criteria 117 (604), as described. However, in additional or alternative example implementations, the request handler 116 , or its functionality, may be implemented within or by the key-value store engine 110 . For example, it may happen that all transactional requests are initially routed to key-value store engine 110 , which may then determine whether such transactional requests can be satisfied using key-value store 108 . If not, the transaction request can be routed to relational storage engine 114 .

However, once classification of accepted transaction requests occurs (604) in the example of FIG. 6, transaction requests determined to be classified as simple transaction requests may also be classified as query or write transactions (606). If the transaction request is a query operation, the underlying transaction may be run by the key-value store engine 110 using the key-value store 108 (608).

By way of specific example, such a transaction request may request a read operation representing an output of all instances of an item of a certain type. Transactional execution may then involve simply accessing the key-value store 108 to retrieve an instance from it. Additionally, as referenced above, the key value store engine 110 may examine the key value Δ 120 to determine whether any previous updates to the key value Δ 120 need to be reflected in the results calculated for the current transaction request.

For example, it may happen that, during a previous transaction run by key-value store engine 110 using key-value store 108 , additional instances of a particular item type were created or inserted. Therefore, the key-value store engine 110 will update the transaction request result to include the additional instance from the key-value Δ120. More generally, then, it will be appreciated that the key-value store engine 110 can initially run any such query operations that can be satisfied using the key-value store 108 , and can thereafter update such results based on the contents of the key value Δ120 .

In some cases, it may happen that the requested transaction may be executed without using the key-value store 108 . For example, it may happen that there is no corresponding key and associated value contained within the data structure of FIG. 5 . For example, as described, it may happen that the required data values were previously moved to the relational store 114 , or were never included in the key-value store 108 by the result calculator 106 . In this case, the failed transaction request may be forwarded to the relational storage engine 112 for execution as described herein (eg, as described below with reference to operation 618). However, if the transaction has been successfully run (608), a corresponding result can be returned to the application 104 and/or user 202 (610), for example.

Meanwhile, if it is determined that the original transaction request was a write operation (606), the key-value store 108 may be used by the key-value store engine 110 to attempt to run the underlying transaction again (612). As described above with reference to operation 608, such a transactional run may include a query of the key-value store 108 along with consideration of the key-value Δ 120 to thereby obtain current, accurate results. Furthermore, as also described with reference to operation 608, the inability to run a transaction through the key-value store engine 110 may result in forwarding the transaction request to the relational store engine 112 for execution (e.g., in the context of operation 618, as described below) .

In such an example where the key-value store engine 110 is performing a write operation with respect to the contents of the key-value store 108, it can be appreciated that such a transaction will result in a change to the contents of the key-value store 108, and/or affect the A change in the underlying data of the contents of the key-value store 108 . Thus, as discussed above with reference to FIG. 1 , invalidation notifier 122 of key-value storage engine 110 may provide notification (arrow 615) to relational storage engine 112 that a previous version of the data is no longer valid or current (arrow 615) in order to guarantee relational Storage engine 112 does not attempt to use such obsolete or invalid data to process transaction requests.

As mentioned, in certain example implementations, the invalidation notifier 122 may simply notify the relational storage engine 112 that the data is invalid without requiring a corresponding immediate update to the contents of the relation Δ124. For example, where the content of a particular data record has been updated, the invalidation notifier 122 may simply notify the relation Δ 124 that the corresponding data record should not be used until a future synchronization process has been run. Such invalidation notifications may accumulate as long as the relational storage engine 112 does not require the data record in question to satisfy the transaction request. Then, after a certain amount of time, or after a certain number of invalidation notifications and/or transaction requests, the relation Δ124 may be updated to reflect the actual content change indicated by the invalidation notifier 122 by using the synchronizer 119 .

In additional or alternative implementations, relational storage engine 112 may perform updates of relation Δ 124 using only a relevant subset of invalidation notifications received from invalidation notifier 122 . For example, relational storage engine 112 may receive a transaction request that requires data designated as invalid by invalidity notifier 122, and may thereafter require immediate updates for at least those data items that need to provide current, accurate results for the transaction request in question. Relationship Δ124.

Additionally, in updating relational data 124 based on notifications received from invalidation notifier 122, operation of relational storage engine 112 may vary based on other factors. For example, such update procedures may vary based on the type of invalidation notification received. For example, where an invalidation notification indicates deletion of a particular data record from key-value store 108, relational storage engine 112 may simply need to associate the related data record as unavailable within relation Δ124, and may not need to actually retrieve data from relation Δ124 at all. Related data records are deleted until a full synchronization of key-value store 108 and relational data store 114 is performed, such as by synchronizer 119 . On the other hand, in instances where new data is created, inserted, or added to key value Δ120, it may therefore be necessary to update relation Δ124 using one or more of the techniques described in order to provide fast, accurate result.

Along with notifying the relational storage engine of the data invalidation caused by the transactional execution of the current write request (614), the key-value storage engine 110 may also update the key value Δ120 itself. For example, as can be appreciated, where data is deleted from key-value store 108, a corresponding update to key value Δ 120 can be performed (616). For example, a mirror image of the affected data record may be included within the key Δ 120 and either marked as deleted/invalid, or changed to reflect the underlying write operations involved in the running transaction.

Therefore, along with the update of the key value Δ120 (616), a transaction result (610) may be returned. As shown, requests can continue to be accepted thereafter (602), so that subsequent transactional requests classified as simple (604) can continue to be processed in the manner just described, including using Any update of the key value Δ120.

Meanwhile, transactional requests classified as complex (604) by request processor 116 may be forwarded to relational storage engine 112 so the transaction may be executed (618). In running a transaction, it will be appreciated that the relational store engine 112 is configured to utilize the relational delta 124 in conjunction with the relational data store 114 in order to ensure that the results of the running transaction are current and accurate (specifically, relation Δ 124 will reflect at least an indication of the invalidity of relevant data required to process the current transaction request, as discussed and shown above with reference to arrow 615 ). In any case, as described, by ensuring that at least the required portion of relation Δ 124 required to process a transaction request is current and considered together with relevant data obtained from relational data store 114, relational storage engine 112 can ensure that the Running transactions together provides fast and precise results.

By the nature of the classification of transactional requests received in relational storage engine 112 , it is highly likely that execution of the associated transaction ( 618 ) would result in updates or other changes to relational data store 114 being unnecessary. Accordingly, invalidation notifier 126 , similar to invalidation notifier 122 , may proceed to notify key-value store engine 110 of the invalidation of data affected by the running transaction ( 620 ). Specifically, as shown by arrow 621 , the invalidation notifier 126 may issue an invalidation notification to the key value Δ120 . As described above with reference to the invalidation notifier 122, such a notification may only provide enough information to prevent the key-value store engine 110 from erroneously using stale data. Thereafter, a partial or full synchronization of key-value delta 120 and key-value store 108 may be performed to also ensure that any subsequent results returned by the key-value store engine (eg, in operation 610 ) are current and accurate.

As can be appreciated by the nature of the key-value store 108, this update (616) to the key value Δ 120 may ultimately rely on the operation of the result calculator 106 to provide the key-value store engine 110 with the current, precise data. For example, result calculator 106 may populate key-value store 108 , including running certain calculations based on underlying data from database 102 and/or relational data store 114 , as described. When such underlying data changes, eg, as a result of relational storage engine 112 operations in processing transactional requests, then calculations based on such changed data must also be updated in order to provide current, accurate results. Such updates may be run as part of one or more synchronization processes, as described herein, and in particular, the operation of result calculator 106 in updating key Δ 120 is described in detail below with reference to FIG. 7 .

Then, along with notifying the key-value store engine 110 that the data is invalid (620), the relational store engine 112 may proceed to update the relation Δ124 (622). Transaction results may then be returned to the application 104/user 102 (624), and requests may continue to be accepted thereafter (602).

Thus, operations 602-624 of flowchart 600 illustrate that system 100 of FIG. 1 can receive and process a large number of transaction requests received in parallel in a very fast and efficient manner while maintaining a high level and accuracy of completion. Over time, during such operations, it will be appreciated that the content of key values 120 and relationships Δ 124 may grow and accumulate to undesired data volume levels. For example, notifications of data invalidation may accumulate within one or both of the key Δ 120 and/or the relationship Δ 124 . More generally, the total size of key values Δ 120 and/or relationships Δ 124 can grow to be undesirably large. In this case, the above-described benefits of maintaining and using keys Δ120 and relationships Δ124 may be partially or completely offset, as the computational resources required to maintain and use keys Δ120 and relationships Δ124 may ultimately outweigh the benefits described above.

Accordingly, it may be necessary or desirable to perform one or more synchronization processes (626). In this regard, it can be appreciated that there are at least three different types of synchronization processes mentioned above, which can be implemented at different time scales and/or in response to different triggering events.

For example, one type of synchronization that may be performed includes updating one or both of the key value Δ 120 and the relation Δ 124 to update the data contained in the Data in key value Δ120 and relation Δ124. As described, such synchronization may occur relatively frequently, and may occur with the synchronization of only those portions of data that are marked as invalid as required by current or predicted transactions.

The second type of synchronization refers to the synchronization of key value Δ 120 and relation Δ 124 with key value store 108 and relational data store 114 . During such synchronization, all changes made to the data and reflected in either or both of key value Δ 120 and relation Δ 124 may be reflected by corresponding modifications of key value store 108 and relational data store 114 . Thus, upon completion of such a synchronization process, the contents of key-value store 108 and relational data store 114 will be at least temporarily consistent with each other, and key-value Δ 120 and relation Δ 124 may themselves be at least temporarily emptied.

For the third type of synchronization, also as discussed above, all transactions run by the relational storage engine 112 may be reflected in the transaction record 118 . Thus, during the third type of synchronization process, database 102 may be updated to reflect all such tracked transactions and associated data. Therefore, transaction log 118 may also be temporarily emptied until a new transaction is received. In some embodiments, the contents of the transaction record 118 may be maintained for long-term use by the result calculator 106 in determining whether and how to calculate certain results for inclusion within the key-value store 108 .

As can be appreciated, synchronizer 119 may be configured to facilitate such synchronization along with key-value store engine 110 and/or relational store engine 112 . In general, the operation of synchronizer 119 can be classified as forward synchronization or reverse synchronization. For example, forward synchronization may refer to synchronization caused by transactions processed by the key-value store engine 110, which will be reflected in the key value Δ 124, and thereafter propagated to the relation Δ 124, and thus to the relational data store 114 and thereafter, Propagate to transaction record 118.

In contrast, reverse synchronization may be understood to refer to a synchronization run by synchronizer 119 as a result of a transaction run by relational storage engine 112 . That is, as discussed above and described in detail below with reference to FIG. 7 , receipt of a transaction request in the relational storage engine 112 for execution thereby will generally require an update to the key value Δ 120 , which may need to be calculated in whole or in part from the result Processor 106 to update key value Δ 120, and ultimately key value store 108, in a current, up-to-date manner.

In general, it can be appreciated that the first type of synchronization (ie, synchronization based on invalidation notifications received in Δ120, 124) is likely to occur most frequently and most easily. Meanwhile, a second type of synchronization (ie, updating key-value store 108 and relational data store 114 with corresponding key-value Δ120 and relationship Δ124 along with associated clearing of the contents of Δ120, 124) may occur relatively less frequently. Finally, in the example implementation, the third synchronization process (ie, updating database 102 with transaction records 118 ) needs to occur less frequently.

FIG. 7 is a flowchart 700 illustrating example operation of a reverse synchronization process, generally associated with arrow 621 of FIG. 6 . In the example of FIG. 7 , it is assumed that a complex transaction has been run by the relational storage engine 112 and the relation Δ 124 has been updated in conjunction therewith. Concurrently, the invalidation notifier 126 may notify the key-value store engine 110 of such data invalidation (702), as discussed above with reference to FIG. 6 (eg, with reference to operation 620).

As also described above with reference to FIG. 6 , key value Δ 120 may thus be updated ( 704 ) with the corresponding new data value, for example either immediately with a received notification that the data is invalid, or during an associated synchronization process. Result calculator 106 may then be configured to re-run previously performed operations and associated calculations to provide pre-computed results to key-value store 108 , but using the current, updated value of key Δ 120 ( 706 ).

Accordingly, the corresponding output of result calculator 106 may also be stored within key Δ 120 (708). Then, during subsequent transactions run by key-value store engine 110, key-value delta 120 will provide the complete and current data needed to ensure that transactions utilizing key-value store 108 provide current, accurate transaction results.

FIG. 8 is a block diagram illustrating a detailed example implementation of the system of FIGS. 1 and 2 . In the example of FIG. 8, multiple computing devices 802-810 are used individually for different roles in order to implement and optimize the various features and functions described above with reference to FIGS. 1-7.

Specifically, as shown, a load balancer 802 may be utilized to implement the request processor 116, the synchronizer 119, and/or the result calculator 106. At the same time, computing devices 804 , 806 , 808 provide a single, parallel implementation of key-value store components 108 , 110 . Finally in FIG. 8 , a separate computing device 810 is shown implementing the associated memory components 112 , 114 . In an example implementation of the construct of FIG. 8, for example, the relational storage engine 810 may be implemented using the SAP HANA database system, while the various key-value storage engines 804, 806, 808 may be implemented using a Java-based application server.

In example embodiments, the described systems and techniques may be balanced to guarantee transactional isolation where many data changes need to be done together, or, if such doing is not possible, will fail together. However, in the embodiments described herein, it may occur in some scenarios that a subset of such a set of data changes may complete successfully and return corresponding results before the remaining data changes are completed. For example, it may happen that partial results are returned and then the synchronization process cannot be completed successfully, so that the system cannot provide exactly all requested results.

To reduce or eliminate related undesired consequences, transactional isolation can be maintained within a single storage location (eg, 804 or 810 of FIG. 8). The relevant storage engine may then wait before providing the full transaction group with results (or, in the case of one or more change requests failing, before providing a corresponding error message).

Additionally, or alternatively, the synchronization process may be retried (in order to maintain data consistency) in response to the types of synchronization errors discussed above. In the unexpected event of eventual synchronization failure, the requesting application can then be notified so that it can implement any application-specific corrective measures.

Accordingly, implementations such as the example of FIG. 8, as well as various other embodiments of the systems of FIGS. Down. By implementing key-value store engine 110 and key-value store 108 as well as the database layer, rather than the application layer, as shown in the example of FIG. 1 , potential bottlenecks in the database layer can be avoided.

Furthermore, as shown by the example of Figure 8, the systems of Figures 1 and 2 can be easily scaled, thereby utilizing a large number of computing devices running in parallel, so that again, very large amounts of data can be processed at once. Furthermore, the costs associated with achieving such high levels of performance can be significantly reduced, for example, as compared to trying solutions that rely on massive computing resources to achieve similar results.

Embodiments of the various techniques described herein may be implemented in digital electronics, or in computer hardware, firmware, software, or a combination thereof. Embodiments can be implemented as a computer program product, i.e. a computer program tangibly embodied in an information carrier (e.g. in a machine-readable storage device or in a propagated signal) for being executed by data processing means, or controlling, e.g. To program the operation of a processor, computer, or data processing device of multiple computers. A computer program such as the one described above can be written in any form of programming language, including compiled or interpreted languages, and it can be arranged in any form, including as a stand-alone program or as a module, component, subroutine, or suitable for use in other units in the computing environment. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. In general, a computer may also include, or be operably coupled to, receive data from, one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks Or send data to it or both. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including, for example: semiconductor memory devices, such as EPROM, EEPROM and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks ; and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide interaction with the user, embodiments may be implemented with a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user, as well as a keyboard and, for example, a mouse or trackball. on a computer such as a pointing device through which a user can provide input to the computer. Another device can also be used to provide interaction with the user; for example, the feedback provided to the user can be in the form of any sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and the input from the user can be in any form. Forms are received, including sonic, speech, or tactile input.

Embodiments may be implemented in a computing system that includes a back-end component, such as a data server; or a middleware component, such as an application server; or a front-end component, such as a client computer with a graphical user interface or a web browser , through a graphical user interface or web browser, a user may interact with an implementation of the subject matter described in this specification; or any combination of one or more such back-end, middleware or front-end components. Components can be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs") such as the Internet.

While certain features of the described embodiments have been illustrated as described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope of the embodiments.

Claims (20)

1. comprise and be recorded in a system that is on computer readable medium and the instruction that can be run by least one processor, described system comprises:

Request processor, be configured to cause at least one processor described to receive will the transactions requests of affairs of data run in usage data storehouse, and be configured to cause at least one processor described that first transactions requests of this transactions requests is categorized as simple transactions requests, and the second transactions requests of this transactions requests is categorized as complex transaction request.

Key assignments storage engines, that determine before being configured to cause at least one processor described to be used in receive the first transactions requests and run the first affairs of satisfied first transactions requests based on key assignments storages of the precalculated result of data, and be configured to then upgrade if any the key assignments Δ of the change reflecting the key assignments storage caused by the first affairs;

Relational storage engine, be configured to cause at least one processor described to use the relational storage comprising the subset of data to run the second affairs of satisfied second transactions requests, and be configured to the relationship delta then upgrading the change reflecting the relational storage caused by the second affairs if any; And

Synchronizer, is configured to cause at least one processor described to run key assignments based on key assignments Δ and relationship delta and stores and relational storage synchronous.

2. the system as claimed in claim 1, is wherein comprising in wide area information server layer from the described transactions requests of at least one application reception.

3. the system as claimed in claim 1, wherein said request processor is configured to use the precalculated result of key assignments storage, classify based on its criteria for classification being satisfied with the feature of possibility of description the first transactions requests and the second transactions requests.

4. system as claimed in claim 3, comprises result counter, is configured to cause at least one processor described to carry out based on the possibility of the prediction of the transactions requests in the future that will be received by request processor the precalculated result that calculation key stores.

5. system as claimed in claim 4, wherein said synchronizer is configured to cause described result counter based on key assignments Δ and relationship delta is synchronous with this jointly upgrades precalculated result.

6. the system as claimed in claim 1, wherein said key assignments storage engines is configured to determine and the key that the first transactions requests associates, and performs searching of analog value within key assignments stores.

7. the system as claimed in claim 1, wherein said key assignments storage engines comprises Notice Of Nonavailability device, is configured to upgrade relationship delta based on renewal key assignments Δ.

8. system as claimed in claim 7, wherein synchronizer is configured to based on relationship delta and the renewal relational storage of more newly arriving received based on the Notice Of Nonavailability device from key assignments storage engines, and after this empties the content of relationship delta.

9. the system as claimed in claim 1, wherein said relational storage engine comprises Notice Of Nonavailability device, is configured to upgrade key assignments Δ based on more newly arriving of relationship delta.

10. system as claimed in claim 9, wherein said synchronizer is configured to based on key assignments Δ and stores based on the renewal key assignments of more newly arriving that the Notice Of Nonavailability device from relational storage engine receives, and after this empties the content of key assignments Δ.

11. the system as claimed in claim 1, wherein said request processor, key assignments storage engines, relational storage engine and synchronizer realize in the primary memory of system.

12. systems as claimed in claim 11, wherein said relational storage engine be configured to cause at least one update processor described to store transaction journal in the nonvolatile memory and utilize caused by the operation of the first affairs or the second affairs more new database is come to its any change.

13. 1 kinds for running the computer implemented method of the instruction be stored on computer-readable recording medium, described method comprises:

Receive will the transactions requests of affairs of data run in usage data storehouse;

First transactions requests of this transactions requests is categorized as simple transactions requests;

Second transactions requests of this transactions requests is categorized as complex transaction request;

Be used in determine before receiving the first transactions requests and run the first affairs of satisfied first transactions requests based on the key assignments storage of the precalculated result of data;

Use the relational storage comprising the subset of data to run the second affairs of satisfied second transactions requests;

Then upgrade the key assignments Δ reflecting the change that the key assignments caused by the first affairs stores if any;

Then upgrade the relationship delta of the change reflecting the relational storage caused by the second affairs if any; And

Run key assignments based on key assignments Δ and relationship delta to store and relational storage synchronous.

14. methods as claimed in claim 13, wherein upgrade key assignments Δ and comprise and upgrade relationship delta based on this key assignments Δ, and wherein upgrade relationship delta further and comprise and upgrade key assignments Δ based on this relationship delta.

15. methods as claimed in claim 13, wherein saidly synchronously comprise based on key assignments Δ and relationship delta is synchronous with this jointly upgrades precalculated result.

16. 1 kinds of computer-readable recording mediums being visibly embodied in non-provisional comprise the computer program of instruction, and when described instruction is run, described computer program is configured to:

Receive will the transactions requests of affairs of data run in usage data storehouse;

First transactions requests of this transactions requests is categorized as simple transactions requests;

Second transactions requests of this transactions requests is categorized as complex transaction request;

Be used in determine before receiving the first transactions requests and run the first affairs of satisfied first transactions requests based on the key assignments storage of the precalculated result of data;

Use the relational storage comprising the subset of data to run the second affairs of satisfied second transactions requests;

Then upgrade the key assignments Δ reflecting the change that the key assignments caused by the first affairs stores if any;

Then upgrade the relationship delta of the change reflecting the relational storage caused by the second affairs if any; And

Run key assignments based on key assignments Δ and relationship delta to store and relational storage synchronous.

17. computer programs as claimed in claim 16, wherein in renewal key assignments Δ, be configured to when described instruction is run upgrade relationship delta based on this key assignments Δ, and, in renewal relationship delta, be configured to when described instruction is run upgrade key assignments Δ based on this relationship delta.

18. computer programs as claimed in claim 17, wherein saidly synchronously to comprise based on relationship delta and based on the renewal relational storage of more newly arriving received from key assignments storage, and after this empty the content of relationship delta, and further wherein said synchronously comprise based on key assignments Δ and upgrade key assignments based on more newly arriving of receiving from relational storage store, and after this empty the content of key assignments Δ.

19. computer programs as claimed in claim 16, wherein saidly synchronously comprise based on key assignments Δ and relationship delta is synchronous with this jointly upgrades precalculated result.

20. computer programs as claimed in claim 16, are wherein comprising in wide area information server layer from the described transactions requests of at least one application reception.