我必须做一个应用程序，每秒检查35项的变化。每个项目有3个值，每个值适合5个字节，因此项目为15个字节。价值不会每秒都改变，但没有一种模式，也许它们会不断变化，或者它们会停滞一段时间......
所以我做了一个很小的计算，我得到了每一个存储在关系数据库（SQL）上的所有字段我将拥有：
35 * 15字节* 60秒* 60分钟* 24小时* 365 = 16.5 Gb一年。
对于SQL数据库来说，这太过分了。你会做些什么来减少数据的大小？我只考虑在存在更改时存储数据，但是在更改完成后需要存储，如果数据更改太频繁，则需要比其他方法更多的空间。
我不知道除了SQL数据库之外是否还有其他存储库更符合我的要求。
您怎么看？
编辑：更多信息。
除了我可以创建以节省空间的数据之外，数据之间没有任何关系。我只需要存储这些数据并进行查询。数据看起来像（将它们全部放在一个表中并每秒保存一次数据）：
Timestamp Item1A Item1B Item1C Item2A Item2B ....
whatever 1.33 2.33 1.04 12.22 1.22
whatever 1.73 2.33 1.04 12.23 1.32
whatever 1.23 2.33 1.34 12.22 1.22
whatever 1.33 2.31 1.04 12.22 1.21
我觉得必须是更好的解决方案，而不是这种方法......
编辑2：
我通常会查询有关物品价值的数据，通常我不会查询多个物品的数据......
答案 0 :(得分：2)
这对SQL数据库来说太多了
什么时候太多了？
对于几乎所有RDBMS来说，这真的很棒（每年大约17GB的数据）。
MySQL可以做到这一点，PostgreSQL，Firebird和其他很多人也可以，但不是像Sqlite那样。我自己选择PostgreSQL。
拥有数百TB数据的SQL数据库现在并不少见，所以17GB无需考虑，真的。更不用说10年内的170GB（使用当时的机器）。
即使考虑到其他数据和索引每年达到30GB，对于SQL数据库来说仍然可以。
修改
考虑到你的结构，这对我来说很稳固，你所需要的最小的东西已经存在，而且你不需要额外的东西。
你不能比这更好，不使用比缺点更多的缺点。
答案 1 :(得分：0)
我目前正在考虑使用压缩文件而不是SQL数据库。我将使用我得到的信息保持帖子升级。