Patent Description:
In some multi-tenant single-instance architecture scenarios, a flat-wide table is used as storage space for tenant data (that is, a custom object of a tenant). Therefore, the flat-wide table stores tenant data of a plurality of tenants. Certainly, referring to <FIG>, a logic table or a service table (for example, an order, an acceptance, and an inventory) instead of a flat-wide table is presented to a user.

As a key data structure in a database system, an index plays an important role in an index update in the database system. Quick access to a record in a physical database table can be implemented by using the index.

However, there is a limitation in an existing index update manner. Indexes can be created only for full table data. This cannot meet a requirement of creating an index on tenant data of a particular tenant, and consequently cannot adapt to a multi-tenant scenario.

For this reason, an index pivot table is introduced and index data in the index pivot table is defined by using metadata, to create an index for a field in a logic table corresponding to the tenant data, and further meet a requirement of creating the index on the tenant data.

However, an existing index update is performed when the system is idle and is not performed online in real time. Therefore, how to update an index online in real time has become a current research and development topic.

"Multi Tenant Architecture", Salesforce. com, URL: https://developer. salesforce. com/page/Multi_Tenant_ Architecture, discloses an index update method that automatically indexes various types of fields.

<CIT> discloses an in-memory database for multi-tenancy.

<CIT>) discloses index-updating in a multi-tenant database.

The object of the invention is solved by the features of the independent claims.

According to one aspect, an embodiment of this application provides an index update method, including: receiving, by a first data access node, an index update request, where the index update request is used to instruct to create or delete a target index that is associated with a logic table of a tenant; updating, by the first data access node, metadata information of the logic table in a database in response to the index update request, and notifying a coordination service that the metadata information of the logic table is changed, where the coordination service notifies a second data access node to perform a local synchronization update on the metadata information of the logic table; in addition, performing, by the first data access node, a local synchronization update on the metadata information of the logic table; and after all second data access nodes finish local synchronization updates, performing, by the first data access node, a data asynchronization update. It can be learned that in this embodiment, after the metadata information is updated in the database, an index is updated in two steps: In a first step, each data access node performs a local synchronization update on the metadata information of the logic table. After the local synchronization update, a subsequent data access request of each data access node for the logic table may be based on new metadata information. In a second step, after all the data access nodes finish the local synchronization updates, a data asynchronization update is performed to create or delete the target index. The index can be updated online in real time through the foregoing two-step update.

In a possible design, after receiving the index update request and before updating the metadata information, the first data access node further adds a table lock to the logic table, where the table lock is used to prohibit another request from being used to perform an update operation on the metadata information of the logic table, and the another request herein is a request related to performing the update operation on the metadata information of the logic table. However, after completing the data asynchronization update, the first data access node releases the table lock. In an actual operation, there may be another index update request that is also used to instruct to create or delete an index for a field on the same logic table, while the table lock may prevent a plurality of requests from being used to simultaneously update the metadata information of the same logic table, to avoid data update confusion.

The local synchronization update includes at least:
refreshing the metadata information of the logic table cached locally; and after all transactions in a current transaction list end, notifying the coordination service that the local synchronization update is finished. Notifying the coordination service after the transactions in the current transaction list end may ensure that a current transaction (an ongoing data operation) is not affected.

In a possible design, the "local synchronization update" may further include the following operation: setting a locally cached query plan associated with the logic table to an invalid state. This is because the query plan in this case is generated before the metadata information is updated and is set to the invalid state to prevent a new query request from using the query plan. It should be noted that, although the query plan is made invalid, the transactions in the current transaction list can still use the query plan in the invalid state while a new query request cannot use the query plan in the invalid state.

The updating metadata information of the logic table in a database includes at least: updating a metadata version number of the logic table in the database. Further, for creating the index, updating index metadata information specifically include: A: storing the index metadata information of the target index into the database, and B: setting a status of the target index to a first intermediate state. Specifically, the first intermediate state is designed as "creating". An index in the first intermediate state cannot be cited by the query plan. The reason that the status of the target index is set to the first intermediate state is as follows: The index metadata information of the target index is stored in the database in this case, but the target index is not really created successfully. In this case, if the query plan is allowed to cite the target index, a query fails. In addition, the first intermediate state has another function in another embodiment, and the function is subsequently described in this specification. For deleting the index, updating index metadata information specifically include: setting a status of the target index to a second intermediate state. Specifically, the second intermediate state is designed as "deleting". More specifically, a status (status) field value in an index metadata table is set to "deleting", indicating "deleting". An index in the second intermediate state cannot be cited by the query plan, either. The status of the target index is set to the second intermediate state to prevent the query plan from citing an index to be deleted. Whether deleting or creating an index, the first data access node updates a metadata version number of the target logic table in the database. This provides a specific manner of updating the metadata information of the logic table in the database, to better update an index online.

In a possible design, the data asynchronization update includes at least: creating the target index or deleting the target index according to the index update request. After the target index is created or the target index is deleted, the data asynchronization update further includes: updating a metadata version number in a target tenant data record. For creating the target index, the first data access node may query a tenant data record associated with the target logic table in a flat-wide table, synchronize data in the target tenant data record to the target index, and in addition, update the metadata version number in the target tenant data record. The target tenant data record includes a tenant data record whose metadata version number is not updated and that is associated with the logic table. After the target tenant data record cannot be found, the first data access node sets the status of the target index in the database to a normal state, and notifies the coordination service. The coordination service may notify the second data access node again to refresh the metadata information of the target logic table cached locally again, or refresh only the status of the target index cached locally. For deleting the target index, after the target index is deleted, the data asynchronization update further includes: deleting the index metadata information of the target index in the database, and notifying the coordination service, where the coordination service may notify the second data access node again to refresh the metadata information of the logic table cached locally again.

According to another aspect, an embodiment of this application provides a data access node, and the data access node has a function of implementing behavior of the data access node in the foregoing method design. The function may be implemented by hardware, or may be implemented by hardware by executing corresponding software.

According to still another aspect, an embodiment of this application provides an index update system, including an application node, a database node, and the foregoing data access node. The data access node has a function of implementing behavior of the data access node in the foregoing method design. The function may be implemented by hardware, or may be implemented by hardware by executing corresponding software.

According to yet another aspect, this application provides a computer-readable storage medium, and the computer-readable storage medium stores an instruction. When the instruction runs on a computer, the computer performs the method in the foregoing aspect.

According to still yet another aspect, this application provides a computer program product that includes an instruction. When the computer program product runs on a computer, the computer performs the method in the foregoing aspect.

According to a further aspect, this application provides a chip system. The chip system includes a processor, configured to support an index update apparatus in implementing functions in the foregoing aspects, for example, generating or processing data and/or information in the foregoing method. In a possible design, the chip system further includes a memory, and the memory is configured to store a program instruction and data that are necessary for the data sending device. The chip system may include a chip, or include a chip and another discrete device.

In the solutions provided in this application, after the metadata information is updated in the database, an index is updated in two steps: In a first step, each data access node performs a local synchronization update on the metadata information of the logic table. After the local synchronization update, a subsequent data access request of each data access node for the logic table may be based on new metadata information. In a second step, after all the data access nodes finish the local synchronization updates, a data asynchronization update is performed to create or delete the target index. The index can be updated online in real time through the foregoing two-step update.

For reference and clarity, technical terms, acronyms, or abbreviations used below are summarized as follows:.

A multi-tenant single-instance architecture may be applied to a plurality of scenarios. For example, a software as a service (Software As A Service, SaaS) mode. In this mode, an SaaS vendor uniformly deploys application software. A tenant subscribes to an application software service from the vendor through the Internet based on an actual requirement and pays a fee. The tenant no longer needs to build additional IT basic settings of an enterprise, to effectively reduce operation and maintenance costs. In the multi-tenant single-instance architecture, a flat-wide table is used as storage space for tenant data (that is, a custom object of the tenant). For ease of understanding of the technical solutions provided in this application, a flat-wide table model, an object metadata table, and a field metadata table are first described in this specification.

The flat-wide table model is shown in Table <NUM> below. The flat-wide table model reserves several (for example, <NUM> or <NUM>) typeless fields as storage fields for tenant data. For example, value0 to value499 in the following table are the foregoing typeless fields. In addition, the flat-wide table model further includes a field that describes basic information about the tenant data, for example, a tenant ID (tenant_id), an object type ID (obj_id), and a global unique identifier (Global Unique Identifier, GUID).

In addition, the tenant data is defined by using a set of metadata tables. Main metadata tables include an object metadata table and a field metadata table. An object metadata table model is shown in Table <NUM> below. The object metadata table is used to store basic metadata information of the tenant data, including a tenant ID, a name (obj_name), an object type ID, and the like.

A field metadata table model is shown in Table <NUM> below. The field metadata table is used to store field detail information of the tenant data, including a field ID (field_id), a name (field_name), a type (data_type), a size (data_size), a column number of a field in a flat-wide table, and the like.

It is assumed that a tenant <NUM> customizes an object ACCOUNT (logic table ACCOUNT). An example of an object metadata table of the object ACCOUNT is shown in Table <NUM> below, and an example of a field metadata table of the object ACCOUNT is shown in Table <NUM> below. It is assumed that an data object ACCOUNT of the tenant <NUM> stored in a flat-wide table is shown in Table <NUM> below.

It can be learned that customizing a data object by the tenant, for example, adding or deleting a field or changing a type, may no longer be implemented based on a DDL operation on a physical table of a physical database, but may be implemented by using a DML operation on metadata. The tenant may arbitrarily modify an object definition of the tenant without affecting another tenant.

It should be noted that, although the tenant data is stored in the flat-wide table, a user does not see the flat-wide table, but a logic table or a service table (for example, an order table, an acceptance table, and an inventory table). For example, for the data object ACCOUNT of the tenant <NUM> in the flat-wide table mentioned above. Referring to <FIG>, a user sees an account logic table.

If there is a need to query an ID, a name (name), and an address (address) in all records with a name "ABC" in the account logic table, an example of a logical SQL statement of the query operation is as follows:
SELECT ACCOUNT_ID, ACCOUNT_NAME, ADDRESS
FROM ACCOUNT
WHERE ACCOUNT_NAME = 'ABC'.

Logical SQL access of the tenant based on a custom data object may be finally converted, by using metadata description information, into physical SQL access based on a data flat-wide table. As a key data structure in a database system, an index plays an important role in query optimization in the database system. Quick access to a record in a physical database table can be implemented by using the index. As mentioned above, there is a limitation in an existing index update manner. Indexes can be created only for full table data. This cannot meet a requirement of creating an index on tenant data of a particular tenant, and consequently cannot adapt to a multi-tenant scenario.

For this reason, an index pivot table is introduced to meet the requirement of creating the index on the tenant data of the particular tenant. Structures of the index pivot table are shown in Table <NUM> and Table <NUM> below, and respectively support a non-unique index and a unique index.

String_value, num_value, and date_value fields of an index pivot table respectively store a character string, a number value, and a date type field value, and a non-unique index is created on these fields. A unique index is created on these fields of a unique index pivot table.

In addition, data in the index pivot table is further defined by using a set of metadata tables, and the metadata tables include an index metadata table (indexes) and an index field table (index_fields). A model of the indexes is shown in Table <NUM> below, and a model of the index_fields is shown in Table <NUM> below.

For example, it is assumed that the data object ACCOUNT data object of the tenant <NUM> stored in the flat-wide table is shown in Table <NUM>. In this application, if the tenant specifies to create a non-unique index for a field ACCOUNT_NAME of the object ACCOUNT, the index metadata table (indexes) is shown in Table <NUM> below, and an index pivot table is shown in Table <NUM> below.

It should be noted that the object metadata table, the field metadata table, the index metadata table, and the index field table all belong to metadata information of the logic table. For example, Table <NUM>, Table <NUM>, Table <NUM>, and Table <NUM> all belong to metadata information of the account logic table, and in addition, the metadata information of the logic table further includes a metadata version number.

Embodiments of this application provide an index update method and a related apparatus (an update apparatus, a data access node, and an index update system), to resolve a limited index creation problem, for example, in an index update manner, there is a specific limitation in aspects of a field type and an index type, so that a tenant can flexibly specify a field to create an index on the field, and in an online index creation process, an ongoing data operation is not affected.

Referring to <FIG>, the foregoing index update system may include an application node <NUM>, a data access node <NUM>, and a database node <NUM> (which stores tenant data). In an example, the index update system may be specifically an SaaS application system.

The application node <NUM> is mainly responsible for running a business service of the index update system. In a large-capacity scenario, referring to <FIG>, cluster deployment may be used. The data access node <NUM> is mainly responsible for running a database access service of the index update system and providing a standard SQL interface, and may accept a database access request of the application node <NUM>, submit a database query (query plan) to the database node <NUM>, and return a result to the application node <NUM>. In the large-capacity scenario, referring to <FIG>, the cluster deployment may be used. In addition, the data access node <NUM> may further perform an index update method provided in this application, for example, index update methods provided in embodiments shown in <FIG> and <FIG> to <FIG> and <FIG>. The database node <NUM> is mainly responsible for a data storage access service of the index update system, and may use a commercial database, for example, an Oracle database and a MySql database. In the large-capacity scenario, referring to <FIG>, the cluster deployment may be used. In a multi-tenant scenario, each piece of tenant data is stored in a specified database node, and the database node may be specified by deploying configuration information.

In a cluster scenario, the index update system may further include a load balancer <NUM>. The load balancer <NUM> is mainly responsible for accepting a request (for example, a logical SQL request) from a (tenant) client, and distributing the request to an application node in an application node cluster based on a load status of each application node <NUM>.

Coordination service: The coordination service is an open source code distributed application program coordination service, and finishes tasks such as a unified naming service, a status synchronization service, cluster management, and distributed application configuration item management. The coordination service is usually deployed on an independent coordination service node.

<FIG> shows an example of a structure of the foregoing data access node <NUM>, including the following components.

An SQL parser <NUM> is responsible for parsing an SQL query request sent by an application node <NUM>, and generating a syntax tree. The SQL query request herein may include a DDL SQL statement and a DML SQL statement. It should be noted that execution of the DML SQL statement is emphasized in this application. Therefore, unless otherwise specified, a subsequent SQL query request is the DML SQL statement.

A metadata and statistical information cache <NUM> is responsible for metadata and statistical information caching on the data access node <NUM>, metadata is loaded from a database when a database access service is started, and statistical information is collected and stored in real time by a data access service. A query analyzer <NUM> is responsible for performing query analysis based on the syntax tree and the metadata and statistical information caching, to obtain a query analysis result. A query plan generator <NUM> may be responsible for determining the target query plan mentioned above. More specifically, when an optimal query plan is not found, the query plan generator <NUM> may generate the target query plan based on the query analysis result. In addition, the query plan generator <NUM> may further determine an alternative query plan for an SQL query request, query the database for query costs of each alternative query plan when there are a plurality of alternative query plans, and cache an alternative query plan with minimum query costs as an optimal query plan for the SQL query request. A DML executor <NUM> is responsible for performing the target query plan, receiving and processing a query result returned by the database, and returning the query result to the application node <NUM>. A DDL executor <NUM> is responsible for executing the DDL SQL statement (a DDL request) sent by the application node <NUM>. A database access interface <NUM> provides an access interface for each heterogeneous database. The foregoing update apparatus may be deployed on the data access node <NUM> in a form of hardware or software.

<FIG> shows an example of a structure of the foregoing update apparatus, and the update apparatus may include a communications unit <NUM> and a processing unit <NUM>. A function of each unit is subsequently described in combination with an update method in this specification.

<FIG> shows another example of a structure of the foregoing update apparatus, including a bus, a controller/processor <NUM>, a memory <NUM>, and a communications interface <NUM>. Optionally, the foregoing update apparatus may further include an input device <NUM> and an output device <NUM>. The processor <NUM>, the memory <NUM>, the input device <NUM>, and the output device <NUM> are connected to each other by using the bus. The bus may include a channel for transferring information between parts of a computer system.

The controller/processor <NUM> may be a general-purpose processor such as a general-purpose central processing unit (CPU), a network processor (Network Processor, NP), or a microprocessor, or may be an application-specific integrated circuit (application-specific integrated circuit, ASIC) or one or more integrated circuits that are configured to control program execution of the solutions of this application, or may be a digital signal processor (Digital Signal Processor, DSP), a field-programmable gate array (Field-Programmable Gate Array, FPGA) or another programmable logic device, a discrete gate or a transistor logic device, or a discrete hardware component. Alternatively, the controller/processor <NUM> may be a combination of processors implementing a computing function, for example, a combination of one or more microprocessors or a combination of the DSP and the microprocessor.

The controller/processor <NUM> may be configured to implement a function of the foregoing processing unit <NUM>. The memory <NUM> stores programs executing the technical solutions of this application, and may also store an operating system and another application program. Specifically, the programs may include program code, and the program code includes a computer operation instruction. More specifically, the memory <NUM> may be a read-only memory (read-only memory, ROM), another type of static storage device that can store static information and instructions, a random access memory (random access memory, RAM), another type of dynamic storage device that can store information and instructions, a magnetic disk storage, or the like. The input device <NUM> may include a terminal device that receives data and information entered by a user, for example, a keyboard, a mouse, a camera, a scanner, a light pen, a voice input terminal device, and a touchscreen. The output device <NUM> may include a terminal device that is allowed to output information to the user, for example, a screen unit. The communications interface <NUM> may include a terminal device that uses any transceiver, to support the update apparatus in communicating with another device or a communications network. The communications interface <NUM> may be configured to implement a function of the foregoing communications unit <NUM>.

It may be understood that <FIG> shows merely a simplified design of the update apparatus. In actual application, the update apparatus may include any quantity of transmitters, receivers, processors, controllers, memories, communications interfaces, and the like, and all update apparatuses that can implement this application fall within the protection scope of this application.

The controller/processor <NUM> executes the programs stored in the memory <NUM>, and invokes another device. The processor <NUM> may be configured to implement an index update method provided in embodiments shown in <FIG> and <FIG> to <FIG> and <FIG>.

In another embodiment of this application, the foregoing data access node <NUM> may also use a structure similar to that in <FIG>.

<FIG> and <FIG> show an example of an interaction procedure of the foregoing index update method, including the following steps.

A user (a tenant) sends an index update request to a particular data access node <NUM> through a database access service of an application node <NUM>.

In this process, the foregoing communications unit <NUM> may receive the index update request. The index update request may be used to instruct to create or delete a target index that is associated with a field in a logic table of the tenant. The target index is an index that the index update request instructs to create, or an index that the index update request instructs to delete. A logic table indicated in the index update request may be referred to as a target logic table.

More specifically, the user may directly write the index update request, or the application node <NUM> may provide a graphical interface for the user to customize and automatically generate a related index update request, and send the index update request to a data access service on the particular data access node <NUM>, so as to trigger an index update procedure. In this manner, the tenant can independently finish an index update operation on the graphical interface provided by the application node <NUM>.

For distinguishing, a data access node that receives the index update request may be referred to as a first data access node, and another data access node may be referred to as a second data access node.

In an example, a standard DDL SQL statement may be used as the index update request.

Creating the target index is used as an example, and syntax of the DDL SQL statement is defined as follows:
CREATE [UNIQUE] INDEX INDEX_NAME ON TABLE_NAME (FIELD_NAME).

"INDEX_NAME" represents a specific index name; "TABLE_NAME" represents a specific logic table name, for example, a name of the foregoing account logic table; and FIELD_NAME represents a specific field in a logic table.

The user may specify a logic table name and a field in the index update request, and update a target index associated with the specified field. In this way, a logic table and a field may be flexibly specified, and an index is created or updated on the specified field.

A first data access node adds a table lock to a target logic table.

The table lock may be used to prohibit another request from being used to perform an update operation on metadata information of a logic table. The another request herein is a request related to performing the update operation on the metadata information of the logic table. For example, in an actual operation, there may be another index update request that is also used to instruct to create or delete an index for a field on the same logic table, while the table lock may prevent a plurality of requests from being used to simultaneously update the metadata information of the same logic table, to avoid data update confusion. In an example, the table lock may be specifically a DDL lock, and the first data access node may obtain the DDL lock from a coordination service deployed on a coordination service node, to prevent different DDLs from being used to concurrently operate the metadata information of the same logic table.

In an example, step <NUM> may be performed by a processing unit <NUM> of the first data access node.

The first data access node updates metadata information of the target logic table in a database.

Step <NUM> may be performed by the processing unit <NUM> of the first data access node. The processing unit <NUM> may instruct the communications unit <NUM> to submit the update request to the database, to update the metadata information of the target logic table.

The metadata information of the logic table is stored in the database, and the metadata information of the logic table is also locally cached in each data access node. In this step, an update of the metadata information of the logic table in the database is performed. In a subsequent step, each data access node also updates the metadata information of the target logic table cached locally.

Actually, this step is mainly used to update index metadata information of the target index, and the index metadata information of the target index belongs to a part of the metadata information of the target logic table. Therefore, updating the index metadata information also belongs to updating the metadata information of the target logic table.

More specifically, as mentioned above, the index update request may instruct to create or delete the target index.

For creating the index, updating the index metadata information may specifically include the following:.

For example, it is assumed that an data object ACCOUNT of a tenant <NUM> stored in a flat-wide table is shown in Table <NUM>. The index update request of the user is used to instruct to create a non-unique index on an ACCOUNT_NAME field (value0 field) of an object ACCOUNT. In this step, an index metadata table (indexes) of the target index in the database is shown in Table <NUM> below. "creating" of a status (status) field indicates "creating".

The reason that the status of the target index is set to the first intermediate state is as follows: The index metadata information of the target index is stored in the database in this case, but the target index is not really created successfully. In this case, if the query plan is allowed to cite the target index, a query fails. In addition, the first intermediate state has another function in another embodiment, and the function is subsequently described in this specification.

For deleting the index, updating the index metadata information may specifically include: setting a status of the target index to a second intermediate state. Specifically, the second intermediate state may be designed as "deleting". More specifically, a status (status) field value in an index metadata table may be set to "deleting", indicating "deleting". An index in the second intermediate state cannot be cited by a query plan, either. The status of the target index is set to the second intermediate state to prevent the query plan from citing an index to be deleted.

C: Whether deleting or creating an index, the first data access node updates a metadata version number of the target logic table in the database. For example, the metadata version number of the target logic table may be updated from previous V1 to V2.

The first data access node notifies a coordination service that the metadata information of the target logic table is changed.

More specifically, the coordination service may be notified that the metadata version number of the target logic table is changed. Step <NUM> may be performed by the communications unit <NUM> under an instruction of the processing unit <NUM> of the first data access node.

The coordination service notifies a second data access node to perform a local synchronization update on the metadata information of the target logic table.

More specifically, a data access service deployed on each second data access node listens to a metadata change notification of the coordination service. When the metadata change notification is obtained through listening, the local synchronization update is performed. There are a plurality of listening mechanisms, and the listening mechanisms are provided by the coordination service and not discussed in detail in this solution.

(A data access service on) the second data access node performs the local synchronization update on the metadata information of the target logic table.

In an example, the "local synchronization update" may include at least the following steps.

Notifying the coordination service after the transactions in the current transaction list end may ensure that a current transaction (an ongoing data operation) is not affected and improve use experience of the user. In an example, after all the transactions in the current transaction list end, the second data access node may notify the coordination service that the local synchronization update is finished. The coordination service may set a metadata synchronization update status of the second data access node to a finish state according to a notification of the second data access node. More specifically, the coordination service may maintain an update status list, set, to <NUM>, a status value of a second data access node that has finished a metadata synchronization update in the list, and set, to <NUM>, a status value of a second data access node that has not notified the coordination service.

It should be noted that the transaction uses the query plan, and the query plan is generated based on the metadata information of the logic table. If a query plan is generated based on metadata information of a particular logic table, it may be considered that the query plan is associated with the logic table. For example, in response to a query request, a particular data access node needs to query a logic table A, a query plan is generated based on metadata information of the logic table A (in other words, a query plan associated with the logic table A is generated).

In addition, after a query ends, the data access node locally caches the generated query plan, so that the data access node can directly use the query plan when receiving the same query request, to improve query efficiency.

Therefore, generally, each data access node locally caches a plurality of query plans, and it may be considered that the data access node maintains a query plan pool. It is assumed that before the metadata information of the target logic table is updated, the metadata version number of the target logic table is V1, and an updated metadata version number is V2.

Apparently, before the foregoing operation A is performed, a query plan that is associated with the target logic table and that is cached by each data access node is generated based on old metadata information of the target logic table (the query plan generated based on the old metadata information may be referred to as an old query plan). Alternatively, the old query plan is generated based on metadata information of a V1 version. A query plan that is associated with the target logic table and that is used by an ongoing transaction in the current transaction list is also based on the V1 version.

Because an index is updated online, each data access node may receive a new query request. To prevent a new SQL query request from using the old query plan, in an example, the foregoing "local synchronization update" may further include the following operation: setting a locally cached query plan (usually an SQL execution plan) associated with the target logic table to an invalid state.

In other words, the old query plan is made invalid. It should be noted that, although the old query plan is made invalid, the transactions in the current transaction list can still use the old query plan while the new query request cannot use the old query plan.

In addition, the data access node may generate a query plan based on new version metadata information (the query plan generated based on the new version metadata information may be referred to as a new query plan for short). The new SQL query request may use the new query plan.

In addition, it should be noted that the query plan is finally converted into an operation on a tenant data record in the flat-wide table.

Referring to Table <NUM>, a metadata version number of a corresponding logic table is stored in each tenant data record. After an operation, the metadata version number in the tenant data record is updated to a metadata version number on which the query plan is based.

Table <NUM> is used as an example. It is assumed that data in a first tenant data record is changed by the old query plan, and a version field value of the first tenant data record is still V1. However, data in a third and fourth tenant data records is changed by the new query plan, and version field values of the third and fourth tenant data records are updated to V2. Updated tenant data records are shown in Table <NUM> below.

For newly creating the target index, because there is no related information about the target index in an old version at all, tenant data changed by the old query plan cannot be synchronized to an index pivot table, and synchronization may be finished in subsequent data asynchronization. However, tenant data changed by the new query plan can be synchronized to the index pivot table.

Step <NUM> may be performed by a processing unit <NUM> of the second data access node, and the processing unit <NUM> of the second data access node may instruct a communications unit <NUM> of the second data access node to notify the coordination service.

The first data access node performs a local synchronization update on the metadata information of the target logic table.

Similar to the second data access node, the first data access node also needs to perform the local synchronization update. Therefore, the first data access node also performs operations such as refreshing the metadata information of the target logic table cached locally, waiting for all the transactions in the current transaction list to end, and setting the locally cached query plan associated with the target logic table to the invalid state. After all the transactions in the current transaction list end, whether to notify the coordination service may be flexibly designed. The first data access node may be designed to notify the coordination service after completing the local synchronization update, or may be designed not to notify the coordination service.

Step <NUM> may be performed by the processing unit <NUM> of the first data access node, and the processing unit <NUM> of the first data access node may instruct the communications unit <NUM> of the first data access node to notify the coordination service.

After all second data access nodes finish local synchronization updates, the first data access node performs a data asynchronization update.

In an example, the first data access node may keep querying the coordination service for the metadata synchronization update status of the second data access node until metadata synchronization update statuses of all the second data access nodes are finish states, and then perform the data asynchronization update. Certainly, in another embodiment, one of the second data access nodes may alternatively perform a data asynchronization update. The data asynchronization update includes at least: creating the target index according to the index update request, or deleting the target index according to the index update request. How to perform the data asynchronization update for two cases of creation and deletion is subsequently described in detail in this specification. The first data access node may start an asynchronization task to perform the asynchronization update.

After finishing the asynchronization update, the first data access node releases the table lock. After the asynchronization update is finished, index creation or deletion is finished. Therefore, the table lock may be released.

In another instance of the present invention, after finishing the asynchronization update, the first data access node may return an update result to a corresponding application node. More specifically, the update result may include information indicating whether the update is success or fail. Certainly, if the update fails, the update result may further include a failure cause.

Steps <NUM> and <NUM> may be performed by the communications unit <NUM> under an instruction of the processing unit <NUM> of the first data access node.

It can be learned that in the solution provided in this application, after the metadata information is updated in the database, an index is updated in two steps: In a first step, each data access node performs a local synchronization update on the metadata information of the logic table, and in the local synchronization update, waits for the transactions in the current transaction list to end. In this way, execution of a current transaction may not be affected. After the local synchronization update, a subsequent data access request of each data access node for the logic table may be based on new metadata information. In a second step, after all the data access nodes finish the local synchronization updates, a data asynchronization update is performed to create or delete the target index. The index can be updated online in real time through the foregoing two-step update, and in addition, it can be further ensured that an ongoing data operation of the current transaction is not affected, to improve use experience of the user.

Steps of creating an index and deleting an index are described below with more detailed examples.

<FIG> and <FIG> show an example of an interaction procedure of the foregoing index update method when a target index is created.

S401 and S402 are the same as S301 and S302, and details are not described herein again.

The first data access node stores index metadata information of a target index into a database, and a status of the target index is set to "creating" (a first intermediate state). For a related description, refer to the foregoing part S303.

The first data access node updates a metadata version number of a target logic table in the database. For example, the metadata version number of the target logic table may be updated from previous V1 to V2.

S405 to S408 are the same as S304 to S307, and details are not described herein again.

The first data access node queries a tenant data record associated with the target logic table in a flat-wide table, synchronizes data in a target tenant data record to the target index, and in addition, updates a metadata version number in the target tenant data record.

A data asynchronization update is started from S409. The first data access node may start an asynchronization task to perform the data asynchronization update.

In the asynchronization task, a specific index on which an asynchronization update needs to be performed may be determined based on the status. Because the status of the target index is currently "creating", it may be determined, in the asynchronization task based on the status of the target index, that an asynchronization update needs to be performed on the target index. Certainly, in another example, a table may be alternatively created, to record to-be-created and to-be-deleted indexes.

The target tenant data record includes a tenant data record whose metadata version number is not updated and that is associated with the logic table. For example, it is assumed that the metadata version number of the target logic table is updated from previous V1 to V2. Referring to Table <NUM>, if the metadata version number of the tenant data record is V2, it indicates that the record has been updated to an index pivot table, and in the asynchronization task, no operation is performed on the record. If the metadata version number of the tenant data record is not V2, it indicates that the tenant data record is not updated to the index pivot table. To be specific, in Table <NUM>, metadata version numbers of two tenant data records in a shadow part are V1, and the two tenant data records are target tenant data records.

In the asynchronization task of the first data access node, field values related to the target index in the two tenant data records in the shadow of Table <NUM> are updated to the index pivot table. It is assumed that a field associated with the target index is "value0" in Table <NUM>, and ACCID_1 and ACCID_2 in Table <NUM> are updated to the index pivot table. An updated index pivot table is shown in Table <NUM> below. In addition, in the asynchronization task, the metadata version numbers of the two tenant data records are further changed, to identify that the two tenant data records have been updated by using new metadata, and changed tenant data records are shown in Table <NUM> below.

In an example, to prevent the asynchronization task and a normal DML from being used to simultaneously operate a particular tenant data record, in the asynchronization task, SELECT FOR UPDATE may be used to add a row lock to the tenant data record. SELECT FOR UPDATE is a standard DML statement that is used to add the row lock to the record.

The first data access node sets the status of the target index in the database to a normal state, and notifies a coordination service.

When a related tenant data record whose version number is less than V2 cannot be found in the asynchronization task, it indicates that all tenant data records related to the target logic table have been updated by using new version metadata information, and the asynchronization task of index creation is finished. An index metadata table of the target index shown in Table <NUM> is used as an example. After the status is changed, an index metadata table of the target index is shown in Table <NUM> below. "Normal" of a status (status) field indicates "normal".

When the coordination service is notified, the coordination service may be notified that the status of the target index is updated, or the coordination service may be notified that metadata information of the target logic table is updated. The coordination service may instruct a second data access node again to refresh the metadata information of the target logic table cached locally again, or refresh only the status of the target index cached locally. In this refreshing, step B and step C in a local synchronization update may not be performed. In another embodiment of this application, a quantity of index records that are updated or deleted each time may be limited. For example, a maximum quantity of index records that are updated or deleted each time may be limited to <NUM>. In each operation in the asynchronization task, <NUM>,<NUM> index records can be updated. If an upper limit of <NUM>,<NUM> is reached, a same operation is performed again. This considers that a log needs to be generated during each update. If there are a large quantity of records for updating data, a quantity of logs is also large, affecting performance. Likewise, a maximum quantity of tenant data records that are updated each time in the flat-wide table may also be limited, and details are not described herein.

After completing an asynchronization update, the first data access node releases the table lock.

S411 is the same as S309, and details are not described herein again.

S411 and S410 may be simultaneously performed, or may be successively performed.

Steps <NUM> to <NUM> may be performed by a communications unit <NUM> under an instruction of a processing unit <NUM> of the first data access node.

<FIG> and <FIG> show an example of an interaction procedure of the foregoing index update method when a target index is deleted.

S501 and S502 are the same as S401 and S402 or S301 and S302, and details are not described herein again.

The first data access node sets a status of a target index in a database to "deleting" (a second intermediate state). For a related description, refer to the foregoing part S303.

The first data access node updates a metadata version number of a target logic table in the database. For example, the metadata version number of the target logic table may be updated from previous V1 to V2.

S505 to S508 are the same as S405 to S408 or S304 to S307, and details are not described herein again.

The first data access node queries a tenant data record associated with the target logic table in a flat-wide table, and updates a metadata version number in a target tenant data record.

For example, it is assumed that the metadata version number of the target logic table is updated from previous V1 to V2. Referring to Table <NUM>, metadata version numbers of all tenant data records associated with the target logic table may be updated to V2. Because in this embodiment, the target index needs to be deleted, data in the target logic table does not need to be synchronized to the target index.

A data asynchronization update is started from S509. The first data access node may start an asynchronization task to perform the data asynchronization update.

In the asynchronization task, a specific index on which an asynchronization update needs to be performed may be determined based on the status. Because the status of the target index is currently "deleting", it may be determined, in the asynchronization task based on the status of the target index, that an asynchronization update needs to be performed on the target index. In an example, to prevent the asynchronization task and a normal DML from being used to simultaneously operate a particular tenant data record, in the asynchronization task, SELECT FOR UPDATE may be used to add a row lock to the tenant data record. SELECT FOR UPDATE is a standard DML statement that is used to add the row lock to the record.

The first data access node deletes a tenant data record related to the target index in a pivot table.

It is assumed that the pivot table is shown in Table <NUM> below, and a "num_value" field is associated with the target index. When the target index is deleted, tenant data in the "num_value" field is deleted. After deletion, a pivot table is shown in Table <NUM> below.

After there is no tenant data associated with the target index in an index pivot table to be deleted, an asynchronization task of index deletion is finished.

The first data access node deletes index metadata information of the target index in the database, and notifies a coordination service that metadata information of the target logic table is updated.

The coordination service may instruct a second data access node to refresh the metadata information of the target logic table cached locally again. In this refreshing, step B and step C in a local synchronization update may not be performed.

After completing an asynchronization update, the first data access node releases the table lock.

S511 and S512 may be simultaneously performed, or may be successively performed.

Steps <NUM> to <NUM> may be perfomed by a communications unit <NUM> under an instruction of a processing unit <NUM> of the first data access node.

In another embodiment of this application, a status query interface for a data asynchronization update may be further provided, and a user may query index update progress. In addition, a query display interface for displaying selectivity of a field of a logic table may be further provided. Before creating an index, a tenant can query a field of the logic table through the query display interface, to display a quantity of different values of the field. If there are many different values of the field, it indicates that selectivity is good. If there are few different values, selectivity is poor. The user can make reference to this, to more effectively assist the tenant in completing index creation.

Method or algorithm steps described in combination with the content disclosed in this application may be implemented by hardware, or may be implemented by a processor by executing a software instruction. The software instruction may include a corresponding software module. The software module may be located in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable hard disk, a CD-ROM, or a storage medium of any other form known in the art. For example, a storage medium is coupled to a processor, so that the processor can read information from the storage medium or write information into the storage medium. Certainly, the storage medium may be a component of the processor. The processor and the storage medium may be located in an ASIC. In addition, the ASIC may be located in user equipment. Certainly, the processor and the storage medium may exist in the user equipment as discrete components.

A person skilled in the art should be aware that in the foregoing one or more examples, functions described in this application may be implemented by hardware, software, firmware, or any combination thereof. When the present invention is implemented by software, the functions may be stored in a computer-readable medium or transmitted as one or more instructions or code in the computer-readable medium. The computer-readable medium includes a computer storage medium and a communications medium, where the communications medium includes any medium that enables a computer program to be transmitted from one place to another. The storage medium may be any available medium accessible to a general-purpose or dedicated computer.

Claim 1:
An index update method, applied to a first data access node, and comprising:
receiving (<NUM>, <NUM>, <NUM>) an index update request, wherein the index update request is used to instruct to create or delete a target index that is associated with a field in a logic table of a tenant;
updating (<NUM>, <NUM>, <NUM>) metadata information of the logic table in a database in response to the index update request;
notifying (<NUM>, <NUM>, <NUM>) a coordination service that the metadata information of the logic table is changed, wherein the coordination service is used to notify (<NUM>, <NUM>, <NUM>) a second data access node to perform (<NUM>, <NUM>, <NUM>) a local synchronization update on the metadata information of the logic table in the second data access node;
performing (<NUM>, <NUM>, <NUM>) a local synchronization update on the metadata information of the logic table in the first data access node; and
after all second data access nodes finish local synchronization updates, asynchronously performing (<NUM>) a data update;
wherein the updating metadata information of the logic table in a database comprises: updating (<NUM>, <NUM>) a metadata version number of the logic table in the database;
wherein
if the index update request is used to instruct to create the target index, the updating metadata information of the logic table in a database further comprises:
storing index metadata information of the target index into the database, wherein a status of the target index in the index metadata information is a first intermediate state; and
if the index update request is used to instruct to delete the target index, the updating metadata information of the logic table in a database further comprises:
setting a status of the target index in the database to a second intermediate state, wherein
an index whose status is the first intermediate state or the second intermediate state is not available for the query plan.