我需要存储播客/音频文件每秒的播放次数。这将生成一个简单的时间线图（如Google Analytics中的“点击”图表），x轴上有秒，并在y轴上播放。
然而，这些播客可能会持续长达3个小时，每秒播放100,000次并不是不切实际的。这是10,800秒，每个最多100,000次。显然，将每个在自己的行中存储第二个是不现实的（它会产生10亿行），因为我希望能够快速获取这些原始数据。
所以我的问题是：我如何才能最好地存储这些大量的时间线数据？
我的一个想法是使用text / blob列，然后用逗号分隔播放，每个逗号代表一个新的秒（按顺序），然后是第二个播放次数的数字。因此，如果第二场比赛中有100,000场比赛，第二场比赛中有90,000场比赛，第二场比赛则有95,000场比赛，那么我会将其存储起来：文本/ blob列中的“100000,90000,95000，[...]”。
这是存储此类数据的可行方法吗？还有更好的方法吗？
谢谢！
编辑：数据被跟踪到另一个源，我只需要每15分钟更新一次原始图数据。因此，快速读取是主要关注点。
注意：由于这个项目的性质，每个玩过的第二个都必须单独跟踪（换句话说，我不能只跟踪每个游戏的'开始'和'结束'）。
答案 0 :(得分：1)
blob存储问题是您需要为所有更改更新整个blob。这不一定是坏事。使用您的格式：（100000,90000，...），7 * 3600 * 3 = ~75K字节。但这意味着你每秒都会为每场比赛更新75K blob。
当然，blob对SQL是不透明的，所以“什么歌曲中播放次数最多的第二部分”将是SQL级别的一个不可能的查询（这基本上是对要学习的所有数据的表扫描）
并且有很多解析开销将数据输入和输出。
另一方面。播客ID（4个字节），第二个偏移（2个字节无符号允许pod转换长达18小时），播放计数（4个字节）=每秒10个字节。因此，减去任何阻塞开销，3小时的歌曲是3600 * 3 * 10 =每首歌108K字节。
如果您将其存储为blob，vs文本（longs块），则为4 * 3600 * 3 = 43K。
因此，第二个/行结构“仅”是二进制blob的两倍大小（在完美的世界中，请参阅数据库服务器以获取详细信息）。考虑到额外的好处，这使您能够查询事物，这可能值得做。
如果您需要进行大量更新（一首歌只需要几秒钟），那么只有第二行/每行的下行，这是DB的大量UPDATE流量，而使用blob方法，这可能是单一更新。
您的流量模式会影响更多。
答案 1 :(得分：0)
使用每一秒是否有问题，每秒播放多少次？ 这意味着10K行，这不错，你只需要每秒用当前数据插入一行。
编辑：我会说这个解决方案比在TEXT列中用逗号分隔的东西更好...特别是因为获取和操作数据（你说你想做的）会非常混乱。
答案 2 :(得分：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行。
答案 3 :(得分：0)
这实际上取决于生成数据的内容..
据我所知，您希望实现一个地图，其中键是第二个标记，值是播放次数。
您要加载的活动，工作单元或交易中的部分是什么？
我可以假设您在播客名称，开始和停止时间都有播放事件 你想加载到地图中进行分析和演示吗？
如果是这种情况，你可以有一张桌子
每个人甚至会更新开始和结束位置之间的行
更新t 设置playCount = playCount +1 其中podCastId = x 和y和z之间的secondOffset
然后插入一个插件，在playcount为1的情况下，在start和stop之间添加不存在的行，除非你用零预加载表。
根据数据库的不同，您可以设置稀疏表，其中不存储空列，从而提高效率。