3

私はこれをやっている人がたくさんいるに違いないことを知っています。

neo4Jを使ったプロジェクトに取り組んでいます。Photo というエンティティがあるとします。今ではインターネット上で公開され、100 万人が気に入っています。それらの百万のいいねをグラフに入れ、そのグラフをナビゲートして集計を計算し、カウントを示すことがばかげているように見えます。もちろん、特にインデックスが (SQL のように) 集計の計算に使用されている場合は、インデックスを使用するとこれがより効率的になる可能性がありますが、多くの場合、これは当てはまらないと思います。もちろん、集計の多くは特定のノードでのリレーション カウントにすぎませんが、これはまだ間違っているようです (たとえば、Photo から Like イベントへのグラフ リレーションを持つことは見苦しく見えます)。

おそらく、最善の方法は、グラフ データベースを適切な用途に使用し、イベントなどにはそれらを SQL データベースに配置することです。反論の 1 つとして、「これを気に入った友達の友達は何人いますか?」などの集計が必要になる可能性があります。グラフの裏庭に戻ってきました。

そこにある選択肢は、いくつかのJavaまたは暗号クエリの束を書くことのようです。

4

1 に答える 1

4

ロブ、

いくつかのオプションがあり、

  • 一部の人々は、グラフ データをグラフに保持し、生のイベントを他のストアに保持するのが最善であると判断し、イベント ストリームから高レベルの概念と構造を導き出し、それらをグラフに具体化しました。
  • 集計データを格納するセカンダリ インデックスは類似していますが、おそらくトランザクション グラフとの統合は不十分です。
  • グラフ内構造を使用して、集計値またはアクセス パターンを表すことも可能です。René Pickard は、graphityリアルタイム ツイート クエリでそれを示しました。このソースはgithubで入手できます

多くの場合、ユースケースを確認する必要があります。すべての「いいね」を読むことがより重要なのか、それとも本当に重要な「いいね」の数が少ないのか、同じことがカウントにも当てはまります。頻繁に読み取られる場合は、それを集計することが理にかなっています (同期を維持し、集約された場所から読み取ります。

グラフのスキーマのない性質により、それを進化させることもできます。つまり、いいねが数個しかない場合は、いいねの数が特定の数を超えたときに、関係をカウントしてその場でその数を計算する方が高速で賢明です。それをイメージ自体の変数に移行する場合があります。

これは、時間主導型のアプローチである場合もあります。たとえば、写真が投稿された直後に、その周りで多くのことが発生するため、カウントを最新の状態に保ちたいと考えています (カウントが数パーセント異なっていても、それほど重要ではないことに注意してください)。結局、遅延更新もできるようになります)。しばらくすると、その写真はあまり注目されなくなり、いいね数をプロパティに集計するだけで安全になります。

于 2012-05-16T19:15:33.260 に答える