この質問は、highscalability.comの記事「 Why are Facebook, Digg, and Twitter so hard to scale? 」に触発されています。
では、この種のデータをより適切に処理できるデータベース システム (あいまいですが) はありますか?
3370 次
4 に答える
7
表現しようとしているデータ構造に合わせてデータモデルが調整されたデータベースシステムを持つことは、多くの場合有利です。ソーシャル ネットワークは、Allegro GraphやNeo4jなどのグラフ データベースに非常に適しています。
Neo4j ブログには、Neo4j を使用した例とともに、グラフ データベースでソーシャル ネットワークを表す方法に関する優れた記事があります。
グラフ データベースの利点は、データが格納されるため、エンティティ間の接続を非常に高速に移動できるため、複雑なネットワークをすばやく移動できることです。これらの操作は通常、現在のリレーショナル データベースの実装では (せいぜい) 高価な結合操作になります。リレーショナル データベースと同様に、グラフ データベースには、複数のハードウェア ノードへのスケール アウトに関して、まだ若干の問題があります。ただし、複数のハードウェア ノードの必要性は、ソーシャル ネットワークの種類のデータ用のリレーショナル データベースよりもグラフ データベースの方がはるかに少なくて済みます。1 台のマシンに数十億のノードがあっても問題ありません。複数のハードウェア ノードへのスケール アウトは、キー値ストア内のエンティティが互いに完全に分離されているため、キー値ストアが優れているところです。ここでの問題は、代わりに、ソーシャル ネットワークで何も隔離されていないことです。つまり、接続をエミュレートするには、エンティティごとに 1 つずつ、データベースへの複数のクエリが必要です。これは、特に、各クエリで 1 つのレベルの友達しか発見できない、友達の友達のようなクエリの場合は遅くなります。
免責事項: 私は Neo4j チームのメンバーです。
于 2009-10-23T10:16:24.960 に答える
1
この記事では、memcached について言及したときに、間接的に答えを伝えました。これは、すべてのデータを RAM に保持するキー値ストアです。明らかに、ハード ドライブにデータを保持する追加のデータ ストアが必要ですが、それらはおそらくキーと値のストアでもあります。これらには、 Hadoop、CouchDB、Tokyo Cabinet、Redisなど、たくさんあります。
テーブルの行全体ではなく、関心のあるフィールドのみを取得する必要があるMonetDBなどの列ストアを使用することもできます。
于 2009-10-22T23:11:05.160 に答える