CN113377402A - Multi-version concurrent storage method and device - Google Patents

Multi-version concurrent storage method and device Download PDF

Info

Publication number
CN113377402A
CN113377402A CN202110701214.1A CN202110701214A CN113377402A CN 113377402 A CN113377402 A CN 113377402A CN 202110701214 A CN202110701214 A CN 202110701214A CN 113377402 A CN113377402 A CN 113377402A
Authority
CN
China
Prior art keywords
request
target object
query
version
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110701214.1A
Other languages
Chinese (zh)
Inventor
覃鹏翔
高源�
曹璨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN202110701214.1A priority Critical patent/CN113377402A/en
Publication of CN113377402A publication Critical patent/CN113377402A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The disclosure discloses a multi-version concurrent storage method and device, relates to the field of artificial intelligence, in particular to computer vision and deep learning technology, and can be used in an infrastructure scene. The specific implementation scheme is as follows: the method comprises the steps of firstly responding to a received updating request of a user, obtaining a target object corresponding to the updating request, then determining a request identifier corresponding to the updating request, finally determining an updating version corresponding to the target object based on metadata and the request identifier of the target object, and updating a storage version of the target object.

Description

Multi-version concurrent storage method and device
Technical Field
The present disclosure relates to the field of artificial intelligence, and in particular to computer vision and deep learning techniques, which can be used in infrastructure scenarios.
Background
When the internet is developed at a high speed, the storage system as the lowest support system is very important in the status of the whole industry,
especially at the moment of the rapid development of artificial intelligence and industrial Internet. With the discovery of the industry, the functions required to be supported by businesses on a storage system are more and more, a typical simple storage system can only meet the access of a single key-value pair, but in some complex scenes, such as an object-based related scene, and a scene of multiple concurrent data, the simple key-value pair system cannot meet the requirement. Therefore, mvcc (Multi-Version concurrent Control), i.e., related technologies such as Multi-Version concurrent Control technology and flashback, has become a research hotspot in these years.
Disclosure of Invention
The disclosure provides a multi-version concurrent storage method and device, electronic equipment and a storage medium.
According to an aspect of the present disclosure, there is provided a multi-version concurrent storage method, including: responding to an update request received from a user, and acquiring a target object corresponding to the update request; determining a request identifier corresponding to the updating request; and determining an updating version corresponding to the target object and updating the storage version of the target object based on the metadata of the target object and the request identification.
According to another aspect of the present disclosure, there is provided a multi-version concurrent storage apparatus, the apparatus including: the acquisition module is configured to respond to the received update request of the user and acquire a target object corresponding to the update request; a determining module configured to determine a request identifier corresponding to the update request; and the updating module is configured to determine an updated version corresponding to the target object and update the stored version of the target object based on the metadata of the target object and the request identification.
According to another aspect of the present disclosure, there is provided an electronic device comprising at least one processor; and a memory communicatively coupled to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the multi-version concurrent storage method.
According to another aspect of the present disclosure, a computer-readable medium is provided, on which computer instructions are stored, the computer instructions being configured to enable a computer to execute the above-mentioned multi-version concurrent storage method.
According to another aspect of the present disclosure, an embodiment of the present application provides a computer program product, which includes a computer program, and the computer program, when executed by a processor, implements the multi-version concurrent storage method described above.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:
FIG. 1 is a flow diagram of one embodiment of a multi-version concurrent storage method according to the present disclosure;
FIG. 2 is a schematic diagram of one application scenario of a multi-version concurrent storage method according to the present disclosure;
FIG. 3 is a flow diagram for one embodiment of determining a request identification corresponding to an update request, according to the present disclosure;
FIG. 4 is a flow diagram for one embodiment of determining an updated version corresponding to a target object, according to the present disclosure;
FIG. 5 is a flow diagram of another embodiment of a multi-version concurrent storage method according to the present disclosure;
FIG. 6 is a schematic block diagram of one embodiment of a multi-version concurrent storage apparatus according to the present disclosure;
fig. 7 is a block diagram of an electronic device for implementing a multi-version concurrent storage method of an embodiment of the present disclosure.
Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Referring to fig. 1, fig. 1 shows a flow diagram 100 of an embodiment of a multi-version concurrent storage method that may be applied to the present disclosure. The multi-version concurrent storage method comprises the following steps:
step 110, responding to the received update request of the user, and acquiring a target object corresponding to the update request.
In this embodiment, the terminal may be a device having a display device, the terminal may display an interface for updating a certain object to a user through the display device, the user performs an update operation on a target object in the display interface of the terminal, the terminal generates an update request corresponding to the target object according to the update operation, and sends the update request to an execution main body of the multi-version concurrent storage method. An executing agent (for example, a server) of the multi-version concurrent storage method receives an update request sent by a terminal, and can determine a target object corresponding to the update request according to the update request.
The execution main body may parse the received update request, obtain identification information of the target object included in the update request, and determine, in the local storage, the target object corresponding to the identification information.
Or, when the terminal sends the update request, the terminal may also send the identification information of the target object corresponding to the update request to the execution main body, and after receiving the update request and the identification information, the execution main body determines the target object corresponding to the identification information in the local storage according to the identification information.
Step 120, determining a request identifier corresponding to the update request.
In this embodiment, after receiving the update request, the execution main body may perform a preset operation according to the update request to determine the corresponding request identifier, where the preset operation may be an operation of determining the request identifier based on the update request.
The execution body may preset a sequence number group, one update request may correspond to one sequence number, and the sequence number group may include at least one ordered sequence number. When receiving an update request, the execution main body may determine a sequence number in the sequence number group according to the sequence, use the sequence number as a request identifier of the update request, and delete the sequence number in the sequence number group. As an example, after receiving the first update request, the execution main body determines that the sequence number corresponding to the first update request is one in the sequence number group, uses the sequence number one as the request identifier of the first update request, and deletes the sequence number one in the sequence number group, then receives the second update request, determines that the sequence number corresponding to the second update request is two in the sequence number group, uses the sequence number two as the request identifier of the second update request, and deletes the sequence number two in the sequence number group, and so on, determines a sequence number in the sequence number group and deletes the corresponding sequence number each time an update request is received.
Or, the execution main body may perform an encoding operation on the received update request to obtain an encoding result corresponding to the update request, and determine the encoding result as a request identifier corresponding to the update request.
Step 130, determining an updated version corresponding to the target object based on the metadata of the target object and the request identifier, and updating the stored version of the target object.
In this embodiment, after the execution subject determines the target object, the execution subject acquires the target object and determines metadata corresponding to the target object, where the metadata may be a basic value of the target object. After the execution main body determines the metadata of the target object and the request identifier corresponding to the update request, the execution main body may determine the update data of the target object for the update request according to the metadata of the target object and the request identifier, construct a finite state machine corresponding to the target object from the metadata and the request identifier, and form an update version of the target object for the update request from the metadata of the target object and the request identifier, where the update data is data of the target object for the update version.
The execution subject may add the updated version to the stored version of the target object to update the stored version of the target object, where the stored version may include the updated version and other versions before the updated version, and the other versions correspond to different operation requests of the target object.
With continued reference to fig. 2, fig. 2 is a schematic diagram of an application scenario of the multi-version concurrent storage method according to the present embodiment. In the application scenario of fig. 2, the terminal 201 receives an update operation of a user on a target object, generates an update request corresponding to the target object according to the update operation, and sends the update request to the server 202. The server 202 receives an update request from a user, and obtains a target object corresponding to the update request according to the update request. Then, the server 202 determines a request identifier corresponding to the update request according to the update request, determines an update version corresponding to the target object according to the metadata of the target object and the request identifier, and updates the storage version of the target object.
According to the multi-version concurrent storage method provided by the embodiment of the disclosure, a target object corresponding to an update request is obtained by responding to the received update request of a user, then a request identifier corresponding to the update request is determined, finally, an update version corresponding to the target object is determined based on metadata and the request identifier of the target object, and the storage version of the target object is updated, so that a brand-new multi-version concurrent control storage method is realized, different versions can be stored based on the update request of the user, different versions corresponding to different request identifiers are realized, other systems do not need to be maintained independently, the realization mode is simple, and the efficiency and the simplicity of multi-version concurrent control storage are improved.
Referring to fig. 3, fig. 3 shows a flowchart 300 of an embodiment of determining a request identifier corresponding to an update request, that is, the step 120 described above, which may include the following steps:
step 310, a request identification sequence corresponding to the target object is obtained.
In this step, after receiving the update request, the execution main body determines a target object corresponding to the update request. The execution main body may obtain the request identifier sequence corresponding to the target object according to a correspondence between the target object and the request identifier sequence, where the request identifier sequence may include request identifiers of all operation requests corresponding to the target object, each request identifier corresponds to a different operation request, and each request identifier is stored in sequence, may be stored in the sequence of the received operation requests, and may also be stored in the time sequence of the operation requests, which is not specifically limited by the present disclosure.
For example, the execution body receives the first update request, determines that the request identifier of the first update request is T0, and may store T0 in the request identifier sequence corresponding to the target object. Then, the executing entity receives the second update request, determines that the request identifier of the second update request is T1, and may store T1 behind T0, at this time, the request identifier sequence corresponding to the target object includes two request identifiers sequentially stored in T0 and T1.
Step 320, determining a request identifier corresponding to the update request based on the last request identifier in the request identifier sequence.
In this step, the execution subject obtains a request identifier sequence corresponding to the target object, where the request identifier sequence stores request identifiers that have been determined according to the sequence. And the execution main body determines the last request identifier from the request identifier sequence, wherein the last request identifier is a request identifier corresponding to the last operation request of the received update request.
After the execution main body determines the last request identifier, the execution main body can perform preset operation on the last request identifier to obtain a request identifier corresponding to the update request. The preset operation may be a preset addition operation, a preset multiplication operation, or an operation executed according to a preset formula, and when the last request is identified as a character string, the preset operation may be adding a preset character after the character string.
Specifically, the execution entity may add 1 to the last request identifier to serve as the request identifier corresponding to the update request, and each request identifier in the request identifier sequence may be 0, 1, 2, 3, …, or T0, T1, T2, T3, … in sequence. Further, if the update request is the first operation request and the previous request flag is blank, the request flag corresponding to the update request may be set to be an initial flag such as 0 or T0.
In this embodiment, the request identifier of the update request is determined based on the previous request identifier, so that the adjacent request identifiers have correlation, and the request identifiers in the request identifier sequence of the target object have correlation, which can be stored in sequence, thereby improving the accuracy of the determined request identifier.
Referring to FIG. 4, FIG. 4 shows a flowchart 400 of one embodiment of determining an updated version corresponding to a target object, namely step 130 described above, determining an updated version corresponding to a target object and updating a stored version of the target object based on metadata and a request identification of the target object, which may include the steps of:
step 410, adding the request identifier to the request identifier sequence to obtain an updated request identifier sequence.
In this embodiment, after obtaining the request identifier corresponding to the update request, the execution main body may add the request identifier to the request identifier sequence, and store the request identifier behind the last request identifier, so that the request identifiers in the request identifier sequence are sequentially stored, thereby obtaining the updated request identifier sequence.
Step 420, determining an updated version corresponding to the target object based on the metadata of the target object and the updated request identification sequence, and updating the stored version of the target object.
In this embodiment, after the execution main body obtains the updated request identifier sequence, the update data of the target object for the update request may be determined according to the metadata of the target object and the request identifier corresponding to the update request. The execution main body may construct a finite state machine corresponding to the target object with the metadata of the target object and the updated request identification sequence, and form an updated version of the target object for the update request with the metadata of the target object and the updated request identification sequence, where the updated version includes all the request identifications arranged before the request identification of the update request in the metadata of the target object and the updated request identification sequence, and the update data is data of the target object for the updated version.
By way of example, the execution body determines that the request identifier of the update request is T2, adds T2 to the back of T1, and obtains the updated request identifier sequences as T0, T1 and T2. The executive may determine that the metadata of the target object and T0, T1, T2 constitute an updated version of the target object. Further, the metadata of the target object together with the T0, T1 make up the last version of the target object, from which recursion the metadata of the target object together with the request identification sequence may be used to make up the versions of the target object.
In this embodiment, the update version of the target object is determined based on the request identifier sequence and the metadata, so that the request identifier corresponding to each operation request can form different versions, different versions can be stored based on the update request of the user, and different versions corresponding to different request identifiers are realized.
Referring to fig. 5, fig. 5 shows a flowchart 500 of another embodiment of a multi-version concurrent storage method, which may further include the following steps:
step 510, in response to receiving the update request of the user, obtaining a target object corresponding to the update request.
Step 510 of this embodiment may be performed in a manner similar to step 110 in the embodiment shown in fig. 1, and is not described herein again.
Step 520, determining a request identifier corresponding to the update request.
Step 520 of this embodiment may be performed in a manner similar to step 120 of the embodiment shown in fig. 1, and is not described herein again.
Step 530, based on the metadata of the target object and the request identifier, determining an updated version corresponding to the target object, and updating the stored version of the target object.
Step 530 of this embodiment may be performed in a manner similar to step 130 of the embodiment shown in fig. 1, and is not described herein again.
Step 540, in response to receiving the query request of the user for the target object, determining a request identifier corresponding to the query request in the request identifier sequence corresponding to the target object.
In this embodiment, the execution main body may perform different versions of storage on the target object according to an update request of a user, so as to obtain different versions of the target object corresponding to different request identifiers. The user can also perform query operation on the target object in a display interface of the terminal, the terminal generates a query request corresponding to the target object according to the query operation, and sends the query request to the execution main body. The execution main body can receive a query request which is sent by a terminal and is aimed at target objects of different versions by a user, and determines a request identifier corresponding to the query request in a request identifier sequence corresponding to the target object according to the query request.
Because different versions correspond to different request identifiers, the query request may include a request identifier input by a user, and the execution main body may parse the query request to obtain the request identifier in the query request. The execution main body can acquire the request identifier corresponding to the user query version from the received query request according to the request identifier, and determine the request identifier corresponding to the query request in the request identifier sequence corresponding to the target object according to the request identifier in the query request.
Step 550, determining a query version corresponding to the query request based on the metadata of the target object and the request identifier corresponding to the query request.
In this embodiment, after determining the request identifier corresponding to the query request from the request identifier sequence, the execution main body further obtains metadata of the target object, takes the metadata of the target object and data corresponding to the request identifier as query data corresponding to the query request, and takes a version formed by the metadata of the target object and the request identifier as a query version.
And step 560, presenting the target object corresponding to the query version to the user.
In this embodiment, after the execution subject determines the query version of the target object, the query version and the query data corresponding to the target object may be sent to the terminal. And the terminal presents the query version and the query data corresponding to the target object to the user through the display equipment.
In this embodiment, the query version of the target object is determined based on the request identifier corresponding to the query request, so that the query efficiency of different storage versions of the target object is improved, and the query version of the target object can be determined more accurately and more quickly.
As an optional implementation manner, in step 550, taking the metadata of the target object and the request identifier corresponding to the query request as the query version corresponding to the query request, the method may include the following steps: in response to determining the request identifier corresponding to the query request, all request identifiers before the request identifier corresponding to the query request in the request identifier sequence are used as query identifiers; and determining a query version corresponding to the query request based on the metadata and the query identification of the target object.
Specifically, because different versions correspond to different request identifiers, the query request may include a request identifier input by a user, and the execution main body may analyze the query request to obtain the request identifier in the query request. The execution main body can acquire the request identifier corresponding to the user query version from the received query request according to the request identifier, and determine the request identifier corresponding to the query request in the request identifier sequence corresponding to the target object according to the request identifier in the query request.
The execution main body determines all the request identifications arranged before the request identification corresponding to the query request from the request identification sequence, and takes all the determined request identifications and the request identifications corresponding to the query request as query identifications. For example, the request identifier sequence may be T0, T1, T2, T3, and the execution subject determines that the request identifier corresponding to the query request is T2, so that the execution subject may use all the request identifiers T0 and T1 arranged before T2 as query identifiers, and further determines that the request identifiers in the query version corresponding to the query request include T0, T1, and T2.
And after determining the query identifier from the request identifier sequence, the execution main body takes the request identifier corresponding to the query identifier and the request identifier corresponding to the query request as the request identifier sequence corresponding to the query version. The execution main body may further obtain metadata of the target object, use the metadata of the target object and data corresponding to the request identification sequence corresponding to the query version as query data corresponding to the query request, and use a version composed of the metadata of the target object and the request identification sequence corresponding to the query version as the query version.
For example, if the execution subject determines that the query identifier is T0, T1, and further determines that the request identifier sequence corresponding to the query version is T0, T1, T2, then the metadata and T0, T1, T2 are used as the query version corresponding to the query request, and the data corresponding to the metadata and T0, T1, T2 are used as the query data corresponding to the query request.
In the implementation mode, the query identifier is determined from the request identifier sequence based on the request identifier corresponding to the query request, and the query version is determined, so that the query efficiency of different storage versions of the target object is improved, and the query version of the target object can be determined more accurately and more quickly.
With further reference to fig. 6, as an implementation of the method shown in the above figures, the present disclosure provides an embodiment of a multi-version concurrent storage apparatus, which corresponds to the embodiment of the method shown in fig. 1, and which is particularly applicable to various electronic devices.
As shown in fig. 6, the multi-version concurrent storage apparatus 600 of the present embodiment includes: an acquisition module 610, a determination module 620, and an update module 630.
The obtaining module 610 is configured to, in response to receiving an update request of a user, obtain a target object corresponding to the update request;
a determining module 620 configured to determine a request identifier corresponding to the update request;
and an updating module 630 configured to determine an updated version corresponding to the target object and update the stored version of the target object based on the metadata of the target object and the request identifier.
In some optional aspects of this embodiment, the determining module 620 is further configured to: acquiring a request identification sequence corresponding to a target object, wherein the request identification sequence comprises request identifications stored in sequence; and determining the request identifier corresponding to the updating request based on the last request identifier in the request identifier sequence.
In some optional aspects of this embodiment, the updating module 630 is further configured to: adding the request identifier to the request identifier sequence to obtain an updated request identifier sequence; and determining an updated version corresponding to the target object and updating the stored version of the target object based on the metadata of the target object and the updated request identification sequence.
In some optional manners of this embodiment, the apparatus further includes: a query module; and a query module configured to: in response to receiving a query request of a user for a target object, determining a request identifier corresponding to the query request in a request identifier sequence corresponding to the target object; determining a query version corresponding to the query request based on the metadata of the target object and a request identifier corresponding to the query request; and presenting the target object corresponding to the query version to the user.
In some optional aspects of this embodiment, the query module is further configured to: in response to determining the request identifier corresponding to the query request, all request identifiers before the request identifier corresponding to the query request in the request identifier sequence are used as query identifiers; and determining a query version corresponding to the query request based on the metadata and the query identification of the target object.
According to the multi-version concurrent storage device provided by the embodiment of the disclosure, the target object corresponding to the update request is obtained by responding to the received update request of the user, then the request identifier corresponding to the update request is determined, finally the update version corresponding to the target object is determined based on the metadata and the request identifier of the target object, and the storage version of the target object is updated, so that a brand-new multi-version concurrent control storage method is realized, different versions can be stored based on the update request of the user, different versions corresponding to different request identifiers are realized, other systems do not need to be maintained independently, the realization mode is simple, and the efficiency and the simplicity of multi-version concurrent control storage are improved.
In the technical scheme of the disclosure, the acquisition, storage, application and the like of the personal information of the related user all accord with the regulations of related laws and regulations, and do not violate the good customs of the public order.
The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.
FIG. 7 illustrates a schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.
As shown in fig. 7, the electronic device 700 includes a computing unit 701, which may perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM)702 or a computer program loaded from a storage unit 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the device 700 can also be stored. The computing unit 701, the ROM702, and the RAM 703 are connected to each other by a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.
A number of components in the electronic device 700 are connected to the I/O interface 705, including: an input unit 706 such as a keyboard, a mouse, or the like; an output unit 707 such as various types of displays, speakers, and the like; a storage unit 708 such as a magnetic disk, optical disk, or the like; and a communication unit 709 such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.
Computing unit 701 may be a variety of general purpose and/or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 701 executes the respective methods and processes described above, such as the multi-version concurrent storage method. For example, in some embodiments, the multi-version concurrent storage method may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 708. In some embodiments, part or all of a computer program may be loaded onto and/or installed onto device 700 via ROM702 and/or communications unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the multi-version concurrent storage method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the multi-version concurrent storage method by any other suitable means (e.g., by means of firmware).
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on 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.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server with a combined blockchain.
It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.
The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims (13)

1. A multi-version concurrent storage method comprises the following steps:
responding to an update request received from a user, and acquiring a target object corresponding to the update request;
determining a request identifier corresponding to the updating request;
and determining an updated version corresponding to the target object and updating the stored version of the target object based on the metadata of the target object and the request identification.
2. The method of claim 1, wherein the determining a request identifier corresponding to the update request comprises:
acquiring a request identification sequence corresponding to the target object, wherein the request identification sequence comprises request identifications stored in sequence;
and determining the request identifier corresponding to the updating request based on the last request identifier in the request identifier sequence.
3. The method of claim 2, wherein the determining an updated version corresponding to the target object and updating the stored version of the target object based on the metadata of the target object and the request identification comprises:
adding the request identifier to the request identifier sequence to obtain an updated request identifier sequence;
and determining an updated version corresponding to the target object and updating the stored version of the target object based on the metadata of the target object and the updated request identification sequence.
4. The method of claim 1, wherein the method further comprises:
in response to receiving a query request of a user for a target object, determining a request identifier corresponding to the query request in a request identifier sequence corresponding to the target object;
determining a query version corresponding to the query request based on the metadata of the target object and a request identifier corresponding to the query request;
and presenting the target object corresponding to the query version to the user.
5. The method of claim 4, wherein the determining a query version corresponding to the query request based on the metadata of the target object and a request identifier corresponding to the query request comprises:
in response to determining the request identifier corresponding to the query request, taking all request identifiers before the request identifier corresponding to the query request in the request identifier sequence as query identifiers;
and determining a query version corresponding to the query request based on the metadata of the target object and the query identifier.
6. A multi-version concurrent storage device, comprising:
the acquisition module is configured to respond to the received update request of a user and acquire a target object corresponding to the update request;
a determining module configured to determine a request identifier corresponding to the update request;
and the updating module is configured to determine an updated version corresponding to the target object and update the stored version of the target object based on the metadata of the target object and the request identification.
7. The apparatus of claim 6, wherein the determination module is further configured to:
acquiring a request identification sequence corresponding to the target object, wherein the request identification sequence comprises request identifications stored in sequence;
and determining the request identifier corresponding to the updating request based on the last request identifier in the request identifier sequence.
8. The apparatus of claim 7, wherein the update module is further configured to:
adding the request identifier to the request identifier sequence to obtain an updated request identifier sequence;
and determining an updated version corresponding to the target object and updating the stored version of the target object based on the metadata of the target object and the updated request identification sequence.
9. The apparatus of claim 6, wherein the apparatus further comprises: a query module; and the query module configured to:
in response to receiving a query request of a user for a target object, determining a request identifier corresponding to the query request in a request identifier sequence corresponding to the target object;
determining a query version corresponding to the query request based on the metadata of the target object and a request identifier corresponding to the query request;
and presenting the target object corresponding to the query version to the user.
10. The apparatus of claim 9, wherein the query module is further configured to:
in response to determining the request identifier corresponding to the query request, taking all request identifiers before the request identifier corresponding to the query request in the request identifier sequence as query identifiers;
and determining a query version corresponding to the query request based on the metadata of the target object and the query identifier.
11. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-5.
12. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-5.
13. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-5.
CN202110701214.1A 2021-06-23 2021-06-23 Multi-version concurrent storage method and device Pending CN113377402A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110701214.1A CN113377402A (en) 2021-06-23 2021-06-23 Multi-version concurrent storage method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110701214.1A CN113377402A (en) 2021-06-23 2021-06-23 Multi-version concurrent storage method and device

Publications (1)

Publication Number Publication Date
CN113377402A true CN113377402A (en) 2021-09-10

Family

ID=77578737

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110701214.1A Pending CN113377402A (en) 2021-06-23 2021-06-23 Multi-version concurrent storage method and device

Country Status (1)

Country Link
CN (1) CN113377402A (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299194A (en) * 2018-09-25 2019-02-01 平安科技(深圳)有限公司 Multi-edition data memory management method and device, electronic equipment, storage medium
CN111782254A (en) * 2020-07-02 2020-10-16 百度在线网络技术(北京)有限公司 Method, device, equipment and storage medium for upgrading object
CN112115217A (en) * 2020-08-11 2020-12-22 北京四维图新科技股份有限公司 Data processing method and device for high-precision map, electronic equipment and storage medium

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299194A (en) * 2018-09-25 2019-02-01 平安科技(深圳)有限公司 Multi-edition data memory management method and device, electronic equipment, storage medium
CN111782254A (en) * 2020-07-02 2020-10-16 百度在线网络技术(北京)有限公司 Method, device, equipment and storage medium for upgrading object
CN112115217A (en) * 2020-08-11 2020-12-22 北京四维图新科技股份有限公司 Data processing method and device for high-precision map, electronic equipment and storage medium

Similar Documents

Publication Publication Date Title
CN108846753B (en) Method and apparatus for processing data
CN113343803A (en) Model training method, device, equipment and storage medium
CN114816393B (en) Information generation method, device, equipment and storage medium
CN112559631A (en) Data processing method and device of distributed graph database and electronic equipment
CN113127357A (en) Unit testing method, device, equipment, storage medium and program product
CN112528067A (en) Graph database storage method, graph database reading method, graph database storage device, graph database reading device and graph database reading equipment
CN113641677A (en) Data processing method and device, electronic equipment and storage medium
CN114328739A (en) Data synchronization method, data reading method, data synchronization device, data reading device, electronic equipment, storage medium and product
CN113312560A (en) Group detection method and device and electronic equipment
CN112783447A (en) Method, apparatus, device, medium, and article of manufacture for processing snapshots
CN113868254B (en) Method, device and storage medium for removing duplication of entity node in graph database
CN111177479A (en) Method and device for acquiring feature vectors of nodes in relational network graph
CN115454971A (en) Data migration method and device, electronic equipment and storage medium
CN115905322A (en) Service processing method and device, electronic equipment and storage medium
CN116028517A (en) Fusion database system and electronic equipment
CN112887426B (en) Information stream pushing method and device, electronic equipment and storage medium
CN113377402A (en) Multi-version concurrent storage method and device
CN112559547B (en) Method and device for determining consistency among multiple storage object copies
CN114417070A (en) Method, device and equipment for converging data authority and storage medium
CN114116924A (en) Data query method based on map data, map data construction method and device
CN113691403A (en) Topological node configuration method, related device and computer program product
CN114610511B (en) Input verification method and device, electronic equipment and storage medium
CN113051313B (en) Information aggregation method, apparatus, electronic device, storage medium, and program product
CN112948246B (en) AB test control method, device and equipment of data platform and storage medium
CN114153526A (en) Agent-based gray level configuration method, device, electronic device and medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20210910