Database system supporting kernel-level multiple protocols and data communication method thereof

Abstract

The invention relates to the technical field of databases, and particularly discloses a kernel-level multi-protocol supporting database system and a data communication method. According to the system, the support capabilities of multiple database protocols such as MySQL and PostgreSQL are originally integrated in a database kernel to form a unified database instance. The basic principle is that client connections are directly distributed through an instantaneous routing mechanism of a network port; syntax and deep semantics (such as transactions, types and error codes) of different protocols are converted into a unified relational algebraic expression in a coordinated mode through a built-in unified semantic core layer; and optimizing and executing the unified semantic expression through a protocol-independent core processing layer, and realizing cross-protocol execution plan and result reuse by using a global DAG cache based on semantic hash. According to the method, high-performance and high-compatibility multi-protocol data service is realized, and the problems of performance overhead and incomplete semantic conversion caused by an external proxy architecture are thoroughly eliminated.

Description

Technical Field

[0001] This invention relates to the field of databases, and more specifically, to a database system that supports kernel-level multi-protocols and its data communication method. Background Technology

[0002] Currently, with the diversification of enterprise IT architectures, the need for application systems to simultaneously access multiple types of databases (such as MySQL and PostgreSQL) is becoming increasingly common. To achieve compatible access from clients using different protocols, the mainstream solution is to deploy a separate proxy or gateway in front of the database. This external proxy, acting as an intermediary layer, is responsible for parsing, translating, and forwarding requests and results from different database protocols. While this approach achieves basic connectivity, it is essentially a compromise and has inherent architectural flaws.

[0003] These external proxy solutions first face significant performance overhead. Each data request needs to be received, parsed, and forwarded through the proxy, introducing additional network hops and serialization overhead, leading to increased response latency and limited throughput. Second, during the connection establishment phase, the proxy typically needs to complete the full application-layer handshake message parsing to identify the client type, increasing connection establishment latency. More importantly, most of these proxies can only perform simple syntax-level translation, failing to address deeper semantic differences between different databases in areas such as transaction auto-commit behavior, data type precision and value range, and error code systems. This can easily lead to unexpected application behavior and lacks complete compatibility.

[0004] Therefore, while current technological developments focus on optimizing proxy performance and enhancing syntax coverage, they have consistently failed to overcome the fundamental architectural limitations of external middleware. This has led to a long-standing dilemma in multi-protocol compatibility solutions, where performance, functional completeness, and resource utilization are difficult to balance. There is an urgent need for a new solution that can natively, efficiently, and thoroughly resolve multi-protocol compatibility issues at the database kernel level. Summary of the Invention

[0005] The purpose of this invention is to provide a database system solution that solves the multi-protocol compatibility problem natively, efficiently, and thoroughly at the database kernel level.

[0006] According to a first aspect of the present invention, a kernel-level multi-protocol database system is proposed, comprising: The multi-protocol listening and routing layer is used to concurrently listen for client connections on multiple predefined ports and directly route client connections to the corresponding protocol resolver based on the target port number used when establishing the connection. The protocol parsing and session management layer communicates with the multi-protocol listening and routing layer, including multiple protocol parsers used to deserialize the received protocol-specific binary data streams into structured SQL commands and control instructions, and maintain a session context containing the protocol type for each client connection; The unified semantic core layer communicates and connects with the protocol parsing and session management layer. It is used to convert SQL commands and control instructions from different protocols into a unified protocol-independent representation within the system through semantic coordination. The protocol-independent core processing layer communicates and connects with the unified semantic core layer, and is used to perform query optimization and execution operations on the unified protocol-independent representation; The unified storage engine layer communicates with the protocol-independent core processing layer to provide persistent storage and management of data.

[0007] According to some embodiments, in the system of the first aspect of the present invention, when establishing a network connection, the multiprotocol listening and routing layer does not parse the application layer handshake message, but only completes instantaneous routing based on the target port number.

[0008] According to some embodiments, in the system of the first aspect of the present invention, the session context maintained by the protocol parsing and session management layer includes at least one of the following: character set, time zone, and transaction state.

[0009] According to some embodiments, in the system of the first aspect of the present invention, the unified semantic core layer includes: SQL dialect normalizer is used to rewrite SQL syntax trees of different protocols into unified relational algebra expressions; The type system coordinator is used to resolve inconsistencies in data type definitions across different protocols based on a predefined type mapping matrix.

[0010] According to some embodiments, in the system of the first aspect of the present invention, the unified semantic core layer further includes: Transaction behavior coordinator is used to uniformly manage the differences in transaction behavior between different protocols; An error mapping coordinator is used to map uniform errors generated during internal execution back to the specific protocol error codes and message formats expected by the client.

[0011] According to some embodiments, in the system of the first aspect of the present invention, the protocol-independent core processing layer includes: A DAG-based query optimizer is used to convert uniform relational algebra expressions into directed acyclic graphs and compute their semantic hashes. A global DAG cache is used to cache execution plans or serialized result packages using semantic hashes as keys.

[0012] According to some embodiments, in the system of the first aspect of the present invention, the global DAG cache is configured to share the same cache entry when queries from different protocol clients have the same semantic hash.

[0013] According to a second aspect of the present invention, a data communication method for a kernel-level multi-protocol database system based on the first aspect of the present invention is proposed, comprising the following steps: S1. Through the multi-protocol listening and routing layer, based on the target port number of the client connection, it is directly routed to the corresponding protocol resolver; S2. Through protocol parsing and session management, parse client requests, establish and maintain session context; S3. By using a unified semantic core layer, the parsed protocol-specific commands are converted into a unified protocol-independent representation within the system; S4. Optimize and execute protocol-independent representations through a protocol-independent core processing layer; S5. Access data through the unified storage engine layer; S6. After the execution result is adapted to the protocol by the unified semantic core layer, it is returned to the client.

[0014] According to some embodiments, in the method of the second aspect of the present invention, step S3 includes: The syntax trees of SQL statements from different protocols are converted into unified relational algebra expressions through syntax tree rewriting technology.

[0015] According to some embodiments, in the method of the second aspect of the present invention, step S4 includes: Compute the semantic hash of the protocol-independent representation; Query the global cache. If a cache entry that matches the semantic hash exists, use the execution plan or result from the cache directly. Otherwise, generate a new execution plan and execute it, while storing the new execution plan in the global cache after associating it with the semantic hash.

[0016] The solution proposed in this invention has the following beneficial effects: 1. To address the issues of additional performance overhead, complex architecture, and inability to deeply optimize multi-protocol compatibility achieved through external proxies, this invention natively integrates the multi-protocol processing module with the core database engine at the kernel level to form a single database instance. This eliminates network jumps and serialization overhead, simplifies the architecture, and lays the foundation for deep kernel-level optimization.

[0017] 2. To address the issue of high connection establishment latency caused by traditional proxies requiring the parsing of application layer handshake messages to identify protocols, this invention achieves millisecond-level or even sub-millisecond-level connection establishment speeds by performing instantaneous direct routing based solely on the target port number during connection establishment, significantly reducing connection latency.

[0018] 3. To address the problem that traditional translation solutions cannot completely solve the differences in syntax and deep semantics (such as transactions, types, and error codes) between different database protocols, this invention constructs a unified semantic core layer, uses relational algebra as a universal intermediate representation, and integrates multiple semantic coordinators for conversion, achieving a leap from syntax compatibility to true semantic compatibility, and ensuring the functional integrity and behavioral consistency of cross-protocol operations.

[0019] 4. To address the problem of wasted computing resources caused by the inability to share optimization results for the same semantic query due to differences in client protocols or text, this invention introduces a global DAG cache based on semantic hashing in the protocol-independent layer to index and reuse execution plans and results. This enables the sharing of query optimization results and calculation results across different database protocol clients (such as MySQL and PostgreSQL), significantly improving the overall system throughput and resource utilization. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without exceeding the scope of protection claimed by the present invention.

[0021] Figure 1 This is a schematic diagram of an embodiment 1000 of the present invention that supports a kernel-level multi-protocol database system; Figure 2 for Figure 1 A schematic diagram of the structure of a specific embodiment 103A of the unified semantic core layer 103; Figure 3 for Figure 1 A schematic diagram of the structure of a specific embodiment 103B of the unified semantic core layer 103; Figure 4 for Figure 1 A schematic diagram of a specific embodiment of the protocol-independent core processing layer 104; Figure 5 A method based on the present invention Figure 1-4 A flowchart illustrating an embodiment 2000 of a data communication method for a kernel-level multi-protocol database system; Figure 6 for Figure 5A flowchart illustrating step S4 in embodiment 2000. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Figure 1 This is a schematic diagram of an embodiment 1000 of the present invention that supports a kernel-level multi-protocol database system. Figure 1 As shown, embodiment 1000 includes a multi-protocol listening and routing layer 101, a protocol parsing and session management layer 102, a unified semantic core layer 103, a protocol-independent core processing layer 104, and a unified storage engine layer 105.

[0024] The multi-protocol listening and routing layer 101 is used to concurrently listen for client connections on multiple predetermined ports and directly route client connections to the corresponding protocol resolver based on the destination port number used when establishing a connection. Optionally, when establishing a network connection, the multi-protocol listening and routing layer 101 does not parse the application layer handshake message, but only performs instantaneous routing based on the destination port number.

[0025] Optionally, in some specific embodiments, upon system startup, the multi-protocol listening and routing layer 101 loads a port-protocol mapping table based on a static configuration file or instructions received via a management API. Subsequently, it calls the operating system's network API to simultaneously create listening sockets on multiple specified ports. Each listening socket is set to non-blocking mode and added to the same high-performance I / O multiplexing event loop. This means that a network thread or a small number of threads can simultaneously monitor connection request events on all ports.

[0026] Specifically, during the connection reception and transient routing process of the multi-protocol listening and routing layer 101, when the client initiates a TCP connection request (i.e., sends a SYN packet), after the operating system kernel completes the TCP three-way handshake, a readable event is generated on the corresponding listening socket. Upon capturing this event in the event loop, the following atomic operations are immediately executed: Accept connection: Call the accept() system call to obtain a newly established connection socket client_socket; Extracting the port: Use the getsockname() function to obtain the local port number bound to client_socket; Lookup routing: Based on the obtained port number, the port-protocol mapping table is queried to instantly determine the protocol type corresponding to the connection; for example, a connection from port 3306 is identified as "MySQL protocol"; Protocol context allocation: Based on the determined protocol type, a protocol parser instance and session memory context corresponding to the protocol are allocated from the pre-allocated protocol processor resource pool. Resource pooling avoids the latency of dynamic creation. Connection handover: The file descriptor of the client_socket, along with the allocated protocol parser and session context, are treated as a complete task package and dispatched directly to the dedicated worker thread group responsible for processing this protocol, via a lock-free queue or work-stealing mechanism. At this point, routing is complete. The key point is that no application-layer data bytes have been read from this socket during this process.

[0027] Optionally, the handover of data flow and subsequent processing between the multi-protocol listening and routing layer 101 includes the following: after the connection is handed over, all subsequent data reading and writing, and protocol parsing work for that connection will be completely taken over by the corresponding protocol-specific worker thread and protocol parser. The multi-protocol listening and routing layer 101 itself no longer participates in any data processing for that connection; its responsibility reverts to continuing to listen for new connection requests. This design achieves a clear separation of responsibilities: the routing layer is only responsible for efficient connection distribution, while complex protocol parsing is handled by specialized backend modules.

[0028] The technical principle of the multi-protocol monitoring and routing layer 101 in this invention is as follows: In standard database protocols, there is a mandatory one-to-one mapping relationship between the port number used to establish a connection and the protocol type. Utilizing this inherent property of the network / transport layer, 100% accurate protocol identification and routing can be achieved without understanding the complex semantics of application layer protocols.

[0029] The principle of comparison with traditional proxies: Traditional proxies, such as MySQL Router or various gateways, must further read and parse the first application-layer handshake packet sent by the client from the socket after accepting the connection, such as MySQL's Handshake Initialization Packet, in order to infer the protocol and version expected by the client. This call process of traditional proxies involves at least one additional system call for read, memory allocation, and protocol decoding, introducing a significant latency and CPU overhead.

[0030] This invention abandons the passive reactive routing of read-parse-determine, and adopts an active preset routing based on port identity. Protocol identification is moved down from the application layer to the transport layer, and the routing decision point is moved from "after receiving the first data packet" to "when the TCP connection is established." According to the multi-protocol monitoring and routing layer 101 of this invention, the following technical effects are achieved: (1) Reduced connection establishment latency, eliminating round-trip time and computational overhead for parsing handshake packets, reducing the processing latency of new connections from milliseconds to microseconds; (2) Increased system throughput, due to the extremely simple routing logic and the fact that the main listening thread / process hardly processes any business data, it can easily handle tens of thousands or even hundreds of thousands of connection establishment requests per second; (3) Deterministic and highly reliable architecture, based on statically configured routing rules, the system behavior is completely deterministic, avoiding any ambiguity or errors that may be caused by dynamic protocol probing. At the same time, the decoupling of the network layer and the protocol processing layer allows both to be horizontally scaled or fault-tolerant independently.

[0031] The protocol parsing and session management layer 102 communicates with the multi-protocol listening and routing layer 101 and includes multiple protocol parsers for deserializing received protocol-specific binary data streams into structured SQL commands and control instructions, and maintaining a session context containing the protocol type for each client connection.

[0032] Optionally, the protocol parsing and session management layer 102 includes a protocol parser plugin framework. At system startup, protocol parser plugins in the form of dynamic libraries are loaded from a predefined directory. Each plugin must implement a set of standard interface functions, including: Initialization function: used to register metadata such as protocol name, default port, and protocol version; Parsing functions: used to parse network data streams into internally structured command objects; Serialization functions: used to serialize internal results into a protocol-specific binary format; Session creation function: Used to create a protocol-specific session context; Feature query function: Returns the features supported by the protocol (such as whether transactions are supported, whether streaming results are supported, etc.).

[0033] Optionally, the system maintains a global protocol resolver registry, mapping protocol names to corresponding resolver instances. Once the routing layer determines the protocol type based on the port number, it can retrieve the corresponding resolver instance from the registry to handle the connection.

[0034] In some specific embodiments, the protocol parsing and session management layer 102, in cooperation with the multi-protocol listening and routing layer 101, includes the following data flow and connection context transmission: (1) Connection establishment and parser binding: When the multi-protocol listening and routing layer 101 receives a new connection, that is, when the protocol type is identified by the port number, it will not parse any application layer data, but will immediately encapsulate the connection socket and protocol identifier into a task and submit it to a global work queue.

[0035] (2) Worker thread allocation: The protocol parsing and session management layer 102 has a set of worker threads used to retrieve tasks from the queue. Each worker thread can handle connections of any protocol, but a connection is usually handled by a fixed worker thread for its lifetime to avoid context switching overhead.

[0036] (3) Parser instantiation: Based on the protocol identifier, the worker thread retrieves the corresponding parser plugin from the protocol parser registry and calls the plugin's session creation function to create an independent parser instance for the connection. This instance will be responsible for all subsequent data parsing for the connection.

[0037] (4) Data stream processing: The worker thread adds the connection socket to the event loop. When data is available to read, the event loop calls back the parsing function of the parser instance corresponding to the connection. The parsing function reads the binary data stream from the socket and parses it according to the protocol specification.

[0038] In some specific embodiments, each protocol parser in the protocol parsing and session management layer 102 implements the following key technologies: (1) Binary stream parsing and state machine: Each protocol parser maintains an internal protocol state machine. For example, the states of the MySQL protocol include: handshake phase, authentication phase, command phase, etc. Based on the current state, the parser knows the expected data format to be received next and parses the data packet according to the protocol specification.

[0039] Taking the MySQL protocol as an example: During the handshake phase, the parser expects to receive a handshake response packet, which contains client capability flags, username, password, etc.

[0040] During the command phase, the parser expects to receive a command packet, the first byte of which is the command type (such as query, prepared statement, etc.), followed by the command data.

[0041] The parser employs an "on-demand parsing" strategy, meaning it only parses when a complete data packet is received (based on the protocol packet length field); otherwise, it continues to wait for data.

[0042] (2) Structured command generation: After parsing the binary data stream, the parser generates a unified command structure. This unified command structure is protocol-independent and will be passed to the upper-layer unified semantic core layer 103. This structure contains: Command types: such as queries, preparation statements, execution statements, transaction control, etc. Parameter list: For prepared statements, parameters are stored in an internal format; The sequence number in the original protocol is used for sorting response packets; (3) Exception handling and protocol compliance: During the parsing process, the parser rigorously checks the validity of the data. If it finds data that does not conform to the protocol specifications, such as incorrect packet length or illegal command type, the parser generates a protocol error and immediately returns it to the client without passing it to the upper layer. This ensures that only legitimate requests enter the database core.

[0043] Optionally, in the protocol resolution and session management layer 102, each connection has a session context, which consists of two parts: (1) Protocol-independent public context: including connection ID, client address, connection time, current database, character set, time zone, transaction status (whether in a transaction, isolation level, etc.). This information is managed uniformly by the core system.

[0044] (2) Protocol-specific private context: This is a part defined and managed by the protocol parser plugin itself, used to store state information specific to the protocol. For example, a MySQL parser may need to store the mapping between the IDs of prepared statements and internal statements, while a PostgreSQL parser may need to store the mapping between the portal and prepared statements.

[0045] Optionally, the protocol resolution and session management layer 102 manages the context of all connections through a unified session manager. The session manager assigns a unique session ID to each connection and maintains a mapping from the session ID to the session context.

[0046] In the protocol parsing and session management layer 102, although the private context structures of different protocols are different, this invention achieves state isolation between protocols by dividing the session context into public and private parts, while ensuring that the core system can access and manage the public state.

[0047] The unified semantic core layer 103 communicates with the protocol parsing and session management layer 102 and is used to convert SQL commands and control instructions from different protocols into a unified protocol-independent representation within the system through semantic coordination.

[0048] Optionally, in some specific embodiments, the unified semantic core layer 103 includes: an SQL dialect normalizer for rewriting SQL syntax trees of different protocols into unified relational algebra expressions; and a type system coordinator for resolving inconsistencies in data type definitions of different protocols based on a predefined type mapping matrix.

[0049] Optionally, the unified semantic core layer 103 also includes: a transaction behavior coordinator for uniformly managing the differences in transaction behavior between different protocols; and an error mapping coordinator for mapping unified errors generated during internal execution back to the specific protocol error codes and message formats expected by the client.

[0050] The protocol-independent core processing layer 104 is communicatively connected to the unified semantic core layer 103 and is used to perform query optimization and execution operations on the unified protocol-independent representation.

[0051] Optionally, the protocol-independent core processing layer 104 includes a DAG-based query optimizer and a global DAG cache: the DAG-based query optimizer is used to convert uniform relational algebra expressions into directed acyclic graphs and compute their semantic hashes; the global DAG cache is used to cache execution plans or serialized result packets using the semantic hash as the key. Specifically, the global DAG cache is configured to share the same cache entry when queries from different protocol clients have the same semantic hash.

[0052] The unified storage engine layer 105 communicates with the protocol-independent core processing layer 104 and is used to provide persistent storage and management of data. The unified storage engine layer 105 is the core of the database system's data persistence, providing a unified, protocol-independent data access interface to the upper protocol-independent core processing layer 104. Regardless of the protocol from which the upper layer processes queries, the storage engine layer uses the same set of interfaces and internal mechanisms to manage data.

[0053] Optionally, the unified storage engine layer 105 adopts a modular design, mainly comprising the following core components: Transaction Manager: Responsible for providing ACID transaction support, including concurrency control, lock management, deadlock detection and recovery, etc.

[0054] Storage Manager: Responsible for managing the storage structure of data on disk, including the management of tablespaces, segments, and pages, as well as data read and write operations.

[0055] Index Manager: Responsible for managing various types of indexes, such as B+ trees, hashes, and full-text indexes, to accelerate data retrieval.

[0056] Buffer manager: Responsible for managing cached pages in memory, reducing disk I / O.

[0057] Log Manager: Responsible for recording transaction logs (such as WAL) to ensure data persistence and fault recovery.

[0058] In some specific embodiments, the design principles of the unified storage engine layer 105 include: unified interface, providing a set of protocol-independent storage interfaces; pluggability, allowing support for different underlying storage formats, which can be selected or switched at runtime; and high concurrency, supporting high-concurrency read and write through mechanisms such as MVCC.

[0059] Optionally, in some specific embodiments, the communication connection between the unified storage engine layer 105 and the protocol-independent core processing layer 104 is as follows: the protocol-independent core processing layer 104 accesses data by calling the unified interface provided by the unified storage engine layer 105. Optionally, the unified interface is provided in the form of functions or methods, including: open_table(table_id): Opens a table and returns the table's metadata and access handle.

[0060] create_table(schema): Creates a new table based on the given table schema.

[0061] `table_scan(table_handle, predicate):` Creates a scanner on the specified table that can be filtered based on a predicate.

[0062] index_scan(index_handle, key_range): Creates a scanner at the specified index and scans based on a range of key values.

[0063] insert_record(table_handle, record): Inserts a record.

[0064] update_record(table_handle, old_record, new_record): Updates one record.

[0065] delete_record(table_handle, record): Deletes a record.

[0066] start_transaction(isolation_level): Starts a transaction.

[0067] commit_transaction(transaction_id): Commits the transaction.

[0068] rollback_transaction(transaction_id): Rolls back the transaction.

[0069] In some specific embodiments, the interfaces are protocol-agnostic, meaning they do not care which database protocol the upper layer uses for the query, but only care about the logical operations on the data.

[0070] In some specific embodiments, the storage structure of the unified storage engine layer 105 is as follows: Data is managed in units of pages, with each page having a fixed size. A page is the basic unit for transferring data between disk and memory. A tablespace is the logical storage unit of a table; a tablespace contains multiple data files, and each data file consists of multiple pages.

[0071] In some specific embodiments, transaction and concurrency control in the unified storage engine layer 105 is implemented in the following manner: Multi-Version Concurrency Control (MVCC) is used to achieve non-blocking read and write operations. Each transaction is assigned a unique transaction ID (XID) at the beginning. Each row of records has multiple versions, and each version records the transaction ID that created it and the transaction ID that deleted it.

[0072] Snapshot isolation ensures transaction isolation. A transaction can only see the version of data that was committed before it began.

[0073] In some specific embodiments, the unified storage engine layer 105 includes index management. Specifically, it supports various index types, the most commonly used being B+ tree indexes. B+ tree index keys can be single-column or multi-column, supporting equality queries and range queries. Like the data, indexes are stored in pages, and a dedicated buffer caches index pages.

[0074] In some specific embodiments, the unified storage engine layer 105 includes buffer management: pages in the buffer are managed using the LRU algorithm or a variant thereof. When data needs to be read, the buffer is checked first; if a match is found, the data is used directly; otherwise, it is read from the disk and placed into the buffer. Dirty pages that have been modified but not written back to disk are periodically flushed back to disk by a background thread, or flushed according to a checkpointing mechanism.

[0075] In some specific embodiments, in the unified storage engine layer 105, logging and recovery include using a write-ahead log (WAL) mechanism, meaning that any modification to a data page must first be written to the log before being written to the data page. This ensures that committed transactions can be redone and uncommitted transactions can be rolled back during fault recovery. Optionally, the log records in the unified storage engine layer 105 include: transaction start, insert, update, delete, commit, rollback, etc.

[0076] Optionally, the unified storage engine layer 105 can be configured via configuration files or management commands, for example: Set the data directory: data_directory = ' / var / lib / database' Set the buffer size: buffer_pool_size = 16GB Set the log file size: log_file_size = 1GB Set the concurrency control parameter: max_transactions = 1000 Administrators can also dynamically adjust some parameters using commands, for example: Adjust buffer size SET GLOBAL buffer_pool_size = 32GB; Adjust log level SET GLOBAL log_level = 'INFO'; In traditional multi-protocol solutions, each protocol may connect to an independent database instance, and each instance has its own storage engine, with no data sharing. This solution, however, uses a unified storage engine layer to provide a shared storage backend for all protocols, ensuring data consistency and eliminating the overhead of data replication.

[0077] The unified storage engine layer 105 proposed in this invention provides a unified, protocol-independent storage interface and integrates core functions such as transaction management, concurrency control, indexing, buffering, and logging, offering efficient, consistent, and reliable data persistence services to the upper multi-protocol processing layer. This is the cornerstone for the entire kernel-level multi-protocol database system to achieve high performance and high compatibility.

[0078] Figure 2 for Figure 1 A schematic diagram of the structure of a specific embodiment 103A of the unified semantic core layer 103. (See attached diagram.) Figure 2 As shown, a specific embodiment 103A of the unified semantic core layer 103 includes an SQL dialect normalizer 3A1 and a type system coordinator 3A2.

[0079] Optionally, the SQL dialect normalizer 3A1 is used to rewrite SQL syntax trees of different protocols into unified relational algebra expressions. The specific operation process is as follows: It accepts an abstract syntax tree (AST) with protocol labels. For example, the AST structures of `SELECT * FROM t LIMIT 10 OFFSET 20` for the MySQL client and `SELECT * FROM t LIMIT 20 OFFSET 10` for the PostgreSQL client are different. The normalizer internally maintains a declarative rewrite rule base. It loads the corresponding rule set based on the protocol label of the command object and iterates and transforms the AST.

[0080] Example rule: Identify the LIMIT offset, count node pattern in the MySQL AST and rewrite it as a standard OFFSET offset LIMIT count node.

[0081] Ultimately, the two SQL statements with different syntaxes were rewritten into the same internal structure: a relational algebra tree containing Projection (selecting all columns), TableScan (scanning table t), and Limit operators with offset and count parameters.

[0082] The core technology of the SQL dialect normalizer 3A1 lies in semantically equivalent syntax rewriting, rather than text replacement. It understands the semantic equivalence of different syntax structures such as LIMIT, TOP, and ROWNUM in pagination functionality and normalizes them through rules. The rule base supports protocol version management, ensuring precise compatibility with specific version syntax.

[0083] Existing database proxies typically perform SQL translation at the string level, which is superficial, error-prone, and unable to handle complex nested cases. The AST-level rewriting solution of this invention is based on a complete understanding of the syntactic structure, ensuring the accuracy and semantic integrity of the conversion.

[0084] Optionally, the type system coordinator 3A2 is used to resolve inconsistencies in data type definitions across different protocols based on a predefined type mapping matrix. The specific operation process includes: Access a scalable type mapping matrix configuration that defines a two-way mapping between data types of different protocols and the internal unified type system, and includes the necessary conversion functions.

[0085] When processing literals or metadata in SQL, the Type System Coordinator 3A2 looks up mapping rules based on the protocol type of the current session.

[0086] For example, when a MySQL client sends a date value '0000-00-00', the type system coordinator 3A2 knows, based on the mapping rules, that MySQL allows this "zero-value date," but the internal unified type system does not. The type system coordinator 3A2 will trigger a conversion: it may convert it to a valid internal date null value and mark it as "derived from MySQL zero value" so that it can be correctly restored when the result is returned.

[0087] The type system coordinator 3A2 in this invention is key to achieving faithful conversion of type semantics. It not only handles name mapping, but also the differences in value range, precision, special values ​​and behavior, ensuring that data does not lose semantics when read and written across protocols.

[0088] Existing agents often ignore deep type semantics, leading to loss of precision. For example, simply mapping SQL Server's DATETIME2(7) to TIMESTAMP may result in incorrect value ranges. The solution of this invention achieves deep integration of data types at the system level through predefined and configurable fine-grained mapping matrices.

[0089] Figure 3 for Figure 1 A schematic diagram of the structure of a specific embodiment 103B of the unified semantic core layer 103. (See attached diagram.) Figure 3 As shown, a specific embodiment 103B of the unified semantic core layer 103 includes an SQL dialect normalizer 3B1, a type system coordinator 3B2, a transaction behavior coordinator 3B3, and an error mapping coordinator 3B4. Among them, the SQL dialect normalizer 3B1, the type system coordinator 3B2, and... Figure 2 The SQL dialect normalizer 3A1 and type system coordinator 3A2 in the Chinese embodiment 3A1 are the same, and will not be described again here.

[0090] Optionally, the transaction behavior coordinator 3B3 is used to uniformly manage the differences in transaction behavior between different protocols. The specific operation process includes: The transaction behavior coordinator 3B3 maintains a unified transaction state machine and interacts closely with the context of each session.

[0091] When commands such as BEGIN, START TRANSACTION, and SET autocommit=0 are received, the transaction behavior coordinator 3B3 will drive these commands into specific state transitions of the unified state machine according to the current protocol specification.

[0092] For example, for protocols that have auto-commit enabled by default, the transaction behavior coordinator 3B3 may implicitly trigger the start of an internal transaction when it receives the first data modification statement, in order to meet the expectations of the protocol users.

[0093] Optionally, the transaction behavior coordinator 3B3 is also responsible for managing the namespace translation of savepoints and mapping protocol-specific isolation levels (such as MySQL's REPEATABLE READ) to the isolation levels implemented internally by the system.

[0094] Existing proxies often pass through transactions incompletely or only partially simulate them, which can easily lead to inconsistent transaction behavior across protocols. This invention provides a unified and consistent transaction model for all protocols through a centralized transaction coordinator. Simultaneously, it abstracts and normalizes protocol-related transaction semantics into a set of internal atomic states and operations, ensuring that the client's view and guarantees of data consistency are the same regardless of the protocol used.

[0095] Optionally, the error mapping coordinator 3B4 is used to map uniform errors generated during internal execution back to the specific protocol error codes and message formats expected by the client. The specific operation process includes: A hierarchical error code mapping table is configured. When an error occurs elsewhere in the kernel, an internal error object is generated containing the standard error code, error message, and severity level. On the result return path, the error mapping coordinator 3B4 is invoked to look up the mapping table according to the session protocol of the original command that caused the error.

[0096] The mapping table converts internal standard error codes into error codes specific to the target protocol and generates error messages according to the format template required by that protocol. For example, it converts the internal "unique key conflict" error into MySQL's 1062 (ER_DUP_ENTRY) or PostgreSQL's 23505 (unique_violation).

[0097] Existing proxy solutions often return errors from the proxy itself or fail to correctly translate the underlying database, thus breaking the client's error handling logic. According to... Figure 3 The embodiment shown in this invention integrates error semantic conversion at the architectural level, which is a key step in achieving transparent compatibility with applications. It achieves protocol transparency and client compatibility for errors, ensuring that specific database error codes and message formats relied upon by the application are preserved, allowing applications to migrate without modifying their error handling logic.

[0098] Figure 4 for Figure 1 A schematic diagram of a specific embodiment of the protocol-independent core processing layer 104. (See attached diagram.) Figure 4 As shown, the protocol-independent core processing layer 104 includes a DAG-based query optimizer 1041 and a global DAG cache 1042.

[0099] The DAG-based query optimizer 1041 is used to convert uniform relational algebra expressions into directed acyclic graphs and compute their semantic hashes.

[0100] Optionally, the relational algebra expressions constructed by the unified semantic core layer 103 are typically represented in a tree structure, where each node represents a relational algebra operator and child nodes represent the inputs of the operators. The goal of the DAG-based query optimizer 1041 is to transform this tree into a directed acyclic graph, allowing identical subexpressions to be shared, thereby avoiding redundant computation.

[0101] Specifically, the process by which the DAG-based query optimizer 1041 transforms a relational algebra expression into a directed acyclic graph includes: (1) Parsing the relational algebra expression tree: The relational algebra expressions received from the unified semantic core layer 103 are abstract syntax trees (ASTs). Each node contains operator type and attribute information, for example: Leaf node: TableScan, with parameters being the table name and possible filtering conditions.

[0102] Internal nodes: Select, Project, Join, etc.

[0103] (2) Constructing the nodes of the DAG: Traverse the relational algebra expression tree and create a DAG node for each unique subexpression. Here, "unique" means that the structure of the subexpression is exactly the same as the operator type and the child node. To achieve sharing, a hash table is used to record the subexpressions that have been created.

[0104] Starting from the leaf nodes, each table scan node creates a unique identifier based on the table name and filtering conditions, and serves as the leaf node of the DAG.

[0105] For internal nodes, their child nodes are processed recursively first. Then, an identifier for the current node is created based on the current operator type and the child nodes that have already been processed. If a node with the same identifier already exists in the hash table, that node is reused directly; otherwise, a new node is created and added to the hash table.

[0106] (3) Establishing the edges of the DAG: When creating each DAG node, the child nodes of that node are recorded at the same time, thus forming directed edges. Since the hash table is used to ensure that nodes with the same subexpression are unique, multiple parent nodes can point to the same child node, forming a graph structure.

[0107] (4) Eliminate repeated subexpressions: Through the above process, repeated subexpressions in the original tree are merged, thus forming a directed acyclic graph (DAG). For example, if the same table scan appears multiple times in the tree, there will only be one node in the DAG, but it will be referenced by multiple parent nodes.

[0108] Optionally, after converting the uniform relational algebra expression into a directed acyclic graph, the DAG-based query optimizer 1041 calculates its semantic hash to generate a unique, fixed-length identifier for the query semantics represented by the DAG.

[0109] Optionally, this hash value should depend only on the semantics of the query, and not on irrelevant representation details (such as variable names, constant values, etc.). Therefore, the DAG needs to be normalized before calculating the hash, specifically including: (1) Constant parameterization: Replace all constant values ​​(such as numbers and strings) in the query with uniform placeholders (e.g., represented by $1, $2, etc.). For example, the queries SELECT * FROM users WHERE id = 123 and SELECT * FROM users WHERE id = 456 will both become SELECT * FROM users WHERE id = $1 after normalization, thus having the same semantic hash.

[0110] (2) Elimination of column and table aliases: Replace all column and table references with their original identifiers. For example, if a table alias is used in a query, it is replaced with the actual table name.

[0111] (3) Expression standardization: Standardize and rearrange mathematical expressions, logical expressions, etc. For example, consider a>5AND b<10 and b<10AND a>5 as the same.

[0112] (4) Eliminate redundant nodes: Eliminate some nodes that do not affect semantics, such as redundant projection operations.

[0113] Optionally, in the implementation of the DAG-based query optimizer 1041 for calculating hash values, the normalized DAG is serialized, and then a cryptographic hash function is applied to calculate the hash value. The serialization process needs to ensure that the same DAG structure always produces the same byte sequence. The following method is used: Perform topological sorting on the DAG to obtain a sequence of nodes; for each node, serialize its operator type, normalized attributes, and child node indices into bytes; input the entire sequence into a hash function.

[0114] Optionally, the semantic hash value calculated by the DAG-based query optimizer 1041 will be used as the identifier for the query and as the key in the global DAG cache. When subsequent queries calculate the same hash value after normalization, the execution plan can be directly retrieved from the cache.

[0115] For example, in some specific embodiments, suppose there are two queries: Query 1 from the MySQL client: SELECT name FROM users WHERE age > 18 Query 2 from the PostgreSQL client: SELECT name FROM users WHERE age > 18 After processing by the unified semantic core layer 103, their relational algebra expressions are completely identical. In the DAG-based query optimizer 1041, they are converted into the same DAG and the same semantic hash is calculated. Therefore, once query 1 is optimized and cached, query 2 can directly use the cached execution plan.

[0116] In some specific embodiments, the global DAG cache 1042 is used to cache execution plans or serialized result packets using semantic hashes as keys. Specifically, the global DAG cache 1042 is configured to share the same cache entry when queries from different protocol clients have the same semantic hash.

[0117] Optionally, the global DAG cache 1042 is an in-memory, high-concurrency caching system using semantic hashes as keys. It stores optimized execution plans, represented as sequences of physical operators in DAG form, and, in some cases, serialized result packets. Its core objective is to enable cross-protocol and cross-session query execution plan reuse, and even result reuse, thereby significantly improving overall system performance.

[0118] In some specific embodiments, the data structure and storage content of the global DAG cache 1042 cache include: (1) Cache entry structure: Key: A semantic hash value calculated by the DAG-based query optimizer 1041, such as a 256-bit SHA-256 hash value.

[0119] Value: Contains two parts: Execution Plan: A serialized, directly executable Directed Acyclic Graph (DAG) of physical operators. The operators in this DAG have been fully optimized and contain all necessary metadata, such as input / output patterns and resource requirement estimates.

[0120] Optional result packet: For some simple or frequently executed queries, the complete serialized result set can be cached. The result packet is stored in a protocol-independent binary format, but it will be converted by a protocol adaptation layer before being returned to the client.

[0121] Metadata: Creation time, last access time, number of accesses.

[0122] Computational cost: The execution cost of the query estimated by the optimizer, used for cache eviction policies.

[0123] Dependencies: Record the data objects (such as tables, views, indexes, etc.) that the plan depends on and their version numbers, for cache invalidation.

[0124] (2) Cache storage media and organization: The global DAG cache 1042 primarily resides in memory to ensure microsecond-level access speeds. To support a large number of cached entries, a sharded hash table design can be adopted, with sharding based on the first few bits of the semantic hash. Each shard is protected by an independent lock to reduce concurrent conflicts.

[0125] For very large execution plans or result sets, the system can adopt a tiered caching strategy: swap some infrequently accessed cache entries to disk, but retain their metadata in memory to quickly determine whether a cache exists.

[0126] Optionally, in some specific embodiments, the workflow of the global DAG cache 1042 includes: (1) Cache query process: After the DAG-based query optimizer 1041 calculates the semantic hash for a query, the optimizer will first query the global DAG cache. The query process is as follows: The corresponding cache fragment is located based on the semantic hash value.

[0127] Search for the entry corresponding to the key within the shard.

[0128] If found, check the validity of the cached entry by comparing the version number in the dependency with the version number of the current data object. If valid, directly return the execution plan or result package from the cached entry; if invalid, delete the entry and proceed to the cache miss process.

[0129] If not found, proceed with the cache miss process.

[0130] (2) Cache misses and padding: When a cache miss occurs, the optimizer performs a full query optimization process to generate an optimal physical execution plan. The optimizer then creates a new cache entry and associates the plan with a semantic hash. Before storing the plan in the cache, the system evaluates whether the plan is worth caching. In some specific embodiments, the evaluation strategy may be based on: Cost threshold: Only plans with optimization costs exceeding a certain threshold are cached to avoid caching overly simple queries; Frequency prediction: If the system predicts that a query is likely to be executed repeatedly, it is cached. Once caching is decided, the system records the data objects that the plan depends on (such as the users table) and their current version numbers, and then inserts the entries into the cache.

[0131] Optionally, the core innovation of the DAG-based query optimizer 1041 in this invention lies in the implementation of cross-protocol sharing, the key of which is: (1) Uniformity of semantic hashing: Regardless of the specific protocol from which the query comes, as long as it is processed by the unified semantic core layer 103, it will be converted into the same relational algebra expression. Therefore, even if the surface text is different, as long as the semantics of the two queries are the same, they will get the same semantic hash. In this way, the same semantic query issued by clients of different protocols will hit the same cache entry.

[0132] (2) Protocol independence of the execution plan: The execution plan in the cache is stored in the form of a protocol-independent physical operator DAG. These operators do not contain any protocol-related features and can therefore be reused by clients of any protocol. When the execution plan is retrieved for execution, the execution engine runs it in a uniform manner and produces results in a uniform format.

[0133] (3) Protocol adaptation of result packets: If the cached result packets are stored in an internally unified binary format, when the cache is hit, the unified result is converted into the protocol format expected by the client through the error mapping coordinator and protocol parsing and session management layer 102, according to the current client protocol.

[0134] For example, in some specific embodiments: A MySQL client sends: SELECT id, name FROM users WHERE age > 18 LIMIT 10 A PostgreSQL client sends: SELECT id, name FROM users WHERE age > 18 LIMIT 10 After being transformed by the unified semantic core layer, both generate the same relational algebra expression, and thus the semantic hashes calculated are the same.

[0135] Assuming the MySQL client executes first, the optimizer generates a plan and caches it.

[0136] When the PostgreSQL client executes, the semantic hash hits the cache, and the cached execution plan is used directly. After execution, the result is converted to PostgreSQL format by the protocol adaptation layer and returned.

[0137] The Global DAG Cache 1042 significantly improves the performance of multi-protocol database systems by caching execution plans and even result packets using semantic hashes as keys, combined with cross-protocol sharing, intelligent management, and invalidation mechanisms. This allows frequently executed queries to avoid redundant optimization or even repeated execution, while ensuring a consistent high-performance experience for clients across different protocols. This is one of the core innovations of this solution in performance optimization.

[0138] Figure 5 A method based on the present invention Figure 1-4 A flowchart illustrating an embodiment 2000 of a data communication method supporting kernel-level multi-protocol database systems. (See also...) Figure 5 As shown, Example 2000 includes steps S1-S6.

[0139] In step S1, the multi-protocol listening and routing layer directly routes the client connection to the corresponding protocol resolver based on the target port number. Step S1 utilizes the strong agreement between the target port number and the application layer protocol in the TCP / IP protocol stack, ensuring that the protocol identity is determined after the transport layer connection is established, without waiting for application layer data.

[0140] Optionally, step S1 includes the following specific operational steps: (1) The system calls the getsockname() function, passes in the client connection socket, and obtains the local port number bound to it.

[0141] (2) Based on this port number, query a static port-protocol mapping table in memory and instantly parse out the corresponding protocol type identifier (such as PROTO_MYSQL).

[0142] (3) Based on the protocol identifier, retrieve an idle parser instance from the pre-allocated protocol parser resource pool.

[0143] (4) Bind this connection socket, protocol identifier and parser instance, and dispatch this connection task to the worker thread queue responsible for the protocol.

[0144] In step S1 of this invention, instantaneous routing based on transport layer attributes is achieved: compared to traditional proxies / gateways that must read and fully parse the application layer handshake packet before identifying the protocol, this invention completes routing decisions with zero millisecond wait and zero application layer data reading after connection establishment. According to step S1, the following are achieved: 1. Extremely low connection establishment latency: reducing the tens of milliseconds of latency caused by parsing handshake packets in traditional solutions to the microsecond level; 2. Significantly reduced system overhead: avoiding the CPU and memory resources required to allocate, read, and parse handshake packets for each new connection; 3. Enhanced architectural determinism: the routing logic is simple and deterministic, without the complexity and failure risk of dynamic protocol probing.

[0145] In step S2, the client request is parsed through protocol parsing and session management layer, and the session context is established and maintained.

[0146] Optionally, in step S2, the client connection socket bound to the resolver and the raw binary network data stream read from the socket are processed to finally obtain: (1) A structured command object containing command type (query, prepare, submit, etc.), parameterized SQL template, list of bound parameter values, etc.; (2) A session context object that is fully synchronized with the current state of the connection.

[0147] Specifically, the operation process of step S2 includes: (1) Stream parsing: The parser reads data from the receive buffer of the connection socket. It identifies frame boundaries according to the protocol specification and only begins parsing the content after confirming that a complete protocol frame has been received.

[0148] (2) State machine driven: The parser maintains the connection state internally. Based on the current state, it knows the type of command to be received and calls the corresponding decoding logic.

[0149] (3) Structured extraction: Decode the frame content and extract the core elements. For example, extract the SQL text string from the COM_QUERY frame; extract the preprocessed statement ID and the bound binary parameter array from the COM_STMT_EXECUTE frame.

[0150] (4) Context Maintenance: During the resolution process, the session context object bound to this connection is updated synchronously. This object is a dynamic key-value store that records, for example, character_set_client (from the SET NAMES command), autocommit status, current transaction ID, and temporary prepared statement mapping table. The context persists throughout the connection's lifecycle and evolves with command execution.

[0151] In step S3, the parsed protocol-specific commands are converted into a unified protocol-independent representation within the system through a unified semantic core layer. Optionally, step S3 specifically includes converting the syntax trees of SQL statements from different protocols into unified relational algebra expressions through syntax tree rewriting techniques.

[0152] Specifically, in step S3, firstly, a syntax tree transformation is performed. The SQL dialect normalizer receives the command object and converts its SQL text into an abstract syntax tree. Then, based on the protocol identifier in the session context, the corresponding rewrite rule set is loaded; then, semantic coordination is performed, including: The type system coordinator intervenes, converting protocol-specific data type tags in the AST into internal uniform types based on a predefined type mapping matrix, and handling special values.

[0153] The transaction behavior coordinator processes transaction control commands, unifying the BEGIN / START TRANSACTION semantics of different protocols to the same entry point of the internal transaction state machine.

[0154] Finally, in step S3, the relational algebra is generated. After standardization and harmonization, the AST is converted into an expression tree or DAG composed of basic relational algebra operators.

[0155] In step S4, the protocol-independent representation is optimized and executed through the protocol-independent core processing layer. Optionally, the execution process of step S41 includes: calculating the semantic hash of the protocol-independent representation; querying the global cache; if a cache entry matching the semantic hash exists, the execution plan or result in the cache is used directly. Otherwise, a new execution plan is generated and executed, and the new execution plan is associated with the semantic hash and stored in the global cache.

[0156] In step S5, data is accessed through the unified storage engine layer. Optionally, the unified storage engine layer in step S5 provides a unified abstract interface to the upper layer, hiding the underlying details such as data storage format, transaction implementation, and persistence.

[0157] Specifically, step S5 includes the following operations: (1) The execution engine calls a unified interface. For example, index_lookup.

[0158] (2) The storage engine locates the data page through the buffer pool manager.

[0159] (3) The transaction manager determines the data version visible to the transaction based on the snapshot timestamp of the current transaction through the MVCC mechanism.

[0160] (4) Read or modify data, and ensure concurrent correctness and durability through lock manager and write-ahead log.

[0161] In step S6, the execution result is adapted to the protocol by the unified semantic core layer and then returned to the client.

[0162] Optionally, in step S6, based on the results generated by the internal execution and the session context of the original request, the results in the internal unified format are reverse-encoded and formatted according to the source protocol specification. The operation steps are as follows: (1) Error and status mapping: The error mapping coordinator converts the internal unified error code into client protocol-specific error codes and message formats.

[0163] (2) Data format conversion: The type system coordinator converts internal data values ​​into the encoding expected by the client.

[0164] (3) Protocol serialization: The protocol parser encodes the converted result according to the binary network packet format of the protocol.

[0165] (4) Network transmission: The encoded binary data packet is sent back to the client through the original connection socket.

[0166] Through the above process, step S6 finally outputs a binary network response packet that fully conforms to the client's expected format.

[0167] According to such Figure 5 The implementation method shown in this invention achieves a fundamental breakthrough in performance, compatibility, and consistency for multi-protocol database support. Its core effect lies in reconstructing the fragmented and high-overhead translation and forwarding chain of traditional external proxy schemes into efficient and unified semantic understanding and computation within the database kernel. Specifically, this method not only minimizes connection and parsing overhead through instantaneous port routing and native protocol parsing, but more importantly, it transforms all protocol queries into a unified relational algebra representation through a semantic unification layer. Furthermore, it innovatively utilizes a global cache based on semantic hashing to achieve cross-protocol and cross-session computing resource sharing, resulting in an order-of-magnitude improvement in overall system throughput and response speed. Simultaneously, the unified storage engine provides a single, strongly consistent data source for all protocols, while bidirectional protocol adaptation ensures transparent migration of client applications with zero modifications.

[0168] Figure 6 for Figure 5 A flowchart illustrating step S4 in embodiment 2000. (See attached diagram.) Figure 6 As shown, step S4 includes steps S41-S43.

[0169] In step S41, the semantic hash of the protocol-independent representation is calculated. Optionally, in step S41, by normalizing the logical structure of the query, surface differences that do not affect the semantics (such as literal constant values ​​and identifier aliases) are eliminated, so that queries with the same semantics will necessarily produce the same normalized structure, and then a unique fingerprint is generated by the cryptographic hash function.

[0170] Specifically, in some embodiments, the execution process of step S41 includes: (1) Normalization: Traverse the relational algebra DAG and perform: i) Constant parameterization: Replace all literal constants with generic placeholders (such as $1). ii) Structure normalization: Sort the operator subtrees according to defined rules.

[0171] (2) Serialization and hashing: The normalized DAG structure is serialized into a byte array in a defined order. This byte array is then input into a cryptographic hash function to generate a fixed-length semantic hash value.

[0172] In step S42, the global cache is queried. If a cache entry matching the semantic hash exists, the execution plan or result in the cache is used directly. Step S42 uses a globally shared concurrent hash table, with the semantic hash as the key, to cache expensive optimization results or computation results. Specifically, the execution process of step S42 includes: (1) accessing the global DAG cache with the semantic hash as the key; (2) if a match is found, checking the validity of the cache entry; for example, whether the dependent table data has been modified; (3) if valid, directly loading the serialized execution plan or protocol-independent result set data stored in the entry.

[0173] In step S43, otherwise, a new execution plan is generated and executed, and the new execution plan is associated with the semantic hash and stored in the global cache. Optionally, step S43 implements cost-based query optimization, converting the logical algebraic expression into an optimal physical execution plan, and storing it in association with the semantic hash for reuse.

[0174] Specifically, in some embodiments, the implementation process of step S43 includes: (1) Optimization: The query optimizer searches for and generates the optimal physical execution plan based on relational algebra, data statistics, and cost models. For example, it selects the hash join algorithm and uses [index A] for lookup.

[0175] (2) Execution: The execution engine schedules the physical plan, retrieves data from the storage engine, and calculates the final result.

[0176] (3) Evaluation and caching: The system evaluates the optimization cost and result set size of the query. If it meets the caching strategy, the execution plan and / or protocol-independent result data will be associated with semantic hash and data dependency version information and inserted as a new entry into the global cache.

[0177] According to such Figure 6 The technical effects achieved by this invention, as illustrated in the implementation method, are mainly reflected in three aspects: First, by calculating a semantic hash based on the query's logical semantics rather than the surface text, it accurately identifies queries from different database protocols with varying textual expressions but identical semantics, laying the foundation for intelligent caching. Second, the global DAG cache based on this hash key enables the reuse of optimization effects: once a query is optimized and executed for the first time, its optimal execution plan or result is cached, and any subsequent queries with the same semantics can be reused instantly, completely skipping the time-consuming query optimization and repetitive calculation process. Finally, relying on powerful self-learning and adaptive capabilities, as the system runs, the response latency of high-frequency queries decreases dramatically, and resource utilization is significantly improved. Overall, Figure 6 The implementation shown breaks down the barriers of traditional database caching isolation by connection or protocol, enabling the sharing and reuse of computing resources globally.

[0178] The embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of the present invention, its specific implementation methods, and its application scope, are all within the scope of protection of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A kernel-level multi-protocol database system support, characterized by, Comprise: A multi-protocol listening and routing layer, for concurrently listening to client connections on multiple predetermined ports, and directly routing a client connection to a corresponding protocol parser based on the target port number used when the connection is established; A protocol parsing and session management layer, communicatively connected with the multi-protocol listening and routing layer, comprising multiple protocol parsers, for deserializing received protocol-specific binary data streams into structured SQL commands and control instructions, and maintaining a session context for each client connection containing its protocol type; A unified semantic core layer, communicatively connected with the protocol parsing and session management layer, for converting SQL commands and control instructions from different protocols into a unified protocol-agnostic representation within the system through semantic reconciliation; A protocol-agnostic core processing layer, communicatively connected with the unified semantic core layer, for performing query optimization and execution operations on the unified protocol-agnostic representation; A unified storage engine layer, communicatively connected with the protocol-agnostic core processing layer, for providing persistent storage and management of data.

2. The system of claim 1, wherein, The multi-protocol listening and routing layer does not parse application layer handshake messages when a network connection is established, and only completes instantaneous routing based on the target port number.

3. The system of claim 1 or 2, wherein, The session context maintained by the protocol parsing and session management layer includes at least one of the following: character set, time zone, transaction state.

4. The system of claim 1, wherein, The unified semantic core layer comprises: A SQL dialect standardizer, for rewriting SQL syntax trees of different protocols into a unified relational algebra expression; A type system reconciler, for resolving inconsistencies in data type definitions of different protocols based on a predefined type mapping matrix.

5. The system of claim 4, wherein, The unified semantic core layer further comprises: A transaction behavior reconciler, for uniformly managing differences in transaction behavior of different protocols; An error mapping reconciler, for mapping unified errors generated during internal execution back to specific protocol error codes and message formats expected by clients.

6. The system of claim 1, wherein, The protocol-agnostic core processing layer comprises: A DAG-ized query optimizer, for converting the unified relational algebra expression into a directed acyclic graph and calculating its semantic hash; A global DAG cache, for caching execution plans or serialized result packages using the semantic hash as a key.

7. The system of claim 6, wherein, The global DAG cache is configured to share the same cache entry when queries from different protocol clients have the same semantic hash.

8. A data communication method supporting a kernel-level multi-protocol database system according to any one of claims 1 to 7, characterized by, Comprise the following steps: S1. Directly route a client connection to a corresponding protocol parser based on its target port number through the multi-protocol listening and routing layer; S2. Analyze client requests, establish and maintain session contexts through the protocol parsing and session management layer; S3. Convert protocol-specific commands after analysis into a unified protocol-agnostic representation within the system through the unified semantic core layer; S4. Optimize and execute the protocol-agnostic representation through the protocol-agnostic core processing layer; S5. Access data through the unified storage engine layer; S6. Return execution results to clients after protocol adaptation through the unified semantic core layer.

9. The method of claim 8, wherein, The step S3 comprises: The syntax trees of different protocol SQL statements are converted into unified relational algebraic expressions through syntax tree rewriting technology.

10. The method according to claim 8 or 9, characterized in that, The step S4 comprises: calculating semantic hash of the protocol-independent representation; querying a global cache, if there is a cache entry matching the semantic hash, directly using the execution plan or result in the cache; otherwise, generating a new execution plan and executing, and meanwhile associating the new execution plan with the semantic hash and storing into the global cache.

Images