分布式数据库用例

Question

目前我确实有一个 mysql 数据库，我收集的数据是每年 5 兆字节。我会一直保存我的数据，我不认为我想很早就删除一些东西。 我问自己是否应该使用分布式数据库，因为我的数据每年都会增长。 5 年后，我将拥有 25 个没有索引的太字节。 （只是计算了我每天保存的原始数据）

我有 5 个表，大多数查询是多个表的连接。 而且我需要在特定的时间戳访问多行的 1-2 列。

分布式数据库会比单个 mysql 数据库更受欢迎吗？

分区会很困难，因为我所有的表都是高度连接的。

我知道这取决于查询和数据库表设计，我也可以拥有一个分布式 mysql 数据库。 我只想知道什么时候应该考虑分布式数据库。 这会是一个用例吗？或者mysql可以处理这么大的数据集吗？

编辑：

• 平均而言，我每秒将有 1500 个客户端写入数据，它们会影响所有表。

• 我只需要旧数据集进行分析。比如机器学习和 模式匹配。

• 客户端也应该能够看到历史数据

Answer 1

您的问题是关于“分布式”的，但我看到更严重的问题需要先回答。

“高度索引的 5TB”将缓慢爬行。索引是 BTree。将新行添加到索引意味着在该项目所属的树中定位块，然后读取-修改-写入该块。但是……

• 如果索引是AUTO_INCREMENT 或TIMESTAMP（或类似的东西），那么被修改的块“总是”在 BTree 的“末端”。所以几乎所有的读取和写入都是可缓存的。也就是说，更新这样的索引开销非常低。

• 如果索引是“随机的”，例如 UUID、GUID、md5 等，则在缓存中很少找到要更新的块。也就是说，为这一行更新这一索引可能会花费一对 IOP。即使使用 SSD，您也可能跟不上。 （假设您没有几 TB 的 RAM。）

• 如果索引介于顺序和随机之间（例如，某种“名称”），则 BTree 中可能有数千个“热点”，这些可能是可缓存的。

底线：如果你不能避免随机索引，你的项目注定要失败。

下一期...查询。如果您需要扫描 5TB 以获取 SELECT，那将需要一些时间。如果这是一个数据仓库类型的应用程序，并且您需要汇总上个月的数据，那么构建和维护汇总表将非常重要。此外，这可以消除对“事实”表中某些索引的需求，从而可能消除我对索引的担忧。

“查看历史数据”——查看单个行？还是只查看摘要信息？ （同样，如果它像 DW 一样，很少需要查看旧数据点。）如果汇总就足够了，那么可以避免 25TB 的大部分。

你有25TB的机器上网吗？如果没有，那可能会迫使您拥有多台机器。但是，您将面临在它们之间运行查询的复杂性。

从 INT = 4 字节等估计 5TB？如果使用 InnoDB，则需要乘以 2 到 3 才能获得实际占用空间。此外，如果您将来需要修改表，则此类操作可能需要将表复制过来，这样所需的磁盘空间就会增加一倍。您的 25TB 变得更像是 100TB 的存储空间。

PARTITIONing 的有效用例很少，所以在了解更多信息之前我不想讨论这个问题。

“分片”（跨机器分割）可能是您所说的“分布式”。对于多个表，您需要认真考虑如何拆分数据，以便JOINs 继续工作。

5TB 很大——尽你所能缩小它——使用更小的数据类型、规范化等。但不要“过度规范化”，你最终可能会得到糟糕的性能。 （我们需要查看查询！）

有许多个方向来获取多 TB 数据库。我们确实需要更多关于您的表和查询的信息，然后才能更具体。

Answer 2

对于如此广泛的问题，真的不可能提供具体的答案。

一般来说，我建议您只在可以证明自己有问题时才担心性能；如果您担心，最好设置一个测试台，用代表性数据填充它，然后看看会发生什么。

“MySQL 可以处理 5 - 25 TB 的数据吗？”是的。不，取决于。如果 - 如您所说 - 您没有索引，您的查询可能会在达到 5TB 之前减慢很长时间。如果它是 5TB / 年的高度可索引数据，那可能没问题。

此问题最常见的解决方案是为所有“常规”工作保留一个“事务性”数据库，并为报告保留一个数据仓库，使用常规的提取/转换/加载作业来移动数据并将其存档.数据仓库通常有一个为查询优化的模式，通常与原始模式完全不同。

如果您想保持一切逻辑一致，您可以使用sharding 和集群 - MySQL 的一种开箱即用的排序功能。

但是，我不会推出自己的“分布式数据库”解决方案。这比你想象的要难得多。