CN118690068A - Database operation method and device - Google Patents

Abstract

The embodiment of the disclosure discloses a database operation method and a database operation device. One embodiment of the method comprises the following steps: in response to receiving the database operation request, determining metadata contained in the database operation request; searching entity objects corresponding to the metadata from a first built cache, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; and executing corresponding database operations according to the execution plan. This embodiment helps to avoid reliance on external services while ensuring data consistency.

Description

Database operation method and device

Technical Field

Embodiments of the present disclosure relate to the field of computer technology, and in particular, to a database operation method and apparatus.

Background

Currently, big data is gradually one of the infrastructures for production and development of various enterprises. For data services in big data based BI (Business Intelligence ) scenarios, there is often a need to face data processing at sea level, data source diversity, heterogeneous data mix queries, etc.

It is common today to rely directly on external micro-services for implementation, or to have a cache of corresponding metadata held by the data service itself. However, the external micro-service may cause performance bottleneck of the data service, and the cache is easy to have data inconsistency risk and lack of fast recovery capability when the data is changed.

Disclosure of Invention

The embodiment of the disclosure provides a database operation method and a database operation device.

In a first aspect, embodiments of the present disclosure provide a database operating method, the method comprising: in response to receiving the database operation request, determining metadata contained in the database operation request; searching entity objects corresponding to the metadata from a first built cache, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; and executing corresponding database operations according to the execution plan.

In a second aspect, embodiments of the present disclosure provide a database operating apparatus, the apparatus comprising: a determining unit configured to determine metadata included in the database operation request in response to receiving the database operation request; the searching unit is configured to search entity objects corresponding to the metadata from a first cache constructed in advance, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; and the execution unit is configured to execute corresponding database operations according to the execution plan.

In a third aspect, embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage means for storing one or more programs; the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method as described in any of the implementations of the first aspect.

In a fourth aspect, embodiments of the present disclosure provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method as described in any of the implementations of the first aspect.

According to the database operation method and device, the data structure of metadata flowing between systems is changed, so that metadata does not flow according to a single entity, but related entities are packaged into one entity object to flow, and therefore data consistency can be guaranteed. Meanwhile, the isomorphism construction and maintenance of the corresponding relation between the storage metadata and the entity object and the second-level cache of the corresponding relation between the entity object and the execution plan can avoid dependence on external services through local cache inquiry, and the external services are prevented from being called performance bottlenecks.

Drawings

Other features, objects and advantages of the present disclosure will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings:

FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present disclosure may be applied;

FIG. 2 is a flow chart of one embodiment of a database operating method according to the present disclosure;

FIG. 3a is a schematic diagram of data flow in a database operating method according to the present disclosure;

FIGS. 3b-3c are schematic diagrams of conventional data flow schemes;

FIG. 4 is a schematic diagram of initializing a first cache;

FIG. 5 is a schematic diagram of a data recovery operation;

FIG. 6 is a schematic diagram of an embodiment of a database operating apparatus according to the present disclosure;

Fig. 7 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.

Detailed Description

The present disclosure is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.

It should be noted that, in the technical scheme of the invention, the related aspects of data acquisition/collection, updating, analysis, use, transmission, storage and the like all conform to the regulations of related laws and regulations, are used for legal and reasonable purposes, are not shared, leaked or sold outside the legal use aspects and the like, and are subjected to supervision and management of the national supervision and management department. Necessary measures should be taken on the data to selectively prevent the use or access of the data to prevent illegal access to such data, ensure that personnel having access to the data comply with the regulations of relevant laws and regulations, and ensure data security. Furthermore, once such data is no longer needed, the risk should be minimized by limiting or even prohibiting the collection and/or deletion of data.

It should be noted that, without conflict, the embodiments of the present disclosure and features of the embodiments may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

FIG. 1 illustrates an exemplary architecture 100 to which embodiments of a database operating method or database operating apparatus of the present disclosure may be applied.

As shown in fig. 1, the system architecture 100 may include a data server 101, an external server 102, and a terminal device 103. The data service end 101, the external service end 102, and the terminal device 103 may be connected by various connection types such as a wired or wireless communication link or an optical fiber cable.

The data service end 101 can provide data supporting services for users, and is mainly used for storing, processing and analyzing data, etc., so as to meet various database operation requirements of the users. A metadata center may be abstracted in the data server 101 to implement functions such as cache construction, cache version management, and the like. The external server 102 may provide various metadata required for database operations to the data server 101.

Various client applications may be installed on the terminal device 103. Such as browser class applications, search class applications, database class applications, and the like. The terminal device 103 may be hardware or software. When the terminal device 103 is hardware, it may be a variety of electronic devices including, but not limited to, smartphones, tablet computers, electronic book readers, laptop and desktop computers, and the like. When the terminal device 103 is software, it can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., multiple software or software modules for providing distributed services) or as a single software or software module. The present invention is not particularly limited herein.

The data server 101 and the external server 102 may be hardware or software. When the data server 101 and the external server 102 are hardware, they may be implemented as a distributed server cluster formed by a plurality of servers, or may be implemented as a single server. When the data service terminal 101 and the external service terminal 102 are software, they may be implemented as a plurality of software or software modules (for example, a plurality of software or software modules for providing distributed services), or as a single software or software module. The present invention is not particularly limited herein.

It should be noted that, the database operation method provided in the embodiments of the present disclosure is generally executed by the data server 101, and accordingly, the database operation device is generally disposed in the data server 101.

It should be understood that the number of data servers, external servers and terminal devices in fig. 1 is merely illustrative. There may be any number of data servers, external servers, and terminal devices, as desired for implementation.

With continued reference to FIG. 2, a flow 200 of one embodiment of a database operating method according to the present disclosure is shown. The database operation method comprises the following steps:

step 201, in response to receiving the database operation request, determining metadata contained in the database operation request.

In this embodiment, the database operation request may be used to request that various database operations be performed on the database. Database operations include, but are not limited to, data reads, writes, updates, modifications, or deletions, and the like.

The metadata (Meta Data) is Data about Data, and is mainly used to describe various Data attribute information. For example, taking a BI scenario as an example, metadata in the scenario includes, but is not limited to, as index definition metadata, dimension definition metadata, and index implementation metadata.

Wherein, index definition metadata is generally used for describing Chinese and English names, calculating caliber and the like of indexes. For example, "a deal order amount" means "an order amount after having paid and having a specified type of amount removed".

Dimension definition metadata is typically used to describe the chinese-english name and dimension value information of a dimension. For example, the specific dimension value of "province" is "Hebei", not "Hebei province".

The index implementation metadata is generally used to represent specific information of the index execution layer. For example, the database table of which engine supports the query of the index, which is used as the decision basis of the data service dependence.

Specifically, the user can send a database operation request through the terminal equipment used by the user according to actual requirements. Upon receipt of the database operation request, metadata contained in the database operation request may be determined by various existing methods such as metadata analysis (e.g., index dependent parsing, etc.).

Step 202, searching entity objects corresponding to the metadata from a first cache constructed in advance.

In this embodiment, the entity object may be obtained by encapsulating the entity corresponding to the metadata, which has the dependency relationship. The entity to which the metadata corresponds may be regarded as a description of the metadata in a database, such as a table in a database. Data dependencies may exist between entities corresponding to different metadata, and the entities with the dependencies may be packaged into an entity object.

The first cache may be used to cache a correspondence between metadata and entity objects locally. Specifically, the corresponding relationship between the metadata and the entity object may be preset according to an actual service scenario or the like, and the first cache may be constructed in advance.

And 203, searching an execution plan corresponding to the entity object from a second buffer constructed in advance.

In this embodiment, the execution plan may be a specific execution manner and step of the database operation. The second cache may cache a correspondence between the physical object and the execution plan locally. Specifically, the corresponding relationship between the entity object and the execution plan may be preset according to an actual service scenario or the like, and the second cache may be constructed in advance.

Step 204, executing corresponding database operation according to the execution plan.

In this embodiment, after the execution plan is obtained, the database operation may be performed according to the steps indicated by the execution plan, so as to complete the response to the database operation request.

The method provided by the embodiment of the disclosure stores the metadata required by database operation in a local cache mode, so that performance bottleneck caused by dependence on external services can be avoided. Meanwhile, according to the correlation between metadata realization, related metadata entities are integrated into one entity object, and a secondary cache is built based on the entity object, so that the data consistency of database operation can be ensured.

In some optional implementations of this embodiment, corresponding updates are made to the first cache and the second cache in response to receiving a metadata change message for the database.

Wherein the metadata change message may indicate that a metadata change event exists. After receiving the metadata change message, the first cache and the second cache can be correspondingly updated to ensure that the latest metadata is cached.

Alternatively, the metadata change Message may be received through a Message Queue (MQ). At this time, messages can be saved and transmitted between different modules or systems (between the execution body and the external service as described above) through the message queue, which helps to promote high availability of the data service.

Optionally, in response to receiving the metadata change message of the database, pulling a new entity object of the database according to the metadata change message, and performing incremental update on the second cache with the new entity object, and in response to determining that the second cache update is complete, performing incremental update on the first cache.

Specifically, the metadata change message may indicate that changed metadata exists, so that an entity with changed metadata may be pulled from the external service depending on the metadata change message to correspond to the encapsulated entity object, that is, a new entity object, and then the second cache may be updated incrementally by using the obtained new entity object. After determining that the second cache has been updated, the first cache may be updated in corresponding increments according to the second cache.

Optionally, in response to determining that the second cache update is complete, pulling a new entity object of the database, and analyzing metadata corresponding to the new entity object, incrementally updating the first cache with metadata corresponding to the new entity object.

Specifically, after the second cache is updated, entity objects with changes may be pulled from the second cache, and metadata corresponding to the entity objects may be analyzed, so that corresponding incremental update is performed on the first cache by using the metadata obtained by the analysis.

Since the change of the cache is not immediately effective, there may be a data inconsistency risk if a data pull is performed while, for example, the second cache update is not complete. Therefore, after the second cache is updated, the first cache is updated again, so that data consistency is guaranteed.

Alternatively, the first cache and the second cache may also be updated in full amount at regular time.

Since incremental updates themselves present some risk of data inconsistency, etc., the full-scale updates combined with timing may exclude the potential risk of incremental updates.

In some optional implementations of this embodiment, version information of the second cache may be set, and the second cache and its corresponding version information may be persisted.

Wherein the version information may be used to record a second cache at a different point in time. The expression mode of the version information can be flexibly set. Meanwhile, the second cache and version information thereof can be stored in a lasting mode, so that when the problems of inconsistent data and the like occur, the data service can be quickly recovered by pulling the cache data of a specific version.

Optionally, in response to detecting the data failure, at least one of the following data recovery operations is performed: and restoring the specified metadata to the target version by using the storage snapshot of the second cache as a new second cache.

Among these, data failures may be various problems such as data inconsistency. The specified metadata may be determined according to an actual application scenario. The target version can be flexibly set according to actual requirements, for example, the target version can be the latest correct version.

The usability of the whole data service can be rapidly ensured by timely using the storage snapshot of the second cache or recovering the specific metadata to the correct version, and the stability of the data service is improved.

Optionally, a layer of metadata center (as shown in fig. 1) may be abstracted to implement the functions of storing the second cache, and the specific design may be flexibly designed according to the actual application requirement.

As shown in fig. 3a, a schematic diagram of data flow in the database operating method of the present disclosure is shown. The external service may provide various types of metadata such as index definitions and dimension definitions. The metadata center can hold the second cache for the data server to pull according to the requirement. When a metadata change occurs, the external service may inform the metadata center through the message queue to pull the new entity object to update the second cache. After the second cache update is completed, the metadata center may send a cache ready notification to the data server to cause the data server to pull and parse the metadata from the metadata center to update the first cache. Meanwhile, the data service end can change the routing logic of inquiring the metadata from relying on external services to relying on local caching.

As shown in fig. 3b-3c, which are schematic diagrams of conventional data flow schemes. As shown in fig. 3b, the routing logic of the data service is typically directly dependent on the external service. In this way, the availability of data services is relatively susceptible to a single external service when the metadata is too much dependent. For example, many external services are based on centralized storage such as databases, and thus it is difficult to re-enhance performance by optimization when the service size increases to a certain level. As another example, the number of instances deployed by a single external service is typically small, and resources such as processors, memory, and thread pools are relatively likely to be performance bottlenecks. As another example, the performance of the external service itself may be uneven and there is a risk of downtime.

As shown in fig. 3c, some data services themselves hold a cache of corresponding metadata. However, this way, passive caches are generally built according to the corresponding entities of metadata, and data consistency may not be guaranteed. Moreover, in case of failure, due to the lack of effective organization of the cache mode, it is difficult to quickly roll back to a certain correct version, i.e. the quick recovery capability is poor.

As can be seen by comparing fig. 3a-3c, the method provided by the foregoing embodiments of the present disclosure fundamentally changes the data structure of metadata stream, so as to solve the data consistency risk problem and the data service performance bottleneck problem existing in the prior art. Specifically, metadata is no longer in terms of a single entity flow, but rather related entities are packaged into one entity object to operate to ensure transaction consistency. In addition, by abstracting a layer of the buffer memory of the entity object held by the metadata center, when the metadata is changed, the data server can be timely informed to carry out local buffer memory update. Meanwhile, the metadata center can also maintain the version information of the entity object so as to quickly roll back to the correct version when the data fails and ensure the quick recovery capability of the data service. And obviously, the data service is not dependent on external services any more, but a local cache is built by pulling the entity object, so that the whole lateral expansion can be conveniently realized by expanding the instance.

With continued reference to FIG. 4, a schematic diagram of initializing a first cache is shown. As shown in fig. 4, after the database system is started, metadata types to be loaded, such as ID (identification) lists of metadata of all types, may be acquired first. Each metadata type may then be traversed in turn, for each type, all metadata IDs for that type may be obtained from the metadata center first, then split into pieces (e.g., paging, etc.) as needed, and then metadata details for each piece may be obtained from the metadata center. The metadata details may correspond to the execution plan described above. And then, constructing a second buffer memory of the entity object and the corresponding execution plan corresponding to all metadata of the type, and then constructing a first buffer memory of the entity object and the corresponding metadata of the type. After the initialization is completed, the local cache of the data service end takes effect to provide various data services.

In the process of acquiring the metadata ID, the metadata details and the like, a waiting or retry mechanism and the like can be adopted according to actual conditions so as to ensure the overall stability. In addition, when the metadata is changed, the metadata center can inform the data service end to update the local cache in a broadcasting mode and the like.

Referring now to FIG. 5, a schematic diagram of a data recovery operation is shown. As shown in fig. 5, the metadata center may pull the entity object of the metadata from the external service after receiving the metadata change message, and generate the version information of the second cache according to each update date. Meanwhile, backup and historical version persistence storage can be performed to record different version information and caches of different time nodes.

After the second cache is updated, the metadata center may send a cache ready notification to the data server, and after the data server receives the cache ready notification, the data server may pull the latest entity object and analyze the corresponding latest metadata to update the first cache.

When faults such as inconsistent data occur, if the metadata center has problems, the metadata center can be directly switched to a cache snapshot locally held by the data server. At this time, the data of the cache snapshot may have errors or be a version of the data in a longer time, but this way can quickly guarantee the availability of the whole data service.

If there is no problem in the metadata center, but there is a problem in a certain entity object, then the entity object specified can be selected to be updated individually to a certain correct version. If the metadata center has no problem and cannot determine which metadata has a problem or has a problem of large-scale inconsistency of metadata, the metadata at the designated time point can be pulled in batches to replace the local first cache.

Different data recovery operations can be adopted in different scenes, so that data recovery can be rapidly performed when data faults occur, and the stability of data service is ensured.

Taking query routing logic as an example, after receiving a database operation request, stages such as protocol conversion, index dependent parsing, table lookup, execution plan construction, SQL (structured query language) generation, and SQL execution are typically included. According to the method provided by the embodiment of the disclosure, through changing the circulation structure, the cache mode and the like of metadata, required metadata can be obtained in a local cache mode, dependence on external services is avoided, and therefore, when the scale of a user is increased, convenient lateral expansion can be realized through an expansion example, and performance bottleneck caused by dependence on the external services is avoided. Meanwhile, the data rapid recovery during data failure is ensured by means of the modes of storing the stable snapshot of the metadata local cache and the like and combining with the pulling of the historical version metadata and the like.

With further reference to fig. 6, as an implementation of the method shown in the foregoing figures, the present disclosure provides an embodiment of a database operating apparatus, which corresponds to the method embodiment shown in fig. 2, and which is particularly applicable to various electronic devices.

As shown in fig. 6, the database operating apparatus 600 provided in the present embodiment includes a determination unit 601, a search unit 602, and an execution unit 603. The determining unit 601 is configured to determine metadata included in the database operation request in response to receiving the database operation request; the searching unit 602 is configured to search for an entity object corresponding to metadata from a first buffer constructed in advance, where the first buffer is used to store a correspondence between metadata and the entity object, and the entity object is obtained based on encapsulation of an entity corresponding to metadata with a dependency relationship; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; the execution unit 603 is configured to perform corresponding database operations according to an execution plan.

In some optional implementations of this embodiment, the database operating apparatus 600 further includes: the updating unit (not shown in the figure) is configured to: responding to the received metadata change message of the database, pulling a new entity object of the database according to the metadata change message, and performing incremental update on the second cache by utilizing the new entity object; in response to determining that the second cache update is complete, the first cache is incrementally updated.

In some optional implementations of this embodiment, the database operating apparatus 600 further includes: the storage unit (not shown in the figure) is configured to: setting version information of the second cache; and persistence is carried out on the second cache and the version information.

In some optional implementations of this embodiment, the updating unit is further configured to: and carrying out full-quantity updating on the first cache and the second cache at fixed time.

In some optional implementations of this embodiment, the metadata change message is received via a message queue.

In some optional implementations of this embodiment, the updating unit is further configured to: and in response to determining that the second cache updating is completed, pulling a new entity object of the database, analyzing metadata corresponding to the new entity object, and performing incremental updating on the first cache by utilizing the metadata corresponding to the new entity object.

In some optional implementations of this embodiment, the database operating apparatus 600 further includes: the recovery unit (not shown in the figure) is configured to: in response to detecting the data failure, performing at least one of the following data recovery operations: using the stored snapshot of the second cache as a new second cache; the specified metadata is restored to the target version.

The device provided by the embodiment of the disclosure, in response to receiving the database operation request, determines metadata contained in the database operation request through the determining unit; the searching unit searches entity objects corresponding to the metadata from a first built cache, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; the execution unit executes the corresponding database operation according to the execution plan. By changing the data structure of the metadata flowing between the systems, the metadata is not circulated according to a single entity, but the related entity is packaged into an entity object for circulation, so that the data consistency can be ensured. Meanwhile, the isomorphism construction and maintenance of the corresponding relation between the storage metadata and the entity object and the second-level cache of the corresponding relation between the entity object and the execution plan can avoid dependence on external services through local cache inquiry, and the external services are prevented from being called performance bottlenecks.

Referring now to fig. 7, a schematic diagram of an electronic device (e.g., data server in fig. 1) 700 suitable for use in implementing embodiments of the present disclosure is shown. The electronic device shown in fig. 7 is only one example and should not impose any limitations on the functionality and scope of use of embodiments of the present disclosure.

As shown in fig. 7, the electronic device 700 may include a processing means (e.g., a central processor, a graphics processor, etc.) 701, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 702 or a program loaded from a storage means 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 are also stored. The processing device 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

In general, the following devices may be connected to the I/O interface 705: input devices 706 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 707 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 708 including, for example, magnetic tape, hard disk, etc.; and a communication device 709. The communication means 709 may allow the electronic device 700 to communicate wirelessly or by wire with other devices to exchange data. While fig. 7 shows an electronic device 700 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 7 may represent one device or a plurality of devices as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication device 709, or installed from storage 708, or installed from ROM 702. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 701.

It should be noted that, the computer readable medium according to the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In an embodiment of the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to receiving the database operation request, determining metadata contained in the database operation request; searching entity objects corresponding to the metadata from a first built cache, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation; searching an execution plan corresponding to the entity object from a second buffer constructed in advance, wherein the second buffer is used for storing the corresponding relation between the entity object and the execution plan; and executing corresponding database operations according to the execution plan.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes a determination unit, a lookup unit, and an execution unit. Wherein the names of the units do not constitute a limitation of the unit itself in some cases, for example, the determining unit may also be described as "in response to receiving a database operation request, determining the unit of metadata contained in the database operation request".

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.

Claims (10)

1. A database operating method, comprising:

In response to receiving a database operation request, determining metadata contained in the database operation request;

Searching entity objects corresponding to the metadata from a first built cache, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with the dependency relation;

searching an execution plan corresponding to the entity object from a second cache constructed in advance, wherein the second cache is used for storing the corresponding relation between the entity object and the execution plan;

And executing corresponding database operation according to the execution plan.

2. The method of claim 1, wherein the method further comprises:

Responding to the received metadata change message of the database, pulling a new entity object of the database according to the metadata change message, and performing incremental update on the second cache by utilizing the new entity object;

and in response to determining that the second cache update is complete, performing incremental update on the first cache.

3. The method of claim 2, wherein the method further comprises:

Setting version information of the second cache;

and persistence is carried out on the second cache and the version information.

4. The method of claim 2, wherein the method further comprises:

and carrying out full-quantity updating on the first cache and the second cache at fixed time.

5. The method of claim 2, wherein the metadata change message is received through a message queue.

6. The method of claim 2, wherein the incrementally updating the first cache in response to determining that the second cache update is complete comprises:

And in response to determining that the second cache updating is completed, pulling a new entity object of the database, analyzing metadata corresponding to the new entity object, and performing incremental updating on the first cache by utilizing the metadata corresponding to the new entity object.

7. A method according to claim 3, wherein the method further comprises:

In response to detecting the data failure, performing at least one of the following data recovery operations:

Using the stored snapshot of the second cache as a new second cache;

the specified metadata is restored to the target version.

8. A database operating apparatus, wherein the apparatus comprises:

a determining unit configured to determine metadata contained in a database operation request in response to receiving the database operation request;

The searching unit is configured to search entity objects corresponding to the metadata from a first cache constructed in advance, wherein the first cache is used for storing the corresponding relation between the metadata and the entity objects, and the entity objects are obtained based on entity encapsulation corresponding to the metadata with a dependency relation; searching an execution plan corresponding to the entity object from a second cache constructed in advance, wherein the second cache is used for storing the corresponding relation between the entity object and the execution plan;

And the execution unit is configured to execute corresponding database operations according to the execution plan.

9. An electronic device, comprising:

One or more processors;

A storage device having one or more programs stored thereon;

When executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-7.

10. A computer readable medium having stored thereon a computer program, wherein the program when executed by a processor implements the method of any of claims 1-7.