Compatible system and compatible control method of cross-time-sequence database

Abstract

The invention provides a compatible system and a compatible control method of a cross-time-sequence database, and relates to the technical field of data processing, and the compatible system comprises a service kernel management module which is used for receiving preset source configuration information, creating corresponding kernel service processes according to the preset source configuration information, and controlling the start and stop of the kernel service processes, the kernel service process is used for connecting a corresponding time sequence database; the proxy module is used for acquiring request information of a client; and the data source driving module is used for accessing the time sequence database through the corresponding kernel service according to the request information and receiving a query result of the time sequence database. According to the method, efficient, flexible and compatible data access of the cross-time-sequence database is achieved, a developer only needs to achieve an interface once, the system can automatically process interaction of different types of databases, the requirement for writing specific interface codes for each type of database is reduced, and therefore the development cost of an application program is reduced.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a cross-time series database compatibility system and a compatibility control method. Background Art

[0002] With the rapid development of fields such as the Internet of Things (IoT), industrial automation, and big data analysis, time series database (TSDB) has become increasingly important in data storage and management.

[0003] Time series databases are specifically designed to process time series data, which is usually indexed by timestamps and has a fixed frequency and order. However, different time series database systems use their own unique data models, API interfaces, and storage mechanisms, which causes compatibility issues when applications access and operate time series databases.

[0004] In order to solve the above problems, developers usually need to write specific interface codes for each type of time series database, that is, they need to implement independent interfaces for each database type (such as relational databases, non-relational databases, etc.). However, this not only increases the development cost of upper-level applications, but also has poor scalability and increases the difficulty of subsequent maintenance. Summary of the invention

[0005] The problem solved by the present invention is one or more of the above-mentioned problems in the prior art.

[0006] In order to solve the above problems, the present invention provides a cross-time series database compatible system and a compatible control method.

[0007] In a first aspect, the present invention provides a cross-time series database compatibility system, including:

[0008] A service kernel management module, used to receive preset source configuration information, create corresponding kernel service processes according to each preset source configuration information, and control the start and stop of each kernel service process, wherein one kernel service process is used to connect to a corresponding time series database;

[0009] Proxy module, used to obtain client request information;

[0010] The data source driver module is used to access the corresponding time series database through the corresponding kernel service process according to the request information, and receive the query result of the time series database.

[0011] Optionally, the cross-time series database compatible system further includes a front-end graphics service module, and the front-end graphics service module is used to receive a creation request from a user, and send the creation request and the corresponding preset source configuration information to the service kernel management module.

[0012] Optionally, the service kernel management module is specifically used for:

[0013] Creating the corresponding kernel service process according to the creation request and the corresponding preset source configuration information, and returning the creation process to the front-end graphics service module;

[0014] When the kernel service process is successfully created, start and stop operations are performed on each kernel service process according to the received start request, and each start result and corresponding connection status are returned to the front-end graphics service module.

[0015] Optionally, the data source driver module further includes a plurality of sub-driver modules, and the data source driver module is specifically used for:

[0016] The request information is converted to obtain corresponding request format information, and according to the corresponding request format information, a connection is established with the corresponding time series database through the sub-driver module corresponding to the kernel service process to realize data access and transmission of the time series database, and receive the query results fed back by the time series database.

[0017] Optionally, the cross-time series database compatible system further includes a data kernel service module, and the data kernel service module is used to forward the request information to the data source driver module.

[0018] Optionally, the preset source configuration information includes the name of the data source, the type of the data source, the IP address and port number of the data source, the port number of the client connection, and the protocol used by the client connection.

[0019] Optionally, the cross-time series database compatible system further includes a front-end data cache module, and the front-end data cache module is used to cache historical query results of each of the time series databases.

[0020] Optionally, the front-end data cache module is further used to check whether there is a corresponding query result in the historical query results according to the request information, and if so, return the corresponding query result to the client.

[0021] Optionally, the front-end graphic service module is also used to visualize user operations.

[0022] In a second aspect, the present invention provides a cross-time series database compatibility control method, which is applied to the cross-time series database compatibility system. The cross-time series database compatibility control method includes:

[0023] Obtaining preset source configuration information, and creating corresponding kernel service processes according to each of the preset source configuration information, and controlling the start and stop of each of the kernel service processes, wherein the kernel service processes are used to connect to the corresponding time series database;

[0024] Get the client's request information;

[0025] The corresponding kernel service process is determined according to the request information, and each time series database is called through the corresponding kernel service, and a query result of the time series database is received.

[0026] The cross-time series database compatible system and compatible control method of the present invention have the following beneficial effects: the cross-time series database compatible system is mainly composed of three core modules: a service kernel management module, a proxy module and a data source driver module. The service kernel management module is mainly responsible for receiving preset source configuration information, which usually includes database type, connection address, authentication information, etc. According to different database requirements, the module will generate corresponding kernel service processes. These processes are respectively connected to specific time series databases to process subsequent database operations. In addition, the service kernel management module can also start and stop each kernel service process to ensure that the system can flexibly respond to load changes. For example, service processes can be added to share requests during peak hours, and unnecessary processes can be stopped to save resources. The proxy module is responsible for receiving request information from the client and acts as an intermediary between the client and the backend database. The proxy module forwards the request information to the appropriate kernel service process to ensure that the request is accurately directed to the corresponding time series database. In this way, the client program does not need to directly access the underlying database. The data source driver module sends a query request to the corresponding time series database through the kernel service process, interacts with the database, and receives the returned query results. The returned query results will be passed back to the proxy module, which will eventually respond to the client's request, ensuring that the client can obtain the required data.

[0027] Through the compatible system of the present invention, the user can create a corresponding kernel service process through the service kernel management module, and based on the request information of the client, connect the corresponding time series database through the data source driver module, and receive the query results of the time series database, that is, realize seamless switching between different time series databases, and reduce the compatibility problems caused by different database types. And the developer only needs to call a unified interface, the system can realize interaction with different types of databases, reduce the need to write specific interface codes for each database, thereby reducing the development cost of the application. At the same time, because the service kernel management module can dynamically start and stop the process, the system can adjust the performance according to real-time needs, and has good flexibility. If it is necessary to support new databases in the future, it is only necessary to simply configure the source information without reconstructing the client application. And through clear module division of labor and responsibility, each part of the system is easier to test and maintain. The improvement or failure of any module will not have a significant impact on other modules, ensuring the overall stability of the system. And the client accesses data through a unified interface, making the user experience more friendly, reducing the learning cost and operation complexity.

[0028] In general, this cross-time series database compatible system can effectively integrate and manage different types of time series databases, provide stable and flexible services, and at the same time improve the efficiency of development and maintenance, bringing convenience to users. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is one of the structural schematic diagrams of a cross-time series database compatible system according to an embodiment of the present invention;

[0030] Figure 2 A schematic diagram of creating a kernel service process according to an embodiment of the present invention;

[0031] Figure 3 This is a second structural diagram of a cross-time series database compatible system according to an embodiment of the present invention;

[0032] Figure 4 A schematic diagram of the relationship between a service kernel management module and multiple kernel services according to an embodiment of the present invention;

[0033] Figure 5 A schematic diagram of a kernel service according to an embodiment of the present invention;

[0034] Figure 6 A schematic diagram of a test page simulating a client connection request according to an embodiment of the present invention;

[0035] Figure 7 The figure is a flowchart of a cross-time series database compatibility control method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. Although certain embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be interpreted as being limited to the embodiments described herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the drawings and embodiments of the present invention are only for exemplary purposes and are not intended to limit the scope of protection of the present invention.

[0037] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0038] The term "including" and its variations used in this document are open inclusions, that is, "including but not limited to"; the term "based on" means "based at least in part on"; the term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one other embodiment"; the term "some embodiments" means "at least some embodiments"; the term "optionally" means "optional embodiments". The relevant definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc. mentioned in the present invention are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0039] It should be noted that the modifications of "one" and "plurality" mentioned in the present invention are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0040] The names of the messages or information exchanged between multiple devices in the embodiments of the present invention are only used for illustrative purposes, and are not used to limit the scope of these messages or information.

[0041] like Figure 1 As shown, an embodiment of the present invention provides a cross-time series database compatible system, including:

[0042] The service kernel management module is used to receive preset source configuration information, create corresponding kernel service processes according to each preset source configuration information, and control the start and stop of each kernel service process. One kernel service process is used to connect to a corresponding time series database.

[0043] Specifically, the service kernel management module is the core component of the cross-time series database compatible system, responsible for receiving configuration information, creating and managing kernel service processes. The received preset source configuration information usually contains parameters related to various time series databases, such as: Figure 2 As shown in the figure, the data source information (preset source configuration information) includes database type (such as PI, InfluxDB, Prometheus, etc.), database address and port, protocol, authentication information (such as user name and password), connection timeout setting, data source name, etc. The service kernel management module receives this configuration information through the internal interface or configuration file. The received information will be parsed and stored in the internal structure of the system for subsequent use.

[0044] Based on the received configuration information, the service kernel management module will generate a kernel service process for each independent time series database source. Each process can run independently and handle requests from its corresponding time series database. When the process is initialized, the kernel service process may try to establish a connection with the corresponding time series database to verify the validity of the configuration information. The service kernel management module can also dynamically adjust the status of the kernel service process according to the system load and demand.

[0045] For example, when the system detects a traffic peak, it can start more service processes to handle requests. When traffic decreases, some no longer needed service processes are automatically stopped to save resources. The module also continuously monitors the running status of each kernel service process to ensure that all processes are working properly. If a process fails, the module can automatically restart the process or record the process status through logs for subsequent analysis and maintenance.

[0046] Each kernel service process maintains a persistent connection with its corresponding time series database to quickly respond to requests from clients.

[0047] When the kernel service process is created, it initializes the connection pool or establishes a direct connection to optimize the performance of subsequent database operations. At the same time, the service kernel management module is responsible for managing these connections, including reconnection mechanisms and connection health checks.

[0048] In summary, the service kernel management module ensures that the system can interact with multiple time series databases efficiently and stably by receiving necessary configuration information, creating and managing kernel service processes, and controlling the running status of these processes. This modular design not only improves the flexibility and scalability of the system, but also ensures efficient use of resources and provides stable service support for clients.

[0049] Proxy module, used to obtain client request information;

[0050] Specifically, the proxy module mainly obtains the client's request information and forwards it to the corresponding kernel service process. The proxy module receives requests from the client application (client) through the API interface or network socket. The client can be a web application, mobile application or other backend service, and the request sent may be to query data, write data or perform other operations.

[0051] After receiving the request, the proxy module will parse it. For example, it will identify the operation that the client wants to perform (such as query, write, delete, etc.). It will determine the target data source and operation type based on the URL path of the request. It will extract the necessary information (such as time range, data point, etc.) from the request body and query parameters.

[0052] In some embodiments, the proxy module is hosted in the process space of the client application, and its core function is to interact with the data kernel service through the WCF (Windows Communication Foundation) protocol. The proxy module is designed to run in the process space of the client application, which means that it can directly access the client's resources and context, thereby improving the efficiency of the request.

[0053] The client application generates read and write requests (request information) for bit data based on user operations or system requirements. These requests may include: requests to read bit data points (such as obtaining the current value of a sensor). Write bit data (such as updating device status or data points). The proxy module also performs basic verification on the received request parameters, such as checking whether the necessary parameters exist and whether the parameter format is correct, to ensure the accuracy of subsequent processing.

[0054] The proxy module acts as a bridge between the client and the backend database by receiving and parsing client requests, forwarding requests and processing responses. This process ensures efficient processing and accurate responses to requests, enhances the flexibility and maintainability of the system, and provides a good user experience.

[0055] The data source driver module is used to access the corresponding time series database through the corresponding kernel service process according to the request information, and receive the query result of the time series database.

[0056] Specifically, the data source driver module is mainly responsible for receiving request information, interacting with various time series databases through the kernel service process corresponding to the request information, and finally obtaining the query results. The data source driver module receives the client's request information from the proxy module. These requests usually contain necessary information, such as request type (read / write), data source identifier, and parameter information (such as time range, data point, etc.).

[0057] The module determines the corresponding kernel service process based on the request information. The module can find the kernel service process information corresponding to the requested target database through the configuration management or addressing table. The kernel service process that is currently running, has a moderate load, and can handle the request can be selected. The module builds the request according to the API or protocol specification of the target kernel service process. The request (request information) can be formatted to ensure that the request conforms to the input format required by the kernel service process (such as a specific data structure or serialization format).

[0058] After receiving the request, the kernel service process will parse and process the request and prepare to interact with the time series database. This process may include: Database (time series database) connection management: ensure that the connection with the time series database is normal and perform necessary authentication. Execute database operations: perform corresponding database operations according to the nature of the request (such as query or write). At the same time, receive the query results of the time series database. Finally, the data source driver module returns the processed query results to the proxy module so that the proxy module can provide them to the client application.

[0059] The data source driver module completes the entire process from client request to data result acquisition by receiving request information, parsing request content, selecting the corresponding kernel service process and interacting with the time series database. This modular design enables the system to efficiently handle diverse requests, ensures good collaboration between various parts, and provides users with accurate and real-time data access capabilities.

[0060] In this embodiment, the cross-time series database compatible system is mainly composed of three core modules: service kernel management module, proxy module and data source driver module. The service kernel management module is mainly responsible for receiving preset source configuration information, which usually includes database type, connection address, authentication information, etc. According to different database requirements, the module will generate corresponding kernel service processes. These processes establish connections with specific time series databases respectively to process subsequent database operations. In addition, the service kernel management module can also start and stop each kernel service process to ensure that the system can flexibly respond to load changes. For example, service processes can be added to share requests during peak hours, and unnecessary processes can be stopped to save resources. The proxy module is responsible for receiving request information from the client and acts as an intermediary between the client and the backend database. The proxy module forwards the request information to the appropriate kernel service process to ensure that the request is accurately directed to the corresponding time series database. In this way, the client program does not need to directly access the underlying database. The data source driver module sends a query request to the corresponding time series database through the kernel service process, interacts with the database, and receives the returned query results. The returned query results will be passed back to the proxy module, and finally respond to the client's request to ensure that the client can obtain the required data.

[0061] Through the compatible system of this embodiment, the user can create a corresponding kernel service process through the service kernel management module, and based on the client's request information, connect the corresponding time series database through the data source driver module, and receive the query results of the time series database, that is, realize seamless switching between different time series databases, and reduce the compatibility problems caused by different database types. And the developer only needs to call a unified interface, the system can realize interaction with different types of databases, reducing the need to write specific interface codes for each database, thereby reducing the development cost of the application. At the same time, because the service kernel management module can dynamically start and stop the process, the system can adjust the performance according to real-time needs, and has good flexibility. If it is necessary to support new databases in the future, it is only necessary to simply configure the source information without reconstructing the client application. And through clear module division of labor and responsibility, each part of the system is easier to test and maintain. The improvement or failure of any module will not have a significant impact on other modules, ensuring the overall stability of the system. And the client accesses data through a unified interface, making the user experience more friendly, reducing the learning cost and operation complexity.

[0062] In general, this cross-time series database compatible system can effectively integrate and manage different types of time series databases, provide stable and flexible services, and at the same time improve the efficiency of development and maintenance, bringing convenience to users.

[0063] Optionally, the cross-time series database compatible system further includes a front-end graphics service module, and the front-end graphics service module is used to receive a creation request from a user, and send the creation request and the corresponding preset source configuration information to the service kernel management module.

[0064] Optionally, the front-end graphic service module is also used to visualize user operations.

[0065] Specifically, the front-end graphics service module is mainly responsible for receiving the user's creation request and sending the corresponding information to the service kernel management module.

[0066] The front-end graphics service module usually exists in the form of a graphical user interface (GUI), through which users can input creation requests. Figure 3 As shown, the user fills in the required information (such as data source name, type, connection parameters, etc.) on the interface and generates a creation request by clicking "Add" or a similar button. After receiving the creation request, the front-end graphics service module will perform basic verification, which may include: checking whether the required fields are complete and verifying the validity of the input data (such as format, type, etc.). After confirming that the request is valid, the module will integrate the required configuration information (such as data source type, connection string, access rights, etc.), which is usually pre-defined for easy reuse.

[0067] The front-end graphic service module encapsulates the creation request and the corresponding preset source configuration information and prepares to send it to the service kernel management module. After receiving the request from the front-end graphic service module, the service kernel management module creates the corresponding kernel service process according to the received information.

[0068] The front-end graphics service module completes the entire process from user interaction to back-end processing by receiving user creation requests, verifying request data, encapsulating and sending requests to the service kernel management module. This module ensures that users can easily create and manage time series database resources, and at the same time, good communication with the service kernel management module ensures the effectiveness and timeliness of request processing, providing users with a friendly operation experience.

[0069] Optionally, the service kernel management module is specifically used for:

[0070] Creating the corresponding kernel service process according to the creation request and the corresponding preset source configuration information, and returning the creation process to the front-end graphics service module;

[0071] When the kernel service process is successfully created, start and stop operations are performed on each kernel service process according to the received start request, and each start result and corresponding connection status are returned to the front-end graphics service module.

[0072] Specifically, the service kernel management module is responsible for managing the creation and control of the kernel service process in the cross-time series database compatible system. When the front-end graphics service module sends a creation request and its corresponding preset source configuration information, the service kernel management module receives the relevant data. That is, the basic information of the creation request is obtained, such as the required kernel service type, data source parameters, etc. The service kernel management module classifies and processes the creation of the kernel service process according to the received creation request and preset source configuration information, that is, the preset source configuration information is applied to the newly created kernel service process to ensure that it has the correct parameters when interacting with the database. During the kernel service process creation process, the service kernel management module tracks the status of the process and forms feedback after the creation is completed. The result of the creation process (success or failure) and related information (such as process ID, error information, etc.) are encapsulated into a response message and returned to the front-end graphics service module to notify the user of the creation result.

[0073] The service kernel management module also needs to manage the start and stop operations of the kernel service process. Figure 3As shown, each kernel service process is started and stopped through the "Start" or "Stop" button in the figure. And the start and stop results and connection status are returned. That is, after completing the start and stop operations, the service kernel management module will collect the start results and current connection status (such as successful connection or connection failure) of each process. The start result and connection status of each kernel service process are encapsulated into the response message. Finally, the response result is returned to the front-end graphic service module to update the user interface to inform the user of the success or failure of the operation and the running status of each service. When the kernel service process is successfully created, the information of the data source is saved in the local configuration file at the same time. This file can be directly applied to the creation and management process of the kernel service when the system service is started next time.

[0074] The front-end graphical service module displays the current status of each kernel service process (such as running, stopped, successfully connected, failed to connect, etc.). It also provides error prompt information so that users can identify it in time and make necessary adjustments.

[0075] The service kernel management module provides important support for dynamically managing cross-time series database services by receiving creation requests, creating kernel service processes, and managing their start and stop. This module ensures that users can easily create and manage services, and provides timely feedback on success and failure, ensuring the robust operation of the system and improving user experience. That is, the service kernel management module functions similarly to the service manager of the Windows system, responsible for adding, deleting, and modifying data kernel services, as well as starting and stopping data kernel service processes.

[0076] Optionally, the cross-time series database compatible system further includes a data kernel service module, and the data kernel service module is used to forward the request information to the data source driver module.

[0077] Alternatively, if Figure 3 As shown, the data source driver module also includes a plurality of sub-driver modules, and the data source driver module is specifically used for:

[0078] The request information is converted to obtain corresponding request format information, and according to the corresponding request format information, a connection is established with the corresponding time series database through the sub-driver module corresponding to the kernel service process to realize data access and transmission of the time series database, and receive the query results fed back by the time series database.

[0079] Specifically, the client program sends a request (request information), which is usually a query or operation request for data. The data kernel service module receives this request and performs preliminary processing and forwarding. Forward to the data source driver module: The data kernel service module forwards the request step by step to the corresponding data source driver module. After receiving the request, the data source driver module first parses the request information. Usually includes: confirming the type of request (such as query, update, insert, delete, etc.). Identifying the parameters and data structure in the request, according to the type and content of the request, the data source driver module converts the data into the specific request format required by the target data source. These conversions may include: converting advanced query statements (such as SQL) into the query language supported by the time series database. Or adjusting the field name, data type and structure to meet the specifications of the target database. Or different conversion logic may be involved for different types of requests.

[0080] Using the converted request format information, through the corresponding kernel service process, and select the corresponding "data source driver". Each data source driver implements a specific data access interface, supports interaction with a specific type of time series database, and the data source driver module establishes a connection with the target time series database through the selected data source driver.

[0081] In some embodiments, such as Figure 4 As shown in the figure, it is a schematic diagram of the relationship between the service kernel management module and multiple kernel services. Multiple applications interact with the service kernel management module through the proxy module and use WCF (Windows Communication Foundation) for communication. The service kernel management module is responsible for managing different kernel services and coordinating the interaction between them. The kernel service (kernel service process) includes kernel service-1 (ISYS driver): responsible for data interaction with the ISYS server and providing relevant API interfaces for application calls.

[0082] Kernel Service-2 (PI Driver): Responsible for data interaction with the PI server and also provides an API interface.

[0083] Kernel service-3 (IP21 driver): responsible for data interaction with the IP21 server and providing corresponding API interface.

[0084] Database server (time series database): Each kernel service connects to its corresponding database server (ISYS server, PI server, IP21 server) to perform data read and write operations. API interface: The kernel service communicates with the application and database server through the API interface to process data requests and responses.

[0085] It should be noted that the API interface in this embodiment is a unified interface, and the interface provided to the outside world is consistent for any kernel service.

[0086] The figure shows a multi-layer architecture in which applications interact with the service kernel management module through agents, which manages multiple kernel services and interacts with different database servers for data. This architectural design helps to achieve modularity and flexibility of the system, and facilitates expansion and maintenance.

[0087] Optionally, the preset source configuration information includes the name of the data source, the type of the data source, the IP address and port number of the data source, the port number of the client connection, and the protocol used by the client connection.

[0088] Specifically, the user passes the created data source configuration information through the front-end graphics service module, and the service kernel management module creates the corresponding kernel service process according to the configuration information. The data source configuration information and the acquisition method are as follows:

[0089] ①The name of the data source, set by the user;

[0090] ②Data source type, which refers to a certain database type, such as ISYS, InfluxDB, PI, etc., which is selected by the user from the built-in supported list;

[0091] ③Data source version, which refers to the version of the database, selected by the user from the built-in supported list;

[0092] ④Data source user and password, which refers to the user name and password for connecting to the database, which are set by the user based on actual needs;

[0093] ⑤ The IP address and port number of the data source refers to the IP address and port number for connecting to the database, which are set by the user based on actual conditions;

[0094] ⑥The port number of the client connection is used by the client to connect to the compatibility layer system to obtain database data. It is automatically generated by the service kernel management module by default, and can also be specified by the user;

[0095] ⑦ The protocol used by the client connection refers to the communication method used by the client to interact with the data core service. WCF can be bound to multiple protocols (such as HTTP, WebSocket, etc.), and the user can select from the built-in supported list;

[0096] Among them, ②③④⑤ are the necessary information for the data kernel service process to connect to the underlying database (time series database), and ⑥⑦ are the necessary information for the client to connect to the data kernel service. Figure 5 and Figure 6 As shown, Figure 5 Each kernel service process contains data. The underlying database in the figure is a time series database. Figure 6 A diagram of the test page that simulates a client connection request.

[0097] Optionally, the cross-time series database compatible system further includes a front-end data cache module, and the front-end data cache module is used to cache historical query results of each of the time series databases.

[0098] Optionally, the front-end data cache module is further used to check whether there is a corresponding query result in the historical query results according to the request information, and if so, return the corresponding query result to the client.

[0099] Specifically, the functions of the front-end data cache module include caching historical query results and checking whether corresponding query results exist when receiving request information. The front-end data cache module is designed as an efficient cache storage space that can store historical query results of various time series databases. These results include but are not limited to data sets returned by queries, time series data, etc. When the system starts, the front-end data cache module will be initialized and ready to receive and store query results. It may define the size and expiration policy of the cache to better manage storage. Whenever a query request is received from a client program, the front-end data cache module will store these query results in the cache after being processed by the data source driver module and obtaining the query results from the time series database.

[0100] When the client program issues a new query request, the data kernel service module forwards the request to the front-end data cache module for processing. The front-end data cache module queries the cache for corresponding historical query results based on the request information. For example, it extracts key parameters and conditions in the request information and uses these key parameters to search in the cache, usually using a hash table or other efficient data structures to speed up the search.

[0101] If the corresponding query result is found in the cache, the module will directly return the result to the client program without requesting the time series database again. This significantly improves the response speed and reduces the burden on the database.

[0102] If the corresponding result is not found in the cache, the module will forward the request to the data source driver module to execute the normal data query process.

[0103] Whether the results are returned directly from the cache or new results are found through the data source driver module, ultimately, the data kernel service module sends the results back to the client program to complete the entire request processing process.

[0104] Through the above steps, the front-end data cache module effectively improves the query efficiency and response time of the cross-time series database system. By caching historical query results, the module not only reduces the burden of repeated queries on the time series database, but also provides the client with the ability to quickly return, thereby enhancing the overall system performance. This mechanism is particularly important when dealing with high-frequency queries or real-time data requirements.

[0105] In some specific embodiments, if the client needs to obtain a batch of historical data of bit numbers from the ISYS database, the following is a detailed description of the entire process: the user initiates a request to add an ISYS data source through the front-end graphics service (front-end graphics service module). After receiving the request, the service kernel management module creates an ISYS data kernel service (data kernel service process) according to the transmitted ISYS data source configuration information.

[0106] The ISYS data kernel service serves as the host of the ISYS database driver module (the sub-driver module in the database driver module). The creation result will be returned to the front-end graphics service to inform the user of the status of the data source creation.

[0107] After the kernel service of the data source is successfully created, the user initiates a request to start the kernel service. After receiving the start request, the service kernel management module starts the specified ISYS data kernel service process. The start result and the connection status of the data source (for example: connected or not connected) will be returned to the front-end graphics service to inform the user of the start status of the kernel service. When the front-end graphics service shows that the kernel service has been successfully started and the connection status with the data source is connected, the ISYS data kernel service can start to receive and process query requests from client applications.

[0108] The client application generates a connection string (data contained in the request information) through the proxy module. The string consists of the IP address of the host where the ISYS data kernel service is located and the client connection port number provided by the service kernel management module. The client application uses the connection string to establish a connection with the ISYS data kernel service.

[0109] When the client needs to read a batch of bit number data from the ISYS database, the client application initiates a request message (request message) through the proxy module, that is, calls the API interface of the data core service to initiate a request to read the bit number. The request will include the query bit number name, time, quantity and other conditions. After the ISYS data core service receives the bit number read request (request message) sent by the proxy module, it first checks whether the result of the same request is cached in the front-end data cache module.

[0110] If the cache hits, the data kernel service module will directly return the cached result to the client application to avoid accessing the database again.

[0111] If there is no hit, the data kernel service module forwards the request to the ISYS data source driver module (the sub-driver module in the data source driver module) of its host.

[0112] After receiving the request to read the bit number, the ISYS data source driver module directly calls the corresponding bit number data reading interface of the ISYS database to obtain data. The ISYS data source driver module obtains the corresponding bit number data from the bit number data reading interface of the ISYS database and returns it to the ISYS data kernel service process. The bit number data is returned to the client application through the proxy module through the data kernel service module. At the same time, the data kernel service module will update the cache in the front-end data cache module to store the bit number data read this time, so that the cache can be directly hit in subsequent requests of the same nature.

[0113] This process implements the complete process from creating an ISYS data source, starting the data kernel service, to requesting data through the client application. The use of the front-end data cache module can effectively improve the system response speed, reduce direct access to the ISYS database, and ensure the efficiency and stability of data access.

[0114] like Figure 7 As shown, an embodiment of the present invention provides a compatibility control method across time series databases, including:

[0115] Obtaining preset source configuration information, and creating corresponding kernel service processes according to each of the preset source configuration information, and controlling the start and stop of each of the kernel service processes, wherein one of the kernel service processes is used to connect to a corresponding time series database;

[0116] Get the client's request information;

[0117] The corresponding time series database is accessed through the corresponding kernel service process according to the request information, and a query result of the time series database is received.

[0118] The advantages of the cross-time series database compatibility control method of this embodiment over the prior art are the same as the advantages of the cross-time series database compatibility system over the prior art, and will not be described in detail here.

[0119] Although the present invention is disclosed as above, the protection scope of the present invention is not limited thereto. Those skilled in the art may make various changes and modifications without departing from the spirit and scope of the present invention, and these changes and modifications will fall within the protection scope of the present invention.

Claims

1. A compatible system across time series databases, characterized in that: include: A service kernel management module, used to receive preset source configuration information, create corresponding kernel service processes according to each preset source configuration information, and control the start and stop of each kernel service process, wherein one kernel service process is used to connect to a corresponding time series database; Proxy module, used to obtain client request information; The data source driver module is used to access the corresponding time series database through the corresponding kernel service process according to the request information, and receive the query result of the time series database.

2. The cross-time series database compatible system according to claim 1, characterized in that: It also includes a front-end graphics service module, which is used to receive a creation request from a user and send the creation request and the corresponding preset source configuration information to the service kernel management module.

3. The cross-time series database compatible system according to claim 2, characterized in that: The service kernel management module is specifically used for: Creating the corresponding kernel service process according to the creation request and the corresponding preset source configuration information, and returning the creation process to the front-end graphics service module; When the kernel service process is successfully created, start and stop operations are performed on each kernel service process according to the received start request, and each start result and corresponding connection status are returned to the front-end graphics service module.

4. The cross-time series database compatible system according to claim 1, characterized in that: The data source driver module further includes a plurality of sub-driver modules, and the data source driver module is specifically used for: The request information is converted to obtain corresponding request format information, and according to the corresponding request format information, a connection is established with the corresponding time series database through the sub-driver module corresponding to the kernel service process to realize data access and transmission of the time series database, and receive the query results fed back by the time series database.

5. The cross-time series database compatible system according to claim 1, characterized in that: It also includes a data kernel service module, and the data kernel service module is used to forward the request information to the data source driver module.

6. The cross-time series database compatible system according to claim 1, characterized in that: The preset source configuration information includes the name of the data source, the type of the data source, the IP address and port number of the data source, the port number of the client connection, and the protocol used by the client connection.

7. The cross-time series database compatible system according to claim 1, characterized in that: It also includes a front-end data cache module, which is used to cache historical query results of each of the time series databases.

8. The cross-time series database compatible system according to claim 7, characterized in that: The front-end data cache module is also used to check whether there is a corresponding query result in the historical query results according to the request information, and if so, return the corresponding query result to the client.

9. The cross-time series database compatible system according to claim 2, characterized in that: The front-end graphic service module is also used to visualize user operations.

10. A compatibility control method across time series databases, characterized in that: Applied to the cross-time series database compatibility system according to any one of claims 1 to 9, the cross-time series database compatibility control method comprises: Obtaining preset source configuration information, and creating corresponding kernel service processes according to each of the preset source configuration information, and controlling the start and stop of each of the kernel service processes, wherein one of the kernel service processes is used to connect to a corresponding time series database; Get the client's request information; The corresponding time series database is accessed through the corresponding kernel service process according to the request information, and a query result of the time series database is received.

Images