CN111708806A

CN111708806A - Data access method, device, server, system and storage medium

Info

Publication number: CN111708806A
Application number: CN202010856775.4A
Authority: CN
Inventors: 杨亚鹏; 杜立博; 徐雄; 唐佳; 赵佳威
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-08-24
Filing date: 2020-08-24
Publication date: 2020-09-25
Anticipated expiration: 2040-08-24
Also published as: CN111708806B

Abstract

The application discloses a data access method, which comprises the following steps: acquiring a first data access request aiming at a target data entity; determining a rule set to be matched according to the target data entity and the target data circulation domain; if the first request statement meets a statement rule hit condition included in the target rule, acquiring a second request statement according to the first request statement and an operation rule included in the target rule; and sending a second data access request to the storage service to cause the storage service to execute a second request statement according to the second data access request, wherein the second data access request comprises the second request statement. The application also provides a data access method, a data access device, a data access server, a data access system and a data access storage medium, which can shield the specific storage modes of different data entities for the data circulation domain, thereby meeting the differentiation requirements of the data circulation domain and enabling the data entity access of the data circulation domain to be simpler, more convenient and more flexible.

Description

Data access method, device, server, system and storage medium

Technical Field

The present application relates to the field of big data processing technologies, and in particular, to a method, an apparatus, a server, a system, and a storage medium for data access.

Background

The global layout of enterprises presents new challenges for the design and implementation of distributed systems. In a complex service system, data of a data entity is usually at a large scale, and storage of the data entity may be distributed in a partition form. While the use and circulation of data have diversity, different mappings may be required for the same data entity on different data circulation domains (data circulation domains).

The view, the storage process and the trigger are storage service objects supported by the relational storage service, and are generally mutually independent storage service objects. Currently, in the existing rule system, different data circulation domains can operate on data in a data entity by using the same set of rules.

However, for the same data entity, there are often multiple access methods, and different data circulation domains need to operate the data entity according to their own business requirements, so that it is difficult to satisfy the differentiated requirements of different data circulation domains by using the same set of rules, resulting in lower flexibility of data operation.

Disclosure of Invention

The embodiment of the application provides a data access method, a data access device, a data access server, a data access system and a data access storage medium, which can shield specific storage modes of different data entities for a data circulation domain, thereby meeting the differentiation requirements of the data circulation domain and enabling the data entity access of the data circulation domain to be simpler, more convenient and more flexible.

In view of the above, an aspect of the present application provides a method for data access, including:

acquiring a first data access request aiming at a target data entity, wherein the first data access request comprises a first request statement and an accessor mark, and the accessor mark is used for indicating a target data circulation domain;

determining a rule set to be matched according to a target data entity and a target data circulation domain, wherein the rule set to be matched and the target data entity have a corresponding relation, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

if the first request statement meets a statement rule hit condition included in a target rule, acquiring a second request statement according to the first request statement and an operation rule included in the target rule, wherein the target rule belongs to a rule to be matched included in a rule set to be matched;

and sending a second data access request to the storage service to cause the storage service to execute a second request statement according to the second data access request, wherein the second data access request comprises the second request statement.

Another aspect of the present application provides a method for data access, including:

receiving a second data access request sent by the rule service;

executing a second request statement according to the second data access request;

acquiring a data execution result for the second request statement;

sending a data execution result to a data access party;

the second data access request comprises a second request statement, the second request statement is generated according to the first request statement and an operation rule included by a target rule, the first request statement meets a statement rule hit condition included by the target rule, the target rule is included in a rule set to be matched, the rule set to be matched comprises at least one rule to be matched, each rule to be matched comprises a statement rule hit condition and a corresponding relation between the operation rules, the first request statement comprises a first data access request sent by a data access party, and the first data access request is a data access request aiming at a target data entity.

Another aspect of the present application provides a data access apparatus, including:

the data access method comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring a first data access request aiming at a target data entity, the first data access request comprises a first request statement and an accessor mark, and the accessor mark is used for indicating a target data circulation domain;

the system comprises a determining module, a matching module and a matching module, wherein the determining module is used for determining a rule set to be matched according to a target data entity and a target data circulation domain, the rule set to be matched and the target data entity have a corresponding relation, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises statement rule hit conditions and a corresponding relation between operation rules;

the obtaining module is further configured to obtain a second request statement according to the first request statement and an operation rule included in the target rule if the first request statement satisfies a statement rule hit condition included in the target rule, where the target rule belongs to a rule to be matched included in a rule set to be matched;

and the sending module is used for sending a second data access request to the storage service so that the storage service executes a second request statement according to the second data access request, wherein the second data access request comprises the second request statement.

In one possible design, in one implementation of another aspect of the embodiment of the present application, the data access apparatus further includes a generation module;

the obtaining module is further used for obtaining a data circulation domain, a data entity, statement rule hit conditions and operation rules, wherein the statement rule hit conditions comprise events and rule hit conditions, and the operation rules comprise rule behaviors and rule mapping;

and the generating module is used for generating the rule to be matched according to the data circulation domain, the data entity, the statement rule hit condition and the operation rule.

In one possible design, in another implementation of another aspect of an embodiment of the present application,

the determining module is specifically configured to determine, if the first request statement corresponds to the read-only event, a target view corresponding to the target data entity according to the first request statement and an operation rule included in the target rule;

and generating a second request statement according to the target view and the first request statement.

the determining module is specifically configured to generate an extended execution statement corresponding to the first request statement according to the first request statement and an operation rule included in the target rule if the first request statement corresponds to the writable event;

generating a second request statement according to the expanded execution statement and the first request statement;

or the like, or, alternatively,

generating a third request statement according to the first request statement;

and generating a second request statement according to the expanded execution statement and the third request statement.

a sending module, configured to send a second data access request to the storage service, so that the storage service executes the extended execution statement and the first request statement according to the second data access request;

receiving a data execution result aiming at the first request statement sent by the storage service;

or the like, or, alternatively,

a sending module, configured to send a second data access request to the storage service, so that the storage service executes the extended execution statement and the third request statement according to the second data access request;

and receiving a data execution result sent by the storage service and aiming at the third request statement.

a sending module, configured to send a second data access request to the storage service, so that the storage service executes the first request statement and the extended execution statement according to the second data access request;

receiving a data execution result aiming at the extended execution statement sent by the storage service;

or the like, or, alternatively,

receiving a data execution result sent by the storage service and aiming at the third request statement;

and receiving a data execution result sent by the storage service and aiming at the extended execution statement.

In one possible design, in another implementation manner of another aspect of the embodiment of the present application, the data access apparatus further includes a receiving module;

the obtaining module is further configured to obtain a fourth request statement according to the first request statement and the first sub-operation rule included in the target rule if the first request statement satisfies a hit sub-condition of the first statement rule included in the target rule, where the hit sub-condition of the first statement rule is included in the target rule;

the sending module is further configured to send a third data access request to the storage service, so that the storage service executes a fourth request statement according to the third data access request, where the third data access request includes the fourth request statement;

the receiving module is used for receiving a data execution result aiming at the fourth request statement sent by the storage service;

the obtaining module is further configured to obtain a fifth request statement according to the first request statement and a second sub-operation rule included in the target rule if a data execution result for the fourth request statement satisfies a second statement rule hit sub-condition included in the target rule, where the second statement rule hit sub-condition is included in the target rule;

the sending module is further configured to send a fourth data access request to the storage service, so that the storage service executes a fifth request statement according to the fourth data access request, where the fourth data access request includes the fifth request statement.

and the sending module is further used for sending the first data access request to the storage service if the data execution result aiming at the fourth request statement does not meet the hit sub-condition of the second statement rule, so that the storage service executes the first request statement according to the first data access request.

the sending module is further configured to send a first data access request to the storage service if the first request statement does not satisfy any rule to be matched in the rule set to be matched, so that the storage service executes the first request statement according to the first data access request.

the receiving module is used for receiving a second data access request sent by the rule service;

the execution module is used for executing the second request statement according to the second data access request;

an obtaining module, configured to obtain a data execution result for the second request statement;

the sending module is used for sending a data execution result to the data access party;

Another aspect of the present application provides a server, including: a memory, a transceiver, a processor, and a bus system;

wherein, the memory is used for storing programs;

a processor for executing the program in the memory, the processor for performing the above-described aspects of the method according to instructions in the program code;

the bus system is used for connecting the memory and the processor so as to enable the memory and the processor to communicate.

Another aspect of the present application provides a data access system, which includes a rule server and a storage server;

the rule server is used for receiving a first data access request aiming at a target data entity and sent by a data access party, wherein the first data access request comprises a first request statement and an access party identifier, and the access party identifier is used for indicating a target data circulation domain;

the rule server is used for determining a rule set to be matched according to the target data entity and the target data circulation domain, wherein the rule set to be matched and the target data entity have a corresponding relation, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

the rule server is used for acquiring a second request statement according to the first request statement and an operation rule included by a target rule if the first request statement meets a statement rule hit condition included by the target rule, wherein the target rule belongs to a rule to be matched included in a rule set to be matched;

the rule server is used for sending a second data access request to the storage server, wherein the second data access request comprises a second request statement;

the storage server is used for executing the second request statement according to the second data access request;

the storage server is used for acquiring a data execution result aiming at the second request statement;

and the storage server is used for sending the data execution result to the data access party.

Another aspect of the present application provides a computer-readable storage medium having stored therein instructions, which when executed on a computer, cause the computer to perform the method of the above-described aspects.

In another aspect of the application, a computer program product or computer program is provided, the computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method provided by the various alternative implementations of the aspects described above.

According to the technical scheme, the embodiment of the application has the following advantages:

in the embodiment of the application, a data access method is provided, which includes first obtaining a first data access request for a target data entity, determining a rule set to be matched according to the target data entity and a target data flow domain based on the first data access request, obtaining a second request statement according to a statement rule included in a first request statement and an operation rule included in a target rule if the first request statement meets a statement rule hit condition included in the target rule, and finally sending a second data access request to a storage service, so that the storage service executes the second request statement according to the second data access request. Through the method, the same target data entity can hit different rule sets to be matched in different data circulation domains, namely the basis for determining the rule sets to be matched comprises the data circulation domains. Different rule sets to be matched can be hit in different data entities in the same target data circulation domain, namely the basis for determining the rule sets to be matched comprises the data entities. The same request statement of the same target data entity can hit different operation rules according to different statement rule hit conditions. Therefore, the data flow domain can shield the specific storage modes of different data entities, so that the differentiation requirements of the data flow domain are met, and the data entity can be accessed more conveniently and flexibly by the data flow domain.

Drawings

FIG. 1 is a schematic diagram of an environment of a data access system in an embodiment of the present application;

FIG. 2 is a schematic diagram of a data infrastructure in an embodiment of the present application;

FIG. 3 is a schematic diagram of a system architecture for implementing data access based on a data infrastructure according to an embodiment of the present application;

FIG. 4 is a schematic diagram of another system architecture for implementing data access based on data infrastructure in the embodiment of the present application;

FIG. 5 is a schematic diagram of an embodiment of a data access method in an embodiment of the present application;

FIG. 6 is a diagram illustrating a rule set to be matched according to an embodiment of the present application;

FIG. 7 is a directed acyclic graph formed by data source and result views in an embodiment of the present application;

FIG. 8 is a schematic diagram of another embodiment of a data access method in the embodiment of the present application;

FIG. 9 is a schematic diagram of an embodiment of a data access device in an embodiment of the present application;

FIG. 10 is a schematic diagram of another embodiment of a data access device in an embodiment of the present application;

FIG. 11 is a schematic structural diagram of a server in an embodiment of the present application;

fig. 12 is a schematic structural diagram of a data access system in the embodiment of the present application.

Detailed Description

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "corresponding" and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

With the continuous improvement of the informatization degree, global data is increasingly expanded. In the face of mass data storage requirements, the traditional storage system has a bottleneck in the expansion of capacity and performance. Cloud storage (cloud storage) has gained wide acceptance in the industry due to its advantages of strong expansibility, high cost performance, good fault tolerance, etc. The data access provided by the application can be applied to not only an independent system, but also a distributed system (distributed system) based on cloud storage, wherein the cloud storage is generated along with a cloud technology (cloud technology), and the cloud technology refers to a hosting technology for unifying series resources such as hardware, software and networks in a wide area network or a local area network to realize the calculation, storage, processing and sharing of data.

The cloud technology is based on the general names of network technology, information technology, integration technology, management platform technology, application technology and the like applied in the cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.

Cloud storage is a new concept extended and developed from a cloud computing concept, and a distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system which integrates a large number of storage devices (storage devices are also referred to as storage nodes) of different types in a network through application software or application interfaces to cooperatively work through functions of cluster application, a grid technology, a distributed storage file system and the like, and provides data storage and service access functions to the outside.

At present, a storage method of a storage system is as follows: logical volumes are created, and when created, each logical volume is allocated physical storage space, which may be the disk composition of a certain storage device or of several storage devices. The client stores data on a certain logical volume, that is, the data is stored on a file system, the file system divides the data into a plurality of parts, each part is an object, the object not only contains the data but also contains additional information such as data Identification (ID), the file system writes each object into a physical storage space of the logical volume, and the file system records storage location information of each object, so that when the client requests to access the data, the file system can allow the client to access the data according to the storage location information of each object.

The process of allocating physical storage space for the logical volume by the storage system specifically includes: physical storage space is allocated for a logical volume according to a group of capacity measures of objects stored in the logical volume (which measures tend to have a large margin with respect to the capacity of the actual objects to be stored) and Redundant Array of Independent Disks (RAID).

The big data (big data) can be further stored based on the cloud storage technology, wherein the big data refers to a data set which cannot be captured, managed and processed by a conventional software tool within a certain time range, and is a massive, high-growth-rate and diversified information asset which needs a new processing mode to have stronger decision-making power, insight discovery power and process optimization capacity. With the advent of the cloud era, big data has attracted more and more attention, and the big data needs special technology to effectively process a large amount of data within a tolerance elapsed time. The method is suitable for the technology of big data, and comprises a large-scale parallel processing database, data mining, a distributed file system, a distributed database, a cloud computing platform, the Internet and an extensible storage system.

In a distributed system (distributed system), there may be various access modes for the same data entity, and therefore, multiple access maps may be required for accessing the same data entity, or complex data access maps may be required for complex joint access of multiple data entity objects. The application provides a data access method realized based on rule service, which can provide big data for a data service domain and a data circulation domain and realize various mapping (mapping) or presentation (projecting) capabilities of data entity objects in a distributed scene. The rule service described in the present application integrates objects such as a view, a storage process, a trigger, and the like of a database system, and in addition, the rule service also integrates objects such as a user-defined function (UDF), and the like. Since data entities are stored in partition partitions according to route keys (route keys), read and write access to the same data entity may involve different partition partitions. Likewise, access to multiple data entities is more likely to involve complex data partition fragmentation, and therefore, the specific storage manner of the data entities can also be shielded from the data circulation domain by the rule service, so that access to the data entities by the data circulation domain becomes simpler.

The present application relates to a plurality of terms, and for ease of understanding, the following description will discuss the relevant terms.

1. A data entity (entity) represents a relational database or a table of non-relational data.

2. A field (field) represents an attribute of a data storage entity.

3. Data fragmentation (data sharing) means that data is distributively stored in a plurality of entity storage nodes or virtual nodes according to certain characteristic information, and the data fragmentation adopts horizontal partitioning (horizontal partitioning).

4. The route key (also called data fragmentation key) is characteristic information stored in the data fragments.

5. A rule (rule) represents a configurable read-write policy or method of a data entity.

6. Events (events) include four event types, namely an add type, a delete type, a modify type, and a query type.

7. A view (view) is a virtual data entity (virtual entry) in a database system. Is a result set formed by a group of query statements, which are combined into a virtual data entity object capable of being queried.

8. A trigger (trigger) is a type of database object that is associated with a data entity event. Its execution is triggered by an event. The trigger may query other tables and may contain complex Structured Query Language (SQL) statements. It can also be used to enforce referential integrity so that when rows are added, updated or deleted in multiple tables, the relationships defined between the tables are preserved.

9. The stored procedure (stored procedure) is a set of SQL statements in a database system for completing a specific function, which is stored in the database and can be permanently valid after one-time compilation. The storage process is an important object in the database, and under the condition of extremely large data volume, the efficiency improvement of speed multiplication can be achieved by using the storage process.

10. A function (function) refers to a piece of code that can be directly referenced by another piece of code.

11. A data service domain generally refers to an owner of a data entity, usually a creator of the data entity or data object, and a producer of the data entity, for example, an advertisement delivery system of a certain traffic.

12. The data circulation domain (data circulation domain) generally refers to the data access side of an entity, and may be an advertisement system of some "traffic" or "traffic alliance". An advertisement engine such as "Tencent video" is one party to access the data.

13. A Data Infrastructure (DI) is a data intermediary between data access parties and data storage systems.

In order to implement data access in a data circulation domain, the present application provides a data access method, which is applied to the data access system shown in fig. 1, as shown in the figure, the data access system includes a server and a terminal device, and a client is deployed on the terminal device. The server related to the present application may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud storage service, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a Content Delivery Network (CDN), a big data and artificial intelligence platform, and the like. The terminal device may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a palm computer, a personal computer, a smart television, a smart watch, and the like. The terminal device and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein. The number of servers and terminal devices is not limited.

The data access party initiates a data access request to the server through the terminal device, the server calls the rule service, and the rule service determines a rule set to be matched based on a first request statement in the data access request and a data circulation domain of the data access party. And if the request statement meets a statement rule hit condition included in a certain multi-entry target rule, generating second request statements corresponding to each request statement according to the first request statement and the operation rule included in each target rule, so that the rule service sends the second request statement including the second request statement to the storage service, and the storage service executes each second request statement according to the second data access request and returns a corresponding data execution result.

The rule services are deployed at an application layer in the data infrastructure, while the storage services are deployed at a data storage layer. For convenience of introduction, please refer to fig. 2, fig. 2 is a schematic structural diagram of a data infrastructure in an embodiment of the present application, and as shown in the drawing, a rule system is embedded in the data infrastructure, and the data infrastructure includes a data access layer (accesslayer) indicated by S1, a rule system (rule system) indicated by S2, a data parsing layer (pars layer) indicated by S3, a data planning layer (exhibition layer) indicated by S4, a planning execution layer (execute layer) indicated by S5, and a data storage layer (storage layer) indicated by S6. The application layer in the data infrastructure comprises a rule system, a data analysis layer, a data plan layer and a plan execution layer.

Based on the data infrastructure shown in fig. 2, first, a data access request is obtained through a data access layer, and the data access request is analyzed by a data analysis layer to obtain a corresponding request statement. And after the data access request is analyzed, the rule system analyzes the rule set to be matched, which is possibly matched, according to the request statement and the target data circulation domain corresponding to the data access party. And the plan execution layer executes the corresponding plan aiming at the data storage layer in combination with the matched target rule.

The rule system is based on a data read-write access strategy and rules on distributed storage, is data model abstraction of different data service domains for distributed data storage objects, and can present or express data in various types for the same or several data entities according to different specific service requirements. The rule system provides various mapping capabilities of data objects in a distributed scene for different data service domains or data flow domains. Especially for a complex internet advertising system, wide use space can be provided. The data storage layer may be in the form of a Database (Database), which may be regarded as an electronic file cabinet, in short, a place for storing electronic files, and a user may add, query, update, delete, etc. to data in the files. A "database" is a collection of data that is stored together in a manner that can be shared by multiple users, has as little redundancy as possible, and is independent of the application.

In practical application, the rule system and the data storage layer may be deployed on the same server, or may be deployed on different servers, for convenience of description, refer to fig. 3, where fig. 3 is a schematic diagram of a system architecture for implementing data access based on a data infrastructure in an embodiment of the present application, as shown in the figure, a data access side sends a first data access request to a server, the server may generate a second data access request through a rule service deployed on the rule system, and then may generate a second data access request through a storage service deployed on the data storage layer by the rule service, and the storage service accesses corresponding data based on the second data access request and feeds back the data access request to the data access side.

Referring to fig. 4, fig. 4 is a schematic diagram of another system architecture for implementing data access based on a data infrastructure in the embodiment of the present application, where as shown in the figure, a data access side sends a first data access request to a rule server, the rule server may generate a second data access request through a rule service deployed on the rule system, and then may send the second data access request to a storage service deployed on the storage server, and the storage service accesses corresponding data based on the second data access request and feeds back the corresponding data to the data access side.

With reference to the above description, the following describes a data access method in the present application from the perspective of a rule service, and referring to fig. 5, an embodiment of the data access method in the present application includes:

101. acquiring a first data access request aiming at a target data entity, wherein the first data access request comprises a first request statement and an accessor mark, and the accessor mark is used for indicating a target data circulation domain;

in this embodiment, the rule service receives a first data access request for a target data entity sent by a data access party, where the first data access request encapsulates a first request statement and an access party identifier, the first request statement carries a field corresponding to the target data entity, and the target data entity is a table, for example, "Tbl _ creation _". The data accessing party can be determined based on the accessing party identification, so that a target data circulation domain corresponding to the data accessing party is determined, for example, "Tencent video" is a target data circulation domain.

It should be noted that the logic of the rule service is deployed in a server, and the server may be an independent server or a cloud server, which is not limited herein.

102. Determining a rule set to be matched according to a target data entity and a target data circulation domain, wherein the rule set to be matched and the target data entity have a corresponding relation, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

in this embodiment, the rule service may determine a rule set to be matched based on the target data entity and the target data circulation domain, that is, the rule set to be matched is applicable to the target data circulation domain, and the rule set to be matched is a relevant rule for accessing the target data entity.

Specifically, after a first data access request is transmitted from a data access layer of a data infrastructure, a first request statement is obtained through parsing the first data access request, the first request statement is preprocessed and subjected to basic validity check, a rule that the data request may be matched is analyzed according to content (data entities, conditions, request data content, and the like) of the first request statement, that is, a rule set to be matched is obtained, the rule set to be matched includes at least one rule to be matched, the rule to be matched may be a determined result (e.g., hit or miss) or an uncertain result (e.g., undetermined), and for the uncertain result, it may be necessary to determine whether the rule is hit in a subsequent execution stage or in a data result fusion stage after execution. Thus, one rule for a data access request may have one or more result sets.

For ease of understanding, please refer to table 1, where table 1 is a schematic diagram of a relationship between a data entity and a rule set to be matched.

TABLE 1

As can be seen from table 1 and fig. 2, the rule service firstly determines the rule set to be matched through the analysis of the rule system, then analyzes each rule to be matched in the rule set to be matched, and determines whether the first request statement hits the rule to be matched, or misses the rule to be matched, or is in a pending state. And the data plan layer is combined with the rule set to be matched to make an execution plan, rewrites the request statement and is prepared to be executed by the plan execution layer. When a pending rule to be matched occurs, rewriting the request statement and executing the rewritten request statement is a cyclic process until each of the pending rules to be matched has a determined result (i.e., a hit or a miss). If the rules to be matched which are pending are matched again, the request statement is continuously rewritten and the rewritten request statement is executed. And after the execution of all the hit rules is finished, fusing (merge) the data results, and finally returning the data results to the data access party.

More specifically, referring to fig. 6, fig. 6 is a schematic diagram of a rule set to be matched in the embodiment of the present application, and as shown in the figure, taking a first data access request for a target data entity as an example, a first request statement is obtained after the first data access request is analyzed, where the first request statement includes a specific event, and the event includes query, insertion (or addition), modification, or deletion. Then, based on the target data entity and the corresponding target data circulation domain, a rule set to be matched of an event corresponding to the first request statement is obtained, where each rule set to be matched includes a statement rule hit condition and an operation rule corresponding to the statement rule hit condition, and the statement rule hit condition includes the event and a rule hit condition, for example, the first request statement is a "delete" event, that is, all rules to be matched in the rule set to be matched belong to rules under the "delete" event, and thus, it is respectively determined whether the first request statement hits the "rule hit condition" in the "statement rule hit condition".

103. If the first request statement meets a statement rule hit condition included in a target rule, acquiring a second request statement according to the first request statement and an operation rule included in the target rule, wherein the target rule belongs to a rule to be matched included in a rule set to be matched;

in this embodiment, the rule service needs to detect whether the first request statement hits the rule set to be matched, and if the rule set to be matched includes N rules to be matched, N matching results are generated according to the first request statement and the rules to be matched, and for the rule to be matched that is successfully matched, the rule to be matched is the target rule corresponding to the first request statement.

In one example, the manner how to detect whether a "rule hit condition" is hit is described below in detail with reference to examples. By taking the example that the target data entity (i.e. the logical table) indicated by the first request statement is "Tbl _ creating _" and the event is "query", the rule set to be matched as shown in table 2 can be obtained based on the target data flow field.

TABLE 2

As can be seen from table 2, the rule set to be matched includes 4 rules to be matched, and each rule to be matched includes a rule name, a rule hit condition, and an operation rule. The specific contents of the 4 rules to be matched will be described below:

code segment 1: the specific contents of the "rule _ status" rule are as follows:

rule_items {

event SELECT \ event is "QUERY"

condition { item { expression { field: "FStatus" operator: Present } reference: NEW } } \ when field "FStatus" is PRESENT

select _ context { \ \ select context

field _ transform { \ \ for field transformation

field _ replace { \ \ proceed with field replacement

item { const _ value { type: STRING _ value:' (CASE WHENFDELStatus = 20 THEN 20 ELSE FSysStatus END) } \ substitution attribute type is "character STRING" means that, in the CASE where the "FDELStatus" field is 20, the "FStatus" field is equal to 20, otherwise, the "FDELStatus" field is equal to "FStatus"

}

Code segment 2: the specific content of the rule is as follows:

rule_items {

event SELECT \ event is "QUERY"

condition { item { expression { field: "FGrantedList" operator: Present } reference: NEW } } \ when field "FGrantedList" is PRESENT

select _ context { \ \ select context

front _ transform { \\ \ for transformation of the front section part

field _ Transoform { \ \ for field transformation

field _ replace { \ \ proceed with field replacement

carrying out name comparison on comp _ name { \ \

INVKE execution function

item { flag: CONST CONST _ value { type: STRING _ val: "AAA _ AUTH" } } \ \ function name is "AAA _ AUTH"

item { flag, NAIVE _ FIELD nasal _ FIELD: "FUId" } \ one parameter of the function is "FUId"

item { flag, NAIVE _ FIELD nasal _ FIELD: "FCId" } \ one parameter of the function is "FCId"

}

Code segment 3: the specific contents of the rule "rule _ black _ list" are as follows:

rule_items {

event SELECT \ event is "QUERY"

condition {

item { expression { field: "FCrtType" operator: PRESENT } reference: NEW } \ \ when there is "FCrtType" field

item { query_sql: "SELECT FUId FROM Tbl_TIdList_WHERE FTId =

"all" FUIDs "with" FTId "as an arbitrary value are selected from the Tbl _ TIdList table, the" FUID "is a main key of data in the" Tbl _ Creative _ "table, and the" FUID "of the input request statement should be included in the selected" FUID

}

select context

field _ transform { \ \ for field transformation

field _ replace { item { const _ value { type: INT64 INT64_ value: 101} } } \ \ replace the value of "FCrtType" with 101

}

Code segment 4: the specific contents of the "rule _ join" rule are as follows:

rule_items {

event SELECT \ event is "QUERY"

condition {

item { expression { field: "PRESENT } preference: NEW } when there is a" field: "field

item { query _ sql: "FUrl" operator: PRESENT } reference: NEWrelational: OR } \ \ OR when there is "FUrl" PRESENT

}

select _ context { \ \ select context

View { \ \ usage view

Source { query _ sql: "SELECT FROM Tbl _ Creative _" alias: "c" } \ acquires all data fields FROM the "Tbl _ Creative _" table, named "c", and "c" in the following code refers to the content in the execution result of this command, such as "c.

source { query _ sql: "SELECT _ FROM Tbl _ additive _" alias: "ac" } \ acquires all data fields FROM the "Tbl _ additive _" table, named "ac",

source { query _ sql: "SELECT FROM Tbl _ Element _" alias: "e" } \ acquires all data FROM the "Tbl _ Creative _" table, named "e"

view _ sql for "SELECT left" FROM (SELECT left, "get" SELECT left ", which means all data fields in" create table "corresponding to the statement execution result of" SELECT left "

(CASE WHEN (c.FAdId > 0) THEN ac.Furl ELSE c.Furl END) AS Furl, \\ if the "FAdId" of the "c" table is greater than zero, THEN get the "Furl" in "ac", otherwise get the "Furl" in "c", and name "Furl"

e. FEgment AS FEgment, \\ selecting "FEgment" in "e"

... ...

FROM c LEET JOIN ac ON c.FAdId = ac.FAdId AND c.FUId =ac.FUId

Let JOIN e ON c.feld = e.feld AND c.fuid = e.fuid "\\ \ c" table AND "ac" table, data in which "FAdId" in "c" table is equal to "FAdId" in "ac" table AND "FUId" in "c" table is equal to "FUId" in "ac" table are combined, AND in the above-mentioned combination result, data in which "FEId" in "c" table is equal to "FEId" in "e" table AND "FUId" in "c" is equal to "FUId" in "e" table are combined

}

Illustratively, assume that the first request statement is:

select FStatus, FCrtType From Tbl_Creative_ where FUId = 20561;

since the first request statement includes the "fsstatus" field, the rule hit condition corresponding to the hit rule name "rule _ status" is reached. The "FGrantedList" field is not included in the first request statement, and thus the rule hit condition corresponding to the rule name "rule _ aaa" is missed. The first request statement includes the "FCrtType" field but does not include the "Tbl _ TIdList _" field, and therefore, whether the rule hit condition corresponding to the rule name "rule _ black _ list" is hit needs to be determined. The "FElemen" field or the "FUrl" field is not included in the first request statement, and therefore, the rule hit condition corresponding to the miss rule name "rule _ join" is not hit. The following results were obtained:

the target rule for hit is { rule _ status };

the rule set to be hit is { rule _ black _ list };

the rule set for the miss is { rule _ aaa, rule _ join };

when the request statement is executed, since the target data entity "Tbl _ creating _" is stored in a shard manner according to the value of "FUId" (for example, 100 banks each storing 10 tables), and the "rule _ black _ list" in the rule set on standby also needs to determine whether the hit occurs according to the value of "FTId".

The rule service may generate a second request statement from the first request statement and the operation rule included in the target rule.

For example, the first request statement is:

select FStatus, FCrtType From Tbl_Creative_ where FUId = 20561;

rewrite to a second request statement:

select FStatus, FCrtType, FTId From DB_61.Tbl_Creative_5 where FUId =20561;

since the primary key of the target data entity "Tbl _ creating _" is "FTId", there may be multiple records of the data execution result, and the rule of "rule _ black _ list" is determined whether to hit according to the "FTId" recorded in the data execution result, and the hit data record will continue to execute the rule of "rule _ black _ list".

Illustratively, assume again that the first request statement is:

select FGrantedList, Furl From Tbl_Creative_ where FUId = 20561 and FTId= 10001;

since the "fsstatus" field is not included in the first request statement, the rule hit condition corresponding to the miss rule name "rule _ status" is not hit. The first request statement includes a "FGrantedList" field, and thus hits the rule hit condition corresponding to the rule name "rule _ aaa". The first request statement does not include the "FCrtType" field and the "Tbl _ TIdList _" field, and thus the rule hit condition corresponding to the miss rule name "rule _ black _ list" is not hit. The first request statement includes a "FUrl" field, and thus, the rule hit condition corresponding to the hit rule name "rule _ join" is included. The following results were obtained:

the target rule of hit is { rule _ aaa, rule _ join };

the rule set for a miss is { rule _ status, rule _ black _ list }.

In yet another example, the target rule configured for the data entity "Tbl _ Commodity _" will be specifically introduced below in connection with the example. Taking the example that the target data entity (i.e. logical table) indicated by the first request statement is "Tbl _ Commodity _", the rule set to be matched as shown in table 3 can be obtained based on the target data flow field.

TABLE 3

Rule name	Rule hit condition	Rules of operation
			rule_insert	Is free of	Table name replacement
rule_update	Is free of	Table name replacement
			rule_insert_extend	In Field of request statement is FTargetDef	Triggering extended updates
rule_update_extend	In Field of request statement is FTargetDef	Triggering extended updates
			rule_select	Is free of	Indicating a substitution

As can be seen from table 3, the rule set to be matched includes 5 rules to be matched, and each rule to be matched includes a rule name, a rule hit condition, and an operation rule.

Illustratively, assume that the first request statement is:

select FTargetDef From Tbl_Commodity where FUId = 20561 and FTId = 100;

wherein, the target rule hit by the first request statement is { rule _ select };

the operation rule of the target rule "rule _ select" is to replace the "Tbl _ Commodity" table with the "Tbl _ CommodityEx _" table, and when executed, since the "Tbl _ CommodityEx _" table is stored in a fragmented manner (100 library 100 table) according to the value of "FUId", the second request statement obtained is:

select FTargetDef From DB_61.Tbl_CommodityEx_5 where FUId = 20561 andFTId = 100;

the storage service acquires a desired data execution result using the rewritten second request statement.

104. And sending a second data access request to the storage service to cause the storage service to execute a second request statement according to the second data access request, wherein the second data access request comprises the second request statement.

In this embodiment, after generating the second request statement, the rule service may encapsulate the second request statement in the second data access request, and may further encapsulate the accessor identifier and the second request statement in the second data access request together. Then, the rule service sends a second data access request to the storage service, and the storage service executes a second request statement according to the second data access request, and finally obtains a data execution result.

Optionally, on the basis of the embodiment corresponding to fig. 5, in an optional embodiment provided in the embodiment of the present application, the method may further include the following steps:

acquiring a data circulation domain, a data entity, statement rule hit conditions and operation rules, wherein the statement rule hit conditions comprise events and rule hit conditions, and the operation rules comprise rule behaviors and rule mapping;

and generating a rule to be matched according to the data circulation domain, the data entity, the statement rule hit condition and the operation rule.

In this embodiment, a Rule configuration manner is introduced, a service Rule Language of a Rule system is defined based on an Extensible Markup Language (XML) Language, and the Rule system is defined and constrained by an XML meta Language (xslschema Definition for Rule, XSDL) of a Rule. The business rule language is oriented to the users of the respective data business domain or data flow domain for describing possible mappings of data entities.

Wherein, the constraint of the rule meta language mainly comprises: version (version), circulation deployment domain (circulation), event (event), rule hit condition (condition), rule action (action), and rule mapping (projection), etc., and the detailed definitions are as follows:

code segment 5: without limitation on the maximum number of occurrences of < xs: element name = "rule" maxOccurs = "unbounded" > \\ rule

<xs:complexType>

<xs:sequence>

< xs: element ref = "vision" minOccurs = "0"/> \\\ "version" minimum number of occurrences is 0

(xs) element ref = "circulation" minOccurs = "0"/> \\\ circulation deployment domain "minimum occurrence number is 0

(xs) element name = "condition" minOccurs = "0" > \\ \ rule hit condition "minimum occurrence number of times is 0

<xs:complexType>

<xs:sequence>

Element name = "item" type = "predicator" minOccurs = "0"/> "\ definition element" item ", and the minimum occurrence number of the element" item "defined as" predicator "is 0

</xs:sequence>

</xs:complexType>

</xs:element>

The minimum number of occurrences of < xs: element name = "actions" type = "actions" minOccurs = "0"/> \\\ regular behavior "is 0

(xs) minimum occurrence number of 0 < 0 > element name = = "projecting" type = "projecting _ sub" minOccurs = "0"/> \\ rule mapping

</xs:sequence>

Attribute ref = "status" use = "optional"/> \\ "state" use optional

(xi) Attribute name = "name" type = "xs: string" use = "optional"/> \\ "name" optional use

(xi) attribute name = "create _ date" type = "xs: date" use = "optional"/> \\\ "creation date

(xi) attribute name = "amplified _ date" type = "xs: date" use = "optional"/> \\ "expiration date" optional use of

(xi) Attribute name = "inner" type = "xs: string" use = "optional"/> \\ owner

Attribute name = "event" type = "events" use = "optional"/> \\ "event" use optional xs

</xs:complexType>

</xs:element>

Where "version" denotes version information of the rule revision, for example, version V10.1.2.

"State" means a rule deployment state, e.g., "deployed" or "in deployment," etc.

"owner" means the owner of the rule, e.g., "Federation advertisement System".

"data entity" means a rule definition or a data object to which a rule belongs.

"currency deployment domain" means a cluster of data infrastructure that is deployed by a rule, for example, both data currency domain A and data currency domain B can adapt the rule.

"event" includes a query, insertion (or addition), modification or deletion.

"rule hit condition" means a condition for a hit rule.

"rule behavior" means the behavior of a rule.

"rule mapping" represents the content of a rule.

Based on this, more specifically, the detailed definition of the rules is as follows:

code segment 6: < xs: complexType name = "actions" > \\ name "regular behavior"

<xs:sequence>

< xs > choice maxOccurs = "unbounded" > \\ selection maximum occurrence number is not limited

The minimum occurrence frequency of < xs, element name = "insert" minOccurs = "1" maxOccurs = "unbounded" > \\ insertion is 1, and the maximum occurrence frequency is not limited

<xs:complexType>

<xs:sequence>

< xs = "field _ value _ calls"/>/key-value pair

An element name = "on _ duplicated" type = "actions" minOccurs = "0"/> \\ definition name "repetition value" for avoiding insertion repetition at the time of insertion, and the minimum occurrence number of the element is 0

</xs:sequence>

< xs: attributeGroup ref = "extended _ multicast"/> \\ definition insert may be used to extend the operation statement

</xs:complexType>

</xs:element>

The minimum occurrence frequency of < xs, element name = "update" minOccurs = "1" maxOccurs = "unbounded" > \\ update is 1, and the maximum occurrence frequency is not limited

<xs:complexType>

<xs:sequence>

< xs = "field _ value _ calls"/>/key-value pair

(xs) element name = "predictions" type = "prediction _ expression" minOccurs = "0"/> \\ assertion expression minimum number of times is 0

</xs:sequence>

< xs: attributeGroup ref = "extended _ multicast"/> \\ definition update may be used to extend the operation statement

</xs:complexType>

</xs:element>

<xs:element name="delete" minOccurs="0" maxOccurs="unbounded"/>

<xs:complexType>

<xs:sequence>

< xs = "field _ value _ calls"/>/key-value pair

(xs) element name = "predictions" type = "prediction _ expression" minOccurs = "0"/> \\ assertion expression, minimum number of times is 0

</xs:sequence>

< xs > attributeGroup ref = "extended _ multicast"/> \\ definition delete can be used to extend the operation statement

</xs:complexType>

</xs:element>

Element name = "entity _ place" minOccurs = "1" maxOccurs = "unbounded"/> \\ definition of replacement entity

<xs:complexType>

Attribute name = "entity _ uri" type = "uri"/> \\ definition attribute is the concrete location of the entity, type is "uri", and is used for directly indicating the location of the entity

</xs:complexType>

</xs:element>

(xs) element name = "field _ linkage" minOccurs = "0" maxOccurs = "unbounded"/> \\ field linkage

<xs:complexType>

< xs: attribute name = "first" type = "uri"/> \\ location of first value

(xs) attribute name = "second" type = "uri"/> \\ second value position

(xs) < attribute name = "linkage _ mode" default = "invoid" > \\ define connection mode, default value is invoid, and optional value is one of FIELD and invoid defined below

<xs:simpleType>

The restriction requirement of < xs: restriction base = 'xs: string' > \ is string connection

< xs: enumeration value = "FIELD"/> \ definitional enumeration value FIELD

< xs: enumeration value = "INVOEICE"/> \\ definitional enumeration value INVOEICE

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:choice>

</xs:sequence>

The rule system translates the service rule description in the XML language into a rule executable by the rule system according to a rule to be matched defined by the service rule language, where the executable rule is configured based on the protobuf language, for example:

code segment 7: message Rule check

message RuleItem {

required string name = 1;

required Event event = 2;

optional Condition condition = 3;

optional Context context = 4;

optional ExecutionOption execution_option = 8;

}

required string entity = 1;

repeated RuleItem rule_items = 2;

}

Wherein, "1", "2", "3", "4" and "8" are all definition rules of protobuf. The executable rules to be matched mainly comprise:

the "name" is a unique identifier of a logical entity rule, and the logical entity plus the name uniquely identifies the rule.

A "data entity" is a rule definition or data object to which a rule belongs.

An "event" is a query, insertion (or addition), modification, or deletion.

A "rule hit condition" is a condition for a hit rule.

"rule context" is a specific content of a rule, and includes two types of contexts, namely, a query context (select context) and a writeable context (multicast context), respectively;

the "execution option" is a definition of the execution of a specific rule.

Based on this, the following describes executable rules based on protobuf language configuration:

code segment 8: enum Event

SELECT = 1;

INSERT = 2;

UPDATE= 3;

DELETE = 4;

}

message Condition {

message ConditionItem {

optional Expression expression = 1;

enum Reference {

OLD = 1;

NEW = 2;

}

optional Reference reference = 2 [ default = OLD];

optional string query_sql = 3;

optional boll is negative =4 [ default = false];

enum Relational {

AND = 1;

OR = 2;

}

enum Relational operator

optional Relational relational = 4 [ default = AND];

}

repeated ConditionItem item = 1;

}

Message Context{

optional SelectContext select_context = 1;

optional MutateCOntezt mutate_context = 2;

... ...

}

Message ExecutionOption{

Enum ExecutionType{

SEQUENTIAL = 1;

PARRALLEL = 2;

}

Optional ExecutionType ExecutionType = 1 [ default = SEQUENTIAL];

... ...

}

Wherein, 1, 2, 3 and 4 are the definition rules of protobuf.

Secondly, in the embodiment of the application, a rule configuration mode is provided, and through the above mode, different rules can be configured according to a target data circulation domain corresponding to a data access party, and setting is performed from multiple dimensions such as a data circulation domain, a data entity, an event, a rule hit condition, a rule behavior, rule mapping and the like, so that feasibility and operability of a scheme are improved.

Optionally, on the basis of the embodiment corresponding to fig. 5, in another optional embodiment provided in the embodiment of the present application, the obtaining the second request statement according to the first request statement and the operation rule included in the target rule specifically includes the following steps:

if the first request statement corresponds to the read-only event, determining a target view corresponding to the target data entity according to the first request statement and an operation rule included by the target rule;

In this embodiment, a manner for implementing request statement conversion based on a read-only event is provided, and when a first request statement is generated into a second request statement, a variety of conversion contents need to be considered, including but not limited to field conversion, conditional conversion, and entity conversion.

Specifically, the query context of the rule corresponds to a query event, and the query event is a read-only event. Query context refers to operations where the rule content is read-only for data operations, typically including elements such as views, transformations, and virtual field definitions. The target view in this embodiment is a view in a similar data object, and the view mainly includes:

the view name (view name), i.e., the identification of other elements within the query context that reference the view result, is the identification that the view is referenced by other objects (or views).

The data source (data source) is composed of several SQL statements.

The view statement (view sql) is the only end point of the directed acyclic graph of the data source.

The primary key (primary key) of the view is the primary key of the view query.

In conjunction with the above description, the contents of the target view will be described as follows:

code segment 9: message SelectContext

message View {

message DataSource {

optional string sql = 1, request statement of \ \ view data source

optional string slias = 2; \ alias of view data source

... ...

}

optional string view _ name = 1; \ name of view; \;, name of view

reproduced DataSource source = 2; \ data source

optional string view _ sql = 3. request statement for \ \ view

requested string primary _ key = 4; \ primary key of view

... ...

}

optional View view = 1;

optional Transform front Transform = 2 \ \ replace at front end

optional Transform backup Transform = 3 \ \ substitution at back end

... ...

}

For easy understanding, please refer to fig. 7, where fig. 7 is a directed acyclic graph formed by data sources and result views in the embodiment of the present application, and as shown in the figure, the inside of the view mainly consists of a plurality of data sources having direct or indirect relationships and a result view statement (view SQL). The data source is a data set participating in the calculation of the data view, the data source can be a simple query statement (for example, SQL statement) or a complex SQL statement (for example, Join), and the data source and the result view form a directed acyclic graph.

Exemplarily, it is assumed that the first request statement corresponds to a read-only event, and the first request statement specifically includes:

select FUId, FTId，FTargetDef From Tbl_Commodity where FUId = 20561 andFTId = 100;

since the first request statement is a "select" statement, the first request statement corresponds to a read-only type event, and a corresponding target rule is determined based on a target data entity "Tbl _ command" in the first request statement, wherein the target rule includes an operation rule of "view data through target view", specifically, the target view is as follows:

code segment 10: view

source {

query _ sql: "SELECT FUId, FTId, EXPLODE (FTargetDef, '/target/def _ id') as FDId FROM Tbl _ CommodetyEx \ \ selecting" FUId "," FTId "and" FTargetDef "FROM the" Tbl _ CommodetyEx "table, and obtaining a"/target/def _ id "sub-item FROM the" FTargetDef ", named" FDId "

alias: "ex _ def" as a result of executing the instruction of the above select statement "

}

view _ sql "SELECT FUId, FTId, FDId FROM ex _ def" \ \ View creation instruction, SELECT "FUId", "FTId", and "FDId" FROM "ex _ def"

}

Based on this, the view generating statement is obtained according to the target view, and the view generating statement and the first request statement are combined to generate the second request statement, that is, the second request statement includes the view generating statement and the first request statement including the target view, wherein in the first request statement including the target view, the original target data entity is replaced by the target view.

Secondly, in the embodiment of the present application, a manner for implementing request statement conversion based on a read-only event is provided, and in the manner, if a first request statement corresponds to the read-only event, a target view corresponding to a target data entity is determined, and a second request statement is generated according to the target view and the first request statement. The goal of view concentration is achieved with the target view, which improves data security by allowing the user to see only the data defined in the view, rather than the data in the view reference table, and in addition, the view simplifies the user's manipulation of the data.

if the first request statement corresponds to the writable event, generating an extended execution statement corresponding to the first request statement according to the first request statement and an operation rule included by a target rule;

or the like, or, alternatively,

obtaining a second request statement according to the first request statement and the operation rule included in the target rule, specifically including the following steps:

generating a third request statement according to the first request statement;

In this embodiment, a manner of implementing request statement conversion based on a writable event is introduced, and when a first request statement is generated into a second request statement, a variety of conversion contents need to be considered, including but not limited to field conversion, conditional conversion, and entity conversion.

Specifically, the query context of the rule corresponds to an insert (add) event, a delete event, or a modify event, and the insert (add) event, the delete event, and the modify event are all writable events. Query context refers to operations where the rule content is read-only for data operations, and typically includes elements such as views, transformations, and virtual field definitions, where the writable context includes mainly the following elements:

mode (mode) is the method by which the rule is rewritten for the original request (first request statement).

The operation (operator) represents the manner in which the original request (first request statement) operates on the write of data, e.g., insert, update, or delete.

The execution statement (mute) represents a change to the original request (first request statement).

An extended execution statement (extended statement), that is, several extended data write statements, may be executed synchronously or asynchronously.

In conjunction with the above description, an example of the code for a target rule, which may be named "rule _ insert _ extended", is provided below, as follows:

code segment 11: rule _ items

event: INSERT

condition { item { expression { field: "FTargetDef" operator: Present } reference: NEW } } \ when the "FTargetDef" field exists

mutate_context {

mode, the ALSO \ \ first request statement and the third request statement execute together

extend_mutate {

mutate {

entity: "Tbl_Targeting"

ADD/insert for operator

order-enter \ \ execute AFTER the first request statement

field_list { field: "FTId" field: "FUId" field: "FDId"}

}

view {

source {

alias: "ex _ def" \ \ names the result of the execution of the select instruction as "ex _ def"

}

}

value_list {

FIELD _ replace { FIELD: "FTId" value { flag: NATIVE _ FIELD FIELD: "FTId" entry: "view _ add" } \ the data of "FTId" in the above insertion instruction is determined from the "FTId" FIELD in the view "view _ add

FIELD _ replace { FIELD: "FUId" value { flag: NATIVE _ FIELD FIELD: "FUId" entry: "view _ add" } \ the data of "FUId" in the above insertion instruction is determined from the "FUId" FIELD in the view "view _ add

FIELD _ replace { FIELD: "FDefId" value { flag: NATIVE _ FIELD FIELD: "FDefId" entity: "view _ add" } \ the data of "FDefId" in the above insertion instruction is determined from the "FDefId" FIELD in the view "view _ add

Based on this, assume that the first request statement is:

insert into Tbl_Commodity (FUId, FTId, FTargetDef) values(28561, 101, x’0A200A0667656E64657212140A060A040801100D0A0’);

wherein, the target data entity is "Tbl _ Commodity", assuming that the "Tbl _ Commodity" satisfies the target rule, and based on the code content, when new data is inserted into the target data entity "Tbl _ Commodity", if the "FTargetDef" field is included, the data entity "Tbl _ Targeting" is also updated, thereby generating an extended execution statement, which is as follows:

insert into Tbl_Targeting（FTId，FUId，FDId）values（101, 28561, x’ 0A200A0667656E64657212140A060A040801100D0A0’）;

wherein the inserted value is obtained by the view query defined in the target rule based on the extended execution statement of the target rule. Since the contents in the view are obtained based on the result of the execution of the first request statement, the extended execution statement needs to be executed after the completion of the execution of the first request statement.

The second request statement thus obtained is:

illustratively, if the target rule also includes a rule with the rule name "rule _ insert", the following is specified:

rule_items {

event: INSERT

mute _ context { front _ transform { entity _ replace: "Tbl _ commodityEx _" } \ \ for an insert operation, the name of the entity is replaced with "Tbl _ commodityEx _"

There may also be another target rule for the target data entity "Tbl _ Commodity", which is to replace the data entity name in the first request statement with "Tbl _ CommodityEx _" when new data is inserted for the target data entity "Tbl _ Commodity".

Based on this, assume that the first request statement is still:

at this time, the two target rules are hit simultaneously, and then the first request statement is converted into a third request statement according to the target rule "rule _ insert", where the third request statement is as follows:

Insert into Tbl_CommodityEx_ (FUId, FTId, FTargetDef) values(28561, 101,x’ 0A200A0667656E64657212140A060A040801100D0A0’);

the second request statement thus obtained is:

in addition, in an actual situation, the number of the target rules may be one, or two or more, and is only one example here, and should not be construed as a limitation to the present application.

Secondly, in the embodiment of the present application, a manner for implementing request statement conversion based on a writable event is provided, and in the manner, if a first request statement corresponds to the writable event, an extended execution statement is generated according to an operation rule under a target rule, and in addition, an original first request statement may be modified or not modified, so that a second request statement may be generated based on the extended execution statement and the first request statement, or the second request statement may be generated based on the extended execution statement and the third request statement, thereby improving flexibility of data access.

Optionally, on the basis of the embodiment corresponding to fig. 5, in another optional embodiment provided in the embodiment of the present application, the sending a second data access request to the storage service, so that the storage service executes a second request statement according to the second data access request specifically includes the following steps:

sending a second data access request to the storage service, so that the storage service executes the extended execution statement and the first request statement according to the second data access request;

or, sending a second data access request to the storage service, so that the storage service executes a second request statement according to the second data access request, specifically including the following steps:

sending a second data access request to the storage service, so that the storage service executes the extended execution statement and the third request statement according to the second data access request;

In this embodiment, a manner of executing a plurality of request statements synchronously is introduced, and when sending the second data access request, the extended execution statement and the first request statement (or the third request statement) may be executed synchronously in consideration of the logical relationship and the function between the extended execution statement and the first request statement (or the third request statement). Specifically, in response to the second data access request, the storage service first executes the first request statement (or the third request statement), and then executes the extended execution statement after executing the first request statement or the third request statement, so as to obtain the data execution result of the data access request.

In conjunction with the above description, an example of a synchronous execution data access request is provided below, taking the following code segment as an example of a target rule, which may be named "rule _ insert _ extend", as follows:

code segment 12: rule _ items

event: UPDATE

condition { item { expression {field: "FTargetDef" operator: PRESENT}reference: NEW }}

mutate_context {

mode: ALSO

extend_mutate {

mutate {

entity: "Tbl_Targeting_"

operator DELETE \ deletion

order: AFTER

predicates {

predicator { field: "FTId" operator: EQUALS } \ \ FTId "EQUALS

predicator { field: "FUId" operator: EQUALS } \ \ FUId "is equal to

predicator { field: "FDId" operator: IN } \ \ FDId "is IN

}

BEFORE \ BEFORE execution of the first request statement or the third request statement

view {

source {

query _ sql: "SELECT FUId, FTId, EXPLODE (FTargetDef,'/target/def _ id) as FDId FROM Tbl _ CommodetyEx \\ \ selecting" FUId "," FTId "and" FTargetDef "FROM the" Tbl _ CommodetyEx "table, and dividing" FTargetDef "by"/target/def _ id "and naming" FDId "

alias: "ex_def"

}

view _ sql for selecting "SELECT FUId, FTId, FDefId FROM ex _ def" \ \ View establishment instruction, selecting "FUId", "FTId", and "FDefId" FROM "ex _ def"

}

value_list {

FIELD _ replace { FIELD: "FTId" value { flag: NAVIE _ FIELD FIELD: "FTId" entry: "view _ update _ before" } } \ \ data of "FTId" in the above insertion instruction is determined from "FTId" FIELD in view "view _ update _ before

FIELD _ replace { FIELD: "FUId" value { flag: NAVIE _ FIELD FIELD: "FUId" entry: "view _ update _ before" } } \ \ data of "FUId" in the above insertion instruction is determined from the "FUId" FIELD in the view "view _ update _ before

FIELD _ replace { FIELD: "FDId" value { flag: NAVIE _ FIELD FIELD: "FDId" entry: "view _ update _ before" } } \ \ data of "FDId" in the above insertion instruction is determined from the "FDId" FIELD in the view "view _ update _ before

}

extend_mutate {

mutate {

entity: "Tbl_Targeting_"

operator: "ADD"

order: "AFTER"

field_list { field: "FTId" field: "FUId" field: "FDdfID"

}

view {

source {

query _ sql: "SELECT FUId, FUId, EXPLODE (FTargetDef,'/target/def _ id) as FDId FROM Tbl _ CommodetyEx \ \ selecting" FUId "," FTId "and" FTargetDef "FROM the" Tbl _ CommodetyEx "table, and dividing" FTargetDef "by"/target/def _ id "and naming" FDId "

alias: "ex_def"

}

}

value_list {

FIELD _ replace { FIELD: "FTId" value { flag: NAVIE _ FIELD FIELD: "FTId" entry: "view _ update _ after" } } \ \ data of "FTId" in the above insertion instruction is determined from the "FTId" FIELD in the view "view _ update _ after

FIELD _ replace { FIELD: "FUId" value { flag: NAVIE _ FIELD FIELD: "FUId" entry: "view _ update _ after" } \ the data of "FUId" in the above insertion instruction is determined from the "FUId" FIELD in the view "view _ update _ after

FIELD _ replace { FIELD: "FDId" value { flag: NAVIE _ FIELD FIELD: "FDId" entry: "view _ update _ after" } } \ \ the data of "FDId" in the above insertion instruction is determined from the "FDId" FIELD in the view "view _ update _ after

}

Based on this, assume that the first request statement is:

Update Tbl_Commodity set FTId=“101”, FTargetDef=“x’ 0A200A0667656E64657212140A060A040801100D0A0” where FUId=28561;

wherein, the target data entity is "Tbl _ Commodity", and assuming that the target data entity "Tbl _ Commodity" satisfies the target rule, based on the code content, when performing data update on the target data entity "Tbl _ Commodity", if the first request statement includes the "FTargetDef" field, the content in the data entity "Tbl _ Targeting" is deleted, and after updating the target data entity "Tbl _ Commodity", the data entity "Tbl _ Targeting" is updated again, so as to generate an extended execution statement, where:

Delete from Tbl_Targeting where FUId=28561;

in the case of executing the second request statement synchronously, the first request statement is executed first, after the target data entity "Tbl _ command" is updated, a delete instruction for the data entity "Tbl _ Targeting" and an update instruction for the data entity "Tbl _ Targeting" are executed based on the updated execution result, and the execution result of the statements is taken as the execution result of the second data access request.

Illustratively, if the target rule further includes a rule with a rule name of "rule _ update", the following is specific:

code segment 13: rule _ items

event: UPDATE

mute _ context { front _ transform { entity _ replace: "Tbl _ commodityEx _" } \ \ for an update operation, the name of the entity is replaced with "Tbl _ commodityEx _"

There may also be another target rule for the target data entity "Tbl _ Commodity", which is to replace the data entity name in the first request statement with "Tbl _ commodutyex _" when a data update is performed on the target data entity "Tbl _ Commodity".

Based on this, assume that the first request statement is still:

at this time, the two target rules are hit at the same time, and then the first request statement is converted into a third request statement according to the target rule "rule _ update", where the third request statement is as follows:

Update Tbl_CommodityEx_ set, FTId=“101”, FTargetDef=“x’ 0A200A0667656E64657212140A060A040801100D0A0’” where FUId=28561;

the second request statement thus obtained is:

Delete from Tbl_Targeting where FUId=28561;

in the case of synchronous execution of the second request statement, the third request statement is executed first, after the target data entity "Tbl _ command" is updated, a delete instruction for the data entity "Tbl _ Targeting" and an update instruction for the data entity "Tbl _ Targeting" are executed based on the updated execution result, and the execution result of the third request statement is taken as the execution result of the second data access request.

In the embodiment of the present application, a manner of executing multiple request statements synchronously is provided, and in the manner, when a request statement is executed, a data execution result can be directly obtained, so that the response to an exception is faster, and the obtained data execution result is more accurate.

sending a second data access request to the storage service, so that the storage service executes the first request statement and the extended execution statement according to the second data access request;

or, sending the second data access request to the storage service, so that the storage service executes the second request statement according to the second data access request, including:

In this embodiment, a manner of asynchronously executing a plurality of request statements is introduced, and in the second data access request, the extended execution statement and the first request statement (or the third request statement) may be asynchronously executed in consideration of the logical relationship and function between the extended execution statement and the first request statement (or the third request statement). Specifically, in response to the second data access request, the storage service first executes the first request statement (or the third request statement), acquires the data execution result for the first request statement (or the third request statement), and then executes the extended execution statement at a subsequent time, thereby acquiring the data execution result for the extended execution statement again.

In conjunction with the above description, an example of an asynchronous execution of data access requests will now be provided, referring again to code segment 12 above:

assume that the first request statement is:

Update Tbl_Commodity set FTId=“101”, FTargetDef=“x’ 0A200A0667656E64657212140A060A040801100D0A0’” where FUId=28561;

wherein, the target data entity is "Tbl _ Commodity", and assuming that the target data entity "Tbl _ Commodity" satisfies the target rule, based on the code content, when data update is performed on the target data entity "Tbl _ Commodity", if the field "FTargetDef" is included, the content in the data entity "Tbl _ Targeting" is deleted, and after the target data entity "Tbl _ Commodity" is updated, the data entity "Tbl _ Targeting" is updated, so as to generate an extended execution statement, where the extended execution statement is as follows:

Delete from Tbl_Targeting where FUId=28561;

in the case of asynchronous execution of the second request statement, the first request statement is executed first, and after the target data entity "Tbl _ command" is updated, the data execution result of the first request statement is taken as the execution result of the second data access request. Then, the delete command for the data entity "Tbl _ Targeting" and the update command for the data entity "Tbl _ Targeting" are executed to complete the execution process of the second data access request.

Please refer to the above code segment 13, wherein there may be another target rule for the target data entity "Tbl _ Commodity", the target rule being that when a data update is performed on the target data entity "Tbl _ Commodity", the data entity name in the first request statement is replaced with "Tbl _ commodityeex _".

Based on this, assume that the first request statement is still:

the second request statement thus obtained is:

Delete from Tbl_Targeting where FUId=28561;

in the case of asynchronously executing the second request statement, the third request statement is executed first, after the target data entity "Tbl _ command" is updated, the execution result of the third request statement is taken as the execution result of the second data access request, and then the delete instruction for the data entity "Tbl _ Targeting" and the update instruction for the data entity "Tbl _ Targeting" are executed to complete the execution process of the second data access request.

In the embodiment of the present application, a manner of asynchronously executing multiple request statements is provided, and in the manner, when a request statement is executed, because an execution result of a data execution result of an expanded execution statement with respect to a second request statement, efficiency of obtaining the data execution result of the second request statement with respect to the second request statement can be improved.

Optionally, on the basis of the embodiment corresponding to fig. 5, in another optional embodiment provided in the embodiment of the present application, the method may further include the following steps:

if the first request statement meets a first statement rule hit sub-condition included in the target rule, acquiring a fourth request statement according to the first request statement and a first sub-operation rule included in the target rule, wherein the first statement rule hit sub-condition is included in the target rule;

sending a third data access request to the storage service so that the storage service executes a fourth request statement according to the third data access request, wherein the third data access request comprises the fourth request statement;

receiving a data execution result aiming at the fourth request statement sent by the storage service;

if the data execution result aiming at the fourth request statement meets a second statement rule hit sub-condition included in the target rule, acquiring a fifth request statement according to the first request statement and a second sub-operation rule included in the target rule, wherein the second statement rule hit sub-condition is included in the target rule;

and sending a fourth data access request to the storage service so that the storage service executes a fifth request statement according to the fourth data access request, wherein the fourth data access request comprises the fifth request statement.

In this embodiment, a processing method for hit conditions of the rules of the standby statements is introduced. Specifically, in the first loop, assuming that the first request statement satisfies a part of the conditions in the target rule, that is, satisfies the first statement rule hit sub-condition, the rule service generates a fourth request statement according to the first request statement and the first sub-operation rule corresponding to the first statement rule hit sub-condition, and at this time, the conversion of the first request statement is completed. Then, the converted fourth request statement is encapsulated in the third data access request, and then the third data access request is sent to the storage service. Based on this, the rule service may receive a data execution result for the fourth request statement.

In the second loop, assuming that the second statement rule hit sub-condition included in the target rule is satisfied with respect to the data execution result of the fourth request statement, that is, the second statement rule hit sub-condition is satisfied, the rule service generates a fifth request statement according to the first request statement and the second sub-operation rule corresponding to the second statement rule hit sub-condition, and at this time, the conversion of another request statement is completed. Then, the converted fifth request statement is encapsulated in the fourth data access request, and then the fourth data access request is sent to the storage service. Based on this, the rule service may receive a data execution result for the fifth request statement.

Secondly, in the embodiment of the application, a processing mode for hit conditions of the statement rules in standby is provided, and by the mode, complex logic can be executed based on the hit conditions of the statement rules, so that the times of statement requests are reduced, and the code execution efficiency is improved.

and if the data execution result aiming at the fourth request statement does not meet the hit sub-condition of the second statement rule, sending a first data access request to the storage service so that the storage service executes the first request statement according to the first data access request.

In this embodiment, another processing method for the hit condition of the rule of the to-be-hit statement is introduced. Specifically, in the first loop, assuming that the first request statement satisfies a part of the conditions in the target rule, that is, satisfies the first statement rule hit sub-condition, the rule service generates a fourth request statement according to the first request statement and the first sub-operation rule corresponding to the first statement rule hit sub-condition, and at this time, the conversion of the first request statement is completed. Then, the converted fourth request statement is encapsulated in the third data access request, and then the third data access request is sent to the storage service. Based on this, the rule service may receive a data execution result for the fourth request statement.

In the second loop, assuming that the data execution result for the fourth request statement does not satisfy the second statement rule included in the target rule, the sub-condition satisfies another part of the conditions in the target rule, that is, the first data access request is directly sent to the storage service, and the storage service executes the first request statement according to the first data access request, based on which the rule service can receive the data execution result for the first request statement.

In the embodiment of the application, another processing mode aiming at the hit condition of the statement rule to be hit is provided, and by the mode, complex logic can be executed based on the hit sub-condition of a plurality of statement rules, so that the times of statement requests are reduced, and the code execution efficiency is improved. And for the situation that the sub-condition is not met and the statement rule is hit, the original request statement is directly sent to the storage service, so that the sending times of the request statement are reduced, and the transmission resource is saved.

and if the first request statement does not meet any rule to be matched in the rule set to be matched, sending a first data access request to the storage service so that the storage service executes the first request statement according to the first data access request.

In this embodiment, a processing method of a hit condition of a missed statement rule is introduced, and specifically, a rule set to be matched may be obtained first according to a target data entity (i.e., a logic table) indicated by a first request statement, where the rule set to be matched may include N rules to be matched, and if it is found after comparison that a first request statement does not hit any rule to be matched in the rule set to be matched, at this time, conversion of the first request statement is not required, so that the rule service directly sends a first data access request carrying the first request statement to a storage service, and the storage service executes the first request statement according to the first data access request.

The first request statement comprises operations of inserting, querying, updating or deleting the target data entity and the like. And if the storage service executes the inserting operation, acquiring a data execution result after data inserting. And if the storage service executes the query operation, acquiring a data execution result obtained by the query. And if the storage service executes the updating operation, acquiring a data execution result after the data updating. And if the storage service executes the deletion operation, acquiring a data execution result after the data deletion.

Secondly, in the embodiment of the present application, a processing method of a hit condition of a missed statement rule is provided, and by the above method, if it is detected that the first request statement does not satisfy any rule to be matched in a rule set to be matched, it is not necessary to provide differentiated data for the target data circulation domain, so that the original request statement is directly executed, thereby increasing feasibility and flexibility of the scheme.

With reference to the above description, the data access method in the present application will be described from the perspective of a storage service, and referring to fig. 8, an embodiment of the data access method in the embodiment of the present application includes:

201. receiving a second data access request sent by the rule service;

The rule service may determine a rule set to be matched based on the target data entity and the target data circulation domain, that is, the rule set to be matched is applicable to the target data circulation domain, and the rule set to be matched is a relevant rule for accessing the target data entity. After the first data access request is transmitted from a data access layer of a data infrastructure, a first request statement is obtained through analysis of the first data access request, the first request statement is preprocessed and subjected to basic validity check, rules which may be matched with the data request are analyzed according to contents (data entities, conditions, request data contents and the like) of the first request statement, and a rule set to be matched is obtained, wherein the rule set to be matched includes at least one rule to be matched, the rule to be matched may be a determined result (for example, hit or miss) or an uncertain result (for example, undetermined), and for the uncertain result, whether hit may be determined in a subsequent execution stage or in a data result fusion stage after execution. Thus, one rule for a data access request may have one or more result sets.

The rule service needs to detect whether the first request statement hits the rule set to be matched, if the rule set to be matched includes N rules to be matched, N matching results are generated according to the first request statement and the rules to be matched, and for the rules to be matched that are successfully matched, the rules to be matched are the target rules corresponding to the first request statement.

The rule service may encapsulate the second request statement in the second data access request after generating the second request statement, and may also encapsulate the accessor identification in the second data access request with the second request statement. The rule service then sends a second data access request to the storage service, and the storage service receives the second data access request sent by the rule service.

It should be noted that the logic of the storage service is deployed in a server, and the server may be an independent server or a cloud server, which is not limited herein.

202. Executing a second request statement according to the second data access request;

in this embodiment, the storage service executes the second request statement according to the second data access request, and specifically, the storage service may perform parsing processing on the second data access to obtain the accessing party identifier and the second request statement. The storage service may then execute a second request statement that includes an insert, query, update, or delete operation on the target data entity.

203. Acquiring a data execution result for the second request statement;

in this embodiment, based on step 202, if the storage service executes the insert operation, the data execution result after the data insert is obtained. And if the storage service executes the query operation, acquiring a data execution result obtained by the query. And if the storage service executes the updating operation, acquiring a data execution result after the data updating. And if the storage service executes the deletion operation, acquiring a data execution result after the data deletion.

204. Sending a data execution result to a data access party;

in this embodiment, the storage service may determine the data access party based on the access party identifier, and then send the data execution result to the data access party, or send the data execution result to the data access party through the application layer, which is not limited herein.

In the embodiment of the application, another data access method is provided, and in the above manner, the same target data entity can hit different rule sets to be matched in different data circulation domains, that is, the basis for determining the rule sets to be matched includes the data circulation domain. Different rule sets to be matched can be hit in different data entities in the same target data circulation domain, namely the basis for determining the rule sets to be matched comprises the data entities. The same request statement of the same target data entity can hit different operation rules according to different statement rule hit conditions. Therefore, the data flow domain can shield the specific storage modes of different data entities, so that the differentiation requirements of the data flow domain are met, and the data entity can be accessed more conveniently and flexibly by the data flow domain.

Referring to fig. 9, fig. 9 is a schematic diagram of an embodiment of a data access apparatus in an embodiment of the present application, where the data access apparatus 30 includes:

an obtaining module 301, configured to obtain a first data access request for a target data entity, where the first data access request includes a first request statement and an accessing party identifier, and the accessing party identifier is used to indicate a target data circulation domain;

a determining module 302, configured to determine a rule set to be matched according to a target data entity and a target data circulation domain, where the rule set to be matched has a corresponding relationship with the target data entity, the rule set to be matched includes at least one rule to be matched, and each rule to be matched includes a statement rule hit condition and a corresponding relationship between operation rules;

the obtaining module 301 is further configured to, if the first request statement meets a statement rule hit condition included in the target rule, obtain a second request statement according to the first request statement and an operation rule included in the target rule, where the target rule belongs to a rule to be matched included in a rule set to be matched;

a sending module 303, configured to send a second data access request to the storage service, so that the storage service executes a second request statement according to the second data access request, where the second data access request includes the second request statement.

In the embodiment of the application, a data access device is provided, and with the device, the same target data entity can hit different rule sets to be matched in different data circulation domains, that is, the basis for determining the rule sets to be matched includes the data circulation domains. Different rule sets to be matched can be hit in different data entities in the same target data circulation domain, namely the basis for determining the rule sets to be matched comprises the data entities. The same request statement of the same target data entity can hit different operation rules according to different statement rule hit conditions. Therefore, the data flow domain can shield the specific storage modes of different data entities, so that the differentiation requirements of the data flow domain are met, and the data entity can be accessed more conveniently and flexibly by the data flow domain.

Optionally, on the basis of the embodiment corresponding to fig. 9, in another embodiment of the data access device 30 provided in the embodiment of the present application, the data access device 30 further includes a generating module 304;

the obtaining module 301 is further configured to obtain a data circulation domain, a data entity, a statement rule hit condition and an operation rule, where the statement rule hit condition includes an event and a rule hit condition, and the operation rule includes a rule behavior and a rule mapping;

the generating module 304 is configured to generate a rule to be matched according to the data circulation domain, the data entity, the statement rule hit condition, and the operation rule.

Secondly, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, different rules may be configured according to a target data circulation domain corresponding to a data access party, and the setting may be performed from multiple dimensions, such as a data circulation domain, a data entity, an event, a rule hit condition, a rule behavior, and rule mapping, so as to improve feasibility and operability of a scheme.

Optionally, on the basis of the embodiment corresponding to fig. 9, in another embodiment of the data access device 30 provided in the embodiment of the present application,

the determining module 302 is specifically configured to determine, if the first request statement corresponds to a read-only event, a target view corresponding to a target data entity according to the first request statement and an operation rule included in the target rule;

Secondly, in an embodiment of the present application, a data access apparatus is provided, where, by using the apparatus, if a first request statement corresponds to a read-only event, a target view corresponding to a target data entity is determined, and a second request statement is generated according to the target view and the first request statement. The goal of view concentration is achieved with the target view, which improves data security by allowing the user to see only the data defined in the view, rather than the data in the view reference table, and in addition, the view simplifies the user's manipulation of the data.

the determining module 302 is specifically configured to, if the first request statement corresponds to the writable event, generate an extended execution statement corresponding to the first request statement according to the first request statement and an operation rule included in the target rule;

or the like, or, alternatively,

generating a third request statement according to the first request statement;

Secondly, in this embodiment of the present application, a data access apparatus is provided, where, by using the apparatus, if a first request statement corresponds to a writable event, an extended execution statement is generated according to an operation rule under a target rule, and in addition, an original first request statement may or may not be modified, so that a second request statement may be generated based on the extended execution statement and the first request statement, or the second request statement may be generated based on the extended execution statement and a third request statement, thereby improving flexibility of data access.

a sending module 303, specifically configured to send a second data access request to the storage service, so that the storage service executes the extended execution statement and the first request statement according to the second data access request;

or the like, or, alternatively,

a sending module 303, specifically configured to send a second data access request to the storage service, so that the storage service executes the extended execution statement and the third request statement according to the second data access request;

Furthermore, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, when a request statement is executed, a data execution result may be directly obtained, so that a response to an exception is faster, and the obtained data execution result is more accurate.

a sending module 303, specifically configured to send a second data access request to the storage service, so that the storage service executes the first request statement and the extended execution statement according to the second data access request;

or the like, or, alternatively,

In addition, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, when a request statement is executed, because an execution result of a data execution result of an expanded execution statement with respect to a second request statement is provided, efficiency of obtaining the data execution result of the second request statement with respect to the second request statement can be improved.

Optionally, on the basis of the embodiment corresponding to fig. 9, in another embodiment of the data access device 30 provided in the embodiment of the present application, the data access device 30 further includes a receiving module 305;

the obtaining module 301 is further configured to, if the first request statement satisfies a hit sub-condition of the first statement rule included in the target rule, obtain a fourth request statement according to the first request statement and the first sub-operation rule included in the target rule, where the hit sub-condition of the first statement rule is included in the target rule;

a sending module 303, further configured to send a third data access request to the storage service, so that the storage service executes a fourth request statement according to the third data access request, where the third data access request includes the fourth request statement;

a receiving module 305, configured to receive a data execution result for the fourth request statement sent by the storage service;

the obtaining module 301 is further configured to, if a data execution result for the fourth request statement satisfies a second statement rule hit sub-condition included in the target rule, obtain a fifth request statement according to the first request statement and a second sub-operation rule included in the target rule, where the second statement rule hit sub-condition is included in the target rule;

the sending module 303 is further configured to send a fourth data access request to the storage service, so that the storage service executes a fifth request statement according to the fourth data access request, where the fourth data access request includes the fifth request statement.

Secondly, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, a complex logic may be executed based on a sub-condition hit by a plurality of statement rules, thereby reducing the number of times of statement requests and improving code execution efficiency.

the sending module 303 is further configured to send the first data access request to the storage service if the data execution result for the fourth request statement does not satisfy the second statement rule hit sub-condition, so that the storage service executes the first request statement according to the first data access request.

Thirdly, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, a complex logic may be executed based on a sub-condition hit by a plurality of statement rules, thereby reducing the number of times of statement requests and improving code execution efficiency. And for the situation that the sub-condition is not met and the statement rule is hit, the original request statement is directly sent to the storage service, so that the sending times of the request statement are reduced, and the transmission resource is saved.

the sending module 303 is further configured to send a first data access request to the storage service if the first request statement does not satisfy any rule to be matched in the rule set to be matched, so that the storage service executes the first request statement according to the first data access request.

Secondly, in the embodiment of the present application, a data access apparatus is provided, and with the above apparatus, if it is detected that the first request statement does not satisfy any rule to be matched in the rule set to be matched, it may not be necessary to provide differentiated data for the target data circulation domain, so that the original request statement may be directly executed, thereby increasing feasibility and flexibility of the scheme.

Referring to fig. 10, fig. 10 is a schematic view of another embodiment of the data access device in the embodiment of the present application, and the data access device 40 includes:

a receiving module 401, configured to receive a second data access request sent by the rule service;

an execution module 402, configured to execute the second request statement according to the second data access request;

an obtaining module 403, configured to obtain a data execution result for the second request statement;

a sending module 404, configured to send a data execution result to the data accessing party;

In the embodiment of the present application, another data access apparatus is provided, and with the above apparatus, the same target data entity may hit different rule sets to be matched in different data flow domains, that is, the basis for determining the rule sets to be matched includes the data flow domain. Different rule sets to be matched can be hit in different data entities in the same target data circulation domain, namely the basis for determining the rule sets to be matched comprises the data entities. The same request statement of the same target data entity can hit different operation rules according to different statement rule hit conditions. Therefore, the data flow domain can shield the specific storage modes of different data entities, so that the differentiation requirements of the data flow domain are met, and the data entity can be accessed more conveniently and flexibly by the data flow domain.

Fig. 11 is a schematic diagram of a server structure provided in an embodiment of the present application, where the server 500 may have a relatively large difference due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 522 (e.g., one or more processors) and a memory 532, and one or more storage media 530 (e.g., one or more mass storage devices) for storing applications 542 or data 544. Memory 532 and storage media 530 may be, among other things, transient storage or persistent storage. The program stored on the storage medium 530 may include one or more modules (not shown), each of which may include a series of instruction operations for the server. Still further, the central processor 522 may be configured to communicate with the storage medium 530, and execute a series of instruction operations in the storage medium 530 on the server 500.

The Server 500 may also include one or more power supplies 526, one or more wired or wireless network interfaces 550, one or more input-output interfaces 558, and/or one or more operating systems 541, such as a Windows Server^TM，Mac OS X^TM，Unix^TM, Linux^TM，FreeBSD^TMAnd so on.

The steps performed by the server in the above embodiment may be based on the server structure shown in fig. 11.

In the embodiment of the present application, a data access system is further provided, please refer to fig. 12, fig. 12 is a schematic structural diagram of the data access system in the embodiment of the present application, and as shown in the figure, the data access system 60 includes a rule server 601 and a storage server 602;

the rule server 601 is configured to receive a first data access request, which is sent by a data accessing party and is directed to a target data entity, where the first data access request includes a first request statement and an accessing party identifier, and the accessing party identifier is used to indicate a target data circulation domain;

the rule server 601 is configured to determine a rule set to be matched according to a target data entity and a target data circulation domain, where the rule set to be matched has a corresponding relationship with the target data entity, the rule set to be matched includes at least one rule to be matched, and each rule to be matched includes a statement rule hit condition and a corresponding relationship between operation rules;

the rule server 601 is configured to, if the first request statement satisfies a statement rule hit condition included in the target rule, obtain a second request statement according to the first request statement and an operation rule included in the target rule, where the target rule belongs to a rule to be matched included in a rule set to be matched;

a rule server 601, configured to send a second data access request to the storage server 602, where the second data access request includes a second request statement;

a storage server 602, configured to execute a second request statement according to a second data access request;

a storage server 602, configured to obtain a data execution result for the second request statement;

and the storage server 602 is used for sending the data execution result to the data access party.

In the embodiment of the application, a data access system is provided, and by adopting the system, the same target data entity can hit different rule sets to be matched in different data circulation domains, that is, the basis for determining the rule sets to be matched comprises the data circulation domains. Different rule sets to be matched can be hit in different data entities in the same target data circulation domain, namely the basis for determining the rule sets to be matched comprises the data entities. The same request statement of the same target data entity can hit different operation rules according to different statement rule hit conditions. Therefore, the data flow domain can shield the specific storage modes of different data entities, so that the differentiation requirements of the data flow domain are met, and the data entity can be accessed more conveniently and flexibly by the data flow domain.

Embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored, and when the computer program runs on a computer, the computer is caused to execute the method described in the foregoing embodiments.

Embodiments of the present application also provide a computer program product including a program, which, when run on a computer, causes the computer to perform the methods described in the foregoing embodiments.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A method of data access, comprising:

determining a rule set to be matched according to the target data entity and the target data circulation domain, wherein the rule set to be matched has a corresponding relation with the target data entity, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

if the first request statement meets a statement rule hit condition included in a target rule, acquiring a second request statement according to the first request statement and an operation rule included in the target rule, wherein the target rule belongs to a rule to be matched included in the rule set to be matched;

sending a second data access request to a storage service to cause the storage service to execute the second request statement according to the second data access request, wherein the second data access request comprises the second request statement.

2. The method of claim 1, further comprising:

3. The method according to claim 1, wherein the obtaining a second request statement according to the operation rule included in the first request statement and the target rule comprises:

if the first request statement corresponds to a read-only event, determining a target view corresponding to the target data entity according to the first request statement and an operation rule included by the target rule;

and generating the second request statement according to the target view and the first request statement.

4. The method according to claim 1, wherein the obtaining a second request statement according to the operation rule included in the first request statement and the target rule comprises:

if the first request statement corresponds to a writable event, generating an extended execution statement corresponding to the first request statement according to the first request statement and an operation rule included by the target rule;

generating the second request statement according to the extended execution statement and the first request statement;

or the like, or, alternatively,

the obtaining a second request statement according to the first request statement and the operation rule included in the target rule includes:

generating a third request statement according to the first request statement;

and generating the second request statement according to the extended execution statement and the third request statement.

5. The method of claim 4, wherein sending a second data access request to a storage service to cause the storage service to execute the second request statement in accordance with the second data access request comprises:

sending the second data access request to the storage service, so that the storage service executes the extended execution statement and the first request statement according to the second data access request;

receiving a data execution result sent by the storage service and aiming at the first request statement;

or, the sending the second data access request to the storage service, so that the storage service executes the second request statement according to the second data access request, includes:

sending the second data access request to the storage service, so that the storage service executes the extended execution statement and the third request statement according to the second data access request;

6. The method of claim 4, wherein sending a second data access request to a storage service to cause the storage service to execute the second request statement in accordance with the second data access request comprises:

sending the second data access request to the storage service, so that the storage service executes the first request statement and the extended execution statement according to the second data access request;

and receiving a data execution result aiming at the extension execution statement sent by the storage service.

7. The method of claim 1, further comprising:

sending a third data access request to the storage service to cause the storage service to execute the fourth request statement according to the third data access request, wherein the third data access request comprises the fourth request statement;

receiving a data execution result sent by the storage service and aiming at the fourth request statement;

if the data execution result for the fourth request statement satisfies a second statement rule hit sub-condition included in the target rule, acquiring a fifth request statement according to the first request statement and a second sub-operation rule included in the target rule, where the second statement rule hit sub-condition is included in the target rule;

sending a fourth data access request to the storage service to cause the storage service to execute the fifth request statement according to the fourth data access request, wherein the fourth data access request comprises the fifth request statement.

8. The method of claim 7, further comprising:

if the data execution result for the fourth request statement does not satisfy the hit sub-condition of the second statement rule, sending the first data access request to the storage service, so that the storage service executes the first request statement according to the first data access request.

9. The method of claim 1, further comprising:

if the first request statement does not satisfy any rule to be matched in the rule set to be matched, sending the first data access request to the storage service so that the storage service executes the first request statement according to the first data access request.

10. A method of data access, comprising:

receiving a second data access request sent by the rule service;

acquiring a data execution result for the second request statement;

sending the data execution result to a data access party;

the second data access request includes a second request statement, the second request statement is generated according to a first request statement and an operation rule included by a target rule, the first request statement satisfies a statement rule hit condition included by the target rule, the target rule is included in a rule set to be matched, the rule set to be matched includes at least one rule to be matched, each rule to be matched includes a corresponding relationship between the statement rule hit condition and the operation rule, the first request statement includes a first data access request sent by the data accessing party, and the first data access request is a data access request for a target data entity.

11. A data access device, comprising:

the determining module is used for determining a rule set to be matched according to the target data entity and the target data circulation domain, wherein the rule set to be matched has a corresponding relation with the target data entity, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

the obtaining module is further configured to obtain a second request statement according to the first request statement and an operation rule included in a target rule if the first request statement meets a statement rule hit condition included in the target rule, where the target rule belongs to a rule to be matched included in the rule set to be matched;

a sending module, configured to send a second data access request to a storage service, so that the storage service executes the second request statement according to the second data access request, where the second data access request includes the second request statement.

12. A data access device, comprising:

the execution module is used for executing a second request statement according to the second data access request;

the sending module is used for sending the data execution result to a data access party;

13. A server, comprising: a memory, a transceiver, a processor, and a bus system;

wherein the memory is used for storing programs;

the processor is configured to execute a program in the memory, the processor is configured to perform the method of any one of claims 1 to 9 or the method of claim 10 according to instructions in the program code;

14. A data access system, characterized in that the data access system comprises a rule server and a storage server;

the rule server is used for determining a rule set to be matched according to the target data entity and the target data circulation domain, wherein the rule set to be matched has a corresponding relation with the target data entity, the rule set to be matched comprises at least one rule to be matched, and each rule to be matched comprises a statement rule hit condition and a corresponding relation between operation rules;

the rule server is configured to, if the first request statement satisfies a statement rule hit condition included in a target rule, obtain a second request statement according to the first request statement and an operation rule included in the target rule, where the target rule belongs to a rule to be matched included in the rule set to be matched;

the rule server is configured to send a second data access request to the storage server, where the second data access request includes the second request statement;

15. A computer-readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 9, or perform the method of claim 10.