問題タブ [titan]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
indexing - elasticsearch の Titan インデックス付きタイプの作成
エラスティック サーチ インデックスを Titan Server で正しく動作させるのに問題があります。私は現在、エラスティック検索を有効にした Titan Server 0.4.0 を使用して、ローカルの Titan/Cassandra をセットアップしています。次のプロパティを持つテスト グラフ 'bg' があります。
- 頂点には、「タイプ」と「値」という 2 つのプロパティがあります。
- エッジには、「タイムスタンプ」、「長さ」などの名前を持つ他の多くのプロパティがあります。
rexster-cassandra-es.xml 構成で titan.sh を実行しています。構成は次のようになります。
この構成は、Rexter の bg 構成と、データをロードする groovy スクリプトで同じです。
Rexster クライアントをロードして と入力するとg = rexster.getGraph("bg")
、 を使用して正確な検索を実行しg.V.has("type","ip_address")
、正しい頂点を取得できます。ただし、クエリを実行すると:
エラーが発生します:
これは、タイプ「値」がインデックス化されていないことに関係していると思います。私がやりたいことは、すべての頂点とエッジの属性をインデックス可能にして、必要に応じて文字列マッチング関数を使用できるようにすることです。コマンドを使用してインデックス付きキーを作成しようとしました
しかし、正直なところ、これがどのように機能するのかわかりません。これで正しい方向に私を向けるのを手伝ってくれる人はいますか? 私は、エラスティック検索と Titan 型の定義にまったく慣れていません。
ありがとう、
アダム
graph - Gremlin を使用して Titan の頂点プロパティをクエリできませんでした
BDB バックエンドを使用して Titan に読み込まれたサンプル プロパティ グラフがあります。各頂点には、" ID "、"first_name"、"middle_name"、"last_name" という 4 つのプロパティがあります。頂点プロパティ「ID」に一意のインデックスを作成しました。型定義コードは以下の通りです。
ただし、Gremlin を介して (コンソール、つまり「gremlin.sh」または REST API のいずれかで) グラフを照会すると、頂点プロパティが「遅延」ロードされているように見えるのは奇妙です。
- クエリを送信する
"g.v(100).__ID__"
と、null が返されます。 - クエリを送信すると、 IDプロパティ
"g.v(100).map.iterate();g.v(100).__ID__"
が返されます。
構成では、storage.transactions を無効にし、storage.read-only を true に設定しました。また、高速プロパティを true または false に設定しようとしましたが、結果に違いはありませんでした。
問題を回避するために他に設定する必要があるものはありますか?
titan - Titan サーバーの起動に失敗する
titan-server を起動すると、次のメッセージが表示されます。
これが私がそれを始める方法です。
私は何が欠けていますか?助けてくれてありがとう。
もちろん、走った後は
そしてそれはうまく起動します。私のデータに何か問題があったということですか?
java - GremlinPipeline を使用して最短パスを見つける
私のデータは Titan グラフ データベースに保存されています。2 つの頂点 (v1 と v2) 間の最短経路を見つけようとしています。現在、次のコードがあります。
すべてのパスを返します。次の質問があります。
- これは、最短経路を見つけるための最速の方法ですか?
- これらすべてのパスを最短にする方法を教えてください。
編集:同じ作業をしようとしていますが、GremlinGroovyScriptEngine を使用しています。次のコードがあります。
しかし、次のエラーが表示されます。
これらの問題に対するアドバイスは素晴らしいでしょう。
output - ノード/エッジを出力するための複雑な Gremlin クエリ
ユーザーが Gremlin クエリを入力して、結果の D3 グラフを返すことができるクエリとグラフの視覚化フレームワークを実装しようとしています。D3 グラフは JSON を使用して構築されます。これは、Gremlin クエリからの個別の頂点とエッジの出力を使用して作成されます。次のような単純なクエリの場合:
これはうまくいきます。ただし、次のようなより複雑なクエリを実行しようとすると:
代わりに、出力は次の形式になります。
結果をグラフとして表示できるように、Gremlin が結果をノードとエッジのリストとして出力する方法があるかどうかを知りたいです。D3 コードを編集してこの新しい出力を取り込むことができることは認識していますが、現在、クエリのタイプ/複雑さに制限がないため、キー/値のペアが毎回同じになるとは限りません。
ありがとう。
titan - ESインデックス付き頂点プロパティによるタイタンの順序?
最新の Titan 0.4.1 docsによると、このコードは結果セット内の頂点を並べ替えるために機能するはずです。
このタイプのクエリを、潜在的に大きな頂点セット全体で実行したいので、インデックスを作成したいと考えています。ドキュメントは次のことを示唆しています:
ほとんどの外部インデックス バックエンドは、ネイティブかつ効率的に順序付けをサポートしています。ただし、 orderBy メソッドで使用されるプロパティ キーは、結果の順序付けをネイティブにサポートするために、このインデックス バックエンドでインデックスを作成するように構成する必要があります。これは、orderBy キーがクエリ キーと異なる場合に重要です。プロパティ キーがインデックス化されていない場合、並べ替えにはすべての結果をメモリにロードする必要があります。
orderBy
具体的には、Elasticsearch バックエンドの場合、この方法をサポートするインデックスを作成するにはどうすればよいでしょうか?
neo4j - 三者関係をサポートするためにグラフデータベースを構築する方法は?
私が取り組んできた個人用 Web アプリケーションのデータベース バックエンドを見つけようとしています。私がデータに必要とする柔軟性のために、リレーショナル データベースは実行できず、何らかの形式のドキュメント ストレージが必要になる可能性があります。グラフデータベースについて知ったとき、これは完璧だろうと感じました。
しかし、私は問題のある人に出くわしました: 何らかの方法で 3 方向の関係を定義できるようにする必要があります。データベースはまだ決めていませんが、Neo4j をいじっているので、Cypher を使用して問題を説明します。
基本的に、私はこれから始めます:
私が必要としているのは、複数のノードを a と b だけでなく r にも関連付ける方法です。これらの他のノードは、3 つすべてに関するさまざまな情報を格納する予定です。これを処理するには、おそらく 2 つの方法しかないと判断しました。関係を独自のノードに格納するか、情報を含むノードへの参照を格納し、疑似エッジを作成します。 . 前者の方が、おそらく次のようなものを提供するより良いアイデアだと思います。
したがって、これはデータのクエリに関する問題につながります。グラフ データベースを使用する最大のポイントは、グラフをトラバースできることです。このようなことをすると、タイプ N のノード間を再帰的にトラバースする方法はありますか? これを処理する適切な方法は何ですか?これを処理するいくつかの異なる方法を考えましたが、それらにはすべて欠点があります。このタイプの機能をネイティブにサポートする特定のグラフ データベースはありますか?
アップデート
元のコードでは、次のコードでノードを再帰的にトラバースできました。
ただし、エッジをハイパーエッジに引き抜くと、ノード タイプを交互に変更するため、グラフを再帰的に不定の深さまでトラバースできる方法があるかどうかわかりません。私はラインに沿って何かを探しています
答えが、ハイパー エッジの作成中に a と b の間にエッジも作成することだけである場合、私の質問は次のようになります。エッジとハイパー エッジが一緒に削除されるようにする良い方法はありますか? 基本的に、両方を持つことは、実際の解決策ではなく、回避策のように感じます.