erlang - 如何将元组内容与 qlc 和 mnesia 匹配?

发布于 2024-07-27 17:01:38 字数 498 浏览 14 评论 0原文

我有一个记录该记录的记忆表。

-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])

谢谢。

I have a mnesia table for this record.

-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 is a tuple {FileId, ClientId}, now I need to extract the ip_port field from all peers that have a specific FileId.

I came up with a workable solution, but I'm not sure if this is a good approach:

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

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

如梦初醒的夏天 2024-08-03 17:01:38

在ordered_set表类型上使用带有元组主键(如{FileId,PeerId}),然后部分绑定元组的前缀(如{RequiredFileId,_})将非常有效,因为只会检查具有该前缀的键的范围,而不是全表扫描。 您可以使用 qlc:info/1 检查查询计划并确保正在发生的任何选择都绑定键前缀。

Using on ordered_set table type with a tuple primary key like { FileId, PeerId } and then partially binding a prefix of the tuple like { RequiredFileId, _ } will be very efficient as only the range of keys with that prefix will be examined, not a full table scan. You can use qlc:info/1 to examine the query plan and ensure that any selects that are occurring are binding the key prefix.

深爱不及久伴 2024-08-03 17:01:38

您的查询时间将随着表大小线性增长,因为它需要扫描所有行。 因此,用实际的表数据对其进行基准测试,看看它是否真的可行。

如果您需要加快速度,您应该专注于能够快速找到带有文件 ID 的所有对等点。 这可以通过以 [fileid,peerid] 作为属性的包类型表来完成。 给定一个文件 ID,您将获得所有对等点 ID。 这样您就可以构建要查找的对等表键。

当然,您还需要在更改对等表的每个事务中维护该包类型表。

另一种选择是重复 fileid 并在该列上添加 mnesia 索引。 我只是不太喜欢 mnesia 自己的二级索引。

Your query time will grow linearly with the table size, as it requires scanning through all rows. So benchmark it with realistic table data to see if it really is workable.

If you need to speed it up you should focus on being able to quickly find all peers that carry the file id. This could be done with a table of bag-type with [fileid, peerid] as attributes. Given a file-id you would get all peers ids. With that you could construct your peer table keys to look up.

Of course, you would also need to maintain that bag-type table inside every transaction that change the peer-table.

Another option would be to repeat fileid and add a mnesia index on that column. I am just not that into mnesia's own secondary indexes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文