Oct 13, 2018 - 10 minute read - Comments - misc

Tips for Working With Graphson and Tinkerpop Systems


If you are working with the Apache TinkerPopTM framework for graph computing, you might want to produce, edit, and save graphs, or parts of graphs, outside the graph database. To accomplish this, you might want a standardized format for a graph representation that is both machine- and human-readable. You might want features for easily moving between that format and the graph database itself. You might want to consider using GraphSON.

GraphSON is a JSON-based representation for graphs. It is especially useful to store graphs that are going to be used with TinkerPopTM systems, because Gremlin (the query language for TinkerPopTM graphs) has a GraphSON Reader/Writer that can be used for bulk upload and download in the Gremlin console. Gremlin also has a Reader/Writer for GraphML (XML-based) and Gryo (Kryo-based).

Unfortunately, I could not find any sort of standardized documentation for GraphSON, so I decided to compile a summary of my research into a single document that would help answer all the questions I had when I started working with it.

グラフ計算用にApache TinkerPopTMフレームワークを使用している場合は、グラフデータベースの外にグラフやグラフの一部を生成、編集、保存することができます。これを達成するには、機械表現と人間が読める形式の両方のグラフ表現のための標準化されたフォーマットが必要な場合があります。その形式とグラフデータベース自体を簡単に移動するための機能が必要な場合があります。 GraphSONの使用を検討することをお勧めします。

GraphSONは、グラフのJSONベースの表現です。 Gremlin(TinkerPopTMグラフのクエリ言語)には、Gremlinコンソールでの一括アップロードとダウンロードに使用できるGraphSON Reader / Writerがあるため、TinkerPopTMシステムで使用するグラフを保存すると特に便利です。 GremlinにはGraphML(XMLベース)とGryo(Kryoベース)用のリーダ/ライタもあります。


When to Use GraphSON

The advantages of GraphSON are that it is the most human-readable option of the three supported Gremlin I/O formats (i.e. GraphSON, GraphML and Gryo), JSON is widely used, and there is some support for it from graph-related applications outside of TinkerPopTM. The disadvantage is that it is verbose and has some redundancy, and is therefore not very memory efficient, so it may not be the best choice when storage is a limiting factor.

The TinkerPopTM documentation advises that it is generally best used in two cases:

A text format of the graph or its elements is desired (e.g. debugging, usage in source control, etc.) The graph or its elements need to be consumed by code that is not JVM-based (e.g. JavaScript, Python, .NET, etc.)

GraphSONの利点は、サポートされている3つのGremlin I/O フォーマット(GraphSON、GraphML、Gryo)の中で最も人間が読めるオプションであり、JSONが広く使われており、グラフ関連のアプリケーション TinkerPopTMの 欠点は、冗長で冗長性があるため、メモリ効率があまり高くないため、ストレージが制限要因である場合には最適な選択ではない可能性があります。


グラフまたはその要素のテキストフォーマットが望ましい(例えば、デバッグ、ソース管理における使用など) グラフまたはその要素は、JVMベースではないコード(JavaScript、Python、.NETなど)によって消費される必要があります。

Formatting GraphSON

The documentation of the Gremlin GraphSON Reader/Writer mentions nothing about the requirements for formatting GraphSON in a way that is readable to it; the resources outside of TinkerPopTM that reference GraphSON (usually in connection to a specific DB, like Titan) have examples, but they are sometimes incompatible with the TinkerPopTM/Gremlin Console built-in reader. The only example of GraphSON in the documentation is a single vertex, not a graph, but the download of the Gremlin Console includes four examples of GraphSON files (in fact, these four graphs are described in all of the different file formats for which Gremlin has a Reader/Writer). From these four examples, I have deduced the following rules and conventions, which I have been able to apply successfully to making my own graphs that can be parsed by the Reader:

Gremlin GraphSON Reader/Writerのドキュメントには、GraphSONを読みやすい形でフォーマットするための要件については何も言及されていません。 GraphSONを参照するTinkerPopTMの外のリソース(通常はTitanのような特定のDBに接続している)には例がありますが、時にはTinkerPop/Gremlin Console組み込みリーダーと互換性がありません。 ドキュメント内のGraphSONの唯一の例は、グラフではなく単一の頂点ですが、Gremlin ConsoleのダウンロードにはGraphSONファイルの4つの例が含まれています(実際、これらの4つのグラフはGremlinが持つさまざまなファイル形式 リーダー/ライター)。 これらの4つの例から、Readerが解析できる独自のグラフを作成するのに成功した以下のルールと慣習を導き出しました。

Vertex Rules and Conventions

  • The file consists of a list of vertices, where each vertex is a dictionary that maps property names to property values, or sub-dictionaries with property values. Each line of the file contains exactly one vertex. The vertices are listed in order of unique ID, which, by convention, starts at 1 and increases sequentially.
  • Each vertex has the following structure:
{"id":int, "label":"", "inE":{"edge_label1":[{edge}, {edge}, ...], "edge_label2":[{edge}, {edge}, ...]}, "outE":{"edge_label1":[{edge}, {edge}, ...], "edge_label2":[{edge}, {edge}, ...]}, "properties":{}}
  • “id” maps to a unique integer id (starting at 1, by convention, and increasing sequentially)

  • “label” maps to a string that represents the label associated with that vertex (think of this being like the vertex’s type, e.g. “person”)

  • “inE” and “outE” map to dictionaries that map the label (again, think type, e.g. “knows” may be a label between two people) of an edge to a list of edges of that type that involve the vertex of which these are sub-dictionaries. “inE” and “outE” encode directionality of the edges as the names suggest (“inE” contains the edges that terminate at the vertex, “outE” contains the edges that originate at the vertex). If a vertex has only one type of edge associated with it (e.g. only in edges), then the other key-value pair (e.g. “outE”:{}) may be omitted from this vertex.

  • “properties” maps to a dictionary where the keys are the labels of the properties and the values are dictionaries that contain the key “id” mapping to an integer ID for that property value (used for indexing) and the key “value” mapping to a value for that property. Every property value needs to have an ID (separate from the IDs for vertices and edges, these can start at 0), otherwise an error will occur in the GraphSON reader (“Error: property value cannot be null”). Example: “properties”:{“name”:{“id”: 0, “value”:“marko”}, “age”:{“id”:1, “value”:29}}. The IDs are unique, and by convention, start at 0 and increase sequentially.

  • ファイルは、頂点のリストで構成されます。各頂点は、プロパティ名をプロパティ値にマップするディクショナリ、またはプロパティ値を含むサブディクショナリです。ファイルの各行に正確に1つの頂点が含まれています。頂点は一意のIDの順に並べられ、慣習的には1から順に増加します。

  • 各頂点は次の構造を持ちます:

{{end_label1}:{{edge}、{edge}、...}、 "edge_label2":[{edge}、{edge}、{edge} ...]}、[outE]:{"edge_label1":[{edge}、{edge}、...]、 "edge_label2":[{edge}、{edge} ":{}}
  • “id"は一意の整数IDにマッピングされます(慣例により1から始まり、順次増加します)
  • “label"は、その頂点に関連付けられたラベルを表す文字列にマップします(これは、頂点のタイプと同じであるとみなします(例: “person”)。
  • “inE"と “outE"は、ラベルをマップする辞書にマップします(もう一度考えてみましょう、タイプは「2つの人の間のラベル」かもしれません)。これらの頂点を含むそのタイプの辺のリストサブディクショナリです。 “inE"と “outE"は、名前が示唆するようにエッジの方向性を符号化する( “inE"は頂点で終わるエッジを含み、 “outE"は頂点で始まるエッジを含む)。頂点がそれに関連する1つのタイプのエッジのみを有する場合(例えば、エッジ内のみ)、この頂点から他のキー - 値ペア(例えば、「outE」:{})を省略することができる。
  • 「プロパティ」は、キーがプロパティのラベルであり、値がそのプロパティ値(インデックスに使用される)の整数IDへのキー「id」マッピングとキー「値」マッピングを含むディクショナリにマップされますそのプロパティの値すべてのプロパティ値はIDを持たなければなりません(頂点とエッジのIDとは別に0から始めることができます)。そうしないと、GraphSONリーダーでエラーが発生します( “エラー:プロパティ値はnullにできません”)。例: “properties”:{“name”:{“id”:0、 “value”: “marko”}、 “age”:{“id”:1、 “value”:29}} IDは一意であり、慣習的には0から始まり順次増加します。

Edge Rules and Conventions

  • Edges have the following structure:
{"id":int, "outV": int, "inV": int, "properties":{"property_name":value}}
  • “id” maps to a unique integer ID. By convention, the edge IDs start immediately after the greatest vertex ID and increase sequentially, so if a graph has 6 vertices and 6 edges, the vertex IDs would be 1-6 and the edge IDs would be 7-12.

  • “inV” and “outV” map to the vertex IDs on each side of the edge. “outV” maps to the ID of the vertex from which the edge originates and “inV” maps to the ID of the vertex at which the edge terminates. For example, the edge 1-knows->2 would look like this: {“outV”:1, “inV”:2, “properties”:{}}. Since in a GraphSON format, the edges are all listed as a property of vertices, and nowhere else, one of “outV” or “inV” is already implicit based on whether it is in the list mapped to by “inE” or “outE” and the ID of the vertex on that line, and, thus, may be omitted. For example, with the edge described above, in the dictionary that describes vertex 1, the edge would be present in the list of edges mapped to by “outE”, so “outV”:1 is implicit and may be omitted. It need not be omitted though, and is convenient to leave in some cases.

  • “properties” maps to a dictionary which maps the label of a property to its value. For example, properties:{“weight”:0.5}. These properties are not indexed, and each edge has only one property associated to it.

  • Because of the redundancy of encoding the same edge in both the “outE” field of the vertex from which it emanates and in the “inE” field of the vertex at which it terminates, each edge will appear twice in the GraphSON format; the two instances of the edge should be identical, since both instances represent the same edge.

  • エッジの構造は次のとおりです。

{"id":int、 "outV":int、 "inV":int、 "プロパティ":{"property_name":value}}
  • “id"は固有の整数IDにマップされます。慣例により、エッジIDは最大の頂点IDの直後に始まり、順番に増加するので、グラフが6つの頂点と6つのエッジを有する場合、頂点IDは1〜6であり、エッジIDは7〜12である。
  • “inV"と “outV"は、エッジの両側の頂点IDにマップされます。 「outV」は、エッジが始まる頂点のIDにマップされ、「inV」は、エッジが終了する頂点のIDにマップされる。例えば、1-knows-> 2の辺は{“outV”:1、 “inV”:2、 “properties”:{}}のようになります。 GraphSON形式では、エッジはすべて頂点のプロパティとしてリストされています。それ以外の場所では、「inE」または「outE」によってマップされたリスト内にあるかどうかに基づいて、「outV」または「inV」のいずれかが既に暗黙的に設定されていますそのライン上の頂点のIDと、したがって、省略されてもよい。例えば、上述したエッジでは、頂点1を記述するディクショナリにおいて、エッジは「outE」によってマップされたエッジのリストに存在するので、「outV」:1は暗黙的であり省略することができる。しかし、省略する必要はなく、場合によっては退室するのが便利です。
  • 「プロパティ」は、プロパティのラベルをその値にマップする辞書にマップされます。たとえば、プロパティー:{“weight”:0.5}。これらのプロパティはインデックスに登録されておらず、各エッジに関連付けられているプロパティは1つだけです。
  • それが出現する頂点の「outE」フィールドと終了する頂点の「inE」フィールドの両方で同じエッジをエンコーディングするため、各エッジはGraphSONフォーマットで2回表示されます。両方のインスタンスが同じエッジを表すので、エッジの2つのインスタンスは同一である必要があります。

Example GraphSON Structure

The TinkerPopTM Modern example (data/tinkerpop-modern.json in the directory apache-tinkerpop-gremlin-console-3.2.5, i.e. the directory created by downloading the Gremlin Console):

TinkerPopTM Modernの例(ディレクトリ/ apache-tinkerpop-gremlin-console-3.2.5のdata / tinkerpop-modern.json、つまりGremlinコンソールをダウンロードして作成したディレクトリ):


13路の囲碁 firebase deploy できない件

comments powered by Disqus