7

写真を NoSQL データベース (<5MB) に保存し、それらを別のバケットの記事にリンクしようとしています。Riak のリンク ウォーキング機能はどのような速度を提供しますか? それは RDBMS 結合のようなものですか?

4

2 に答える 2

11

リンクは JOIN (デカルト積を含む) とはまったく似ていませんが、いくつかの意味で同様の目的に使用できます。これらは、HTML ドキュメント内のリンクに非常に似ています。

リンク ウォーキングでは、単一のキーで開始するか、複数のキーで開始する map-reduce ジョブを作成します。(リンク ウォーキング/トラバーサルは、実際には map-reduce の特殊なケースです。) これらの値がフェッチされ、それらのリンクが仕様 (バケット、タグ) に対してフィルター処理され、一致したリンクが次のフェーズに渡されます (または、クライアント）。もちろん、これらはすべて (JOIN とは異なり) 並行して行われ、データの局所性が高くなります。

また、map-reduce 自体は遅くはありません。複雑な作業を行うための洗練されたクエリ プランナーを持っていないだけです。必要に応じて、データをクエリして整理する方法を考える必要があります。

于 2010-06-16T12:53:19.643 に答える
7

一方向の関係を考えて、通常のクエリと同じくらい高速にします。MapReduce ほど遅くはありません。

から: http://seancribbs.com/tech/2010/02/06/why-riak-should-power-your-next-rails-app/

Riak がこれに対処する最初の方法は、リンク ウォーキングです。Riak に保存されているすべてのデータは、Link HTTP ヘッダーを介して他のデータとの一方向の関係を持つことができます。標準的な例では、「アーティスト」バケットに保存したバンドのキーを知っています (Riak バケットは、データベース テーブルまたは S3 バケットのようなものです)。そのアーティストがそのアルバムにリンクされており、そのアルバムがアルバムのトラックにリンクされている場合、1 回のリクエストで制作されたすべてのトラックを見つけることができます。次のセクションで説明するように、一度に 1 つのテーブルではなく、各項目が個別に操作されるため、これは SQL の JOIN よりもはるかに負担が少なくなります。そのクエリは次のようになります。

GET /raw/artists/TheBeatles/albums, , /tracks,_,1 「/raw」は URL 名前空間の先頭、「artists」はバケット、「TheBeatles」はソース オブジェクト キーです。以下は、どのリンクをたどるかの一致仕様です。バケット、タグ、キープのトリプルの形式で、アンダースコアは何にでも一致します。3 番目のパラメーター「keep」は、そのステップから結果を返すことを示します。これは、任意の組み合わせで、必要な任意のステップから結果を取得できることを意味します。私はあなたのことを知りませんが、私にはこれよりも自然に感じます:

SELECT トラック.* FROM トラック INNER JOIN アルバム ON トラック.album_id = albums.id INNER JOIN アーティスト ON アルバム.artist_id = artist.id WHERE artist.name = "ビートルズ"アプリケーションでほとんど問題なく克服できます。SQL データベースに参照整合性制約がなければ (ActiveRecord は過去に苦労しました)、DELETE や UPDATE によって行が孤立しないという確固たる保証はありません。ActiveRecord は関連のリンクを自動的に処理するので、私たちはちょっと甘やかされています。

リンクウォーキング機能が本当に輝く場所は、自己参照的で深い推移的な関係にあります (has_many :through writ large を考えてください)。JOIN を介して仮想テーブルを作成し、同じテーブルの異なるバージョンにエイリアスを作成する必要がないため、ソーシャル ネットワーク グラフ (友人の友人の友人) や、ツリーやツリーのようなデータ構造を簡単に作成できます。リスト。

于 2010-06-16T05:01:56.550 に答える