CN102103642A

CN102103642A - OLTP-based data deletion method, system and graphic database sever

Info

Publication number: CN102103642A
Application number: CN2011100744978A
Authority: CN
Inventors: 陈升; 于洪方; 井卫军; 蒋建平; 姚福源; 刘健
Original assignee: BEIJING CLOUDEX SOFTWARE SERVICE Co Ltd; BEIJING BANYANO DATA CENTER SOLUTIONS Ltd
Current assignee: BEIJING CENTURY BROADBAND INTERNET DATA CENTER Co Ltd
Priority date: 2011-03-25
Filing date: 2011-03-25
Publication date: 2011-06-22
Anticipated expiration: 2031-03-25
Also published as: CN102103642B

Abstract

The embodiment of the invention discloses an on-line transaction processing (OLTP)-based data deletion method, an OLTP-based data deletion system and a graphic database sever. The method comprises the following steps of: receiving a data deletion command transmitted by calling an application programming interface (API) through a client, wherein the data deletion command contains transaction identification, node name and filter condition; searching transaction record according to the transaction identification, and adding the node name into the searched valid transaction record; searching a node attribute state information table according to the node name, and acquiring data records in accordance with the filter condition from the node attribute state information table; and deleting the data records in accordance with the filter condition item by item. By using the embodiment of the invention, deletion of the data records of one transaction on multiple nodes can be realized, and synchronism and integrity of data deletion can be ensured; and when the transaction is invalid, data recovery can be performed by rollback operation, and the integrity of the database is ensured.

Description

OLTP-based data deletion method and system and graphic database server

Technical Field

The present application relates to the field of data Processing technologies, and in particular, to a method and a system for deleting data based On an online Transaction Processing (OLTP) and a graph database server.

Background

OLTP is a system that collects data associated with transactions in real time, as well as sharing changes between databases and other files. When the online transaction processing is carried out, the original data to be processed can be immediately transmitted to the computing center for processing, and a processing result is given in a short time, so that the instant processing and the instant response to the data are realized.

In the OLTP system based on the distributed environment, the integrity of the database needs to be maintained, in the prior art, most of OLTP is realized on a large computer system due to the operation complexity of OLTP and the requirement of quick input/output, and when one transaction involves deleting data on a plurality of nodes (nodes), the rewriting and the non-synchronization of the data are easily caused; moreover, particularly when a transaction fails, recovery is difficult, and the database is likely to be incomplete.

Disclosure of Invention

The embodiment of the application provides a data deletion method and system based on OLTP and a graph database server, and aims to solve the problem that data rewriting and asynchronization are easily caused when data are deleted in the existing distributed OLTP.

In order to solve the technical problem, the embodiment of the application discloses the following technical scheme:

a data deleting method based on an online transaction processing system (OLTP) comprises the following steps:

receiving a data deleting command transmitted by a client through calling an Application Programming Interface (API), wherein the data deleting command comprises a transaction identifier, a node name and a filtering condition;

searching a transaction record according to the transaction identifier, and adding the node name to the searched effective transaction record;

searching a node attribute state information table according to the node name, and acquiring a data record meeting the filtering condition from the node attribute state information table;

and deleting the data records meeting the filtering condition one by one.

Further comprising:

receiving a transaction establishing command transmitted by a client through calling an API;

generating a new transaction record in a transaction attribute state information table according to the transaction creating command, and allocating a unique transaction identifier for the new transaction record;

setting a commit attribute and a rollback attribute of the transaction record to unexecuted.

After searching the transaction record according to the transaction identifier, the method further includes:

judging whether the transaction record is found;

when the transaction record is not found, ending the process, and when the transaction record is found, judging whether the submission attribute and the rollback attribute of the found transaction record are both unexecuted;

and when the judgment result shows that the transaction record is not executed, determining that the searched transaction record is an effective transaction record, executing the operation of adding the node name into the searched effective transaction record, and otherwise, ending the process.

Before deleting the data records meeting the filtering condition one by one, the method further comprises the following steps:

judging whether a data record is locked by other affairs;

and when the data records are not locked by other transactions, executing the operation of deleting the data records meeting the filtering condition one by one, otherwise, returning to the operation of searching the transaction records according to the transaction identification when determining that the transaction corresponding to the transaction records does not exceed a preset time threshold.

The deleting the data records meeting the filtering condition one by one comprises the following steps:

forming the data records into a queue;

sequentially extracting a data record from the queue;

when the extracted data record is not dirty data and is not marked to be updated or deleted, marking to delete the data record and the associated data record of the data record, and physically deleting the dirty data of the associated data record;

when the extracted data record is dirty data and is a newly inserted data record, physically deleting the data record and physically deleting the associated data record of the data record;

when the extracted data record is not dirty data, is not marked for deletion, and is marked for updating, then the duplicate record of the data record is physically deleted, the associated data record of the data record is marked for deletion, and the dirty data of the associated data record is physically deleted.

Further comprising:

after finishing deleting the data records meeting the filtering condition one by one, executing transaction submission operation of data deletion; or, rolling back the deleted data record.

The transaction commit operation includes:

receiving a transaction identifier transmitted by a client through calling an Application Programming Interface (API);

finding out a corresponding transaction record according to the transaction identifier;

when the effective transaction record is found, setting the submission attribute of the transaction record as executed;

deleting the locked data record and the associated data record of the data record;

and deleting the transaction record from the transaction attribute state information table.

The rollback operation comprises:

when a valid transaction record is found, setting the rollback attribute of the transaction record as executed;

unlocking the data record and the associated data record of the data record;

An OLTP-based data deletion system comprising: a graphic database server and a client terminal,

the client is used for transmitting a data deletion command to the graphic database server by calling an API (application program interface) of the graphic database server, wherein the data deletion command comprises a transaction identifier, a node name and a filtering condition;

the graph database server is used for searching transaction records according to the transaction identification, adding the node name into the found effective transaction records, searching a node attribute state information table according to the node name, acquiring the data records meeting the filtering condition from the node attribute state information table, and deleting the data records meeting the filtering condition one by one.

The client is also used for transmitting a transaction establishing command to the graphic database server by calling an API of the graphic database server;

the graphic database server is further configured to generate a new transaction record in the transaction attribute state information table according to the transaction creation command, assign a unique transaction identifier to the new transaction record, and set a commit attribute and a rollback attribute of the transaction record to be unexecuted.

The graph database server is further configured to determine whether the transaction record is found, end the process when the transaction record is not found, determine whether the commit attribute and the rollback attribute of the found transaction record are both unexecuted when the transaction record is found, determine that the found transaction record is an effective transaction record when the commit attribute and the rollback attribute of the found transaction record are both unexecuted, execute the operation of adding the node name to the found effective transaction record, and otherwise end the process.

And the graphic database server is also used for judging whether a data record is locked by other transactions, when the data record is not locked by other transactions, the operation of deleting the data records meeting the filtering condition one by one is executed, otherwise, when the transaction corresponding to the transaction record is determined not to exceed the preset time threshold value, the operation of searching the transaction record according to the transaction identifier is returned.

The graphic database server is further configured to execute a transaction submitting operation of data deletion after completing deleting the data records meeting the filtering condition one by one, or perform a rollback operation on the deleted data records.

A graphic database server, comprising:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is used for receiving a data deleting command transmitted by a client through calling an Application Programming Interface (API), and the data deleting command comprises a transaction identifier, a node name and a filtering condition;

the searching unit is used for searching the transaction record according to the transaction identifier and adding the node name to the searched effective transaction record;

the acquisition unit is used for searching a node attribute state information table according to the node name and acquiring the data record meeting the filtering condition from the node attribute state information table;

and the deleting unit is used for deleting the data records meeting the filtering condition one by one.

The receiving unit is further configured to receive a transaction creation command transmitted by the client through the calling API;

further comprising:

a generating unit, configured to generate a new transaction record in a transaction attribute state information table according to the transaction creating command, and allocate a unique transaction identifier to the new transaction record;

and the setting unit is used for setting the commit attribute and the rollback attribute of the transaction record as unexecuted.

Further comprising:

the first judging unit is used for judging whether the transaction record is found;

the first execution unit is used for ending the process when the transaction record is not found;

the first judging unit is further configured to, when the transaction record is found, judge whether the found commit attribute and rollback attribute of the transaction record are both unexecuted;

the first execution unit is further configured to determine that the found transaction record is an effective transaction record when none of the transactions is determined to be executed, and execute the operation of adding the node name to the found effective transaction record, otherwise, end the process.

Further comprising:

the second judgment unit is used for judging whether the data records are locked by other transactions;

and the second execution unit is used for triggering the deletion unit to execute the operation when the data records are not locked by other transactions, and returning to the search unit to execute the operation when determining that the transaction corresponding to the transaction record does not exceed the preset time threshold value.

The deletion unit includes:

the queue generating unit is used for forming a queue by the data records;

a record extraction unit for sequentially extracting a data record from the queue;

a mark deleting unit, configured to, when the extracted data record is not dirty data and is not marked as updated or deleted, mark to delete the data record and an associated data record of the data record, and physically delete the dirty data of the associated data record;

the mark deleting unit is further configured to, when the extracted data record is dirty data and is a newly inserted data record, physically delete the data record and physically delete an associated data record of the data record;

the mark deleting unit is further configured to, when the extracted data record is not dirty data, is not marked as deleted, and is marked as updated, physically delete a duplicate record of the data record, mark and delete an associated data record of the data record, and physically delete dirty data of the associated data record.

Further comprising:

the submitting unit is used for finishing the transaction submitting operation of executing data deletion after deleting the data records meeting the filtering condition one by one;

and the rollback unit is used for performing rollback operation on the deleted data records.

The commit unit includes:

the identification receiving unit is used for receiving the transaction identification transmitted by the client through calling the Application Programming Interface (API);

the record searching unit is used for searching the corresponding transaction record according to the transaction identifier;

the attribute setting unit is used for setting the submission attribute of the transaction record as executed when the effective transaction record is found;

and the record deleting unit is used for deleting the locked data record and the associated data record of the data record and deleting the transaction record from the transaction attribute state information table.

The rollback unit includes:

the attribute setting unit is used for setting the rollback attribute of the transaction record to be executed when the effective transaction record is found;

a lock releasing unit configured to release a lock on the data record and a lock on an associated data record of the data record;

and the record deleting unit is used for deleting the transaction record from the transaction attribute state information table.

It can be seen from the foregoing embodiments that, in the embodiments of the present application, after receiving a data deletion command transmitted by a client through calling an application programming interface API, a transaction record is searched according to a transaction identifier in the deletion command, a node name is added to the searched valid transaction record, a node attribute state information table is searched according to the node name in the deletion command, a data record meeting a filtering condition is obtained from the node attribute state information table, and the data record meeting the filtering condition is deleted one by one. By applying the embodiment of the application, the operation complexity of OLTP and the requirement of quick input/output can be met, the data records on a plurality of nodes related to one transaction are deleted, and the synchronism and the integrity of data deletion are ensured; and when the transaction fails, data recovery can be performed through rollback operation, and the integrity of the database is guaranteed.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art to obtain other drawings without inventive exercise.

FIG. 1 is a flowchart illustrating an embodiment of an OLTP-based data deletion method according to the present invention;

FIG. 2 is a diagram illustrating an OLTP architecture according to an embodiment of the present application;

FIG. 3 is a flow chart of creating a new transaction in an application example of the present application;

FIG. 4 is a flowchart illustrating deletion of data in a created new transaction according to an exemplary application of the present application;

FIG. 5 is a flow chart illustrating deletion of data records in an exemplary application of the present application;

FIG. 6 is a flow chart illustrating transaction commit for modified data in an example of the application of the present application;

FIG. 7 is a flowchart illustrating transaction rollback on modified data in an example application of the present application;

FIG. 8 is a block diagram of an embodiment of an OLTP-based data deletion system of the present application;

FIG. 9 is a block diagram of a first embodiment of a graphic database server according to the present application;

FIG. 10 is a block diagram of a first embodiment of a graphic database server according to the present application;

fig. 11 is a block diagram of a third embodiment of a graphic database server according to the present application.

Detailed Description

The following embodiments of the present invention provide a data deletion method, system and graphic database server based on OLTP.

In order to make the technical solutions in the embodiments of the present invention better understood and make the above objects, features and advantages of the embodiments of the present invention more comprehensible, the technical solutions in the embodiments of the present invention are described in further detail below with reference to the accompanying drawings.

Referring to fig. 1, a flowchart of an embodiment of the OLTP-based data deletion method of the present application is shown:

step 101: and receiving a data deletion command transmitted by the client through calling the API, wherein the data deletion command comprises a transaction identifier, a node name and a filtering condition.

Further, before receiving the data modification command, the method also comprises a step of creating a transaction, namely receiving the transaction creation command transmitted by the client through calling the API, generating a new transaction record in the transaction attribute state information table according to the transaction creation command, allocating a unique transaction identifier for the new transaction record, and then setting the commit attribute and the rollback attribute of the transaction record to be unexecuted.

Step 102: and searching the transaction record according to the transaction identifier, and adding the node name into the searched effective transaction record.

When the transaction record is searched according to the transaction identifier, further judging whether the transaction record is searched, ending the process when the transaction record is not searched, judging whether the submission attribute and the rollback attribute of the searched transaction record are both unexecuted when the transaction record is searched, determining that the searched transaction record is an effective transaction record when the submission attribute and the rollback attribute of the searched transaction record are both unexecuted, executing the operation of adding the node name into the searched effective transaction record, and ending the process otherwise.

Step 103: and searching a node attribute state information table according to the node name, and acquiring the data record meeting the filtering condition from the node attribute state information table.

Step 104: and deleting the data records meeting the filtering condition one by one.

Before deleting the data records, further judging whether the data records are locked by other transactions, if not, executing the operation of deleting the data records meeting the filtering condition one by one, otherwise, returning the operation of searching the transaction records according to the transaction identification when determining that the transaction corresponding to the transaction records does not exceed the preset time threshold.

When deleting data records, forming the data records into a queue, sequentially extracting one data record from the queue, when the extracted data record is not dirty data and is not marked to be updated or deleted, marking to delete the data record and the associated data record of the data record, and physically deleting the dirty data of the associated data record, when the extracted data record is dirty data and is newly inserted data record, physically deleting the data record and physically deleting the associated data record of the data record, when the extracted data record is not dirty data, is not marked to be deleted, and is marked to be updated, physically deleting the duplicate record of the data record, marking to delete the associated data record of the data record, and physically deleting the dirty data of the associated data record.

Further, the embodiment further includes a transaction commit operation, specifically: receiving a transaction identifier transmitted by a client through calling an Application Programming Interface (API), finding a corresponding transaction record according to the transaction identifier, setting the submission attribute of the transaction record as executed and deleting the locked data record and the associated data record of the data record when the effective transaction record is found, and deleting the transaction record from the transaction attribute state information table.

Further, the embodiment further includes a transaction rollback operation, specifically: receiving a transaction identifier transmitted by a client through calling an Application Programming Interface (API), finding a corresponding transaction record according to the transaction identifier, setting the rollback attribute of the transaction record to be executed when a valid transaction record is found, unlocking the data record, unlocking the associated data record of the data record, and deleting the transaction record from the transaction attribute state information table.

Fig. 2 is a schematic diagram of an architecture of OLTP in the embodiment of the present application:

the OLTP is divided into three layers from top to bottom, and the top layer is an API (Application Programming Interface) for an external calling program to call; the middle layer is a transaction logic control layer and is divided into a synchronous area and a non-synchronous area according to different operation types, wherein only one operation can be executed in the synchronous area at the same time, other operations are in a waiting state when entering the synchronous area, the data deleting process in the embodiment of the application is the operation finished in the synchronous area, the operation in the non-synchronous area is not limited, and the operation can be carried out at any time; the lowest layer is a data storage DataSet operation abstract layer, and the attribute information of the online transaction and the attribute information of the node where the data to be processed by the online transaction are located are respectively stored in different attribute state information tables DataSet.

In the graph database, the state information of the online transaction may be stored in an attribute state information table DataSet named graph _ db _ tx _ def, and the data structure of the DataSet is as shown in table 1 below:

TABLE 1

In the graph database, each data Node (Node) has a corresponding homonymic attribute state information table DataSet, each data record in the DataSet includes data content and also includes associated information of data, which includes attribute information of two column fields as shown in table 2 below, wherein the associated information may also be separately stored in the DataSet named graphic _ db _ relation _ record _ def:

TABLE 2

Based on the foregoing description of the OLTP architecture, an application example is listed below to describe the data deletion method process of the present application.

Referring to fig. 3, it is a flowchart of creating a new transaction in the OLTP system in the application example of the present application:

step 301: and receiving an API call command sent by the client, wherein the call command is used for creating a transaction.

Step 302: a globally unique transaction ID is generated for the transaction to be created.

Step 303: and acquiring the system time of the current OLTP.

Step 304: a new transaction record is inserted in the transaction attribute status information table and the transaction ID and system time are written to the new record.

Wherein, the transaction attribute status information table is graphic _ db _ tx _ def, and the new transaction record inserted therein is as shown in the following table 3:

TABLE 3

tx_no

is_commit

is_rollback

is_timeout

start_time

associate_node

processing

123abc

-1

1291739790803

null

-1

Referring to FIG. 4, a flow diagram for deleting data in a created new transaction:

step 401: the client program calls the API.

The client program transfers the transaction ID and the data to be deleted to the graphic database server by calling the API.

The parameters transmitted into the graphic database by calling the API comprise:

tx _ no, indicating which transaction is to be modified;

a Node _ name specifying which Node data is to be deleted;

and the filter is used for filtering the filtering condition of the data record meeting the condition.

Step 402: and entering a synchronization zone.

Wherein the synchronization zone can be implemented using synchronized synchronous thread locking in the Java language, i.e. only one operation can enter the synchronization zone at the same time.

Step 403: judging whether the transaction is valid, if yes, executing step 404; otherwise, the flow ends.

When judging whether the transaction is valid, querying a graphic _ db _ tx _ def table, and searching by taking the transaction ID as a filtering condition, wherein if the following conditions exist, the transaction is invalid:

the record is not found;

the value of is _ commit in the record is 1, which indicates that the transaction has been committed;

the value of is _ rollback in the record is 1, which indicates that the transaction has rolled back;

the value of is _ timeout in the record is 1, which indicates that the transaction has expired;

if the transaction is invalid, the calling is finished, and error information is returned, otherwise, the subsequent process is continued.

Step 404: the transaction flag is opened.

Looking up the graphic db _ tx _ def table, assuming that the transaction ID (tx _ no) is 123abc, the value of the processing column of the record is set to 1, as shown in the following Table 4:

TABLE 4

tx_no

is_commit

is_rollback

is_timeout

Start_time

associate_node

processing

123abc

-1

1291739790803

null

1

Step 405: the data set change is marked.

The node (associate _ node) name of the node involved in this operation is added to the transaction record. Assuming that the client program inserts data into the Node named Customer after calling the API in the transaction numbered 123abc, the following table 5 shows:

TABLE 5

tx_no

is_commit

is_rollback

is_timeout

Start_time

associate_node

processing

123abc

-1

1291739790803

Customer

1

In the same transaction, if data modifications to multiple nodes are involved, the names of the multiple nodes are separated by commas.

Step 406: and determining data to be deleted.

And taking the filtering parameters transmitted when the client program calls the API as filtering conditions, and filtering data in the DataSet with the same name as the node _ name of the API, wherein all the data matched with the filtering conditions are data records to be deleted.

Step 407: checking whether the data is locked, if yes, executing step 412; otherwise, step 408 is performed.

And checking each data record to be deleted, and if the value of any data record _ dirty column is-1 and the value of the _ tx _ no column is neither null nor equal to the current transaction ID, indicating that the data record exists in the data record to be deleted and is locked by other transactions.

Step 408: and deleting the data records one by one.

When all the data to be deleted are not locked by other transactions, all the data records to be deleted can form a queue, and each data record is deleted. The specific deletion operation process may refer to the flow described in the subsequent fig. 5.

Step 409: the timestamp of the transaction is updated.

The latest system time is updated to the start _ time column of the belonging transaction record. Assuming that the current transaction ID is 123abc and the current system time is 1291739798888, the updated data is shown in table 6 below:

TABLE 6

tx_no

is_commit

is_rollback

is_timeout

Start_time

associate_node

processing

123abc

-1

1291739798888

Customer

1

Step 410: the transaction flag is turned off.

Querying the graphic _ db _ tx _ def table, assuming the transaction ID is 123abc, setting the processing column value of the record to-1, as shown in Table 7 below:

TABLE 7

tx_no

is_commit

is_rollback

is_timeout

start_time

associate_node

processing

123abc

-1

1291739798888

Customer

-1

Step 411: and exiting the synchronous area and ending the flow.

Jumping out of the synchronized synchronous thread lock described above.

Step 412: wait 10 milliseconds.

I.e., the thread executing the current logic sleeps for 10 milliseconds. The time length may be set as needed, and the embodiment of the present application is not limited.

Step 413: judging whether the transaction is overtime, if yes, ending the process; otherwise, return to step 402.

In the current transaction record of the graphic _ db _ tx _ def table, the value of the transaction record start _ time column is subtracted from the current system time, if the difference is greater than 30000 (i.e. 30 seconds), the transaction is over time, the current flow is ended, otherwise, the synchronization area is entered again.

Referring to fig. 5, a flowchart for deleting data item by item in the application example is shown, that is, a detailed description of step 408 in fig. 4 is provided:

step 501: and acquiring the length of the data queue to be deleted.

Step 502: judging whether the queue length is empty, if so, ending the process; otherwise, step 503 is executed.

If the queue length is empty (i.e., 0), it means that there are no data records in the queue to be processed, and the process ends.

Step 503: a data record is taken from the queue of data to be deleted.

Step 504: judging whether the data record is dirty data, if so, executing step 510; otherwise, step 505 is performed.

The value of the _ dirty column of the data record is checked, if the value of this column is 1, this means that this piece of data record is dirty data, otherwise it is not.

Step 505: checking whether the piece of data is marked to be deleted, if so, returning to the step 501; otherwise, step 506 is performed.

Wherein the piece of data record is marked for deletion when the following condition is satisfied:

the value of the _ tx _ no column of the data record is equal to the transaction ID of the current transaction; or,

no data record with the same record ID as the current data record, a dirty column value of 1, and a tx no column value of the current transaction ID exists in the DataSet with the same name of the current node.

If the data record is marked for deletion, the data record is deleted before the current transaction, so that the data record is ignored, the queue length is rechecked, and the next data record is processed, otherwise, the subsequent steps are continued.

Step 506: checking whether the piece of data is marked to be updated, if so, executing step 512; otherwise, go to step 507.

duplicate records with the same record ID of the current data, a dirty column value of 1, and a tx no column value of the current transaction number can be found in the same name DataSet of the current node.

If the piece of data record has been marked for updating, indicating that a modification operation has been performed on the piece of data record in an operation prior to the current transaction, then step 512 is performed, otherwise, the subsequent steps are continued.

Step 507: the delete record is marked.

The value of the _ tx _ no column of the piece of data record is modified to the current transaction ID.

Step 508: the Relation of the deleted data record is marked.

Searching in DataSet with the name of graphic _ db _ Relation _ record _ def, filtering all Relation _ record with the value of source _ record column or target _ record column equal to the record ID of the data record and the value of _ direct column as-1, and setting the value of the _ tx _ no column of the Relation data records as the current transaction ID.

Step 509: the relationship dirty data is physically deleted, and the process returns to step 501.

Looking up in the DataSet named graphic _ db _ Relation _ record _ def, filtering all the Relation data records with the value of source _ record column or target _ record column equal to the record ID of the data record and the value of _ direction column equal to 1, deleting the Relation data records from the DataSet, and returning to step 501.

Step 510: judging whether the dirty data is newly inserted, if so, executing step 511; otherwise, return to step 501.

Searching a data record with the same ID as the data record of the current data record and a dirty column value of-1 in the DataSet, if the data record is found, indicating that the current data is a dirty data copy of the data record, ignoring the current data record, rechecking the queue length, and processing the next data record; if not, it indicates that the current data record is the newly inserted dirty data.

Step 511: the data record is physically deleted, and the replacement dirty data is returned to step 501.

Step 512: the copy of the record is deleted, the deletion of the Relation is marked, the Relation dirty data is physically deleted, and the process returns to step 501.

First, the copy of the data record is deleted.

Next, the delete Relation is marked. Searching in DataSet with the name of graphic _ db _ Relation _ record _ def, filtering all Relation _ record with the value of source _ record column or target _ record column equal to the data record ID of the data record and the value of _ direction column as-1, and setting the value of the _ tx _ no column of the Relation data records as the current transaction ID.

Finally, the replacement dirty data is physically deleted. Searching in the DataSet named graphic _ db _ Relation _ record _ def, filtering all the Relation data records with the value of source _ record column or target _ record column equal to the data record ID of the data record and the value of _ direction column equal to 1, and deleting the Relation data records from the DataSet.

Referring to fig. 6, a process of submitting things for the deleted data is as follows:

step 601: the client invokes the API.

The client program transmits the transaction ID to the graphics database by calling the API.

Step 602: judging whether the transaction is valid, if yes, executing step 603; otherwise, the flow ends.

The mechanism for judging whether the transaction is valid is to query the graphic _ db _ tx _ def table by taking the transaction ID as a filtering condition, and if the following conditions exist, the transaction is invalid:

the record is not found;

if the transaction is invalid, the calling is finished, and error information is returned, otherwise, the subsequent flow is continuously executed.

Step 603: the transaction commit status is marked.

Querying the graphic _ db _ tx _ def table, assuming that the ID of the belonging transaction is 123abc, setting the value of the is _ commit column of the record to 1, as shown in the following table 8:

TABLE 8

tx_no

is_commit

is_rollback

is_timeout

Start_time

associate_node

processing

123abc

1

-1

1291739790803

Customer

-1

Step 604: the locked data is deleted.

Inquiring the value of the associate _ node column in the transaction record in the graphic _ db _ tx _ def table, if the value of the column is Customer, inquiring the DataSet named Customer, and deleting the record with the value of the dirty column in the DataSet being-1 and the value of the _ tx _ no column being-1 as the transaction ID.

Step 605: and deleting the relationship.

Querying the graphic _ db _ translation _ record _ def table, filtering all data records in the DataSet, wherein the value of the _ dirty column is-1, and the value of the _ tx _ no column is equal to the current transaction ID, and deleting the data records from the DataSet.

Step 606: the transaction record is deleted.

And deleting the record of the transaction submitted at this time from the table with the name of graphic _ db _ tx _ def, and completing the submitting operation of the transaction.

Referring to fig. 7, it is a flowchart of the present application when performing transaction rollback on deleted data:

step 701: the client invokes the API.

Step 702: judging whether the transaction is valid, if yes, executing step 703; otherwise, the flow ends.

the record is not found;

Step 703: the transaction rollback state is marked.

Inquiring graphic _ db _ tx _ def, assuming that the number of the belonging transaction is 123abc, setting the value of the is _ rollback column of the data record to be 1, as shown below:

TABLE 9

tx_no

is_commit

is_rollback

is_timeout

Start_time

associate_node

processing

123abc

-1

1

-1

1291739790803

Customer

-1

Step 704: and releasing the data lock.

Inquiring the value of the column associate _ node in the affiliated transaction record in the graphic _ db _ tx _ def table, if the value of the column is Customer, inquiring the DataSet named Customer, filtering the records of which the value of the _ dirty column in the DataSet is equal to-1 and the value of the _ tx _ no column is equal to the current transaction ID, and modifying the value of the _ tx _ no column of the data records into null.

Step 705: release the relationship lock.

Querying a graphic _ db _ relationship _ record _ def table, filtering data records in the DataSet, wherein the value of the _ dirty column is equal to-1, the value of the _ tx _ no column is equal to the current transaction ID, and modifying the value of the _ tx _ no column of the data records to null.

Step 706: the transaction record is deleted.

And deleting the data record of the rollback transaction from the table with the name of graphic _ db _ tx _ def, and finishing the rollback operation of the transaction.

Corresponding to the embodiment of the data deleting method based on the OLTP, the invention also provides the embodiments of the data deleting system based on the OLTP and the graphic database server.

Referring to fig. 8, which is a block diagram of an embodiment of an OLTP-based data deletion system according to the present application:

the OLTP-based data deletion system includes: a client 810 and a graphic database server 820.

The client 810 is configured to transmit a data deletion command to the graph database server by calling an API of the graph database server, where the data deletion command includes a transaction identifier, a node name, and a filtering condition;

the graph database server 820 is configured to search a transaction record according to the transaction identifier, add the node name to the found valid transaction record, search a node attribute state information table according to the node name, obtain the data records meeting the filtering condition from the node attribute state information table, and delete the data records meeting the filtering condition one by one.

Further, the client 810 is further configured to transmit a transaction creation command to the graphic database server by calling an API of the graphic database server; the graphic database server 820 is further configured to generate a new transaction record in the transaction attribute status information table according to the transaction creation command, allocate a unique transaction identifier to the new transaction record, and set the commit attribute and the rollback attribute of the transaction record to be unexecuted.

Further, the graph database server 820 is further configured to determine whether the transaction record is found, end the process when the transaction record is not found, determine whether the commit attribute and the rollback attribute of the found transaction record are both unexecuted when the transaction record is found, determine that the found transaction record is an effective transaction record when the commit attribute and the rollback attribute are both unexecuted, execute the operation of adding the node name to the found effective transaction record, and otherwise end the process.

Further, the graphic database server 820 is further configured to determine whether a data record is locked by other transactions, execute the operation of deleting the data records meeting the filtering condition one by one when none of the data records is locked by other transactions, and otherwise, return the operation of searching for the transaction record according to the transaction identifier when it is determined that the transaction corresponding to the transaction record does not exceed the preset time threshold.

Further, the graphic database server 820 is further configured to complete a transaction submitting operation of data deletion after deleting the data records meeting the filtering condition one by one, or perform a rollback operation on the deleted data records.

Referring to fig. 9, a block diagram of a first embodiment of a graph database server according to the present application is shown:

the graphic database server includes: a receiving unit 910, a searching unit 920, an obtaining unit 930, and a deleting unit 940.

The receiving unit 910 is configured to receive a data deletion command transmitted by a client by calling an application programming interface API, where the data deletion command includes a transaction identifier, a node name, and a filtering condition;

a searching unit 920, configured to search a transaction record according to the transaction identifier, and add the node name to the found valid transaction record;

an obtaining unit 930, configured to search a node attribute state information table according to a node name, and obtain a data record meeting the filtering condition from the node attribute state information table;

a deleting unit 940, configured to delete the data records meeting the filtering condition one by one.

Referring to fig. 10, a block diagram of a second embodiment of a graph database server according to the present application is shown:

the graphic database server includes: the device comprises a receiving unit 1001, a generating unit 1002, a setting unit 1003, a searching unit 1004, a first judging unit 1005, a first executing unit 1006, an acquiring unit 1007, a second judging unit 1008, a second executing unit 1009 and a deleting unit 1010.

The receiving unit 1001 is configured to receive a transaction creation command transmitted by a client through a call API;

a generating unit 1002, configured to generate a new transaction record in a transaction attribute status information table according to the transaction creating command, and allocate a unique transaction identifier to the new transaction record;

a setting unit 1003, configured to set a commit attribute and a rollback attribute of the transaction record to be unexecuted;

the receiving unit 1001 is further configured to receive a data deletion command transmitted by a client by calling an application programming interface API, where the data deletion command includes a transaction identifier, a node name, and a filtering condition;

a searching unit 1004, configured to search a transaction record according to the transaction identifier;

a first determining unit 1005, configured to determine whether the transaction record is found;

a first executing unit 1006, configured to end the process when the transaction record is not found;

the first determining unit 1005 is further configured to, when the transaction record is found, determine whether the commit attribute and the rollback attribute of the found transaction record are both unexecuted;

the first executing unit 1006, configured to determine that the found transaction record is an effective transaction record when none of the transactions is determined to be executed, and execute the operation of adding the node name to the found effective transaction record, otherwise, end the process;

an obtaining unit 1007, configured to search a node attribute state information table according to a node name, and obtain a data record meeting the filtering condition from the node attribute state information table;

a second judgment unit 1008, configured to judge whether there is a data record locked by another transaction;

a second executing unit 1009, configured to trigger the deleting unit 1010 to execute an operation when none of the data records is locked by another transaction, and otherwise, return to the searching unit 1004 to execute an operation when it is determined that the transaction corresponding to the transaction record does not exceed a preset time threshold;

a deleting unit 1010, configured to delete the data records meeting the filtering condition one by one.

Specifically, the deleting unit 1010 may include (not shown in fig. 10): the queue generating unit is used for forming a queue by the data records; a record extraction unit for sequentially extracting a data record from the queue; a mark deleting unit, configured to, when the extracted data record is not dirty data and is not marked as updated or deleted, mark to delete the data record and an associated data record of the data record, and physically delete the dirty data of the associated data record; the mark deleting unit is further configured to, when the extracted data record is dirty data and is a newly inserted data record, physically delete the data record and physically delete an associated data record of the data record; the mark deleting unit is further configured to, when the extracted data record is not dirty data, is not marked as deleted, and is marked as updated, physically delete a duplicate record of the data record, mark and delete an associated data record of the data record, and physically delete dirty data of the associated data record.

Referring to fig. 11, a block diagram of a third embodiment of a graph database server according to the present application is shown:

the graphic database server includes: a receiving unit 1110, a searching unit 1120, an acquiring unit 1130, a deleting unit 1140, a submitting unit 1150, and a rolling-back unit 1160.

A receiving unit 1110, configured to receive a data deletion command transmitted by a client by calling an application programming interface API, where the data deletion command includes a transaction identifier, a node name, and a filtering condition;

a searching unit 1120, configured to search a transaction record according to the transaction identifier, and add the node name to the found valid transaction record;

an obtaining unit 1130, configured to search a node attribute state information table according to a node name, and obtain a data record meeting the filtering condition from the node attribute state information table;

a deleting unit 1140, configured to delete the data records meeting the filtering condition one by one;

a commit unit 1150, configured to complete the transaction commit operation of executing data deletion after deleting the data records meeting the filtering condition one by one;

a rollback unit 1160, configured to perform a rollback operation on the deleted data record.

In particular, the commit unit 1150 may include (not shown in fig. 11): the identification receiving unit is used for receiving the transaction identification transmitted by the client through calling the Application Programming Interface (API); the record searching unit is used for searching the corresponding transaction record according to the transaction identifier; the attribute setting unit is used for setting the submission attribute of the transaction record as executed when the effective transaction record is found; and the record deleting unit is used for deleting the locked data record and the associated data record of the data record and deleting the transaction record from the transaction attribute state information table.

In particular, the rollback unit 1160 may include (not shown in fig. 11): the identification receiving unit is used for receiving the transaction identification transmitted by the client through calling the Application Programming Interface (API); the record searching unit is used for searching the corresponding transaction record according to the transaction identifier; the attribute setting unit is used for setting the rollback attribute of the transaction record to be executed when the effective transaction record is found; a lock releasing unit configured to release a lock on the data record and a lock on an associated data record of the data record; and the record deleting unit is used for deleting the transaction record from the transaction attribute state information table.

As can be seen from the description of the above embodiment, in the embodiment of the present application, after the graphic database server receives the data modification command transmitted by the client through the API, the transaction record is searched according to the transaction identifier in the modification command, the node name is added to the found valid transaction record, the node attribute state information table is searched according to the node name in the modification command, the data record meeting the filtering condition is obtained from the node attribute state information table, and the data record is updated piece by using the data to be updated. By applying the embodiment of the application, the operation complexity of OLTP and the requirement of quick input/output can be met, the data record modification on a plurality of nodes related to one transaction is realized, and the synchronism and the integrity of the data modification are ensured; and when the transaction fails, data recovery can be performed through rollback operation, and the integrity of the database is guaranteed.

Those skilled in the art will readily appreciate that the techniques of the embodiments of the present invention may be implemented as software plus a required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above-described embodiments of the present invention do not limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A data deleting method based on an online transaction processing system (OLTP) is characterized by comprising the following steps:

and deleting the data records meeting the filtering condition one by one.

2. The method of claim 1, further comprising:

3. The method of claim 2, wherein after searching for a transaction record according to the transaction identifier, further comprising:

judging whether the transaction record is found;

4. The method according to claim 1, wherein before deleting the data records meeting the filtering condition one by one, the method further comprises:

judging whether a data record is locked by other affairs;

5. The method according to claim 2, wherein the deleting the data records meeting the filtering condition item by item comprises:

forming the data records into a queue;

sequentially extracting a data record from the queue;

6. The method of claim 5, further comprising:

7. The method of claim 6, wherein the transaction commit operation comprises:

8. The method of claim 6, wherein the rollback operation comprises:

unlocking the data record and the associated data record of the data record;

9. An OLTP-based data deletion system, comprising: a graphic database server and a client terminal,

10. The system of claim 9, wherein the client is further configured to transmit a transaction creation command to the graphics database server by calling an API of the graphics database server;

11. The system of claim 10,

12. The system of claim 9,

13. The system of claim 9,

14. A graphic database server, comprising:

15. The server according to claim 14, wherein the receiving unit is further configured to receive a transaction creation command transmitted by the client through a call API;

further comprising:

16. The server of claim 15, further comprising:

17. The server of claim 14, further comprising:

18. The server according to claim 16, wherein the deleting unit includes:

the queue generating unit is used for forming a queue by the data records;

19. The server of claim 16, further comprising:

20. The server according to claim 19, wherein the submitting unit comprises:

21. The server according to claim 19, wherein the rollback unit comprises: