Data query method and device, big data platform, equipment, medium and program product

Abstract

Embodiments of the present specification provide a data query method, device, big data platform, equipment, medium and program product, wherein the data query method comprises: receiving a data query request, determining at least one data source corresponding to the data query request; determining a corresponding security query operator based on the data query request; obtaining data description information of the data source, determining a target query plan from candidate query plans of the at least one data source based on the data description information and the security query operator, and obtaining a query result corresponding to the data query request based on the target query plan, wherein the candidate query plan is used to indicate an execution order of the at least one data source under the security query operator. By using the security query operator and combining the data description information to dynamically select the target query plan, the operator execution order is optimized while ensuring data security, the efficiency bottleneck of traditional non-security scene operators in an encrypted environment is solved, and the effective improvement of query performance in a security protection scene is realized.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of data processing technology, and in particular to a data query method, apparatus, big data platform, device, medium, and program product. Background Technology

[0002] In modern data management and analysis systems, the need to process and parse large-scale datasets is ever-increasing. Whether it's a relational database, data warehouse, or big data platform, there's a need to effectively execute various query operations to meet user needs. These queries typically involve complex operations such as filtering specific records, calculating summary statistics, and joining multiple tables. To achieve efficient data query processing, database management systems have introduced logical operators as one of their core components. Logical operators not only determine the logical structure of the query but also directly affect its performance.

[0003] In related technologies, logical operators in secure protection scenarios need to be specially designed to support encrypted data processing, which is significantly different from logical operators in non-secure protection scenarios. If the query method of logical operators in non-secure protection scenarios is still used, it may lead to a decrease in computational efficiency.

[0004] Therefore, there is an urgent need for a data query method that balances computational efficiency with security protection scenarios. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a data query method. One or more embodiments of this specification also relate to a big data platform, a data query device, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a data query method is provided, including:

[0007] Receive a data query request and determine at least one data source corresponding to the data query request;

[0008] Determine the corresponding secure query operator based on the data query request;

[0009] Obtain data description information from the data source; based on the data description information and the security query operator, determine the target query plan from the candidate query plans of at least one data source; and obtain the query results corresponding to the data query request based on the target query plan. The candidate query plan is used to indicate the execution order of at least one data source in the security query operator.

[0010] According to a second aspect of the embodiments of this specification, a data query apparatus is provided, comprising:

[0011] The data source determination module is configured to receive data query requests and determine at least one data source corresponding to the data query request.

[0012] The operator determination module is configured to determine the corresponding security query operator based on the data query request;

[0013] The plan determination module is configured to obtain data description information from the data source, determine the target query plan from candidate query plans of at least one data source based on the data description information and the security query operator, and obtain the query results corresponding to the data query request based on the target query plan. The candidate query plans are used to indicate the execution order of at least one data source in the security query operator.

[0014] According to a third aspect of the embodiments of this specification, a big data platform is provided, including an optimizer, a metadata management system, and an execution engine;

[0015] The optimizer is used to receive data query requests, determine at least one data source and a secure query operator corresponding to the data query request, and obtain data description information of the data source sent by the metadata management system. Based on the data description information and the secure query operator, it determines the target query plan from the candidate query plans of at least one data source and sends the target query plan to the execution engine. The candidate query plan is used to indicate the execution order of at least one data source in the secure query operator.

[0016] Metadata management system, used to send data description information from the data source to the optimizer;

[0017] The execution engine receives the target query plan, executes the query operation corresponding to the target query plan, and obtains the query results corresponding to the data query request.

[0018] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0019] Memory and processor;

[0020] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, they implement the steps of the above-mentioned data query method.

[0021] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the data query method described above.

[0022] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data query method.

[0023] One embodiment of this specification implements receiving a data query request, determining at least one data source corresponding to the data query request, determining a corresponding security query operator based on the data query request, obtaining data description information of the data source, determining a target query plan from candidate query plans of at least one data source based on the data description information and the security query operator, and obtaining the query result corresponding to the data query request based on the target query plan. The candidate query plans are used to indicate the execution order of at least one data source in the security query operator. By combining data source description information and security query operators, a suitable target query plan is dynamically selected from multiple candidate query plans, while avoiding performance degradation caused by default selection of query plans incompatible with the security protection scenario. This significantly improves query execution efficiency and overall system performance while ensuring data security. Thus, even in complex security protection scenarios, the system can dynamically adapt and optimize the query processing, meeting users' dual needs for data security and fast access. Attached Figure Description

[0024] Figure 1 This is an interactive schematic diagram of a big data platform provided in one embodiment of this specification;

[0025] Figure 2 This is a flowchart illustrating a data query method provided in one embodiment of this specification;

[0026] Figure 3 This is a schematic diagram illustrating the processing procedure of a data query method provided in one embodiment of this specification;

[0027] Figure 4 This is a schematic diagram of the structure of a data query device provided in one embodiment of this specification;

[0028] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0029] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

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

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

[0032] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0033] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0034] SQL, or Structured Query Language, is a standard programming language used for managing and manipulating relational databases. It allows users to perform various database operations, such as querying data, updating records, and creating and modifying table structures. SQL is widely used in database systems and big data platforms and is a primary tool for processing and managing structured data. By using SQL, users can easily retrieve information from databases and perform complex data analyses.

[0035] Calcite is a database optimizer designed to provide unified query and computation capabilities across multiple data sources. Calcite supports SQL query parsing, optimization, and execution plan generation, and can integrate with different storage engines to achieve efficient data access. Its design goal is to provide a scalable infrastructure that enables applications to seamlessly switch between heterogeneous data sources and execute complex queries.

[0036] TEE stands for Trusted Execution Environment. It is an isolated execution environment with security features, where data can be securely computed without fear of leakage.

[0037] MPC stands for Secure Multi-party Computation. It's a model where multiple participating entities collaboratively compute a common function, requiring each entity to receive a specified computation result without obtaining any other related information.

[0038] FHE stands for Fully Homomorphic Encryption. It is a cryptographic system that allows arbitrary computations on the ciphertext.

[0039] With the rapid development of information technology, the volume of data is exploding, making it increasingly difficult for users, especially individual users and small businesses, to manage their own data. Faced with the massive demands for data storage, processing, and analysis, many users choose to entrust their data to big data platforms for management and computation. These big data platforms offer powerful data processing capabilities, efficiently executing complex query operations and supporting various data analysis tasks. However, while data hosting solves the technical challenges of data management, it brings new challenges—data security protection. Ensuring that sensitive information is not leaked during the data upload process to third-party platforms has become a critical issue that urgently needs to be addressed.

[0040] While hosting data on a big data platform simplifies data management processes, it also poses a potential threat to user data security. To address this challenge, a common practice is to encrypt data before uploading it to the platform. However, this raises another problem: how can encrypted data be efficiently computed? Current mainstream solutions include Trusted Execution Environments (TEEs), Secure Multi-Party Computation (MPC), and Fully Homomorphic Encryption (FHE). Each solution has its unique security protection model: TEE relies on a hardware-level trusted environment to ensure data security; MPC is based on the trust assumption that there is no collusion among the participants, achieving joint computation through secret sharing; and FHE allows arbitrary computation directly on the ciphertext, obtaining results without decryption. However, in practical applications, the execution speed of operators under these security protection schemes is much lower than that under plaintext conditions, posing new challenges to the physical plans generated by traditional optimizers. Directly using traditional execution schemes may lead to a significant decrease in execution efficiency. Therefore, it is necessary to design a dedicated security enhancement optimization system for big data platforms to improve the overall efficiency of query execution.

[0041] One related technique involves replacing the execution scheme of physical operators within an open-source big data processing framework. Data is decrypted, executed, and encrypted in a Trusted Execution Environment (TEE) to achieve data security protection. However, this method does not adjust the default optimizer, still using an optimization scheme designed for plaintext data, which may lead to decreased execution efficiency. Another related technique proposes a SQL query support solution based on a Multi-Party Computation (MPC) framework. This solution uses an optimizer provided by an open-source database and leverages the MPC protocol to perform computations on secretly shared data. Similarly, this optimizer is designed for traditional plaintext databases and does not optimize for MPC scenarios. Furthermore, some academic research has proposed methods to adjust the physical plan provided by the optimizer, mainly considering how to adjust operators in the physical plan according to changes in data security requirements or optimize the physical plan based on table holdings. However, most of these methods adjust rules based on the execution scheme of existing optimizers, failing to fully consider the significant difference in operator execution efficiency after enabling and disabling security enhancements, potentially resulting in overall query performance falling short of expectations.

[0042] To address the aforementioned technical problems, this specification provides a data query method. This specification also relates to a big data platform, a data query device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0043] See Figure 1 , Figure 1 This is an interactive diagram of a big data platform provided in one embodiment of this specification, including an optimizer, a metadata management system, and an execution engine. The optimizer receives data query requests, determines at least one data source and a secure query operator corresponding to the data query request, and obtains data description information of the data source sent by the metadata management system. Based on the data description information and the secure query operator, it determines a target query plan from candidate query plans of at least one data source and sends the target query plan to the execution engine. The candidate query plans are used to indicate the execution order of at least one data source in the secure query operator. The metadata management system sends data description information of the data source to the optimizer. The execution engine receives the target query plan and executes the query operation corresponding to the target query plan to obtain the query result corresponding to the data query request. Specifically... Figure 1In the process, the optimizer first receives a request from the SQL Structured Query Language (SQL), parses it into an abstract syntax tree (AST), and obtains data description information from the data source through the metadata management system. After obtaining the data description information, the optimizer validates the AST and generates logical operators. Next, based on the data description information and logical operators, the optimizer determines a suitable target query plan from the candidate query plans. Finally, the optimizer sends the target query plan to the execution engine, which receives and executes the query operation corresponding to that plan. Throughout the entire process, the metadata management system continuously provides necessary data description information to ensure that the optimizer can accurately generate and optimize the query plan.

[0044] See Figure 2 , Figure 2 A flowchart of a data query method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0045] Step 202: Receive a data query request and determine at least one data source corresponding to the data query request.

[0046] A data query request refers to an information request issued by a user or system to retrieve specific data. These requests typically contain specific conditions regarding the required data, such as the fields to be queried and filter criteria. By parsing these requests, the system can understand what data the user wants to extract from the database.

[0047] In this context, the data source specifically refers to the data table that stores the data to be queried. Each data table represents a specific collection of data, containing multiple records (rows) and fields (columns) describing the attributes of these records. For example, in an e-commerce application, there may be different data tables such as order data tables, product data tables, and user data tables, each serving a specific type of data storage and querying needs.

[0048] In practical applications, when a data query request is received, the system first parses the request to determine the query target, i.e., what type of data the user wants to retrieve. Based on the information in the query request, such as the field names involved or the logical relationships between tasks, the system identifies at least one corresponding data table as the data source. If the query involves the user's order details and related product information, then the system needs to determine the order table and product table as the data source for this query. For the step of receiving a data query request, one option is to directly parse the target data table name from the request parameters; another implementation is to dynamically match the corresponding data table based on the logical conditions in the request content. Regardless of the method used, the ultimate goal is to accurately identify all data tables that meet the query conditions, ensuring that subsequent processing can correctly retrieve data from these tables.

[0049] In the embodiments described in this specification, by accurately parsing the data query request and determining at least one corresponding data table as the data source, the system can effectively locate the correct data location for querying, reducing unnecessary search scope.

[0050] For example, in a task on a social media platform, a user initiates a query request to view all public posts made by people they follow. The system first analyzes this query request, extracting key information such as user ID and follow relationships. Next, the system identifies two main data sources: a follow table storing users and their follow relationships, and a content table storing all posts made by users.

[0051] Step 204: Determine the corresponding security query operator based on the data query request.

[0052] Secure query operators are a set of query logic operators predefined in the optimizer by the optimizer designers. These operators are specifically designed to ensure security during data processing. Their characteristic is that regardless of the content of the data being processed, as long as the number of input rows is consistent, the number of output rows will also remain consistent. This avoids inferring sensitive information from the results, thus ensuring the effectiveness of security protection. For example, PrivateAggregate and PrivateProject are concrete examples of such operators.

[0053] In practical applications, when a data query request is received, the system determines which secure query operators should be used for data processing based on the content of the request. This includes analyzing the query conditions, the data tables involved, and any specific security requirements. For example, if the query involves aggregation operations, the PrivateAggregate operator will be selected; if it involves selecting specific columns, the PrivateProject operator will be used. One approach to determining the appropriate secure query operator based on the data query request is to directly match the corresponding secure query operator according to the operation type in the query request; another approach is to dynamically determine the appropriate combination of secure query operators through metadata analysis and the complexity of the query conditions. Regardless of the approach taken, the goal is to ensure that the selected secure query operators effectively protect data privacy while meeting the query requirements.

[0054] In the embodiments described in this specification, by accurately selecting appropriate secure query operators based on the data query request, the system can ensure the security of data processing while executing data queries. This method not only enhances the system's security mechanism but also maintains data integrity and confidentiality even during processing, preventing potential information leakage risks. Furthermore, since each secure query operator is designed to maintain the same number of input and output rows, the security of the data access pattern is further strengthened, ensuring that external entities cannot infer any sensitive information by observing the size of the result set.

[0055] For example, in a healthcare information management system, a user initiates a query request to obtain the incidence rate statistics of a specific disease in patients of different age groups. The system first parses the query request and identifies the need for aggregation calculations to statistically determine the incidence rate. Next, the system selects PrivateAggregate as the secure query operator to perform this task. Simultaneously, to filter records related to the specific disease, the system also selects the PrivateFilter operator. Throughout the query process, all selected secure query operators ensure the consistency of the number of input and output rows, effectively protecting patients' personal information from leakage. Finally, the system successfully returns results that meet the user's needs and have undergone rigorous security protection, satisfying the user's query requirements while fully guaranteeing data security.

[0056] Furthermore, determining the corresponding secure query operator based on the data query request includes: generating a corresponding query statement based on the data query request; performing syntax analysis on the query statement to determine the query features corresponding to the query statement, and determining the initial query operator corresponding to the query request based on the query features; and determining the secure query operator corresponding to the initial query operator based on the query features.

[0057] A query statement is automatically generated based on a user's data query request. It expresses the information the user wants to retrieve from the database in a structured way. For example, a query statement might require filtering all records that meet certain conditions from a specific data table and performing operations such as aggregation or sorting on these records.

[0058] Query features refer to the key attributes and operation types extracted after syntactic analysis of the query statement, including but not limited to the data tables involved, the operations to be performed (such as selection, projection, join, aggregation, etc.), filtering conditions, and sorting rules. These features provide a basis for subsequently selecting appropriate query operators. For example, in an e-commerce database, if the query statement requests statistics on the sales volume of a certain type of product, then the relevant query features would include the product category, the sales record table, and aggregation operations.

[0059] In practical applications, when the system receives a data query request, it first generates a corresponding query statement based on the request. Then, the system performs syntactic analysis on this query statement to extract query features. Based on these features, the system determines the initial query operator corresponding to the query request; for example, the Aggregate operator is selected for aggregation needs, and the Filter operator is selected for data selection needs. Next, the system further determines the corresponding security query operators based on these initial query operators, ensuring that data security and privacy are maintained throughout the entire data processing process. For example, if the initial query operator is Aggregate, its corresponding security query operator might be PrivateAggregate; if it is Join, the corresponding security query operator might be PrivateJoin or PrivateKeyJoin. This conversion ensures that regardless of the content of the processed data, as long as the number of input rows is consistent, the number of output rows will also remain consistent, thereby protecting the data access pattern from being leaked.

[0060] In the embodiments described in this specification, by meticulously analyzing query requests and accurately transforming query statements into a series of secure query operators, the system can efficiently complete data query tasks while ensuring data security. This method not only enhances system security but also guarantees the ability to provide rapid responses even in complex privacy-preserving environments. Furthermore, since each secure query operator is designed to maintain consistency in the number of input and output rows, privacy protection measures throughout the entire data processing flow are further strengthened.

[0061] For example, in a task on an online education platform, a user wants to understand student participation in a course over the past month, including the number of videos watched and assignments submitted. The system first generates a corresponding query based on the user's request, then performs syntactic analysis to identify the student behavior record table, time range filtering conditions, and required aggregation operations. Based on these query characteristics, the system selects `Aggregate` as the initial query operator to count student activity frequency. Subsequently, considering data security and privacy protection requirements, the system converts `Aggregate` to the `PrivateAggregate` secure query operator, ensuring that no sensitive information is leaked throughout the entire process, whether in intermediate or final results.

[0062] Further, determining the safe query operator corresponding to the initial query operator includes: obtaining a data description information and operator correspondence table of the data source; determining at least one candidate safe operator corresponding to the initial query operator in the operator correspondence table; and determining the hit safe query operator from at least one candidate safe operator based on the data description information.

[0063] Data description information includes metadata about the data structure and characteristics of the data source, such as the number of rows in the table, the data types of the columns, and whether certain columns are unique or ordered. This information is crucial for optimizing query performance and selecting appropriate safe query operators. The operator mapping table is a predefined mapping that lists the relationships between standard query operators and their corresponding safe query operators, taking into account applicability in different scenarios. For example, in this table, the Aggregate operator might correspond to PrivateAggregate, and the Join operator might correspond to PrivateKeyJoin or PrivateJoin, depending on whether the join condition columns are unique.

[0064] In practical applications, after determining the initial query operator, the system first obtains the data description information of the relevant data sources and a mapping table between query operators and secure query operators. Based on this mapping table, the system can find at least one candidate secure operator corresponding to the initial query operator. For example, if the initial query operator is Join, the candidate secure operators might be PrivateKeyJoin or PrivateJoin. Next, the system uses the obtained data description information to further filter out the secure query operator most suitable for the current query environment. For example, if the data description information shows that the join condition column is unique in a table, then PrivateKeyJoin will be selected as the final secure query operator; otherwise, PrivateJoin may be selected. This process ensures that the selected secure query operator not only meets the query function requirements but also maintains data security and privacy protection during processing.

[0065] In the embodiments described in this specification, by combining data description information with an operator correspondence table, the system can accurately determine the most suitable secure query operator from multiple candidate secure operators for the current query task. This method not only improves query efficiency and reduces unnecessary resource consumption, but also ensures data security throughout the entire processing. Since each secure query operator is designed to maintain consistency in the number of input and output rows, it effectively prevents potential information leakage risks and enhances the overall protection capability of the system.

[0066] For example, in a task on an e-commerce data analysis platform, a user wants to understand the sales performance of a certain type of product and its associated order details within a specific time period. The system first parses the user's query request and generates a corresponding query statement, identifying that a join operation is needed between the `orders` (user) table and the `lineitem` (product) table to obtain complete sales records. Next, the system selects `Join` as the initial query operator based on the query characteristics. Subsequently, the system obtains the data description information of these two tables and consults the operator correspondence table to find two candidate safe operators for `Join`: `PrivateKeyJoin` and `PrivateJoin`. Based on the characteristic that the `orderid` column in both the `orders` and `lineitem` tables is unique, the system determines to use `PrivateKeyJoin` as the safe query operator for this query.

[0067] Furthermore, after performing syntactic analysis on the query statement, determining the query features corresponding to the query statement, and determining the initial query operator corresponding to the query request based on the query features, the method also includes: obtaining data description information of the data source; and removing the initial query operator if the data description information ensures that the data source does not need to perform the query operation corresponding to the query features.

[0068] In practical applications, after performing syntactic analysis on the query statement and determining its characteristics, the system first selects an initial query operator corresponding to these characteristics. For example, if the query requires sorting the `orders` table by order date in ascending order, the system will initially select `Sort` as the initial query operator. Next, the system obtains the data description information from the relevant data source. Suppose the data description information shows that the order date column in the `orders` table is already sorted in ascending order. In this case, since the data source itself already meets the sorting conditions required by the query, no additional sorting operation is needed. Therefore, the system will remove the initial query operator `Sort` to avoid unnecessary computational overhead.

[0069] This approach not only improves query efficiency and reduces resource consumption, but also ensures the system's flexibility and intelligence. By utilizing data description information, the system can dynamically adjust its query plan to adapt to different data states and query needs, thereby achieving more efficient query processing.

[0070] In the embodiments described in this specification, by combining data description information, the system can automatically remove unnecessary initial query operators when it is confirmed that the data source already meets the requirements of the query features. This not only improves query performance but also reduces the waste of system resources. Especially for operations such as sorting that may consume a lot of resources, correctly identifying and skipping sorted data can significantly improve overall query efficiency.

[0071] For example, in a task on an e-commerce data analytics platform, a user wants to view information on all orders placed within the past month, sorted by order date in ascending order. The system first parses the user's query request and generates a corresponding query statement, identifying the need to sort the `orders` table by order date in ascending order. Next, the system selects `Sort` as the initial query operator. Subsequently, the system obtains the data description information of the `orders` table and finds that the order date column is already sorted in ascending order. Based on this information, the system determines that no further sorting operation is needed and therefore removes the `Sort` initial query operator.

[0072] Step 206: Obtain data description information from the data source; based on the data description information and the security query operator, determine the target query plan from the candidate query plans of at least one data source; obtain the query results corresponding to the data query request based on the target query plan; wherein, the candidate query plan is used to indicate the execution order of at least one data source in the security query operator.

[0073] Data description information refers to metadata about the data structure and characteristics of a data source, including but not limited to the number of rows in a table, the data types of columns, and whether certain columns are unique or ordered. This information is crucial for optimizing query performance because it helps the system choose an execution plan more intelligently. For example, in an e-commerce database, a product table might contain fields such as product ID, name, and price, and it also has the characteristic that the product ID column is unique.

[0074] A candidate query plan refers to multiple possible execution schemes generated by the optimizer during the database query optimization process. Each candidate plan describes how to use a specific sequence of operations (such as scans, joins, filtering, etc.) to access and process data in the data source to satisfy the user's query request. These plans consider factors such as different operation orders, indexes used, and join strategies, aiming to find an efficient path to complete the query.

[0075] Execution order refers to the sequence in which various query operations (such as table scans, filtering, joins, aggregations, etc.) are executed within a selected query plan. It determines how data is retrieved, processed, and combined, directly impacting the overall performance and efficiency of the query. For example, in a multi-table join query, deciding which two tables to join first, and then join with the third, or whether to apply filtering conditions to certain tables before joining, are all different manifestations of execution order.

[0076] In practical applications, when query results need to be retrieved from at least one data source, the system first obtains descriptive information for each data source. Based on this metadata and the previously determined security query operators, the system begins to evaluate the cost of multiple candidate query plans. Each candidate plan indicates the execution order of different data sources under the security query operators. For example, if the task involves encrypting user orders before joining them to a product information table, the system might consider different execution orders: filtering before joining or joining before filtering, and calculate the cost of each approach. One option is to directly estimate the cost of each plan based on existing metadata and select the one with the lowest cost; another approach is to dynamically adjust the metadata information and recalculate the cost of each plan to adapt to the new data state. Ultimately, the system selects the target query plan that has the lowest cost and meets the security requirements to execute the query request.

[0077] In the embodiments described in this specification, by combining data description information with a secure query operator, the system can intelligently select a suitable target query plan from multiple candidate query plans. This method not only improves query efficiency and reduces unnecessary resource consumption, but also ensures data security throughout the entire processing. Because the secure query operator is designed to guarantee the consistency of input and output row counts, the system can effectively prevent potential information leakage risks and enhance overall security capabilities.

[0078] For example, in a task on a financial data analysis platform, a user wants to query the transaction records and related customer information of a specific bank product within a specific time period. The system first obtains descriptive information from the relevant data tables (such as a transaction record table and a customer information table), including the number of rows and the existence of unique keys. Next, based on the query requirements, it selects secure query operators such as PrivateJoin and PrivateFilter. The system then analyzes various possible query paths, such as filtering transaction records first and then joining them with customer information, or joining the two tables first and then filtering. By comprehensively considering the cost and security of each approach, the system ultimately selects the most suitable query plan to execute the task. Throughout the process, all selected secure query operators ensure the consistency of the number of input and output rows, thereby effectively protecting the customer's privacy information. Finally, the system successfully returns results that meet the user's needs and have undergone rigorous security processing, satisfying the user's query requirements while fully guaranteeing data security.

[0079] Furthermore, before obtaining the data description information and security query operators from the data source and determining the target query plan from the candidate query plans of at least one data source, the method further includes: determining the combination method of the security query operators and generating at least one candidate query plan corresponding to the query request based on the combination method.

[0080] A candidate query plan refers to multiple possible schemes for executing a user query, generated based on different combinations of secure query operators. Each candidate plan describes how to access and process data in the data source through a series of operations to satisfy the user's query request. These plans consider factors such as different operation sequences, indexes used, join strategies, etc., and combine the characteristics of secure query operators, aiming to find a suitable path to complete the query task.

[0081] In practical applications, after the system determines the initial query operators and converts them into corresponding safe query operators, the next step is to determine the appropriate combination of these safe query operators. For example, suppose a query request requires a join operation on the `orders` and `lineitem` tables, followed by sorting and filtering of the results. The system first identifies that `PrivateJoin` is needed for the table join, followed by `PrivateSort` for sorting and `PrivateFilter` for filtering. Next, based on these safe query operators and their combinations, the system generates at least one candidate query plan. For example, one combination might be to first execute `PrivateJoin`, then `PrivateSort`, and finally apply `PrivateFilter`; another combination might be to first perform `PrivateFilter` to filter out unnecessary data, and then execute `PrivateJoin` and `PrivateSort`. The system evaluates the cost of each combination based on data description information and selects the target query plan that best suits the current query requirements.

[0082] In the embodiments described in this specification, by determining a suitable combination of secure query operators and generating at least one candidate query plan based on this, the system can efficiently complete query tasks while ensuring data security. This method enables the system to flexibly respond to various query needs and provide rapid response capabilities even in complex privacy-preserving environments. Furthermore, since each secure query operator is designed to maintain consistency in the number of input and output rows, privacy protection measures throughout the entire data processing flow are further strengthened.

[0083] For example, in a task on an online retail platform, a user wants to obtain sales statistics for a certain type of product over the past month, including total sales and order quantity. The system first parses the user's query request, selecting PrivateJoin to join the `orders` and `lineitem` tables, PrivateAggregate to calculate total sales and order quantity, and PrivateSort to sort the results in descending order of sales. Next, the system determines several possible safe combinations of query operators: one is to first execute PrivateJoin, then apply PrivateAggregate, and finally perform PrivateSort; another is to first use PrivateFilter to filter relevant records, and then execute PrivateJoin, PrivateAggregate, and PrivateSort sequentially. Based on the data description information, the system evaluates the cost of each combination and ultimately selects the target query plan that has the lowest cost and meets the security requirements for execution.

[0084] Furthermore, the process involves obtaining data description information and security query operators from the data source, and determining the target query plan from candidate query plans of at least one data source. This includes: for any candidate query plan, identifying the target security query operator included in the candidate query plan, and determining the cost calculation method corresponding to the target security query operator; calculating the planned query cost corresponding to the candidate query plan based on the data description information and the cost calculation method corresponding to the target security query operator; and determining the target query plan based on the planned query cost.

[0085] Each target security query operator has its corresponding cost calculation method, which is usually in the form of a formula or function to estimate the resource consumption required to execute the operator. For example, for a PrivateJoin operation, the cost calculation method may be based on the size of the data tables involved in the join and the selectivity of the join conditions; while for a PrivateSort operation, the cost calculation method may consider factors such as the amount of data to be sorted and whether it is already partially sorted.

[0086] In practical applications, after the system obtains the data description information from the data source and determines a series of candidate query plans, the next step is to conduct a detailed evaluation of each candidate query plan. First, the system identifies all target safe query operators included in the candidate query plans and determines the cost calculation method for each target safe query operator. For example, in a query involving multiple table joins and aggregation operations, the system might identify PrivateJoin and PrivateAggregate as target safe query operators and define cost calculation methods for each of these operators. Assume the cost calculation formula for PrivateJoin is C_join = N*M (where N and M are the number of rows in the two tables, respectively), and the cost calculation formula for PrivateAggregate is C_aggregate = K*log(K) (where K is the number of input records).

[0087] Next, the system calculates the planned query cost for each candidate query plan based on the cost calculation method corresponding to the data description information and the target security query operator. For example, if the data description information shows that the `orders` table has 100 rows and the `lineitem` table has 200 rows, and aggregation processing is required on the joined results, then according to the above formula, the cost of `PrivateJoin` will be 100 * 200 = 20,000. Assuming the size of the result set before the aggregation operation is 20,000, then the cost of `PrivateAggregate` will be 20,000 * log(20,000). By summing the costs of each operator, the total cost of the entire query plan can be obtained.

[0088] Finally, the system determines a suitable target query plan based on the calculated planned query cost. Specifically, the system selects the candidate query plan with the lowest planned query cost as the final execution option. This method not only improves query efficiency and reduces unnecessary resource consumption, but also ensures data security throughout the entire processing.

[0089] In the embodiments described in this specification, by combining data description information with the cost calculation method of the target security query operator, the system can accurately evaluate the cost of each candidate query plan and select the appropriate target query plan accordingly. This not only improves query performance but also ensures data security and privacy protection. Especially when dealing with complex query operations, accurate cost estimation can help the system make more intelligent decisions, thereby achieving an efficient data processing workflow.

[0090] For example, in a task on an e-commerce data analysis platform, a user wants to understand the sales performance of a certain type of product and its associated order details within a specific time period. The system first parses the user's query request, selects several safe query operators including PrivateJoin and PrivateAggregate, and generates several candidate query plans. Next, the system obtains the data description information from the `orders` and `lineitem` tables, finding that the `orders` table has 100 rows and the `lineitem` table has 200 rows. Based on this information and the cost calculation methods of each safe query operator, the system calculates the planned query cost for each combination. For example, for a combination that executes PrivateJoin first and then PrivateAggregate, the costs are 100*200 = 20,000 and 20,000*log(20,000), respectively. By comparing the costs of all candidate plans, the system selects the one with the lower cost as the target query plan for execution.

[0091] Furthermore, determining the target query plan based on the planned query cost includes: discarding the candidate query plan corresponding to the planned query cost when the planned query cost is greater than a preset threshold; and determining the candidate query plan corresponding to the planned query cost as the target query plan when the planned query cost is less than or equal to the preset threshold.

[0092] In the process of optimizing query plans, the Volcano Model is a commonly used cost-based query optimization method. It explores all possible execution plans through breadth-first search and heuristics, and utilizes dynamic programming and equivalence class sets to avoid redundant computations, thereby finding a relatively suitable physical execution plan. The preset threshold refers to a cost upper limit set by the system based on factors such as resource constraints and performance requirements, used to filter out acceptable query plans.

[0093] In practical applications, after the system calculates the planned query cost for each candidate query plan, it compares these cost values ​​with preset thresholds to determine the final target query plan. The specific process is as follows:

[0094] The Volcano algorithm iteratively processes each candidate query plan. First, it selects an initial candidate query plan and calculates its planned query cost. If the calculated cost exceeds a preset threshold, the candidate query plan is considered unacceptable and discarded. Next, the Volcano algorithm continues to select the next candidate query plan for evaluation. This process is iterative until a candidate query plan with a planned query cost less than or equal to the preset threshold is found. Once a plan meeting the criteria is found, it is designated as the target query plan, and further searching ceases.

[0095] For example, in a task on an e-commerce data analytics platform, a user wants to obtain the sales data of a certain type of product and its associated order details within a specific time period. The system generates multiple candidate query plans, including different table join orders and the timing of filter application. Suppose one candidate query plan involves first performing a PrivateJoin operation on the `orders` and `lineitem` tables, and then applying PrivateFilter and PrivateAggregate operations. The system first calculates the cost of this plan. If the cost is 50,000, and the preset threshold is 40,000, this plan is discarded because the cost is too high. The Volcano algorithm then moves on to evaluate the next candidate query plan, such as first applying PrivateFilter to filter out unnecessary data, and then performing PrivateJoin and PrivateAggregate operations. If the calculated cost this time is 38,000, which is lower than the preset threshold, then this plan is selected as the target query plan.

[0096] This method not only improves query efficiency and reduces resource consumption, but also ensures the system's flexibility and intelligence. By setting reasonable preset thresholds, the complexity and resource requirements of query execution can be effectively controlled, avoiding the execution of excessively time-consuming or resource-intensive query plans. The iterative nature of the Volcano algorithm allows the system to gradually approach a suitable solution from numerous candidate plans until a target query plan that meets both performance requirements and security protection standards is found.

[0097] In the embodiments described in this specification, by combining the iterative mechanism of the Volcano algorithm with preset thresholds, the system can effectively select the most suitable execution plan from multiple candidate query plans. This method not only improves query performance but also ensures data security and privacy protection. Especially when facing complex query tasks, the Volcano algorithm can intelligently evaluate and select appropriate paths, ensuring an efficient data processing flow. Throughout the process, the system continuously iterates and tries until it finds a query plan that is cost-effective and meets security requirements, achieving efficient resource utilization and maximizing query performance.

[0098] For example, in the e-commerce data analysis platform example above, the Volcano algorithm evaluated multiple candidate query plans sequentially. The first plan was discarded because its cost exceeded a preset threshold. The Volcano algorithm continued to evaluate the next plan, and after several iterations, finally found a plan with a cost of 38,000, which was below the preset threshold of 40,000, and was therefore selected as the target query plan.

[0099] Furthermore, the data query method also includes: when the query texts of multiple plans corresponding to candidate query plans are all greater than a preset threshold, sorting is performed on the query costs of multiple plans to obtain a sorting result; based on the sorting result, the target query plan is determined from the candidate query plans.

[0100] In some complex query scenarios, the cost of all generated candidate query plans may exceed a preset performance threshold. Nevertheless, the system still needs to select a relatively optimal execution plan to fulfill the user's query request. To this end, the system first sorts the query costs of all candidate plans, generating a ranking result from lowest to highest cost. This process ensures that even if all plan costs exceed expectations, the system can still select the plan with the lowest cost to execute, thereby minimizing resource consumption and improving response speed.

[0101] In practical applications, when the system finds that the cost of all candidate query plans exceeds a preset threshold, it does not immediately abandon the query task but takes further measures to optimize the selection process. First, the system sorts the costs of all candidate query plans, generating a ranking result from lowest to highest cost. For example, in a multi-table join and aggregation analysis task, suppose the system generates four candidate query plans with costs of 50,000, 45,000, 42,000, and 41,000 units respectively. The system sorts these costs from lowest to highest, resulting in a ranking result of [41,000, 42,000, 45,000, 50,000]. Next, based on this ranking result, the system selects the plan with the lowest cost from all candidate query plans as the target query plan. In this example, the plan with a cost of 41,000 is selected as the target query plan. Although its cost is still higher than the preset threshold, it is a suitable choice among all current options, satisfying the user's query needs to a certain extent while minimizing resource consumption.

[0102] In the embodiments described in this specification, by sorting the costs of all candidate query plans and selecting the plan with the lowest cost as the target query plan when costs exceed a preset threshold, the system can complete the query task as efficiently as possible. This method not only improves query efficiency and reduces unnecessary resource waste, but also ensures the flexibility and intelligence of the system. Through meticulous cost evaluation and sorting, the system can maintain good performance in complex query environments, ensuring an efficient data processing flow. Furthermore, this strategy allows the system to provide a feasible solution even when the costs of all plans exceed expectations, maximizing query performance and data processing efficiency.

[0103] For example, in a task on an e-commerce data analysis platform, a user wants to obtain the sales data of a certain type of product and its associated order details within a specific time period. The system generates multiple candidate query plans based on factors such as different table join orders and the timing of filter application. However, after calculating the cost of each plan, it is found that the cost of all plans exceeds the preset threshold of 40,000 units. Faced with this situation, the system sorts the costs of these plans, obtaining the sorted results [41,000, 42,000, 45,000, 50,000]. Then, the system selects the plan with the lowest cost of 41,000 units as the target query plan. Throughout the process, through meticulous cost evaluation and sorting, the system ultimately selects the query plan with the lowest cost, satisfying the user's query needs while achieving efficient resource utilization. In this way, even when the cost of all plans exceeds expectations, the system can still provide a feasible and efficient solution.

[0104] Furthermore, based on the cost calculation method corresponding to the data description information and the target security query operator, the planned query cost corresponding to the candidate query plan is calculated, including: determining the header security query operator and the intermediate security query operator in the target security query operator; calculating the header cost and intermediate results based on the cost calculation method corresponding to the data description information and the header security query operator; obtaining the intermediate description information corresponding to the intermediate results; calculating the intermediate cost based on the cost calculation method corresponding to the intermediate security query operator based on the intermediate description information; and calculating the planned query cost corresponding to the candidate query plan based on the header cost and the intermediate cost.

[0105] A head-safe query operator is a safe query operator that appears first in the execution order of a candidate query plan; it is the first step in processing the data flow. For example, if a query plan first performs a join operation on two tables, then the PrivateJoin operation corresponding to that join operation is a head-safe query operator.

[0106] Intermediate safe query operators refer to all other safe query operators besides the header safe query operators. These operators process the data stream output by the previous operator in a specific order until the entire query plan is completed. For example, after the header operator, there may be aggregation operations (such as PrivateAggregate) or filtering operations (such as PrivateFilter), which are intermediate safe query operators.

[0107] Cost calculation methods refer to the formulas or functions used to estimate the resource consumption required to execute each security query operator. Different operator types have different cost calculation methods, which are usually determined based on data description information such as the amount of input data and the uniqueness of columns.

[0108] In practical applications, when a system needs to calculate the planned query cost of a candidate query plan, it first distinguishes between head-safe and intermediate-safe query operators within the target safe query operators. Suppose that in a task on an e-commerce data analysis platform, a user wants to obtain the sales data of a certain type of product and its associated order details within a specific time period. Assume the query plan first uses PrivateJoin to join the orders and lineitem tables, and then uses PrivateAggregate to aggregate the results. In this example, PrivateJoin is the head-safe query operator, while PrivateAggregate is the intermediate-safe query operator.

[0109] Next, the system calculates the header cost and intermediate results based on the data description information and the cost calculation method corresponding to the header security query operator. For example, if the `orders` table has 100 rows and the `lineitem` table has 200 rows, and the cost calculation formula for `PrivateJoin` is `C_join = N*M` (where N and M are the number of rows in the two tables, respectively), then the header cost is 100 * 200 = 20,000. Simultaneously, the system also records relevant information about the intermediate results, such as the size of the joined result set being 20,000 rows.

[0110] Then, the system obtains the intermediate description information corresponding to the intermediate results, and calculates the intermediate cost based on this information and the cost calculation method corresponding to the intermediate security query operator. Continuing the above example, assuming the cost calculation formula for PrivateAggregate is C_aggregate=K*log(K) (K is the number of input records), then the intermediate cost is 20,000*log(20,000).

[0111] Finally, the system calculates the planned query cost corresponding to the candidate query plan based on the header cost and the intermediate cost. In this example, the total planned query cost is the header cost plus the intermediate cost, which is 20,000 + (20,000 * log(20,000)).

[0112] In the embodiments described in this specification, by explicitly distinguishing between head-level and intermediate-level security query operators and calculating their costs separately, the system can more accurately assess the total cost of the entire query plan. This method not only improves query efficiency and reduces unnecessary resource consumption but also ensures data security throughout the processing. Especially when dealing with complex query operations, accurate cost estimation can help the system make more intelligent decisions, thereby achieving an efficient data processing flow. Furthermore, this strategy enables the system to maintain good performance in complex query environments, ensuring an efficient data processing flow.

[0113] For example, in a task on an online retail platform, a user wants to see all orders placed within the last month, sorted in ascending order by order date. The system first parses the user's query request, selecting `PrivateJoin` to join the `orders` and `customer` tables, and `PrivateSort` to sort by order date. In this query plan, `PrivateJoin` acts as a header-safe query operator, with a cost calculated based on 100 rows from the `orders` table and 200 rows from the `customer` table: 100 * 200 = 20,000. Subsequently, the system records relevant information about the intermediate results, including the size of the joined result set being 20,000 rows. Next, for the intermediate-safe query operator `PrivateSort`, the system calculates its cost based on the description information of the intermediate results: 20,000 * log(20,000). Finally, the system adds the header cost and the intermediate cost to obtain the total cost of the entire query plan. This satisfies the user's query needs while achieving efficient resource utilization.

[0114] Furthermore, the data source is a data table, and the data description information includes the number of rows in the data table. Based on the data description information and the cost calculation method corresponding to the header security query operator, the header cost and intermediate results are calculated, including: calculating the header cost based on the number of rows and the cost calculation method corresponding to the header security query operator; executing the header security query operator based on the data table to obtain intermediate results; the intermediate description information includes the number of rows in the intermediate results; and the intermediate cost is calculated based on the intermediate description information and the cost calculation method corresponding to the intermediate security query operator, including: calculating the intermediate cost based on the number of rows in the intermediate results and the cost calculation method corresponding to the intermediate security query operator.

[0115] In practical applications, when a system executes a series of security protection operators, multiple intermediate tables are generated. The system utilizes Calcite's built-in functionality to obtain metadata for these intermediate tables, including row count information and whether specified columns are unique or ordered. For example, after the first security protection operator is executed, the system can deduce the input row count for the next intermediate operator based on its output row count information. Suppose that in a task on an e-commerce data analysis platform, a user wants to obtain the sales data of a certain type of product and its associated order details within a specific time period. The query plan first uses PrivateJoin to join the orders table (100 rows) and the lineitem table (200 rows), resulting in an intermediate result set of 200 rows.

[0116] Based on the row count information of the intermediate results, the system can further deduce the output row count of subsequent intermediate safe query operators. For example, if the next step is to perform an aggregation operation (such as PrivateAggregate) on the join results, the system will calculate the cost of the aggregation operation based on the row count information of the intermediate results and add it to the total planned query cost. Assuming the cost calculation formula for PrivateAggregate is C_aggregate = K * log(K) (where K is the number of input records), then the intermediate cost is 20,000 * log(20,000).

[0117] For each intermediate safe query operator, the system repeats this process: first, it uses Calcite's built-in functions to infer the metadata of the intermediate table (such as the number of rows, the uniqueness and order of columns), then calculates the cost of the current operator based on this information, and passes the output row count to the next operator as the input row count. In this way, the system can progressively derive the total cost of the entire query plan.

[0118] In the embodiments described in this specification, the system can more accurately assess the total cost of the entire query plan. This method not only improves query efficiency and reduces unnecessary resource consumption, but also ensures data security throughout the processing. Especially when dealing with complex query operations, accurate cost estimation can help the system make more intelligent decisions, thereby achieving an efficient data processing workflow.

[0119] For example, in a task on an online retail platform, a user wants to see all orders placed within the last month, sorted in ascending order by order date. The system first parses the user's query request, selecting PrivateJoin to join the orders table (100 rows) and the customer table (2000 rows), and PrivateSort to sort by order date. In this query plan, PrivateJoin acts as a head-safe query operator, with a cost calculated based on the number of rows in both tables as 100 * 200 = 20,000. Subsequently, the system executes the PrivateJoin operation, obtaining intermediate results; assuming the result set size after the join is 20,000 rows.

[0120] Next, the system uses Calcite's built-in functions to infer the metadata of the intermediate table, including the number of rows, whether certain columns are unique, and whether they are ordered. Assuming the system finds that the order date column is already partially ordered, this helps optimize the cost calculation of the PrivateSort operation. Based on the row count information of the intermediate results and the cost calculation method corresponding to the intermediate safe query operator, the system calculates the cost of PrivateSort to be 20,000*log(20,000).

[0121] Ultimately, the system adds the header cost to the intermediate cost to obtain the total cost of the entire query plan. In this way, the system not only meets the user's query needs but also achieves efficient resource utilization. Throughout the process, the system uses meticulous cost evaluation and calculation to ultimately select a suitable query plan, maximizing query performance and data processing efficiency. Furthermore, the system utilizes Calcite's built-in functions to dynamically acquire and infer metadata from intermediate tables, making the entire query processing flow more intelligent and efficient.

[0122] One embodiment of this specification implements receiving a data query request, determining at least one data source corresponding to the data query request, determining a corresponding security query operator based on the data query request, obtaining data description information of the data source, determining a target query plan from candidate query plans of at least one data source based on the data description information and the security query operator, and obtaining the query result corresponding to the data query request based on the target query plan. The candidate query plans are used to indicate the execution order of at least one data source in the security query operator. By combining data source description information and security query operators, a suitable target query plan is dynamically selected from multiple candidate query plans, while avoiding performance degradation caused by default selection of query plans incompatible with the security protection scenario. This significantly improves query execution efficiency and overall system performance while ensuring data security. Thus, even in complex security protection scenarios, the system can dynamically adapt and optimize the query processing, meeting users' dual needs for data security and fast access.

[0123] The following is in conjunction with the appendix Figure 3 Taking the data query method provided in this specification as an example in the application of e-commerce data query, the data query method will be further explained. Among other things, Figure 3 This is a schematic diagram of the processing procedure of a data query method provided in one embodiment of this specification, which specifically includes the following steps.

[0124] Step 302: Design security protection operators and register them in the optimizer.

[0125] Specifically, Calcite developers provide an interface for custom operators, allowing developers to inherit commonly used database operators such as Project, Filter, and Join. In this step, developers modify the corresponding computational cost and the number of rows in the output table for each logical operator. The optimizer automatically adjusts the physical plan based on the computational cost and the number of rows. Because the access pattern of operator computation is typically protected under the security protection model—meaning the computational cost and the number of rows in the output table are the same regardless of the data in the table—the cost estimation here is more accurate than in traditional databases, further enhancing the importance of the optimizer. The table below lists the details of the security protection operators, assuming the number of rows in the input tables is n, and the security protection model is a suitable algorithm in MPC that satisfies access pattern protection. For the Join (natural join) operator, if the two input tables satisfy the property that the condition column of the natural join is unique in at least one of the tables, then the corresponding security protection operator is PrivateKeyJoin, which can be used to reduce computational cost and the number of output rows; otherwise, the corresponding security protection operator is PrivateJoin.

[0126] Table 1: Correspondence between logical operators and security protection operators

[0127] Logical operator name Security protection operator name Output line number Calculation cost Aggregate PrivateAggregate n n*log(n) Correlate PrivateCorrelate n^2 n^2 Filter PrivateFilter n n Intersect PrivateIntersect n n*log(n) Join PrivateJoin n^2 n^2 PrivateKeyJoin n n*log(n) Project PrivateProject n n Sort PrivateSort n n*log(n) Union PrivateUnion 2n 2n*log(n)

[0128] Table 1 shows the names of logical operators, security protection operators, the number of output rows for a security protection operator with n input rows, and the computational cost of the security protection operator. Specifically, Aggregate corresponds to PrivateAggregate (safe aggregation), with n output rows and a computational cost of nlog(n); Correlate corresponds to PrivateCorrelate (safe correlation), with n^2 output rows and a computational cost of n^2; Filter corresponds to PrivateFilter (safe filtering), with n output rows and a computational cost of n; Intersect corresponds to PrivateIntersect (safe intersection), with n output rows and a computational cost of nlog(n); Join usually corresponds to Private... eJoin (secure join) outputs n^2 rows and has a computation cost of n^2. However, if the natural join condition column is unique in at least one table, then PrivateKeyJoin (private key join) is used, which outputs n rows and has a computation cost of nlog(n). Project corresponds to PrivateProject (secure projection), outputs n rows and has a computation cost of n. Sort corresponds to PrivateSort (secure sort), outputs n rows and has a computation cost of nlog(n). Union corresponds to PrivateUnion (secure union), outputs 2n rows and has a computation cost of 2n*log(n).

[0129] Step 304: Define metadata maintenance and application rules for security protection operators.

[0130] Specifically, under traditional security protection models, because data is usually stored in encrypted form, the optimizer cannot directly use the data content to optimize the logical plan. However, non-sensitive metadata information (such as column names, the number of rows in a table, and whether the data is unique or ordered) is very useful for the optimization process.

[0131] Developers can define how to maintain metadata as follows: First, provide the optimizer with relevant metadata information for the input tables. For intermediate tables generated during the calculation process, the system infers the number of rows in the generated table based on the output row count information provided by the security protection operator, and uses Calcite's functionality to evaluate the uniqueness and order of data on specific columns.

[0132] For specific security protection operators, the application of metadata can follow these rules:

[0133] If the table operated on by the PrivateAggregate operator is unique on the grouping column, or if the two columns involved by the PrivateIntersect operator are unique in their respective tables, the computational cost of these operators can be reduced from n*log(n) to n. This is because when using PrivateAggregate for aggregation operations, if the values ​​on the grouping column are unique, it means that each group contains only one row of data, so there is no need for complex aggregation calculations, and the original data can be output directly. Similarly, for the PrivateIntersect operator, if the two columns involved are unique in their respective tables, it means that every value in these columns is unique, which greatly simplifies the process of finding the intersection, because it is only necessary to check if there are identical unique values ​​without comparing each record. In this way, the computational cost can be reduced from n*log(n) to linear n.

[0134] When the tables processed by the PrivateAggregate operator are sorted on the grouping column, or when both tables of the PrivateKeyJoin operator are ordered on the condition columns, the computational cost of these operators can also be reduced from n*log(n) to n. This is because the algorithm can leverage this pre-sorted order to optimize execution. For example, when processing PrivateAggregate, if the data is already sorted by the grouping column, rows belonging to the same group are necessarily adjacent, allowing for more efficient aggregation calculations. For PrivateKeyJoin, if both tables are ordered on the join condition columns, matches can be efficiently obtained by calling a privacy intersection protocol instead of a sorting algorithm.

[0135] If the PrivateSort operator is applied to a table that is already sorted on the unsorted sequence, the operator will be omitted because it no longer requires a sorting operation. This is because if the input data is already sorted according to the specified sorting rules, then theoretically, a sorting operation is unnecessary. The main purpose of sorting is to make unordered data ordered, but if the data itself already satisfies this condition, the step becomes redundant. Therefore, in this case, the PrivateSort operator can be directly omitted because it no longer provides any value and saves unnecessary computational resources.

[0136] When appropriate, the system will automatically identify and convert the Join operator into a PrivateKeyJoin operator to improve efficiency and security.

[0137] In this way, the optimizer not only enhances query security, but also ensures that query performance can still be optimized even after security protection measures are applied.

[0138] Step 306: Replace the default optimization logic in the optimizer for security protection operators, metadata maintenance, and application rules.

[0139] Specifically, to replace the default logic of the Calcite optimizer with the security-protected optimization logic within the optimizer, after generating the initial logical plan, all standard logical operators in the plan are first replaced with the corresponding security-protected operators. Next, Calcite's Volcano optimization algorithm is used to further optimize the updated logical plan. The Volcano algorithm aims to find a low-cost execution plan. It explores suitable total cost paths through breadth-first search combined with heuristics, and uses dynamic programming and equivalence class sets to avoid redundant calculations, efficiently returning a superior physical execution plan. Because the optimizer has made specific adjustments to the cost calculation logic of each operator to adapt to security protection requirements, the Volcano optimization algorithm automatically adjusts its optimization strategy based on these modifications, ensuring that the final generated physical plan meets the requirements of the security protection model. This not only strengthens the security of data processing but also ensures that the system can still provide efficient query performance under the new cost evaluation framework.

[0140] Step 308: Receive the user's query information and determine the security protection operator required for the query.

[0141] Specifically, the system receives user queries. The user wants recommendations based on the following table from the social media platform and the orders and lineitem tables from the shopping mall. The recommendations should include all items purchased by the user's followers that are priced below 100 yuan, white in color, and weigh less than 10 kilograms. Based on this requirement, the user submitted the following SQL query:

[0142] SELECT DISTINCT f.userid, l.itemid / / Select unique user IDs and the item IDs purchased by their followers.

[0143] from following f, orders o, lineitem l / / Select data from three tables: following, orders, and lineitem.

[0144] where f.followid = o.userid / / Relationship between followid in the following table and userid in the orders table

[0145] and o.itemid = l.itemid / / Then associate the itemid in the orders table with the itemid in the lineitem table

[0146] and l.price<100 / / Filter out products priced below 100 yuan

[0147] and l.color = 'white' / / Filter out products that are white.

[0148] and l.weight<10; / / Filter out products weighing less than 10 kg.

[0149] The main operations involved in this query include:

[0150] Join: Perform a natural join on the following, orders, and lineitem tables to find product information purchased by users who meet the criteria and the people they follow.

[0151] Filter: Apply filtering conditions to the results after connection to select products that meet the criteria (price below 100 yuan, color is white, weight is less than 10 kg).

[0152] Project: Finally, select the fields to be displayed from the filtered results (i.e., user ID and product ID), and ensure the uniqueness of the results using the distinct keyword.

[0153] Step 310: Generate a physical plan based on the replaced optimization logic.

[0154] Specifically, in order to execute a query, the optimizer may provide two join orders in the execution plan: (1) join the following table with the orders table first, and then join the result with the lineitem table; (2) join the orders table with the lineitem table first, and then join the result with the following table.

[0155] Step 312: Execute the physical plan query data and return it to the user.

[0156] Specifically, to compare the differences between the traditional optimizer and the optimizer that replaces the optimization logic in step 306, the process of the traditional optimizer generating the physical plan is given below:

[0157] LAN = ToEnumerableConverter / / Converts data into an enumerable form for easier subsequent processing.

[0158] Aggregate(group=[{0,2}]) / / Performs an aggregation operation on the data, grouping it based on columns 0 and 2.

[0159] Join(condition=[=($1,$6)],joinType=[inner]) / / Performs an inner join operation, provided that column 1 of the first table is equal to column 6 of the second table.

[0160] TableScan(table=[[following]]) / / Scans the following table to obtain information about users and their followers.

[0161] Join(condition=[=($5,$0)],joinType=[inner]) / / Another inner join operation, the condition is that column 5 in the previous join result is equal to column 0 in the orders table.

[0162] Filter(condition=[AND(<($1,100),=($2,'white'),<($3,10))]) / / Apply a filter to select items with a price below 100, white color, and weight less than 10.

[0163] TableScan(table=[[lineitem]]) / / Scans the lineitem table to obtain the relevant attributes of the product.

[0164] Project(userid=[$0],itemid=[$1]) / / Projection operation, selects the userid and itemid columns from the orders table.

[0165] TableScan(table=[[orders]]) / / Scans the orders table to retrieve order information.

[0166] That is, plan (2) in step 310 was selected.

[0167] The following describes the process by which the optimizer generates the physical plan in step 306, which involves replacing the optimization logic:

[0168] PrivateAggregate(group=[{0,1}]) / / Performs aggregation operation on the data, grouping based on column 0 and column 1.

[0169] PrivateProject(userid=[$0],itemid=[$4]) / / Projection operation, selects specific columns (here userid anditemid).

[0170] PrivateJoin(condition=[=($3,$4)],joinType=[inner]) / / Performs an inner join operation, provided that column 3 of the first table is equal to column 4 of the second table.

[0171] PrivateJoin(condition=[=($1,$2)],joinType=[inner]) / / Another inner join operation, the condition is that the first column of the previous join result is equal to the second column of the orders table.

[0172] PrivateTableScan(table=[[following]]) / / Scans the following table to obtain information about users and their followers.

[0173] PrivateProject(userid=[$0],itemid=[$1]) / / Projection operation, selects specific columns (userid anditemid) from the orders table.

[0174] PrivateTableScan(table=[[orders]]) / / Scans the orders table to retrieve order information.

[0175] PrivateFilter(condition=[AND(<($1,100),=($2,'white'),<($3,10))]) / / Apply a filter to select items with a price below 100, white color, and weight less than 10.

[0176] PrivateTableScan(table=[[lineitem]]) / / Scan the lineitem table to obtain the relevant attributes of the product.

[0177] That is, plan (1) in step 310 was selected. Plan (1) has a lower cost than plan (2) because in the process of generating the physical plan, the traditional optimizer estimates the size of the filtered result set for the table lineitem (which has 150 rows) based on filtering conditions (price less than 100, color is white, weight less than 10). Assuming that based on these conditions, the optimizer guesses that the number of remaining rows after filtering will be less than 100 rows, it decides to join the filtered lineitem with the orders table first (i.e., select plan (2)). This strategy relies on reducing the amount of data involved in subsequent join operations, thereby theoretically reducing the computational cost.

[0178] However, this logic no longer holds true under a privacy-preserving model. Because it's necessary to protect data access patterns from being leaked to external entities, even after filtering, the number of rows in the `lineitem` table remains unchanged at 150. The rows that are actually filtered out are not truly deleted; instead, they are filled with useless data to ensure that the size of the intermediate calculation results does not reveal any information. This means that in a privacy-preserving scenario, the result set after performing a filtering operation on the `lineitem` table is still actually 150 rows, only some of which are invalid data.

[0179] Therefore, applying the logic of traditional optimizers to the security protection model can lead to incorrect cost estimations and suboptimal physical plan selection. Traditional optimizers fail to consider the impact of privacy protection measures, still evaluating the size of the filtered dataset and making optimization decisions based on the number of unfilled rows. This results in physical plans that do not reflect reality (i.e., the actual number of rows after considering security protection). Specifically, the optimizer might choose to perform join operations on the larger dataset first, without fully utilizing the capabilities of privacy-preserving operators for more efficient resource allocation and execution ordering, ultimately increasing the overall query processing cost.

[0180] It is understandable that the examples given in steps 302-312 above and the content of Table 1 are all examples under the MPC scenario. In the TEE and FHE scenarios, the correspondence between the logical operator name and the security protection operator name, the number of output rows of the security protection operator with n rows of input, and the computational cost of the security protection operator will be somewhat different from the content of Table 1. For details, please refer to the actual application scenario and the design decision of the optimizer designer. It will not be elaborated here.

[0181] Corresponding to the above method embodiments, this specification also provides embodiments of a data query device. Figure 4 This is a schematic diagram of the structure of a data query device provided in one embodiment of this specification. Figure 4 As shown, the device includes:

[0182] The data source determination module 402 is configured to receive data query requests and determine at least one data source corresponding to the data query request.

[0183] Operator determination module 404 is configured to determine the corresponding security query operator based on the data query request.

[0184] The plan determination module 406 is configured to obtain data description information of the data source, determine the target query plan from candidate query plans of at least one data source based on the data description information and the security query operator, and obtain the query results corresponding to the data query request based on the target query plan. The candidate query plans are used to indicate the execution order of at least one data source in the security query operator.

[0185] Optionally, the operator determination module 404 is further configured to generate a corresponding query statement based on the data query request; perform syntax analysis on the query statement to determine the query features corresponding to the query statement, and determine the initial query operator corresponding to the query request based on the query features; and determine the security query operator corresponding to the initial query operator based on the query features.

[0186] Optionally, the operator determination module 404 is further configured to obtain a data description information of the data source and an operator correspondence table; determine at least one candidate safe operator corresponding to the initial query operator in the operator correspondence table; and determine the hit safe query operator among the at least one candidate safe operator based on the data description information.

[0187] Optionally, the operator determination module 404 is further configured to obtain data description information of the data source; and remove the initial query operator if the data description information ensures that the data source does not need to perform the query operation corresponding to the query feature.

[0188] Optionally, the data query device further includes a plan generation module, configured to determine the combination of secure query operators and generate at least one candidate query plan corresponding to the query request based on the combination.

[0189] Optionally, the plan determination module 406 is further configured to, for any candidate query plan, determine the target security query operator included in the candidate query plan, and determine the cost calculation method corresponding to the target security query operator; calculate the planned query cost corresponding to the candidate query plan based on the data description information and the cost calculation method corresponding to the target security query operator; and determine the target query plan based on the planned query cost.

[0190] Optionally, the plan determination module 406 is further configured to discard the candidate query plan corresponding to the plan query cost if the plan query cost is greater than a preset threshold; and to determine the candidate query plan corresponding to the plan query cost as the target query plan if the plan query cost is less than or equal to the preset threshold.

[0191] Optionally, the plan determination module 406 is further configured to perform sorting processing on the multiple plan query costs when the multiple plan query texts corresponding to the candidate query plans are all greater than a preset threshold, and obtain a sorting result; based on the sorting result, determine the target query plan from the candidate query plans.

[0192] Optionally, the plan determination module 406 is further configured to: determine the header security query operator and the intermediate security query operator in the target security query operator; calculate the header cost and intermediate results based on the data description information and the cost calculation method corresponding to the header security query operator; obtain the intermediate description information corresponding to the intermediate results; calculate the intermediate cost based on the intermediate description information and the cost calculation method corresponding to the intermediate security query operator; and calculate the planned query cost corresponding to the candidate query plan based on the header cost and the intermediate cost.

[0193] Optionally, the data source is a data table, and the data description information includes the number of rows in the data table; the planning determination module 406 is further configured to calculate the header cost based on the row number information and the cost calculation method corresponding to the header security query operator; execute the header security query operator based on the data table to obtain intermediate results; and calculate the intermediate cost based on the row number information of the intermediate results and the cost calculation method corresponding to the intermediate security query operator.

[0194] Applied to this data query device, firstly, the data source determination module 402 receives the user's data query request and identifies at least one data source related to the request; then, the operator determination module 404 determines which security query operators need to be used for data protection and processing based on the specific requirements of the query request; then, the plan determination module 406 uses the obtained data source description information (such as the number of rows in the table, the uniqueness or order of columns, etc.) and the determined security query operators to dynamically select the target query plan (406) that best suits the current security protection scenario from all possible data source candidate query plans. This process ensures that even under complex security protection requirements, the system can intelligently avoid those default but inappropriate query plans, preventing performance degradation caused by this. Ultimately, while ensuring data security, a significant improvement in query execution efficiency and overall system performance is achieved, meeting the user's dual needs for data security and fast access. In this way, the entire mechanism not only enhances the system's flexibility and adaptability but also optimizes the query processing flow, enabling efficient response to different security protection requirements.

[0195] The above is an illustrative scheme of a data query device according to this embodiment. It should be noted that the technical solution of this data query device and the technical solution of the data query method described above belong to the same concept. For details not described in detail in the technical solution of the data query device, please refer to the description of the technical solution of the data query method described above.

[0196] Figure 5A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0197] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0198] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0199] Computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). Computing device 500 can also be a mobile or stationary server.

[0200] The memory 510 is used to store computer programs / instructions, and the processor 520 is used to execute the computer programs / instructions stored in the memory 510. When the computer programs / instructions are executed by the processor, they implement the steps of the above-mentioned data query method.

[0201] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data query method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the data query method described above.

[0202] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the data query method described above.

[0203] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the data query method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the data query method described above.

[0204] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data query method.

[0205] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the data query method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the data query method described above.

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

[0207] The computer program / instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0208] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0209] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0210] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A data query method, comprising: Receive a data query request and determine at least one data source corresponding to the data query request; Determine the corresponding security query operator based on the data query request; Obtain data description information from the data source; determine a target query plan from candidate query plans of the at least one data source based on the data description information and the security query operator; obtain the query result corresponding to the data query request based on the target query plan; wherein the candidate query plan is used to indicate the execution order of the at least one data source in the security query operator.

2. The method according to claim 1, wherein determining the corresponding security query operator based on the data query request includes: Generate a corresponding query statement based on the data query request; The query statement is parsed to determine the query features corresponding to the query statement, and the initial query operator corresponding to the query request is determined based on the query features. Based on the query characteristics, determine the safe query operator corresponding to the initial query operator.

3. The method according to claim 2, wherein determining the safe query operator corresponding to the initial query operator includes: Obtain the data description information and operator correspondence table of the data source; Determine at least one candidate security operator corresponding to the initial query operator in the operator correspondence table; Based on the data description information, the selected security query operator is determined from the at least one candidate security operator.

4. The method according to claim 2, after performing syntactic analysis on the query statement, determining the query features corresponding to the query statement, and determining the initial query operator corresponding to the query request based on the query features, further includes: Obtain the data description information of the data source; If the data description information ensures that the data source does not need to perform the query operation corresponding to the query feature, the initial query operator is removed.

5. The method according to claim 1, further comprising, before obtaining the data description information of the data source and the security query operator, and determining the target query plan from the candidate query plans of the at least one data source: Determine the combination method of the security query operators, and generate at least one candidate query plan corresponding to the query request based on the combination method.

6. The method according to claim 1, wherein obtaining the data description information of the data source and the security query operator, and determining the target query plan from the candidate query plans of the at least one data source, comprises: For any candidate query plan, identify the target security query operator included in the candidate query plan, and determine the cost calculation method corresponding to the target security query operator; Based on the data description information and the cost calculation method corresponding to the target security query operator, calculate the planned query cost corresponding to the candidate query plan; The target query plan is determined based on the planned query cost.

7. The method according to claim 6, wherein determining the target query plan based on the planned query cost includes: If the planned query cost is greater than a preset threshold, the candidate query plan corresponding to the planned query cost is discarded. If the planned query cost is less than or equal to a preset threshold, the candidate query plan corresponding to the planned query cost is determined as the target query plan.

8. The method according to claim 7, further comprising: If the query texts corresponding to multiple candidate query plans are all greater than a preset threshold, the query costs of the multiple plans are sorted to obtain a sorting result. Based on the ranking results, the target query plan is determined from the candidate query plans.

9. The method according to claim 6, wherein the planned query cost corresponding to the candidate query plan is calculated based on the cost calculation method corresponding to the data description information and the target security query operator, comprising: In the target security query operator, the head security query operator and the middle security query operator are determined; Based on the data description information and the cost calculation method corresponding to the header security query operator, the header cost and intermediate results are calculated. Obtain the intermediate description information corresponding to the intermediate result; Based on the intermediate description information and the cost calculation method corresponding to the intermediate security query operator, the intermediate cost is calculated. Based on the head cost and the intermediate cost, the planned query cost corresponding to the candidate query plan is calculated.

10. The method according to claim 9, wherein the data source is a data table, and the data description information includes the row number information of the data table; the step of calculating the header cost and intermediate results based on the cost calculation method corresponding to the header security query operator and the data description information includes: Calculate the header cost based on the row count information and the cost calculation method corresponding to the header security query operator; The header security query operator is executed based on the data table to obtain intermediate results; The intermediate description information includes the row number information of the intermediate results; The method of calculating intermediate costs based on the intermediate description information and the intermediate security query operator includes: The intermediate cost is calculated based on the row count information of the intermediate results and the cost calculation method corresponding to the intermediate security query operator.

11. A data query device, comprising: The data source determination module is configured to receive a data query request and determine at least one data source corresponding to the data query request. The operator determination module is configured to determine the corresponding security query operator based on the data query request; The plan determination module is configured to obtain data description information of the data source, determine a target query plan from candidate query plans of the at least one data source based on the data description information and the security query operator, and obtain the query result corresponding to the data query request based on the target query plan, wherein the candidate query plan is used to indicate the execution order of the at least one data source in the security query operator.

12. A big data platform, comprising an optimizer, a metadata management system, and an execution engine; The optimizer is configured to receive data query requests, determine at least one data source and a secure query operator corresponding to the data query request, obtain data description information of the data source sent by the metadata management system, determine a target query plan from candidate query plans of the at least one data source based on the data description information and the secure query operator, and send the target query plan to the execution engine. The candidate query plan is used to indicate the execution order of the at least one data source in the secure query operator; The metadata management system is used to send data description information of the data source to the optimizer; The execution engine is used to receive the target query plan, execute the query operation corresponding to the target query plan, and obtain the query result corresponding to the data query request.

13. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1-10.

14. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1-10.

15. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1-10.

Images