我必须研究提供 MySQL 数据库的解决方案，该数据库可以处理 TB 范围内的数据量并具有高可用性（五个九）。每个数据库行可能有一个时间戳和最多 30 个浮点值。预期工作负载高达 2500 次插入/秒。查询可能不太频繁，但可能很大（可能涉及 100Gb 的数据），尽管可能只涉及单个表。
我一直在研究 MySQL Cluster，因为那是他们的 HA 产品。由于数据量大，我需要使用基于磁盘的存储。实际上，我认为只有时间戳可以保存在内存中，而所有其他数据都需要存储在磁盘上。
有没有人在这种规模的数据库上使用 MySQL Cluster 的经验？它甚至可行吗？基于磁盘的存储如何影响性能？
我也愿意接受其他关于如何实现这一数据量的预期可用性的建议。例如，使用像Sequoia这样的第三方库来处理标准 MySQL 实例的集群会更好吗？还是基于 MySQL 复制的更直接的解决方案？
唯一的条件是它必须是基于 MySQL 的解决方案。我不认为 MySQL 是处理我们正在处理的数据的最佳方式，但这是一个硬性要求。
速度方面，可以处理。大小方面，问题不在于数据的大小，而在于索引的大小，因为索引必须完全适合内存。
我很乐意提供更好的答案，但高端数据库工作非常依赖于任务。我需要更多地了解数据的情况才能提供进一步的帮助。
好的，我确实阅读了关于 mySQL 是一项硬性要求的部分。
话虽如此，让我首先指出您所说的工作负载——2500 次插入/秒、罕见的查询、可能具有高达整个数据集 10% 的结果集的查询——几乎是微不足道的适用于任何关系数据库系统。
（这让我想起了很久以前的一个项目，在该项目中，我有一个硬性要求，即在不到 300 秒的时间内通过 9600 波特 RS-422 线路（也是硬性要求）加载 100 兆字节的程序数据（也是硬性要求。 ) 1kbyte/sec × 300 seconds = 300kbytes 的事实似乎没有通信。）
然后是关于“最多包含30 个浮点数”的部分。措辞至少表明每次插入的样本数量是可变的，这反过来又表明了一些规范化问题——或者需要使每行 30 个条目宽并使用 NULL。
但话虽如此，好吧，您说的是 300Kbytes/sec 和 2500 TPS（假设这确实是一系列不相关的样本）。至少，这组基准表明它并非不可能。
这篇文章非常有助于确定什么会降低大型 MySQL 数据库的速度。
可能尝试休眠分片并在 10 个节点上运行 MySQL，每个节点 1/2 TB，这样您就可以处理 5 TB 了；）我认为远远超出了您的限制？