Query method of graph database, index creation method, and related device

Abstract

The application discloses a data query method of a graph database, an index creation method of the graph database, an electronic device and a computer readable storage medium. The query method comprises the following steps: acquiring a query condition; finding a target joint index from joint indexes of the graph database, the attribute of the target joint index meeting the query condition, and the attributes of the joint indexes comprising the attributes of edges and the attributes of two nodes associated with the edges; and taking two target nodes associated with target edges with the target joint index as a data query result. Through the above method, the query efficiency can be improved, and the application range can be expanded.

Description

Technical Field

[0001] This application relates to the field of graph database technology, and in particular to a data query method for graph databases, a graph database index creation method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Januspraph is an open-source distributed database whose graph data is based on the attribute graph model. An attribute graph is a directed graph composed of nodes, edges, node labels, and properties. Nodes represent entities, and edges represent relationships. Entities can be any describable subject in nature, such as people, vehicles, events, categories, etc.

[0003] Querying data directly from a graph database involves a full graph scan, resulting in extremely low query efficiency. To improve efficiency, existing methods involve creating indexes for the graph database. However, these index-based methods still lack sufficient efficiency and have limited applicability. Summary of the Invention

[0004] This application provides a data query method for graph databases, a graph database index creation method, an electronic device, and a computer-readable storage medium, which can solve the problems of insufficient query efficiency and limited applicability of existing index-based methods for querying data from graph databases.

[0005] To address the aforementioned technical problems, this application provides a data query method for graph databases. This method includes: obtaining query conditions; searching for a target composite index from the composite index of the graph database, wherein the attributes of the target composite index meet the query conditions, and the attributes of the composite index include the attributes of the edges and the attributes of the two nodes associated with the edges; and using the two target nodes associated with the target edge that have the target composite index as the data query result.

[0006] To solve the above-mentioned technical problems, this application adopts the following technical solution: providing a method for creating an index for a graph database, the method including: creating a composite index; and writing the attributes of the edge and the attributes of the two nodes associated with the edge into the composite index.

[0007] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide an electronic device, which includes a processor and a memory connected to the processor, wherein the memory stores program instructions; the processor is used to execute the program instructions stored in the memory to implement the above-mentioned method.

[0008] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a computer-readable storage medium storing program instructions that, when executed, can implement the above-mentioned method.

[0009] Through the above method, the composite index of the graph database in this application includes the attributes of the edges and the attributes of the two nodes associated with the edges. Therefore, when querying data, regardless of whether the query conditions involve edge attributes, node attributes, or both edge and node attributes, the target composite index that meets the query conditions can be directly determined, directly hitting the data query results without traversal. Therefore, it has a wide range of applications and high query efficiency. Furthermore, the data query method provided in this application still follows the original query syntax (Gremlin syntax), requiring no changes to the graph query syntax, thus simplifying implementation. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the HBase storage structure;

[0011] Figure 2 This is a schematic diagram of the structure of a storage unit in HBase;

[0012] Figure 3 This is a diagram of the graph data structure corresponding to "men lingering at the Bank of China";

[0013] Figure 4 This is a schematic diagram of Person id 1;

[0014] Figure 5 This is a diagram illustrating the traversal information obtained based on Person id 1;

[0015] Figure 6 This is a diagram illustrating the traversal information obtained based on Person id 95647;

[0016] Figure 7 This is a flowchart illustrating an embodiment of the index creation method for the graph database of this application;

[0017] Figure 8 This is a flowchart illustrating another embodiment of the index creation method for the graph database in this application;

[0018] Figure 9 This is a flowchart illustrating the process of creating a composite index for the current edge;

[0019] Figure 10 This is a flowchart illustrating an embodiment of the data query method for the graph database in this application;

[0020] Figure 11 This is a schematic diagram of the structure of an embodiment of the electronic device of this application;

[0021] Figure 12 This is a schematic diagram of the structure of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0023] The terms "first," "second," and "third" used in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0024] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments without conflict.

[0025] Before introducing the method provided in this application, let's briefly introduce graph databases:

[0026] Graph databases use storage systems (such as HBase, Cassandra, etc.) as external storage backends, meaning that the graph data in a graph database is actually stored in the storage system.

[0027] This application will use HBase as an example. HBase is a NoSQL database, a distributed, column-oriented open-source database. In HBase, a table is a collection of rows, a row is a collection of column families, a column family is a collection of columns, and a column is a collection of key-value pairs. An example of an HBase storage structure is shown below. Figure 1 In HBase, a storage unit (cell) is defined by rows and columns. A row in HBase contains information about a node, including all its attributes and the edges associated with it. Each attribute and each edge is a separate storage unit. An example of an HBase storage unit is shown below. Figure 2When writing an edge to a graph database, it is necessary to query the nodes associated with the edge, add the edge to the row data of the associated nodes, and update the row data.

[0028] Graph databases use indexing systems (such as Elasticearch and Solr) as external index backends. This allows them to accelerate the querying of graph data within the database.

[0029] Graph databases support gremlins (TinkerPop graph traversal language) for querying, allowing users to add, delete, modify, and query graph data in the database.

[0030] Graph databases support creating indexes for their edges and nodes. For clarity, this application will refer to the indexes created for edges and nodes as single indexes. Therefore, when querying data from a graph database, the starting object (starting node or starting edge) can be found first using the single index, and then the starting object can be traversed to obtain the data query results. However, since a single index only involves one node or one edge and only applies to the starting object, when there are multiple query conditions (one query condition involving one node or edge), after determining that the starting object matches one of the query conditions based on the single index, it is necessary to traverse the starting object to determine the target objects that match other query conditions.

[0031] For example, a single index was created for the attributes (name id, gender) of the node "person" in a graph database. To query "males loitering in the Bank of China", Figure 3 This is a diagram of the graph data structure corresponding to "men lingering in the Bank of China". Figure 3 The middle nodes represent a "person" with a male gender attribute and an event with a "Bank of China" location attribute, while the edges are "hesitation edges." For example... Figure 3 As shown, to query "male loitering in the Bank of China" in the graph database, the query conditions include query condition 1 "person, gender: male", query condition 2 "loitering edge", and query condition 3 "event, location: Bank of China".

[0032] To find the target object based on the three query conditions mentioned above, the following query process is required:

[0033] 1) Determine candidate indexes that meet query condition 1 from the single index. Each candidate index corresponds to a candidate object (a person with an id).

[0034] 2) The target objects that meet query conditions 2 and 3 are determined from the candidate objects through a traversal process. Specifically:

[0035] See also Figure 4Using Person id1 as the first candidate, retrieve the edges associated with Person id1 (wandering edge, peer edge, nocturnal edge). The edges associated with Person id1 include the wandering edge, therefore Person id1 meets query condition 2.

[0036] Furthermore, in conjunction with reference Figure 5 Determine the hovering event (hovering id1) associated with the hovering edge.

[0037] Furthermore, the attributes of Person ID1 were determined (time attribute: January 2020, location attribute: China Merchants Bank). Since the location attribute is not Bank of China, Person ID1 does not meet query condition 3.

[0038] See also Figure 6 If Person id 1 does not meet query conditions 2 and 3, continue to perform the above steps on the next candidate object to find the candidate object (Person id 95647) that meets query conditions 2 and 3, and take Person id 95647 as the target object.

[0039] In the above process, since the single index for a person only applies to "people", that is, the single index only involves one query condition, it is necessary to further determine the target objects that satisfy query condition 2 and query condition 3 from the candidate objects by traversing after determining the candidate objects that satisfy query condition 1.

[0040] Therefore, querying data from a graph database using a single index inevitably involves a traversal process, which leads to low query efficiency. Consequently, querying data from a graph database using a single index is limited in its applicability due to its low query efficiency.

[0041] To improve query efficiency, a common approach in existing technologies is to list all possible combinations of query conditions, create a corresponding graph index for each combination, and then, when a query is needed, simply determine the graph index based on the query condition combination and use that index to identify the target object that satisfies the query condition combination. However, this approach has the following problems:

[0042] 1) The more complex the business logic and the more query conditions there are, the more difficult it is to create a graph index;

[0043] 2) The more complex the graph data structure in a graph database, the more possible combinations of query conditions, the larger the disk space occupied by the graph index, and the more difficult it is to write.

[0044] 3) The native Gremlin query syntax cannot be used directly, and the index query interface needs to be redeveloped;

[0045] 4) It is easy to exceed the field limit of a single index in Elasticearch (maximum 1024 fields), and the attribute field process will affect index performance.

[0046] In order to improve query efficiency without affecting other performance aspects, the method provided in this application is as follows:

[0047] The method provided in this application consists of two parts: one part is creating a composite index for a graph database; the other part is the application of the composite index, that is, querying data from the graph database based on the composite index.

[0048] The following section introduces how to create a composite index for a graph database:

[0049] Figure 7 This is a flowchart illustrating an embodiment of the index creation method for the graph database of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily reflect that outcome. Figure 7 The illustrated process sequence is limited. For example... Figure 7 As shown, this embodiment may include:

[0050] S11: Create a composite index.

[0051] The structure of a composite index includes the attributes of the edge and the attributes of the two nodes associated with the edge. Additionally, the composite index includes its name. The structure of a composite index created from the nodes of an edge can be represented as follows:

[0052] {

[0053] Composite index name,

[0054] List of attributes of a composite index [

[0056] Edge properties,

[0057] Node attributes ]

[0059] }

[0060] S12: Write the attributes of the edge, as well as the attributes of the two nodes associated with the edge, into the joint index.

[0061] A joint index can be created for each edge. Thus, each edge can be sequentially treated as the current edge, and the attributes of the current edge, as well as the attributes of the two current nodes associated with the current edge, can be written into the joint index to obtain the joint index of the current edge.

[0062] Alternatively, a joint index can be created only for edges of a preset category. In this way, each edge can be sequentially treated as the current edge, and its category can be checked against the preset category. If it is a preset category, the attributes of the current edge, as well as the attributes of the two current nodes associated with it, can be written into the joint index to obtain the joint index of the current edge. The following is an explanation of edges of a preset category:

[0063] From the perspective of whether or not they change over time, nodes in a graph database can be divided into static nodes and dynamic nodes, and edges can be divided into dynamic edges and static edges.

[0064] Static nodes do not change over time and can include various types of archival data (personnel files, vehicle files, case files, etc.). Dynamic nodes increase continuously over time and can include various spatiotemporal event data (such as violation times, travel trajectories, etc.).

[0065] Static edges represent relationships between two nodes that are one-to-many, one-to-one, or many-to-many. Static edges do not change over time. Examples of static edges include kinship edges, parent-child edges, and person-vehicle edges (e.g., vehicle owner edges). Dynamic edges represent relationships between two nodes that are many-to-many, and the number of dynamic edges increases over time (the nodes associated with dynamic edges are dynamic nodes). Examples of dynamic edges include person-event edges, vehicle-event edges (e.g., traffic violation edges), and peer-to-peer edges.

[0066] Let's take the mother-child edge and the relative edge as examples to explain static edges. Regarding the mother-child edge, one person has only one mother, but a mother may have multiple children. The mother-child edge represents a one-to-many relationship, and the mother-child edge does not change over time. Therefore, the mother-child edge is a static edge. Regarding the relative edge, although it represents a many-to-many relationship, the relative edge does not change over time. Therefore, the relative edge is a static edge.

[0067] Let's use the "person-event" edge to explain dynamic edges. For dynamic edges, one person may be related to multiple events, and one event may also have multiple related people. Therefore, the person-event edge represents a many-to-many relationship between people and events. Moreover, as the number of people and events increases over time, the number of person-event edges will also increase.

[0068] Considering that when the edge represents a many-to-many relationship between two nodes, the amount of data queried is large, static edges representing many-to-many relationships between two nodes can be used as edges of a preset category. Alternatively, considering that when the edge represents a many-to-many relationship between two nodes and the relationship increases continuously over time, the amount of data queried is large and uncontrollable, dynamic edges can be used as edges of a preset category. Therefore, edges of a preset category can be either static edges representing many-to-many relationships between two nodes or edges representing dynamic relationships (dynamic edges).

[0069] Alternatively, you can write all attributes of the two nodes associated with an edge into the composite index, or you can write only the key attributes of the two nodes associated with the edge. Whether a node attribute is a key attribute depends on the user's query requirements. For example, attributes with sufficiently high query frequency can be designated as key attributes. Therefore, you can create a composite index to meet query requirements while reducing the resources required by the composite index.

[0070] Furthermore, considering that two nodes associated with an edge may have the same attribute name, a prefix can be added to the node attributes for easier differentiation later. The prefix is ​​the corresponding node identifier; the attribute of the node with the added prefix is ​​then written into the composite index. In this application, one of the two nodes associated with an edge will be referred to as the head node, and the other as the tail node.

[0071] Creating a joint index for edges can be done either during the process of writing the edges to the graph database or after writing the edges to the graph database.

[0072] Through the implementation of this embodiment, this application only needs to create a composite index for the edge following the original process of creating a single index for the edge, thus simplifying the creation method. Furthermore, compared to creating a single index, creating a composite index only requires adding the attributes of the two nodes associated with the edge, thus requiring fewer resources. Secondly, when querying data from the graph database based on the composite index, the original query syntax (Gremlin syntax) is still followed, so no additional changes to the query syntax are needed. Additionally, since the composite index includes both the edge's attributes and the attributes of the two nodes associated with the edge, subsequent queries from the graph database based on the composite index do not require traversal and can directly retrieve the data query results.

[0073] In other embodiments, if S12 only creates a joint index for edges of a preset category, the above embodiments can be extended as follows:

[0074] Figure 8 This is a flowchart illustrating another embodiment of the index creation method for the graph database in this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily reflect that outcome. Figure 8 The illustrated process sequence is limited. In this embodiment, S21 is a step that may be included before S12, and S22 to S24 are further extensions of S12. Figure 8 As shown, this embodiment may include:

[0075] S21: Set a joint index identifier for each edge.

[0076] The composite index of edges belonging to the preset category is marked as "true", while the composite index of edges belonging to non-preset categories is marked as "false".

[0077] Examples are provided in Tables 1 and 2 below:

[0078] Table 1

[0079]

[0080] As shown in Table 1, the two nodes associated with the current edge are person and event. person has attributes num, name and sex, and event has attributes num and tag.

[0081] Table 2

[0082]

[0083] As shown in Table 2, the relation represented by the current edge is named hasEwent, and the current edge has the attributes relationAddress and relationTime. Of the two nodes associated with the current edge, person is the head node and event is the tail node. The union index of the current edge is "true".

[0084] S22: Treat each edge as the current edge and determine whether the joint index identifier of the current edge is true.

[0085] If true, then execute S23; otherwise, do not execute S23.

[0086] S23: Write the attributes of the current edge and the attributes of the two current nodes associated with the current edge into the joint index to obtain the joint index of the current edge.

[0087] The following combination Figure 9 This section provides a detailed explanation of creating a joint index for the current edge using a specific example:

[0088] 1) Determine if the composite index identifier of the current edge is true.

[0089] 2) If true, the attributes of the current edge and the attributes of the two current nodes associated with the current edge are written into the composite index to obtain the composite index of the current edge. The composite index is stored in Elasticearch (ES). The current edge is then written to HBase.

[0090] 3) If false, execute the original edge writing process, that is, write the current edge to the graph database / HBase.

[0091] The resulting composite index for the edges shown in Table 2 is as follows:

[0092]

[0093]

[0094] The following describes the application of composite indexes:

[0095] Figure 10 This is a flowchart illustrating an embodiment of the data query method for the graph database in this application. It should be noted that if substantially the same result is obtained, this embodiment does not necessarily reflect that result. Figure 10 The illustrated process sequence is limited. For example... Figure 10 As shown, this embodiment may include:

[0096] S31: Get the query conditions.

[0097] There can be one or more query conditions. Each query condition involves a node or an edge, and different query conditions involve different nodes or edges.

[0098] For example, as mentioned earlier, the target of the query is "a man loitering at the Bank of China". The query conditions include query condition 1 "person, gender: male", query condition 2 "loitering side", and query condition 3 "event, location: Bank of China".

[0099] For example, if the target of the query is "22-year-old female", the query conditions include "person, age: 22 years old, gender: female".

[0100] S32: Find the target composite index from the composite index of the graph database.

[0101] The attributes of the target composite index meet the query conditions. The attributes of the composite index include the attributes of the edge and the attributes of the two nodes associated with the edge.

[0102] Understandably, since a composite index includes the attributes of the edge and the attributes of the two nodes associated with the edge, when the query conditions involve the attributes of the edge, or the attributes of the node, or the attributes of both the edge and the node, the target composite index can be directly found from the composite index of the graph database.

[0103] Using "men lingering at the Bank of China" as an example, we can directly find the target composite index that meets query conditions 1, 2, and 3.

[0104] S33: Use the two target nodes associated with the target edge that has the target joint index as the data query result.

[0105] Through the implementation of this embodiment, the composite index of the graph database in this application includes the attributes of the edges and the attributes of the two nodes associated with the edges. Therefore, when querying data, regardless of whether the query conditions involve edge attributes, node attributes, or both edge and node attributes, the target composite index that meets the query conditions can be directly determined, directly hitting the data query results without traversal. Therefore, it has a wide range of applications and high query efficiency. Furthermore, the data query method provided in this application still follows the original query syntax (Gremlin syntax), requiring no changes to the graph query syntax, thus simplifying implementation.

[0106] The following is a comparison of querying data from a graph database based on existing single indexes and composite indexes:

[0107] The query task is to find the specific attribute "male" in the graph database. The corresponding query conditions include query condition a "person, gender: male", query condition b "specific attribute edge", and query condition c "specific attribute case".

[0108] The query logic for a single-index query based on people is as follows: Iterate through the single index to find people who meet query condition 'a', and then retrieve the people who meet query conditions 'b' and 'c', which are then used as the data query results. An example of a Gremlin query is as follows:

[0109] gV().has('person','sex','male').as('person1')

[0110] .outE('hasEvent').as('hasEvent1')

[0111] .inV().has('event','tag','specific attribute').as('event1')

[0112] .select('person1',hasEvent','event'))

[0113] The query logic based on a composite index is as follows: It directly identifies individuals who meet query conditions a, b, and c, and uses these results as the query outcome. An example of a Gremlin query is shown below:

[0114] gE().has('hasEvent','sex','Male').has('hasEvent','tag','Specific Attribute').as('hasEvent1')

[0115] .outV('event').as('event1')

[0116] .select('hasEvent1').inV('person').as('person1')

[0117] .select('hasEvent1','event1','person1'))

[0118] The above comparison shows that the data query method based on composite indexes in this application has higher query efficiency.

[0119] Figure 11 This is a schematic diagram of the structure of an embodiment of the electronic device of this application. Figure 11 As shown, the electronic device includes a processor 21 and a memory 22 coupled to the processor 21.

[0120] The memory 22 stores program instructions for implementing the methods of any of the above embodiments; the processor 21 executes the program instructions stored in the memory 22 to implement the steps of the above method embodiments. The processor 21 may also be referred to as a CPU (Central Processing Unit). The processor 21 may be an integrated circuit chip with signal processing capabilities. The processor 21 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor may be a microprocessor or any conventional processor.

[0121] Figure 12 Figure 12 is a schematic diagram of the structure of an embodiment of the computer-readable storage medium of this application. As shown in Figure 12, the computer-readable storage medium 30 of this application embodiment stores program instructions 31, which, when executed, implement the methods provided in the above embodiments of this application. The program instructions 31 can form a program file and be stored in the computer-readable storage medium 30 in the form of a software product, so that a computer device (which may be a personal computer, server, or network device, etc.) or processor can execute all or part of the steps of the methods of various embodiments of this application. The aforementioned computer-readable storage medium 30 includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0123] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data query method of a graph database, characterized by, The method comprises the following steps: acquiring a query condition, the query condition being related to at least one of an attribute of an edge and an attribute of a node; finding a target joint index from joint indexes of the graph database, the target joint index being related to the query condition, the joint index being related to an attribute of an edge and attributes of two nodes associated with the edge, the attribute of the node being prefixed with an identifier of the node, the attribute of the edge being one or more, the attribute of the node being one or more; associating the two nodes associated with the target edge with the target joint index with the target edge as a data query result.

2. The method of claim 1, wherein, The method further comprises the following steps of creating the joint index for the edge: creating the joint index; writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index.

3. The method of claim 2, wherein, Before the step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index, the method comprises the following steps: setting a joint index identifier for each of the edges, the joint index identifier of a preset category of edges being true; the step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index comprises the following steps: respectively taking each of the edges as a current edge, determining whether the joint index identifier of the current edge is true; if the joint index identifier of the current edge is true, writing the attribute of the current edge and the attributes of two current nodes associated with the current edge into the joint index to obtain a joint index of the current edge.

4. The method of claim 3, wherein, The preset category of edges represents a dynamic relationship.

5. The method of claim 2, wherein, The step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index comprises the following steps: respectively taking each of the edges as a current edge, sequentially writing the attribute of the current edge and the attributes of two current nodes associated with the current edge into the joint index to obtain a joint index of the current edge.

6. The method of claim 5, wherein, The step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index comprises the following steps: prefixing the attribute of the node with an identifier of the corresponding node; writing the attribute of the node with the prefix into the joint index.

7. An index creation method of a graph database, characterized by, The method comprises the following steps: creating a joint index; writing an attribute of an edge and attributes of two nodes associated with the edge into the joint index, the attribute of the node being prefixed with an identifier of the node, the attribute of the edge being one or more, the attribute of the node being one or more, the joint index supporting a query based on the attribute of the edge, a query based on the attribute of the node, and a query based on the attribute of the edge and the attribute of the node.

8. The method of claim 7, wherein, Before the step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index, the method comprises the following steps: setting a joint index identifier for each of the edges, the joint index identifier of a preset category of edges being true; the step of writing the attribute of the edge and the attributes of the two nodes associated with the edge into the joint index comprises the following steps: respectively taking each of the edges as a current edge, determining whether the joint index identifier of the current edge is true; if the joint index identifier of the current edge is true, writing the attribute of the current edge and the attributes of two current nodes associated with the current edge into the joint index to obtain a joint index of the current edge.

9. The method of claim 8, wherein, The preset category of edges represents dynamic relationships.

10. The method of claim 7, wherein, The writing of the attribute of the edge and the attribute of two nodes associated with the edge into the joint index comprises: Respectively taking each edge as a current edge, sequentially writing the attribute of the current edge and the attribute of two current nodes associated with the current edge into the joint index to obtain a joint index of the current edge.

11. The method of claim 7, wherein, The writing of the attribute of the edge and the attribute of two nodes associated with the edge into the joint index comprises: A prefix is added to the attribute of the node, and the prefix is a corresponding node identifier; The attribute of the node after the prefix is added is written into the joint index.

12. An electronic device, comprising: The device comprises a processor and a memory connected to the processor, wherein The memory stores program instructions; The processor is configured to execute the program instructions stored in the memory to implement the method in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that, The storage medium stores program instructions, and the program instructions are executed to implement the method in any one of claims 1-11.

Images