[go: up one dir, main page]

WO2016032548A1 - Fourniture d'un support transactionnel à un système de stockage de données - Google Patents

Fourniture d'un support transactionnel à un système de stockage de données Download PDF

Info

Publication number
WO2016032548A1
WO2016032548A1 PCT/US2014/060705 US2014060705W WO2016032548A1 WO 2016032548 A1 WO2016032548 A1 WO 2016032548A1 US 2014060705 W US2014060705 W US 2014060705W WO 2016032548 A1 WO2016032548 A1 WO 2016032548A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
record
client
data storage
storage system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2014/060705
Other languages
English (en)
Inventor
Krishnaprasad Lingadahalli SHASTRY
Sandesh V. MADHYASTHA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of WO2016032548A1 publication Critical patent/WO2016032548A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2315—Optimistic concurrency control
    • G06F16/2322—Optimistic concurrency control using timestamps
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing

Definitions

  • FIG. 1 is a block diagram of an example computing environment for providing transactional support to a data storage system
  • FIG. 2 illustrates a sequence diagram for an example transaction
  • FIG. 3 is a block diagram of an example computing device for providing transactional support to a data storage system
  • FIG. 4 is a flowchart of an example method for providing transactional support to a data storage system
  • FIG. 5 is a block diagram of an example system for providing transactional support to a data storage system.
  • Big data may include data sets with sizes beyond the ability of commonly used software applications and tools to capture, manage, and process the data within a reasonable time. For example, big data may include a few dozen terabytes to petabytes of data in a single data set.
  • a NoSQI database such as HBase, Cassandra, etc. may be a distributed database.
  • a distributed database is a database in which sections of the database may be stored on multiple computer systems within a network. Data may be stored on multiple computers or storage devices, located at same physical location or different geographical locations, connected over a network.
  • a distributed database may lack "transactional support" functionality, typically provided by a Relational Database Management System.
  • a "transaction” may be defined as a sequence of read and/or write operations that may be conceptually related. Transactions are designed to maintain database integrity in a known, consistent state, by ensuring that interdependent operations on the system complete successfully or all the operations are cancelled. However, there may be instances when concurrent transactions may occur. Transactions are said to be “concurrent” if they are being executed simultaneously. To avoid concurrency, database transactions are expected to satisfy a set of properties. These include atomicity, consistency, isolation, and durability. They are also commonly known by the acronym ACID.
  • the "isolation" property defines that no transaction would interfere with another concurrent transaction. In other words, the intermediate steps of a transaction are invisible to other transactions.
  • One of the mechanisms for managing isolation includes Snapshot Isolation (SI).
  • SI Snapshot Isolation
  • a transaction operates on a "private" snapshot of the database, taken at the start of the transaction. When the transaction concludes, it will successfully commit only if the values updated by the transaction have not been changed externally since the snapshot was taken. Snapshot isolation may involve use of timestamps.
  • Timestamps are unique sequence of characters or encoded information identifying when a certain event occurred (for example, by usually providing date and time of day). Timestamps can facilitate multiple versions of data in a database. They may be defined by a user when the data value is inserted, or implicitly assigned by the system.
  • SI a transaction acquires a start timestamp, at the beginning of its execution, and acquires a commit timestamp, at the end of its execution.
  • a transaction is said to be "committed” when the modifications done by the transaction are made visible to other transactions.
  • a transaction that commits successfully is called a committed transaction.
  • a transaction support based on optimistic concurrency is required to implement a mechanism to hide the intermediate modification to the data from other concurrent transactions.
  • Some of the present mechanisms to handle this requirement either create additional metadata tables in the database to store information about intermediate modifications, or modify an existing database schema. Needless to say, such intrusion into a database is undesirable.
  • a transaction server may receive, from a client, a transaction request related to a record in a data storage system.
  • the transaction sever may provide a unique transaction ID for the transaction request and last commit timestamp related to the record to the client, wherein the transaction ID is a timestamp value equal to or less than epoch time.
  • the client may obtain a version of the record, corresponding to the last commit timestamp, from the data storage system.
  • the client may update the version of the record, corresponding to the last commit timestamp, to generate an updated record in the data storage system, wherein the updating comprises including the unique transaction ID in the updated record.
  • the transaction server may receive a request from the client to commit the updated record.
  • the transaction server may determine whether a conflict related to the transaction request exists. In response to the determination that no conflict related to the transaction request exists, the updated record may be committed in the data storage system.
  • FIG. 1 is a block diagram of an example computing environment 100 for providing transactional support to a data storage system.
  • Computing environment 100 may include a client computing devices 102, 104, and 106, a transaction server 108, and a database (or data storage system) 1 10.
  • Client computing devices may be communicatively coupled to transaction server 108 and database 1 10 via a computer network.
  • Computer network may be a wireless or wired network.
  • Computer network may include, for example, a Local Area Network (LAN), a Wireless Local Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like.
  • LAN Local Area Network
  • WAN Wireless Local Area Network
  • MAN Metropolitan Area Network
  • SAN Storage Area Network
  • CAN Campus Area Network
  • computer network may be a public network (for example, the Internet) or a private network (for example, an intranet).
  • client computing devices may directly communicate with database 1 10.
  • Client computing devices 102, 104, and 106 generally represent any type of computing systems capable of reading machine-executable instructions. Examples of client computing devices 102, 104, and 106 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.
  • PDA personal digital assistant
  • the number of client computing devices shown in FIG. 1 is for the purpose of illustration only and their number may vary in other implementations.
  • Client computing devices 102, 104, and 106 may each include one or more computer applications (machine-executable instructions) 1 12, 1 14, and 1 16 for carrying out a transaction(s) on a database 1 10.
  • client computing devices 102, 104, and 106 may each include a transaction client (for example, a library) 1 18, 120, and 122 that may provide transaction management APIs such as beginTransaction, endTransaction, etc.
  • Transaction client e.g., 102, 104, or 106
  • Transaction client may also extend generic API's related to database, such as get, put, etc. to provide transaction support.
  • transaction client in case a computer application (example, 1 12) on a client computing device (example, 102) wish to perform a transaction related to a record in a database 1 10, transaction client (example, 1 18) may generate a transaction request for carrying out a transaction related to the record.
  • the client computing device may send the request to a transaction server (example, 108).
  • the transaction server (example, 108) may generate and assign a unique transaction ID to the transaction request, which is then shared with the client computing device (example, 102).
  • the unique transaction ID is a timestamp value equal to or less than epoch time (or Unix time).
  • Epoch time or Unix time
  • Epoch time is a system for describing instants in time, defined as the number of seconds that have elapsed since January 1 , 1970.
  • the transaction server may also provide, to the client computing device (example, 102), the last commit timestamp value related to the record.
  • a "last commit timestamp value" of a record is a value that was assigned to the record when it was last committed.
  • the client computing device may use the last commit timestamp of the record to obtain, from the database (example, 1 10), a version of the record, corresponding to the last commit timestamp. This version would be the latest version of the record in the database (example, 1 10).
  • database may be a multi-version data storage system.
  • database may store multiple versions of a record.
  • each version of the record may include a unique timestamp value.
  • the latest version of the record may include the last commit timestamp value.
  • the client computing device (example, 102) may use the last commit timestamp value to obtain the latest version of a record from a database (example, 1 10).
  • the client computing device may modify or update the latest version of the record to generate an updated or modified record in the database (example, 1 10). Updating of the record may include modifying an existing value in the record or inserting a new value in the record. In an instance, while updating, the client device (example, 102) may insert or include the unique transaction ID, which it had received from the transaction server (example, 108), in the updated record. A record updated in this manner by a transaction will not be visible to other transactions since any other transaction (for example, a read operation) would use timestamp value of January 1 , 1970 (or a later value) as the starting value for a timestamp range. Fig.
  • an application on a client device may initiate a transaction call (begin Trx) 202 related to a record (in a database, for example, Hbase) to a transaction client, which in turn may generate a transaction request based on the transaction call and send it to transaction server.
  • transaction server may generate and assign a unique transaction ID (Return Txid) 204 to the transaction request, which is then shared with the client computing device.
  • the unique transaction ID is a timestamp value equal to or less than epoch time (or Unix time).
  • Transaction server may also provide, to the client computing device, the last commit timestamp (LCT) value 206 related to the record.
  • LCT last commit timestamp
  • the client device may use the LCT value of the record (for example, via Get (ekeyl , LCT)) to obtain 208, from the database, a version of the record (for example, Return (rKeyl , vail )), corresponding to the last commit timestamp. This version would be the latest version of the record in the database.
  • the client computing device may modify or update the latest version of the record (for example, using put (rKeyl , val2, Txid) 212 to generate an updated or modified record in the database. While updating, the client device may insert or include the unique transaction ID (for example, Txid), which it had received from the transaction server, in the updated record.
  • the client may first look for the rows corresponding to its transaction ID thereby only reading its own changes. If a row is not modified by other transactions, the "get” and “scan” operations may read data which is greater than the timestamp value of January 1 , 1970 and less than the last commit timestamp of the transaction. Thus, an intermediate "put" operation done by a transaction will not be visible to other transactions.
  • the client computing device may send a request (for example, commitTransaction) 214 to the transaction server to commit the updated record.
  • the transaction server may determine whether a conflict related to the transaction request exists 216 (for example, ChkConflict (Txid, M_r)).
  • the transaction server may provide a success response to the transaction client (for example, Return (Success, CT) 218, and the updated record may be committed in the database (for example, put (rKeyl , val2, CT)).
  • the status in the transaction server is marked as "committed” and the LCT is updated 222. At this point, the updated record is visible to other transactions.
  • Transaction server may include machine-readable instructions to generate a unique transaction ID for each transaction request that it may receive from a client computing device (example, 102).
  • the unique transaction ID is a timestamp value equal to or less than epoch time (or Unix time), as explained above.
  • Transaction server may maintain the start timestamp and the commit timestamp of a transaction.
  • a transaction acquires a start timestamp, at the beginning of its execution, and acquires a commit timestamp, at the end of its execution.
  • Transaction server (example, 108) may maintain the state of transactions and include instructions to resolve conflicts during the transactions.
  • the transaction server may also provide, to the client computing device (example, 102), from which it had received a transaction request related to a record in a database (example, 1 10), the last commit timestamp value related to the record.
  • a "last commit timestamp value" of a record is a value that was assigned to the record when it was last committed.
  • the client computing device may use the last commit timestamp of the record to obtain, from the database, a version of the record, corresponding to the last commit timestamp.
  • the client computing device may modify or update said version of the record to generate an updated or modified record in the database.
  • the client device while updating, may insert or include the unique transaction ID, which it had received from the transaction server (example, 108), in the updated record.
  • the transaction server may receive a request from the client device (example, 102) to commit the updated record.
  • the transaction server may determine whether a conflict related to the transaction request exists. In case no conflict related to the transaction request exists, the updated record may be committed in the database.
  • Various example components e.g., a timestamp generation module 302, a conflict resolution module 304, a logging module 306, and a recovery module 308) of transaction server are described in detail below in reference to FIG. 2.
  • computing environment 100 may include an additional backup transaction server to take care of the failure of transaction server. If the master transaction server fails the backup may take over.
  • Database 1 10 may be a repository that stores an organized collection of data.
  • Database 1 10 may store one or more records.
  • database 1 10 may be a distributed database.
  • database 1 10 may use a key-value data structure for storing data. Such data structure provides scalability to the database and allows storage of large amounts of data, for instance, from a few dozen terabytes to petabytes of data in a single data set.
  • database 1 10 may be a multi-version data storage system. In other words, database may store multiple versions of a record. In such case, in an instance, each version of the record may include a unique timestamp value. The latest version of the record may include the last commit timestamp value.
  • FIG. 3 is a block diagram of an example computing device 300 for providing transactional support to a data storage system.
  • Examples of computing device 300 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.
  • computing device 100 is transaction server 108 of FIG. 1 .
  • computing device 300 may include a timestamp generation module 302, a conflict resolution module 304, a logging module 306, and a recovery module 308.
  • module may refer to a software component (machine readable instructions), a hardware component or a combination thereof.
  • a module may include, by way of example, components, such as software components, processes, tasks, co-routines, functions, attributes, procedures, drivers, firmware, data, databases, data structures, Application Specific Integrated Circuits (ASIC) and other computing devices.
  • a module may reside on a volatile or non-volatile storage medium and configured to interact with a processor of a computing device (e.g. 300).
  • Timestamp generation module 302 may receive, from a client, a transaction request related to a record in a distributed database. Timestamp generation module 302 may include instructions to provide a unique transaction ID for the transaction request and last commit timestamp related to the record to the client. In an example, the transaction ID is a timestamp value equal to or less than Unix time.
  • Conflict resolution module 304 may receive, from a client, a request to commit an updated record in the distributed database. In an instance, the updated record is generated by the client by obtaining a version of the record, corresponding to the last commit timestamp, from the distributed database. The client may modify said version of the record to generate an updated record.
  • a modification of said version of the record comprises inserting the unique transaction ID in the updated record.
  • Conflict resolution module 304 may further determine whether a conflict related to the transaction request exists. The conflict resolution module 304 may use the modified record and the transaction start timestamp to determine whether any other transactions modified and committed the same row. In response to the determination that no conflict related to the transaction request exists, conflict resolution module 304 may communicate the same to the client, which in turn may commit the updated record in the distributed database. In such case, the conflict resolution module 304 may also generate a new commit timestamp and send the new commit timestamp to the client.
  • conflict resolution module 304 may mark the transaction for abort and send this information to client device.
  • Logging module 306 may log the functionalities performed by timestamp generation module and conflict resolution module into a persistence space for recovery. If a transaction is marked for abort due to conflicts, the client may return this information without cleaning the temporary updates to the database tables. If the client fails during the transaction execution, recovery module 308 may mark the transaction for abort after a specified duration. The transaction server may implement a background thread to clean all temporary "put" operations from the aborted transactions. If the client fails after the transaction is marked for "commit” then the transaction server background thread may update the corresponding records in the database table using the transaction commit timestamp. [0036] FIG. 4 is a flowchart of an example method for providing transactional support to a data storage system.
  • the method 400 may at least partially be executed on a client computing device (example, 102, 104, or 106) , a transaction server (example, 108), and a database (example, 1 10) of FIG. 1 or transaction server 300 of FIG. 3.
  • client computing device example, 102, 104, or 106
  • transaction server example, 108
  • database example, 1 10
  • a transaction server may receive, from a client, a transaction request related to a record in the data storage system.
  • the transaction sever may provide a unique transaction ID for the transaction request and the last commit timestamp related to the record to the client.
  • the transaction ID is a timestamp value equal to or less than epoch time.
  • the client may obtain a version of the record, corresponding to the last commit timestamp, from the data storage system.
  • the client may update the version of the record, corresponding to the last commit timestamp, to generate an updated record in the data storage system.
  • the updating comprises including the unique transaction ID in the updated record.
  • a transaction server may receive a request from the client to commit the updated record.
  • the transaction server may determine whether a conflict related to the transaction request exists.
  • the updated record may be committed in the data storage system.
  • FIG. 5 is a block diagram of an example system 500 for providing transactional support to a data storage system.
  • System 500 includes a processor 502 and a machine-readable storage medium 504 communicatively coupled through a system bus.
  • Processor 502 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 504.
  • Machine-readable storage medium 504 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 502.
  • RAM random access memory
  • machine-readable storage medium 504 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc.
  • SDRAM Synchronous DRAM
  • DDR Double Data Rate
  • RDRAM Rambus DRAM
  • Rambus RAM Rambus RAM
  • machine-readable storage medium 504 may be a non- transitory machine-readable medium.
  • Machine-readable storage medium 504 may store instructions 506, 508, 510, 512, 514, 516, and 518.
  • instructions 506 may be executed by processor 502 to receive, at a transaction server, a transaction request related to a record in a data storage system, from a client.
  • Instructions 508 may be executed by processor 502 to provide, by the transaction sever, a unique transaction ID for the transaction request and last commit timestamp related to the record to the client, wherein the transaction ID is a timestamp value equal to or less than epoch time.
  • Instructions 510 may be executed by processor 502 to obtain, by the client, a version of the record, corresponding to the last commit timestamp, from the data storage system.
  • Instructions 512 may be executed by processor 502 to update, by the client, the version of the record, corresponding to the last commit timestamp, to generate an updated record in the data storage system, wherein the updating comprises including the unique transaction ID in the updated record.
  • Instructions 514 may be executed by processor 502 to receive, at the transaction server, a request from the client to commit the updated record.
  • Instructions 516 may be executed by processor 502 to determine, by the transaction server, whether a conflict related to the transaction request exists.
  • Instructions 518 may be executed by processor to committing the updated record in the data storage system, in response to the determination that no conflict related to the transaction request exists.
  • Storage medium 504 may further include instructions to generate, in response to the determination that no conflict related to the transaction request exists.
  • Storage medium 504 may also include instructions to send, by the transaction sever, the new commit timestamp to the client, and instructions to update, by the client, the unique transaction ID in the updated record with the new commit timestamp.
  • the example method of FIG. 4 is shown as executing serially, however it is to be understood and appreciated that the present and other examples are not limited by the illustrated order.
  • the example systems of FIGS. 1 , 3, and 5, and method of FIG. 4 may be implemented in the form of a computer program product including computer- executable instructions, such as program code, which may be run on any suitable computing device in conjunction with a suitable operating system (for example, Microsoft Windows, Linux, UNIX, and the like).
  • a suitable operating system for example, Microsoft Windows, Linux, UNIX, and the like.
  • Embodiments within the scope of the present solution may also include program products comprising non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.
  • Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.
  • Such computer-readable media can comprise RAM, ROM, EPROM, EEPROM, CD- ROM, magnetic disk storage or other storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions and which can be accessed by a general purpose or special purpose computer.
  • the computer readable instructions can also be accessed from memory and executed by a processor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Certains exemples de l'invention concernent la fourniture d'un support transactionnel à un système de stockage de données. Dans un exemple, un serveur de transactions peut recevoir, d'un client, une demande de transaction relative à un enregistrement dans un système de stockage de données. Le serveur de transaction peut fournir au client un ID de transaction unique pour la demande de transaction et la dernière estampille temporelle de validation relative à l'enregistrement, l'ID de transaction étant une valeur d'estampille temporelle égale ou inférieure à un cycle. Le client peut obtenir une version de l'enregistrement, correspondant à la dernière estampille temporelle de validation, à partir du système de stockage de données. Le client peut mettre à jour la version de l'enregistrement, correspondant à la dernière estampille temporelle de validation, pour générer un enregistrement mis à jour dans le système de stockage de données, la mise à jour comprenant l'ID de transaction unique dans l'enregistrement mis à jour. Le serveur de transaction peut recevoir du client une demande de validation de l'enregistrement mis à jour. Le serveur de transaction peut déterminer s'il existe un conflit relatif à la demande de transaction. En réponse à la détermination du fait qu'il n'existe pas de conflit relatif à la demande de transaction, l'enregistrement mis à jour peut être validé dans le système de stockage de données.
PCT/US2014/060705 2014-08-25 2014-10-15 Fourniture d'un support transactionnel à un système de stockage de données Ceased WO2016032548A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN4146/CHE/2014 2014-08-25
IN4146CH2014 2014-08-25

Publications (1)

Publication Number Publication Date
WO2016032548A1 true WO2016032548A1 (fr) 2016-03-03

Family

ID=55400246

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/060705 Ceased WO2016032548A1 (fr) 2014-08-25 2014-10-15 Fourniture d'un support transactionnel à un système de stockage de données

Country Status (1)

Country Link
WO (1) WO2016032548A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776837A (zh) * 2016-11-25 2017-05-31 国云科技股份有限公司 一种基于MongoDB的证券实时交易关联分析的方法
CN106844556A (zh) * 2016-12-30 2017-06-13 江苏瑞中数据股份有限公司 一种基于HBase的智能电网时标量测数据存储方法
CN110309152A (zh) * 2019-06-26 2019-10-08 广州探迹科技有限公司 一种基于HBase的数据存储方法及装置
CN110622151A (zh) * 2017-05-15 2019-12-27 谷歌有限责任公司 通过较早地读取时钟来减少分布式多版本数据库中的提交等待
US20210064604A1 (en) * 2019-08-28 2021-03-04 Sparta Method, apparatus, and computer readable medium for generating an audit trail of an electronic data record
EP3800558A1 (fr) * 2016-06-30 2021-04-07 Huawei Technologies Co., Ltd. Procédé de traitement de transaction de base de données, client et serveur
US20220414065A1 (en) * 2017-11-13 2022-12-29 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026413A (en) * 1997-08-01 2000-02-15 International Business Machines Corporation Determining how changes to underlying data affect cached objects
US20020065848A1 (en) * 2000-08-21 2002-05-30 Richard Walker Simultaneous multi-user document editing system
US20080222296A1 (en) * 2007-03-07 2008-09-11 Lisa Ellen Lippincott Distributed server architecture
KR20090102788A (ko) * 2006-12-06 2009-09-30 퓨전 멀티시스템즈, 인크.(디비에이 퓨전-아이오) 전단의 분산된 ｒａｉｄ장치, 시스템 및 방법
US7702739B1 (en) * 2002-10-01 2010-04-20 Bao Tran Efficient transactional messaging between loosely coupled client and server over multiple intermittent networks with policy based routing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026413A (en) * 1997-08-01 2000-02-15 International Business Machines Corporation Determining how changes to underlying data affect cached objects
US20020065848A1 (en) * 2000-08-21 2002-05-30 Richard Walker Simultaneous multi-user document editing system
US7702739B1 (en) * 2002-10-01 2010-04-20 Bao Tran Efficient transactional messaging between loosely coupled client and server over multiple intermittent networks with policy based routing
KR20090102788A (ko) * 2006-12-06 2009-09-30 퓨전 멀티시스템즈, 인크.(디비에이 퓨전-아이오) 전단의 분산된 ｒａｉｄ장치, 시스템 및 방법
US20080222296A1 (en) * 2007-03-07 2008-09-11 Lisa Ellen Lippincott Distributed server architecture

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3800558A1 (fr) * 2016-06-30 2021-04-07 Huawei Technologies Co., Ltd. Procédé de traitement de transaction de base de données, client et serveur
CN106776837A (zh) * 2016-11-25 2017-05-31 国云科技股份有限公司 一种基于MongoDB的证券实时交易关联分析的方法
CN106844556A (zh) * 2016-12-30 2017-06-13 江苏瑞中数据股份有限公司 一种基于HBase的智能电网时标量测数据存储方法
CN110622151A (zh) * 2017-05-15 2019-12-27 谷歌有限责任公司 通过较早地读取时钟来减少分布式多版本数据库中的提交等待
US11556375B2 (en) 2017-05-15 2023-01-17 Google Llc Reducing commit wait in a distributed multiversion database by reading the clock earlier
CN110622151B (zh) * 2017-05-15 2023-07-14 谷歌有限责任公司 通过较早地读取时钟来减少分布式多版本数据库中的提交等待
US20220414065A1 (en) * 2017-11-13 2022-12-29 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases
US12197396B2 (en) * 2017-11-13 2025-01-14 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases
CN110309152A (zh) * 2019-06-26 2019-10-08 广州探迹科技有限公司 一种基于HBase的数据存储方法及装置
US20210064604A1 (en) * 2019-08-28 2021-03-04 Sparta Method, apparatus, and computer readable medium for generating an audit trail of an electronic data record
CN114761940A (zh) * 2019-08-28 2022-07-15 斯巴达系统公司 用于生成电子数据记录的审计跟踪的方法、设备和计算机可读介质
US11675777B2 (en) * 2019-08-28 2023-06-13 Sparta Systems, Inc. Method, apparatus, and computer readable medium for generating an audit trail of an electronic data record

Similar Documents

Publication Publication Date Title
US11874746B2 (en) Transaction commit protocol with recoverable commit identifier
US8442962B2 (en) Distributed transaction management using two-phase commit optimization
EP3117348B1 (fr) Systèmes et procédés pour optimiser une prise en charge multi-version optimisée d'index
US10042910B2 (en) Database table re-partitioning using two active partition specifications
WO2016032548A1 (fr) Fourniture d'un support transactionnel à un système de stockage de données
US9063969B2 (en) Distributed transaction management using optimization of local transactions
CN105630863B (zh) 用于多版本并发提交状态的事务控制块
EP2825957B1 (fr) Systèmes et procédés d'aide à la délégation en ligne de journaux de transaction de niveau intermédiaire vers une base de données
US9189513B1 (en) Distributed, transactional key-value store
US9069704B2 (en) Database log replay parallelization
US9223805B2 (en) Durability implementation plan in an in-memory database system
US9208191B2 (en) Lock-free, scalable read access to shared data structures
US10983981B1 (en) Acid transaction for distributed, versioned key-value databases
US9053153B2 (en) Inter-query parallelization of constraint checking
CN113168371B (zh) 多主共享存储数据库的写-写冲突检测
US10185736B2 (en) Replicable differential store data structure
US12326845B2 (en) Pageable hash index for document store
US20180074919A1 (en) Hybrid Database Concurrent Transaction Control
AU2016244128A1 (en) Processing database transactions in a distributed computing system
US12032560B2 (en) Distributed transaction execution management in distributed databases
US20180210914A1 (en) Consistent query of local indexes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14900814

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14900814

Country of ref document: EP

Kind code of ref document: A1