8

これはベストプラクティスに関する質問です。これを行うにはさまざまなオプションがあることを理解していますが、この問題の解決にどのように取り組むかについて、ご意見をお聞かせください。このシステムではパフォーマンスが重要である、つまりスケーラブルであるかのように考えてください。

最近、グラフデータベースの素晴らしさを見つけたので、会社が顧客との関係を管理したいという理論的な状況を思いつきました。そのために、彼らは素晴らしい、そして本当に素晴らしい管理を可能にするneo4jを使用する予定です。顧客、さまざまなスタッフ、およびそれらの関係はすべて素晴らしいですが、会社は認証を必要とするWebベースのインターフェイスを作成したいと考えており、neo4jデータベースの誰もがシステムにログインして表示できるようにする必要があります。彼らが会社のデータベース内の他の人々とどのように関係しているか。したがって、各ユーザーは自分の名前に関連付けられたパスワード/電子メール/IDを持っている必要があります。

したがって、私の質問は、この場合のシナリオでは、password_hash / password_salt / id / emailをmysqlデータベースに保存し、ノードに基づいてmysqlデータベースで検索するのが最善かどうかです。または、password_hash / password_salt / id/emailをノード内のハッシュテーブルに保存することをお勧めします。

また、各ストアには数千の製品があり、グラフデータベースに保存することも、mysqlデータベースに製品を保存してそこで製品を検索し、そこで変更を行うこともできます。これは、製品が互いに関連していないためです。 、グラフデータベースに保存しても意味がないので、パフォーマンスを向上させるためにそこに保存しないでください。

だから私の質問はこれに要約されます：大規模なプロジェクトでは、mysqlなどのより一般的なrdmsデータベースと一緒にグラフデータベースを使用するのが最善ですか？そうでない場合、これら2つのデータベースシステムを使い始めるポイントは何ですか？

データベースの用語に関する知識が不足していることを事前に謝罪します。

4

3 に答える 3

13

グラフDBは、主に関係を維持するために使用されます。アプリにグラフDBがある場合、それはアプリがすべてをグラフDBに保存する必要があることを意味するわけではありません。

グラフ上のすべてのノードリクエストはメモリ内にあるため、ノードに不要なプロパティがあると肥大化し、処理速度が低下し、より多くのメモリを消費する可能性があります。簡単なルール。

高レベルのプロパティ（ノードを定義する関係およびその他の重要なプロパティを定義する）はグラフに表示されますが、追加情報はRDMSに表示されます。

たとえば、FBではFBIDの場合があります。名前は、あるノードと別のノードの関係を定義するため、グラフに表示されます。しかし、ユーザーが誰かのFacebook IDをクリックすると、他のユーザーのDOB、年齢、大学を見ることができます。これらはすべてRDBMSに入れることができます。

PS：RDMSには別の利点があり、迅速な分析に使用できます。グラフでもそれができることは知っていますが、RDBMSのようにスケーラブルで簡単かどうかはわかりません。

このアプローチの欠点は次のとおりです。2つのDBSを維持する必要があります。

于 2014-01-03T17:51:37.617 に答える
3

2 DBソリューションの実証済みのケースがない限り、可動部品が少ないほどアジャイルが維持され、物事を迅速に変更できるようになると思います。後で難しいユースケースを見つけた場合は、2番目のストレージを導入することのコスト/メリットを比較検討してください。2 DBアーキテクチャは前代未聞ではありませんが、オーバーヘッドが伴います。

セキュリティに固有の理由として、Neo4jやその他の合理的なNOSQLソリューションでそれができなかった理由はありません。http：//spring.neo4j.org/docs#tutorial_security

于 2012-07-04T09:52:00.893 に答える
1

neo4j / orientDBなどのグラフDBに格納する意味があまりないデータがある場合は、両方を使用する必要があります（一部のデータは、リレーショナルDBではなくグラフDBに保存する方が適切です）。1つのプラットフォームにデータを強制すると、将来的にパフォーマンス/スケーラビリティに問題が発生する可能性があります。

于 2012-07-04T00:27:38.607 に答える