如何有效地存储这么大的数据量？数据库还是什么？

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的值的数据，通常我不会从多个Item中查询数据...

Answer 1

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

什么时候过分了？
对于几乎所有的 RDBMS 来说，这真的是小菜一碟（每年大约 17GB 的数据）。

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

如今，拥有数百 TB 数据的 SQL 数据库并不少见，因此 17GB 真的没什么好考虑的。更不用说 10 年内达到 170GB（使用当时的机器）。

即使考虑到其他数据和索引每年达到 30GB，对于 SQL 数据库来说仍然可以。

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

Answer 2

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