High conflict transaction processing method and system for shared-nothing architecture distributed database

Abstract

The application discloses a high-conflict transaction processing method for a shared-nothing architecture distributed database, realizes a prototype system, can effectively detect high-conflict load existing in the distributed database, and starts corresponding high-conflict processing strategies, so that the performance of the distributed database system under high-conflict load is improved. The application further provides a high-conflict transaction processing system for the shared-nothing architecture distributed database.

Description

Technical Field

[0001] This invention belongs to the field of distributed database and concurrency control technology based on a shared-nothing architecture (each processing unit has its own CPU / memory / hard disk, there are no shared resources, and the processing units communicate with each other through protocols). It relates to a method and system for handling high-conflict transactions in a shared-nothing architecture distributed database, which is used for distributed transaction processing under high-conflict conditions. Background Technology

[0002] Since 2000, with the rapid development of the Internet, the scale of various applications has continued to grow, which has put forward higher requirements for the continuous online capability of applications. As an important part of Internet applications, this situation has also put forward higher requirements for the scalability and high availability of databases[1]. Traditional single-machine relational databases are no longer suitable for this scenario. In order to meet the challenges of scalability and high availability, distributed databases have emerged.

[0003] From NoSQL to NewSQL[1], distributed databases have made great progress and made great strides in solving transaction consistency and scalability. However, there are still some unresolved challenges. Reference[2] mentions that the throughput of current distributed databases is mainly limited by three factors: (1) the additional overhead of message passing; (2) network bandwidth; and (3) resource contention. With the rapid development of network technology, the first two problems have been greatly alleviated. However, in distributed scenarios, message latency is greatly increased. For example, the cost of a single small message transmission in Ethernet is about 35μs. Without considering disk and network latency, the transaction latency is about 10-60μs[3,4]. Network latency has become the main bottleneck of short transaction latency, and short transactions are the main type of Online Transactional Processing (OLTP). The increase in message latency has worsened the conflict of distributed databases. Studies have shown that the probability of transaction conflict and the latency of accessing a single record are exponentially related[2].

[0004] For the currently popular shared-nothing architecture, logically, there is often a stateless Transaction Component layer for computation and a Data Component layer for storing data and transaction state[5], such as TiDB[6], CockroachDB[7], Spanner[8], FoundationDB[9]. In such an architecture, in high-conflict scenarios, the conflict may increase due to the long time required to detect the conflict, thereby reducing throughput. For example, for optimistic concurrency control protocols such as Percolator

[10] , the transaction needs to detect the conflict in the storage layer when committing and reading data, and before that, the transaction may have already performed multiple network I / O operations, which causes the time when the conflict actually occurs and the time when the conflict is detected to be lengthened.

[0005] In summary, currently, distributed databases with a shared-nothing architecture generally suffer from performance issues under high conflict loads, and the impact of high conflict loads on their performance cannot be ignored. Summary of the Invention

[0006] Shared-nothing architecture distributed databases were developed to address the high scalability and high availability requirements of internet services. Their architecture typically includes a stateless Transaction Component layer for computation and a Data Component layer for storing data and transaction states. Each conflict detection and data access incurs network overhead, leading to excessively long conflict detection chains. To address this issue, this invention proposes a method and system for handling high-conflict transactions in shared-nothing architecture distributed databases. This includes two high-conflict handling strategies: first, pre-locking to roll back some high-conflict transactions in advance, thereby reducing the length of the conflict detection chain; second, using local caching to reduce read operation latency for high-conflict data items, avoiding the performance impact of frequent RPCs on high-conflict data items.

[0007] This invention proposes a method for handling high-conflict transactions in distributed databases with a shared-nothing architecture, comprising the following steps:

[0008] Step 1: Conflict Detection: The conflict detection node (resolver) detects the conflict rate of the key. If the system is currently in a high-conflict state, it collects a set of high-conflict data items and sends them to the monitoring node (monitor). The monitor will randomly select a transaction processing node (proxy) as the high-conflict handling node. The high-conflict state means that many transactions are accessing a data item at the same time, causing many transactions to roll back.

[0009] Step 2: Client determines high-conflict transactions: The client determines whether a transaction is a high-conflict transaction by whether it accesses high-conflict data items, and sends the result to the high-conflict handling node selected in Step 1;

[0010] Step 3: High Conflict Handling: After selecting the high conflict handling node, high conflict transactions are handled by pre-locking and local caching strategies.

[0011] In step one, the resolver node refers to the node responsible for detecting conflicts between transactions, which is divided according to the range of accessed data items. The algorithm for detecting conflicts between transactions is the same as that of FoundationDB[9]. It records the write timestamp of each range. If the read set of a transaction detects that it has been modified by other transactions, that is, the write timestamp of the range is greater than the commit timestamp of this transaction, then the transaction will be rolled back. The monitor refers to the node that monitors the entire cluster, that is, all nodes in the system, and is responsible for operations such as timestamp distribution. High-conflict data items refer to data items on which the probability of a conflict between transactions is relatively high within a certain period of time.

[0012] In step two, the proxy is a transaction processing node responsible for communicating with the client and handling high-conflict transactions. A high-conflict transaction refers to a transaction involving highly conflicting data items.

[0013] In step three, pre-locking refers to adding an extra locking step to the selected high-conflict processing proxy node in addition to the normal optimistic transaction processing flow. During the transaction execution phase, the corresponding lock must be acquired before the resource can be acquired. The algorithm of this locking step is an improvement on MOCC

[11] (in MOCC, the read lock is acquired during the transaction execution phase, while the write lock is acquired during the transaction commit phase, resulting in deadlock). For high-conflict transactions, it is possible to detect the conflict during execution and abort in advance. Local cache refers to the cache maintained on the high-conflict processing node for reading high-conflict data items.

[0014] This invention also provides a system for implementing the above method based on the FoundationDB paper and code. The system is divided into a computation layer and a storage layer. The computation layer includes a monitor, a resolver, and a proxy. The storage layer includes a storage built on memory. The main innovation of the system lies in the conflict detection module and the high conflict handling module.

[0015] Specifically, the conflict detection module includes resolver nodes divided according to the access key range. The conflict detection module detects conflicts in the system. When the conflict becomes large enough, it will start collecting highly conflicting data items and send a certain percentage of highly conflicting data items to the monitor node.

[0016] The high-conflict handling module employs methods such as pre-locking and local caching to reduce transaction execution latency. Pre-locking reduces the execution time of rollback transactions by performing rollbacks earlier in the execution phase; while local caching reduces transaction latency by minimizing read operation latency for highly conflicting data items. These two methods work together to improve system performance under high-conflict loads.

[0017] This invention proposes a method and system for handling high-conflict transactions in shared-nothing architecture distributed databases. It can effectively detect high conflicts in the system and improve system performance by using methods such as pre-locking and local caching, while reducing the latency of abort transactions. A abort transaction refers to a transaction whose final result is a rollback.

[0018] The beneficial effects of this invention include: Compared to existing work, this invention is the first to adopt an early locking strategy similar to MOCC in a distributed scenario, effectively reducing the length of the conflict detection link in high-conflict scenarios and reducing abort transaction latency by up to 23.98%. Simultaneously, local caching is used to reduce read operation latency for highly conflicting data items, avoiding the impact of frequent RPCs on system performance. With a Zipf parameter greater than or equal to 0.85 for the YCSB load, the local cache latency is consistently within 12% of that returned via remote RPC. Using these two strategies, system throughput is improved by up to 84%. Attached Figure Description

[0019] Figure 1 This is a system architecture diagram of the high-conflict transaction processing system of the present invention.

[0020] Figure 2 This is a diagram showing the state changes between high-conflict and low-conflict states in this invention.

[0021] Figure 3 This is a diagram showing the effectiveness of the high-conflict handling strategy in an embodiment of the present invention.

[0022] Figure 4 This is a diagram showing the effectiveness of high-collision detection in an embodiment of the present invention. Detailed Implementation

[0023] The present invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the present invention are all common knowledge and general knowledge in the art, and the present invention does not have any particular limitations.

[0024] Shared-nothing architecture distributed databases were developed to address the high scalability and high availability requirements of internet services. To address the problem of excessively long conflict detection links in shared-nothing architecture distributed databases, this invention proposes a method and system for handling high-conflict transactions in shared-nothing architecture distributed databases.

[0025] This invention proposes a method for handling high-conflict transactions in distributed databases with a shared-nothing architecture, comprising the following steps:

[0026] Step 1: Conflict Detection: The resolver node detects and finds that the system is currently in a high-conflict state, then collects a set of high-conflict data items and sends them to the monitor node;

[0027] Step 2: Client identifies high-conflict transactions: The client determines whether a transaction is a high-conflict transaction and sends the result to the corresponding proxy node;

[0028] Step 3: High Conflict Handling: After selecting the high conflict handling node, implement strategies such as pre-locking and local caching for high conflict transactions.

[0029] In step one, such as Figure 1 The high-conflict detection module detected high conflicts at the resolver node and collected a set of high-conflict data items within a short period of time, such as 1 second. Recording of high-conflict data items only started when the rollback rate reached a certain threshold, preferably 0.05. To prevent false positives (i.e., when there are actually very few transactions), the transaction load (transactions per second) was also limited when recording high-conflict data items. After high-conflict detection was initiated, the skip list index within the resolver node was sent to the background coroutine for the currently conflicting keys during conflict detection. After collection, the background coroutine selected the keys with a certain percentage (λ) of access frequency as the set of high-conflict data items.

[0030]

[0031] Here, `key` represents a specific accessed data item, `Akey` represents the number of times a key is accessed within a certain period, such as 1 second, and `λ` represents a threshold. `λ` is set as the difference between the rollback rate (`abort_rate`) and the rollback rate that triggers the collection of high-conflict data items (`hc_abort_rate_threshold`) during the sampling period, i.e., `λ = abort_rate - hc_abort_rate_threshold`. The reasons for setting `λ` in this way are: first, as `abort_rate` increases, `λ` also increases, ensuring that high-conflict data items are collected into the hot keys when conflicts are higher; second, subtracting `hc_abort_rate_threshold` avoids including some low-conflict keys in the hot keys, reducing the impact on non-high-conflict loads. `hot_keys` has already been sorted by access count from largest to smallest. Every so often, the resolver node sends a high-conflict status request to the monitor node, which contains the current set of high-conflict data items. This continues until the high-conflict phenomenon is eliminated. To avoid unnecessary duplicate sending, the resolver node compares the changes in the set of high-conflict data items each time. If the total number of accesses to newly added high-conflict data items within 1 second is greater than the threshold of 100, then a new set of high-conflict data items will be sent to the monitor. Otherwise, no new set will be sent.

[0032] In step two, the proxy node is a transaction processing node responsible for communicating with the client and handling high-conflict transactions. A high-conflict transaction refers to a transaction involving highly conflicting data items.

[0033] In step three, the method for requesting locks by pre-locking is shown in Algorithm 1, and the algorithm for acquiring locks by transactions is shown in Algorithm 2. The process of requesting locks is similar to that of MOCC

[11] , both of which involve pre-locking. Read locks are acquired during the transaction execution phase, while write locks are acquired only during the commit phase. Locks are always acquired according to the size of the key value, thereby avoiding deadlocks. Locks that are not acquired in order will be released. By using pre-locking, this invention ensures that conflicts can be detected during the execution phase of rollback transactions, thereby shortening the conflict detection chain.

[0034] In Algorithm 1, `priority` refers to the priority of the lock request, `max_priority` refers to the maximum priority of the waiters, `MAX_ALLOWED_WAITERS` refers to the maximum number of waiters allowed, `GRANTED` means the result is allowed to acquire the lock, and `ABORTED` means the result is not allowed to acquire the lock.

[0035] In Algorithm 2, `violations` refers to the set of locks that do not conform to the locking order. `locks.release(violations)` means releasing the locks that do not conform to the locking order from the currently acquired locks. `lock_table.lock(record, request_mode)` means acquiring the lock for the corresponding record according to the requested lock mode (request_mode).

[0036] The main difference between this invention and MOCC is that, as shown in lines 11-12 of Algorithm 1, in the design of this invention, only the writer is allowed to wait for the reader, and the reader is not allowed to wait for the writer; the second difference is that, as shown in lines 5-10 of Algorithm 1, when requesting a lock, the number of read locks that can be acquired for the same record at the same time is also limited, so as to avoid the phenomenon of lock thrashing (that is, due to too many transactions waiting for the same lock, the lock waiting chain is too long, which leads to a rapid decline in performance). As shown in lines 6-7 of Algorithm 2, the third difference is that, in order to solve the deadlock problem, MOCC

[11] will directly release locks that do not conform to the locking order when locking. In the design of this invention, this mechanism is only triggered when acquiring a write lock. This is because there is no conflict between reads and reads, and the conflict between reads and writes, since the reader is not allowed to wait for the writer, can only be write pointing to read; therefore, acquiring a new read lock will not cause a deadlock, so locks that do not conform to the locking order can be retained when acquiring a read lock.

[0037] In a high-conflict strategy, the high-conflict handling proxy node can also maintain a local cache, caching all high-conflict data items. The cache consistency strategy is a write-through strategy (i.e., data is synchronously updated to both the local cache and the storage nodes). Each cache maintains a strategy version (strategy_version). When a high-conflict handling node attempts to read from the local cache, it may find that its own strategy_version is inconsistent with the strategy_version of the local cache. In this case, the local cache can be cleared. Simultaneously, for transactions that have already read from the local cache but have not yet been executed or committed, the high-conflict handling node will check the strategy_version of the transaction's read from the local cache upon commit. If it is inconsistent with its own record, the transaction will be rolled back.

[0038] Algorithm 1

[0039]

[0040] Algorithm 2

[0041]

[0042] Basic architecture

[0043] Figure 1 In this context, each node contains modules. The basic architecture of this system is as follows: Figure 1 As shown, it includes four types of nodes: monitor, proxy, resolver, and storage.

[0044] The monitor node consists of two parts: a timestamp sender (sequencer) and a monitoring module. The sequencer is used to distribute timestamps. When a transaction begins to commit, it obtains a commit timestamp from the sequencer, which is used as the timestamp for verifying the read-write set during the commit. The monitoring module is responsible for changing the system state after receiving high-conflict state request requests and low-conflict state request requests.

[0045] System state changes such as Figure 2 As shown, after receiving a high-conflict state request from the resolver node, the monitor node increments its internal strategy_version variable by 1. This strategy_version is a global variable used by the system to identify whether the current concurrency control is a high-conflict handling strategy or a normal strategy. After incrementing the internal strategy_version, the monitor node requests updates to the strategy_version at all proxy nodes. Once all requests are completed, the state change is complete. The client also maintains a strategy_version. When the client sends a request to the proxy, its strategy_version may have expired. In this case, it needs to update the strategy_version from the monitor and retrieve the potentially high-conflict data items. Changing from a high-conflict state to a low-conflict state is similar, but the request is sent from the proxy node. This is because the proxy node knows how many transactions are currently high-conflict. If the number of high-conflict transactions is below 1000 per second for five consecutive seconds, it can send a request to the monitor node to change the system's concurrency control strategy.

[0046] In addition to detecting conflicts between transactions, the resolver node includes a high-conflict detection module. This module has two functions: first, detecting and identifying when the system is currently in a high-conflict state; and second, collecting a set of high-conflict data items. After a transaction is sent to the proxy node, the proxy node starts a coroutine to process the transaction. Besides its own transaction processing capabilities, the proxy node also includes a high-conflict handling module, which employs two methods: pre-locking and local caching.

[0047] The storage node is a memory-based storage node that internally maintains 5 seconds of multi-version data. Data older than 5 seconds is unversioned. The transaction completes the commit process after the data is applied to the storage node.

[0048] Experimental conclusions

[0049] Experimental environment

[0050] Experimental hardware configuration: This system is deployed across 6 nodes. Three nodes are configured with 4 vCPUs and 16GB of memory, with Intel Xeon Platinum (Cooper Lake) 8369 CPUs. The other three nodes are configured with 4 vCPUs and 8GB of memory, with Intel Xeon (Ice Lake) Platinum 8369B CPUs. Three storage nodes are deployed on three 4 vCPU 16GB nodes, three resolver nodes are each deployed on one 4 vCPU 8GB node, three proxy nodes and one monitor node are each deployed on one 4 vCPU 8GB node, and the client is deployed on one 4 vCPU 8GB node.

[0051] Test load

[0052] The test load of this experiment is YCSB. The Yahoo! Cloud Serving Benchmark (YCSB)

[12] is a set of load simulations developed by Internet companies to simulate large-scale services. The YCSB evaluation standard with modified load was used in the experiment. The transaction load used in this experiment contains 10 SQL statements. Each SQL statement has an equal probability of being a read or a write. All records involved in the SQL statements are generated according to the same distribution. In this experiment, 500,000 data were loaded. Each data contains 10 columns, and the length of each column is 1000. The resolver node and storage node are evenly divided into all keys according to the range.

[0053] Performance Evaluation

[0054] Experiment 1: The Effectiveness of High-Conflict Handling Strategies

[0055] The Zipf parameter of the YCSB load varied from 0.5 to 1.05. Throughput changes were tested with pre-locking enabled and with pre-locking + local caching enabled. The average value was collected over one minute after throughput stabilized. The experimental results are as follows: Figure 3 As shown in the figure. The Zipf parameter of the YCSB load varies from 0.5 to 1.05, and the experimental results are as follows. Figure 3 As shown, all experimental data were collected as the average value one minute after stabilization. Generally, a Zipf parameter greater than 0.7 can be considered a high-conflict load. Experimental results with a Zipf parameter greater than 0.7 show that the high-conflict handling strategy designed in this paper improves throughput to a certain extent, with a maximum throughput improvement of 84% when the Zipf parameter is 1.05; while the experimental results with a Zipf parameter less than or equal to 0.7 show almost no difference.

[0056] Experiment 2: Effectiveness of High-Collision Detection

[0057] Initially, a uniform load is applied for 20 seconds. Then, a high-conflict load with a Zipf parameter of 0.99 is applied from 20 to 40 seconds. Finally, a uniform load is applied from 40 to 60 seconds.

[0058] The high-conflict strategy has a latency of approximately 3-4 seconds from conflict detection to activation. Pre-locking achieved better throughput than the baseline by the 23rd second, and with local caching enabled, even better throughput was achieved by the 24th second. The time required to reach stable throughput is 6-7 seconds. Pre-locking achieved a stable throughput of approximately 2400 tps by the 26th second, about 20% higher than the baseline. With local caching enabled, a stable throughput of approximately 2900 tps was achieved by the 27th second, about 45% higher than the baseline. Experimental data shows that this invention can efficiently detect conflicts and effectively improve system performance under high-conflict loads after conflict detection.

[0059] References

[0060] [1]Andrew Pavlo and Matthew Aslett. "What's Really New with NewSQL?" In: SIGMOD Rec.45.2(2016), pp.45–55.doi:10.1145 / 3003665.3003674.url:https: / / doi.org / 10.1145 / 3003665.3003674.

[0061] [2]Carsten Binnig et al.“The End of Slow Networks:It’s Time for aRedesign”.In:Proc.VLDB Endow.9.7(2016),pp.528–539.doi:10.14778 / 2904483.2904485.url:http: / / www.vldb.org / pvldb / vol9 / p528-binnig.pdf.

[0062] [3]Franz et al.“The SAP HANA Database–An Architecture Overview”.In:IEEE Data Eng.Bull.35.1(2012),pp.28–33.url:http: / / sites.computer.org / debull / A12mar / hana.pdf.

[0063] [4]Robert Kallman et al.“H-store:a high-performance,distributed mainmemory transaction processing system”.In:Proc.VLDB Endow.1.2(2008),pp.1496–1499.doi:10.14778 / 1454159.1454211.url:http: / / www.vldb.org / pvldb / vol1 / 1454211.pdf.

[0064] [5]David B.Lomet et al.“Unbundling Transaction Services in theCloud”.In:Fourth Biennial Conference on Innovative Data Systems Research,CIDR2009,Asilomar,CA,USA,January 4-7,2009,Online Proceedings.www.cidrdb.org,2009.url:http: / / www.db.cs.wisc.edu / cidr / cidr2009 / Paper%5C_53.pdf.

[0065] [6]Dongxu Huang et al.“TiDB:A Raft-based HTAP Database”.In:Proc.VLDBEndow.13.12(2020),pp.3072–3084.doi:10.14778 / 3415478.3415535.url:http: / / www.vldb.org / pvldb / vol13 / p3072-huang.pdf.

[0066] [7]Rebecca Taft et al.“CockroachDB:The Resilient Geo-Distributed SQLDatabase”.In:Proceedings of the 2020 International Conference on Managementof Data,SIGMOD Conference 2020,online conference[Portland,OR,USA],June 14-19,2020.Ed.by David Maier et al.ACM,2020,pp.1493–1509.doi:10.1145 / 3318464.3386134.url:https: / / doi.org / 10.1145 / 3318464.3386134.

[0067] [8]James C.Corbett et al.“Spanner:Google’s Globally-DistributedDatabase”.In:10th USENIX Symposium on Operating Systems Design andImplementation,OSDI 2012,Hollywood,CA,USA,October 8-10,2012.Ed.by ChanduThekkath and Amin Vahdat.USENIX Association,2012,pp.251–264.url:https: / / www.usenix.org / conference / osdi12 / technical-sessions / presentation / corbett.

[0068] [9]Jingyu Zhou et al.“FoundationDB:A Distributed UnbundledTransactional Key Value Store”.In:SIGMOD’21:International Conference onManagement ofData,Virtual Event,China,June 20-25,2021.Ed.by Guoliang Li etal.ACM,2021,pp.2653–2666.doi:10.1145 / 3448016.3457559.url:https: / / doi.org / 10.1145 / 3448016.3457559.

[0069]

[10] Daniel Peng and Frank Dabek.“Large-scale Incremental ProcessingUsing Distributed Transactions and Notifications”.In:9th USENIX Symposium onOperating Systems Design and Implementation,OSDI 2010,October 4-6,2010,Vancouver,BC,Canada,Proceedings.Ed.by Remzi H.Arpaci-Dusseau and BradChen.USENIX Association,2010,pp.251–264.url:http: / / www.usenix.org / events / osdi10 / tech / full%5C_papers / Peng.pdf.

[0070]

[11] Tianzheng Wang and Hideaki Kimura.“Mostly-Optimistic ConcurrencyControl for Highly Contended Dynamic Workloads on a Thousand Cores”.In:Proc.VLDB Endow.10.2(2016),pp.49–60.doi:10.14778 / 3015274.3015276.url:http: / / www.vldb.org / pvldb / vol10 / p49-wang.pdf.

[0071]

[12] Brian F.Cooper et al. "Benchmarking cloud serving systems withYCSB".In:Proceedings of the 1st ACM Symposium on Cloud Computing,SoCC 2010,Indianapolis,Indiana,USA,June 10-11,2010.Ed.by Joseph M.Hellerstein,SurajitChaudhuri,and Mendel Rosenblum.ACM,2010,pp.143–154.doi:10.1145 / 1807128.1807152.url:https: / / doi.org / 10.1145 / 1807128.1807152.

[0072] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of this invention are included in this invention and are protected by the appended claims.

Claims

1. A method for handling high-conflict transactions in a distributed database with a shared-nothing architecture, characterized in that, Includes the following steps: Step 1: The conflict detection node detects the conflict rate of the key. If the detection finds that the system is currently in a high conflict state, it collects a set of high-conflict data items and sends them to the monitoring node. Step 2: The client determines whether the transaction is a high-conflict transaction and sends it to the high-conflict processing node selected in Step 1; Step 3: After selecting the high-conflict processing node, pre-lock and local cache the high-conflict transactions; In step three, pre-locking is an additional locking process added outside the normal execution flow. It only allows writers to wait for readers, but not readers to wait for writers. When requesting a lock, it also limits the number of read locks that can be acquired for the same record at the same time. When acquiring a read lock, locks that do not conform to the locking order are reserved. Read locks are acquired during the transaction execution phase, while write locks are acquired only during the commit phase. Locks are always acquired according to the size of the key value, and locks that are not acquired in order will be released. In step three, the high-conflict processing node maintains a local cache to cache all high-conflict data items; When a high-conflict handling node attempts to read the local cache, if it finds that its own policy version is inconsistent with the policy version of the local cache, it clears the local cache. For transactions that have read the previous local cache but have not yet been executed or committed, the high-conflict handling node checks the policy version of the transaction that read the local cache when committing. If it is inconsistent with the version it recorded, the transaction is rolled back.

2. The method for handling high-conflict transactions in a distributed database with a shared-nothing architecture as described in claim 1, characterized in that, In step one, the abort rate of each conflict detection node is detected at the conflict detection node. When the abort rate is higher than the threshold, the recording of high-conflict data items is initiated.

3. The method for handling high-conflict transactions in a distributed database with a shared-nothing architecture as described in claim 2, characterized in that, The threshold is set to 0.

05.

4. The method for handling high-conflict transactions in a distributed database with a shared-nothing architecture as described in claim 1, characterized in that, In step one, a certain percentage of the set of highly conflicting data items are selected and sent to the monitoring node. Here, 'key' represents a specific data item being accessed, and 'Akey' represents the number of times a specific key has been accessed within a given time period. Indicates the threshold. The value set is the difference between the rollback rate during the sampling period and the rollback rate that triggers the collection of highly conflicting data items. = Rollback rate during sampling time - Rollback rate that triggers collection of highly conflicting data items.

5. The method for handling high-conflict transactions in a distributed database with a shared-nothing architecture as described in claim 1, characterized in that, In step two, the client determines whether a transaction is a high-conflict transaction based on the transaction ID and the transaction's input and output. For high-conflict transactions, the client sends them to the corresponding high-conflict processing node.

6. The method for handling high-conflict transactions in a distributed database with a shared-nothing architecture as described in claim 1, characterized in that, In step three, the system maintains a global policy version to identify the version of the conflict handling policy. After receiving a high conflict status request from the conflict detection node, the monitoring node changes its internal policy version and then updates the policy version at the transaction processing node. After discovering that its policy version is incorrect, the client requests the monitoring node to update its policy version and the corresponding conflict handling policy.

7. A system for implementing the method as described in any one of claims 1-6, characterized in that, The system includes a collision detection module and a high-collision processing module; wherein... The conflict detection module controls when to collect high-conflict data items by using the rollback rate, and sends high-conflict data items to the monitoring node according to the ratio of load change. The core of the high-conflict handling module lies in using two methods—pre-locking and local caching—to increase system performance.

Images