我在这里有点困惑......我被提议进入一个项目，这将是一系列某些传感器，它会在每毫秒发出一次读数（是的，一秒内读取1000次）。读数可以是3位或4位数，例如818或1529.此读数需要存储在服务器上的数据库中并远程访问。
我从未使用如此大量的数据，你怎么看，一天读取一个传感器的MB数量会是多少？... 4（数字）x1000x60x60x24 ... = 345600000位.. 。 对 ？每天约42 MB ......似乎不太糟糕，对吧？
因此，例如1 GB的数据库，可以从1个传感器保存23天的信息，对吗？
我理解MySQL＆amp; PHP可能无法处理它...你会建议什么，也许是一些aps？天青？甲骨文？
答案 0 :(得分：4)
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”类型的建议。
答案 1 :(得分：2)
很可能您不需要长时间保持数据具有如此高的离散度。您可以使用多个选项来最小化卷。首先，经过一段时间后，您可以将每小时数据折叠成min / max / avg值;您可以仅针对检测到的某些不稳定情况或需要按照定义保留详细数据的情况保留详细信息。此外，许多事情可能会变成事件记录。几十年前，这些方法在我当时为之工作的公司提供的一些工业自动化系统中得到了实施和成功应用。可用的存储设备大小比您今天所能找到的小。
因此，首先，您需要分析要存储的数据，然后决定如何优化存储。
答案 2 :(得分：1)
跟随@ MarcB的数字，1kHz处的2个字节，仅为2KB / s，或16Kbit / s。这不是一个太大的问题。
我认为一种明智而灵活的方法应该是构建一个传感器读数队列，数据库可以简单地弹出直到它清晰。在这些数据速率下，问题不在于吞吐量（可以由拨号调制解调器处理），而是时间之间的差距。任何系统缓存值都需要能够快速地离开，以便存储下一个值;返回1ms不长，特别是如果您有GC干扰。
队列的优点是在一端向队列添加内容很便宜，并且可以在另一端批量处理这些值。因此传感器端获得了所需的响应能力，数据库可以批量处理。
答案 3 :(得分：1)
如果你不使用关系数据库，你可以使用像mongodb这样的NoSQL数据库，或者使用像JDBM2那样简单的解决方案，如果你使用的是java。