Methods and apparatus, devices, media and products for databases

Abstract

Methods and apparatuses, devices, media and products for databases are disclosed. The method includes migrating, based on a target SQL statement, first data applied from a first database of a first storage engine based on a first protocol to a second database of a second storage engine based on a second protocol, the first database being a static copy database created for a source database interacting with the application. The method also includes migrating, in response to completion of the migration of the first data, second data applied corresponding to a target time period from the first database to the second database based on a target locator, wherein the target time period indicates from a first time to a second time after the first time at which the migration of the first data is started, and the target locator indicates a data migration track from the first database to the second database. In this way, data migration between databases of different protocols can be implemented, while ensuring consistency of the migrated application data at the database side without affecting the functional operation of the application side.

Description

Technical Field

[0001] The embodiments of this disclosure generally relate to the field of computers, and more particularly to methods, apparatuses, devices, media, and products for databases. Background Technology

[0002] When an application and / or its functional modules are running, they will interact with the database. For example, on the one hand, the application can initiate query requests to the database based on user actions, established business logic, etc., to retrieve query data that meets predetermined conditions. On the other hand, during business processing, the application may generate new data or update existing data, and so on. According to predetermined organization and storage rules, this data from the application can be consistently persisted to the database. Furthermore, the application can also instruct the deletion of specific data from the database.

[0003] Database security is of paramount importance. Databases store data from applications, which may involve the privacy and confidentiality of application users or service providers. Because applications and databases frequently interact—such as adding, deleting, modifying, and querying data—choosing a trusted database and building a secure storage ecosystem is crucial for application data security. Summary of the Invention

[0004] The embodiments of this disclosure provide a scheme for a database.

[0005] In a first aspect of this disclosure, a method for a database is provided, comprising migrating first data of an application from a first database based on a first storage engine according to a first protocol to a second database based on a second storage engine according to a second protocol, the first database being a statically replicated database created for a source database with which the application interacts. The method further comprises, in response to completion of the migration of the first data, migrating second data of the application corresponding to a target time period from the first database to the second database based on a target locator, wherein the target time period indicates from a first moment when the migration of the first data begins to a second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database.

[0006] In a second aspect of this disclosure, a database processing apparatus is provided, comprising a first migration module configured to migrate first data of an application from a first database based on a first storage engine according to a first protocol to a second database based on a second storage engine according to a second protocol, based on a target SQL statement. The first database is a statically copied database created for a source database with which the application interacts. The apparatus also includes a second migration module configured to, in response to completion of the migration of the first data, migrate second data of the application corresponding to a target time period from the first database to the second database based on a target locator, wherein the target time period indicates from a first moment when the migration of the first data begins to a second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database.

[0007] According to a third aspect of this disclosure, an electronic device is provided. The computing device includes a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform a method or process according to embodiments of this disclosure.

[0008] According to a fourth aspect of this disclosure, a machine-readable storage medium is provided. The machine-readable storage medium stores machine-executable instructions that, when executed by a processor, cause the processor to perform a method or process according to embodiments of this disclosure.

[0009] In a fifth aspect of this disclosure, a computer program product is provided. The computer program product is tangibly stored on a non-transitory computer-readable storage medium and includes a computer program that, when executed by a processor of a computer, causes the processor to perform a method or process according to an embodiment of this disclosure.

[0010] Please note that the Summary of the Invention is provided to introduce a series of concepts in a simplified form, which will be further described below in the Detailed Description. The Summary of the Invention is not intended to identify key or essential features of the disclosure, nor is it intended to limit the scope of the disclosure. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become clearer through a more detailed description of the embodiments of this disclosure in conjunction with the accompanying drawings, in which:

[0012] Figure 1 This is a schematic diagram illustrating an example environment in which methods and / or processes according to embodiments of the present disclosure may be implemented;

[0013] Figure 2 This is a schematic illustration of a flowchart of a method for a database according to an embodiment of the present disclosure;

[0014] Figure 3 This is a schematic illustration of example operations between a database agent-based application and a replaced database according to an embodiment of the present disclosure;

[0015] Figure 4 This is a schematic diagram illustrating a data migration process according to an embodiment of the present disclosure;

[0016] Figure 5 This is a schematic diagram illustrating a topology transformation process for a database according to an embodiment of the present disclosure;

[0017] Figure 6 This is a schematic diagram illustrating another data migration process according to an embodiment of the present disclosure;

[0018] Figure 7 The illustration shows a diagram of a database interaction process according to an embodiment of the present disclosure;

[0019] Figure 8 This is a schematic diagram illustrating a traffic switching process according to an embodiment of the present disclosure;

[0020] Figure 9 This is a schematic illustration of a database processing apparatus according to an embodiment of the present disclosure;

[0021] Figure 10 These are schematic block diagrams that can be used to implement example devices according to embodiments of the present disclosure.

[0022] In all the accompanying drawings, the same or similar reference numerals usually indicate the same or similar elements. Detailed Implementation

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] In the description of embodiments of this disclosure, the term "comprising" and its variations should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects unless explicitly indicated otherwise.

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0026] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0027] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0028] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0029] As mentioned above, applications and databases frequently interact. The security of application data within the database is paramount; therefore, it is necessary to select a trusted database and build a secure storage ecosystem to protect the rights of application users and providers.

[0030] Initially, applications were typically configured with open-source or mainstream databases for storing, querying, updating, and cleaning application data. However, with increasing demands for security and customization, these traditional databases have revealed their limitations to varying degrees, becoming increasingly unable to meet stringent security standards and personalized functional requirements. Currently, more and more applications are turning to domestically developed databases or similar products to improve the security of application data storage, personalize database deployment, and enable privatization. Such privatized deployments are beneficial for improving the user experience. "Domestic information technology innovation" refers to relevant standards and specifications in the field of information technology application innovation. The domestic information technology innovation industry is not only a fundamental support for data security and network security, but also an important component of "new infrastructure."

[0031] Data migration between databases using different protocols (e.g., migrating application data from a traditional database to a new domestically developed database) poses challenges to application stability and user experience. To minimize the impact of data migration on the application side and ensure a seamless migration experience for users, application data migration must be non-downtime. During the migration process, application data continues to be generated in the existing database as the application continues to be used. Furthermore, all application data—whether generated before, during, or after the migration—must be preserved. Data consistency and integrity must be guaranteed throughout the migration process. Additionally, given the massive volume of application data, the migration speed should be as fast as possible without any bottlenecks.

[0032] In some related solutions, migration tools can be used to migrate data from one database to another. These tools have extraction, transformation, and loading capabilities. More specifically, first, the data to be migrated is queried from the source database and stored in a temporary file in a predetermined format, which consumes significant local storage resources. Then, the data in the temporary file is transformed into a data format that the destination database can recognize; this process is relatively slow and the data may be lossy. Next, the temporary file is imported into the destination database. However, introducing such a migration tool as a standalone tool can increase the difficulty of adaptation. Furthermore, because the data needs to be written line by line to the local file before being transformed and loaded into the destination database, performance degradation occurs (e.g., slow migration speed, huge storage resource consumption, etc.).

[0033] To address at least some of the aforementioned and other potential problems, embodiments of this disclosure provide a scheme for a database that includes migrating first data of an application from a first database based on a first storage engine according to a first protocol to a second database based on a second storage engine according to a second protocol, based on a target SQL statement. The first database is a statically copied database created for a source database with which the application interacts. The scheme also includes, in response to the completion of the migration of the first data, migrating second data of the application corresponding to a target time period from the first database to the second database based on a target locator, wherein the target time period indicates from a first moment when the migration of the first data begins to a second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database.

[0034] According to embodiments of the present disclosure, a data migration strategy between databases using different protocols is provided. By creating a static copy of the database that interacts with the application, application data can be quickly migrated from a database based on the original protocol to a database based on the new protocol without affecting the application's functionality. Furthermore, this solution can accurately identify newly generated application data during the migration process and further migrate it to the new database, thereby ensuring the consistency of the migrated application data on the database side.

[0035] The following is for reference. Figures 1 to 10 The present disclosure is provided to illustrate its basic principles and several exemplary implementations. It should be understood that these exemplary embodiments are given only to enable those skilled in the art to better understand and implement the embodiments of the present disclosure, and are not intended to limit the scope of the disclosure in any way.

[0036] Figure 1 This is a schematic diagram illustrating an example environment 100 in which methods and / or processes according to embodiments of the present disclosure may be implemented. Figure 1 As shown, example environment 100 includes application 110, database agent 120, and database 130. It should be understood that... Figure 1 The arrangement described herein is merely exemplary and not a limiting description. For example, the number of database agents 120 and databases 130 could be two or more. A suitable environment configuration can be selected based on actual needs.

[0037] exist Figure 1 Only a limited set of components and exemplary connections are shown in this document. It should be understood that this is for illustrative and diagrammatic purposes and is not intended to limit the scope of this disclosure, and other different components may exist. For example, display components and input components, etc. By way of example and not limitation, specific instances of stored data in database 130, results of operations on the stored data (e.g., query results of query operations, etc.) may be displayed on the display component, and requests for operations on the stored data may be entered through the input component.

[0038] According to embodiments of this disclosure, application 110 can be various types of applications, such as financial applications, office-related applications, etc. Application 110 interacts with a database (also referred to herein as the source database) based on a source protocol (also referred to herein as the first protocol), where application data of application 110 is stored. In some embodiments, the source database can be an online database for online services of application 110, which interacts directly with application 110. Furthermore, after enabling the database proxy service, the source database can be a local database of a storage engine based on the first protocol (also referred to herein as the first storage engine) within a database proxy 120 based on the first protocol. It should be understood that, in the context of this disclosure, application data should be interpreted in the broadest sense, encompassing various types of data associated with the application, including but not limited to user data, configuration data, etc.

[0039] For the purpose of database replacement, it is necessary to migrate application data from the source database to another database 130 (also referred to as the second database or destination database) based on a different protocol than the original protocol (also referred to as the second protocol in this document). Due to the change in the database protocol framework, if application 110 interacts directly with database 130, it may require different drivers and interfaces for accessing the database, and modifications to the application and / or its functional modules to adapt to differences in Structured Query Language (SQL), different data organization methods, and new primary key handling, system functions, custom capabilities, binary types, view usage, parameter configuration, etc. This will result in a significant workload for adaptation (e.g., recoding, debugging, etc.).

[0040] According to embodiments of this disclosure, a database proxy 120 based on a first protocol is configured between application 110 and database 130, acting as an interaction intermediary for data interaction between application 110 and database 130. The database proxy 120 is configured with a storage engine based on a second protocol (also referred to herein as a second storage engine) to adapt to database replacement, for example, configured to transform SQL. By using the database proxy 120 according to embodiments of this disclosure, the adaptation load after database replacement can be simplified and the impact on application operation can be reduced. The database proxy 120 will be described in further detail below with reference to the accompanying drawings.

[0041] The above combination Figure 1 Example environments 100 in which methods and / or processes according to embodiments of this disclosure may be implemented are described below in conjunction with... Figure 2This document describes a method 200 for a database according to embodiments of the present disclosure. This method 200 enables data migration between databases using different protocols, ensuring the consistency of migrated application data on the database side without affecting the functionality of the application.

[0042] Figure 2 This is a schematic illustration of a flowchart of a method 200 for a database according to an embodiment of the present disclosure. At 210, first data of an application is migrated from a first database based on a first storage engine based on a first protocol to a second database based on a second storage engine based on a second protocol, the first database being a statically copied database created for the source database with which the application interacts, based on a target SQL statement.

[0043] The source database can be related to the application (e.g., Figure 1 The application 110 directly interfaces with a database (such as an online database). According to embodiments of this disclosure, a static copy database (i.e., the aforementioned first database) is created for the source database. In other words, the first database is a copy of the source database and has the same data as the source database when it is created. The first database is static at this time; for example, newly generated application data will not be immediately synchronized to the first database, i.e., no data change will occur. Data migration for application data will start from this copy database, while the source database will interact normally with the application. Furthermore, the target SQL statement can correspond to all application data of the application, i.e., the first data is the full amount of application data. It should be understood that the target SQL statement can also correspond to a portion of the application data. In some embodiments, the application data migration at 210 is a parallel data migration, thereby promoting an increase in the migration speed of the first data. This will be described in further detail below.

[0044] At 220, in response to the completion of the migration of the first data, the second data of the application corresponding to the target time period is migrated from the first database to the second database based on the target locator, wherein the target time period indicates from the first moment when the migration of the first data begins to the second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database.

[0045] As described above, during the migration of the first data, the application continues to generate new application data. This newly generated application data also needs to be migrated to the second database to achieve data consistency and integrity during the migration process. According to embodiments of this disclosure, the second data corresponding to a target time period is migrated based on a target locator. The first moment of the target data segment is the moment when the migration of the first data begins, and the second moment of the target time period can be the moment when the migration of the first data is completed. In other words, the second data can be incremental data applied throughout the entire migration process of the first data. In some embodiments, the second moment can also be the moment after the migration of the first data begins and before the migration of the first data is completed, which may be the moment when an interruption occurs. In other words, the second data can be newly generated application data applied during the period from the start of the migration of the first data to the interruption of the migration. Furthermore, the second moment can also be the moment after the migration of the first data is completed. The accurate identification of the incremental data to be migrated can be achieved based on the target locator (such as gtid) that indicates the data migration trajectory. This will be described in further detail below.

[0046] According to the method 200 for a database according to embodiments of this disclosure, a data migration strategy between databases using different protocols is provided. By creating a static copy database for the database interacting with the application, application data can be quickly migrated from a database based on the original protocol to a database based on the new protocol without affecting the functional operation of the application. Furthermore, this solution can accurately identify newly generated application data during the migration process and further migrate it to the new database, thereby ensuring the consistency of the migrated application data on the database side.

[0047] Figure 3 This diagram schematically illustrates an example operation 300 between an application based on a database proxy and a replaced database according to an embodiment of the present disclosure. By configuring a database proxy based on the original protocol as an interaction intermediary between the application (or a functional module of the application) and the new database, it is possible to ensure that the application initiates data interaction according to the original protocol framework, while leveraging the new protocol-based storage engine within the database proxy to facilitate seamless integration with the new database. The application side exemplarily includes three functional modules: application functional module 312, application functional module 314, and application functional module 316. Interaction requests from these upper-layer application functional modules can be parallel, and connections to the replaced database can also be parallel, enabling efficient and accurate data access through a connection pool management mechanism.

[0048] Application function modules 312, 314, and 316 on the application side can be coupled to the database agent 320 based on the first protocol via the connection driver 318. Since the database agent is built based on the original protocol framework, no modifications are needed to the application side; for example, the connection driver 318 does not need to be replaced.

[0049] like Figure 3 As shown, the database agent 320 based on the first protocol can have a layered architecture, including a service layer 322 and a storage layer 324. The service layer 322, also known as the compute layer, can be configured to handle interactive requests, plan data storage, etc. The storage layer 324 includes multiple storage engines, such as... Figure 3 The first storage engine 323, the second storage engine 326, the third storage engine 327, etc. are shown in the figure.

[0050] According to embodiments of this disclosure, the first storage engine 325 is a storage engine based on the first protocol (i.e., the original protocol). As described above, the database agent 320 based on the first protocol can be viewed as adding new functional plugins to the database within the original protocol framework (here, referring to the application-level database, which can be considered as a local database), such as for connecting to remote databases externally (e.g., Figure 3 The diagram schematically illustrates storage engines (e.g., second storage engine 326, third storage engine 327) for a second database 330 based on a second protocol and a third database 340 based on a third protocol. In other words, the database agent 320 based on the first protocol has the ability to store data and is configured to store application data before the database is replaced. For example, the database of the first storage engine 325 (i.e., the source database) stores application data for application function modules 312, 314, and 316. However, due to the adaptation requirements of the database replacement, the database of the first storage engine 325 no longer stores application data locally, and the application data therein needs to be migrated to a remote database (e.g., at least one of the second database 330 and the third database 340).

[0051] According to embodiments of this disclosure, the second storage engine 326 is a storage engine based on a second protocol (i.e., another protocol different from the original protocol). As described above, the second storage engine 326 can be coupled to the second database 330 and can be configured to translate SQL statements (e.g., converting SQL statements from other protocols (such as SQL statements from the first protocol) to those of the second protocol). The translated SQL statements can be transmitted to a database driver 3300 corresponding to the second database 330 (which may be a database driver within the storage engine). This database driver can execute the translated SQL statements to perform corresponding operations on the corresponding data in the second database 330. Furthermore, the second storage engine 326 can be configured to store application data from one or more application function modules into the second database 330 and can manage the stored data in the database. In some embodiments, the second database 330 can be a trusted database (e.g., a domestically developed database).

[0052] Furthermore, the database proxy 320 based on the first protocol according to embodiments of this disclosure can link to multiple external databases, thereby achieving scalability, wherein these external databases may be based on different protocol frameworks. Figure 3 To illustrate, the third storage engine 327 is a storage engine based on a third protocol (i.e., another protocol different from both the first and second protocols). The third storage engine 327 can be coupled to a third database 340 and can be configured to translate SQL statements (e.g., translating SQL statements from other protocols (such as those of the first protocol) into those of the third protocol). The translated SQL statements can be transmitted to a database driver 3400 corresponding to the third database 340 (which may be an in-store database driver within the storage engine). This database driver can execute the translated SQL statements to perform corresponding operations on the corresponding data in the third database 340. Furthermore, the third storage engine 327 can be configured to store application data from one or more application function modules into the third database 340 and can manage the stored data in that database. In some embodiments, the third database 340 can be another trusted database (e.g., a different type of domestically developed database). It should be understood that the number of databases linked to by the database proxy can be more or less, and the protocol frameworks of these linked databases can be different or the same. In the following description, for ease of understanding and illustration, an example of an external database will be used. This is exemplary and not restrictive. The database scheme according to the embodiments of this disclosure can also be implemented in a multi-external database environment.

[0053] Figure 4This diagram schematically illustrates a data migration process 400 according to an embodiment of the present disclosure. As described above, the application data to be migrated is in a first storage engine 425 based on a first protocol. This application data needs to be migrated to a second protocol side, where the first and second protocols are different. The second storage engine 426 based on the second protocol points to a corresponding backend second database 430 based on the second protocol, and they are compatible. In some embodiments, the second storage engine 426 can be operated directly without directly interacting with the second database 430. In other words, application data (with respect to the original protocol) in the database of the first storage engine 425 can be copied to the second storage engine 426, and the copied application data (with respect to the new protocol) will therefore be stored in the second database 430.

[0054] like Figure 4 As shown, the database agent 420 based on the first protocol may include a first storage engine 425 and a second storage engine 426. The second storage engine 426 may be configured to convert target SQL statements from SQL statements of the first protocol to SQL statements of the second protocol, so that the database driver 4300 of the second storage engine 426 can execute the converted target SQL statements.

[0055] According to embodiments of this disclosure, a first database is created as a static copy of the source database, and a transformed target SQL statement is executed on first data in the first database to migrate the first data. The created first database may be a database based on a first protocol. A non-limiting example of the target SQL statement may be "insertinto B select * from A", where A indicates the source of the migration, B indicates the destination of the migration, and the target SQL statement instructs that all data in A be inserted into B. That is, the first data to be migrated based on the target SQL statement (in this case, also referred to as the existing SQL statement) may be all application data of the application (i.e., existing data). It should be understood that other SQL statements may be used to migrate only a portion of the application's application data.

[0056] The first data can be organized in at least one first table in a first database. Transformed target SQL statements can be executed in parallel against each of the at least one first data tables to facilitate the replication of the first data to at least one second table in a second database 430, the at least one second table corresponding to the at least one first table. In some embodiments, the at least one second table and the at least one first table can have the same table structure (e.g., the number of tables, fields, and the data type of each field, etc.), i.e., the same data organization method.

[0057] For a specific large table, in order to speed up the data replication process, after generating the transformed target SQL statement, the transformed target SQL statement can be provided to the thread pool for execution, while the main thread that generated the SQL statement continues to generate new SQL statements. This achieves parallel migration for a specific table, thereby greatly accelerating the data migration speed.

[0058] As can be seen from the above, in this migration process, the second storage engine 426 can be a channel, configured as an adapter. The SQL statement used for querying and inserting is converted from the original protocol SQL statement by the second storage engine 426 into the new protocol SQL statement, and then executed by the database driver 4300 of the second storage engine 426, thereby realizing the requirement of migrating application data from the first database to the second database 430. The migration process in this embodiment of the disclosure does not involve the problem of writing intermediate data to temporary files, nor does it involve the workload of data conversion and processing, and it does not require the introduction of additional components.

[0059] After the initial data migration is complete, since the migration is based on replication (i.e., query first, then insert), the initial data can reside in the first directory database of the first database, and the corresponding initial metadata resides in a second directory database within the first database, which is different from the first directory database. The initial data and initial metadata are corresponding; they can have the same table structure but contain different engine information. For example, the initial data in the first directory database is related to the first storage engine, while the initial metadata is related to the second storage engine. Below, we will combine... Figure 5 This will be described in further detail.

[0060] Figure 5 This diagram schematically illustrates a database topology transformation process 500 according to an embodiment of the present disclosure. After the migration of existing data is completed, incremental data needs to be migrated. The first problem to be solved is the subscription of incremental data. In some related solutions, an additional component is added to capture and parse database logs and generate corresponding SQL statements for execution, thereby writing the incremental data into the new database. However, these related solutions first require adaptation to the new database, and the generation and execution of corresponding SQL statements are error-prone and performed serially, and consistency is not guaranteed. If the subscription service crashes, the migration location is lost, and all previous efforts are wasted. By introducing a database agent based on the original protocol according to an embodiment of the present disclosure, which can interact with the application based on the original protocol framework without modifying the application side, and which includes a storage engine based on the new protocol, can be linked to databases based on the new protocol for seamless integration, thereby solving the aforementioned difficulties in database adaptation and SQL statement generation and execution.

[0061] like Figure 5 As shown, the first database 510, serving as an application-level database, may include a first directory database 511 and a second directory database 512. The first directory database 511 stores first data, and the second directory database 512 stores first metadata corresponding to the first data. On the local side, the metadata of the first data is stored in the second directory database 512 within the first database 510, while the actual data is stored in a remote second database 540.

[0062] According to embodiments of this disclosure, a relay database 520 for a second storage engine can be created based on the second directory database 512, and this relay database 520 is coupled between the first database 510 and the second database 540. In some embodiments, a new database agent (based on a first protocol) can be created, and the relay database 520 according to embodiments of this disclosure is formed by copying or importing the first metadata of the second directory database 512 into the database of the new database agent, wherein the original database agent and the new database agent can interact through their respective service layers. The created relay database 520 can be based on the first protocol. The second directory database 512 can then be deleted from the first database 510. Based on the first metadata in the relay database 520, the migrated data (e.g., the aforementioned migrated first data) in the second database 540 can be accessed.

[0063] After deleting the second directory database 512, only the first directory database 511 remains in the first database 510. In other words, the first database 510 can store first data (i.e., application data equivalent to the first storage engine stored locally), and the relay database 520 can store first metadata corresponding to this first data. In this case, due to the stored data, the table structures in the first database 510 and the relay database 520 are completely identical and correspond one-to-one, but the engine information differs between them. The first metadata in the relay database 520 can be related to the second protocol. In some embodiments, the data content of the tables in the first database 510 and the relay database 520 is also identical and corresponding, which is due to the replication from the first storage engine to the second storage engine during the migration of existing data.

[0064] The first database 510 and the relay database 520 can reside within the original database agent and the new database agent, respectively, and correspond to different storage engines (i.e., both are within the same protocol framework ecosystem of the first protocol), while the second database 540 can be an external database relative to the first database 510 and the relay database 520. As described above, the first data has been migrated from the first database 510 to the second database 540 (e.g., through query insertion), and it is necessary to verify the consistency of the migration for the migrated existing data.

[0065] Currently, no consistency verification tool has been developed for databases using different protocols. Therefore, the first database 510 based on the first protocol and the second database 540 based on the second protocol cannot be directly compared. However, since both the first database 510 and the relay database 520 correspond to database agents (the original database agent and the new database agent) based on the first protocol, and both are based on the first protocol, their data (i.e., the first data and the first metadata corresponding to that first data) are consistent except for engine information. In the case where the first protocol is, for example, the MySQL protocol, the first database 510 and the relay database 520 can be in a master-slave relationship (i.e., the relationship between the master database and the slave database used to implement master-slave replication). Thus, the first database 510 and the relay database 520 can be compared to perform data verification between the first database 510 and the second database 540.

[0066] According to embodiments of this disclosure, after the first data is migrated to the second database 540, a first consistency of the first data between the first database 510 (as the primary database) and the second database 540 can be determined by performing a first comparison between the primary database 510 and the relay database 520 (as the secondary database). This enables consistency verification of migrated data between databases using different protocols. In some embodiments, this first comparison can be implemented, for example, using the pt-table-checksum tool.

[0067] More specifically, the pt-table-checksum tool can perform slicing on data, with each slice having a fixed number of rows. The pt-table-checksum tool calculates the checksum of a slice by executing an SQL statement on the master database (also known as the primary database), essentially concatenating all data in that slice and then calculating an MD5 value. After the calculation, the SQL statement is generated in the binlog, and the calculated MD5 value is stored in a corresponding table with two columns: one for the primary node and one for the secondary node. The calculated MD5 value is then stored in the primary node's MD5 column of the checksum record for that slice. This is also synchronized to the secondary nodes via the binlog. When the secondary database (also known as the slave database) has copied the SQL statement used to calculate the checksum, it will be executed again on the slave database to calculate the MD5 value for the same slice in the same table. The checksum record copied from the primary database will then be found, and the MD5 value calculated on the slave database will be updated in the secondary node's MD5 column of that checksum record. Thus, the checksum for that slice is calculated. After calculating the checksum for all slices, check the MD5 values ​​of the master node and the slave node for all slices to see if there are any differences. If there are, it indicates that there is inconsistent data in that slice; otherwise, it means that the entire table is consistent.

[0068] Figure 6 This is a schematic illustration of another data migration process 600 according to an embodiment of the present disclosure. Figure 6 The source database 630 that interacts with the application is shown. Figure 6 (Bold text) The first database 610, a replica database of the source database 630, the relay database 620, and the remote second database 640. Traffic from the application is directed to the source database 630 (by... Figure 6 (As indicated by the arrow box in the image), the first database 610 still locally stores the first data after the data migration, and the relay database 620 stores the first metadata corresponding to the first data. The first data and the first metadata are identical except for engine information. Furthermore, the source database 630, the first database 610, and the relay database 620 can correspond to a database agent based on the first protocol (e.g., located within or created within it), and they can interact through the service layer of the corresponding database agent. The second database 640 can be an external database relative to the source database 630, the first database 610, and the relay database 620. In combination... Figure 6 The description uses the MySQL protocol as an example of the first protocol. It should be understood that this is exemplary and not restrictive.

[0069] First, incremental data needs to be migrated from the source database 630 to the first database 610. According to embodiments of this disclosure, second data indicating incremental data applied during a target time period can be migrated from the source database 630 to the first database 610 based on a first target locator corresponding to the creation of the first database 610. The first target locator is determined based on a first log from the source database 630 to the first database 610.

[0070] For source database 630 and first database 610, based on a subscription mechanism, source database 630, as the master database, can send database logs (such as binlogs) to first database 610, as the slave database. These database logs (referred to herein as the first logs) can indicate incremental data applied during the migration of existing data. Incremental data is identified based on a first target locator determined according to the first logs, facilitating the migration of incremental data from source database 630 to first database 610. Since first database 610 is a statically created replica of source database 630, the two are completely identical at creation. The first target locator (such as a consistency point) is also generated and recorded in the database logs at this time.

[0071] Then, incremental data needs to be migrated from the first database 610 to the relay database 620. According to embodiments of this disclosure, in response to the second data having been migrated to the first database 610, a second target locator (which may be combined with...) is used to indicate that the second data has been migrated from the source database 630 to the first database 610. Figure 2 The target locator (when describing) can migrate second data from the first database 610 to the relay database 620. The second target locator is determined based on the second log from the first database 610 to the relay database 620.

[0072] While the first database 610 continuously executes the first log for incremental data, it also generates a database log (i.e., a second log). For both the first database 610 and the relay database 620, based on a subscription mechanism, the first database 610, as the master database, can send a database log (such as a binlog) to the relay database 620, which is the slave database. This database log (referred to herein as the second log) indicates the incremental data at the first database 610. Incremental data is identified based on a second target locator determined according to the second log, facilitating the migration of incremental data from the first database 610 to the relay database 620. The tables in the relay database 620 are all related to the second storage engine, therefore all incremental data changes will point to these specific tables related to the second storage engine. Thus, all database log changes are translated into corresponding SQL statements in the second database 640.

[0073] Next, the incremental data needs to be migrated from the relay database 620 to the second database 640. According to embodiments of this disclosure, in response to the second data having been migrated to the relay database 620, the second data can be migrated from the relay database 620 to the second database 640 based on the first metadata in the relay database 620. In some embodiments, a second storage engine can be used to convert the incremental SQL statement corresponding to the second data from a first protocol SQL statement to a second protocol SQL statement, and the converted incremental SQL statement can be executed in the second database 640 using a database driver in the second storage engine.

[0074] According to embodiments of this disclosure, after the second data is migrated to the second database, a second consistency of the second data between the first database 610 (as the master database) and the second database 640 can be determined by performing a second comparison between the first database 610 (as the master database) and the relay database 620 (as the slave database). The second comparison can be performed after the verification based on the first comparison has passed. The verification based on the second comparison can employ the same or similar comparison verification techniques as the first comparison described above. Further details are omitted here.

[0075] Figure 7 The illustration shows a diagram of a database interaction process 700 according to an embodiment of the present disclosure. In conjunction with... Figure 7The description uses the MySQL protocol as an example, which should be understood as exemplary rather than restrictive. The binlog is organized by transaction, with each binlog entry consisting of a series of transactions. A transaction contains several events, where the first event is "begin," indicating the start of the transaction, and the last is "commit," indicating the commit of the transaction. The events in between are the specific operations (such as insert, delete, or update events). For a given transaction, each event corresponds to that transaction. If replication from the master is unexpectedly interrupted, a transaction on the slave will not be in an intermediate state; it will either be in the start state or in the commit state. For example, if the interruption occurs midway through a transaction (e.g., during a specific operation), due to transaction integrity requirements, the executed operations will be rolled back to the start of the transaction, resulting in the transaction being in the start state.

[0076] For scenarios involving switching to databases with different protocols, binlogs are composed of transactions. Each transaction is applied to the database based on the new protocol (e.g., ...). Figure 7 When using the second database (740) in the database, persistence is also based on transactions as the smallest unit, where each transaction corresponds to a locator (e.g., but not limited to, the aforementioned gtid). To achieve consistency of the migrated data, according to embodiments of this disclosure, 1) the binlog is obtained, 2) transactions in the binlog are parsed, and 3) the events included within the transaction are applied or executed.

[0077] 4) If the processing event (the currently processed event) is begin (i.e., the start event), the transaction begins in the second database 740. 5) If the processing event is a specific operation event, the corresponding SQL statement is generated, converted into a new protocol SQL statement, and executed. According to embodiments of this disclosure, if the processing event is determined to be commit (i.e., the commit event), insert SQL statements for inserting locators are concatenated or added to multiple events of the transaction. The added insert SQL statements are after the start event and before the commit event, and do not disrupt specific operation events or intervene between specific operation events. If the commit event is executed, the transaction is persisted to the second database 740, where the locator corresponding to the transaction is inserted into the locator set of the second database. If the commit event is not executed, the transaction is rolled back to the start event of the transaction.

[0078] More specifically, 6) if event is commit, concatenate the insert SQL statement used to insert the locator into the locator status table, which corresponds to the transaction. For example... Figure 7 As shown, the insert SQL statement is appended to the specific transaction and before the commit. This insert SQL statement is translated into a second protocol SQL statement and executed in the second database 740. Next, the transaction is committed, thus successfully committing the current transaction. This process (3)-6) is repeated continuously to maintain synchronization between the databases.

[0079] Inserting a locator into the locator state table (also known as the locator set) is configured into the transaction along with the specific operations of the current transaction. If the commit operation fails, the insertion into the locator state table will also fail; if it succeeds, the insertion will also succeed. This ensures the consistency between GTID and the transaction.

[0080] Furthermore, in the event of an interruption, the locator recorded in the locator status table of the second database 740 will be used as the standard, ignoring the locator status table recorded in the local InnoDB, and a new data replication request will be made to the primary database, thereby achieving data consistency throughout the entire chain (from the source database to the first database 710, then to the relay database 720, and finally to the second database 740).

[0081] Figure 8 This is a schematic illustration of a traffic switching process 800 according to an embodiment of the present disclosure. In response to the second data being migrated to the relay database 820, writes to the source database 830 can be disabled (in...). Figure 8 (shown in shaded mode), which can switch data routing from the application to the relay database 820 (by...) corresponding to the storage engine based on the second protocol. Figure 8 (indicated by the arrow box in the image), and can delete source database 830 and first database 810 (in the image). Figure 8 (Shown in shaded area). In some embodiments, the consistency state of the first database 810, the relay database 820, and the second database 840 no longer changes, and the data routing is switched to the relay database 820, enabling the application to interact with the relay database 820.

[0082] Figure 9 This is a schematic illustration of an apparatus 900 for a database according to an embodiment of the present disclosure. The apparatus 900 may include multiple units or modules for performing steps or actions in the methods or processes discussed above. Figure 9As shown, the apparatus 900 includes a first migration module 910 configured to migrate first data of an application from a first database based on a first storage engine using a first protocol to a second database based on a second storage engine using a second protocol, based on a target SQL statement. The first database is a statically copied database created for a source database that interacts with the application. The apparatus 900 also includes a second migration module 920 configured to, in response to the completion of the migration of the first data, migrate second data of the application from the first database to the second database based on a target locator, corresponding to a target time period. The target time period indicates the period from a first moment when the migration of the first data begins to a second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database.

[0083] In some embodiments, the first storage engine and the second storage engine may be included in a database agent based on the first protocol, and the second protocol may be different from the first protocol. The apparatus 900 may further include: an SQL conversion module configured to convert the target SQL statement from an SQL statement of the first protocol to an SQL statement of the second protocol using the second storage engine; and an SQL execution module configured to execute the converted target SQL statement in the second database using a database driver in the second storage engine.

[0084] In some embodiments, wherein the first data may be organized in the first database in at least one first table, the SQL execution module may be further configured to: execute the transformed target SQL statement in parallel for each first data table in the at least one first table to facilitate the replication of the first data to at least one second table in the second database, the at least one second table corresponding to the at least one first table.

[0085] In some embodiments, after the migration of the first data is completed: the first data may exist in a first directory database of the first database, and the first metadata corresponding to the first data may exist in a second directory database of the first database that is different from the first directory database. The first metadata is related to the second storage engine, wherein the first database may be an application-level database, and the first directory database and the second directory database may be directory-level databases.

[0086] In some embodiments, the apparatus 900 may further include: a database creation module configured to create a relay database for the second storage engine based on the second directory database, the relay database being coupled between the first database and the second database; and a database deletion module configured to delete the second directory database in the first database.

[0087] In some embodiments, the apparatus 900 may further include a first comparison module configured to: determine a first consistency between the first database and the second database for the first data by performing a first comparison between the first database as the master database and the relay database as the slave database after the first data has been migrated to the second database.

[0088] In some embodiments, the apparatus 900 may further include a source migration module configured to migrate second data indicating an incremental application during the target time period from the source database to the first database based on a first target locator corresponding to the creation of the first database, the first target locator being determined based on a first log from the source database to the first database.

[0089] In some embodiments, the target locator may be a second target locator, and the second migration module 920 may be further configured to: in response to the second data having been migrated to the first database, migrate the second data from the first database to the relay database based on the second target locator indicating that the second data has been migrated from the source database to the first database, wherein the second target locator is determined based on a second log from the first database to the relay database; and in response to the second data having been migrated to the relay database, migrate the second data from the relay database to the second database based on the first metadata in the relay database.

[0090] In some embodiments, migrating the second data from the relay database to the second database may include: using the second storage engine to convert an incremental SQL statement corresponding to the second data from an SQL statement of the first protocol to an SQL statement of the second protocol; and using a database driver in the second storage engine to execute the converted incremental SQL statement in the second database.

[0091] In some embodiments, the apparatus 900 further includes a second comparison module configured to determine a second consistency between the first database and the second database for the second data by performing a second comparison between the first database as the master database and the relay database as the slave database after the second data has been migrated to the second database.

[0092] In some embodiments, the apparatus 900 further includes: a log parsing module configured to determine multiple events of a transaction from the second log; a concatenation module configured to add an insert SQL statement for inserting locators to the multiple events in response to determining that a processing event among the multiple events is a commit event; a persistence module configured to persist the transaction to the second database in response to the commit event being executed, wherein the locator corresponding to the transaction is inserted into the locator set of the second database; and a rollback module configured to roll back the transaction to the start event of the transaction in response to the commit event not being executed.

[0093] In some embodiments, the apparatus 900 may further include a database enabling module configured to: disable writing to the source database in response to the second data having been migrated to the relay database; switch the data routing from the application to the relay database; and delete the source database and the first database.

[0094] In some embodiments, the first database may be a local database for the database agent, and the second database may be a remote database relative to the database agent.

[0095] Figure 10 A block diagram of an electronic device (device 1000) according to certain embodiments of the present disclosure is shown. Device 1000 may be the device or apparatus described in the embodiments of the present disclosure. Figure 10 As shown, device 1000 includes a central processing unit (CPU) and / or a graphics processing unit (GPU) 1001, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 1002 or loaded from storage unit 1008 into random access memory (RAM) 1003. Various programs and data required for the operation of device 1000 can also be stored in RAM 1003. The CPU / GPU 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004. Although not shown in... Figure 10 As shown, device 1000 may also include a coprocessor.

[0096] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0097] The various methods or processes described above can be executed by CPU / GPU 1001. For example, in some embodiments, the methods may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by CPU / GPU 1001, one or more steps or actions in the methods or processes described above can be performed.

[0098] In some embodiments, the methods and processes described above can be implemented as a computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of this disclosure.

[0099] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0100] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0101] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and conventional procedural programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0102] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0103] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0105] Various embodiments of the present disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the various embodiments disclosed herein.

Claims

1. A method for a database, comprising: Migrate application data from a first database based on a first storage engine based on a first protocol to a second database based on a second storage engine based on a second protocol, using target SQL statements. The first database is a static replica database created for the source database that interacts with the application. as well as In response to the completion of the migration of the first data, second data of the application corresponding to a target time period is migrated from the first database to the second database based on a target locator, wherein the target time period indicates from the first moment when the migration of the first data begins to a second moment after the first moment, and the target locator indicates the data migration trajectory from the first database to the second database. After the migration of the first data is completed, the first data resides in the first directory database of the first database, and the first metadata corresponding to the first data resides in the second directory database of the first database. This first metadata is related to the second storage engine. The method further includes: creating a relay database for the second storage engine based on the second directory database, the relay database being coupled between the first database and the second database and including the first metadata.

2. The method of claim 1, wherein the first storage engine and the second storage engine are included in a database broker based on the first protocol, and the second protocol is different from the first protocol, the method further comprising: The target SQL statement is converted from the SQL statement of the first protocol to the SQL statement of the second protocol using the second storage engine; as well as The transformed target SQL statement is executed in the second database using the database driver in the second storage engine.

3. The method of claim 2, wherein the first data is organized in the first database in at least one first table, and executing the transformed target SQL statement comprises: The transformed target SQL statement is executed in parallel for each of the at least one first table to facilitate the replication of the first data to at least one second table in the second database, the at least one second table corresponding to the at least one first table.

4. The method according to claim 1, wherein: The first database is an application-level database, and the first directory database and the second directory database are directory-level databases. The first directory database is different from the second directory database.

5. The method according to claim 1, further comprising: Delete the second directory database from the first database.

6. The method according to claim 5, further comprising: After the first data is migrated to the second database, a first consistency between the first database and the second database for the first data is determined by performing a first comparison between the first database, which is the master database, and the relay database, which is the slave database.

7. The method according to claim 5, further comprising: Based on a first target locator corresponding to the creation of the first database, the second data indicating the incremental migration of the application from the source database to the first database during the target time period is determined based on a first log from the source database to the first database.

8. The method of claim 7, wherein the target locator is a second target locator, and migrating the second data from the first database to the second database comprises: In response to the second data having been migrated to the first database, the second data is migrated from the first database to the relay database based on the second target locator indicating that the second data has been migrated from the source database to the first database, the second target locator being determined based on the second log from the first database to the relay database; as well as In response to the fact that the second data has been migrated to the relay database, the second data is migrated from the relay database to the second database based on the first metadata in the relay database.

9. The method of claim 8, wherein migrating the second data from the relay database to the second database comprises: The incremental SQL statement corresponding to the second data is converted from the SQL statement of the first protocol to the SQL statement of the second protocol using the second storage engine. as well as The transformed incremental SQL statement is executed in the second database using the database driver in the second storage engine.

10. The method of claim 8, further comprising: After the second data is migrated to the second database, a second consistency for the second data between the first database (which is the master database) and the relay database (which is the slave database) is determined by performing a second comparison.

11. The method of claim 8, further comprising: Identify multiple events of the transaction from the second log; In response to determining that the processing event among the plurality of events is a commit event, an insert SQL statement for inserting a locator is added to the plurality of events; In response to the commit event being executed, the transaction is persisted to the second database, wherein the locator corresponding to the transaction is inserted into the locator set of the second database; as well as In response to the commit event not being executed, the transaction is rolled back to the start event of the transaction.

12. The method of claim 7, further comprising: In response to the fact that the second data has been migrated to the relay database, writing to the source database is prohibited; Switch the data route from the application to the relay database; as well as Delete the source database and the first database.

13. The method according to claim 1, wherein: The first database is a local database for the database proxy, and The second database is a remote database relative to the database proxy.

14. An electronic device comprising: processor; as well as A memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 13.

15. A machine-readable storage medium having stored thereon machine-executable instructions, wherein the machine-executable instructions, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 13.

16. A computer program product comprising a computer program that, when executed by a processor of a computer, causes the processor to perform the method according to any one of claims 1 to 13.

Images