分布式数据库用例

Question

目前，我确实有一个mysql数据库，而iam每年收集的数据是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类似，人们很少需要看到旧的数据点。)如果总结就足够了，那么大多数25 be是可以避免的。

你有在线25 Do的机器吗？如果没有，这可能会迫使您拥有多台机器。但是，您将具有跨它们运行查询的复杂性。

5TB是从INT =4个字节来估计的，等等？如果使用InnoDB，则需要乘以2到3才能获得实际占用空间。此外，如果将来需要修改表，这种操作可能需要复制表，从而使所需的磁盘空间翻一番。你的25 of变得更像100 of的存储。

PARTITIONing几乎没有有效的用例，所以在了解更多之前，我不想讨论这个问题。

“切分”(在机器之间分裂)可能就是你所说的“分布式”。对于多个表，您需要认真考虑如何分割数据，以便JOINs能够继续工作。

5TB是巨大的--尽你所能缩小它--使用更小的数据类型，标准化等等。但是不要“过度正常化”，你可能会以糟糕的性能结束。(我们需要查看查询！)

使用多TB分贝有很多方向。我们确实需要更多关于您的表和查询的信息，然后才能更加具体。

Answer 2

要对这么广泛的问题提供一个具体的答案是不可能的。

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

“MySQL能处理5-25 TB的数据吗？”是。不是的。视情况而定。如果--正如您说的--您没有索引，那么在进入5TB之前，查询速度可能会减慢很长一段时间。如果它是5TB /年的高度可索引的数据，它可能是好的。

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

如果您想保持所有事物逻辑上的一致性，可以使用切分和集群--一种排序-一种-- MySQL的开箱即用特性。

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