我在这里有点困惑......我被提议进入一个项目，其中将是一组某些传感器，每毫秒都会发出读数（是的，每秒读取 1000 个读数）。读数将是 3 或 4 位数字，例如 818 或 1529。此读数需要存储在服务器上的数据库中并远程访问。
我从未处理过如此大量的数据，您认为，一天从一个传感器读取的 MB 数是多少？... 4（数字）x1000x60x60x24 ... = 345600000 位...对吗？每天大约 42 MB... 看起来还不错，对吧？
因此，例如 1 GB 的数据库，可以保存来自 1 个传感器的 23 天信息，对吗？
我知道 MySQL 和 PHP 可能无法处理它......你有什么建议，也许是一些应用程序？天蓝色？甲骨文？
3 位或 4 位数字 =
4 bytes if you store it as a string.
2 bytes storing it as a 16bit (0-65535) integer
1000/sec -> 60,000/minute -> 3,600,000/hour, 86,400,000/day
as string: 86,400,000 * 4 bytes = 329megabytes/day
as integer:86,400,000 * 2bytes = 165megabytes/day
在这种插入负载下，您的数据库可能表现不佳，尤其是在您对相同数据运行频繁选择的情况下。优化数据库以进行大规模检索会减慢快速/频繁插入的速度。另一方面，插入一个简单的整数并不完全是一个“有压力的”操作。
您最好插入一个临时数据库，然后每小时批量复制到主“存档”数据库中。您在该主存档表上进行分析/挖掘，并了解其数据将长达 1 小时陈旧。
但最后，您必须对所有这些变化进行基准测试，看看哪种方法最适合您的特定用例。在数据库领域没有“你必须做 X 才能实现 Y”类型的建议。
您很可能不需要长时间保持如此高离散化的数据。您可以使用几个选项来最小化卷。首先，一段时间后，您可能会将每小时数据折叠成最小/最大/平均值；您可以仅针对检测到的某些不稳定情况或需要根据定义保留详细数据的情况保留详细信息。此外，许多事情可能会变成事件记录。几十年前，这些方法已在我当时工作的公司提供的一些工业自动化系统中实施并成功使用。可用的存储设备大小比您今天可以找到的要小几倍。
因此，首先，您需要分析要存储的数据，然后决定如何优化其存储。
在@MarcB 的数字之后，1kHz 的 2 个字节仅为 2KB/s 或 16Kbit/s。这并不是什么太大的问题。
我认为一种明智而灵活的方法应该是构建一个传感器读数队列，数据库可以简单地弹出这些读数，直到清楚为止。在这些数据速率下，问题不在于吞吐量（可以由拨号调制解调器处理），而是时间之间的差距。任何系统缓存值都需要能够足够快地避开以便存储下一个值；1ms 的返回时间并不长，特别是如果您有 GC 干扰。
队列的优点是在一端向队列中添加一些东西很便宜，并且可以在另一端批量处理这些值。因此，传感器端获得了所需的响应能力，并且数据库可以批量处理。
如果您不需要关系数据库，您可以使用像 mongodb 这样的 NoSQL 数据库，或者甚至像JDBM2这样更简单的解决方案，如果您使用的是 java。