Question

我正在寻找这个用例的可行答案。有音乐曲目，用户有曲目播放列表。假设用户上传了一首曲目，然后一周后决定编辑该名称（或将曲目设为私有等）。如果已将轨道添加到~10k不同的播放列表中，则该单个编辑将导致~10k写入。

只需一个查询即可获取已添加使用的曲目的所有播放列表反向查找表，然后应用程序必须遍历所有10k 结果并在播放列表表格上执行相应的更新。

我看到的唯一选择是在检索播放列表时在应用程序级别执行连接。

这是我一直遇到的常见用例，想知道如何最好地处理它。

CREATE TABLE tracks (
    track_id timeuuid,
    url text,
    name text,
    PRIMARY KEY (track_id)
)

CREATE TABLE playlist_ordered_by_recently_added (
    playlist_id timeuuid,
    date_added_id timeuuid,
    track_id timeuuid,
    url text,
    name text,
    PRIMARY KEY (playlist_id, date_added_id)
) WITH CLUSTERING ORDER BY (date_added_id DESC)

CREATE TABLE playlist_ordered_by_recently_added_reverse_lookup (
    track_id,
    playlist_id,
    date_added_id,
    PRIMARY KEY (track_id, playlist_id)
)

Answer 1

“加入”方法是正确的，但我不会称之为“加入”。要检索曲目列表，您需要针对playlist_ordedred_by_recently_added发出第一个查询（它会为您提供所有track_id（预计相当小），然后是一堆并行查询来检索tracks.url和track表中的tracks.name。更新时，只需更新一次轨道表即可更改名称。

单次更新会导致数千次写入

1 个答案: