MySQL集群能处理1TB的数据库吗？

Question

我需要寻找一种MySQL数据库解决方案，能够处理以TB计量的数据量，并且具备高可用性（五个9）。每个数据库行可能都有一个时间戳和多达30个浮点值。预期工作负载高达2500个插入/秒。查询可能不那么频繁，但可能很大（可能涉及100GB的数据），尽管可能仅涉及单个表。

考虑到数据量，我一直在研究MySQL Cluster，因为它是其HA产品。由于数据量的原因，我需要使用基于磁盘的存储。实际上，我认为只有时间戳可以保存在内存中，所有其他数据都需要存储在磁盘上。

有人有使用MySQL Cluster处理这种规模数据库的经验吗？它是否可行？磁盘存储如何影响性能？

我也愿意听取其他建议，以实现所需的数据容量的可用性。例如，是否更好地使用第三方库（例如Sequoia）来处理标准MySQL实例的群集化？还是基于MySQL复制的更简单的解决方案？

唯一的条件是它必须是基于MySQL的解决方案。我认为MySQL并不是处理我们所涉及的数据的最佳选择，但这是一个硬性要求。

- Mark

---

如果你正在寻找技术，可以考虑一些基于Google的BigTable的项目。Hadoop的HBase和Hypertable是值得关注的项目。http://hadoop.apache.org/hbase/ 和 http://www.hypertable.org/ - Kekoa

这个问题在serverfault.com上问可能更好。 - lothar

Answer 1

就速度而言，它是可以处理的。就大小而言，问题不在于数据的大小，而在于索引的大小，因为索引必须完全适合内存。

我很乐意提供更好的答案，但高端数据库工作非常依赖任务。我需要了解更多有关数据的信息才能提供进一步的帮助。

- Jeff Ferland

---

数据库将存储我们以50Hz接收到的多个位置的时间戳数据流，因此每秒会有2500个插入操作。数据流的配置可以随时更改，因此浮点值的数量可能是可变的。时间戳将作为主键并具有索引。我们假设时间戳列将与磁盘上的其他数据一起在内存中。 - Mark

我会批量插入。每个客户端每秒一个插入，适用于多行数据。简单的主-主复制将允许您进行故障转移，并轻松满足50个插入/秒的负载。唯一真正的问题是避免丢失样本的重要性有多大，我猜您可以处理2或3秒的数据丢失以应对服务器崩溃。作为额外的提示，如果您有除主键之外的索引，则分区表可能很有用。还可能有数据仓库技巧可加速这些大型查询。 - Jeff Ferland

感谢您的评论。我们确实认为批量插入是正确的方法。我使用ndb_size.pl脚本进行了一些计算，您关于索引大小的说法是正确的。所需的内存不足以使用Cluster。然而，今天我们也了解到有些数据丢失是可以接受的，因此，正如您所说，我们现在正在考虑使用简单的复制。 - Mark

Answer 2

“好的，我确实看到了mySQL是硬性要求的部分。

所以说，首先让我指出你所谈论的工作负载——每秒2500次插入、很少的查询、查询结果集可能达到整个数据集的10%——对于任何关系型数据库系统来说都是最劣的情况。

（这让我想起了一个项目，很久以前，我有一个硬性要求，在9600波特率的RS-422线路上加载100兆字节的程序数据，时间不超过300秒（同样是硬性要求）。1kbyte/sec × 300 seconds = 300kbytes这个事实似乎没有被理解。）

然后还有“包含最多30个浮点数”的部分。措辞至少表明每个插入的样本数量是可变的，这反过来又暗示了一些规范化问题——或者需要让每行有30个条目并使用NULL。”

但是话虽如此，好吧，你说的是每秒300K字节和2500个TPS（假设这确实是一系列不相关的样本）。至少这一组基准测试表明这并非不可能。

- Charlie Martin

---

感谢评论并教我一个新单词！（pessimal） 为了处理可变数量的样本，我们考虑每次更改时创建一个新表格，因为这不应该太频繁。然后我们将拥有一个查找表，允许您找到适当的数据表以获取时间段。 - Mark

Answer 3

这篇文章非常有助于识别导致大型MySQL数据库变慢的原因。

- Ólafur Waage

Answer 4

或许可以尝试使用Hibernate Shards，在10个节点上运行每个节点拥有1/2 TB的MySQL，这样你就可以处理5TB的数据了；）这远超出了你的限制，不是吗？

- Dean Hiller