3

我需要存储播客/音频文件每秒的播放次数。这将产生一个简单的时间线图（如 Google Analytics 中的“点击”图），x 轴为秒，y 轴为播放。

然而，这些播客可能会持续长达 3 个小时，每秒播放 100,000 次也并非不现实。那是 10,800 秒，每次播放多达 100,000 次。显然，将每个播放的秒数存储在自己的行中是不现实的（这将导致 1+ 十亿行），因为我希望能够快速获取这些原始数据。

所以我的问题是：如何最好地存储这些大量的时间线数据？

我的一个想法是使用文本/blob 列，然后用逗号分隔剧本，每个逗号代表新的一秒（按顺序），然​​后是该秒播放次数的数字。因此，如果在第 1 秒中有 100,000 次播放，在第 2 秒中有 90,000 次播放，在第 3 秒中有 95,000 次播放，那么我会将其存储为：“100000,90000,95000,[...]” 在 text/blob 列中。

这是存储此类数据的可行方法吗？有没有更好的办法？

谢谢！

编辑：数据正在被跟踪到另一个来源，我只需要每 15 分钟左右更新一次原始图形数据。因此，快速读取是主要问题。

注意：由于这个项目的性质，必须单独跟踪每个播放的秒数（换句话说，我不能只跟踪每次播放的“开始”和“结束”）。

4

4 回答 4

1

Blob 存储的问题是您需要为所有更改更新整个 Blob。这不一定是坏事。使用您的格式：(100000, 90000,...), 7 * 3600 * 3 = ~75K 字节。但这意味着您每秒都在为每次播放更新 75K blob。

而且，当然，blob 对 SQL 是不透明的，因此“哪一首歌的播放次数最多”将是 SQL 级别的不可能查询（这基本上是对所有数据的表扫描以了解这一点）。

并且有很多解析开销将数据编组进出。

另一方面。Podcast ID（4 字节），秒偏移量（2 字节无符号允许 pod cast 长达 18 小时），播放次数（4 字节）= 10 字节每秒。因此，减去任何阻塞开销，一首 3 小时的歌曲是每首歌曲 3600 * 3 * 10 = 108K 字节。

如果将其存储为 blob，vs 文本（长块），4 * 3600 * 3 = 43K。

因此，第二个/行结构“仅”是二进制 blob 大小的两倍（在理想情况下，请咨询您的数据库服务器以获取详细信息）。考虑到这在能够查询事物方面给您带来的额外好处，这可能是值得的。

只有第二/每行的缺点是如果您需要进行大量更新（一首歌曲一次几秒钟），那么数据库的更新流量会很大，而使用 blob 方法，这可能是一次更新。

您的流量模式将影响更多。

于 2010-07-14T22:39:13.647 回答
0

每秒使用会不会有问题，每秒播放多少次？这意味着 10K 行，这还不错，您只需每秒使用当前数据插入一行。

编辑：我会说这种解决方案比在 TEXT 列中使用逗号分隔的内容要好......特别是因为获取和操作数据（你说你想做的）会非常混乱。

于 2010-07-14T21:57:54.380 回答
0

我将其视为键值问题。

for each second played

   Song[second] += 1

end

作为关系数据库 -

song
----
name | second | plays

还有一个 hack psuedo-sql 开始第二个：

insert into song(name, second, plays) values("xyz", "abc", 0)

另一个更新第二个

update song plays = plays + 1 where name = xyz and second = abc

一个 3 小时的播客将有 11K 行。

于 2010-07-14T22:06:41.450 回答
0

这实际上取决于生成数据的内容..

据我了解，您想要实现一个地图，其中键是第二个标记，值是播放次数。

您正在加载的事件、工作单元或事务中的部分是什么？

我可以假设您在播客名称、开始和停止时间上有一个播放事件并且您想加载到地图中进行分析和演示吗？

如果是这种情况，你可以有一张桌子

  • 播客 ID
  • 秒偏移
  • 播放计数

每个偶数都会更新开始和结束位置之间的行

update t set playCount = playCount +1 where podCastId = x and secondOffset between y and z

然后是插入以在开始和停止之间添加那些不存在的行，播放计数为 1，除非您用零预加载表。

根据数据库，您可能能够设置不存储空列的稀疏表，从而提高效率。

于 2010-07-14T22:16:39.347 回答