7

最終的にテーブル/モデル間の多対多の関係がほとんどない可能性のあるsinatra/railsベースのWebポータルを実装しています。これは 1 人のチームであり、パートタイムですが、現実世界のアプリです。

自分のエンティティについて誰かと話し合ったところ、neo4j を試すように勧められました。本当の「セクシーではない」企業の世界から来た私の傾向は、スケーリングが停止するか、シャーディングなどのために悪夢になるまでリレーショナルデータベースを使用してから、他のことを考えることです。

でも、

  • 私はこのプロジェクトで datamapper と一緒に postgres を初めて使用しています。非常に速く使い始めるのに時間がかかります
  • 私はいくつかのことを試して、より多くのユースケースを構築しているだけなので、一貫してスキーマを更新する必要があります (プロトタイプのアイデアとベータ版からのフィードバック)。これをneo4jで行う必要はありません（クエリの変更を除く）
  • neo4j を使用して検索をセットアップするのは非常に簡単なようです。しかし、Postgres は全文検索も行うことができます。
  • Postgres は最近、json と javascript のサポートを発表しました。PG を使い続けて、neo4j の代わりに PG (良いコミュニティを持っている) の学習にもっと時間を費やすべきかどうか疑問に思っています。

特にプロタイピング/プロジェクトの初期段階で、neo4j が優れているユースケースを探しています。Web サイトが成長すると、s3、リレーショナル (PG)、mongo などの複数の永続的なテクノロジが必要になる可能性があることを理解しています。

また、Rails/Ruby エコシステムでどのように機能するかを知っておくとよいでしょう。

アップデート1:

私は多くの良い答えを得て、今のところPostgresに固執するのが正しいことのようです（特にherokuにデプロイして以来）

ただし、スキーマレスであるという考えは魅力的です。基本的には、100 ～ 150 人のユーザーがいて、製品の適切なスキーマ (ビジネス ユース ケース) を自分で考え出すまで、データモデルを定義しないアプローチを考えています。限られたサインアップでのフィードバック。次に、スキーマを決定し、リレーショナルから始めることができます。

スケーリングなどをあきらめる可能性のある、使いやすいスキーマ/永続性の低いオプション (新しいユーザーの使いやすさ/セットアップに基づく) があるかどうかを知っておくとよいでしょう。

4

3 に答える 3

9

本当に無秩序なデータ モデルがある場合は、グラフ データベースを検討する必要があります。エンティティ間の非常に複雑な関係を表現するために必要でした。そのために、RDBMS は宣言型アプローチを使用するのに対し、データ レベルで関係を保存します。リレーションシップを保存することは、これらのリレーションシップが非常に異なる場合にのみ意味があります。このような多様な関係を要求するには、膨大な量のデータを処理する必要があります。大量の結合を実行する場合、レコードを選択してその関係を追跡するだけなので、グラフ データベースが優れているのはこの点です。私の声明を裏付けるために、Neo4j の Web サイトのすべてのユース ケースが非常に複雑なデータを扱っている ことに気付くでしょう。

要するに、私が上で言ったことに関心がなければ、別のテクノロジーを使用するべきだと思います。これがスケーリング、スキーマレス、またはプロジェクトの迅速な開始に関するものである場合は、他の NoSQL ソリューション (より具体的には、列指向またはドキュメント指向のデータベース) を検討してください。それ以外の場合は、PostgreSQL を使用する必要があります。あなたが言ったように、ポリグロットの永続性を考慮することもできます。

更新については、hStoreを検討してください。あなたの要件に合っていると思います。Herokuでも動作するPostgreSQLモジュールです。

于 2013-06-07T08:22:58.543 に答える
5

最も適切な選択は、解決しようとしている問題によって異なります。

多対多のテーブルがいくつかある場合は、リレーショナル データベースで十分です。一般に、リレーショナル データベースははるかに古く、標準化されたインターフェイスと行と列の構造を持っているため、OR マッパーのサポートは優れています。それらはまた、長い間改良されてきたので、安定しており、彼らがしていることのために最適化されています.

たとえば、問題がエンティティ間の接続に関するものである場合、特に「(不特定の長さの) サイクルを検出する」、「友人の友人は何を好むか」など、より距離の長い接続が必要な場合は、グラフ データベースが適しています。そのようなことは、SQL 結合に制限されると扱いにくくなります。Neo4j の場合のcypherのような問題固有の言語は、それをより簡潔にします。欠点としては、グラフ データベースとオブジェクトの間にマッパーがありますが、太陽の下のすべてのフレームワークと言語に対応しているわけではありません。

私は最近、neo4j を使用してシステム プロトタイプを実装しました。データの構造と接続について話し、データ ストレージで 1 対 1 でモデル化できることは非常に役に立ちました。また、データ ポイント間に他の接続を追加するのは簡単で、neo4j はスキーマレス ストレージです。書き込み性能に問題があり、mongodb に切り替えることになりましたが、それと同時にプロトタイプを完成させることはできなかったと思います。

ドキュメントベース、列、キー値などの他の NoSQL データストアも、特定のユースケースをカバーしています。ポリグロットの永続性は間違いなく注目すべきものです。新しいことを学んだ場合に後でテクノロジーを変更できるように、バックエンドの選択をビジネス ロジックから合理的に分離しておいてください。

于 2013-06-07T19:41:45.277 に答える
5

データ モデルが非常に複雑な場合にのみグラフ データベースを使用する必要があることに同意するとは思いません。単純なデータモデル/関係も処理できると確信しています。

Neo4j または Postgres の経験がない場合は、おそらくどちらも十分に習得するのにかなりの時間がかかります。

選ぶ際の注意点：

  1. これは、データベース テクノロジに対する開発だけではありません。展開も検討する必要があります。Postgres/Neo4j のデプロイとスケーリングはどれくらい簡単ですか?

  2. 各テクノロジーに関するコミュニティとツールを検討してください。PostgresにあるようなNeo4j用のデータマッパーはありますか?

  3. この 2 つのデータ モデルはかなり異なっていることを考慮してください。すでにリレーショナルに考えられるのであれば、私はおそらく Postgres を使い続けるでしょう。Neo4j を使用すると、データ モデルで数か月間多くの間違いを犯すことになります。

  4. 時間の経過とともに、できる限りシンプルに保つことを学びました。Postgres は、Neo4j に比べて退屈な選択かもしれませんが、退屈で夜更かしすることはできません。=)

また、誰も言及していませんが、Riak ( http://basho.com/riak/ ) も参照してください。これは、オブジェクト間の関係 (リンク) も提供するドキュメント データベースです。グラフ データベースほど成熟していませんが、いくつかのエンティティをすばやく接続できます。

于 2013-06-07T16:23:01.373 に答える