4

このレコードの記憶喪失表があります。

-record(peer, {
    peer_key,   %% key is the tuple {FileId, PeerId}
    last_seen,
    last_event,
    uploaded = 0,
    downloaded = 0,
    left = 0,
    ip_port,
    key
}).

Peer_key はタプル {FileId, ClientId} です。ここで、特定の FileId を持つすべてのピアから ip_port フィールドを抽出する必要があります。

実行可能な解決策を思いつきましたが、これが良いアプローチであるかどうかはわかりません:

qlc:q([IpPort || #peer{peer_key={FileId,_}, ip_port=IpPort} <- mnesia:table(peer), FileId=:=RequiredFileId])

ありがとう。

4

2 に答える 2

3

{ FileId, PeerId } のようなタプルの主キーを持つ Ordered_set テーブル タイプを使用し、{ RequiredFileId, _ } のようなタプルのプレフィックスを部分的にバインドすると、そのプレフィックスを持つキーの範囲のみが検査され、テーブル全体のスキャン。qlc:info/1 を使用してクエリ プランを調べ、発生しているすべての選択がキー プレフィックスをバインドしていることを確認できます。

于 2009-07-23T14:42:15.930 に答える
0

すべての行をスキャンする必要があるため、クエリ時間はテーブルサイズに比例して増加します。したがって、現実的なテーブルデータを使用してベンチマークを行い、実際に機能するかどうかを確認します。

高速化する必要がある場合は、ファイルIDを持つすべてのピアをすばやく見つけることができるようにすることに集中する必要があります。これは、属性として[fileid、peerid]を持つbag-typeのテーブルを使用して実行できます。ファイルIDを指定すると、すべてのピアIDを取得できます。これで、検索するピアテーブルキーを作成できます。

もちろん、ピアテーブルを変更するすべてのトランザクション内でそのバッグタイプのテーブルを維持する必要もあります。

もう1つのオプションは、fileidを繰り返し、その列にmnesiaインデックスを追加することです。私は、mnesia自身のセカンダリインデックスにはあまり興味がありません。

于 2009-07-22T00:14:15.347 に答える