Database management system

Abstract

This specification provides a database management system that simultaneously supports single-machine and distributed tenants, and offers adaptive data processing capabilities. For single-machine tenants, at least one worker thread located on the same database node can generate execution plans for SQL statements and submit the corresponding pending transactions via group commit. Data processing is then performed based on these pending transactions through an I / O interface that supports single-machine parallel processing. For distributed tenants, multiple worker threads located on different database nodes can generate pending transactions for SQL statements and submit them via distributed transactions. Data processing is then performed based on these pending transactions through an I / O interface that supports distributed processing. Through this approach, tenants in a distributed database can adaptively select between single-machine and distributed modes to use the database, thereby improving database efficiency.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of terminal technology, and more particularly to a database management system. Background Technology

[0002] A database is a structured data storage system that can effectively store, retrieve, and process large amounts of data, providing powerful support for data management. Based on different database architectures, databases can be divided into standalone databases and distributed databases. Judging from current technological trends, the application of distributed databases will become increasingly widespread. Although distributed databases offer better disaster recovery capabilities and stronger horizontal scalability...

[0003] Distributed databases can provide services to multiple database tenants simultaneously, and these tenants can be isolated from each other to ensure data security for each tenant. In a distributed database, tenants are deployed in a distributed mode. However, not all transactions handled by tenants in distributed mode are distributed transactions. If a tenant in distributed mode needs to handle single-machine transactions, the complex underlying architecture of the distributed database can lead to significant unnecessary overhead, resulting in low database efficiency. Therefore, there is an urgent need for a database management system that supports both single-machine and distributed modes, allowing tenants in a distributed database to adaptively choose either mode to use the database, thereby improving database efficiency. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a database management system.

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

[0006] According to one or more embodiments of this specification, a database management system is proposed, which includes multiple tenants, wherein the tenants are single-machine tenants and / or distributed tenants, wherein:

[0007] When the tenant is a single-machine tenant, in response to receiving a Structured Query Language (SQL) statement, an execution plan corresponding to the SQL statement is generated by at least one worker thread located in the same database node, and the pending transaction corresponding to the execution plan is submitted by group commit, so that data processing can be performed on the target database corresponding to the database management system based on the pending transaction through the IO interface that supports single-machine parallel processing.

[0008] When the tenant is a distributed tenant, in response to receiving an SQL statement, multiple worker threads located in different database nodes generate a transaction to be processed corresponding to the SQL statement, and submit the transaction to be processed in a distributed transaction manner, so as to perform data processing based on the transaction to be processed in the target database corresponding to the database management system through the IO interface that supports distributed processing.

[0009] This specification provides a database management system that supports both single-machine and distributed tenants, offering data processing capabilities tailored to their specific needs and deployment methods. For single-machine tenants, at least one worker thread on the same database node generates execution plans for SQL statements and submits the corresponding transactions via group commit. Data processing is then performed on the target database within the database management system based on these transactions, utilizing an I / O interface that supports single-machine parallel processing. For distributed tenants, multiple worker threads on different database nodes generate corresponding transactions for SQL statements and submit them via distributed transactions. This allows for data processing on the target database within the database management system based on these transactions, utilizing an I / O interface that supports distributed processing. Through the solution provided in this specification, tenants in a distributed database can adaptively choose between single-machine or distributed modes to utilize the database, thereby improving database efficiency. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of a database management system provided in an exemplary embodiment.

[0011] Figure 2 This is a schematic diagram illustrating a tenant organization form as an exemplary embodiment.

[0012] Figure 3 This is a schematic diagram illustrating a tenant organization form as an exemplary embodiment.

[0013] Figure 4 This is a schematic diagram of a tenant organization form provided in an exemplary embodiment.

[0014] Figure 5 This is a schematic diagram of a tenant organization form provided in an exemplary embodiment.

[0015] Figure 6 This is a system architecture diagram of a database management system provided in an exemplary embodiment.

[0016] Figure 7 This is a schematic structural diagram of a server provided in an exemplary embodiment. Detailed Implementation

[0017] 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 as detailed in the appended claims.

[0018] 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.

[0019] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0020] To aid in understanding this specification, we will first introduce the technical terms that will be used in or related to this specification.

[0021] Transaction: A database transaction refers to a series of database operations that have semantic meaning. Therefore, they must either all be executed or none of them are executed. In other words, a database transaction is an indivisible unit of work.

[0022] The CAP theorem states that in a distributed system, consistency (C), availability (A), and partition tolerance (P) cannot be achieved simultaneously.

[0023] Vertical scaling refers to improving the performance of a single server by upgrading hardware. Common vertical scaling methods include increasing available memory and increasing the number of central processing units (CPUs).

[0024] Horizontal scaling: When a single machine reaches its performance limit through vertical scaling, greater throughput can be achieved by adding more servers.

[0025] Global Transaction Manager (GTM): One of the implementation schemes for distributed transactions. It maintains the state of all transactions in the cluster in a centralized mode. Among related technologies, MySQL InnoDB engine and Postgres-XL have adopted GTM or similar schemes.

[0026] Unified Time Service (Timestamp Oracle, TSO): One of the implementation schemes for distributed transactions. Compared with GTM, TSO generates a commit timestamp for each physical record, thereby ordering transactions.

[0027] System throughput (Transactions Per Second, TPS): refers to the number of transactions processed per second, and is often used to measure database performance.

[0028] After introducing the relevant technical terms in this manual, the data management system provided in this manual will be described in detail below.

[0029] In related technologies, whether it's a standalone database or a distributed database, the architecture of its database management system can be simply summarized into three layers: the SQL layer, the transaction layer, and the storage layer. The SQL layer is responsible for receiving SQL statements, converting them into the database's internal query language, and returning the processing results to the user. The transaction layer is a crucial component in managing and coordinating multiple database operations, playing a vital role in ensuring data consistency and security. The storage layer is responsible for storing data in the database to achieve data persistence.

[0030] Although the architecture of database management systems corresponding to standalone databases and distributed databases is the same, distributed databases need to deal with more complex scenarios compared to standalone databases. Therefore, distributed databases have more complex internal architecture designs, which leads to significant differences in the internal implementation of standalone databases and distributed databases. As a result, distributed databases are almost no longer designed to take into account the application scenarios of standalone databases.

[0031] For distributed databases to handle single-machine application scenarios, the entire distributed architecture needs to be migrated to a single node to simulate single-machine mode and thus cope with single-machine data application scenarios. However, compared to a true single-machine database, while a distributed database in single-machine mode can provide similar processing performance, the various components within the distributed database generate additional communication latency, resulting in lower single-machine performance for the distributed database compared to a true single-machine database.

[0032] With the continuous development of hardware technology, single-machine servers can now integrate more CPU cores, larger amounts of memory, and faster disk read / write speeds, giving them sufficiently strong computing and storage capabilities. Given this robust computing and storage capacity, maximizing database performance has become a key focus in mainstream database development.

[0033] Compared to distributed databases, standalone databases often achieve the goal of maximizing database performance more easily because their underlying architecture is simpler. Furthermore, standalone databases do not require consideration of inter-node communication and synchronization issues. Therefore, it is worthwhile to consider providing a database management system that can be compatible with the processing capabilities of standalone databases within a distributed database framework. This would allow for improved database performance utilization while retaining the processing power of distributed data.

[0034] Furthermore, because the designs of distributed databases and standalone databases are currently independent, the tenant types in distributed databases and standalone databases are relatively fixed. Distributed databases are all distributed tenants, while standalone databases are all standalone tenants. Distributed tenants cannot achieve the high performance of standalone tenants when processing standalone transactions, while standalone tenants cannot process distributed transactions at all.

[0035] In view of this, this specification aims to provide a database management system that can achieve integrated single-machine and distributed database operation, compatible with the processing capabilities of both single-machine and distributed databases. This allows it to support different business scales of large, medium, and small enterprises, providing elastically scalable database services that can seamlessly switch between single-machine and distributed modes without affecting data processing performance. It also ensures that the distributed database can fully utilize the configuration resources of a single-machine node even in single-machine mode. Furthermore, the provided database management system is expected to support both single-machine tenants and distributed tenants, providing the convenience of managing multiple tenants through a single database management system while achieving the same high efficiency performance as a single-machine database on each single-machine tenant.

[0036] See Figure 1 , Figure 1 This is a schematic diagram of a database management system provided in an exemplary embodiment, such as... Figure 1 As shown, the database management system can support both single-machine tenants and distributed tenants simultaneously. That is, a database management system can include multiple tenants, which can be single-machine tenants and / or distributed tenants. The database management system can provide adaptive data processing capabilities for different types of tenants.

[0037] When the tenant is a single-machine tenant, in response to receiving an SQL statement, an execution plan corresponding to the SQL statement is generated by at least one worker thread located in the same database node, and the pending transaction corresponding to the execution plan is submitted by group commit, so that data processing can be performed on the target database corresponding to the database management system based on the pending transaction through the IO interface that supports single-machine parallel processing;

[0038] When the tenant is a distributed tenant, in response to receiving an SQL statement, multiple worker threads located in different database nodes generate a transaction to be processed corresponding to the SQL statement, and submit the transaction to be processed in a distributed transaction manner, so as to perform data processing based on the transaction to be processed in the target database corresponding to the database management system through the IO interface that supports distributed processing.

[0039] The database management system provided in this manual enables the simultaneous deployment of single-machine tenants and distributed tenants in a distributed database. Each single-machine tenant can achieve the performance and efficiency of single-machine operation, while each distributed tenant can achieve distributed scalability. Tenants can adaptively choose the deployment method according to their actual technical needs. Regardless of whether it is deployed as a single-machine tenant or a distributed tenant, the database management system provided in this manual can support its operation.

[0040] Under different deployment methods, the tenants included in the database system can have the following organizational forms:

[0041] In one possible implementation, if the target database is deployed in standalone mode, then all tenants in the database management system are standalone tenants.

[0042] See Figure 2 , Figure 2 This is a schematic diagram illustrating a tenant organization form as shown in an exemplary embodiment, in which... Figure 2 In the database architecture shown, the database is deployed on only one database node, that is, as follows: Figure 2 The database shown is deployed in a standalone mode, such as Figure 2The database shown includes two tenants (tenant 1 and tenant 2), both of whom are single-machine tenants.

[0043] In another possible implementation, if the target database is deployed in a distributed mode, then multiple tenants in the database management system are single-machine tenants.

[0044] See Figure 3 , Figure 3 This is a schematic diagram illustrating a tenant organization form as shown in an exemplary embodiment, in which... Figure 3 In the database architecture shown, the database is deployed on two database nodes (i.e., database node 1 and database node 2), that is, as follows: Figure 3 The database shown is deployed in a distributed mode. Database node 1 includes two tenants (tenant 1 and tenant 2), and database node 2 includes two tenants (tenant 3 and tenant 4). All four tenants are single-machine tenants.

[0045] In another possible implementation, if the target database is deployed in a distributed mode, the multiple tenants in the database management system include single-machine tenants and distributed tenants.

[0046] See Figure 4 , Figure 4 This is a schematic diagram of a tenant organization form provided in an exemplary embodiment, in which... Figure 4 In the database architecture shown, the database is deployed on two database nodes (i.e., database node 1 and database node 2), that is, as follows: Figure 4 The database shown is deployed in a distributed mode. Database node 1 includes two tenants (i.e., tenant 1 and tenant 2), and database node 4 includes two tenants (i.e., tenant 2 and tenant 4). Among these four tenants, tenant 2 is a distributed tenant, while tenant 1, tenant 3, and tenant 4 are all single-machine tenants.

[0047] In another possible implementation, if the target database is deployed in a distributed mode, all tenants in the database management system are distributed tenants.

[0048] See Figure 5 , Figure 5 This is a schematic diagram of a tenant organization form provided in an exemplary embodiment, in which... Figure 5 In the database architecture shown, the database is deployed on two database nodes (i.e., database node 1 and database node 2), that is, as follows: Figure 5 The database shown is deployed in a distributed mode. Database node 1 includes two tenants (tenant 1 and tenant 2), and both tenants are distributed tenants.

[0049] It should be noted that after a tenant selects a certain deployment mode, the deployment method can be adjusted according to the dynamic changes in the tenant's needs.

[0050] Optionally, each tenant can maintain a tenant resource pool to record the database nodes that provide services to that tenant. The tenant can increase or decrease the number of nodes in the corresponding tenant resource pool according to its actual needs. Accordingly, the deployment method of the tenant can be adjusted according to the adjustment in the tenant resource pool.

[0051] It should be noted that, since the database management system provided in this manual can support both single-machine tenants and distributed tenants, switching between these two tenant deployment modes is permitted during the adjustment of the tenant deployment mode. In other words, the database management system also provides a function for converting between single-machine tenants and distributed tenants.

[0052] For example, for any tenant in a database management system, if the tenant is a single-machine tenant, the single-machine tenant is converted into a distributed tenant by increasing the number of database nodes corresponding to the single-machine tenant in the tenant resource pool; if the tenant is a distributed tenant, the distributed tenant is converted into a single-machine tenant by reducing the number of database nodes corresponding to the distributed tenant in the tenant resource pool to one.

[0053] Through the above solution, tenants can dynamically adjust their deployment methods according to actual needs. Regardless of the deployment method, the database management system can support their use of database functions, improving the flexibility of database usage. Moreover, single-machine tenants can obtain the performance and efficiency of single-machine operation, while distributed tenants can obtain distributed scalability, thereby improving database utilization efficiency.

[0054] The above embodiments mainly introduce the single-machine distributed integrated effect of the database management system from the perspective of tenant deployment. The architecture of the single-machine distributed integrated database will be described in detail below.

[0055] The data management system provided in this specification for implementing a single-machine distributed integrated system may include an SQL layer, a transaction layer, and a storage layer.

[0056] The SQL layer is used to generate an execution plan corresponding to an SQL statement in response to the received SQL statement, through at least one worker thread located in the same database node or multiple worker threads located in different database nodes.

[0057] The transaction layer is used to generate pending transactions based on the execution plan and submit the pending transactions to the storage layer through group commit or distributed transaction commit.

[0058] The storage layer is used to process data in the target database based on pending transactions through I / O interfaces that support both single-machine parallel processing and distributed processing.

[0059] Specifically, the SQL layer processes SQL statements through at least one worker thread located on the same database node, enabling it to process SQL statements in a standalone database mode; while processing SQL statements through multiple worker threads located on different database nodes enables it to process SQL statements in a distributed database mode, thus ensuring that the SQL layer provided in this specification is compatible with the processing capabilities of SQL layers in both standalone and distributed databases.

[0060] The transaction layer submits pending transactions via group commit, enabling it to commit transactions in a standalone database environment. Conversely, it submits pending transactions via distributed transaction commit, allowing it to commit transactions in a distributed database environment. This ensures that the transaction layer provided in this specification is compatible with the transaction layer processing capabilities of both standalone and distributed databases.

[0061] The storage layer enables data interaction in a standalone database mode by providing input / output (IO) interfaces that support parallel processing on a single machine; and enables data interaction in a distributed database mode by providing IO interfaces that support distributed processing, so that the storage layer provided in this specification is compatible with the processing capabilities of storage layers for both standalone and distributed databases.

[0062] For database developers, this database architecture provides a unified abstraction perspective, with each layer—SQL, transaction, and storage—compatible with the processing capabilities of both standalone and distributed databases. This represents a significant performance improvement for small and medium-sized enterprises (SMEs). In the early stages of business operations, SMEs typically have relatively small data volumes, allowing them to utilize the processing power of a standalone database while improving database performance utilization.

[0063] As business volume grows, the data scale of small and medium-sized enterprise users will also increase at any time. At this time, the above database architecture can be switched to a distributed mode to use the processing capabilities of the distributed database to process data without the need for data migration, thus avoiding potential data migration risks and maintenance costs caused by switching databases.

[0064] Additionally, it should be noted that the above database structure can provide at least one server for deploying the database. Therefore, the above data architecture is essentially a distributed database architecture. However, since each layer in the above database architecture is compatible with the processing logic of a standalone database, the above database architecture can achieve a unified standalone and distributed architecture.

[0065] Optionally, for tenants with different deployment methods, the SQL layer, transaction layer, and storage layer can adaptively select the processing method to meet the tenant's usage needs.

[0066] For example, in the case of a single-machine tenant, the SQL layer can be used to generate an execution plan corresponding to the SQL statement in response to the received SQL statement, through at least one worker thread located in the same database node; the transaction layer can be used to generate pending transactions based on the execution plan, and submit the pending transactions to the storage layer through group commit; the storage layer can be used to perform data processing in the target database based on the pending transactions through an IO interface that supports single-machine parallel processing.

[0067] When the tenant is a distributed tenant, the SQL layer can be used to respond to received SQL statements and generate execution plans corresponding to the SQL statements through multiple worker threads located in different database nodes; the transaction layer can be used to generate pending transactions based on the execution plans and submit the pending transactions to the storage layer through distributed transaction commit; the storage layer can be used to perform data processing in the target database based on the pending transactions through IO interfaces that support distributed processing.

[0068] Optionally, the processing logic under different modes can be encapsulated into corresponding processing engines so that different processing engines can meet the data processing needs of different tenants.

[0069] In some embodiments, the SQL layer may include a standalone SQL engine and a distributed SQL engine, so that the standalone SQL engine can realize the processing capabilities of the SQL layer in a standalone database, and the distributed SQL engine can realize the processing capabilities of the SQL layer in a distributed database.

[0070] Among them, the single-machine SQL engine is used to generate the execution plan corresponding to the SQL statement by using at least one worker thread located in the database node to be accessed when there is only one database node to be accessed for the SQL statement.

[0071] A distributed SQL engine is used to generate an execution plan for an SQL statement when there are multiple database nodes to be accessed, by using multiple worker threads located on different database nodes.

[0072] The database architecture described above is essentially a distributed database architecture. Therefore, using a distributed SQL engine in a distributed database can provide good distributed processing capabilities. That is, by using a distributed SQL engine in a distributed database, SQL statements can be processed by multiple worker threads located on different database nodes. From the perspective of a single-machine database, in order to make the most of single-machine resources, SQL statements are processed by at least one worker thread located on the same database node. This allows the SQL layer to make full use of multi-threading technology to provide parallel capabilities, thereby maximizing data processing performance under the current hardware conditions.

[0073] It should be noted that, in a single-machine SQL engine, when generating the execution plan corresponding to the SQL statement through at least one worker thread located in the database node to be accessed, communication between at least one worker thread in the database node to be accessed can be achieved through function calls, so that at least one worker thread can generate the execution plan corresponding to the SQL statement.

[0074] A distributed SQL engine, when generating execution plans for SQL statements through multiple worker threads located on different database nodes to be accessed, can communicate between worker threads on different database nodes through remote procedure calls, so as to generate execution plans for SQL statements through multiple worker threads.

[0075] In some embodiments, the transaction layer includes a single-machine transaction engine and a distributed transaction engine, so that the single-machine transaction engine can realize the transaction layer processing capabilities of a single-machine database, and the distributed transaction engine can realize the transaction layer processing capabilities of a distributed database.

[0076] Among them, the single-machine transaction engine is used to generate pending transactions based on the execution plan, and submit pending transactions in batches through group commit, so as to submit the pending transactions to the storage layer.

[0077] The distributed transaction engine is used to generate pending transactions based on the execution plan and submit the pending transactions to the storage layer through distributed transaction commit.

[0078] The database architecture described above is essentially a distributed database architecture. Therefore, using a distributed transaction engine in a distributed database can provide good distributed processing capabilities. That is, by using a distributed transaction engine in a distributed database, pending transactions can be submitted through distributed transactions. From the perspective of a single-machine database, in order to make the best use of single-machine resources, group commit can be used to submit pending transactions. Optionally, the single-machine transaction engine can handle data read and write conflicts at the transaction layer by providing technologies such as Multiversion Concurrency Control (MVCC), ensuring that pending transactions can be successfully submitted through group commit.

[0079] In some embodiments, the storage layer includes a single-machine storage engine and a distributed storage engine, so that the single-machine storage engine can realize the processing capabilities of the storage layer in a single-machine database, and the distributed storage engine can realize the processing capabilities of the storage layer in a distributed database.

[0080] Among them, the single-machine storage engine is used to process data in the target database based on the transaction to be processed through the IO interface that supports single-machine parallel processing;

[0081] A distributed storage engine is used to process data in the target database based on pending transactions through an I / O interface that supports distributed processing.

[0082] The database architecture described above is essentially a distributed database architecture. Therefore, using a distributed storage engine within a distributed database can provide good distributed processing capabilities. In other words, using a distributed storage engine within a distributed database can provide an I / O interface that supports distributed processing. From the perspective of a standalone database, in order to make full use of the disk and storage resources of the standalone machine, an I / O interface that supports standalone parallel processing can be provided through a standalone storage engine.

[0083] See Figure 6 , Figure 6 This is a system architecture diagram of a database management system provided in an exemplary embodiment, such as... Figure 6 As shown, the system architecture can be divided into standalone mode and distributed mode.

[0084] In standalone mode, the SQL layer in standalone mode may include a standalone SQL engine to provide standalone parallel execution capabilities; the transaction layer in standalone mode may include a standalone transaction engine to provide group commit capabilities; and the storage layer in standalone mode may include a standalone storage engine to provide standalone parallel I / O interfaces.

[0085] In distributed mode, the SQL layer can include a distributed SQL engine to provide efficient serial execution capabilities; the transaction layer can include a distributed transaction engine to provide single-machine transaction optimization capabilities; and the storage layer can include a distributed storage engine to provide I / O interface rotation and merging capabilities.

[0086] It should be noted that when a distributed database is working in distributed mode, communication between components can be achieved normally through distributed components; however, when a distributed database is working in single-machine mode, there is no need to start additional distributed components. Instead, a single-process multi-threaded model is used, and communication between various components in the database architecture can be achieved through direct function calls.

[0087] In addition, through such Figure 6 The database architecture shown not only enables vertical interaction between different levels, but also supports horizontal interaction between different levels. For example, the single-machine SQL engine and the distributed SQL engine can communicate via Remote Procedure Call (RPC), the single-machine transaction engine and the distributed transaction engine can communicate via RPC, and the single-machine storage engine and the distributed storage engine can communicate via RPC.

[0088] With the above database architecture, in single-machine mode, nodes can interact with each other only by local function calls, without the need for additional communication steps. This breaks away from the traditional distributed database design approach of strict layering and only supporting inter-layer calls.

[0089] Additionally, it should be noted that this database architecture can serve as an intermediary layer connecting the front-end and the database, enabling communication through mechanisms such as... Figure 1 The database architecture shown receives database operation requests from the front end and processes the data in the database based on these requests. The front end can be a program driver or a database proxy server, etc.

[0090] Experiments show that, through single-machine transaction TPS tests in a distributed deployment environment, the single-machine integrated database provided in this manual demonstrates superior performance compared to the traditional centralized database MySQL 8.0 in terms of data selection, data reading and writing, data insertion, and data updating. The experimental results can be seen in Table 1 below, which compares the performance of the single-machine integrated database and MySQL 8.0 in terms of TPS.

[0091] Table 1

[0092] operate Standalone integrated database MySQL 8.0 point select 619669 571863 Read only 25611 12327 Write only 61654 43836 read write 16736 11342 insert 234907 140379 update 229066 116765

[0093] This manual presents a database management system that integrates single-machine and distributed deployments, addressing the industry pain point that distributed databases are not well-suited for single-machine deployments. This integrated single-machine and distributed database management system will further reduce data management costs for small and medium-sized enterprises and improve the efficiency of single-machine transaction processing in distributed databases. Experimental results demonstrate that the database based on this integrated single-machine and distributed database management system significantly outperforms the traditional centralized database MySQL 8.0 in single-machine performance.

[0094] In some embodiments, this specification also provides a server; please refer to... Figure 7 , Figure 7 This is a schematic structural diagram of a server provided in an exemplary embodiment. For example... Figure 7 As shown, at the hardware level, the server includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 710, and may also include other hardware required for tasks. One or more embodiments of this specification can be implemented in software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into memory 708 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0095] The systems or engines described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0096] In a typical configuration, a computer includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0097] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0098] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined in this article, computer-readable media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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."

[0103] 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 database management system comprising a plurality of tenants, the database management system supporting each of the tenants to convert a tenant type between a single-tenant type and a distributed-tenant type, wherein: in a case that the tenant is a single-tenant, in response to receiving a SQL statement, an execution plan corresponding to the SQL statement is generated by at least one worker thread located in a same database node, and a to-be-processed transaction corresponding to the execution plan is submitted in a group commit manner, so that data processing is performed in a target database corresponding to the database management system based on the to-be-processed transaction through an IO interface supporting single-parallel processing; and in a case that the tenant is a distributed-tenant, in response to receiving a SQL statement, a to-be-processed transaction corresponding to the SQL statement is generated by a plurality of worker threads located in different database nodes, and the to-be-processed transaction is submitted in a distributed transaction manner, so that data processing is performed in the target database corresponding to the database management system based on the to-be-processed transaction through an IO interface supporting distributed processing. 2.The system of claim 1, for any tenant in the database management system: if the tenant is a single-tenant, the single-tenant is converted to a distributed-tenant in response to increasing a number of database nodes corresponding to the single-tenant in a tenant resource pool; and if the tenant is a distributed-tenant, the distributed-tenant is converted to a single-tenant in response to reducing a number of database nodes corresponding to the distributed-tenant in the tenant resource pool to one. 3.The system of claim 1, wherein: if the target database is deployed in a single mode, each of the plurality of tenants in the database management system is a single-tenant; and if the target database is deployed in a distributed mode, each of the plurality of tenants in the database management system is a single-tenant, or the plurality of tenants in the database management system comprises single-tenants and distributed-tenants, or each of the plurality of tenants in the database management system is a distributed-tenant. 4.The system of claim 1, comprising a SQL layer, a transaction layer and a storage layer, and in a case that the tenant is a single-tenant: the SQL layer is configured to generate an execution plan corresponding to a SQL statement by at least one worker thread located in a same database node in response to receiving the SQL statement; the transaction layer is configured to generate a to-be-processed transaction based on the execution plan, and submit the to-be-processed transaction to the storage layer in a group commit manner; and the storage layer is configured to perform data processing in the target database based on the to-be-processed transaction through an IO interface supporting single-parallel processing. 5.The system of claim 4, in a case that the tenant is a distributed-tenant: the SQL layer is configured to generate an execution plan corresponding to a SQL statement by a plurality of worker threads located in different database nodes in response to receiving the SQL statement. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ The transaction layer is configured to generate a to-be-processed transaction based on the execution plan, and submit the to-be-processed transaction to the storage layer in a distributed transaction submission manner. The storage layer is configured to perform data processing in the target database based on the to-be-processed transaction through an IO interface supporting distributed processing.

6. The system of claim 5, wherein the SQL layer comprises a single-machine SQL engine and a distributed SQL engine. The single-machine SQL engine is configured to generate an execution plan corresponding to the SQL statement through at least one worker thread in a to-be-accessed database node in a case where the to-be-accessed database node is one. The distributed SQL engine is configured to generate an execution plan corresponding to the SQL statement through a plurality of worker threads in different to-be-accessed database nodes in a case where the to-be-accessed database nodes are multiple.

7. The system of claim 6, wherein the single-machine SQL engine, when configured to generate an execution plan corresponding to the SQL statement through at least one worker thread in a to-be-accessed database node, is configured to: communicate between the at least one worker thread in the to-be-accessed database node through a function call to generate the execution plan corresponding to the SQL statement through the at least one worker thread.

8. The system of claim 6, wherein the distributed SQL engine, when configured to generate an execution plan corresponding to the SQL statement through a plurality of worker threads in different to-be-accessed database nodes, is configured to: communicate between the worker threads in different to-be-accessed database nodes through a remote procedure call to generate the execution plan corresponding to the SQL statement through the plurality of worker threads.

9. The system of claim 5, wherein the transaction layer comprises a single-machine transaction engine and a distributed transaction engine. The single-machine transaction engine is configured to generate a to-be-processed transaction based on the execution plan, and submit the to-be-processed transaction to the storage layer in a group submission manner. The distributed transaction engine is configured to generate a to-be-processed transaction based on the execution plan, and submit the to-be-processed transaction to the storage layer in a distributed transaction submission manner.

10. The system of claim 5, wherein the storage layer comprises a single-machine storage engine and a distributed storage engine. The single-machine storage engine is configured to perform data processing in the target database based on the to-be-processed transaction through an IO interface supporting single-machine parallel processing. The distributed storage engine is configured to perform data processing in the target database based on the to-be-processed transaction through an IO interface supporting distributed processing.

Images