如何高效存储如此大的数据量？数据库还是什么？

Question

我必须做一个每秒检查 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：

我通常会查询有关项目值的数据随着时间的推移，通常我不会查询多个 Item 的数据......

Answer 1

这对于 SQL 数据库来说太多了

，什么时候开始变得太多了？
对于几乎所有 RDBMS 来说，这确实是微不足道的（每年约 17GB 的数据）。

MySQL 可以做到这一点，PostgreSQL、Firebird 和许多其他数据库也可以做到，但 Sqlite 之类的不行。我自己会选择 PostgreSQL。

如今，拥有数百 TB 数据的 SQL 数据库并不罕见，因此 17GB 确实没什么可考虑的。更不用说10年后170GB了（用当时的机器）。

即使用于其他数据和索引的存储空间达到每年 30GB，对于 SQL 数据库来说仍然可以。

编辑
考虑到您的结构，在我看来很可靠，您需要的最少的东西已经存在，并且没有您不需要的额外内容。
如果不使用弊大于利的技巧，你就不可能得到比这更好的结果。

Answer 2

我目前正在考虑使用压缩文件而不是 SQL 数据库。我将根据我得到的信息不断更新帖子。