A Communication Method between the Server and Client of a GQL Graph Database Based on the gRPC Protocol

Abstract

The present application discloses a communication method between the GQL graph database server and the client based on the gRPC protocol, which relates to the technical field of data transmission. It solves the problem in the prior art that when returning the query result to the client, the data conversion overhead, performance overhead, I / O overhead, and memory management overhead caused by converting columnar data to row storage format are relatively large. The method includes: using protobuf to define the communication protocol between the GQL graph database server and the client, the client sends a query request to the GQL graph database server, the GQL graph database server serializes the query result, and the client deserializes it, which not only avoids the high query latency caused by the server's column-to-row conversion, but also reduces the network transmission bytes, improving the overall performance.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to a communication method between the GQL graph database server and the client based on the gRPC protocol. Background Art

[0002] In a graph database system, the communication between the server and the client is a key link for realizing data query and operation. Traditional communication methods usually adopt text protocols or custom binary protocols, and these methods have certain limitations in terms of performance and scalability. As a high-performance and general RPC framework, gRPC can effectively solve these problems, but its application in graph database systems still faces challenges in serialization and deserialization.

[0003] In the GQL graph database NebulaGraph service, data usually adopts a columnar storage format. This format has high efficiency and compressibility in data storage and query, and can provide better performance. However, when the query results need to be returned to the client, it is usually necessary to convert the columnar storage data into a row-based storage format, which incurs several performance overheads:

[0004] 1. Data conversion overhead

[0005] Columnar storage data is stored by column, while the client usually expects row-based storage data. Therefore, before returning the query results, it is necessary to convert the columnar storage data into row-based storage data. This conversion process involves the following steps:

[0006] Column data reorganization: Reorganize the data stored by column into data stored by row.

[0007] Data decompression: Columnar storage data is usually compressed, and the data needs to be decompressed during the conversion process.

[0008] Data serialization: Serialize the reorganized row-based storage data into a format acceptable to the client (such as JSON, CSV, etc.).

[0009] 2. Performance overhead

[0010] CPU overhead: The data reorganization and decompression processes require a large amount of CPU computing resources.

[0011] Memory overhead: During the conversion process, it is necessary to temporarily store the reorganized row-based storage data, occupying a large amount of memory.

[0012] Time overhead: The data conversion process takes a long time, increasing the query response time.

[0013] 3. I / O overhead

[0014] Converting the columnar storage format to row storage leads to an increase in data volume, and network transmission latency and bandwidth limitations increase the data transmission time.

[0015] 4. Memory management overhead

[0016] Memory allocation and deallocation: During the data conversion process, memory needs to be dynamically allocated and deallocated to store temporary data. During data reorganization and serialization, memory needs to be dynamically allocated. After the conversion is completed, the temporarily allocated memory needs to be released. Summary of the Invention

[0017] The purpose of this application is to overcome the problems of large data conversion overhead, performance overhead, I / O overhead, and memory management overhead caused by converting columnar storage data to row storage format when returning query results to the client in the prior art, and to provide a communication method between the GQL graph database server and the client based on the gRPC protocol.

[0018] In the first aspect, a communication method between the GQL graph database server and the client based on the gRPC protocol is provided. The communication protocol between the GQL graph database server and the client is defined using protobuf. The communication method between the GQL graph database server and the client includes:

[0019] Obtain the query request of the client, and serialize the query result into binary data. Among them, when serializing, the columnar storage in memory is directly serialized;

[0020] Return the binary data to the client through the gRPC protocol, so that the client can restore the data structure of the GQL graph database by deserializing and parsing the binary data.

[0021] In some possible implementation manners, during the process of serializing the query result into binary data, a null bitmap is used to mark null values. When storing in columnar storage, if a certain data is null, the null data can be skipped and the next non-null data can be directly stored. When the client parses the data of a certain column, first judge whether the data at the current index position is null through the nullbitmap. If it is non-null, read the bytecode for parsing. If it is null, directly return the null data, avoiding parsing for null data.

[0022] In some possible implementation manners, before returning the binary data to the client through the gRPC protocol, the binary data is compressed using a compression algorithm. By compressing the transmitted binary data, the amount of data transmitted over the network is reduced.

[0023] Second aspect, a communication method between a client based on the gRPC protocol and a GQL graph database server, using protobuf to define the communication protocol between the GQL graph database server and the client. The communication method between the client and the GQL graph database server includes:

[0024] Sending a query request to the GQL graph database server to obtain a query result serialized as binary data, where the binary data is columnar stored;

[0025] Restoring the data structure of the GQL graph database by deserializing and parsing the binary data.

[0026] In some possible implementation manners, after receiving the binary data, the binary data is parsed according to the null bitmap to restore the data structure of the GQL graph database.

[0027] In some possible implementation manners, during deserialization and parsing, it is determined whether the currently deserialized vector is a constant vector. If it is a constant vector, the data of the constant vector is cached after the first deserialization of the constant vector. Subsequently, each time the constant vector is deserialized and parsed, the data of the constant vector is directly obtained from the cache. A constant vector is a special columnar storage format used to represent the situation where all values in a certain column are the same. It optimizes storage and transmission by storing a constant value and the number of rows. Since the constant vector stores only one value, it can significantly reduce the memory and network transmission overhead. In the GQL graph database, the combination of constant vectors and flat vectors can efficiently represent and store data, improving system performance.

[0028] In some possible implementation manners, the binary data includes node data, edge data, and path data. Different deserialization and parsing methods are used for the node data, edge data, and path data, specifically including:

[0029] Deserializing and parsing the node data includes: in the little-endian mode, parsing the node ID, node type ID, graph ID, and the number of node attributes from the fixed fields of the binary data. According to the number of node attributes, the node attribute names, node attribute types, and node attribute values are cyclically parsed, and the node attribute names, node attribute types, and node attribute values are stored in the node attribute Map. The graph ID, node type ID, node ID, node attribute Map, and the metadata information of the graph (i.e., graphSchema, graphSchema stores the mapping of the point type name and point type ID in the graph, the mapping of the edge type name and edge type ID, the mapping of the graph name and graph ID. The points, edges, and graphs deserialized by the client from the binary data are all IDs, and these IDs can be mapped to the corresponding names according to graphSchema) are encapsulated and returned;

[0030] Deserializing and parsing the edge data includes: in the little-endian mode, parsing the source node ID, target node ID, edge Rank, graph ID, edge type ID, and number of edge attributes from the fixed fields of the binary data, cyclically parsing the edge attribute name, edge attribute type, and edge attribute value according to the number of edge attributes, storing the edge attribute name, edge attribute type, and edge attribute value into an edge attribute Map, and encapsulating and returning the graph ID, edge type ID, edge Rank, source node ID, target node ID, edge attribute Map, and graph metadata information (i.e., graphSchema).

[0031] Deserializing and parsing the path data includes: parsing the number of elements on the path from the binary data, where the elements include nodes and edges, cyclically parsing the node data and edge data in the binary data to obtain the element type and the corresponding element value, and storing the element type and the corresponding element value into an element list and returning it.

[0032] In some possible implementation manners, the binary data is deserialized and parsed in an iterative parsing manner. The user obtains query results from the client in an iterative manner, getting one row each time. When the user obtains a certain row of data, the client performs deserialization and parsing on this row of data. When the user does not need all the data, the extra deserialization and parsing overhead can be effectively avoided, thereby improving the efficiency of client data processing.

[0033] In a third aspect, a computer-readable storage medium is provided. The computer-readable medium stores program code for a device to execute, and the program code includes steps for executing the method in any one of the implementation manners in the first aspect and the second aspect as described above.

[0034] In a fourth aspect, an electronic device is provided. The electronic device includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, the method in any one of the implementation manners in the first aspect and the second aspect as described above is implemented.

[0035] The present application has the following beneficial effects: The GQL graph database server and client communication method of the present application defines the communication protocol between the GQL graph database server and the client using protobuf, supports the data structures unique to the graph database, improves the expressiveness and scalability of the protocol. Secondly, when serializing, the column store in memory is directly serialized, reducing the time overhead of serialization and deserialization and improving the data transmission efficiency. By defining an efficient communication protocol and serialization / deserialization method, high-performance and highly reliable data communication between the GQL graph database server and the client is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings, which form a part of this application, are used to provide a further understanding of this application. The schematic embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings required for the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0038] Figure 1 is a flowchart of the communication method between the GQL graph database server and the client based on the gRPC protocol in Embodiment 1 of this application;

[0039] Figure 2 is a flowchart of the communication method between the client and the GQL graph database server based on the gRPC protocol in Embodiment 2 of this application;

[0040] Figure 3 is a schematic internal structure diagram of the electronic device in Embodiment 4 of this application. Detailed implementation manners

[0041] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.

[0042] Embodiment 1

[0043] As Figure 1 shown, a communication method between the GQL graph database server and the client based on the gRPC protocol in Embodiment 1 of this application includes the following steps:

[0044] First, the protocol needs to be defined: Use Protocol Buffers (i.e., protobuf) to define the communication protocol between the server and the client, including the message formats of requests and responses.

[0045] Exemplarily, the serialization process:

[0046] S1. Set the version identifier: Fill in the data_layout_version field to mark the data layout version (such as v1.0).

[0047] S2. Construct the metadata object VectorTableMetaData:

[0048] Define the types of VectorTable, including flat vectors and constant vectors, etc.;

[0049] Calculate the total number of data records num_records included in the current query result;

[0050] Specify the data type table_type of the data in the current query result, such as: node data, edge data, and path data;

[0051] Determine how many batch quantities num_batches are included in the current query result;

[0052] Set the time_zone_offset and endianness is_little_endian;

[0053] Associate the graph schema (defining attributes, node / edge types, etc.);

[0054] Slice the data into multiple VectorBatches by a fixed size or logical unit;

[0055] Each batch corresponds to a VectorBatch, which contains multiple NestedVectors (columns or nested columns).

[0056] S3. Construct the nested vector NestedVector. The nested vector NestedVector includes setting how many vectors are included in the current vector (corresponding to how many columns in the data), common metadata of sub-vectors (such as data type, length), special metadata of the vector, binary data storing the result data in the vector, null value bitmap, and a set of sub-vectors.

[0057] S4. Serialization and storage:

[0058] Serialize all VectorBatches into a binary stream in sequence;

[0059] Write the complete VectorResultTable to a file or for network transmission.

[0060] During serialization, construct the VectorResultTable from the top layer, fill in the metadata, and then process the data in batches. Each batch contains a nested vector structure, and at the same time, process the null value bitmap. When deserializing, it is the opposite. First, parse the top-level structure, then unpack the metadata and actual data layer by layer, and process the null value bitmap to determine the position of valid data.

[0061] S101. The GQL graph database server obtains a query request from the client and serializes the query result into binary data. Specifically, during serialization, the column store in memory is directly serialized.

[0062] Specifically, the GQL graph database server serializes the query result into binary data in column store format and uses a null bitmap (i.e., nullbitmap) to mark null values. That is, when storing data in column store, if a certain data is null, the null data can be skipped directly to store the next non-null data. When the client parses the data of a certain column, it first determines whether the data at the current index position is null through the nullbitmap. If it is non-null, it reads the bytecode for parsing. If it is null, it can directly return null data, avoiding the parsing of null data.

[0063] Secondly, in column store, data is stored using constant vectors and flat vectors respectively. A flat vector is a columnar storage data structure where the values of each column are stored independently. It is suitable for storing column data with different values and is usually used to represent multiple rows of data in a query result. When storing multiple rows of data, it occupies a large amount of memory. A constant vector is a special columnar storage format used to represent the case where all values in a certain column are the same. It optimizes storage and transmission by storing a constant value and the number of rows.

[0064] In this embodiment, since the constant vector stores only one value, it can significantly reduce the overhead of memory and network transmission. In a graph database, the combination of constant vectors and flat vectors can efficiently represent and store data, improving system performance.

[0065] It should be noted that usually when communicating between the server and the client, the data to be transmitted needs to be converted into the format and data type defined in the communication protocol. Since the data stored by the GQL graph database server is columnar storage, it is necessary to copy the original columnar storage data into the defined Row and Value results respectively, and then serialize the data. This process requires multiple copies of the data in memory.

[0066] In this embodiment, during serialization, the column store in memory is directly serialized, avoiding the operation of converting the data structure in the middle. Therefore, zero-copy can be achieved, avoiding multiple copies of data in memory, directly transmitting data between memory and network, reducing memory overhead and CPU occupancy, and at the same time balancing the ease of use of client deserialization. Only the data storing memory addresses is copied, facilitating the client to directly read the data binary for deserialization. For example, for some data structures such as String strings, since the GQL graph database server accesses data through a link address during use, in order to facilitate the client to directly obtain the data without refreshing the address, the String type is copied, copied into a column of String type and then serialized into binary data.

[0067] S102. The GQL graph database server returns the binary data in step S101 to the client through the gRPC protocol, so that the client can deserialize the binary data to parse and restore the data structure of the GQL graph database for the client to use.

[0068] In a further embodiment, to improve the efficiency of data transmission and reduce network latency, the binary data to be returned to the client is compressed by a communication protocol compression algorithm such as Deflate or Gzip to reduce the transmitted binary packets, thereby optimizing the efficiency of data transmission and reducing network latency.

[0069] Exemplarily, compressing the binary data includes: creating a Deflater object for data compression, inputting the data to be compressed, starting compression after the data input is completed, defining a byte array compressedData to store the compressed data, writing the compressed data into the byte array compressedData, and releasing the resources after compression is completed to obtain the compressed data.

[0070] In this embodiment, a data protocol format for gRPC communication transmission is proposed. The GQL graph database server directly serializes the columnar data, and the client deserializes it. This not only avoids the high query latency caused by the column-to-row conversion on the GQL graph database server but also reduces the data conversion overhead, performance overhead, I / O overhead, and memory management overhead, reduces the network transmission bytes, improves the overall performance. By using protobuf to define the communication protocol between the GQL graph database server and the client, it supports the unique data structure of the graph database, improves the expressiveness and scalability of the protocol. Secondly, when serializing, the GQL graph database server directly serializes the columnar data in memory, reducing the serialization time overhead and improving the data transmission efficiency. By defining an efficient communication protocol and serialization / deserialization method, high-performance and highly reliable data communication between the GQL graph database server and the client is achieved.

[0071] Embodiment 2

[0072] As Figure 2 shown, a method for a client to communicate with a GQL graph database server based on the gRPC protocol according to Embodiment 2 of the present application includes the following steps:

[0073] Similarly, the protocol needs to be defined first: Use Protocol Buffers (protobuf) to define the communication protocol between the server and the client, including the message formats of requests and responses. The serialization and deserialization processes are the same as those in Embodiment 1. To avoid redundancy, they will not be elaborated here.

[0074] S201. The client sends a query request to the GQL graph database server to obtain a query result serialized as binary data, where the binary data is columnar.

[0075] Specifically, in the GQL graph database server, the query result is serialized into binary data in columnar format, and a null bitmap (i.e., nullbitmap) is used to mark null values. When the client parses the data of a certain column, it first determines whether the data at the current index position is null through the nullbitmap. If it is not null, it reads the bytecode for parsing; if it is null, it directly returns null data, avoiding the parsing of null data, thus saving the parsing time of the client.

[0076] S202. The client deserializes the binary data obtained in step S101, so as to be able to parse and restore the data structure of the GQL graph database for the client to use.

[0077] Specifically, after receiving the binary data, the client parses the data according to the nullbitmap and restores it to the data structure of the graph database. The specific implementation is as follows:

[0078] / / Parse the data of the specified field

[0079] public Object decodeValue(VectorWrapper vector,

[0080] DataType type,

[0081] int rowIndex) {

[0082] / / If the data of the specified field is empty, directly return null.

[0083] if (!vector.isNullAllSet() &&!vector.getNullBitMap().toString(charset).isEmpty()) {

[0084] int byteIndex = rowIndex / 8;

[0085] int bitIndex = rowIndex % 8;

[0086] if ((vector.getNullBitMap().byteAt(byteIndex) & kOneBitmasks[bitIndex]) == 0) {

[0087] return null;

[0088] }

[0089] }。

[0090] Next, the client deserializes according to the type of the vector. When parsing the data, the client determines that if the currently deserialized vector is a constant vector, it caches the data after the first deserialization of the vector, and directly takes the data in the cache each time the data is obtained, avoiding repeated deserialization and saving the deserialization time of the client.

[0091] In this embodiment, there are different parsing methods for different data types. If the data of the specified field is not empty, different deserialization and parsing methods are performed according to the data type of the data. For the GQL graph database, the parsing structures with specializations are node data, edge data, and path data. The following are the deserialization and parsing methods for the three types of data:

[0092] Deserializing node data:

[0093] / / Node data

[0094] case COLUMN_TYPE_NODE:

[0095] / / The binary data is represented as: 8-byte node ID, 4-byte graph ID, and 2-byte number of attributes. All the following parsing is in little-endian mode

[0096] / / Parse the node ID from the vector binary data

[0097] long nodeId = bytesToInt64(reader.read(NODE_ID_SIZE), byteOrder);

[0098] / / Take the high 16 bits from the node ID as the ID of the node type

[0099] int nodeTypeId = getNodeTypeIdFromNodeId(nodeId);

[0100] / / Parse the graph ID of the node from the vector binary data

[0101] int nodeGraphId = bytesToInt32(reader.read(GRAPH_ID_SIZE), byteOrder);

[0102] / / Parse the number of node attributes from the vector binary data

[0103] int nodePropNum = bytesToInt16(

[0104] reader.read(ELEMENT_NUMBER_SIZE_FOR_ANY_VALUE), byteOrder);

[0105] Map<String, ValueWrapper> nodeProperties = newHashMap<>();

[0106] / / Loop to parse the attribute data according to the number of attributes

[0107] for (int i = 0; i < nodePropNum; i++) {

[0108] / / Parse the attribute name

[0109] String propName = reader.readSizedString(byteOrder);

[0110] / / Get the property data type

[0111] ColumnType propType = ColumnType.getColumnType(

[0112] bytesToUInt8(reader.read(VALUE_TYPE_SIZE)));

[0113] / / Parse the property data

[0114] Object propValue = decodeCompositeValue(reader,propType);

[0115] nodeProperties.put(propName, new ValueWrapper(propValue, propType));

[0116] }

[0117] / / Return the node structure

[0118] return new Node(nodeGraphId, nodeTypeId, nodeId,nodeProperties, graphSchemas);

[0119] Deserialize edge data:

[0120] / / Edge data

[0121] case COLUMN_TYPE_EDGE:

[0122] / / The binary data representation is: 8-byte source node ID, 8-byte target node ID, 8-byte edge rank, 4-byte graph ID, 4-byte edge type ID, 2-byte number of properties. The following parsing is in little-endian mode

[0123] / / Parse the source node ID from the vector binary data

[0124] long srcNodeId = bytesToInt64(reader.read(NODE_ID_SIZE), byteOrder);

[0125] / / Parse the target node ID from the vector binary data

[0126] long dstNodeId = bytesToInt64(reader.read(NODE_ID_SIZE), byteOrder);

[0127] / / Parse the rank of the edge from the vector binary data

[0128] long rank = bytesToInt64(reader.read(RANK_SIZE),byteOrder);

[0129] / / Parse the graph ID from the vector binary data

[0130] int edgeGraphId = bytesToInt32(reader.read(GRAPH_ID_SIZE), byteOrder);

[0131] / / Parse the edge type ID from the vector binary data

[0132] int edgeTypeId = bytesToInt32(reader.read(EDGE_TYPE_ID_SIZE), byteOrder);

[0133] / / Parse the number of edge properties from the vector binary data

[0134] int edgePropNum = bytesToInt16(

[0135] reader.read(ELEMENT_NUMBER_SIZE_FOR_ANY_VALUE), byteOrder);

[0136] Map<String, ValueWrapper> edgeProperties = newHashMap<>();

[0137] / / Loop to parse the property data according to the number of properties

[0138] for (int i = 0; i < edgePropNum; i++) {

[0139] / / Parse property name

[0140] String propName = reader.readSizedString(byteOrder);

[0141] / / Get property data type

[0142] ColumnType propType = ColumnType.getColumnType(

[0143] bytesToUInt8(reader.read(VALUE_TYPE_SIZE)));

[0144] Object propValue = decodeCompositeValue(reader,propType);

[0145] / / Parse property data

[0146] edgeProperties.put(propName, new ValueWrapper(propValue, propType));

[0147] }

[0148] / / Return edge structure

[0149] return new Edge(edgeGraphId,

[0150] edgeTypeId,

[0151] rank,

[0152] srcNodeId,

[0153] dstNodeId,

[0154] edgeProperties,

[0155] graphSchemas);

[0156] Deserialize path data:

[0157] / / Path data

[0158] case COLUMN_TYPE_PATH:

[0159] / / Parse the number of elements on the path from the vector binary data (i.e., how many points and edges does this path include)

[0160] int elementNum = bytesToInt16(

[0161] reader.read(ELEMENT_NUMBER_SIZE_FOR_ANY_VALUE), byteOrder);

[0162] List <valuewrapper>eleValues = new ArrayList<>();

[0163] / / Loop to parse the point-edge data in the binary data

[0164] for (int i = 0; i < elementNum; i++) {

[0165] ColumnType elementType = ColumnType.getColumnType(

[0166] bytesToUInt8(reader.read(VALUE_TYPE_SIZE)));

[0167] Object element = decodeCompositeValue(reader,elementType);

[0168] eleValues.add(new ValueWrapper(element,elementType));

[0169] }

[0170] / / Return the path structure, which contains a list of elements composed of point-edge Values

[0171] return new Path(eleValues);

[0172] To reduce the deserialization overhead, the user obtains the query results from the client iteratively, getting one row at a time. When the user retrieves a row of data, the client deserializes the data for that row. When the user does not need all the data, it can effectively avoid the additional deserialization overhead and improve the efficiency of client data processing.

[0173] In this embodiment, a data protocol format for grpc communication transmission is proposed. The GQL graph database server directly serializes the columnar data, and the client deserializes it. This not only avoids the high query latency caused by the column-to-row conversion on the GQL graph database server, but also reduces the data conversion overhead, performance overhead, I / O overhead, and memory management overhead, reduces the network transmission bytes, improves the overall performance. By using protobuf to define the communication protocol between the GQL graph database server and the client, it supports the data structures unique to the graph database, improves the expressiveness and scalability of the protocol. Secondly, when serializing, the columnar data in memory is directly serialized, reducing the time overhead of client deserialization and improving the efficiency of data transmission. By defining an efficient communication protocol and serialization / deserialization method, high-performance and highly reliable data communication between the client and the GQL graph database server is achieved.

[0174] Embodiment 3

[0175] A computer-readable storage medium related to Embodiment 3 of the present application. The computer-readable medium stores program code for a device to execute, and the program code includes steps for executing the method in any one of the implementation manners in Embodiment 1 of the present application;

[0176] Among them, the computer-readable storage medium can be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM); the computer-readable storage medium can store program code. When the program stored in the computer-readable storage medium is executed by a processor, the processor is used to execute the steps of the method in any one of the implementation manners in Embodiment 1 of the present application.

[0177] Embodiment 4

[0178] As Figure 3 shown, an electronic device related to Embodiment 4 of the present application. The electronic device includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, it implements the method in any one of the implementation manners in Embodiments 1 and 2 of the present application;

[0179] Among them, the processor may adopt a general - purpose central processing unit (CPU), a microprocessor, an application - specific integrated circuit (ASIC), a graphics processing unit (GPU), or one or more integrated circuits to execute relevant programs to implement the methods in any of the implementation manners in Embodiment 1 and Embodiment 2 of the present application.

[0180] The processor may also be an integrated - circuit electronic device with the ability to process signals. During the implementation process, each step of the methods in any of the implementation manners in Embodiment 1 and Embodiment 2 of the present application may be completed by the integrated logic circuit in the hardware of the processor or the instructions in software form.

[0181] The above - mentioned processor may also be a general - purpose processor, a digital signal processor, an application - specific integrated circuit (ASIC), a field - programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general - purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the methods disclosed in combination with the embodiments of the present application may be directly embodied as being completed by the hardware decoding processor, or completed by a combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random - access memory, a flash memory, a read - only memory, a programmable read - only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the functions required to be executed by the units included in the data - processing device of the present application, or execute the methods in any of the implementation manners in Embodiment 1 and Embodiment 2 of the present application.

[0182] The above is only a preferred specific implementation manner of the present application; however, the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application, according to the technical solution of the present application and its improved concept, makes equivalent substitution or change, and should be covered by the protection scope of the present application.< / valuewrapper>

Claims

1. A communication method between the GQL graph database server and the client based on the gRPC protocol, characterized in that, Use protobuf to define the communication protocol between the GQL graph database server and the client. The communication method between the GQL graph database server and the client includes: Obtain the query request from the client and serialize the query result into binary data. Specifically, during serialization, directly serialize the column store in memory; Return the binary data to the client through the gRPC protocol, so that the client can restore the data structure of the GQL graph database by deserializing and parsing the binary data.

2. The communication method between the GQL graph database server and the client based on the gRPC protocol according to claim 1, characterized in that During the process of serializing the query result into binary data, use a null bitmap to mark null values.

3. The communication method between the GQL graph database server and the client based on the gRPC protocol according to claim 1 or 2, characterized in that, Before returning the binary data to the client through the gRPC protocol, compress the binary data using a compression algorithm.

4. A communication method between a client based on the gRPC protocol and a GQL graph database server, characterized in that, Use protobuf to define the communication protocol between the GQL graph database server and the client. The communication method between the client and the GQL graph database server includes: Send a query request to the GQL graph database server to obtain the query result serialized into binary data, where the binary data is columnar; Restore the data structure of the GQL graph database by deserializing and parsing the binary data.

5. The method for communication between a client based on the gRPC protocol and a GQL graph database server according to claim 4, characterized in that, After receiving the binary data, parse the binary data according to the null bitmap to restore the data structure of the GQL graph database.

6. The method for a client based on the gRPC protocol to communicate with a GQL graph database server according to claim 4 or 5, characterized in that, During deserialization and parsing, determine whether the currently deserialized vector is a constant vector. If it is a constant vector, cache the data of the constant vector after the first deserialization of the constant vector, and directly obtain the data of the constant vector from the cache every time the constant vector is deserialized and parsed subsequently.

7. The method for a client based on the gRPC protocol to communicate with a GQL graph database server according to claim 4, characterized in that, The binary data includes node data, edge data, and path data. Different deserialization and parsing methods are used for node data, edge data, and path data, specifically including: The deserialization and parsing of node data includes: in little-endian mode, parse the node ID, node type ID, graph ID, and the number of node attributes from the fixed fields of the binary data. According to the number of node attributes, loop to parse the node attribute name, node attribute type, and node attribute value, store the node attribute name, node attribute type, and node attribute value into the node attribute Map, and encapsulate and return the graph ID, node type ID, node ID, node attribute Map, and the metadata information of the graph; The deserialization and parsing of edge data includes: in little-endian mode, parse the source node ID, target node ID, edge rank, graph ID, edge type ID, and the number of edge attributes from the fixed fields of the binary data. According to the number of edge attributes, loop to parse the edge attribute name, edge attribute type, and edge attribute value, store the edge attribute name, edge attribute type, and edge attribute value into the edge attribute Map, and encapsulate and return the graph ID, edge type ID, edge rank, source node ID, target node ID, edge attribute Map, and the metadata information of the graph; Deserializing and parsing the path data includes: parsing the number of elements on the path from the binary data, where the elements include nodes and edges, iteratively parsing the node data and edge data in the binary data to obtain the element type and the corresponding element value, storing the element type and the corresponding element value in an element list, and returning it.

8. The method for a client based on the gRPC protocol to communicate with a GQL graph database server according to any one of claims 4, 5, and 7, characterized in that, The binary data is deserialized and parsed by means of iterative parsing.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code for a device to execute, and the program code includes steps for executing the method according to any one of claims 1-8.

10. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, the method according to any one of claims 1-8 is implemented.

Images