タグ付けされた質問 「graph-databases」

議論のために、FourSquareのシナリオを考えてみましょう。 シナリオ エンティティ： ユーザー 場所 関係： チェックイン：ユーザー<->場所、多対多 友人：ユーザー<->ユーザー、多対多 データベース設計 これらにはエラーが発生する可能性が高いため、指摘してください。 RDBMS テーブル： ユーザー 場所 チェックイン（ジャンクション） 友達（ジャンクション） 長所： CAP：一貫性、可用性 短所： CAP：パーティション許容値、別名シャーディング スキーム=柔軟性のない構造 貧弱な複製？ グラフ オブジェクト： ユーザー 場所 エッジ： 友達：ユーザー<->ユーザー チェックイン：ユーザー->場所 タイムスタンプを含む 長所： CAP：一貫性、可用性？ スキーマレスで簡単に変更可能なオブジェクトとエッジ グラフトラバーサルクエリ、たとえば： クラスタリング 友達のグループを見つける 似たような人が好きなレストランを見つける 他の一般的な/有用なクエリはありますか？ 短所： CAP：パーティションの許容範囲？ ドキュメント/オブジェクト 3つの個別のデータベース？ ユーザー 友達リスト チェックイン タイムスタンプ ユーザー 場所 場所 長所： …

29 database  database-design  relational-database  document-databases  graph-databases 

ElasticSearchとグラフデータベースの比較について、Webで詳細な説明を見つけることはできません。 どちらもデータを横断するように最適化されています。 ElasticSearchは分析用に最適化されているようです。 ただし、Neo4jは、インデックスと一部のフルテキスト機能を管理するLuceneにも基づいています。 すでにグラフデータベースを使用しているのにElasticSearchを使用するのはなぜですか？ 私の場合、Neo4jを使用してソーシャルネットワークを構築しています。 ElasticSearchがもたらす本当のメリットは何ですか？ 更新---------- 私はこの段落を見つけました： elasticsearchが役立つ無数のケースがあります。いくつかのユースケースは、他のユースケースよりも明確にそれを要求します。次に、elasticsearchが特に適しているタスクをいくつか示します。 特定のフレーズ（「シェフのナイフ」など）に最も一致する製品説明を多数検索して、最良の結果を返す 前の例では、「シェフのナイフ」が表示されるさまざまな部門を分類します（この本の後半のファセットを参照） 「季節」のように聞こえる単語をテキストで検索する スペルミスを考慮しながら、以前に発行された検索に基づいて部分的に入力された単語に基づいて検索ボックスを自動補完する 大量の半構造化（JSON）データを分散方式で保管し、マシンのクラスター全体に指定されたレベルの冗長性を持たせる ただし、elasticsearchは前述の問題を解決するのに優れていますが、他の人には最適な選択ではないことに注意してください。リレーショナルデータベースが最適化されている問題の解決は特に苦手です。以下にリストされているような問題。 在庫に残っているアイテムの数を計算する 特定の月に送信されたすべての請求書のすべての明細の合計を計算する ロールバックサポートを使用してトランザクションで2つの操作を実行する 電話番号や内線番号など、指定された複数の用語にわたって一意であることが保証されているレコードを作成する Elasticsearchは一般に、品質による結果のスコアリングなど、データからおおよその回答を提供するのに優れています。elasticsearchは正確なマッチングと統計計算を実行できますが、検索の主なタスクは本質的におおよそのタスクです。 おおよその回答を見つけることは、elasticsearchと従来のデータベースを分離するプロパティです。そうは言っても、従来のリレーショナルデータベースは精度とデータの整合性に優れているため、elasticsearchとLuceneにはほとんど規定がありません。 おおよその回答が必要ない場合、ElasticSearchは既に使用されているグラフデータベースと比較して役に立たないと断言できますか？

15 database  query  graph-databases  elasticsearch 

私は、宇宙が非常に大きくなる（基本的には無限に大きくなる）Webサイト用の2Dゲームを作成しています。最初は、宇宙は原点（0、0）から等しい距離にある6つの星で構成されています。私のタスクは、相互に接続する「パス」（エッジ）を持つより多くの星を生成できるようにすることです。これらの制限を満たすアルゴリズムをどのように設計できますか： 星は外側にランダムに生成されます。（たとえば、新しい星の（x、y）座標は、（0、0）からすべての方向にゆっくりと外側に移動し、できれば螺旋状になります） エッジは交差しません。 多少の違いはあるはずですが、新しい星は他の星に近すぎたり近すぎたりしてはなりません。（たとえば、最小半径が必要です） スター/ポイントの多重度が3を超えることはできません。 このすべてがデータベースに保存されることを考えると、アルゴリズムのコストが高すぎることはありません。言い換えれば、O（n）の複雑さを実現したいと考えています（これが実現可能かどうかはわかりません）。 基本的に、私が目指しているのは、星がグラフ上の点であり、星間の移動がそれらの星の間のエッジで描かれている渦巻き状の銀河です。 解決する必要がある特定の手順は次のとおりです。 まだ3の多重度を持たない他の星の近隣に点をランダムに生成します。 エッジの競合を生成しない3の多重度をまだ持たない最初の星を見つけます。 星がx単位の最小距離にある場合、2点間にエッジを作成します。 解決策を探してみましたが、数学のスキル（およびグラフ理論の知識）には多くの作業が必要です。また、この問題に関するリソース/リンクは大歓迎です。 ここに私が考えていたいくつかの擬似コードがありますが、これがうまくいくかどうかはわかりません。 newStar = randomly generated (x, y) within radius of last star from origin while(newStar has not been connected): for (star in the known universe): if(distance between newStar and star > x units): if(star has < 3 multiplicity): …

11 php  algorithms  mysql  graph  graph-databases 

メニュー/レシピ管理という趣味のプロジェクトに取り組んでいます。 これは私の実体とそれらの関係がどのように見えるかです。 AにNutrientはプロパティがCodeあり、Value のIngredientコレクションを持っていますNutrients A RecipeにはコレクションがIngredientsあり、時々他のコレクションを持つことができますrecipes Aは、Mealのコレクションを持っているRecipesし、Ingredients A MenuのコレクションがありますMeals 関係は次のように表すことができます いずれかのページで、選択したメニューについて、その構成要素（食事、レシピ、成分、および対応する栄養素）に基づいて計算された有効栄養素情報を表示する必要があります。 現在、SQL Serverを使用してデータを格納しています。メニューの各食事から始めて栄養素の値を集計して、C＃コードからチェーンを移動しています。 この計算はページがリクエストされ、構成要素が時々変更されるたびに行われるため、これは効率的な方法ではないと思います。 MenuNutrients（{MenuId, NutrientId, Value}）と呼ばれるテーブルを維持し、コンポーネント（食事、レシピ、成分）のいずれかが変更されたときに、このテーブルに有効な栄養素を追加/更新するバックグラウンドサービスがあることを考えていました。 GraphDBはこの要件に適していると思いますが、NoSQLへの私の露出は限られています。 特定のメニューの栄養素を表示するというこの要件に対する代替の解決策/アプローチは何ですか？ シナリオの説明が明確であることを願っています。

10 c#  sql  database-design  nosql  graph-databases