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

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

This is too much for an SQL database

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

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

如今，拥有包含数百 TB 数据的 SQL 数据库并不少见，所以 17GB 真的没什么好考虑的。更不用说 10 年 170GB(使用当时的机器)。

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

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