Method, device, server and storage medium for data updating

Abstract

The present disclosure relates to a method, device, server and storage medium for data updating. The method comprises: obtaining a first update transaction request and a second update transaction request from a group of update transaction requests, wherein the group comprises update transaction requests for a same hot data row in a database; in a case where the first update transaction request is updated successfully, updating an operator of the first update transaction request with an operator in the second update transaction request to obtain an updated first update transaction request; and executing the updated first update transaction request to update data in the hot data row in batches and generate an update result. The present disclosure can improve the update performance of the hot data row.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to methods, apparatus, servers and storage media for data updating. Background Technology

[0002] With the development of computer technology, database technology emerged. In many scenarios, a large number of requests may suddenly access a small number of data rows within a short period of time. These data rows, which are frequently subjected to operations such as adding, deleting, modifying, and querying, are called hot rows. (Reference) Figure 1 As shown, when performing an update operation on a hot row, a row lock needs to be added to the hot row before the update is performed. After the update is completed without any failures, the log is recorded, the operation is committed, the row lock is released, and then a response is sent to the client.

[0003] In hot row scenarios, many updates involve operations on the same row. Since row locks for updating the same row are mutually exclusive, only one operation can successfully acquire the lock at any given time. Other update operations must wait for the lock to be released before they can acquire the lock and update. Locking, releasing, and logging are all time-consuming operations, resulting in extremely low update performance for hot rows, making it difficult to meet business requirements. Summary of the Invention

[0004] This disclosure provides a method, apparatus, server, and storage medium for data updating. It aims to at least address the technical problem of low performance in updating hot rows in related technologies. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a method for updating data is provided, comprising:

[0006] Obtain the first update transaction request and the second update transaction request from the group of update transaction requests, wherein the group includes update transaction requests for the same hot data row in the database;

[0007] If the first update transaction request is successful, the operators of the first update transaction request are updated using the operators in the second update transaction request to obtain the updated first update transaction request;

[0008] Execute the first update transaction request after the update to update the data in the hot data rows in batches and generate update results.

[0009] In one possible implementation, before obtaining the first update transaction request and the second update transaction request from the group of update transaction requests, the method further includes:

[0010] Update transaction requests for hot data rows are retrieved from the task queue at preset time intervals, and grouped into groups for different hot data rows. The task queue is used to store update transaction requests for hot data rows.

[0011] In one possible implementation, the task queue includes a first task queue and a second task queue, and the grouping includes a first grouping and a second grouping;

[0012] The step of retrieving update transaction requests for hot data rows from the task queue at preset time intervals, and grouping update transaction requests for different hot data rows, includes:

[0013] Update transaction requests for hot data rows are retrieved from the first task queue at preset time intervals to obtain the first group of update transaction requests for different hot data rows;

[0014] When all update transaction requests in the first task queue have been grouped and completed, a second group of update transaction requests is obtained from the second task queue, wherein the second task queue is used to store update transaction requests of hot data rows when grouping update transaction requests in the first task queue.

[0015] In one possible implementation, obtaining the first update transaction request and the second update transaction request from the group of update transaction requests includes:

[0016] The first update transaction request is determined from the group of update transaction requests as the first update transaction request, and the remaining update transaction requests are determined as the second update transaction requests;

[0017] If the first update transaction request fails, a second update transaction request is determined from the group as the first update transaction request, and all update transaction requests in the group other than the second update transaction request are determined as the second update transaction requests.

[0018] In one possible implementation, updating the operator of the first update transaction request using the operator in the second update transaction request to obtain the updated first update transaction request includes:

[0019] The context information in the first update transaction request is retained, and the operators in the first update transaction request are replaced with the operators in the second update transaction request to obtain the updated first update transaction request.

[0020] In one possible implementation, updating the operator of the first update transaction request using the operator in the second update transaction request to obtain the updated first update transaction request includes:

[0021] The operators in the second update transaction request are kept unchanged, and the context information in the second update transaction request is replaced with the context information in the first update transaction request to obtain the updated first update transaction request.

[0022] In one possible implementation, after executing the first update transaction request following the update, to batch update the data in the hot data rows and generate update results, the process further includes:

[0023] The update results are sent to the client corresponding to the first update transaction request and the client corresponding to the second update transaction request, respectively.

[0024] In one possible implementation, after executing the first update transaction request following the update, to batch update the data in the hot data rows and generate update results, the process further includes:

[0025] Submit the update results and generate the update log corresponding to the group.

[0026] According to a second aspect of the present disclosure, a data updating apparatus is provided, comprising:

[0027] The acquisition module is used to acquire a first update transaction request and a second update transaction request from a group of update transaction requests, wherein the group includes update transaction requests for the same hot data row in the database;

[0028] The first update module is used to update the first update transaction request with the operators in the second update transaction request when the first update transaction request is successfully updated, so as to obtain the updated first update transaction request.

[0029] The second update module is used to execute the updated first update transaction request to update the data in the hot data rows in batches and generate update results.

[0030] In one possible implementation, the method further includes:

[0031] The grouping module is used to retrieve update transaction requests for hot data rows from the task queue at preset time intervals, and to group the update transaction requests for different hot data rows. The task queue is used to store the update transaction requests for hot data rows.

[0032] In one possible implementation, the task queue includes a first task queue and a second task queue, and the grouping includes a first grouping and a second grouping;

[0033] The grouping module includes:

[0034] The first grouping submodule is used to obtain update transaction requests for hot data rows from the first task queue at preset time intervals, and obtain the first group of update transaction requests for different hot data rows;

[0035] The second grouping submodule is used to obtain a second group of update transaction requests from the second task queue when all update transaction requests in the first task queue have been grouped. The second task queue is used to store update transaction requests of hot data rows when grouping update transaction requests in the first task queue.

[0036] In one possible implementation, the acquisition module includes:

[0037] The first acquisition submodule is used to determine the first update transaction request as the first update transaction request and the remaining update transaction requests as the second update transaction requests from the group of update transaction requests.

[0038] The second acquisition submodule is used to determine a second update transaction request from the group as the first update transaction request when the first update transaction request fails to update, and to determine the update transaction requests in the group other than the second update transaction request as the second update transaction request.

[0039] In one possible implementation, the first update module includes:

[0040] The first replacement submodule is used to retain the context information in the first update transaction request unchanged, and replace the operators in the first update transaction request with the operators in the second update transaction request to obtain the updated first update transaction request.

[0041] In one possible implementation, the first update module includes:

[0042] The second replacement submodule is used to retain the operators in the second update transaction request unchanged, and replace the context information in the second update transaction request with the context information in the first update transaction request to obtain the updated first update transaction request.

[0043] One possible implementation also includes:

[0044] The sending module is used to send the update result to the client corresponding to the first update transaction request and the client corresponding to the second update transaction request, respectively.

[0045] One possible implementation also includes:

[0046] The submission module is used to submit the update results and generate the update log corresponding to the group.

[0047] According to a third aspect of the present disclosure, a server is provided, comprising:

[0048] processor;

[0049] Memory used to store the processor's executable instructions;

[0050] The processor is configured to execute the instructions to implement a data update method as described in any of the embodiments of this disclosure.

[0051] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of a server, enables the server to perform a data update method as described in any one of the embodiments of the present disclosure.

[0052] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including instructions that, when executed by a processor of a server, enable the server to perform a data update method as described in any one of the embodiments of the present disclosure.

[0053] The technical solutions provided by the embodiments of this disclosure offer at least the following beneficial effects: In the embodiments of this disclosure, the operators in the second update transaction request within the same group are updated on the first update transaction request, and the updated first update transaction request is executed to batch update the data in the hot data rows. This reduces repetitive operations in the update process, such as locking, logging, committing, and releasing row locks, so that multiple update transaction requests in a group only need to perform operations such as locking, logging, committing, and releasing row locks once, thereby improving the update performance of hot data rows.

[0054] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0055] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0056] Figure 1 This is a flowchart of a data update method in the prior art;

[0057] Figure 2 This is a flowchart of a data update method in related technologies;

[0058] Figure 3 This is a flowchart of a data update method in another related technology;

[0059] Figure 4 This is a flowchart illustrating a data update method according to an exemplary embodiment;

[0060] Figure 5 This is a flowchart illustrating another data update method according to an exemplary embodiment;

[0061] Figure 6 This is a flowchart illustrating another data update method according to an exemplary embodiment;

[0062] Figure 7 This is an illustration showing the effect of implementing a data updating method according to an exemplary embodiment;

[0063] Figure 8 This is an illustration showing the effect of implementing another data updating method according to an exemplary embodiment;

[0064] Figure 9 This is a block diagram illustrating a data updating apparatus according to an exemplary embodiment;

[0065] Figure 10 This is a block diagram illustrating a server according to an exemplary embodiment. Detailed Implementation

[0066] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0067] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0068] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0069] To facilitate understanding of the technical solutions provided by the embodiments of this disclosure by those skilled in the art, the technical environment for implementing the technical solutions will be described below.

[0070] To address the issue of updating hot rows, a hot row queuing model is provided in related technologies, as referenced. Figure 2 As shown, update requests for the same frequently accessed data rows are queued at the database server layer. The next update operation begins only after the previous one is completed. This reduces the deadlock detection overhead caused by row lock contention at the database engine layer in existing technologies, thus improving performance. However, when a large number of update requests for frequently accessed data rows occur within a short period, this queuing model still cannot handle the situation, resulting in slow updates.

[0071] Another related technology proposes a pipelined optimization scheme. This scheme involves processing and committing update transaction requests for the same hot data row in groups and batches according to their arrival order. (Reference) Figure 3 The process involves dividing update transaction requests for the same hot data row into two groups. When the first group finishes collecting and is ready to commit, the second group immediately begins collecting update transaction requests. When the second group finishes collecting and is ready to commit, the first group has already committed and begins collecting a new batch of update transaction requests. The two groups switch continuously and execute in parallel. For each group, the first update transaction request within the group is designated as the primary update transaction request. This primary update transaction request traverses the index to locate the hot data row, locks it, and updates it, caching the updated data in memory. Subsequent update transaction requests are designated as secondary update transaction requests. Secondary update transaction requests can directly read the hot data row from memory without needing to traverse the index again or lock the hot data row; they directly follow the primary update transaction request. Both the primary and secondary update transaction requests update the memory records, then a group commit is performed, and update logs for each update transaction request are recorded.

[0072] The pipelined optimization scheme has the following problems: Since row locks are released only after the update transaction request has been committed, the group executing the collection task must wait for the group committing the task to complete before the row locks are released and updates can begin. Therefore, this method is not truly parallel; due to network latency or a certain number of requests, the update performance of this scheme is difficult to improve further. There is a delay between update transaction requests within a group, and a log is generated after each update transaction request is committed. In a master-slave database, the limited application capabilities of the slave database can lead to severe log accumulation. If the slave database does not fully receive the logs from the master database, data loss may occur if the master database encounters problems.

[0073] Based on the actual technical needs similar to those described above, the industry still faces performance bottlenecks in updating hot data rows. This disclosure provides a method, apparatus, server, and storage medium for data updating.

[0074] Figure 4 This is a flowchart illustrating a data update method according to an exemplary embodiment, such as... Figure 4 As shown, the method is used in a server and includes the following steps.

[0075] Step S401: Obtain the first update transaction request and the second update transaction request from the group of update transaction requests, wherein the group includes update transaction requests for the same hot data row in the database.

[0076] In this embodiment of the disclosure, multiple update transaction requests for the same hot data row in the database can be grouped to obtain update transaction request groups. Specifically, when the database receives update transaction requests sent by different clients, it needs to identify the update transaction requests to determine which update transaction requests belong to the hot data row. The identification method may include: in one example, adding identification information to the update transaction requests of the hot data row, and using this identification information to distinguish between hot data rows and non-hot data rows. In another example, the update operations of data rows can be counted. For example, if the update operations for data row A are greater than a preset value, then data row A is considered a hot data row, and the transaction requests that update data row A are identified as hot data row update transaction requests.

[0077] In this embodiment of the disclosure, update transaction requests for hot data rows can be stored in a task queue. In one example, an update transaction request for the same hot data row is retrieved from the task queue once every preset time period, resulting in a group. In another example, all update transaction requests in the task queue can be hash-bucketed according to their index identifier (primary key or unique key), with each bucket containing update transaction requests for the same hot data row, which can be considered as a group.

[0078] In this embodiment of the disclosure, a first update transaction request and a second update transaction request are obtained from the group. In one example, the first update transaction request in the group can be taken as the first update transaction request, and the remaining update transaction requests in the group other than the first update transaction request can be taken as the second update transaction request. In another example, any update transaction request in the group can be taken as the first update transaction request, and the remaining update transaction requests in the group other than the first update transaction request can be taken as the second update transaction request.

[0079] Step S403: If the first update transaction request is successfully updated, the operator of the first update transaction request is updated using the operator in the second update transaction request to obtain the updated first update transaction request.

[0080] In this embodiment of the disclosure, in response to the first update transaction request, before updating the data in the hot data row corresponding to the first update transaction request, the hot data row corresponding to the first update transaction request needs to be locked. After the first update transaction request is successfully updated, the update information of the second update transaction request is obtained sequentially. After parsing the update information, the operator is updated using the following method: In one example, the operator of the first transaction request can be replaced with the operator of the second transaction request to obtain the updated first update transaction request. In another example, the context information of the second transaction request can also be replaced with the context information of the first transaction request to obtain the updated first update transaction request.

[0081] Step S405: Execute the updated first update transaction request to update the data in the hot data rows in batches and generate update results.

[0082] In this embodiment of the disclosure, the update result may include update success or update failure. In this embodiment, after executing the memory update of the first update transaction request after the update, the operator for the next update transaction request is obtained, an updated first update transaction request is generated, and the memory update of the updated first update transaction request is executed again, until all update transaction requests within the group have been updated. Finally, the first update transaction request records the update log, commits, and releases the row lock. The following example illustrates the specific implementation of the above update transaction request: Figure 6 This is a flowchart illustrating another data update method according to an exemplary embodiment. (Reference) Figure 6 As shown, for example: the data stored in the hot data row is A. The operator of the first update transaction request is A+1, the operator of the second update transaction request 1 is A+1, the operator of the second update transaction request 2 is A+1, the operator of the second update transaction request 3 is A+1, and the operator of the second update transaction request 4 is A+1. After the first update transaction request is executed, the data stored in the hot data row is A+1. The first update transaction request retrieves the operator A+1 from the second update transaction request 1 and executes it. At this time, the data stored in the hot data row is A+2. The first update transaction request retrieves the operator A+1 from the second update transaction request 2 and executes it. At this time, the data stored in the hot data row is A+3, and so on. When all the operators in the second update transaction requests have been executed, the first update transaction request records the update log, A+5. The row lock of the hot data row is then committed and released.

[0083] In this embodiment, the operators in the second update transaction request within the same group are updated on the first update transaction request, and the updated first update transaction request is executed to batch update the data in the hot data rows. This reduces repetitive operations in the update process, such as locking, logging, committing, and releasing row locks. Thus, multiple update transaction requests within a group only need to perform these operations once, improving the update performance of hot data rows while avoiding excessive logs that could overload the slave database.

[0084] In one possible implementation, before obtaining the first update transaction request and the second update transaction request from the group of update transaction requests, the method further includes:

[0085] Update transaction requests for hot data rows are retrieved from the task queue at preset time intervals, and hot update transaction requests for different hot data rows are grouped. The task queue is used to store update transaction requests for hot data rows.

[0086] In this embodiment of the disclosure, the task queue can store update transaction requests for different hot data rows. To group update transaction requests for the same hot data row, the task queue can be scanned at preset time intervals to organize update transaction requests for the same hot data row into one group. Different hot data rows correspond to different groups. In one example, if there are many update transaction requests for the same hot data row in the task queue, for example, exceeding the preset number of groups, the update transaction requests for the same hot data row can be divided into multiple groups. And when the preset number of groups is not exceeded, if identical groups are found waiting at each preset time interval, the groups can be merged.

[0087] In this embodiment of the disclosure, update transaction requests for the same hot data row are obtained at preset time intervals, and the update transaction requests are grouped. This allows for the orderly determination of update transaction groups, which can reduce the overhead of lock acquisition and release, as well as deadlock detection caused by lock contention.

[0088] In one possible implementation, the task queue includes a first task queue and a second task queue, and the grouping includes a first grouping and a second grouping;

[0089] The step of retrieving update transaction requests for hot data rows from the task queue at preset time intervals, and grouping update transaction requests for different hot data rows, includes:

[0090] Update transaction requests for hot data rows are retrieved from the first task queue at preset time intervals to obtain the first group of update transaction requests for different hot data rows;

[0091] When all update transaction requests in the first task queue have been grouped and completed, a second group of update transaction requests is obtained from the second task queue, wherein the second task queue is used to store update transaction requests of hot data rows when grouping update transaction requests in the first task queue.

[0092] In this embodiment of the disclosure, to improve the update level, update transaction requests for hot data rows are obtained from the first task queue for each preset time period, resulting in a first grouping of update transaction requests for different hot data rows. At this time, the second task queue stores the update transaction requests for the hot data rows. Both queues process simultaneously. In one example, when the update transaction requests in the first task queue are grouped and completed, update transaction requests for hot data rows are obtained from the second task queue for each preset time period. In this case, the first task queue can be used to store the hot data rows. It should be noted that the configuration of the task queues is not limited to the examples above. For example, three or more task queues with clear division of labor can be used to achieve parallel processing. Those skilled in the art may make other changes based on the essence of this application, but as long as the functions and effects achieved are the same as or similar to those of this application, they should be covered within the scope of protection of this application.

[0093] In this embodiment of the disclosure, two task queues are used. While one task queue is performing grouping work, the other task queue is performing update transaction request work to store hot data rows. The two task queues work in parallel, which further improves the update performance of hot data rows.

[0094] In one possible implementation, obtaining the first update transaction request and the second update transaction request from the group of update transaction requests includes:

[0095] The first update transaction request is determined from the group of update transaction requests as the first update transaction request, and the remaining update transaction requests are determined as the second update transaction requests;

[0096] If the first update transaction request fails, a second update transaction request is determined from the group as the first update transaction request, and all update transaction requests in the group other than the second update transaction request are determined as the second update transaction requests.

[0097] In this embodiment of the disclosure, the first update transaction request includes an update transaction request capable of performing all update operations, such as locking, updating, generating logs, committing, and releasing row locks. After updating the operators of the second update transaction request to the first update transaction request, the operator portion of the second update transaction request is executed. In one example, the first update transaction request can be determined from the group of update transaction requests as the first update transaction request, and the remaining update transaction requests are designated as the second update request. If the first update transaction request fails to update, it means that subsequent updates will not be committed and are invalid updates. Therefore, if the first update transaction request fails to update, the second update transaction request is determined from the group as the first update transaction request, and all update transaction requests other than the second update request are designated as the second update request. This ensures the success of the first update transaction request. In one example, if the second determined first update transaction request also fails to update successfully, the third update transaction request is determined from the group as the first update transaction request, and so on, until the first update transaction request updates successfully. In one possible implementation, one update transaction request can be randomly selected from the group as the first update transaction request, and the other update transaction requests besides the first update transaction request can be selected as the second update transaction request. If the first update transaction request fails, the other update transaction requests are selected as the first update transaction request.

[0098] In this embodiment of the disclosure, if the first update transaction request fails to update, a new first update transaction request is selected, which can ensure the effectiveness of the update transaction requests within the group and improve the success rate of the update.

[0099] In one possible implementation, the step of updating the operator of the first update transaction request using the operator in the second update transaction request to obtain the updated first update transaction request includes:

[0100] The context information in the first update transaction request is retained, and the operators in the first update transaction request are replaced with the operators in the second update transaction request to obtain the updated first update transaction request.

[0101] In this embodiment of the disclosure, the context information may include the scope in which the programming language corresponding to the update transaction request is running. The update transaction request may include field information and values, such as the MySQL UPDATE statement: UPDATE table_name SET field1 = value1, field2 = value2... WHERE clause ORDER BY field. When the database executes the update transaction request, it needs to parse the update transaction request and store the parsed content in a database structure, such as the THD structure. The THD structure stores the operators and context of the update transaction request. In one example, the context information of the first update transaction request is kept unchanged, and the operators in the first update transaction request are replaced with the operators of the second update transaction request. Then, after the first update transaction request is executed, when the updated first transaction request is executed again, it is not necessary to switch the context information of the first update transaction request. The operators in the updated first transaction request are directly executed, which are the operators in the second update transaction request, which is equivalent to executing the update content of the second update transaction request. Since both the first and second update transaction requests are update operations targeting the same hot data row, executing the first update transaction request after the update is equivalent to executing the second update transaction request; the former eliminates the need for context switching.

[0102] In this embodiment, by replacing the operators in the first update transaction request with the operators in the second update transaction request, an updated first update transaction request is obtained. Executing the updated first transaction request eliminates repetitive operations in the update process, such as locking, log generation, committing, and releasing row locks, significantly improving database update performance.

[0103] In one possible implementation, the step of updating the operator of the first update transaction request using the operator in the second update transaction request to obtain the updated first update transaction request includes: keeping the operator in the second update transaction request unchanged, and replacing the context information in the second update transaction request with the context information in the first update transaction request to obtain the updated first update transaction request.

[0104] In this embodiment, the operators in the second update transaction request are retained unchanged, and the context information of the second update transaction request replaces the context information in the first update transaction request. Therefore, after executing the first update transaction request, when continuing to execute the updated first transaction request, it is not necessary to switch the context information of the first update transaction request; the operators in the updated first transaction request are directly executed, and these operators are the same as those in the second update transaction request, which is equivalent to executing the update content of the second update transaction request. Since both the first and second update transaction requests are update operations targeting the same hot data row, executing the updated first update transaction request and executing the second update request are equivalent; the former eliminates the need for context switching.

[0105] In this embodiment, by replacing the context information in the second update transaction request with the context information in the first update transaction request, an updated first update transaction request is obtained. Executing the updated first transaction request achieves the same effect as the embodiments described above, also eliminating repetitive operations in the update operation, such as locking, log generation, committing, and releasing row locks, thus significantly improving database update performance.

[0106] In one possible implementation, following the first update transaction request after the execution of the update, the process includes:

[0107] The update results are sent to the client corresponding to the first update transaction request and the client corresponding to the second update transaction request, respectively.

[0108] In this embodiment of the disclosure, the update result may include update success or update failure. In one example, refer to... Figure 6 As shown, after each updated first update transaction request is executed, it can be marked, for example, as successful or unsuccessful. After batch updating the data in the hot data rows, the update results of all updated first update transaction requests can be obtained. Since the updated first update transaction requests are obtained through operator substitution or context substitution of the second update transaction requests, the update results of the original second update transaction requests can be determined. Based on the client information in the second update transaction requests, the batch update results are sent to the corresponding clients.

[0109] In this embodiment of the disclosure, the update results of batch updates are sent to the corresponding clients respectively. Compared with the traditional method of sending an update result notification after each update transaction request is completed, this disclosure can improve the update capability of hot data rows.

[0110] In one possible implementation, after executing the first update transaction request following the update, to batch update the data in the hot data rows and generate update results, the process further includes:

[0111] Submit the update results and generate the update log corresponding to the group.

[0112] In this embodiment of the disclosure, the submitted update results include the update results corresponding to the first update transaction request and the update results corresponding to the second update transaction request. The update log corresponding to the group includes an update log after all update transaction requests have been completed. For example, refer to... Figure 6 As shown, the data stored in the hot data row is A. The operator for the first update transaction request is A+1, the operator for the second update transaction request 1 is A+1, the operator for the second update transaction request 2 is A+1, the operator for the second update transaction request 3 is A+1, and the operator for the second update transaction request 4 is A+1. After the first update transaction request is executed, the data stored in the hot data row is A+1. The first update transaction request retrieves the operator A+1 from the second update transaction request 1 and executes it. At this point, the data stored in the hot data row is A+2. The first update transaction request retrieves the operator A+1 from the second update transaction request 2 and executes it. At this point, the data stored in the hot data row is A+3, and so on. After all the operators in the second update transaction requests are executed, the first update transaction request records the update log, and the log record content is A+5. The traditional method would generate 5 update logs, recording the contents as A+1, A+2, A+3, A+4, and A+5 respectively.

[0113] In this embodiment of the disclosure, multiple update transaction requests in a group only need to perform operations such as locking, logging, committing, and releasing row locks once, which reduces the number of logs generated and avoids the problem of too many logs causing excessive pressure on the slave database.

[0114] Figure 5 This is a flowchart illustrating a data update method according to an exemplary embodiment. (Reference) Figure 5 As shown, the method is used in a server and includes the following steps:

[0115] Step S501: Obtain update transaction requests for hot data rows from the first task queue at preset time intervals to obtain the first group of update transaction requests for different hot data rows.

[0116] Step S503: When all update transaction requests in the first task queue have been grouped and completed, a second group of update transaction requests is obtained from the second task queue. The second task queue is used to store update transaction requests of hot data rows when grouping update transaction requests in the first task queue.

[0117] In this embodiment, update transaction requests for the same hot data row are obtained from a first task queue for each preset time period to form a first group of update transaction requests. Then, a second task queue is used to store the update transaction requests for the hot data row. Both queues process simultaneously. In one example, when the update transaction requests in the first task queue have been grouped, update transaction requests for the same hot data row are obtained from the second task queue for each preset time period. At this time, the first task queue can be used to store the hot data row.

[0118] Step S505: If the first update transaction request fails to update, a second update transaction request is determined from the group as the first update transaction request, and all update transaction requests in the group other than the second update transaction request are determined as the second update transaction requests.

[0119] In this embodiment of the disclosure, the first update transaction request can be determined from the group of update transaction requests as the first update transaction request, and the remaining update transaction requests are designated as the second update transaction requests. If the first update transaction request fails, it means that subsequent updates will not be committed and are considered invalid updates. Therefore, if the first update transaction request fails, the second update transaction request is determined from the group as the first update transaction request, and all update transaction requests other than the second update transaction request are designated as the second update transaction requests. This ensures that the first update transaction request succeeds.

[0120] Step S507: Keep the operators in the second update transaction request unchanged, and replace the context information in the second update transaction request with the context information in the first update transaction request to obtain the updated first update transaction request.

[0121] In this embodiment of the disclosure, the operators in the second update transaction request are kept unchanged, and the context information of the second update transaction request is used to replace the context information in the first update transaction request. Then, after the first update transaction request is executed, when the updated first transaction request is executed, it is not necessary to switch the context information of the first update transaction request. The operators in the updated first transaction request are executed directly, and the operators are the operators in the second update transaction request, which is equivalent to executing the update content of the second update transaction request.

[0122] Step S511: Execute the updated first update transaction request to update the data in the hot data rows in batches and generate update results.

[0123] In this embodiment of the disclosure, after executing the updated first update transaction request, the operator for the next update transaction request is obtained, an updated first update transaction request is generated, and the updated first update transaction request is executed again, until all update transaction requests within the group have been updated. Finally, the first update transaction request records the update log, commits, and releases the row lock.

[0124] In this embodiment of the disclosure, the update result may include update success or update failure. In one example, refer to... Figure 6 As shown, after each updated first update transaction request is executed, it can be marked, for example, as successful or unsuccessful. After batch updating the data in the hot data rows, the update results of all updated first update transaction requests can be obtained. Since the updated first update transaction requests are obtained through operator substitution or context substitution of the second update transaction requests, the update results of the original second update transaction requests can be determined. Based on the client information in the second update transaction requests, the batch update results are sent to the corresponding clients.

[0125] Step S515: Send the update result to the client corresponding to the first update transaction request and the client corresponding to the second update transaction request, respectively.

[0126] Figure 7 and Figure 8 This is an illustration showing the effect of implementing a data updating method according to an exemplary embodiment. (Reference) Figure 7 As shown, in the prior art, MySQL is represented by 703, the hotspot row queuing model is represented by 702, and the scheme of this embodiment is represented by 701. Compared with the previous two schemes, the scheme 701 of this embodiment significantly outperforms both in QPS (Queries per second), and under high concurrency (1024 threads), the QPS value exceeds 250,000, demonstrating a high-performance update level. (Reference) Figure 8 As shown, compared to the existing MySQL 703, the solution 701 of this disclosure is also superior to the hotspot row queuing model 702, and is at a higher level of low latency.

[0127] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order restriction on the execution of these steps. These steps can be executed in other orders, and at least some steps in the flowchart may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0128] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0129] Figure 9 This is a block diagram illustrating a data updating apparatus according to an exemplary embodiment. (Refer to...) Figure 9 The device 900 includes:

[0130] The acquisition module 901 is used to acquire a first update transaction request and a second update transaction request from a group of update transaction requests, wherein the group includes update transaction requests for the same hot data row in the database;

[0131] The first update module 903 is used to update the first update transaction request with the operator in the second update transaction request when the first update transaction request is successfully updated, so as to obtain the updated first update transaction request.

[0132] The second update module 905 is used to execute the updated first update transaction request to update the data in the hot data rows in batches and generate update results.

[0133] In one possible implementation, the method further includes:

[0134] The grouping module is used to retrieve update transaction requests for hot data rows from the task queue at preset time intervals, and to group the update transaction requests for different hot data rows. The task queue is used to store the update transaction requests for hot data rows.

[0135] In one possible implementation, the task queue includes a first task queue and a second task queue, and the grouping includes a first grouping and a second grouping;

[0136] The grouping module includes:

[0137] The first grouping submodule is used to obtain update transaction requests for hot data rows from the first task queue at preset time intervals, and obtain the first group of update transaction requests for different hot data rows;

[0138] The second grouping submodule is used to obtain a second group of update transaction requests from the second task queue when all update transaction requests in the first task queue have been grouped. The second task queue is used to store update transaction requests of hot data rows when grouping update transaction requests in the first task queue.

[0139] In one possible implementation, the acquisition module includes:

[0140] The first acquisition submodule is used to determine the first update transaction request as the first update transaction request and the remaining update transaction requests as the second update transaction requests from the group of update transaction requests.

[0141] The second acquisition submodule is used to determine a second update transaction request from the group as the first update transaction request when the first update transaction request fails to update, and to determine the update transaction requests in the group other than the second update transaction request as the second update transaction request.

[0142] In one possible implementation, the first update module includes:

[0143] The first replacement submodule is used to retain the context information in the first update transaction request unchanged, and replace the operators in the first update transaction request with the operators in the second update transaction request to obtain the updated first update transaction request.

[0144] In one possible implementation, the first update module includes:

[0145] The second replacement submodule is used to retain the operators in the second update transaction request unchanged, and replace the context information in the second update transaction request with the context information in the first update transaction request to obtain the updated first update transaction request.

[0146] One possible implementation also includes:

[0147] The sending module is used to send the update result to the client corresponding to the first update transaction request and the client corresponding to the second update transaction request, respectively.

[0148] One possible implementation also includes:

[0149] The submission module is used to submit the update results and generate the update log corresponding to the group.

[0150] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0151] Figure 10 This is a block diagram illustrating an electronic device 1000 for a data update method according to an exemplary embodiment. For example, the electronic device 1000 may be a server. (Refer to...) Figure 10 The electronic device 1000 includes a processing component 1020, which further includes one or more processors, and memory resources represented by memory 1022 for storing instructions, such as application programs, that can be executed by the processing component 1020. The application programs stored in memory 1022 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1020 is configured to execute instructions to perform the methods described above.

[0152] The electronic device 1000 may further include: a power supply component 1024 configured to perform power management of the electronic device 1000, a wired or wireless network interface 1026 configured to connect the electronic device 1000 to a network, and an input / output (I / O) interface 1028. The electronic device 1000 may operate on an operating system stored in memory 1022, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or similar.

[0153] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1022 including instructions, which can be executed by a processor of an electronic device 1000 to perform the above-described method. The storage medium may be a computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0154] In an exemplary embodiment, a computer program product is also provided, the computer program product including instructions that can be executed by a processor of an electronic device 1000 to perform the above-described method.

[0155] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0156] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0157] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method of data updating, characterized by, The application comprises the following steps: obtaining a first update transaction request and a second update transaction request from a group of update transaction requests, wherein the group of update transaction requests comprises update transaction requests for the same hot data row in a database; wherein the group of update transaction requests comprises a first group of update transaction requests and a second group of update transaction requests; wherein the first update transaction request comprises the first update transaction request or any update transaction request in the group, and the second update transaction request comprises update transaction requests other than the first update transaction request in the group; in the case that the first update transaction request is updated successfully, updating the operator of the first update transaction request with the operator in the second update transaction request to obtain an updated first update transaction request; the step of updating the operator of the first update transaction request with the operator in the second update transaction request to obtain an updated first update transaction request comprises the following steps: keeping the context information in the first update transaction request unchanged, replacing the operator in the first update transaction request with the operator in the second update transaction request to obtain an updated first update transaction request; the context information comprises a scope in which the update transaction request corresponding to a programming language runtime is located; executing the updated first update transaction request, continuing to obtain the operator of the next update transaction request, generating an updated first update transaction request, and executing the memory update of the updated first update transaction request again until all update transaction requests in the group are updated, so as to update the data in the hot data row in batches and generate an update result.

2. The method of claim 1, wherein, Before the step of obtaining a first update transaction request and a second update transaction request from a group of update transaction requests, the method further comprises the following steps: obtaining update transaction requests for hot data rows from a task queue at a preset time interval to obtain a group of update transaction requests for different hot data rows, wherein the task queue is used to store update transaction requests for hot data rows.

3. The method of claim 2, wherein, The task queue comprises a first task queue and a second task queue, and the group comprises a first group and a second group. The step of obtaining update transaction requests for hot data rows from a task queue at a preset time interval to obtain a group of update transaction requests for different hot data rows comprises the following steps: obtaining update transaction requests for hot data rows from the first task queue at a preset time interval to obtain a first group of update transaction requests for different hot data rows; in the case that all update transaction requests in the first task queue are grouped, obtaining a second group of update transaction requests from the second task queue, wherein the second task queue is used to store update transaction requests for hot data rows when the update transaction requests in the first task queue are grouped.

4. The method of claim 1, wherein, The step of obtaining a first update transaction request and a second update transaction request from a group of update transaction requests comprises the following steps: determining the first update transaction request in the group of update transaction requests as the first update transaction request and the remaining update transaction requests as the second update transaction request. In a case that the first update transaction request fails to update, a second update transaction request is determined from the group as the first update transaction request, and update transaction requests in the group except the second update transaction request are determined as second update transaction requests.

5. The method of claim 1, wherein, The updating the operator in the first update transaction request by the operator in the second update transaction request comprises: The operator in the second update transaction request is kept unchanged, and context information in the second update transaction request is replaced by context information in the first update transaction request to obtain an updated first update transaction request.

6. The method according to any one of claims 1 to 5, characterized in that, After the execution of the updated first update transaction request to update data in the hot data row in batches to generate an update result, the method further comprises: The update result is sent to a client corresponding to the first update transaction request and a client corresponding to the second update transaction request respectively.

7. The method of claim 1, wherein, After the execution of the updated first update transaction request to update data in the hot data row in batches to generate an update result, the method further comprises: The update result is submitted to generate an update log corresponding to the group.

8. An apparatus for data update, characterized by The method comprises: An acquisition module is configured to acquire a first update transaction request and a second update transaction request from a group of update transaction requests, wherein the group of update transaction requests comprises update transaction requests for a same hot data row in a database; wherein the group of update transaction requests comprises a first group of update transaction requests and a second group of update transaction requests; wherein the first update transaction request comprises a first update transaction request in the group or any update transaction request, and the second update transaction request comprises update transaction requests in the group except the first update transaction request; A first update module is configured to, in a case that the first update transaction request succeeds to update, update the first update transaction request by an operator in the second update transaction request to obtain an updated first update transaction request; the first update module comprises a first replacement submodule configured to keep context information in the first update transaction request unchanged, and replace the operator in the first update transaction request by the operator in the second update transaction request to obtain the updated first update transaction request; the context information comprises a scope in which a programming language runtime corresponding to the update transaction request is located; A second update module is configured to execute the updated first update transaction request, continue to acquire an operator of a next update transaction request, generate an updated first update transaction request, and execute the memory update of the updated first update transaction request again until all update transaction requests in the group are updated to update data in the hot data row in batches to generate an update result.

9. The apparatus of claim 8, wherein, The method further comprises: A grouping module is configured to acquire update transaction requests for hot data rows from a task queue every preset time period to obtain groups of update transaction requests for different hot data rows, wherein the task queue is configured to store update transaction requests for hot data rows.

10. The apparatus of claim 9, wherein, The task queues include a first task queue and a second task queue, and the groups include a first group and a second group; The grouping module includes: A first grouping submodule is configured to obtain, from the first task queue, update transaction requests for different hot data rows at every preset time interval, to obtain a first group of update transaction requests for the hot data rows; A second grouping submodule is configured to obtain, from the second task queue, a second group of update transaction requests when all update transaction requests in the first task queue are grouped, wherein the second task queue is configured to store update transaction requests for the hot data rows when the update transaction requests in the first task queue are grouped.

11. The apparatus of claim 8, wherein, The obtaining module includes: A first obtaining submodule is configured to determine, from the group of update transaction requests, a first update transaction request as a first update transaction request and the remaining update transaction requests as second update transaction requests; A second obtaining submodule is configured to determine, from the group, a second update transaction request as the first update transaction request and the update transaction requests in the group other than the second update transaction request as the second update transaction requests when the first update transaction request fails to update.

12. The apparatus of claim 8, wherein, The first updating module includes: A second replacing submodule is configured to keep the operators in the second update transaction requests unchanged, replace the context information in the second update transaction requests with the context information in the first update transaction request, and obtain an updated first update transaction request.

13. The apparatus of any one of claims 8-12, wherein, Further includes: A sending module is configured to send the update result to a client corresponding to the first update transaction request and a client corresponding to the second update transaction request, respectively.

14. The apparatus of claim 8, wherein, Further includes: A submitting module is configured to submit the update result and generate an update log corresponding to the group.

15. A server, characterized by Includes: A processor; A memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method for data updating according to any one of claims 1 to 7.

16. A computer readable storage medium characterized by: When the instructions in the computer-readable storage medium are executed by the processor of the server, the server can execute the method for data updating according to any one of claims 1 to 7.

17. A computer program product comprising instructions therein, characterised in that, The instructions are executed by the processor of the server, so that the server can execute the method for data updating according to any one of claims 1 to 7.

Images