Method and apparatus for managing access request for database, device, and medium

Abstract

Provided are a method and apparatus for managing an access request for a database, a device, and a medium. The method comprises: determining a storage mode associated with a database, wherein the database is a non-structured query language database, and the storage mode specifies a constraint for at least one data object in the database; receiving an access request for accessing the database; in response to determining that the data object specified in the access request matches the storage mode, updating the access request on the basis of the constraint; and using the updated access request to access the database. By using some implementations of the present disclosure, before accessing a database, whether a data object to be processed satisfies a constraint of the database can be determined in advance. In response to determining that the data object does not satisfy the predetermined constraint, the access request can be converted in advance into an access request that satisfies the constraint. In this way, the efficiency of accessing the database can be improved.

Description

Methods, apparatus, devices, and media for managing database access requests. Technical Field

[0001] Exemplary implementations of this disclosure generally relate to database management, and more particularly to methods, apparatus, devices, and computer-readable storage media for managing access requests to a database. Background Technology

[0002] Various types of databases have been developed, and databases can store diverse data types. Different data types involve different security constraints. For example, some data can be stored directly in a database, while some data involving security needs to be preprocessed before storage to ensure data security requirements. Therefore, there is a desire to manage databases more conveniently and efficiently, especially to preprocess the data to be processed and transform it to meet predetermined constraints before storing it in the database. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for managing access requests to a database is provided. In this method, a storage schema associated with the database is determined, the database being an Unstructured Query Language database, and the storage schema specifies constraints for at least one data object in the database. An access request for accessing the database is received. In response to determining that the data object specified in the access request matches the storage schema, the access request is updated based on the constraints. The database is accessed using the updated access request.

[0004] In a second aspect of this disclosure, an apparatus for managing access requests to a database is provided. The apparatus includes: a determining module configured to determine a storage schema associated with the database, the database being an Unstructured Query Language database, and the storage schema specifying constraints for at least one data object in the database; a receiving module configured to receive an access request for accessing the database; an updating module configured to update the access request based on constraints in response to determining that a data object specified in the access request matches the storage schema; and an access module configured to access the database using the updated access request.

[0005] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to a first aspect of this disclosure when executed by the at least one processing unit.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method according to a first aspect of this disclosure.

[0007] In a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to a first aspect of this disclosure.

[0008] It should be understood that the content described in this content section is not intended to limit the key or essential features of the implementation of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] In the following detailed description, the above and other features, advantages, and aspects of the various implementations of this disclosure will become more apparent, taken in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0010] Figure 1 shows a block diagram of an application environment according to an exemplary implementation of the present disclosure;

[0011] Figure 2 shows a block diagram of database access requests according to some implementations of this disclosure;

[0012] Figure 3 shows a block diagram of an architecture for managing database access requests according to some implementations of this disclosure;

[0013] Figure 4 shows a block diagram of the deployment location of access management according to some implementations of this disclosure;

[0014] Figure 5 shows a block diagram of the structure of access management according to some implementations of this disclosure;

[0015] Figure 6 shows a block diagram of performing access management at a gateway device according to some implementations of this disclosure;

[0016] Figure 7 shows a flowchart of a method for managing database access requests according to some implementations of this disclosure;

[0017] Figure 8 shows a block diagram of an apparatus for managing database access requests according to some implementations of this disclosure; and

[0018] Figure 9 shows a block diagram of a device capable of implementing various implementations of the present disclosure. Detailed Implementation

[0019] Implementations of this disclosure will now be described in more detail with reference to the accompanying drawings. While some implementations of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the implementations set forth herein. Rather, these implementations are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and implementations of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] In the description of the implementation methods disclosed herein, the term "comprising" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one implementation" or "the implementation" should be understood as "at least one implementation". The term "some implementations" should be understood as "at least some implementations". Other explicit and implicit definitions may also be included below. As used herein, the term "model" can represent the relationships between various data. For example, the aforementioned relationships can be obtained based on various currently known and / or future-developed technical solutions.

[0021] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and user authorization should be obtained.

[0023] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0024] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, for example, via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose whether to "agree" or "disagree" to provide personal information to the electronic device.

[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0026] The term "in response to" as used herein refers to a state in which a corresponding event occurs or a condition is satisfied. It will be understood that the timing of subsequent actions performed in response to such event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be performed immediately upon the occurrence of the event or the fulfillment of the condition; while in others, they may be performed some time after the occurrence of the event or the fulfillment of the condition.

[0027] Example Environment

[0028] Different types of databases have been developed, capable of storing various data types, each with different security constraints. Figure 1 illustrates an application environment according to some implementations of this disclosure, showing a block diagram 100 of an application environment based on an exemplary implementation of this disclosure. As shown in Figure 1, two main types of databases exist: a Structured Query Language (SQL) database 110 and an Unstructured Query Language (NoSQL) database 120. For the SQL database 110, a schema needs to be predefined. A schema refers to the structure or framework of the database, defining how data is organized and stored. A schema typically includes definitions of database objects such as tables, fields, views, indexes, and stored procedures. For example, a schema might specify that the SQL database 110 includes data tables with multiple fields: user ID, email address, etc. When creating an SQL database, a schema needs to be predefined, and various database objects are created according to this schema to store data in the database.

[0029] For NoSQL databases 120, this type of database differs from traditional SQL databases. NoSQL databases are used to store large amounts of unstructured or semi-structured data and are typically horizontally scalable to support very large datasets. NoSQL databases offer various types, including key-value databases, document databases, column-family databases, and graph databases. As shown in Figure 1, NoSQL database 120 illustrates a key-value database, where "keys" store data keywords and "values" store the corresponding data content. Compared to SQL databases, before storing data in a NoSQL database, the specific content of the data to be stored is unknown, and it is impossible to verify whether the data to be stored meets constraints such as security.

[0030] For example, some data can be stored directly in a database; however, information involving data security needs to be preprocessed before storage to ensure data security requirements. Existing solutions typically verify whether the stored data meets constraints after storing it in the NoSQL database. When illegal data is found, a corresponding processing procedure is triggered, such as storing the processed data that meets the constraints in the database. This leads to significant delays in the database access process. Therefore, there is a desire for a more convenient and efficient way to manage the database, especially by preprocessing the data to be processed and converting it to meet predetermined constraints before storing it in the database.

[0031] Overview of Access Management

[0032] To at least partially address the shortcomings of the prior art, a method for managing database access requests is proposed according to an exemplary implementation of this disclosure. Referring to Figure 2, which describes an overview of an exemplary implementation of this disclosure, Figure 2 shows a block diagram 200 for managing database access requests according to some implementations of this disclosure. As shown in Figure 2, for a NoSQL database 120, a storage schema 230 associated with the database can be determined. Here, the storage schema can specify constraints 222 for at least one data object in the database. These constraints can involve various aspects; assuming the database is used to store user data, the constraints could specify: hiding sensitive user information (e.g., email address, phone number, etc.). For example, the constraints could specify: the length of the user ID does not exceed 10 characters, etc.

[0033] According to some implementations of this disclosure, storage schema 230 can be predefined, and its function can be similar to that of a schema in an SQL database. The difference is that the storage schema of a NoSQL database can be defined independently of the NoSQL database. For example, storage schema 230 can be defined based on various formats and stored in a location other than the NoSQL database. In the context of this disclosure, database developers can declare the storage schema in advance before the database goes live, thereby ensuring that a verification process is performed before write operations are performed on the NoSQL database. For ease of description, the specific process of this disclosure is described below using a key-value database as an example of a NoSQL database. Alternatively and / or additionally, the technical solutions of this disclosure can be implemented in various types of NoSQL databases, including but not limited to key-value databases, document databases, column-family databases, and graph databases.

[0034] Further, as shown in Figure 2, an access request 210 for accessing the database can be received, which may, for example, specify the storage of a data object in the database. It can be determined whether the data object specified in the access request 210 matches a storage schema. In response to determining that the data object specified in the access request matches a storage schema, the access request can be updated based on constraints. Furthermore, the updated access request 220 can be used to access the database.

[0035] Using some implementation methods disclosed herein, it is possible to pre-determine whether the data object to be processed conforms to the database constraints before accessing the database. In response to determining that the data object does not conform to the predetermined constraints, the access request can be converted into a constraint-compliant access request in advance. In this way, database access efficiency can be improved.

[0036] Detailed process of access management

[0037] Having described an overview of some implementations according to this disclosure, further details of accessing a NoSQL database are described below with reference to Figure 3. Figure 3 shows a block diagram 300 of an architecture for managing database access requests according to some implementations of this disclosure. As shown in Figure 3, in the control plane 310, an access request 312 may be received, and it may be determined whether the data object specified in the access request 312 matches storage mode 230. In response to determining that the data object matches storage mode 230, an access management process may be performed in the data plane 320.

[0038] According to some implementations of this disclosure, there are two access management modes. For example, in mode 1, process 330 can be executed in container 322 (e.g., at the client device used to access the database), thereby performing access management 334. Specifically, access management 334 can be used to handle logic 332 for accessing the database.

[0039] According to some implementations of this disclosure, a database access tool can be used to implement a method for managing database access requests at the client device used to access the database. In this case, accessing the database using an updated access request includes sending an updated access request to the database gateway device to access the database. Further encapsulation can be provided on top of existing NoSQL database management software development kits (SDKs), and the proposed execution mode verification access management logic can be integrated into the SDK.

[0040] In subsequent development, developers can use the encapsulated SDK to perform data writes. Specifically, if the schema verification process fails, the access request can be updated, the write operation can be directly blocked, and alert information can be provided, etc. In this way, a control mechanism can be added to the client to ensure that users can perform schema verification in advance. At this time, in access management 334, the database access logic implemented using the encapsulated SDK will be automatically parsed, and then the schema verification process will be executed. At this time, the original access request will be updated, and the updated access request will be written to proxy 350, which will then use the updated access request to write data to NoSQL database 120.

[0041] It should be understood that Mode 1 requires developers to use a packaged SDK for programming, which may affect the code. Alternatively and / or additionally, a non-intrusive code solution is proposed. According to some implementations of this disclosure, methods for managing database access requests can be implemented at the gateway device used to access the database. As shown in Figure 3, in Mode 2, access management 344 can be performed in the database proxy device 340.

[0042] For example, service 342 can be started to implement access management 244. Specifically, the Foreign Function Interface (FFI) allows the database agent to call functions in one programming environment from another. As another example, Web Assembly (WAsm) allows Web Assembly code to run on the server or at the agent. Access management processes can be performed based on WAsm. In this way, the access management functionality implemented by this encapsulated code can be integrated into the gateway's agent using the plugin capabilities provided by the database service gateway. In this case, developers only need to ensure that all write storage traffic passes through the gateway's agent, thus avoiding the additional cost of modifying the code.

[0043] According to some implementations of this disclosure, storage schemas can be defined using various formats. For example, the JavaScript Object Notation (JSON) format can be used to define storage schemas. Table 1 shows examples of storage schemas, for instance.

[0044] Table 1 Examples of storage modes

[0045] As shown in Table 1, Storage Schema 1 illustrates the constraints on a data object written to a key-value database, which includes the fields "id" and "email". The "id" field can be represented using an integer (int), labeled "User ID" and described as "xxxx". The "email" field can be represented using a string (string), labeled "Email" and described as "yyyy". Storage Schema 2 can include more information, such as specifying a maximum length of 50 for the "email" field, etc. Storage Schema 3 illustrates further constraints on the storage format for the "email" field. Specifically, "format": encrypted by func1 can indicate that the email address is stored in encrypted form, and the encryption function is func1. Alternatively and / or additionally, it can be specified that the email address is stored using features (e.g., embedding), and the encoder used to generate the features can be specified, etc.

[0046] It should be understood that Table 1 only shows examples of storage schemas. Alternatively and / or additionally, storage schemas can be defined in other formats (e.g., XML, text, and / or tables). Alternatively and / or additionally, storage schemas can include more, fewer, or different fields; for example, the field "telephone" can be further defined, etc.

[0047] According to some implementations of this disclosure, access requests can be updated based on constraints. Specifically, a process associated with the constraint can be determined, and the data object in the access request can be updated based on the process. In the context of this disclosure, access requests can be represented in various formats, and Table 2 shows examples of access requests. It should be understood that other formats can be used to represent access requests.

[0048] Table 2 Examples of Access Requests

[0049] As shown in Access Request 1 in Table 2, "op" indicates performing a "set" operation on the database (i.e., writing data to the database), "key" indicates the key is "foo," and "val" indicates that the data object being written includes the fields "id" and "email." At this point, each access request can be validated based on the constraints in Table 1 above, and the access requests can be updated as needed. In response to determining that the access request will write an email address to the database, the constraints associated with the "email" field can be determined. When validating Access Request 1 using storage schema 1 or 2 in Table 1, it can be determined that Access Request 1 meets the constraints and does not require updating. When validating Access Request 1 using storage schema 3, it can be determined that the email address in Access Request 1 is in plaintext and does not meet the constraints. In response to the received access request that will write an email address to the database, the email address can be converted to ciphertext format using the encryption function func1; that is, the data object in the access request can be updated using the ciphertext address. For example, the email address xx@xxx.com can be converted to ciphertext format to update the access request.

[0050] By utilizing some implementation methods disclosed herein, before writing data objects to the database, it can be determined in advance whether the data to be written meets predetermined constraints, thereby converting data objects that do not meet the constraints to those that do. In this way, illegal data that violates constraints can be avoided from being written to the NoSQL database, thus ensuring the legality and security of data in the NoSQL database.

[0051] According to some implementations of this disclosure, constraints include sub-constraints for data items in a data object. Updating the data object in the access request based on the processing procedure includes: extracting the original data item corresponding to the sub-constraint from the data object; performing a preprocessing procedure on the original data item to obtain the destination data item, the preprocessing procedure corresponding to the sub-constraint; and replacing the original data item in the access request with the destination data item. Using some implementations of this disclosure, the original data items corresponding to each sub-constraint can be determined in a more granular manner, thereby performing the update operation.

[0052] When validating access request 2 using storage schema 2, for the sub-constraint regarding email address length, the corresponding raw data item "xx@xx...xxx.com" can be extracted. In response to determining that the email address length is greater than 50 characters, the address can be truncated. Alternatively and / or additionally, an alert message can be provided, or the access request can be blocked, etc. As another example, when validating access request 3 using storage schema 2, it can be determined that the data object to be written includes three fields: "id", "email", and "phone", and does not match the two fields "id" and "email" defined in storage schema 2. In this case, the "phone" field can be removed, an alert message can be provided, or the access request can be blocked, etc.

[0053] Based on some implementations of this disclosure, processing strategies for handling access requests can be further provided. These processing strategies may include, for example: 1) directly updating the access request; 2) updating the access request and sending an alarm message; 3) sending only an alarm message; 4) sending alarm messages in batches (e.g., sending an alarm message when the quantity reaches 10 or other values), and so on. In this way, access requests can be processed in a more granular and controllable manner.

[0054] Figure 4 shows a block diagram 400 illustrating the deployment location of access management according to some implementations of this disclosure. According to some implementations of this disclosure, the process described above can be executed in different ways. For example, in Mode 1, access management 440 can be executed by calling the functionality encapsulated in SDK 420 to update access requests. In this case, access management 440 can be implemented at the client device that calls the database access logic to access the database. In this way, developers only need to call the SDK that encapsulates the access management functionality to pre-validate whether the data conforms to predetermined constraints before writing data to the NoSQL database. Since the access management functionality is encapsulated within the SDK, developers do not need to concern themselves with the specific implementation details, but only need to use the SDK to rewrite the relevant code. Alternatively and / or additionally, in Mode 2, access management 440' can be executed at the gateway device 430 to update access requests. In this case, developers do not need to rewrite the code, but the gateway device 430 can automatically perform the verification process, thereby reducing interference with the development process.

[0055] According to some implementations of this disclosure, during the process of updating an access request, a loader at the gateway device can be initialized based on the storage mode and the processing strategy for handling the access request; and in response to determining that the data object specified in the access request matches the storage mode, the loader updates the access request according to the processing strategy. See Figure 5 for further details on performing access management at the gateway device, which shows a block diagram 500 of the structure of access management according to some implementations of this disclosure. As shown in Figure 5, access management 344 can be triggered based on a request hook 530. Specifically, the request hook 530 can intercept requests from the caller 510. In the request hook 530, a filter 532 can be used to filter the request, and further, a parser 534 can be used to determine the data object specified in the request, and then determine whether the data object matches the required storage mode.

[0056] For example, during initialization, loader 540 can be used to preload the required data. According to some implementations of this disclosure, initializing the loader may include: writing the storage schema associated with the database to the loader's schema cache; and writing the processing policy for handling access requests to the loader's policy cache. According to some implementations of this disclosure, access management loader 542 can be used to perform the process described above, which may include a schema cache for maintaining the storage schema and a policy cache for maintaining the processing policy. The corresponding data can be written to the two caches in advance, thereby enabling access management 344 at the gateway device to be ready in advance to improve the efficiency of handling user requests. Alternatively and / or additionally, loader 540 may also include a loader 544 for providing other authentication functions.

[0057] After initialization, loader 540 compares the data object in the request with the loaded storage mode and processes the request according to the loaded processing strategy. Then, request hook 530 sends the updated request to NoSQL database proxy 512, and response hook 550 receives the response from proxy 512 and forwards it to caller 510. In this way, access management can be performed directly at the gateway device without requiring developers to modify the code.

[0058] According to some implementations of this disclosure, the database storage schema may be updated during database operation. In this case, in response to determining that the storage schema has been updated, the updated storage schema can be written to the schema cache of the loader. Alternatively and / or additionally, in response to determining that the processing policy has been updated, the updated processing policy can be written to the policy cache of the loader. For example, the above update process can be performed by the access management loader 542, thereby allowing the underlying data (e.g., storage schema and / or processing policy) upon which access management depends to be updated in real time, so that access requests are validated according to the latest underlying data.

[0059] According to some implementations of this disclosure, the database may include multiple storage patterns. In this case, during the process of writing a storage pattern to the pattern cache, the storage pattern can be determined from multiple storage patterns based on initialization attributes associated with the database. Here, the initialization attributes can specify one or more storage patterns associated with the verification process, and the storage pattern to be written to the cache can be determined according to these initialization attributes. In this way, only the required storage patterns are written to the cache, thereby reducing the resource overhead of the gateway device.

[0060] See Figure 6 for further details on access management, which illustrates a block diagram 600 of access management performed at a gateway device according to some implementations of this disclosure. As shown in Figure 6, the loader 540 can provide an initialization process 640 and an execution process 630. During initialization, the synchronizer 642 can interact with external sources to write one or more storage patterns that will be used as the basis for authentication to the pattern cache 644 and to write the corresponding processing policies to the policy cache 646. Alternatively and / or additionally, the initial attribute 650 can be represented, for example, in format 614, specifying the storage pattern to be written to the cache by “APP1.XXX”. In this case, the storage pattern can be represented, for example, in format 612.

[0061] In execution process 630, as shown in box 634, the loader can determine whether access request 620 matches a storage schema in schema cache 644. In response to determining a match, a validation process can be performed at box 636, that is, validating whether the data object specified in access request 620 conforms to the constraints in the storage schema. If the constraints are found to be met, the access request is directly dispatched at box 638. If the constraints are found to be unmet, the access request can be updated first, and then an updated access request can be dispatched to provide command 622 to the database broker.

[0062] According to some implementations of this disclosure, the access request may or may not involve a storage schema that needs to be verified. According to some implementations of this disclosure, in response to determining that a data object does not match a storage schema, the database can be accessed based on the access request. Specifically, assuming the storage schema to be verified is storage schema 1 (i.e., a data object that needs verification including the fields "id" and "email"), and the access request does not involve these fields, the access request can be executed directly. In this way, only access requests involving a specified storage schema (e.g., those involving data security factors) can be verified, without interfering with other access requests that do not involve data security factors.

[0063] It should be understood that although the above description of database access processes uses key-value databases as an example of NoSQL databases, alternatively and / or additionally, databases include at least one of the following types: key-value databases, document databases, column-family databases, and graph databases. Specifically, key-value databases store data in key-value pairs and are suitable for applications requiring fast lookups, such as caching and session management. Document databases store documents in a JSON-like format, and each document can have a different structure. Document databases are suitable for building content management systems, user management systems, etc. Column-family databases store data by columns rather than rows and support highly efficient querying of a small number of rows from a large number of columns, making them suitable for write-intensive applications such as log aggregation and counters. Graph databases store entities and their relationships in a graph format, making them ideal for complex network structures, such as social networks, recommendation systems, and knowledge graphs.

[0064] According to some implementations of this disclosure, data objects can be extracted from access requests in a manner similar to extracting data objects to be stored in a key-value database as described above. Furthermore, it can be determined whether the data object to be stored includes data requiring special processing, and then the data object to be stored can be converted into a format conforming to predetermined constraints before writing data to the database. Using some implementations of this disclosure, inspection and processing tasks can be performed in advance in various types of NoSQL databases, thereby reducing database access latency and improving access efficiency.

[0065] Using some implementation methods disclosed herein, it is possible to pre-determine whether the data object to be processed conforms to the database constraints before accessing the database. In response to determining that the data object does not conform to the predetermined constraints, the access request can be converted into a constraint-compliant access request in advance. In this way, database access efficiency can be improved.

[0066] Example process

[0067] Figure 7 illustrates a flowchart of a method 700 for managing database access requests according to some implementations of this disclosure. At block 710, a storage schema associated with the database is determined, the database being an Unstructured Query Language database, and the storage schema specifies constraints for at least one data object in the database. At block 720, an access request for accessing the database is received. At block 730, in response to determining that the data object specified in the access request matches the storage schema, the access request is updated based on the constraints. At block 740, the database is accessed using the updated access request.

[0068] According to some implementations of this disclosure, updating an access request based on constraints includes: determining a process associated with the constraint; and updating the data object in the access request based on the process.

[0069] According to some implementations of this disclosure, the constraints include sub-constraints for data items in a data object, and updating the data object in the access request based on the processing procedure includes: extracting the original data item corresponding to the sub-constraint from the data object; performing a preprocessing procedure on the original data item to obtain the destination data item, the preprocessing procedure corresponding to the sub-constraint; and replacing the original data item in the access request with the destination data item.

[0070] According to some implementations of this disclosure, the method is implemented at a gateway device for accessing the database, and updating the access request based on constraints includes: initializing a loader at the gateway device based on the storage mode and a processing strategy for handling the access request; and updating the access request by the loader according to the processing strategy in response to determining that the data object specified in the access request matches the storage mode.

[0071] According to some implementations of this disclosure, initializing the loader includes: writing the storage schema associated with the database into the loader's schema cache; and writing the processing strategy for handling access requests into the loader's policy cache.

[0072] According to some implementations of this disclosure, the method further includes at least one of the following: in response to determining that the storage mode has been updated, writing the updated storage mode to the mode cache of the loader; or in response to determining that the processing policy has been updated, writing the updated processing policy to the policy cache of the loader.

[0073] According to some implementations of this disclosure, the database includes multiple storage schemas, and writing a storage schema into a schema cache includes: determining a storage schema from multiple storage schemas based on initialization attributes associated with the database.

[0074] According to some implementations of this disclosure, the method is implemented at a client device for accessing the database using a database access tool, wherein accessing the database using an updated access request includes: sending an updated access request to the database gateway device in order to access the database.

[0075] According to some implementations of this disclosure, the method further includes: in response to determining that a data object does not match a storage schema, accessing the database based on an access request.

[0076] According to some implementations of this disclosure, the database includes at least one of the following types: key-value database, document database, column-family database, and graph database.

[0077] Example devices and equipment

[0078] Figure 8 shows a block diagram of an apparatus 800 for managing database access requests according to some implementations of the present disclosure. The apparatus 800 includes: a determining module 810 configured to determine a storage schema associated with a database, the database being an unstructured query language database, and the storage schema specifying constraints for at least one data object in the database; a receiving module 820 configured to receive an access request for accessing the database; an updating module 830 configured to update the access request based on constraints in response to determining that a data object specified in the access request matches the storage schema; and an access module 840 configured to access the database using the updated access request.

[0079] According to some implementations of this disclosure, the update module 830 is further configured to: determine the processing procedure associated with the constraint; and update the data object in the access request based on the processing procedure.

[0080] According to some implementations of this disclosure, the constraints include sub-constraints for data items in a data object, and the update module 830 is further configured to: extract the original data item corresponding to the sub-constraint from the data object; perform a preprocessing procedure on the original data item to obtain a destination data item, the preprocessing procedure corresponding to the sub-constraint; and replace the original data item in the access request with the destination data item.

[0081] According to some implementations of this disclosure, the apparatus 800 is implemented at a gateway device for accessing a database, and the update module 830 is further configured to: initialize a loader at the gateway device based on a storage mode and a processing strategy for handling access requests; and update the access request by the loader according to the processing strategy in response to determining that the data object specified in the access request matches the storage mode.

[0082] According to some implementations of this disclosure, the update module 830 is further configured to: write the storage pattern associated with the database to the loader's pattern cache; and write the processing strategy for handling access requests to the loader's policy cache.

[0083] According to some implementations of this disclosure, the device 800 further includes a management module configured to: write an updated storage mode to the loader's mode cache in response to determining that the storage mode has been updated; or write an updated processing policy to the loader's policy cache in response to determining that the processing policy has been updated.

[0084] According to some implementations of this disclosure, the database includes multiple storage modes, and the management module is further configured to: determine a storage mode from the multiple storage modes based on initialization attributes associated with the database.

[0085] According to some implementations of this disclosure, the device 800 is implemented at a client device for accessing a database using a database access tool, and the access module is further configured to: send an updated access request to the database gateway device in order to access the database.

[0086] According to some implementations of this disclosure, the management module is further configured to: access the database based on an access request in response to determining that a data object does not match the storage schema.

[0087] According to some implementations of this disclosure, the database includes at least one of the following types: key-value database, document database, column-family database, and graph database.

[0088] Figure 9 shows a block diagram of a device 900 capable of implementing various implementations of the present disclosure. It should be understood that the computing device 900 shown in Figure 9 is merely exemplary and should not constitute any limitation on the functionality and scope of the implementations described herein. The computing device 900 shown in Figure 9 can be used to implement the methods described above.

[0089] As shown in Figure 9, the computing device 900 is in the form of a general-purpose computing device. Components of the computing device 900 may include, but are not limited to, one or more processors or processing units 910, memory 920, storage devices 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. The processing unit 910 may be a physical or virtual processor and is capable of performing various processes according to programs stored in the memory 920. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of the computing device 900.

[0090] Computing device 900 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 900, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 920 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 930 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media capable of storing information and / or data (e.g., training data for training) and accessible within computing device 900.

[0091] The computing device 900 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 9, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. The memory 920 may include a computer program product 925 having one or more program modules configured to perform various methods or actions of various implementations of the present disclosure.

[0092] The communication unit 940 enables communication with other computing devices via a communication medium. Additionally, the components of the computing device 900 can function as a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the computing device 900 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0093] Input device 950 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 960 can be one or more output devices, such as a monitor, speaker, printer, etc. Computing device 900 can also communicate as needed with one or more external devices (not shown) via communication unit 940. These external devices, such as storage devices, display devices, etc., can communicate with one or more devices that enable user interaction with computing device 900, or with any device (e.g., network card, modem, etc.) that enables computing device 900 to communicate with one or more other computing devices. Such communication can be performed via input / output (I / O) interfaces (not shown).

[0094] According to exemplary implementations of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to exemplary implementations of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above. According to exemplary implementations of this disclosure, a computer program product is provided that stores a computer program thereon, which, when executed by a processor, implements the methods described above.

[0095] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0096] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0097] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0099] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for managing database access requests, comprising: Determine a storage schema associated with the database, which is an unstructured query language database, and specify constraints for at least one data object in the database; Receive an access request for accessing the database; In response to determining that the data object specified in the access request matches the storage pattern, the access request is updated based on the constraints; as well as Access the database using the updated access request.

2. The method of claim 1, wherein updating the access request based on the constraint comprises: Determine the processing procedures associated with the constraints; as well as The data object in the access request is updated based on the processing procedure.

3. The method of claim 2, wherein the constraint includes sub-constraints for data items in the data object, and updating the data object in the access request based on the processing procedure includes: Extract the original data items corresponding to the sub-constraints from the data object; A preprocessing procedure is performed on the original data item to obtain the target data item, the preprocessing procedure corresponding to the sub-constraint; as well as Replace the original data item in the access request with the destination data item.

4. The method of claim 1, wherein the method is implemented at a gateway device for accessing the database, and updating the access request based on the constraints comprises: Based on the storage mode and the processing strategy for handling the access request, initialize the loader at the gateway device; as well as In response to determining that the data object specified in the access request matches the storage pattern, the loader updates the access request according to the processing strategy.

5. The method of claim 4, wherein initializing the loader comprises: Write the storage pattern associated with the database into the pattern cache of the loader; as well as Write the processing strategy for handling the access request into the policy cache of the loader.

6. The method of claim 5, further comprising at least one of the following: In response to determining that the storage mode has been updated, the updated storage mode is written to the mode cache of the loader; or In response to determining that the processing policy has been updated, the updated processing policy is written to the policy cache of the loader.

7. The method of claim 5, wherein the database comprises a plurality of storage modes, and writing the storage mode to the mode cache comprises: The storage mode is determined from the plurality of storage modes based on the initialization attributes associated with the database.

8. The method of claim 1, wherein the method is implemented at a client device for accessing the database with a database access tool, wherein accessing the database with the updated access request comprises: The gateway device of the database sends an updated access request to access the database.

9. The method of claim 1, further comprising: In response to determining that the data object does not match the storage mode, the database is accessed based on the access request.

10. The method of claim 1, wherein the database comprises at least any of the following types: key-value database, document database, column family database, and graph database.

11. An apparatus for managing database access requests, comprising: A determination module is configured to determine a storage mode associated with the database, which is an unstructured query language database, and the storage mode specifies constraints for at least one data object in the database. A receiving module is configured to receive access requests for accessing the database; An update module is configured to update the access request based on the constraints in response to determining that the data object specified in the access request matches the storage mode; as well as The access module is configured to access the database using the updated access request.

12. An electronic device, comprising: At least one processing unit; as well as At least one memory, coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 10 when executed by the at least one processing unit.

13. A computer-readable storage medium having a computer program stored thereon, the computer program causing the processor to implement the method according to any one of claims 1 to 10 when executed by a processor.

14. A computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1 to 10.

Images