A table building method, device, electronic equipment and storage medium

Abstract

The present specification provides a table building method and device, electronic equipment and storage medium, the method comprises: receiving a virtual table creation request initiated by an application for an application table maintained by itself, the virtual table creation request is used to indicate that a virtual table corresponding to the application table is created in a first physical table; create the virtual table in the first physical table partition maintained by any storage node, and record the metadata of the virtual table in the physical table partition maintained by the any storage node, the virtual table is used to record the data corresponding to the application table.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and more particularly to a method, apparatus, electronic device, and storage medium for creating tables. Background Technology

[0002] With the rise of Web 2.0, NoSQL databases (Not Only SQL, non-relational databases) have been widely used for storing massive amounts of data on servers due to their scalability, large data volume, and high performance. Currently, NoSQL database design schemes require configuring nodes to assume the roles of Master and Worker. The main tasks of the Master node are to partition and schedule database tables onto the corresponding worker nodes, and to record all metadata for the database tables. In other words, for each new database table added, its corresponding metadata needs to be recorded on the Master node.

[0003] However, since the Master node is a single node, there is an upper limit to the amount of metadata it can store for all tables. Therefore, there is also an upper limit to the number of database tables. When the number of database tables exceeds a certain scale, a system bottleneck will inevitably be encountered, and the application's demand for the number of tables will not be met. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide a method, apparatus, electronic device, and storage medium for creating tables.

[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0006] According to a first aspect of one or more embodiments of this specification, a method for creating a table is provided, the method comprising:

[0007] Receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table within the first physical table.

[0008] The virtual table is created within the first physical table partition maintained by any storage node, and the metadata of the virtual table is recorded in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

[0009] According to a second aspect of one or more embodiments of this specification, an apparatus for creating a table is provided, the apparatus comprising:

[0010] The receiving unit is used to receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table in the first physical table.

[0011] A creation unit is used to create the virtual table within a first physical table partition maintained by any storage node, and to record the metadata of the virtual table in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

[0012] According to a third aspect of one or more embodiments of this specification, a distributed database system is proposed, the system including a scheduling node and a storage node, the storage node being used to perform the steps of the method described in the first aspect.

[0013] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0014] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method described in the first aspect.

[0015] In the technical solution provided in this specification, when an application needs to create a table in the database for an application table it maintains, any storage node can create a virtual table within the partition of the first physical table it maintains. The virtual table records the data corresponding to the application table, and the first physical table can record the data corresponding to multiple application tables. Thus, the database no longer needs to create an independent physical table for each application table, thereby expanding the number of database tables, getting rid of the limitation on the number of database tables, and meeting the application's needs for the number of tables.

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

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

[0018] Figure 1 This is a system architecture diagram of a distributed database system provided in an exemplary embodiment of this specification;

[0019] Figure 2 This is a flowchart illustrating a method for creating a table, as provided in an exemplary embodiment of this specification.

[0020] Figure 3 This is a schematic diagram of data storage for a scheduling node and a storage node provided in an exemplary embodiment of this specification;

[0021] Figure 4 This is a schematic diagram illustrating the creation of index data provided in an exemplary embodiment of this specification;

[0022] Figure 5 This is an interactive flowchart of an exemplary embodiment of the present specification for creating a virtual table;

[0023] Figure 6 This is an exemplary embodiment of the flowchart illustrating the interaction between reading and writing a virtual table.

[0024] Figure 7 This is an interactive flowchart of deleting or modifying a virtual table provided in an exemplary embodiment of this specification;

[0025] Figure 8 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment of this specification;

[0026] Figure 9 This is a block diagram of an apparatus for creating a table, provided in an exemplary embodiment of this specification. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification.

[0028] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0029] As mentioned earlier, with the rise of Web 2.0, NoSQL databases (Not Only SQL, non-relational databases) are widely used for storing massive amounts of data on servers due to their scalability, large data volume, and high performance. Currently, NoSQL database designs require configuring nodes to assume the roles of Master and Worker. The main task of the Master node is to execute the scheduling of database table partitions and record the metadata of each database table; therefore, the Master node can also be called a scheduling node. The main task of the Worker node is to receive database table partitions scheduled by the Master node and process read and write requests for the corresponding database tables from the application; therefore, the Worker node can also be called a partitioning node. In a NoSQL database, the Master node is a single node, while the number of worker nodes can be determined according to needs, such as dozens or thousands. In other words, the number of worker nodes can be expanded infinitely according to needs, as there is no limit to the number of worker nodes. Therefore, there is also no limit to the amount of data in the database tables; a single database table can record a massive amount of data. The Master node can be used to store the metadata of all tables in the database, which also records the partition range corresponding to that database table. In other words, for every new database table added to the database, the corresponding metadata for that database table needs to be stored on the Master node.

[0030] However, while there is no limit to the amount of data in any single database table, the Master node, being a single node, has an upper limit to the amount of metadata it can store for the database tables. Therefore, there is also an upper limit to the number of database tables. When the number of database tables exceeds a certain threshold, a system bottleneck inevitably occurs, making it impossible to meet the application's requirements for the number of tables.

[0031] Therefore, to solve this problem, this specification proposes a table creation method that takes advantage of the fact that there is no limit to the amount of data in a database table. When an application needs to create a table in the database for its own maintained application tables, any storage node can create a virtual table within the partition of the first physical table it maintains. The virtual table records the data corresponding to the application table, and the first physical table can record the data corresponding to multiple application tables. Thus, the database no longer needs to create an independent physical table for each application table, thereby expanding the number of database tables, getting rid of the limitation on the number of database tables, and meeting the application's needs for the number of tables.

[0032] Figure 1 This is a system architecture diagram of a distributed database system provided in an exemplary embodiment of this specification, such as... Figure 1As shown, the system architecture may include a scheduling node 101 and multiple storage nodes (such as storage node 102, storage node 103, and storage node 104).

[0033] The scheduling node 101 can be deployed on a physical server containing an independent host, or it can be deployed on a virtual server (such as a cloud server) hosted in a host cluster; this specification does not impose any restrictions on this. The scheduling node 101 is used to perform the scheduling of physical table partitions, enabling any storage node to maintain its corresponding physical table partition. Simultaneously, the scheduling node 101 can record the metadata corresponding to the physical table partitions maintained by each storage node and the access addresses of each storage node. Therefore, the scheduling node 101 can determine the corresponding storage node from multiple storage nodes based on the identification information contained in the virtual table creation request and the metadata recorded by the scheduling node 101.

[0034] Storage nodes (such as) Figure 1 The storage node 102, storage node 103, or storage node 104 in the illustrated embodiments can be deployed on a physical server containing an independent host, or the aforementioned storage nodes can be deployed on a virtual server (such as a cloud server) hosted by a host cluster; this specification does not impose any limitations on this. It should be noted that, although in Figure 1 In the illustrated embodiment, storage node 102 is deployed on a physical server of a standalone host. However, in some embodiments, the physical server of the standalone host may deploy multiple storage nodes, such as storage node 102 and storage node 103. This specification does not impose any limitations on this. Each storage node maintains a physical table partition scheduled by scheduling node 101. Based on a virtual table creation request initiated by the application, the storage node can create a virtual table within the first physical table partition maintained by the corresponding storage node and record the metadata of the virtual table in the physical table partition maintained by the storage node. This achieves the creation of a virtual table, which is used to record data corresponding to the application table. Therefore, it can be seen that the physical table described in this specification no longer records only the data of a single application table, but can record the data of multiple application tables in the form of virtual tables within the physical table. Since the amount of data stored in the physical table can be expanded indefinitely by increasing the number of storage nodes, the number of virtual tables can be considered unlimited. In other words, the database no longer needs to create a separate database table for each application table on a storage node, but instead uses virtual tables to record the application table data, thus expanding the number of database tables and overcoming the limitation on the number of database tables, meeting the application's requirements for the number of tables. It should be noted that although in Figure 1In the illustrated embodiment, the distributed database system may include multiple storage nodes, and the table creation method described in this specification is configured on these storage nodes, thereby enabling the distributed database to achieve unlimited expansion of the number of tables. However, in some embodiments, such as NoSQL databases, the table creation method described in this specification can be configured directly on the partition nodes of the NoSQL database, so that physical tables can be maintained and corresponding virtual tables can be created on the partition nodes, thereby enabling the NoSQL database to achieve unlimited expansion of database tables and meet the application's requirements for the number of NoSQL database tables.

[0035] Based on the system architecture of the database table creation system described above, when an application needs to create a table in the database for an application table it maintains, any storage node can create a virtual table within the partition of the first physical table it maintains. The virtual table records the data corresponding to the application table, and the first physical table can record the data corresponding to multiple application tables. Thus, the database no longer needs to create an independent physical table for each application table, thereby expanding the number of database tables, getting rid of the limitation on the number of database tables, and meeting the application's needs for the number of tables.

[0036] For ease of description, the following is in conjunction with the appendix. Figure 2 To be continued Figure 7 This specification provides a detailed description of a table creation method.

[0037] Figure 2 This is a flowchart illustrating a table creation method provided in an exemplary embodiment of this specification. For example... Figure 2 As shown, the method may include the following steps:

[0038] Step 202: Receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table within the first physical table.

[0039] The physical table described in this specification can be considered a database table. However, unlike the independent physical table created by the application based on the application table, the physical table described in this specification no longer records only the data of one application table. Instead, it records multiple application tables in the form of multiple corresponding virtual tables. In other words, one physical table can record the data corresponding to multiple application tables, thereby achieving unlimited expansion of the number of forms.

[0040] As mentioned earlier, the number of storage nodes can be expanded according to actual needs, ranging from dozens to thousands. Therefore, there is no limit to the amount of data in the physical tables, and consequently, no limit to the number of virtual tables. Based on this, a single physical table is sufficient to achieve the expansion of the database table number described in this specification. Since only one physical table is needed, the virtual table creation request does not require the corresponding physical table parameter identifier, such as the physical table ID. If the application requires multiple physical tables and needs to create corresponding virtual tables on different physical tables, then the virtual table creation request can include the corresponding physical table parameter identifier, such as the physical table ID. This allows the virtual table creation request to instruct the creation of a virtual table corresponding to the application table within that physical table. For example, if a storage node maintains a first physical table partition (ID 1) and a second physical table partition (ID 2), the virtual table creation request can include the corresponding physical table ID. If ID 1, then the virtual table creation request can instruct the creation of a virtual table corresponding to the application table within the first physical table partition (ID 1). It should be noted that the parameter identifiers of the physical tables mentioned above can also be divided according to function, and are not necessarily the IDs of the physical tables. For example, they can be divided into approval physical tables, voting physical tables, etc., based on specific functions, and the corresponding physical tables can be determined according to the function identifiers. This specification does not impose any restrictions on this. The number of physical tables described in this specification can be adapted to meet the actual needs of the application, thereby improving the flexibility of the database tables. In one embodiment, the database may include multiple storage nodes, and each storage node maintains a physical table partition with a corresponding virtual table partition range; wherein: the virtual table creation request contains the identifier information of the virtual table to be created, and if the value of the identifier information is determined to belong to the virtual table partition range corresponding to the physical table partition maintained by any of the storage nodes, the virtual table creation request is sent to any of the storage nodes. Figure 1 Taking the illustrated embodiment as an example, there are three storage nodes: storage node 102, storage node 103, and storage node 104. The range of the virtual table partition corresponding to the physical table partition maintained by storage node 102 can be [1, 200], the range of the virtual table partition corresponding to the physical table partition maintained by storage node 103 can be (200, 400], and the range of the virtual table partition corresponding to the physical table partition maintained by storage node 104 can be (400, 600]. In this case, the virtual table creation request can include the identification information of the virtual table to be created. The value of the identification information can be 40. Therefore, it can be determined that the value of the identification information 40 belongs to storage node 102, and the corresponding virtual table creation request can be sent to storage node 102.

[0041] In one embodiment, the database may include a scheduling node. The scheduling node records metadata corresponding to physical table partitions maintained by each storage node and the access address of each storage node. The metadata recorded by the scheduling node includes the range of virtual table partitions corresponding to the physical table partitions. The scheduling node is further configured to: compare the identification information included in the virtual table creation request with its own recorded metadata; and if it determines that the value of the virtual table identification information belongs to the range of virtual table partitions corresponding to the physical table partitions maintained by any of the storage nodes, determine the access address of any of the storage nodes as the sending address of the virtual table creation request. Figure 1 Taking the illustrated embodiment as an example, the database includes a scheduling node 101 and storage nodes 102, 103, and 104. The scheduling node 101 records the metadata corresponding to the physical table partitions maintained by the three storage nodes and the access addresses of each storage node. For example, the access address of storage node 102 is A, the access address of storage node 103 is B, and the access address of storage node 104 is C. When the value of the identifier information included in the virtual table creation request is 40, the scheduling node 101 can determine the access address A of storage node 102 as the sending address of the virtual table creation request, thereby enabling storage node 102 to create the corresponding virtual table. Moreover, the scheduling node only needs to record the metadata of the physical table. As mentioned above, one physical table can meet the needs of the application, so the amount of data recorded by the scheduling node is also greatly reduced.

[0042] To reduce the number of accesses to the scheduling node, the database can also include proxy nodes. These proxy nodes cache the metadata corresponding to the physical table partitions maintained by each storage node and the access addresses of each storage node. The cached metadata includes the range of virtual table partitions corresponding to the physical table partitions. The proxy node is further configured to: compare the identification information included in the virtual table creation request with its own recorded metadata; and if the value of the virtual table identification information belongs to the range of virtual table partitions corresponding to the physical table partitions maintained by any of the aforementioned storage nodes, determine the access address of that storage node as the sending address of the virtual table creation request. Through the caching function of the proxy node, access to the scheduling node can be skipped, allowing the sending address of the virtual table creation request to be determined directly based on the cached data. This effectively reduces the workload of the scheduling node. Furthermore, because the cache granularity has a faster data interaction speed, it can accelerate the determination of the sending address, indirectly improving the creation speed of virtual tables.

[0043] Step 204: Create the virtual table in the first physical table partition maintained by any storage node, and record the metadata of the virtual table in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

[0044] Metadata, also known as intermediary data, is essentially data about data. Metadata is mainly used to describe the attributes of data. Metadata for virtual tables can be used to describe the basic attributes of the virtual table, such as the definition of the primary key column and the primary key type (such as int).

[0045] A virtual table creation request can include the virtual table's identification information. The storage node can then sequentially create the virtual table within the first physical table partition based on the value relationship between the virtual table's identification information and the identification information of other virtual tables. This ensures that the arrangement order of the virtual table matches the value relationship with other virtual tables. For example, if the virtual table's identification information has a value of 50 (i.e., the virtual table ID is 50), and the physical table partition maintained by the storage node contains other virtual tables, virtual table A and virtual table B, with corresponding identification information values ​​of 2 and 60 respectively, then the virtual table (i.e., table ID 50) can be created between virtual table A and virtual table B. The final arrangement order will be 2, 50, and 60, achieving a matching of the virtual table's arrangement order with other virtual tables based on the value relationship, i.e., an ordered arrangement of virtual tables.

[0046] In one embodiment, the metadata of the aforementioned virtual table can be recorded in the virtual table corresponding to that metadata within the first physical table partition; such as... Figure 3 As shown, Figure 3 This is a schematic diagram of data storage for a scheduling node and a storage node provided in an exemplary embodiment of this specification. As shown in the figure, storage node 102 maintains a first physical table partition 301, the virtual table partition corresponding to the first physical table partition 301 has a range of [1, 5], storage node 103 maintains a first physical table partition 303, the virtual table partition corresponding to the first physical table partition 303 has a range of (5, 10], and storage node 104 maintains a first physical table partition 304, the virtual table partition corresponding to the first physical table partition 304 has a range of (10, 20]. At this time, the metadata of virtual table 1 can be recorded in the virtual table 302 corresponding to the first physical table partition 301. By recording the metadata of the virtual table in the virtual table corresponding to the metadata, when the metadata is needed, such as when performing read and write operations, it is not necessary to look up the metadata according to the mapping relationship, but the metadata can be directly obtained, which speeds up the acquisition of metadata. Of course, in addition to such Figure 3In the illustrated embodiment, the metadata of the virtual table is recorded in the virtual table corresponding to the metadata within the first physical table partition. Alternatively, the metadata of the virtual table can be recorded in another storage space within the first physical table partition that is distinct from the virtual table; or, the metadata of the virtual table can be recorded in the second physical table partition maintained by the storage node. Through diverse metadata recording methods, the recording location of the virtual table metadata can be determined according to actual needs, enriching the diversity of metadata recording locations and meeting different requirements.

[0047] In one embodiment, index data corresponding to the virtual table can also be created and recorded in the physical table partition maintained by the storage node. For example... Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the creation of index data according to an exemplary embodiment of this specification. Storage node 102 can create and record index data corresponding to the virtual table corresponding to the first physical table partition 301, thereby enabling quick retrieval of data corresponding to the application table recorded within the virtual table and accelerating data retrieval. Of course, the index data can also be recorded in other storage spaces within the first physical table partition, distinct from the virtual table, as described above; or, the index data can be recorded in a second physical table partition maintained by the storage node. This specification does not impose any limitations on this.

[0048] After the virtual table is created, corresponding read and write operations can be performed. Specifically, in response to received read / write requests for the virtual table, data read and write operations can be performed on the virtual table; and / or, in response to received delete or modify requests for the virtual table, the metadata corresponding to the virtual table can be retrieved from the physical table partitions maintained by the storage node, and the virtual table can be deleted or modified based on the retrieved metadata. For example, suppose a field in the virtual table needs to be modified, and the metadata shows that the field type is int, but the data type in the application's modification request is string. In this case, the modification will ultimately fail. In other words, when the application modifies the virtual table, it needs to comply with the requirements of the corresponding metadata for that virtual table.

[0049] To better understand the table creation method described in this manual, the following section refers to the appendix. Figure 5 Appendix Figure 6 and attached Figure 7 Using a NoSQL database as an example, this manual provides a detailed description of the table creation method.

[0050] like Figure 5 As shown, Figure 5This specification provides an exemplary embodiment of an interactive flowchart for creating a virtual table. The proxy node can send a physical table creation request to the scheduling node. Upon receiving the request, the scheduling node creates the physical table (e.g., a first physical table) and records the metadata of its partitions. The scheduling node then schedules the first physical table partitions to their corresponding partition nodes. For example, it schedules partition A to partition node A, partition B to partition node B, and partition C to partition node C. The scheduling node then returns the physical table creation result to the application, indicating successful creation. However, due to factors such as network fluctuations, the scheduling node may be unable to complete the physical table creation or partition scheduling. In such cases, the scheduling node can return a failure message indicating a physical table creation failure, along with the reason for the failure, allowing the physical table to be recreated after troubleshooting. After the physical table is created, the virtual table creation process can begin. The proxy node sends a virtual table creation request to the corresponding partition node. For example, if the identification information in the virtual table creation request indicates that the table ID of the virtual table is 10, then the proxy node can send the virtual table creation request to any virtual table partition range whose identification information value belongs to any partition node. For instance, the proxy node sends the virtual table creation request to partition node A. The method for determining the access address of the partition node can be as described above: it can be determined by the metadata recorded by the scheduling node and the access addresses of each partition node, or by the metadata corresponding to the physical table partitions maintained by each partition node and the access addresses of each partition node cached by the proxy node. This bypasses access to the scheduling node. After receiving a virtual table creation request from the application for the application table it maintains, the partition node can create the virtual table in the first physical table partition it maintains and record the metadata of the virtual table in the physical table partition maintained by any partition node. The virtual table is used to record the data corresponding to the application table. Thus, the virtual table is successfully created in the physical table partition maintained by the partition node.

[0051] After the virtual table is successfully created, read and write operations can be performed on it, such as... Figure 6 As shown, Figure 6 This is an exemplary embodiment of the flowchart illustrating the interaction between virtual table read and write operations. In response to a read / write request for the virtual table, a partition node can perform data read / write operations on the virtual table. It should be noted that the access address of the partition node can still be determined using the two methods described above: either based on the metadata recorded by the scheduling node and the access addresses of each partition node, or based on the metadata cached by the proxy node and the access addresses of each partition node. For specific determination methods, please refer to the relevant content above; these will not be repeated here.

[0052] After the virtual table is successfully created, you can perform deletion or modification operations on it, such as... Figure 7 As shown, Figure 7 This is an exemplary embodiment of the flowchart illustrating the interaction of deleting or modifying a virtual table. In response to a request to delete or modify a virtual table, a partition node retrieves the corresponding metadata for the virtual table from the physical table partitions maintained by that partition node, and then deletes or modifies the virtual table based on the retrieved metadata. It should be noted that the access address of the partition node can still be determined using the two methods described above: either based on the metadata recorded by the scheduling node and the access addresses of each partition node, or based on the metadata cached by the proxy node and the access addresses of each partition node. This specification does not impose any restrictions on this method.

[0053] From the above appendix Figure 5 To be continued Figure 7 Taking NoSQL databases as an example, when an application needs to create tables in a NoSQL database for its own maintained application tables, any partition node described in this specification can create a virtual table within the first physical table partition it maintains. The virtual table records the data corresponding to the application table, and the first physical table can record the data corresponding to multiple application tables. Thus, the NoSQL database no longer needs to create an independent physical table for each application table, thereby expanding the number of NoSQL database tables, getting rid of the limitation on the number of database tables, and meeting the application's needs for the number of tables.

[0054] Corresponding to the embodiments of the methods described above, this specification also provides embodiments of the apparatus.

[0055] Figure 8 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to it. Figure 8 At the hardware level, the electronic device includes a processor 801, a network interface 802, memory 803, non-volatile memory 804, and an internal bus 805, and may also include other hardware required for its functions. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it. Of course, this specification does not exclude other implementation methods besides software implementation, such as logic devices or a combination of hardware and software, etc. In other words, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0056] Figure 9 This is a block diagram of an apparatus for creating a table, as provided in an exemplary embodiment. Figure 9 As shown, the device includes:

[0057] The receiving unit 901 is used to receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table in the first physical table.

[0058] The creation unit 902 is used to create the virtual table within a first physical table partition maintained by any storage node, and to record the metadata of the virtual table in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

[0059] Optionally, the virtual table creation request includes the identification information of the virtual table, and the creation unit 902 is specifically used for:

[0060] Based on the value relationship between the identification information of the virtual table and the identification information of other virtual tables, the virtual tables are sequentially created within the first physical table partition, so that the arrangement order of the virtual tables and other virtual tables matches the value relationship.

[0061] Optionally, the database to which any storage node belongs includes multiple storage nodes, and each storage node maintains a physical table partition with a corresponding virtual table partition range; wherein: the virtual table creation request includes the identification information of the virtual table to be created, and if the value of the identification information is determined to belong to the virtual table partition range corresponding to the physical table partition maintained by any storage node, the virtual table creation request is sent to any storage node.

[0062] Optionally, the database includes a scheduling node, which records the metadata corresponding to the physical table partitions maintained by each storage node and the access address of each storage node. The metadata recorded by the scheduling node includes the range of virtual table partitions corresponding to the physical table partitions. The scheduling node is further configured to: compare the identification information included in the virtual table creation request with its own recorded metadata; and if it determines that the value of the virtual table identification information belongs to the range of virtual table partitions corresponding to the physical table partitions maintained by any storage node, determine the access address of that storage node as the sending address of the virtual table creation request; or...

[0063] The database includes the scheduling node and the proxy node. The proxy node caches the metadata corresponding to the physical table partitions maintained by each storage node and the access address of each storage node. The metadata cached by the proxy node includes the virtual table partition range corresponding to the physical table partition. The proxy node is further configured to: compare the identification information contained in the virtual table creation request with its own recorded metadata; and if it is determined that the value of the identification information of the virtual table belongs to the virtual table partition range corresponding to the physical table partition maintained by any storage node, determine the access address of any storage node as the sending address of the virtual table creation request.

[0064] Optionally, the creation unit 902 is specifically used for:

[0065] The metadata of the virtual table is recorded in the virtual table corresponding to the metadata within the first physical table partition; or, the metadata of the virtual table is recorded in another storage space within the first physical table partition that is different from the virtual table; or, the metadata of the virtual table is recorded in the second physical table partition maintained by the storage node.

[0066] Optionally, the device further includes:

[0067] The index data creation unit 903 is used to create index data corresponding to the virtual table and record the index data in the physical table partition maintained by the storage node.

[0068] Optionally, the device further includes:

[0069] The virtual table read / write unit 904 is configured to perform data read / write operations on the virtual table in response to a received read / write request for the virtual table; and / or, in response to a received delete or modify request for the virtual table, search for the metadata corresponding to the virtual table from the physical table partition maintained by the storage node, and delete or modify the virtual table according to the found metadata.

[0070] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments of the relevant methods, and will not be elaborated upon here.

[0071] As can be seen from the technical solutions provided in this specification, when an application needs to create tables in the database for its own maintained application tables, any storage node described in this specification can create a virtual table within the first physical table partition it maintains. The virtual table records the data corresponding to the application table, and the first physical table can record the data corresponding to multiple application tables. Thus, the database no longer needs to create an independent database table for each application table, thereby expanding the number of database tables, getting rid of the limitation on the number of database tables, and meeting the application's needs for the number of tables.

[0072] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0073] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0074] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0075] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0076] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0077] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for creating a table, the method comprising: Receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table within the first physical table. The virtual table is created within the first physical table partition maintained by any storage node, and the metadata of the virtual table is recorded in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

2. The method according to claim 1, wherein the virtual table creation request includes the identification information of the virtual table, and the step of creating the virtual table within a first physical table partition maintained by any storage node includes: Based on the value relationship between the identification information of the virtual table and the identification information of other virtual tables, the virtual tables are sequentially created within the first physical table partition, so that the arrangement order of the virtual tables and other virtual tables matches the value relationship.

3. The method according to claim 1, wherein the database to which any storage node belongs comprises multiple storage nodes, and each storage node maintains a physical table partition with a corresponding virtual table partition range; wherein: The virtual table creation request includes the identification information of the virtual table to be created, and if the value of the identification information is determined to belong to the range of the virtual table partition corresponding to the physical table partition maintained by any of the storage nodes, the virtual table creation request is sent to any of the storage nodes.

4. The method according to claim 3, wherein the database includes a scheduling node, the scheduling node being used to record metadata corresponding to physical table partitions maintained by each storage node and access addresses of each storage node, and the metadata recorded by the scheduling node includes the range of virtual table partitions corresponding to the corresponding physical table partitions; wherein, The scheduling node is also configured to: compare the identification information contained in the virtual table creation request with the metadata recorded by itself, and if it is determined that the value of the identification information of the virtual table belongs to the range of the virtual table partition corresponding to the physical table partition maintained by any storage node, determine the access address of any storage node as the sending address of the virtual table creation request. or, The database includes the scheduling node and the proxy node. The proxy node caches the metadata corresponding to the physical table partitions maintained by each storage node and the access address of each storage node. The metadata cached by the proxy node includes the virtual table partition range corresponding to the physical table partition. The proxy node is further configured to: compare the identification information contained in the virtual table creation request with its own recorded metadata; and if it is determined that the value of the identification information of the virtual table belongs to the virtual table partition range corresponding to the physical table partition maintained by any storage node, determine the access address of any storage node as the sending address of the virtual table creation request.

5. The method according to claim 1, wherein recording the metadata of the virtual table in the physical table partition maintained by any of the storage nodes comprises: Record the metadata of the virtual table in the virtual table corresponding to that metadata within the first physical table partition; or, The metadata of the virtual table is recorded in a separate storage space within the first physical table partition, distinct from the virtual table. or, The metadata of the virtual table is recorded in the second physical table partition maintained by the storage node.

6. The method according to claim 1, further comprising: Create index data corresponding to the virtual table and record the index data in the physical table partition maintained by the storage node.

7. The method according to claim 1, further comprising: In response to a received read / write request for the virtual table, data read / write operations are performed on the virtual table. And / or, In response to a received request to delete or modify the virtual table, the system searches for the metadata corresponding to the virtual table in the physical table partition maintained by the storage node, and deletes or modifies the virtual table based on the found metadata.

8. An apparatus for creating a table, the apparatus comprising: The receiving unit is used to receive a virtual table creation request initiated by the application party for the application table it maintains. The virtual table creation request is used to instruct the creation of a virtual table corresponding to the application table in the first physical table. A creation unit is used to create the virtual table within a first physical table partition maintained by any storage node, and to record the metadata of the virtual table in the physical table partition maintained by any storage node. The virtual table is used to record the data corresponding to the application table.

9. A distributed database system, the system comprising a scheduling node and a storage node, the storage node being configured to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as claimed in any one of claims 1 to 7.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as claimed in any one of claims 1 to 7.

Images