mySQL是否适合存储250ms更新时的数据流，每次更新有30字节的信息，并服务于web？

标题中的大部分内容是这样的，我想知道MySQL是否适合（如果不适合，还有什么更好的方法）存储这些数据

最有可能是每四分之一秒发送3到6个浮点数。（大约每年1-3 GB）

同时，这些数据需要从MySQL实时（或接近）访问，因此在数据库上运行一些（可能较大的）查询时，它不会错过任何机会

MySQL能处理这个问题吗？我不知道这种数据库是如何扩展的，也不知道这些数据库的“大量”信息是由什么组成的

---

如果数据库接收到相同的信息，但每5-10分钟就进行一次大规模更新，这会改变答案吗？

这取决于表和硬件。一个好的mysql服务器不会有任何问题。特别是如果配备了SSD驱动器

一个插入大量数据的大型查询将更有效，因为它将是单个索引更新等等。在0.25秒的更新和5分钟的批量更新之间会有一个最佳点。测试将证明这一点

---

如果您正在进行复制，请记住从机是单线程的，这些更新最终需要更长的时间。您还希望使用innodb而不是myisam，以避免写入期间的表级锁。

从透视图上看，这里的一个应用程序（诚然是一个主要应用程序）每年生成超过13GB的新数据；这还不算（需要的，一些不需要的）指标。当然，其中大部分都在一个表中（设计问题）。。。当然，这是在带有DB2的iSeries上进行的。谢谢，我不知道最后一部分是什么意思，但在我尝试任何一种方法之前，我会弄清楚的。我正在考虑这个问题。如果myisam主要是插入式的，你也可以使用它。。。