A table metadata changing method and device and related product

Abstract

The embodiment of the present application provides a table metadata change method, device and related product, and relates to the technical field of data processing. The table metadata change method provided by the embodiment of the present application can complete the pre-change operation before the formal change of the table metadata by pre-storing the to-be-changed table metadata and the to-be-changed version number to the memory of the service node, and only needs to perform a simple update operation in the formal change stage of the table metadata, thereby reducing the risk of change failure of the table metadata and improving the consistency and reliability of the change of the table metadata. Moreover, if a data rollback request is received in the pre-change stage, the to-be-changed table metadata and the to-be-changed version number can be deleted from the memory of the service node, thereby realizing the data rollback operation and avoiding the problem of data inconsistency caused by the change failure of the table metadata.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device, and medium for modifying table data. Background Technology

[0002] In distributed databases, table metadata describes the structure and characteristics of a database table, including basic table information, field information, index information, and constraint information. Since distributed databases typically consist of multiple service nodes, changes to table metadata need to be synchronized across all service nodes to ensure consistency.

[0003] In related technologies, the method for changing table metadata typically involves the following steps: First, the control layer sends a change command to all service nodes with which it has a communication connection. Upon receiving the change command, each service node pauses all its current worker threads to ensure that no other interference occurs during the table metadata change process. Subsequently, the service nodes perform the table metadata changes according to the change command. Only when all service nodes have successfully completed the table metadata changes will the control layer determine that the table metadata change operation was successful.

[0004] However, in practical applications, due to network latency, service node failures, and other issues, the change may succeed on some service nodes while failing on others. Once some service nodes begin reading and writing data based on the changed table metadata, it becomes difficult to roll back the table metadata and terminate the change operation. This situation leads to inconsistencies in table metadata across different service nodes, thus affecting the normal operation of the business. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, apparatus, and related products for modifying table data, which can reduce the risk of table data modification failure and avoid data inconsistency caused by table data modification failure.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] In view of this, the first aspect of this application discloses a method for modifying table metadata, applied to a first service node, the method comprising:

[0008] In response to the first change request sent by the control layer, the metadata of the table to be changed and the version number to be changed included in the first change request are stored in the memory of the first service node;

[0009] If a second change request is received from the control layer, the real-time table metadata of the first service node is updated to the table metadata to be changed by reading the memory, and the real-time version number of the first service node is updated to the version number to be changed, wherein the second change data includes the version number to be changed;

[0010] If a data rollback request is received from the control layer, the metadata of the table to be changed and the version number to be changed are deleted from the memory, wherein the data rollback request includes the version number to be changed.

[0011] The second aspect of this application discloses a device for modifying table data, applied to a first service node, the device comprising: a storage module, a modification module, and a deletion module;

[0012] The storage module is used to respond to a first change request sent by the control layer by storing the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node.

[0013] The change module is configured to, upon receiving a second change request sent by the control layer, update the real-time table metadata of the first service node to the table metadata to be changed by reading the memory, and update the real-time version number of the first service node to the version number to be changed, wherein the second change data includes the version number to be changed;

[0014] The deletion module is used to delete the data of the table to be changed and the version number to be changed from the memory if a data rollback request is received from the control layer, wherein the data rollback request includes the version number to be changed.

[0015] A third aspect of this application discloses a computer device, the device comprising a processor and a memory:

[0016] The memory is used to store program code and transmit the program code to the processor;

[0017] The processor is configured to execute the steps of the table data modification method described in the first aspect according to the instructions in the program code.

[0018] The fourth aspect of this application discloses a computer-readable storage medium for storing program code for performing the steps of the table data modification method described in the first aspect.

[0019] Compared with the prior art, this application has the following beneficial effects:

[0020] This application discloses a method, apparatus, and related products for modifying table data. The method provided pre-stores the table data to be modified and its version number in the service node's memory, enabling pre-modification before the actual modification. The actual modification phase only requires a simple update operation, reducing the risk of modification failure and improving consistency and reliability. Furthermore, if a data rollback request is received during the pre-modification phase, the table data and version number can be deleted from the service node's memory, enabling data rollback and preventing data inconsistency due to modification failure. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A scenario architecture diagram illustrating a method for modifying table metadata provided in an embodiment of this application;

[0023] Figure 2 A flowchart illustrating a method for modifying table data as provided in this application embodiment;

[0024] Figure 3 A flowchart illustrating another method for modifying table data provided in this application embodiment;

[0025] Figure 4 A schematic diagram illustrating a table data pre-modification stage provided in an embodiment of this application;

[0026] Figure 5 A flowchart illustrating a determination method provided in an embodiment of this application;

[0027] Figure 6 A flowchart illustrating another determination method provided in this application embodiment;

[0028] Figure 7 A schematic diagram illustrating a table data modification stage provided in an embodiment of this application;

[0029] Figure 8 A flowchart illustrating the third determination method provided in this application embodiment;

[0030] Figure 9 A schematic diagram illustrating an implementation of a method for modifying table data provided in an embodiment of this application;

[0031] Figure 10 A schematic diagram of a device for changing table data provided in an embodiment of this application;

[0032] Figure 11 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;

[0033] Figure 12 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0035] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0036] As described earlier, the method for changing table metadata is typically as follows: First, the control layer sends a change command to all service nodes with which it has a communication connection. Upon receiving the change command, each service node pauses all its current worker threads to ensure that no other interference occurs during the table metadata change process. Subsequently, the service nodes perform the table metadata changes according to the change command. Only when all service nodes have successfully completed the table metadata changes will the control layer determine that the table metadata change operation was successful.

[0037] However, in practical applications, due to network latency, service node failures, and other issues, the change may succeed on some service nodes while failing on others. Once some service nodes begin reading and writing data based on the changed table metadata, it becomes difficult to roll back the table metadata and terminate the change operation. This situation leads to inconsistencies in table metadata across different service nodes, thus affecting the normal operation of the business.

[0038] The inventors, through research, have proposed a method, apparatus, and related products for modifying table metadata. The method for modifying table metadata provided in this application pre-stores the table metadata to be modified and its version number in the service node's memory. This allows for pre-modification operations before the formal modification of the table metadata, while the formal modification phase only requires a simple update operation. This reduces the risk of modification failure and improves the consistency and reliability of the modification. Furthermore, if a data rollback request is received during the pre-modification phase, the table metadata to be modified and its version number can be deleted from the service node's memory, thereby achieving data rollback and avoiding data inconsistency issues caused by modification failure. Further, since multiple versions of table metadata can coexist during the modification process—for example, the old version (i.e., real-time table metadata) and the table metadata to be modified can coexist—the service node's worker threads can continue using the old version of the table metadata until the modified table metadata officially takes effect. Therefore, during the modification process, the service node's worker threads do not need to be paused and can continue processing user requests, thus reducing the impact of worker thread pauses on user access.

[0039] Next, the executing entity of the method for changing table data provided in this application embodiment will be specifically introduced:

[0040] The execution subject of the table data modification method provided in this application embodiment can be a computer device with data processing capabilities, specifically a terminal device or a server. As examples, terminal devices may include, but are not limited to, mobile phones, desktop computers, tablet computers, laptops, handheld computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The server can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed device. Furthermore, the server can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. In addition, the table data modification method provided in this application embodiment can also be executed collaboratively by the terminal device and the server. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein. Therefore, this application embodiment does not limit the implementation subject of the technical solution of this application.

[0041] Next, we will describe in detail the scenarios of the table data modification method provided in the embodiments of this application:

[0042] See Figure 1 This figure is a scenario architecture diagram of a method for changing table data according to an embodiment of this application, including a computer device 100. The computer device 100 can be a terminal device or a server as described above. Specifically, the following embodiments use server A as an example to illustrate the computer device 100.

[0043] Server A, in response to a first change request sent by the control layer, stores the table metadata to be changed and the version number to be changed, included in the first change request, in the memory of the first service node. The first change request includes the table metadata to be changed and the version number to be changed. The table metadata to be changed refers to data describing changes to the structure or characteristics of a database table, such as adding fields or modifying indexes. The version number to be changed is a unique identifier used to distinguish different change operations. Therefore, before the table metadata is officially changed, the server node can ensure that the table metadata and version number to be changed have been stored, providing a data foundation for subsequent official changes or rollback operations of the table metadata.

[0044] Server A, upon receiving a second change request from the control layer, updates the real-time table metadata of the first service node to the table metadata to be changed, and updates the real-time version number of the first service node to the version number to be changed, by reading memory. The second change data includes the version number to be changed. Thus, by retrieving the table metadata to be changed corresponding to the version number to be changed in the received second change data from memory, and using this table metadata to update the real-time table metadata of the first service node, and using the version number to update the real-time version number of the first service node, Server A can complete the formal change operation of the table metadata after the pre-change phase. At this point, the formal change operation only requires a simple update operation, thereby reducing the risk of table metadata change failure and improving the consistency and reliability of the table metadata change.

[0045] Server A is used to delete the table metadata and version number to be changed from memory if it receives a data rollback request from the control layer. The data rollback request includes the version number to be changed. Therefore, if a data rollback request is received during the pre-change phase, the server node can delete the table metadata and version number to be changed from its memory, thus achieving a data rollback operation and restoring the table metadata to its state before the change. This avoids inconsistencies in table metadata caused by failed changes.

[0046] Next, taking server A as the execution subject, the method for modifying table metadata provided in this application embodiment will be described in detail:

[0047] See Figure 2 This figure is a flowchart of a method for modifying table metadata provided in an embodiment of this application. Figure 2 The method for changing table metadata shown includes the following steps:

[0048] First, it should be noted that, as Figure 2 The method for changing table metadata shown is only an example applied to the first service node; in practice, it is as follows: Figure 2 The method for modifying table metadata shown can be applied to any service node connected to the control layer. This application does not limit this application.

[0049] S201: In response to the first change request sent by the control layer, store the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node.

[0050] The first change request is a pre-change request for table metadata sent from the control layer to the first service node. It instructs the first service node to store the table metadata to be changed and the version number to be changed. The table metadata to be changed refers to data describing changes to the structure or characteristics of the database table, such as adding fields or modifying indexes. The version number to be changed is a unique identifier used to distinguish different change operations.

[0051] After receiving the first change request from the control layer, the first service node stores the metadata of the table to be changed and the version number to be changed in its memory. In one specific implementation, the first service node can store the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata and the version number in a first table (i.e., a pre-change table) in its memory. The first table is a temporary table for storing the metadata of the table to be changed and the version number to be changed. The metadata of the table to be changed and the version number to be changed are usually stored in the form of key-value pairs (thus storing the correspondence between the metadata and the version number to be changed), and the key is the version number to be changed, and the value is the metadata of the table to be changed.

[0052] It is understandable that distributed databases typically consist of multiple service nodes, so changes to table metadata need to be synchronized to all relevant service nodes. The pre-change operation (i.e., storage operation) provided in this application embodiment ensures that all service nodes complete the storage operation of the table metadata to be changed and the version number to be changed before making formal changes to the table metadata, avoiding inconsistencies in table metadata caused by changes failing on some service nodes.

[0053] S202: If a second change request is received from the control layer, the real-time table metadata of the first service node is updated to the table metadata to be changed by reading memory, and the real-time version number of the first service node is updated to the version number to be changed, wherein the second change data includes the version number to be changed.

[0054] The second change request is a formal change request for table metadata sent by the control layer to the first service node, used to instruct the first service node to update the table metadata and version number to be changed.

[0055] Specifically, after receiving the second change request sent by the control layer, the first service node will first retrieve the table metadata to be changed corresponding to the version number to be changed included in the second change request in memory. Then, it will update the real-time table metadata of the first service node to the table metadata to be changed, and update the real-time version number of the first service node to the version number to be changed.

[0056] In one specific implementation, the first service node can first retrieve the table metadata to be changed corresponding to the version number to be changed included in the second change request from the first table. Then, by moving the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table to the second table (i.e. the change table) in memory, and deleting the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table, the real-time table metadata of the first service node is updated to the table metadata to be changed, and the real-time version number of the first service node is updated to the version number to be changed.

[0057] Understandably, the difference between the first table and the second table is that the first table is used to temporarily store the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed. The second table is used to store the metadata of the table to be changed that has been officially applied, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed.

[0058] Understandably, the first service node completes the formal change operation of the table metadata after the pre-change phase. At this time, the formal change operation only requires a simple update operation, thereby reducing the risk of table metadata change failure and improving the consistency and reliability of table metadata change.

[0059] S203: If a data rollback request is received from the control layer, the data of the table to be changed and the version number to be changed are deleted from memory. The data rollback request includes the version number to be changed.

[0060] A data rollback request refers to the control layer instructing the first service node to restore the data state in memory to the state before saving the version number to be changed and the corresponding table metadata to be changed, which is included in the data rollback request. Therefore, the data rollback request must include the version number to be changed, because the first service node needs the version number to be changed to accurately locate and restore to a specific data state.

[0061] In one specific implementation, if a data rollback request is received from the control layer, the first service node can perform a data rollback by deleting the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata and the version number from the first table. As a result, the memory of the first service node no longer contains the metadata and version number of this version of the table to be changed, thus achieving data rollback.

[0062] Understandably, if a data rollback request is received during the pre-change phase, the table metadata and version number to be changed can be deleted from the service node's memory, thereby enabling the data rollback operation and restoring the table metadata to its state before the change, thus avoiding the problem of inconsistent table metadata caused by the failure of the table metadata change.

[0063] In summary, this application discloses a method for modifying table metadata. This method pre-stores the table metadata to be modified and its version number in the service node's memory, enabling pre-modification operations before the actual modification of the table metadata. The actual modification phase only requires a simple update operation, thus reducing the risk of modification failure and improving the consistency and reliability of the changes. Furthermore, if a data rollback request is received during the pre-modification phase, the table metadata and version number to be modified can be deleted from the service node's memory, thereby achieving a data rollback and avoiding data inconsistency issues caused by failed modification of table metadata.

[0064] See Figure 3 This figure is a flowchart of another method for modifying table data provided in an embodiment of this application. Figure 3 The method for changing table metadata shown includes the following steps:

[0065] S301: The control layer sends a first change request to the first service node, wherein the first change request includes the table metadata to be changed and the version number to be changed. Subsequently, step S302 is executed.

[0066] See Figure 4 This figure is a schematic diagram of a table data pre-modification stage provided in an embodiment of this application. Figure 4 It can be seen that the first change request is a pre-change request for table data sent by the control layer to the first service node to the Nth service node (i.e. all service nodes that are connected to the control layer), which is used to instruct the first service node to the Nth service node to perform storage operations on the table data data to be changed and the version number to be changed.

[0067] For example, the control layer can increment the version number of the table metadata by 1, and then send the incremented version number (i.e. the version number to be changed) and the table metadata to be changed to all service nodes that are connected to the control layer through the first change request.

[0068] S302: The first service node determines whether the metadata of the table to be changed is compatible with the real-time metadata of the first service node, and whether the version number to be changed is greater than the real-time version number of the first service node. If so, proceed to step S303.

[0069] Real-time table metadata refers to the table metadata currently used by the first service node, and real-time version number refers to the version number currently used by the first service node.

[0070] See Figure 5 The figure is a flowchart of a judgment method provided in an embodiment of this application. First, the first service node determines whether the version number to be changed is greater than the real-time version number of the first service node. Based on this judgment, the following three situations may occur:

[0071] In the first scenario, if the version number to be changed is less than the real-time version number of the first service node, it indicates that the first change request is outdated or duplicated. In this case, storing the table metadata and version number to be changed included in the first change request may lead to inconsistencies or conflicts in the table metadata. Therefore, the first service node directly sends a storage error instruction to the control layer, indicating that it cannot store the table metadata and version number to be changed.

[0072] In the second scenario, if the version number to be changed equals the real-time version number of the first service node, the first service node will continue to determine whether the table metadata to be changed is consistent with the real-time table metadata of the first service node. If they are inconsistent, it indicates a table metadata conflict or inconsistency. Therefore, the first service node directly sends a storage error instruction to the control layer, indicating that it cannot store the table metadata and version number to be changed. If they are consistent, even though the real-time version number has not been updated and the real-time table metadata has not changed, the first service node will also directly send a change success instruction to the control layer (this only indicates that no change has occurred, not that an actual change has been performed).

[0073] In the third scenario, if the version number to be changed is greater than the real-time version number of the first service node, the first service node continues to determine whether the table metadata to be changed is compatible with the real-time table metadata of the first service node. If compatible, step S303 is executed (i.e., the first service node stores the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed into the first table in the memory of the first service node); if incompatible, it indicates that the table metadata to be changed included in the first change request conflicts with the real-time table metadata of the first service node. Therefore, the first service node directly sends a storage error instruction to the control layer, indicating that it cannot store the table metadata to be changed and the version number to be changed.

[0074] S303: The first service node stores the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata and the version number to be changed into the first table in the memory of the first service node. Then, step S304 is executed.

[0075] Understandably, memory is a high-speed storage device in a computer used to temporarily store data and program instructions, and its access speed is much faster than persistent storage devices such as hard drives. Therefore, storing the metadata of the table to be modified, the version number to be modified, and the correspondence between the metadata and the version number to be modified in a first table in memory can speed up subsequent processing.

[0076] S304: The first service node sends a storage success command to the control layer. Then, step S305 is executed.

[0077] The successful storage instruction indicates that the first service node has completed the storage operation of the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata and the version number to be changed, and is ready to receive subsequent second change instructions or perform other processing.

[0078] S305: The control layer determines whether it has received storage success instructions from all service nodes communicating with the control layer. If not, proceed to step S306; if yes, proceed to step S308.

[0079] In one specific implementation, the control layer can determine whether it has received storage success instructions from all service nodes communicating with it within a first preset time period by judging whether it has received an equal number of storage success instructions from all service nodes communicating with it. For example, if the control layer is communicating with three service nodes, it needs to determine whether it has received three storage success instructions within the first preset time period. It should be noted that the first preset time period should be long enough to accommodate factors such as network latency and differences in service node processing speeds, but it should not be too long to avoid unnecessary waiting time. This application does not limit the specific first preset time period.

[0080] Specifically, if the control layer receives fewer storage success instructions than the number of all service nodes communicating with the control layer within a first preset time period, this means that at least one service node failed to successfully store the table data to be changed and the version number to be changed, then step S306 is executed. If the control layer receives a number of storage success instructions equal to the number of all service nodes communicating with the control layer within the first preset time period, this means that all service nodes have successfully stored the table data to be changed and the version number to be changed, then step S308 is executed.

[0081] In another specific implementation, the control layer can further determine whether all instructions received within a first preset time period are either successful storage instructions or successful modification instructions. If the instructions received by the control layer include storage error instructions, then step S306 is executed. If all instructions received by the control layer are successful storage instructions or successful modification instructions, then step S308 is executed.

[0082] S306: The control layer sends a data rollback request to the first service node, wherein the data rollback request includes the version number to be changed. Then, step S307 is executed.

[0083] The data rollback request includes the version number to be changed, which is the version number for which a previous attempt to change the data failed to take effect on all service nodes. Understandably, the purpose of the data rollback request is to inform the first service node that it needs to roll back to a version prior to the version number to be changed.

[0084] S307: The first service node deletes the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed from the first table in memory.

[0085] See Figure 6 This figure is a flowchart of another determination method provided in an embodiment of this application. Figure 6 It can be seen that the first service node can re-determine whether the first table in memory contains the version number to be changed. This is to ensure that the table metadata and version number to be changed, which need to be rolled back, actually exist in the first table in memory before the deletion operation is performed. If yes, the first service node then deletes the version number to be changed and the corresponding table metadata from the first table in memory. This means that the first service node will restore the table metadata to its state before the change. If no, it means that the table metadata has been cleaned up by other operations (such as the previous rollback operation), or there is some kind of anomaly. In this case, the first service node sends a rollback success command to the control layer (indicating that although no deletion operation was performed, it is already in the expected state).

[0086] Therefore, if a data rollback request is received during the pre-change phase, the table metadata and version number to be changed can be deleted from the memory of the first service node, thereby realizing the data rollback operation and restoring the table metadata to its state before the change, thus avoiding data inconsistency caused by the failure of the table metadata change.

[0087] S308: The control layer sends a second change request to the first service node, wherein the second change request includes the version number to be changed.

[0088] See Figure 7 This figure is a schematic diagram of a table data modification stage provided in an embodiment of this application. Figure 7 It can be seen that the second change request is a formal change request for table data sent by the control layer to the first service node to the Nth service node (i.e. all service nodes that are connected to the control layer), which is used to instruct the service nodes to perform change operations on the table data data to be changed and the version number to be changed.

[0089] S309: The first service node transfers the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table in memory to the second table in memory, and deletes the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table. The first service node then updates the real-time table metadata to the table metadata to be changed and updates the real-time version number of the first service node to the version number to be changed.

[0090] See Figure 8 The figure is a flowchart of the third judgment method provided in the embodiment of this application.

[0091] A1: The first service node checks if the version number to be changed exists in the first table in memory. If not, proceed to step A2; if yes, proceed to step A5.

[0092] A2: The first service node determines whether the version number to be changed is equal to the real-time version number of the first service node. If yes, proceed to step A3; otherwise, proceed to step A4.

[0093] A3: The first service node sends a success message to the control layer.

[0094] If the version number to be changed is the same as the real-time version number, the second change request is considered a retry request. At this time, the real-time version number of the first service node is already the latest (i.e. the version number to be updated), and there is no need to update it again.

[0095] A4: The first service node sends a change error command to the control layer.

[0096] If the version number to be changed is different from the real-time version number, it means that the second change request is an invalid request, and the first service node directly sends a change error instruction to the control layer.

[0097] A5: The first service node transfers the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table in memory to the second table in memory, and deletes the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed from the first table. The real-time table metadata of the first service node is updated to the table metadata to be changed, and the real-time version number of the first service node is updated to the version number to be changed.

[0098] It should be noted that the step of "deleting the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed in the first table" can be performed simultaneously with the step of "transferring the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed in the first table in memory to the second table in memory," or it can be performed after the second preset time period of the step of "transferring the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed in the first table in memory to the second table in memory." This application does not limit the specific execution time.

[0099] It should also be noted that changes to table metadata in a distributed database need to be synchronized to all service nodes connected to the control layer to ensure consistency. However, if the control layer sends both the first and second change requests to all service nodes, it may lead to high network overhead and complex synchronization issues between service nodes. See also Figure 9 The figure is a schematic diagram illustrating the implementation of a method for changing table data provided in an embodiment of this application.

[0100] The first implementation method is as follows: Figure 9 As shown in Figure A, during the pre-modification phase of table data, the control layer only sends the first change request to the service node where the Leader replica resides. The service node where the Leader replica resides is responsible for synchronizing the first change request to the service nodes where the Follower replicas reside. Similarly, during the formal modification phase of table data, the control layer only sends the second change request to the service node where the Leader replica resides. The service node where the Leader replica resides is responsible for synchronizing the second change request to the service nodes where the Follower replicas reside. Therefore, the control layer only needs to communicate with the service node where the Leader replica resides, reducing the number of service nodes that need to be notified, thereby reducing network overhead. Furthermore, since both the first and second change requests are synchronized to the service nodes where the Follower replicas reside through the service node where the Leader replica resides, the execution sequence of the service nodes where the Leader and Follower replicas resides is consistent; that is, they process the first and second change requests in the same order.

[0101] The second implementation method is as follows: Figure 9As shown in B, during the pre-change phase of table data, the control layer sends the first change request to all service nodes (including the service nodes where the Leader replica and Follower replicas reside). During the formal change phase of table data, the control layer only sends the second change request to the service node where the Leader replica resides. The service node where the Leader replica resides is responsible for synchronizing the second change request to the service nodes where the Follower replicas reside. Therefore, during the pre-change phase, all service nodes participate in the change operation, and even if the table data change fails on some service nodes, a rollback mechanism can restore a consistent state. Furthermore, during the formal change phase, only the service node where the Leader replica resides participates in the change operation, thereby reducing network overhead and synchronization complexity.

[0102] Understandably, the first implementation method is suitable for high-concurrency access scenarios, effectively improving change performance by reducing network overhead and enhancing timing consistency. Alternatively, the first implementation method is also suitable for scenarios where the service nodes hosting the Leader replica are highly stable, avoiding inconsistencies in table data caused by Leader replica failures. The second implementation method is suitable for scenarios with high requirements for table data consistency, effectively avoiding inconsistencies in table data caused by partial node failures through fault tolerance in the pre-change phase. Alternatively, the second implementation method is also suitable for scenarios where the service nodes hosting both the Leader and Follower replicas are highly stable, avoiding inconsistencies in table data caused by Follower replica synchronization failures. This application does not limit the application to using either the first or second implementation method in practical applications.

[0103] In summary, this application discloses a method for modifying table metadata. This method pre-stores the table metadata to be modified and its version number in the service node's memory, enabling pre-modification before the formal modification of the table metadata. The formal modification phase only requires a simple update operation, thus reducing the risk of modification failure and improving the consistency and reliability of the changes. Furthermore, if a data rollback request is received during the pre-modification phase, the table metadata to be modified and its version number can be deleted from the service node's memory, achieving data rollback and avoiding data inconsistency issues caused by modification failure. Moreover, since multiple versions of table metadata can coexist during the modification process—for example, the old version (i.e., real-time table metadata) and the table metadata to be modified can coexist—the service node's worker threads can continue using the old version of the table metadata until the modified version officially takes effect. Therefore, during the table metadata modification process, the service node's worker threads do not need to be paused and can continue processing user requests, reducing the impact of worker thread pauses on user access.

[0104] Based on the table data modification method provided in the preceding embodiments, this application also provides a corresponding table data modification device. The table data modification device provided in this application embodiment will be described in detail below:

[0105] See Figure 10 This figure is a schematic diagram of a table data modification device provided in an embodiment of this application. The table data modification device 1000 includes: a storage module 1001, a modification module 1002, and a deletion module 1003;

[0106] Storage module 1001 is used to respond to a first change request sent by the control layer and store the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node;

[0107] The change module 1002 is used to update the real-time table metadata of the first service node to the table metadata to be changed and update the real-time version number of the first service node to the version number to be changed by reading memory if a second change request is received from the control layer. The second change data includes the version number to be changed.

[0108] The deletion module 1003 is used to delete the data metadata and version number of the table to be changed from memory if a data rollback request is received from the control layer. The data rollback request includes the version number to be changed.

[0109] In one specific implementation, the table metadata modification device 1000 further includes: an instruction sending module;

[0110] The instruction sending module is used to send a storage success instruction to the control layer;

[0111] The second change request is sent by the control layer to the first service node after receiving storage success instructions from all service nodes that are communicating with the control layer.

[0112] In one specific implementation, the data rollback request is sent to the first service node when the control layer receives fewer storage success instructions from fewer than all service nodes communicating with the control layer within a first preset time period.

[0113] In one specific implementation, the storage module 1001 is specifically used to: if the table metadata to be changed included in the first change request is compatible with the real-time table metadata of the first service node, and the version number to be changed included in the first change request is greater than the real-time version number of the first service node, then the table metadata to be changed and the version number to be changed are stored in the memory of the first service node.

[0114] In one specific implementation, the instruction sending module is further configured to send a change success instruction to the control layer if the table metadata to be changed included in the first change request is consistent with the real-time table metadata of the first service node, and the version number to be changed included in the first change request is equal to the real-time version number of the first service node.

[0115] In one specific implementation, the storage module 1001 is specifically used to: store the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed, which are included in the first change request, into the first table in the memory of the first service node;

[0116] The modification module 1002 is specifically used to: move the metadata of the table to be modified, the version number to be modified, and the correspondence between the metadata of the table to be modified and the version number to be modified in the first table to the second table in memory, and delete the metadata of the table to be modified, the version number to be modified, and the correspondence between the metadata of the table to be modified and the version number to be modified in the first table, update the real-time table metadata of the first service node to the metadata of the table to be modified, and update the real-time version number of the first service node to the version number to be modified;

[0117] The deletion module 1003 is specifically used to delete the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed from the first table.

[0118] In one specific implementation, the instruction sending module is further configured to send a change success instruction to the control layer if it receives a second change request from the control layer, and the first table does not include the version number to be changed and the metadata of the table to be changed, and the version number to be changed is consistent with the real-time version number of the first service node.

[0119] In summary, this application discloses a device for modifying table metadata. This device pre-stores the table metadata to be modified and its version number in the service node's memory, enabling pre-modification before the formal modification of the table metadata. The formal modification phase only requires a simple update operation, thus reducing the risk of modification failure and improving the consistency and reliability of the changes. Furthermore, if a data rollback request is received during the pre-modification phase, the table metadata to be modified and its version number can be deleted from the service node's memory, thereby achieving data rollback and avoiding data inconsistency issues caused by modification failure. Moreover, since multiple versions of table metadata can coexist during the modification process—for example, the old version (i.e., real-time table metadata) and the table metadata to be modified can coexist—the service node's worker threads can continue using the old version of the table metadata until the modified version officially takes effect. Therefore, during the modification process, the service node's worker threads do not need to be paused and can continue processing user requests, reducing the impact of worker thread pauses on user access.

[0120] See Figure 11 , Figure 11 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. For example... Figure 11 As shown, for ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. The terminal can be any terminal device including mobile phones, tablets, personal digital assistants, point-of-sale (POS) terminals, in-vehicle computers, etc. Taking a computer as an example:

[0121] Figure 11 This is a block diagram illustrating a portion of the structure of a computer associated with the terminal provided in an embodiment of this application. (Reference) Figure 11The computer includes: a radio frequency (RF) circuit 1210, a memory 1220, an input unit 1230 (including a touch panel 1231 and other input devices 1232), a display unit 1240 (including a display panel 1241), a sensor 1250, an audio circuit 1260 (which can connect to a speaker 1261 and a microphone 1262), a wireless fidelity (WiFi) module 1270, a processor 1280, and a power supply 1290, etc. Those skilled in the art will understand that... Figure 11 The computer architecture shown does not constitute a limitation on the computer and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0122] The memory 1220 can be used to store software programs and modules. The processor 1280 executes various computer functions and data processing by running the software programs and modules stored in the memory 1220. The memory 1220 may mainly include a program storage area and a data storage area. The program storage area may store the operating device and application programs required for at least one function (such as sound playback function, image playback function, etc.); the data storage area may store data created according to the use of the computer (such as audio data, telephone directory, etc.). In addition, the memory 1220 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0123] The processor 1280 is the control center of the computer, connecting various parts of the computer through various interfaces and lines. It performs various computer functions and processes data by running or executing software programs and / or modules stored in the memory 1220, and by calling data stored in the memory 1220. Optionally, the processor 1280 may include one or more processing units; preferably, the processor 1280 may integrate an application processor and a modem processor, wherein the application processor mainly handles operating devices, user interfaces, and application programs, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1280.

[0124] In this embodiment of the application, the processor 1280 included in the terminal also has the following functions:

[0125] In response to the first change request sent by the control layer, the metadata of the table to be changed and the version number to be changed included in the first change request are stored in the memory of the first service node;

[0126] If a second change request is received from the control layer, the real-time table metadata of the first service node is updated to the table metadata to be changed by reading memory, and the real-time version number of the first service node is updated to the version number to be changed, wherein the second change data includes the version number to be changed;

[0127] If a data rollback request is received from the control layer, the data of the table to be changed and the version number to be changed are deleted from memory. The data rollback request includes the version number to be changed.

[0128] See Figure 12 , Figure 12 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1300 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 1322 (e.g., one or more processors) and memory 1332, and one or more storage media 1330 (e.g., one or more mass storage devices) for storing application programs 1342 or data 1344. The memory 1332 and storage media 1330 can be temporary or persistent storage. The program stored in the storage media 1330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1322 may be configured to communicate with the storage media 1330 and execute the series of instruction operations in the storage media 1330 on the server 1300.

[0129] Server 1300 may also include one or more power supplies 1326, one or more wired or wireless network interfaces 1350, one or more input / output interfaces 1358, and / or one or more operating devices, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0130] The steps performed by the server in the above embodiments can be based on this Figure 12 The server structure shown.

[0131] CPU1322 is used to perform the following steps:

[0132] In response to the first change request sent by the control layer, the metadata of the table to be changed and the version number to be changed included in the first change request are stored in the memory of the first service node;

[0133] If a second change request is received from the control layer, the real-time table metadata of the first service node is updated to the table metadata to be changed by reading memory, and the real-time version number of the first service node is updated to the version number to be changed, wherein the second change data includes the version number to be changed;

[0134] If a data rollback request is received from the control layer, the data of the table to be changed and the version number to be changed are deleted from memory. The data rollback request includes the version number to be changed.

[0135] This application also provides a computer-readable storage medium for storing a computer program that executes any one of the methods for modifying table data described in the foregoing embodiments.

[0136] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the methods for modifying table data described in the foregoing embodiments.

[0137] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus, devices, and units can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0139] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0140] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0143] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for modifying table metadata, characterized in that, Applied to the first service node, the method includes: In response to the first change request sent by the control layer, the metadata of the table to be changed and the version number to be changed included in the first change request are stored in the memory of the first service node; If a second change request is received from the control layer, the real-time table metadata of the first service node is updated to the table metadata to be changed by reading the memory, and the real-time version number of the first service node is updated to the version number to be changed, wherein the second change data includes the version number to be changed; If a data rollback request is received from the control layer, the metadata of the table to be changed and the version number to be changed are deleted from the memory, wherein the data rollback request includes the version number to be changed.

2. The method according to claim 1, characterized in that, After storing the table metadata and version number to be changed included in the first change request into the memory of the first service node, the method further includes: Send a storage success command to the control layer; The second change request is sent by the control layer to the first service node after receiving a storage success instruction from all service nodes that are communicatively connected to the control layer.

3. The method according to claim 2, characterized in that, The data rollback request is sent to the first service node when the control layer receives fewer storage success instructions from fewer than all service nodes communicating with the control layer within a first preset time period.

4. The method according to claim 1, characterized in that, The step of storing the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node includes: If the table metadata to be changed included in the first change request is compatible with the real-time table metadata of the first service node, and the version number to be changed included in the first change request is greater than the real-time version number of the first service node, then the table metadata to be changed and the version number to be changed are stored in the memory of the first service node.

5. The method according to claim 4, characterized in that, The method further includes: If the table metadata to be changed included in the first change request is consistent with the real-time table metadata of the first service node, and the version number to be changed included in the first change request is equal to the real-time version number of the first service node, then a change success instruction is sent to the control layer.

6. The method according to any one of claims 1-5, characterized in that, The step of storing the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node includes: The metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed included in the first change request are stored in the first table in the memory of the first service node. The step of updating the real-time table metadata of the first service node to the table metadata to be changed by reading the memory, and updating the real-time version number of the first service node to the version number to be changed, includes: By moving the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed in the first table to the second table in memory, and deleting the table metadata to be changed, the version number to be changed, and the correspondence between the table metadata to be changed and the version number to be changed in the first table, the real-time table metadata of the first service node is updated to the table metadata to be changed, and the real-time version number of the first service node is updated to the version number to be changed; The step of deleting the metadata of the table to be modified and the version number to be modified from the memory includes: Delete the metadata of the table to be changed, the version number to be changed, and the correspondence between the metadata of the table to be changed and the version number to be changed from the first table.

7. The method according to claim 6, characterized in that, The method further includes: If a second change request is received from the control layer, and the first table does not include the version number to be changed and the metadata of the table to be changed, and the version number to be changed is consistent with the real-time version number of the first service node, then a change success instruction is sent to the control layer.

8. A device for modifying table data, characterized in that, Applied to the first service node, the device includes: a storage module, a modification module, and a deletion module; The storage module is used to respond to a first change request sent by the control layer by storing the table metadata to be changed and the version number to be changed included in the first change request into the memory of the first service node. The change module is configured to, upon receiving a second change request sent by the control layer, update the real-time table metadata of the first service node to the table metadata to be changed by reading the memory, and update the real-time version number of the first service node to the version number to be changed, wherein the second change data includes the version number to be changed; The deletion module is used to delete the data of the table to be changed and the version number to be changed from the memory if a data rollback request is received from the control layer, wherein the data rollback request includes the version number to be changed.

9. A computer device, characterized in that, The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the steps of the method for modifying table data according to any one of claims 1 to 7, based on the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the steps of the method for changing table data as described in any one of claims 1 to 7.

Images