WO2023066211A1 - 图数据写入 - Google Patents

图数据写入 Download PDF

Info

Publication number
WO2023066211A1
WO2023066211A1 PCT/CN2022/125736 CN2022125736W WO2023066211A1 WO 2023066211 A1 WO2023066211 A1 WO 2023066211A1 CN 2022125736 W CN2022125736 W CN 2022125736W WO 2023066211 A1 WO2023066211 A1 WO 2023066211A1
Authority
WO
WIPO (PCT)
Prior art keywords
write request
graph data
row lock
data write
row
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.)
Ceased
Application number
PCT/CN2022/125736
Other languages
English (en)
French (fr)
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.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information 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 Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Publication of WO2023066211A1 publication Critical patent/WO2023066211A1/zh
Priority to US18/390,739 priority Critical patent/US12189598B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2272—Management thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists

Definitions

  • the embodiments of this specification generally relate to the field of databases, and in particular, relate to a method and device for writing graph data.
  • the embodiments of this specification provide a method and device for writing image data.
  • the graph data writing method and device by setting a finer-grained row lock structure for each vertex or each edge in the graph data, the lock competition during vertex/edge writing can be reduced, thereby improving the performance of the graph database.
  • Write TPS as a whole.
  • the set row locks can be added and deleted automatically, the dynamic management of row locks can be realized, so that very large-scale graph data can be protected with less memory coverage.
  • a method for writing image data including: in response to receiving a first image data write request initiated by a user, based on the target write object in the first image data write request
  • the object identification information determines the row lock index of the corresponding row lock of each target write object, and the target write object includes a target write vertex and/or a target write edge, and each target write object corresponds to a row lock; based on each The row lock index of the target write object is used to lock each target write object in the first map data write request; after each target write object in the first map data request is locked, execute the Write the graph data of the first graph data write request; after the graph data writing of each target write object in the first graph data write request is completed, the data held in the first graph data write request unlocking the row locks; and after all the row locks held by the first graph data write request are unlocked, providing the graph data writing result to the user.
  • locking each target write object in the first map data write request may include: The row lock index of each target write object in the data write request, determine the locking sequence of each target write object; and according to the determined locking sequence, write The object is locked and the locked row lock information is recorded in the write request record, the row lock information at least including the row lock index of the row lock.
  • locking each target write object in the first map data write request may include: for the first map data write request The following locking process is cyclically executed until each target write object is locked or the first map data write request is put into the row lock waiting queue: according to the determined locking sequence, write data from the first map Sequentially fetch the currently unlocked target write object in the request; for the fetched target write object, query whether there is a corresponding row lock in the latch according to the row lock index of the target write object; in the latch When there is no corresponding row lock, create a row lock for the fetched target write object in the latch, and put the first graph data write request into the row if there is a corresponding row lock in the latch The lock's row lock wait queue.
  • the row lock held by the first graph data write request Unlocking may include: cyclically executing the following unlocking process for the first graph data write request until all row locks held by the first graph data write request are unlocked: from the first graph data write request Extract the unlocked row lock information from the request record; based on the row lock index in the extracted row lock information, query whether there is a graph data write request waiting to be written in the corresponding row lock waiting queue; in the row lock waiting queue When there is a graph data write request waiting to be written, the right to hold the row lock corresponding to the row lock index is passed to the second graph data write request at the head of the row lock waiting queue. When there is no second graph data write request waiting to be written in the lock waiting queue, the row lock corresponding to the row lock index is deleted from the latch.
  • the method for writing graph data may further include: triggering an asynchronous retry of the second graph data write request to perform graph data for the second graph data write request write.
  • the method for writing graph data may further include: in response to triggering an asynchronous retry of the second graph data write request, accessing the Row lock waiting queue, to determine whether there is a third graph data write request that can be combined and processed in the row lock waiting queue; and when there is a third graph data write request that can be combined and processed in the row lock waiting queue, The second graph data write request and the third graph data write request are combined into a new graph data write request to write graph data.
  • the second graph data write request or the merged new graph data write request when writing graph data for the second graph data write request or the merged new graph data write request, the second graph data write request or the merged new graph data write request The target write object that has been locked in the new graph data write request does not need to be locked again.
  • a device for writing graph data including: a row lock index determination unit, in response to receiving a first graph data write request initiated by a user, based on the first graph data write
  • the object identification information of the target write object in the request determines the row lock index of the corresponding row lock of each target write object, and the target write object includes a target write vertex and/or a target write edge, and each target write
  • the object corresponds to a row lock
  • the lock unit based on the row lock index of each target write object, locks each target write object in the first graph data write request
  • the data write unit in the first After each target write object in the map data write request is locked, execute the map data write for the first map data write request
  • the unlocking unit writes each target in the first map data write request After the graph data writing of the object is completed, the row locks held by the first graph data write request are unlocked; and the writing result providing unit completes unlocking of all row locks held by the first graph data write request After that, the graph
  • the locking unit may include: a locking sequence determination module, based on the row lock index of each target write object in the first map data write request, determine the The locking sequence of writing objects; the locking module, according to the determined locking sequence, locks each target writing object in the first graph data write request; and the locking information recording module, the locked The row lock information of is recorded in the write request record, and the row lock information includes at least a row lock index of the row lock.
  • the locking module executes the following locking process cyclically for the first map data write request until each target write object is locked or the first map data
  • the write request is put into the row lock waiting queue: according to the determined locking sequence, the currently unlocked target write object is sequentially taken out from the first map data write request; for the taken out target write object, according to The row lock index of the target write object queries whether there is a corresponding row lock in the latch; if there is no corresponding row lock in the latch, create a row lock for the fetched target write object in the latch , when there is a corresponding row lock in the latch, put the first graph data write request into the row lock waiting queue of the row lock.
  • the unlocking unit loops through the following unlocking process for the first graph data write request until all row locks held by the first graph data write request are unlocked: Extract the unlocked row lock information from the write request record of the first graph data write request; based on the row lock index in the retrieved row lock information, query whether there is a graph waiting to be written in the corresponding row lock waiting queue Data write request; when there is a graph data write request waiting to be written in the row lock waiting queue, transfer the ownership of the row lock corresponding to the row lock index to the row lock at the head of the row lock waiting queue For the second graph data write request, when there is no graph data write request waiting to be written in the row lock waiting queue, the row lock corresponding to the row lock index is deleted from the latch.
  • the graph data writing device may further include an asynchronous retry triggering unit, which triggers an asynchronous retry of the second graph data write request to perform Write request for graph data to write.
  • the apparatus for writing graph data may further include: a combinable write request determining unit, responsive to an asynchronous retry triggered by the second graph data write request, accessing the second The row lock waiting queue where the data write request of the second graph is located, to determine whether there is a third graph data write request that can be combined and processed in the row lock waiting queue; When merging the processed third graph data write request, the second graph data write request and the third graph data write request are merged into a new graph data write request for graph data writing.
  • a graph data writing device including: at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory, the The at least one processor executes the computer program to implement the above-mentioned graph data writing method.
  • a computer-readable storage medium which stores executable instructions, and the instructions, when executed, cause a processor to execute the method for writing image data as described above.
  • a computer program product including a computer program, the computer program is executed by a processor to implement the method for writing image data as described above.
  • Fig. 1 shows a schematic diagram of an example of a lock structure in a graph database according to an embodiment of the present specification.
  • FIG. 2 shows an example flowchart of a method for writing graph data according to an embodiment of the present specification.
  • Fig. 3 shows an example flow chart of a writing object locking process according to an embodiment of the specification.
  • Fig. 4 shows an example flow chart of the sequential locking process of writing objects according to the embodiment of the specification.
  • FIG. 5 shows an example flowchart of a row lock unlocking process according to an embodiment of the present specification.
  • FIG. 6 shows an example block diagram of a graph data writing device according to an embodiment of the present specification.
  • Fig. 7 shows an example block diagram of a locking unit according to an embodiment of the present specification.
  • Fig. 8 shows an example schematic diagram of an apparatus for writing graph data based on a computer system according to an embodiment of the present specification.
  • the term “comprising” and its variants represent open terms meaning “including but not limited to”.
  • the term “based on” means “based at least in part on”.
  • the terms “one embodiment” and “an embodiment” mean “at least one embodiment.”
  • the term “another embodiment” means “at least one other embodiment.”
  • the terms “first”, “second”, etc. may refer to different or the same object. The following may include other definitions, either express or implied. Unless the context clearly indicates otherwise, the definition of a term is consistent throughout the specification.
  • Vertex data includes vertex data and edge data.
  • Vertex data may include, for example, vertex identification and vertex attributes.
  • vertex identification may include a vertex ID and a vertex type.
  • the vertex identification may include a vertex ID.
  • Vertex IDs are used to uniquely identify vertices in graph data.
  • Edge data may include edge identifiers and edge attributes.
  • Edge identification may include origin ID, edge type, edge timestamp and end ID.
  • Vertex IDs, edge IDs, vertex attributes, and edge attributes can be business-related. For example, for a social network scenario, the vertex ID may be a person's ID number or personnel number.
  • the vertex type may be the classification to which the vertex belongs, for example, the vertex is classified as a user class vertex.
  • Vertex attributes can include age, education, address, occupation, etc.
  • the edge type is used to indicate the type of the edge. For example, if a transfer edge is created between vertices A and B, the edge type of the transfer edge can be "transfer".
  • the edge attributes may include attributes of edges formed between vertices. For example, in the above transfer edge, the edge attributes may include "amount”, "currency”, "operating equipment” and so on.
  • the term “vertex” may also be referred to as a graph node.
  • vertex data may be referred to as vertex information
  • edge data may be referred to as edge information.
  • hot data may refer to vertices, edges or subgraphs that are frequently updated in a unit time in a graph database.
  • row lock can refer to fine-grained locks used to protect data resources, with one row lock per vertex or edge.
  • row lock waiting queue (Wait List) is used to refer to the queue created in the row lock to store graph data write requests that have lock conflicts.
  • the embodiments of this specification provide a scheme for writing graph data.
  • a finer-grained row lock structure is set for each vertex or each edge in the graph data in the latch (Latch) created when the graph database is initialized, and each row is locked in the latch. It is unique in the lock, so as to reduce the lock competition when the vertex/edge is written when the graph data is written, thereby improving the overall writing TPS of the graph database.
  • the row locks in each latch can be added and deleted, and the row locks are created when the lock is added, and the row locks are released when unlocked, thereby realizing the dynamic management of the row locks, so that the memory space can be fully utilized, enabling the use of Less memory overlay protects very large graph data.
  • FIG. 1 shows an example diagram of a lock structure 100 in a graph database according to an embodiment of the present specification.
  • the lock structure 100 includes multiple latches (Latch), each Latch has multiple row locks (row lock), and a row lock waiting queue (Wait List) is created in each row lock.
  • Latch is created when the graph database is initialized to provide critical protection for the row lock in it.
  • the Latch where the row lock is located needs to be locked.
  • the number of Latches in the lock structure 100 is fixed, but the number of row locks in each Latch is not fixed.
  • the row lock can be created when the target write object is locked, and the row lock can be released (deleted) when the target write object is unlocked.
  • a Wait List can be created in the row lock to store graph data write requests that have lock conflicts.
  • FIG. 2 shows an example flowchart of a method 200 for writing map data according to an embodiment of the present specification.
  • the target write object includes a target write vertex and/or a target write edge, and each target write object corresponds to a row lock.
  • the object identification information is the vertex identification of the target writing vertex, for example, vertex ID and vertex type.
  • the object identification information is the edge identifier of the target write edge, for example, the starting point ID, edge type, time stamp and end point ID.
  • the row lock index Index corresponding to the row lock may be calculated based on the vertex identifier (eg, vertex ID and vertex type).
  • the row lock index Index corresponding to the row lock may be calculated based on the edge identifier (for example, start ID, edge type, edge timestamp, and end ID).
  • the row lock index Index may be determined by calculating a hash value. For example, it is determined by using a hash algorithm to calculate a hash value of the object identification information of the target write object. Examples of hashing algorithms may include, but are not limited to, consistent hashing or perfect hashing.
  • consistent hashing algorithm refers to ordinary hashing algorithms. For any given data, no matter how many consistent hash calculations are performed, the resulting hash calculation results are the same. In addition, hash collisions may occur in consistent hash calculations. In other words, for two given data, after consistent hash calculation, the obtained hash calculation results may be the same.
  • the term "perfect hash algorithm” refers to any data within a given range.
  • the perfect hash values obtained after perfect hash calculation are different, so that the perfect hash value can be used to uniquely map the data.
  • the perfect hash algorithm is used to perform perfect hash calculation on data, it can be ensured that the perfect hash value obtained by the data in the given range is a unique value.
  • the uniqueness of the perfect hash value is relative to the data in the given range, and the hash value obtained from the data outside the given range may be the perfect hash value corresponding to the data in the given range same.
  • FIG. 3 shows an example flowchart of a write object locking process 300 according to an embodiment of the specification.
  • each target write object may be locked and sorted based on the size of the index value of the row lock index determined by the hash calculation.
  • RowIndex hash(id, type)
  • a modulo operation is performed on the RowIndex with the latch size (LatchSize) as the modulus, thereby obtaining the latch index LatchIndex of the latch where the RowIndex is located.
  • each target write object in the first map data write request When performing row lock and lock processing, a Latch may be acquired based on the LatchIndex and the acquired Latch may be locked.
  • the locking process of each target write object in the data write request in the first figure is a sequential cyclic process.
  • FIG. 4 shows an example flowchart of a write object sequential locking process 400 according to an embodiment of the specification.
  • the currently unlocked target write objects are sequentially fetched from the first map data write request.
  • the latch is found based on the row lock index RowIndex of the target write object.
  • the LatchIndex is obtained by performing a modulo operation on the RowIndex with the LatchSize as the modulus, and then the Latch where the RowIndex is located is found based on the LatchIndex.
  • the latch Latch is found, at 430, based on the row lock index RowIndex, it is queried whether there is a corresponding row lock in the latch.
  • 450 it is determined whether there is a target write object that has not been locked in the first map data write request. If there is a target write object that has not been locked, return to step 410, and perform a lock process for the next target write object. If there is no target write object that has not been locked, the lock process for the first map data write request ends.
  • the locked row lock information is recorded in the write request record, and the recorded row lock information includes at least row lock The row lock index RowIndex.
  • the recorded row lock information may also include a latch index LatchIndex of the latch where the row lock is located. It should be noted that, in other embodiments, the operation of 330 may also be performed immediately after 440 in FIG. write request record.
  • the map data write for the first map data write request is performed.
  • the graph data writing process may be implemented by any applicable data writing manner in the art, and no detailed description is given here.
  • the row lock held by the first graph data write request is unlocked.
  • the unlocking process of the row locks held by the data write request of the first map is a cyclic process until all the row locks held by the data write request of the first map are unlocked.
  • FIG. 5 shows an example flowchart of a row lock unlocking process 500 according to an embodiment of the specification.
  • the unlocked row lock information is fetched from the write request record of the first graph data write request.
  • step 510 determine whether there is unprocessed row lock information in the write request record. If there is unprocessed row lock information, return to step 510, and perform row lock unlocking processing for the next row lock information. If there is no unprocessed row lock information, the row lock unlocking process for the first map data write request is completed.
  • the row lock information in the write request record may further include a latch index of the latch where the row lock is located.
  • the latch indexed by the latch index that is, the latch where the row lock is located
  • the data write request for the second graph can also be triggered.
  • the map data writing process for the second map data write request may be performed in the same manner as the map data writing process for the first map data write request.
  • the row lock waiting queue where the data write request of the second graph is located can also be accessed to determine whether there is a mergeable row lock waiting queue in the queue. Handles a third graph data write request. If there is a third graph data write request that can be merged and processed in the row lock waiting queue, the second graph data write request and the third graph data write request are merged into a new graph data write request. Then, graph data writing is performed based on a new graph data write request.
  • the locked target in the second graph data write request or the new graph data write request Writing objects does not need to be locked again.
  • graph data writing results may include, but not limited to: graph data writing success, graph data writing failure (additional failure reason), graph data writing timeout, etc.
  • the above graph data writing method may be executed in parallel for the multiple graph data write requests.
  • the graph data writing device simultaneously receives three graph data write requests, namely, write request 1, write request 2, and write request 3, wherein write request 1 includes three target write vertices ⁇ D, B , C>, write request 2 includes three target write vertices ⁇ E, F, C>, and write request 1 includes three target write vertices ⁇ A, C, G>.
  • the graph data writing means executes write request 1, write request 2, and write request 3 concurrently.
  • the graph data writing device calculates the RowIndex of the row lock corresponding to each vertex according to the vertex information in the write request 1, write request 2 and write request 3, and performs lock sorting according to the RowIndex.
  • the RowIndex and lock order of write request 1 are ⁇ RowIndex_B, RowIndex_C, RowIndex_D>
  • the RowIndex and lock order of write request 2 are ⁇ RowIndex_C, RowIndex_E, RowIndex_F>
  • the RowIndex and lock order of write request 3 are ⁇ RowIndex_A, RowIndex_C, RowIndex_G>.
  • the three write requests concurrently lock the vertices according to the locking order determined by them. Assuming that write request 2 first successfully locks vertex C, the locking process of the three write requests is as follows.
  • Write request 1 first calculates the corresponding LatchIndex according to RowIndex_B, and thus finds the corresponding Latch. At this time, there is no row_lock_B corresponding to vertex B in the Latch, so row_lock_B is created in the Latch, and vertex B is locked successfully. Next, lock processing of the vertex C is performed. When performing lock processing on vertex C, since row_lock_C (created by write request 2) already exists in the corresponding Latch, write request 1 is placed in the Wait List of row_lock_C and waits for row_lock_C to be released.
  • Write request 2 is locked in sequence according to the locking order of vertices C, E, and F, and the graph data write operation is performed after the locking is successful.
  • Write request 3 first calculates the corresponding LatchIndex according to RowIndex_A, and thus finds the corresponding Latch. At this time, there is no row_lock_A corresponding to vertex A in the Latch, so row_lock_A is created in the Latch, and vertex A is locked successfully. Next, lock processing of the vertex C is performed. When performing lock processing on vertex C, since row_lock_C (created by write request 2) already exists in the corresponding Latch, write request 3 is put into the Wait List of row_lock_C and waits for row_lock_C to be released.
  • the unlock operation starts.
  • first release row_lock_C When performing an unlock operation, first release row_lock_C.
  • row_lock_C When row_lock_C is released, it is found that there are write requests 1 and 3 in the Wait List of row_lock_C, and write request 1 is at the head of the Wait List. In this case, the ownership of row_lock_C is passed to write request 1, and an asynchronous retry of write request 1 is triggered, thereby completing row_lock_C release for write request 2.
  • row_lock_E and row_lock_F are released in sequence. Since the Wait List of row_lock_E and row_lock_F has no write request waiting to be written, row_lock_E and row_lock_F are deleted from the Latch.
  • vertices A, B, and C have already been locked, during the lock processing for write request 4, vertices A, B, and C can no longer be locked, but only the unlocked Vertices D and G are locked sequentially, and after the locking is successful, subsequent graph data writing operations are performed for write request 4.
  • each row lock is unique in the latch and corresponds to a unique vertex or edge, so that only the same vertex or edge will have lock conflicts when graph data is written, thereby reducing the number of vertices Lock competition during /edge writing, thereby improving the overall writing TPS of the graph database.
  • the row locks in each latch can be added and deleted, thereby realizing the dynamic management of row locks, so that the memory space can be fully utilized, and ultra-large-scale graph data can be protected with less memory coverage.
  • a row lock waiting queue is created in each row lock to store graph data write requests that have lock conflicts, so that lock conflicts caused by hot data will no longer block threads in the graph database thread pool. Other writing threads, thus greatly improving the overall writing TPS of the graph database when hot data exists.
  • the merge row lock when triggering the asynchronous retry of the second graph data write request, the merge row lock waits for other mergeable graph data write requests in the queue, which can solve the problem of hot data write requests that cannot be executed concurrently.
  • the problem of low write TPS caused.
  • FIG. 6 shows an example block diagram of a graph data writing device 600 according to an embodiment of the present specification.
  • the graph data writing device 600 may include a row lock index determining unit 610 , a locking unit 620 , a data writing unit 630 , an unlocking unit 640 and a writing result providing unit 650 .
  • the row lock index determination unit 610 is configured to, in response to receiving the first map data write request initiated by the user, determine the corresponding row lock of each target write object based on the object identification information of the target write object in the first map data write request.
  • the row lock index of , the target write object includes a target write vertex and/or a target write edge, and each target write object corresponds to a row lock.
  • the locking unit 620 is configured to lock each target write object in the first graph data write request based on the row lock index of each target write object.
  • the operation of the lock unit 620 may refer to the operation described above with reference to 220 of FIG. 2 and the operations described with reference to FIGS. 3 and 4 .
  • the data writing unit 630 is configured to write the map data for the first map data write request after each target write object in the first map data write request is locked.
  • the operation of the data writing unit 630 may refer to the operation described above with reference to 230 of FIG. 2 .
  • the unlocking unit 640 is configured to unlock the row lock held by the first graph data write request after the graph data of each target write object in the first graph data write request is completed.
  • the operation of the unlocking unit 640 may refer to the operation described above with reference to 240 of FIG. 2 and the operation described with reference to FIG. 5 .
  • the write result providing unit 650 is configured to provide the graph data write result to the user after all row locks held by the first graph data write request are unlocked.
  • the operation of the write result providing unit 650 may refer to the operation described above with reference to 250 of FIG. 2 .
  • FIG. 7 shows an example block diagram of a locking unit 620 according to an embodiment of the present specification.
  • the locking unit 620 includes a locking sequence determination module 621 , a locking module 623 and a locking information recording module 625 .
  • the locking sequence determination module 621 is configured to determine the locking sequence of each target write object based on the row lock index of each target write object in the first map data write request. For the operation of the locking sequence determination module 621, reference may be made to the operation of 310 described above with reference to FIG. 3 .
  • the locking module 623 is configured to, according to the determined locking sequence, lock each target write object in the first map data write request.
  • the operation of the locking module 623 may refer to the operation described above with reference to 320 of FIG. 3 and the operation described with reference to FIG. 4 .
  • the operation process of the locking module 623 is a cyclic process. Specifically, the locking module 623 cyclically executes the following locking process for the first map data write request until each target write object is locked or the first map data write request is put into the row lock waiting queue.
  • the locking module 623 sequentially fetches the currently unlocked target write objects from the first map data write request according to the determined locking sequence, and for the fetched target write objects, according to the The row lock index of the target write object checks whether there is a corresponding row lock in the latch. When there is no corresponding row lock in the latch, the locking module 623 creates a row lock for the fetched target write object in the latch. When there is a corresponding row lock in the latch, the locking module 623 puts the first map data write request into the row lock waiting queue of the row lock.
  • the lock information recording module 625 is configured to record the locked row lock information in the write request record, and the recorded row lock information includes at least the row lock index of the row lock.
  • the lock information recording module 625 For operations of the lock information recording module 625, reference may be made to the operations described above with reference to 330 in FIG. 3 .
  • the unlocking process performed by the unlocking unit 640 for the row locks held by the first map data write request is a cyclic process until all row locks held by the first map data write request are unlocked. Specifically, in each cycle, the unlocking unit 640 fetches the unlocked row lock information from the write request record of the first graph data write request, and queries the corresponding row lock index based on the row lock index in the fetched row lock information. Whether there is a graph data write request waiting to be written in the lock waiting queue. When there is a graph data write request waiting to be written in the row lock waiting queue, the unlocking unit 640 transfers the holding right of the row lock corresponding to the row lock index to the second graph data write request at the head of the row lock waiting queue. When there is no graph data write request waiting to be written in the row lock waiting queue, the unlocking unit 640 deletes the row lock from the latch corresponding to the row lock index.
  • the graph data writing apparatus 600 may further include an asynchronous retry trigger unit (not shown).
  • the asynchronous retry triggering unit triggers an asynchronous retry of the second map data write request to perform a map data write operation for the second map data write request.
  • the graph data writing apparatus 600 may further include a combineable write request determining unit and a write request merging unit.
  • the mergeable write request determining unit accesses the row lock waiting queue where the data write request of the second graph is located, to determine whether there is a third graph that can be merged and processed in the row lock waiting queue Data write request.
  • the write request merging unit merges the second graph data write request and the third graph data write request into a new graph data write request for graph data writing enter.
  • the third map data write request may include one or more third map data write requests.
  • the above graph data writing device can be realized by hardware, software or a combination of hardware and software.
  • FIG. 8 shows a schematic diagram of an apparatus 800 for writing graph data based on a computer system according to an embodiment of the present specification.
  • the graph data writing device 800 may include at least one processor 810, a memory (for example, a non-volatile memory) 820, a memory 830, and a communication interface 840, and at least one processor 810, a memory 820, a memory 830 and communication interface 840 are connected together via bus 860 .
  • At least one processor 810 executes at least one computer-readable instruction (ie, the elements implemented in software described above) stored or encoded in memory.
  • computer-executable instructions are stored in memory which, when executed, cause at least one processor 810 to: in response to receiving a user-initiated first map data write request, based on the target in the first map data write request
  • the object identification information of the write object determines the row lock index of the corresponding row lock of each target write object, the target write object includes the target write vertex and/or the target write edge, and each target write object corresponds to a row Lock; based on the row lock index of each target write object, lock each target write object in the first graph data write request; after each target write object in the first graph data write request is locked, execute Write graph data for the first graph data write request; after the graph data writing of each target write object in the first graph data write request is completed, unlock the row lock held by the first graph data write request; And after all row locks held by the first graph data write request are unlocked, the graph data writing result is provided to the user.
  • a program product such as a machine-readable medium (eg, a non-transitory machine-readable medium) is provided.
  • the machine-readable medium may have instructions (that is, the above-mentioned elements implemented in the form of software), and the instructions, when executed by the machine, cause the machine to perform the various operations and operations described above in conjunction with FIGS. 1-7 in various embodiments of this specification.
  • Function Specifically, a system or device equipped with a readable storage medium can be provided, on which a software program code for realizing the functions of any one of the above embodiments is stored, and the computer or device of the system or device can The processor reads and executes the instructions stored in the readable storage medium.
  • the program code itself read from the readable medium can realize the function of any one of the above-mentioned embodiments, so the machine-readable code and the readable storage medium storing the machine-readable code constitute the present invention. a part of.
  • Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, non- Volatile memory card and ROM.
  • the program code can be downloaded from a server computer or cloud via a communication network.
  • a computer program product includes a computer program.
  • the computer program product includes a computer program.
  • the processor executes the above-described in conjunction with FIGS. 1-7 in various embodiments of the present specification. Various operations and functions.
  • the execution order of each step is not fixed, and can be determined as required.
  • the device structures described in the above embodiments may be physical structures or logical structures, that is, some units may be realized by the same physical entity, or some units may be realized by multiple physical entities, or may be realized by multiple physical entities. Certain components in individual devices are implemented together.
  • the hardware units or modules may be implemented mechanically or electrically.
  • a hardware unit, module, or processor may include permanently dedicated circuitry or logic (such as a dedicated processor, FPGA, or ASIC) to perform the corresponding operations.
  • the hardware unit or processor may also include programmable logic or circuits (such as a general-purpose processor or other programmable processors), which can be temporarily set by software to complete corresponding operations.
  • the specific implementation mechanical way, or dedicated permanent circuit, or temporarily installed circuit

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本说明书的实施例提供图数据写入方法及装置。响应于接收到第一图数据写请求，基于第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁。基于各个目标写入对象的行锁索引，为第一图数据写请求中的各个目标写入对象加锁。在第一图数据写请求中的各个目标写入对象完成加锁后，执行针对第一图数据写请求的图数据写入。在第一图数据写请求中的各个目标写入对象的图数据写入完成后，对第一图数据写请求持有的行锁进行解锁。在第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给用户。

Description

图数据写入 技术领域
本说明书实施例通常涉及数据库领域，尤其涉及图数据写入方法及装置。
背景技术
图数据库在写入顶点/边数据时，为了保证数据的准确性，需要对相应的数据资源进行加锁，并且在图数据写入完成后进行解锁。按照这种图数据写入方式，在图数据库的写入出现热点数据时，会阻塞图数据库内的线程池中的大部分写入线程，从而导致数据写入被阻塞，由此造成图数据库的整体写入TPS(Transactions Per Second)大幅下降。此外，由于锁之间存在互斥性，使得热点数据的写请求无法并发执行，从而导致热点数据的写入TPS较低，无法匹配热点数据的写入规模，由此发生大量热点数据写请求失败或超时。
发明内容
鉴于上述，本说明书实施例提供一种图数据写入方法及装置。利用该图数据写入方法及装置，通过为图数据中的每个顶点或每条边设置更细粒度的行锁结构，可以减少顶点/边写入时的锁竞争，由此提升图数据库的整体写入TPS。此外，由于所设置的行锁可以自动增删，由此实现行锁的动态管理，从而可以使用较少内存覆盖保护超大规模的图数据。
根据本说明书实施例的一个方面，提供一种图数据写入方法，包括：响应于接收到用户发起的第一图数据写请求，基于所述第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁；基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁；在所述第一图数据请求中的各个目标写入对象完成加锁后，执行针对所述第一图数据写请求的图数据写入；在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁；以及在所述第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给所述用户。
可选地，在上述方面的一个示例中，基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁可以包括：基于所述第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序；以及按照所确定的 加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁并将已加锁的行锁信息记录在写请求记录中，所述行锁信息至少包括行锁的行锁索引。
可选地，在上述方面的一个示例中，按照所确定的加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁可以包括：针对所述第一图数据写请求循环执行下述加锁过程，直到各个目标写入对象完成加锁或者所述第一图数据写请求被放入行锁等待队列：按照所确定的加锁顺序，从所述第一图数据写请求中顺序取出当前未加锁的目标写入对象；针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁；在所在闩锁中不存在对应的行锁时，在所在闩锁中为所取出的目标写入对象创建行锁，在所在闩锁中存在对应的行锁时，将所述第一图数据写请求放入该行锁的行锁等待队列。
可选地，在上述方面的一个示例中，在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁可以包括：针对所述第一图数据写请求循环执行下述解锁过程，直到所述第一图数据写请求持有的所有行锁完成解锁：从所述第一图数据写请求的写请求记录中取出未解锁的行锁信息；基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列中是否存在等待写入的图数据写请求；在所述行锁等待队列中存在等待写入的图数据写请求时，将所述行锁索引所对应的行锁的持有权传递给位于所述行锁等待队列队首的第二图数据写请求，在所述行锁等待队列中不存在等待写入的第二图数据写请求时，从所在闩锁中删除所述行锁索引所对应的行锁。
可选地，在上述方面的一个示例中，所述图数据写入方法还可以包括：触发所述第二图数据写请求的异步重试来进行针对所述第二图数据写请求的图数据写入。
可选地，在上述方面的一个示例中，所述图数据写入方法还可以包括：响应于所述第二图数据写请求被触发异步重试，访问所述第二图数据写请求所在的行锁等待队列，以确定所述行锁等待队列中是否存在可合并处理的第三图数据写请求；以及在所述行锁等待队列中存在可合并处理的第三图数据写请求时，将所述第二图数据写请求与所述第三图数据写请求合并为新的图数据写请求来进行图数据写入。
可选地，在上述方面的一个示例中，在针对所述第二图数据写请求或所述合并后的新图数据写请求进行图数据写入时，所述第二图数据写请求或所述新图数据写请求中已经加锁的目标写入对象无需再次加锁。
根据本说明书的实施例的另一方面，提供一种图数据写入装置，包括：行锁索引确定单元，响应于接收到用户发起的第一图数据写请求，基于所述第一图数据写请求中的 目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁；加锁单元，基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁；数据写入单元，在所述第一图数据写请求中的各个目标写入对象完成加锁后，执行针对所述第一图数据写请求的图数据写入；解锁单元，在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁；以及写入结果提供单元，在所述第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给所述用户。
可选地，在上述方面的一个示例中，所述加锁单元可以包括：加锁顺序确定模块，基于所述第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序；加锁模块，按照所确定的加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁；以及加锁信息记录模块，将已加锁的行锁信息记录在写请求记录中，所述行锁信息至少包括行锁的行锁索引。
可选地，在上述方面的一个示例中，所述加锁模块针对所述第一图数据写请求循环执行下述加锁过程，直到各个目标写入对象完成加锁或者所述第一图数据写请求被放入行锁等待队列：按照所确定的加锁顺序，从所述第一图数据写请求中顺序取出当前未加锁的目标写入对象；针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁；在所在闩锁中不存在对应的行锁时，在所在闩锁中为所取出的目标写入对象创建行锁，在所在闩锁中存在对应的行锁时，将所述第一图数据写请求放入该行锁的行锁等待队列。
可选地，在上述方面的一个示例中，所述解锁单元针对所述第一图数据写请求循环执行下述解锁过程，直到所述第一图数据写请求持有的所有行锁完成解锁：从所述第一图数据写请求的写请求记录中取出未解锁的行锁信息；基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列中是否存在等待写入的图数据写请求；在所述行锁等待队列中存在等待写入的图数据写请求时，将所述行锁索引所对应的行锁的持有权传递给位于所述行锁等待队列队首的第二图数据写请求，在所述行锁等待队列中不存在等待写入的图数据写请求时，从所在闩锁中删除所述行锁索引所对应的行锁。
可选地，在上述方面的一个示例中，所述图数据写入装置还可以包括异步重试触发单元，触发所述第二图数据写请求的异步重试来进行针对所述第二图数据写请求的图数据写入。
可选地，在上述方面的一个示例中，所述图数据写入装置还可以包括：可合并写请 求确定单元，响应于所述第二图数据写请求被触发异步重试，访问所述第二图数据写请求所在的行锁等待队列，以确定所述行锁等待队列中是否存在可合并处理的第三图数据写请求；以及写请求合并单元，在所述行锁等待队列中存在可合并处理的第三图数据写请求时，将所述第二图数据写请求与所述第三图数据写请求合并为新的图数据写请求来进行图数据写入。
根据本说明书的实施例的另一方面，提供一种图数据写入装置，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上所述的图数据写入方法。
根据本说明书的实施例的另一方面，提供一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如上所述的图数据写入方法。
根据本说明书的实施例的另一方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如上所述的图数据写入方法。
附图说明
通过参照下面的附图，可以实现对于本说明书内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。
图1示出了根据本说明书的实施例的图数据库中的锁结构的示例示意图。
图2示出了根据本说明书的实施例的图数据写入方法的示例流程图。
图3示出了根据本说明书的实施例的写入对象加锁过程的示例流程图。
图4示出了根据本说明书的实施例的写入对象顺序加锁过程的示例流程图。
图5示出了根据本说明书的实施例的行锁解锁过程的示例流程图。
图6示出了根据本说明书的实施例的图数据写入装置的示例方框图。
图7示出了根据本说明书的实施例的加锁单元的示例方框图。
图8示出了根据本说明书的实施例的基于计算机系统实现的图数据写入装置的示例示意图。
具体实施方式
现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺 序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
图数据包括顶点数据和边数据。顶点数据例如可以包括顶点标识和顶点属性。在一个示例中，顶点标识可以包括顶点ID和顶点类型。在另一示例中，顶点标识可以包括顶点ID。顶点标识用于唯一标识图数据中的顶点。边数据可以包括边标识和边属性。边标识可以包括起点ID、边类型、边时间戳和终点ID。顶点标识、边标识、顶点属性和边属性可以与业务相关。比如，对于社交网络场景，顶点ID可以是人的身份证号码或者人员编号等。顶点类型可以是顶点所属分类，例如，顶点分类为用户类顶点。顶点属性可以包括年龄、学历、住址、职业等。边类型用于表示边所属类型，例如，在顶点A和B之间创建一条转账边，则该转账边的边类型可以为“转账”。边属性可以包括顶点与顶点之间所形成边的属性。例如，在上述转账边中，边属性可以包括“金额”、“货币”、“操作设备”等。术语“顶点”也可以称为图节点。在本说明书中，顶点数据可以称为顶点信息，以及边数据可以称为边信息。
在本说明书中，术语“热点数据”可以指代图数据库中的在单位时间内频繁更新的顶点、边或者子图。术语“行锁(row lock)”可以指代用于保护数据资源的细粒度锁，每个顶点或者每条边对应一个行锁。术语“行锁等待队列(Wait List)”用于指代在行锁中创建的用于存放发生锁冲突的图数据写请求的队列。
在将顶点/边数据写入图数据库时，为了保证数据的准确性，需要对相应的数据资源进行加锁，并且在图数据写入完成后进行解锁。在图数据的应用场景下，存在拥有大量关联边的顶点，例如，微博大V、电商头部商家等。这些顶点在一些场景下会在瞬间接收到大量并发的写请求，由此成为热点数据。在图数据中的顶点成为热点数据时，所有对应的并发写入线程中仅仅一个写入线程能够持有该顶点的资源锁，而其它写入线程必须等待该锁释放后再逐一加锁并写入。由此可见，在热点数据的场景下，图数据库内的线程池中的大部分写入线程会被阻塞，从而导致大部分数据写入被阻塞，由此造成图数据库的整体写入TPS大幅下降。此外，由于热点数据本身为瞬时并发的大量写请求，而这些写请求的锁之间存在互斥性，使得热点数据的写请求无法并发执行，从而导致热点 数据的写入TPS较低，无法匹配热点数据的写入规模，由此发生大量热点数据写请求失败或超时。
鉴于此，本说明书的实施例提供一种图数据写入方案。在该图数据写入方案中，在图数据库初始化时创建的闩锁(Latch)中为图数据中的每个顶点或每条边设置具有更细粒度的行锁结构，每个行锁在闩锁中是唯一的，从而在图数据写入时减少顶点/边写入时的锁竞争，由此提升图数据库的整体写入TPS。此外，每个闩锁中的行锁具有可增删性，在加锁时创建行锁，以及在解锁时释放行锁，由此实现行锁的动态管理，从而可以充分利用内存空间，使得能够使用较少的内存覆盖保护超大规模的图数据。
下面将参照附图描述根据本说明书的实施例的图数据写入方法及图数据写入装置。
图1示出了根据本说明书的实施例的图数据库中的锁结构100的示例示意图。
如图1所示，锁结构100包括多个闩锁(Latch)，每个Latch下具有多个行锁(row lock)，以及每个row lock内创建一个行锁等待队列(Wait List)。Latch在图数据库初始化时创建，用于提供对其中的row lock的临界保护。在对row lock进行加锁/解锁操作时，需要对该row lock所在的Latch进行加锁。锁结构100所具有的Latch数量固定，但每个Latch内的row lock的数量不固定。针对一个Latch，可以在对目标写入对象加锁时创建row lock，以及在对目标写入对象解锁时释放(删除)row lock。row lock内可以创建Wait List，用于存放发生锁冲突的图数据写请求。
图2示出了根据本说明书的实施例的图数据写入方法200的示例流程图。
如图2所示，在210，响应于接收到用户发起的第一图数据写请求，基于第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁。例如，在目标写入对象为目标写入顶点时，对象标识信息为目标写入顶点的顶点标识，比如，顶点ID和顶点类型。在目标写入对象为目标写入边时，对象标识信息为目标写入边的边标识，比如，起点ID、边类型、时间戳和终点ID。
例如，在目标写入对象为顶点时，可以基于顶点标识(例如，顶点ID和顶点类型)计算出对应行锁的行锁索引Index。在目标写入对象为边时，可以基于边标识(例如，起点ID、边类型、边时间戳和终点ID)计算出对应行锁的行锁索引Index。在一个示例中，行锁索引Index可以通过计算哈希值的方式确定出。比如，通过使用哈希算法计算目标写入对象的对象标识信息的哈希值确定出。哈希算法的示例可以包括但不限于一致性哈希算法或完美哈希算法。
在本说明书中，术语“一致性哈希算法”是指普通哈希算法。对于任意给定数据，无 论经过多少次一致性哈希计算，所得到的哈希计算结果都相同。此外，一致性哈希计算可能会出现哈希碰撞。换言之，对于两个给定数据，在经过一致性哈希计算后，所得到的哈希计算结果可能会相同。
术语“完美哈希算法”是针对给定范围内的任意数据，经过完美哈希计算后得到的完美哈希值都不相同，从而可以利用该完美哈希值唯一地映射该数据。在进行完美哈希计算时，需要基于该给定范围内的数据在完美哈希计算过程中确定出完美哈希因子，每个数据或者多个数据可以对应一个完美哈希因子。在使用完美哈希算法对数据进行完美哈希计算时，可以确保该给定范围内的数据所得到的完美哈希值是唯一值。这里，完美哈希值的唯一性相对于该给定范围内的数据，根据该给定范围之外的数据得到的哈希值可能会与该给定范围内的数据所对应的完美哈希值相同。
在220，基于各个目标写入对象的行锁索引，为第一图数据写请求中的各个目标写入对象加锁。
图3示出了根据本说明书的实施例的写入对象加锁过程300的示例流程图。
如图3所示，在310，基于第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序。例如，可以基于哈希计算确定的行锁索引的索引值的大小来对各个目标写入对象进行加锁排序。
具体地，例如，对于顶点，使用顶点id与顶点type进行哈希计算得到顶点的行锁索引，即，RowIndex＝hash(id，type)。对于边，使用起点id(srcid)、边类型(type)、边时间戳(timestamp)和终点id(dstid)进行哈希计算得到边的行锁索引，即，RowIndex＝hash(srcid，type，timestamp，dstid)。在确定出目标写入对象的行锁索引RowIndex后，对RowIndex进行以闩锁大小(LatchSize)为模数的取模运算，由此得到该RowIndex所在闩锁的闩锁索引LatchIndex。
在进行加锁排序时，首先基于RowIndex所在闩锁的LatchIndex进行排序。接着，针对LatchIndex相同的RowIndex，基于RowIndex进行排序。例如，假设针对目标写入对象A、B、C和D，通过上述计算所得到的<LatchIndex，RowIndex>分别为<1，6>、<2，4>、<1，5>和<2，3>，则目标写入对象A、B、C和D的加锁顺序为<C，A，D，B>。
在320，按照所确定的加锁顺序，为第一图数据写请求中的各个目标写入对象加锁。在进行行锁加锁处理时，可以基于LatchIndex获取Latch并对所获取的Latch进行加锁。第一图数据写请求中的各个目标写入对象加锁过程是依序进行的循环过程。
图4示出了根据本说明书的实施例的写入对象顺序加锁过程400的示例流程图。
如图4所示，在410，按照所确定的加锁顺序，从第一图数据写请求中顺序取出当前未加锁的目标写入对象。
针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁。具体地，在420，基于该目标写入对象的行锁索引RowIndex找到所在闩锁。例如，通过对RowIndex进行以LatchSize为模数的取模运算得到LatchIndex，然后基于LatchIndex找到该RowIndex所在闩锁Latch。在找到所在闩锁Latch后，在430，基于行锁索引RowIndex在该闩锁中查询是否存在对应的行锁。
如果在所在闩锁中不存在对应的行锁时，则在440，在所在闩锁中为所取出的目标写入对象创建行锁，由此完成针对该目标写入对象的加锁。然后，流程进行到450，在450中，判断第一图数据写请求中是否存在未进行加锁处理的目标写入对象。如果存在未进行加锁处理的目标写入对象，则返回到410，执行针对下一目标写入对象的加锁处理过程。如果不存在未进行加锁处理的目标写入对象，则针对第一图数据写请求的加锁处理过程结束。
在所在闩锁中存在对应的行锁时，在460，将第一图数据写请求放入该行锁的行锁等待队列，由此结束针对第一图数据写请求的加锁处理过程。
回到图3，在如上完成针对第一图数据写请求的加锁处理过程后，在330，将已加锁的行锁信息记录在写请求记录中，所记录的行锁信息至少包括行锁的行锁索引RowIndex。可选地，在一个示例中，所记录的行锁信息还可以包括行锁所在闩锁的闩锁索引LatchIndex。要说明的是，在其它实施例中，330的操作也可以紧接在图4中的440之后执行，即，每当针对一个目标写入对象完成加锁，就将对应的行锁信息记录在写请求记录中。
在如上完成针对第一图数据写请求的加锁处理后，在230，执行针对第一图数据写请求的图数据写入。这里，图数据写入过程可以采用本领域的任何适用的数据写入方式实现，在此不进行详细描述。
在第一图数据写请求中的各个目标写入对象的图数据写入完成后，在240，对第一图数据写请求持有的行锁进行解锁。第一图数据写请求所持有行锁的解锁过程是循环处理过程，直到第一图数据写请求持有的所有行锁完成解锁。
图5示出了根据本说明书的实施例的行锁解锁过程500的示例流程图。
如图5所示，在每次循环时，在510，从第一图数据写请求的写请求记录中取出未解锁的行锁信息。
在520，基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列，并且在 530，判断对应的行锁等待队列中是否存在等待写入的图数据写请求。
如果行锁等待队列中存在等待写入的图数据写请求，则在540，将行锁索引所对应的行锁的持有权传递给位于行锁等待队列队首的第二图数据写请求，由此完成该行锁与第一图数据写请求之间的解锁处理。然后，流程进行到560。
如果行锁等待队列中不存在等待写入的第二图数据写请求，则在550，从所在闩锁中删除行锁索引所对应的行锁，由此完成该行锁的解锁处理。然后，流程进行到560。
在560，判断写请求记录中是否存在未处理的行锁信息。如果存在未处理的行锁信息，则返回到510，针对下一行锁信息执行行锁解锁处理。如果不存在未处理的行锁信息，则针对第一图数据写请求的行锁解锁处理完成。
在一个示例中，写请求记录中的行锁信息还可以包括行锁所在闩锁的闩锁索引。在这种情况下，在对行锁索引所对应的行锁进行解锁处理时，可以对闩锁索引所索引的闩锁(即，行锁所在闩锁)进行加锁。
可选地，在一个示例中，在将行锁索引所对应的行锁的持有权传递给位于行锁等待队列队首的第二图数据写请求后，还可以触发针对第二图数据写请求的异步重试来执行针对第二图数据写请求的图数据写入过程。针对第二图数据写请求的图数据写入过程可以参照与第一图数据写请求的图数据写入过程相同的方式执行。
可选地，在一个示例中，在第二图数据写请求被触发异步重试后，还可以访问第二图数据写请求所在的行锁等待队列，以确定行锁等待队列中是否存在可合并处理的第三图数据写请求。如果在行锁等待队列中存在可合并处理的第三图数据写请求时，则将第二图数据写请求与第三图数据写请求合并为新的图数据写请求。然后，基于新的图数据写请求来执行图数据写入。
可选地，在一个示例中，在针对第二图数据写请求或者新的图数据写请求进行图数据写入时，第二图数据写请求或者新的图数据写请求中已经加锁的目标写入对象无需再次加锁。
回到图2，在第一图数据写请求持有的所有行锁完成解锁后，在250，将图数据写入结果提供给用户。在本说明书中，图数据写入结果的示例例如可以包括但不限于：图数据写入成功，图数据写入失败(附加失败原因)、图数据写入超时等。
要说明的是，在图数据写入包括多个图数据写请求的情况下，可以针对多个图数据写请求并行执行上述图数据写入方法。
下面以一个示例来描述根据本说明书的实施例的图数据写入过程。在该示例中，图数据写入装置同时接收到3个图数据写请求，即，写请求1、写请求2和写请求3，其 中，写请求1包括三个目标写入顶点<D，B，C>，写请求2包括三个目标写入顶点<E，F，C>，以及写请求1包括三个目标写入顶点<A，C，G>。
在执行图数据写入时，图数据写入装置并发执行写请求1、写请求2和写请求3。首先，图数据写入装置分别根据写请求1、写请求2和写请求3中的顶点信息计算各个顶点对应的row lock的RowIndex，并根据RowIndex进行加锁排序。例如，写请求1的RowIndex与加锁顺序为<RowIndex_B，RowIndex_C，RowIndex_D>，写请求2的RowIndex与加锁顺序为<RowIndex_C，RowIndex_E，RowIndex_F>，以及写请求3的RowIndex与加锁顺序为<RowIndex_A，RowIndex_C，RowIndex_G>。
三个写请求并发地按照各自确定出的加锁顺序对顶点进行加锁。假设写请求2首先对顶点C加锁成功，则三个写请求的加锁过程如下。
写请求1首先根据RowIndex_B计算出对应的LatchIndex，由此找到对应的Latch。此时该Latch内没有与顶点B对应的row_lock_B，从而在Latch内创建row_lock_B，顶点B加锁成功。接着，执行顶点C的加锁处理。在进行顶点C的加锁处理时，由于对应Latch中已经存在row_lock_C(写请求2所创建的)，从而将写请求1放入row_lock_C的Wait List中等待row_lock_C释放。
写请求2按照顶点C、E和F的加锁顺序依次加锁，并且在加锁成功后执行图数据写入操作。
写请求3首先根据RowIndex_A计算出对应的LatchIndex，由此找到对应的Latch。此时该Latch内没有与顶点A对应的row_lock_A，从而在Latch内创建row_lock_A，顶点A加锁成功。接着，执行顶点C的加锁处理。在进行顶点C的加锁处理时，由于对应Latch中已经存在row_lock_C(写请求2所创建的)，从而将写请求3放入row_lock_C的Wait List中等待row_lock_C释放。
在写请求2完成图数据写入操作后，开始执行解锁操作。在进行解锁操作时，首先释放row_lock_C。在释放row_lock_C时，发现row_lock_C的Wait List中存在写请求1和写请求3，并且写请求1排在Wait List的队首。在这种情况下，将row_lock_C的持有权传递到写请求1，并且触发写请求1的异步重试，由此针对写请求2完成row_lock_C释放。随后，依次释放row_lock_E和row_lock_F。由于row_lock_E和row_lock_F的Wait List没有等待写入的写请求，从而从所在Latch中删除row_lock_E和row_lock_F。
在写请求1的异步重试时，首先查看row_lock_C的Wait List是否存在可与写请求1合并的写请求，例如，发现可与写请求1合并的写请求3，则将写请求1和写请求3合并为新的写请求4<A，B，C，D，G>，然后针对写请求4执行图数据写入。针对写请 求4的图数据写入过程与针对写请求2的图数据写入过程相同。
具体地，计算写请求4中的5个顶点A，B，C，D和G的行锁索引RowIndex_A，RowIndex_B，RowIndex_C，RowIndex_D，RowIndex_G，并确定加锁顺序<RowIndex_A，RowIndex_B，RowIndex_C，RowIndex_D，RowIndex_G>。然后，按照上述加锁顺序对顶点A，B，C，D和G依次加锁。在一个示例中，由于顶点A、B和C已经完成加锁，从而在针对写请求4的加锁处理时，可以不再对顶点A、B和C进行加锁，而仅仅对未加锁的顶点D和G依次加锁，在加锁成功后，针对写请求4执行后续图数据写入操作。
在写请求4的图数据写入完成后，释放并删除行锁row_lock_A、row_lock_B、row_lock_C、row_lock_D和row_lock_G。然后，返回写请求1和写请求2的图数据写入结果。
如上参照图1到图5描述了根据本说明书的实施例的图数据写入方法。
利用上述图数据写入方法，通过在图数据库初始化时创建的闩锁(Latch)中为图数据中的每个顶点或每条边设置具有更细粒度的行锁结构来替换原有的桶锁(bucket lock)结构，每个行锁在闩锁中是唯一的并且与唯一的顶点或边对应，从而使得在图数据写入时仅仅相同的顶点或边才会发生锁冲突，由此减少顶点/边写入时的锁竞争，进而提升图数据库的整体写入TPS。此外，每个闩锁中的行锁具有可增删性，由此实现行锁的动态管理，从而可以充分利用内存空间，使得能够使用较少内存覆盖保护超大规模的图数据。
利用上述图数据写入方法，通过在每个行锁中创建行锁等待队列来存放发生锁冲突的图数据写请求，使得由于热点数据导致的锁冲突不再阻塞图数据库内的线程池中的其它写入线程，从而大大提升存在热点数据时的图数据库的整体写入TPS。
利用上述图数据写入方法，通过在触发第二图数据写请求的异步重试时，合并行锁等待队列中的其它可合并图数据写请求，可以解决热点数据写请求时由于无法并发执行而导致的写入TPS低的问题。
图6示出了根据本说明书的实施例的图数据写入装置600的示例方框图。如图6所示，图数据写入装置600可以包括行锁索引确定单元610、加锁单元620、数据写入单元630、解锁单元640和写入结果提供单元650。
行锁索引确定单元610被配置为响应于接收到用户发起的第一图数据写请求，基于第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁。行锁索引确定单元610的操作可以参考上面参照图2的210描述的操作。
加锁单元620被配置为基于各个目标写入对象的行锁索引，为第一图数据写请求中的各个目标写入对象加锁。加锁单元620的操作可以参考上面参照图2的220描述的操作以及参照图3和图4描述的操作。
数据写入单元630被配置为在第一图数据写请求中的各个目标写入对象完成加锁后，执行针对第一图数据写请求的图数据写入。数据写入单元630的操作可以参考上面参照图2的230描述的操作。
解锁单元640被配置为在第一图数据写请求中的各个目标写入对象的图数据写入完成后，对第一图数据写请求持有的行锁进行解锁。解锁单元640的操作可以参考上面参照图2的240描述的操作以及参照图5描述的操作。
写入结果提供单元650被配置为在第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给用户。写入结果提供单元650的操作可以参考上面参照图2的250描述的操作。
图7示出了根据本说明书的实施例的加锁单元620的示例方框图。如图7所示，加锁单元620包括加锁顺序确定模块621、加锁模块623和加锁信息记录模块625。
加锁顺序确定模块621被配置为基于第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序。加锁顺序确定模块621的操作可以参考上面参照图3描述的310的操作。
加锁模块623被配置为按照所确定的加锁顺序，为第一图数据写请求中的各个目标写入对象加锁。加锁模块623的操作可以参考上面参照图3的320描述的操作以及参照图4描述的操作。
加锁模块623的操作过程为循环过程。具体地，加锁模块623针对第一图数据写请求循环执行下述加锁过程，直到各个目标写入对象完成加锁或者第一图数据写请求被放入行锁等待队列。
在每次循环时，加锁模块623按照所确定的加锁顺序，从第一图数据写请求中顺序取出当前未加锁的目标写入对象，并且针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁。在所在闩锁中不存在对应的行锁时，加锁模块623在所在闩锁中为所取出的目标写入对象创建行锁。在所在闩锁中存在对应的行锁时，加锁模块623将第一图数据写请求放入该行锁的行锁等待队列。
加锁信息记录模块625被配置为将已加锁的行锁信息记录在写请求记录中，所记录的行锁信息至少包括行锁的行锁索引。加锁信息记录模块625的操作可以参考上面参照图3的330描述的操作。
解锁单元640针对第一图数据写请求所持有行锁执行的解锁过程是循环处理过程，直到第一图数据写请求持有的所有行锁完成解锁。具体地，在每次循环时，解锁单元640从第一图数据写请求的写请求记录中取出未解锁的行锁信息，并且基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列中是否存在等待写入的图数据写请求。在行锁等待队列中存在等待写入的图数据写请求时，解锁单元640将行锁索引所对应的行锁的持有权传递给位于行锁等待队列队首的第二图数据写请求。在行锁等待队列中不存在等待写入的图数据写请求时，解锁单元640从行锁索引所对应的行锁所在闩锁中删除该行锁。
此外，可选地，在一个示例中，图数据写入装置600还可以包括异步重试触发单元(未示出)。所述异步重试触发单元触发第二图数据写请求的异步重试来执行针对第二图数据写请求的图数据写入操作。
此外，可选地，在一个示例中，图数据写入装置600还可以包括可合并写请求确定单元和写请求合并单元。响应于第二图数据写请求被触发异步重试，可合并写请求确定单元访问第二图数据写请求所在的行锁等待队列，以确定行锁等待队列中是否存在可合并处理的第三图数据写请求。在行锁等待队列中存在可合并处理的第三图数据写请求时，写请求合并单元将第二图数据写请求与第三图数据写请求合并为新的图数据写请求来进行图数据写入。这里，第三图数据写请求可以包括一个或多个第三图数据写请求。
如上参照图1到图7，对根据本说明书实施例的图数据写入方法以及图数据写入装置进行了描述。上面的图数据写入装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。
图8示出了根据本说明书的实施例的基于计算机系统实现的图数据写入装置800的示意图。如图8所示，图数据写入装置800可以包括至少一个处理器810、存储器(例如，非易失性存储器)820、内存830和通信接口840，并且至少一个处理器810、存储器820、内存830和通信接口840经由总线860连接在一起。至少一个处理器810执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器810：响应于接收到用户发起的第一图数据写请求，基于第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁；基于各个目标写入对象的行锁索引，为第一图数据写请求中的各个目标写入对象加锁；在第一图数据写请求中的各个目标写入对象完成加锁后，执行针对第一图数据写请求的图数据写 入；在第一图数据写请求中的各个目标写入对象的图数据写入完成后，对第一图数据写请求持有的行锁进行解锁；以及在第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给用户。
应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器810进行本说明书的各个实施例中以上结合图1-图7描述的各种操作和功能。
根据一个实施例，提供了一种比如机器可读介质(例如，非暂时性机器可读介质)的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-图7描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
根据一个实施例，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序当被处理器执行时，使得处理器执行本说明书的各个实施例中以上结合图1-图7描述的各种操作和功能。
本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。
需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实 现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。
上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (16)

  1. 一种图数据写入方法，包括：
    响应于接收到用户发起的第一图数据写请求，基于所述第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁；
    基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁；
    在所述第一图数据写请求中的各个目标写入对象完成加锁后，执行针对所述第一图数据写请求的图数据写入；
    在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁；以及
    在所述第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给所述用户。
  2. 如权利要求1所述的图数据写入方法，其中，基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁包括：
    基于所述第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序；以及
    按照所确定的加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁并将已加锁的行锁信息记录在写请求记录中，所述行锁信息至少包括行锁的行锁索引。
  3. 如权利要求2所述的图数据写入方法，其中，按照所确定的加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁包括：
    针对所述第一图数据写请求循环执行下述加锁过程，直到各个目标写入对象完成加锁或者所述第一图数据写请求被放入行锁等待队列：
    按照所确定的加锁顺序，从所述第一图数据写请求中顺序取出当前未加锁的目标写入对象；
    针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁；
    在所在闩锁中不存在对应的行锁时，在所在闩锁中为所取出的目标写入对象创建行锁，
    在所在闩锁中存在对应的行锁时，将所述第一图数据写请求放入该行锁的行锁等待队列。
  4. 如权利要求2所述的图数据写入方法，其中，在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁包括：
    针对所述第一图数据写请求循环执行下述解锁过程，直到所述第一图数据写请求持有的所有行锁完成解锁：
    从所述第一图数据写请求的写请求记录中取出未解锁的行锁信息；
    基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列中是否存在等待写入的图数据写请求；
    在所述行锁等待队列中存在等待写入的图数据写请求时，将所述行锁索引所对应的行锁的持有权传递给位于所述行锁等待队列队首的第二图数据写请求，
    在所述行锁等待队列中不存在等待写入的第二图数据写请求时，从所在闩锁中删除所述行锁索引所对应的行锁。
  5. 如权利要求4所述的图数据写入方法，还包括：
    触发所述第二图数据写请求的异步重试来进行针对所述第二图数据写请求的图数据写入。
  6. 如权利要求5所述的图数据写入方法，还包括：
    响应于所述第二图数据写请求被触发异步重试，访问所述第二图数据写请求所在的行锁等待队列，以确定所述行锁等待队列中是否存在可合并处理的第三图数据写请求；以及
    在所述行锁等待队列中存在可合并处理的第三图数据写请求时，将所述第二图数据写请求与所述第三图数据写请求合并为新的图数据写请求来进行图数据写入。
  7. 如权利要求5或6所述的图数据写入方法，其中，在针对所述第二图数据写请求或所述合并后的新图数据写请求进行图数据写入时，所述第二图数据写请求或所述新图数据写请求中已经加锁的目标写入对象无需再次加锁。
  8. 一种图数据写入装置，包括：
    行锁索引确定单元，响应于接收到用户发起的第一图数据写请求，基于所述第一图数据写请求中的目标写入对象的对象标识信息确定各个目标写入对象的对应行锁的行锁索引，所述目标写入对象包括目标写入顶点和/或目标写入边，每个目标写入对象对应一个行锁；
    加锁单元，基于各个目标写入对象的行锁索引，为所述第一图数据写请求中的各个目标写入对象加锁；
    数据写入单元，在所述第一图数据写请求中的各个目标写入对象完成加锁后，执行针对所述第一图数据写请求的图数据写入；
    解锁单元，在所述第一图数据写请求中的各个目标写入对象的图数据写入完成后，对所述第一图数据写请求持有的行锁进行解锁；以及
    写入结果提供单元，在所述第一图数据写请求持有的所有行锁完成解锁后，将图数据写入结果提供给所述用户。
  9. 如权利要求8所述的图数据写入装置，其中，所述加锁单元包括：
    加锁顺序确定模块，基于所述第一图数据写请求中的各个目标写入对象的行锁索引，确定各个目标写入对象的加锁顺序；
    加锁模块，按照所确定的加锁顺序，为所述第一图数据写请求中的各个目标写入对象加锁；以及
    加锁信息记录模块，将已加锁的行锁信息记录在写请求记录中，所述行锁信息至少包括行锁的行锁索引。
  10. 如权利要求9所述的图数据写入装置，其中，所述加锁模块：
    针对所述第一图数据写请求循环执行下述加锁过程，直到各个目标写入对象完成加锁或者所述第一图数据写请求被放入行锁等待队列：
    按照所确定的加锁顺序，从所述第一图数据写请求中顺序取出当前未加锁的目标写入对象；
    针对所取出的目标写入对象，根据该目标写入对象的行锁索引查询所在闩锁中是否存在对应的行锁；
    在所在闩锁中不存在对应的行锁时，在所在闩锁中为所取出的目标写入对象创建行锁，
    在所在闩锁中存在对应的行锁时，将所述第一图数据写请求放入该行锁的行锁等待队列。
  11. 如权利要求9所述的图数据写入装置，其中，所述解锁单元：
    针对所述第一图数据写请求循环执行下述解锁过程，直到所述第一图数据写请求持有的所有行锁完成解锁：
    从所述第一图数据写请求的写请求记录中取出未解锁的行锁信息；
    基于所取出的行锁信息中的行锁索引，查询对应的行锁等待队列中是否存在等待写入的图数据写请求；
    在所述行锁等待队列中存在等待写入的图数据写请求时，将所述行锁索引所对应的 行锁的持有权传递给位于所述行锁等待队列队首的第二图数据写请求，
    在所述行锁等待队列中不存在等待写入的图数据写请求时，从所在闩锁中删除所述行锁索引所对应的行锁。
  12. 如权利要求11所述的图数据写入装置，还包括：
    异步重试触发单元，触发所述第二图数据写请求的异步重试来进行针对所述第二图数据写请求的图数据写入。
  13. 如权利要求12所述的图数据写入装置，还包括：
    可合并写请求确定单元，响应于所述第二图数据写请求被触发异步重试，访问所述第二图数据写请求所在的行锁等待队列，以确定所述行锁等待队列中是否存在可合并处理的第三图数据写请求；以及
    写请求合并单元，在所述行锁等待队列中存在可合并处理的第三图数据写请求时，将所述第二图数据写请求与所述第三图数据写请求合并为新的图数据写请求来进行图数据写入。
  14. 一种图数据写入装置，包括：
    至少一个处理器，
    与所述至少一个处理器耦合的存储器，以及
    存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求1到7中任一所述的图数据写入方法。
  15. 一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如权利要求1到7中任一所述的图数据写入方法。
  16. 一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如权利要求1到7中任一所述的图数据写入方法。
PCT/CN2022/125736 2021-10-21 2022-10-17 图数据写入 Ceased WO2023066211A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/390,739 US12189598B2 (en) 2021-10-21 2023-12-20 Writing graph data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111224487.8A CN113672636B (zh) 2021-10-21 2021-10-21 图数据写入方法及装置
CN202111224487.8 2021-10-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/390,739 Continuation US12189598B2 (en) 2021-10-21 2023-12-20 Writing graph data

Publications (1)

Publication Number Publication Date
WO2023066211A1 true WO2023066211A1 (zh) 2023-04-27

Family

ID=78550794

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/125736 Ceased WO2023066211A1 (zh) 2021-10-21 2022-10-17 图数据写入

Country Status (3)

Country Link
US (1) US12189598B2 (zh)
CN (1) CN113672636B (zh)
WO (1) WO2023066211A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113672636B (zh) * 2021-10-21 2022-03-22 支付宝(杭州)信息技术有限公司 图数据写入方法及装置
CN120910061A (zh) * 2024-11-21 2025-11-07 支付宝(杭州)信息技术有限公司 一种针对图数据库的操作方法及相关设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100242043A1 (en) * 2009-03-18 2010-09-23 Charles Scott Shorb Computer-Implemented Systems For Resource Level Locking Without Resource Level Locks
CN103886109A (zh) * 2014-04-18 2014-06-25 北京搜狐新媒体信息技术有限公司 一种实现数据库行锁的方法及装置
CN108595251A (zh) * 2018-05-10 2018-09-28 腾讯科技（深圳）有限公司 动态图更新方法、装置、存储引擎接口和程序介质
CN108959403A (zh) * 2018-06-06 2018-12-07 阿里巴巴集团控股有限公司 一种分布式事务处理方法及装置
CN110730958A (zh) * 2017-06-09 2020-01-24 华为技术有限公司 用于管理按优先级排序的数据库事务的方法和系统
CN112084206A (zh) * 2020-09-15 2020-12-15 腾讯科技（深圳）有限公司 数据库的事务请求处理方法、相关设备及存储介质
CN113672636A (zh) * 2021-10-21 2021-11-19 支付宝(杭州)信息技术有限公司 图数据写入方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996563B2 (en) * 2010-04-06 2015-03-31 Tokutek, Inc. High-performance streaming dictionary
CN106354729B (zh) * 2015-07-16 2020-01-07 阿里巴巴集团控股有限公司 一种图数据处理方法、装置和系统
US11093497B1 (en) * 2018-03-23 2021-08-17 Amazon Technologies, Inc. Nearest neighbor search as a service
US11442994B2 (en) * 2018-03-27 2022-09-13 Substrate Inc. Unified data store and transaction system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100242043A1 (en) * 2009-03-18 2010-09-23 Charles Scott Shorb Computer-Implemented Systems For Resource Level Locking Without Resource Level Locks
CN103886109A (zh) * 2014-04-18 2014-06-25 北京搜狐新媒体信息技术有限公司 一种实现数据库行锁的方法及装置
CN110730958A (zh) * 2017-06-09 2020-01-24 华为技术有限公司 用于管理按优先级排序的数据库事务的方法和系统
CN108595251A (zh) * 2018-05-10 2018-09-28 腾讯科技（深圳）有限公司 动态图更新方法、装置、存储引擎接口和程序介质
CN108959403A (zh) * 2018-06-06 2018-12-07 阿里巴巴集团控股有限公司 一种分布式事务处理方法及装置
CN112084206A (zh) * 2020-09-15 2020-12-15 腾讯科技（深圳）有限公司 数据库的事务请求处理方法、相关设备及存储介质
CN113672636A (zh) * 2021-10-21 2021-11-19 支付宝(杭州)信息技术有限公司 图数据写入方法及装置

Also Published As

Publication number Publication date
US12189598B2 (en) 2025-01-07
CN113672636A (zh) 2021-11-19
CN113672636B (zh) 2022-03-22
US20240119039A1 (en) 2024-04-11

Similar Documents

Publication Publication Date Title
US11934424B1 (en) Method and apparatus for resolving target database constraint violations in a database replication system where target database transactions are automatically aborted due to constraints violations
US11907260B2 (en) Compare processing using replication log-injected compare records in a replication environment
CN105700939B (zh) 一种分布式系统中多线程同步的方法和系统
US7912821B2 (en) Apparatus and method for data management
US20160275150A1 (en) Lightweight table comparison
US12189598B2 (en) Writing graph data
CN110442459A (zh) 分布式死锁检测方法及装置、计算机设备及可读介质
US20140279987A1 (en) Workflow design for long-running distributed operations using no sql databases
CN117076147B (zh) 死锁检测方法、装置、设备和存储介质
CN113760976A (zh) 业务的处理方法、装置、设备及存储介质
WO2021036909A1 (zh) 写入图片的方法和装置
US10657139B2 (en) Information processing apparatus and non-transitory computer readable medium for distributed resource management
WO2023071848A1 (zh) 图数据加载
US20230117060A1 (en) Read-write method and apparatus, electronic device, and readable memory medium
WO2015085914A1 (zh) 数据库访问方法和装置
US20150074062A1 (en) Capturing change data of deferred updates
CN113761059B (zh) 数据处理方法及装置
CN104077078A (zh) 读存储区、更新存储区的方法及装置
JP2003271436A (ja) データ処理方法、データ処理装置およびデータ処理プログラム
CN111414337B (zh) 一种文件读取方法、装置、计算设备及存储介质
HK40062626A (zh) 图数据写入方法及装置
HK40062626B (zh) 图数据写入方法及装置
CN108255848B (zh) 实现条件更新的方法、设备及系统
CN111274208A (zh) 锁定文件的方法和装置
CN120804164B (zh) 一种减少数据库智能大对象高并发场景下冲突的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22882817

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22882817

Country of ref document: EP

Kind code of ref document: A1