目前我有一个mysql数据库，收集的数据是每年5 Terrabyte。我会一直保存我的数据，我不认为我想尽早删除一些东西。 我问自己是否应该使用分布式数据库，因为我的数据每年都在增长。 5年后，我将有25 Terrabyte没有索引。 （只计算了我每天保存的原始数据）
我有5个表，大多数查询是多个表的连接。 我需要在特定的时间戳上访问多行的1-2列。
分布式数据库是一个首选的数据库，而不仅仅是一个mysql数据库吗？
分区很难，因为我的所有桌子都是高度连接的。
我知道这取决于查询和数据库表设计，我也可以有一个分布式的mysql数据库。 我只想知道何时应该考虑分布式数据库。 这是一个用例吗？或者mysql可以处理这个大型数据集吗？
编辑：
平均而言，每秒会有1500个客户端写入数据，它们会影响所有表格。
我只需要旧数据集进行分析。像机器学习和 模式匹配。
答案 0 :(得分：3)
你的问题是关于“分发”的，但我看到了需要先回答的更严重的问题。
“高度索引的5TB”将慢慢爬行。索引是BTree。向索引添加新行意味着在该项所属的树中定位块，然后读取 - 修改 - 写入该块。但...
如果索引是AUTO_INCREMENT或TIMESTAMP（或类似的东西），那么被修改的块在BTree的'end'处是'always'。因此几乎所有的读写都是可缓存的。也就是说，更新这样的索引的开销非常低。
如果索引是“随机”，例如UUID，GUID，md5等，那么要更新的块在缓存中很少 。也就是说，为这一行更新这一个索引可能需要花费一对IOP。即使使用SSD，您也可能无法跟上。 （假设您没有几TB的RAM。）
如果索引介于顺序和随机之间（比如某种“名称”），那么BTree中可能会有数千个“热点”，这些可能是可缓存的。
底线：如果你无法避免随机索引，你的项目就注定失败。
下一期......查询。如果您需要为SELECT扫描5TB，那么将需要时间。如果这是一个数据仓库类型的应用程序，并且您需要总结上个月的数据，那么构建和维护摘要表将非常重要。此外，这可以避免对'Fact'表中某些索引的需要，从而可能消除我对索引的关注。
“查看历史数据” - 查看各行？或者只是看一下摘要信息？ （同样，如果它像DW一样，很少需要看到旧的数据点。）如果汇总就足够了，那么25TB的大部分都可以避免。
你有25TB在线机器吗？如果没有，那可能会迫使您拥有多台机器。但是，您将面临跨越它们运行查询的复杂性。
从INT = 4字节等估计5TB？如果使用InnoDB，您需要多次2到3才能获得实际的足迹。此外，如果您将来需要修改表，则此类操作可能需要复制表，以便将所需的磁盘空间加倍。你的25TB变得更像100TB的存储空间。
PARTITIONing的有效用例非常少，所以在了解更多信息之前我不想讨论这个问题。
“Sharding”（跨机器分割）可能就是“分布式”的意思。使用多个表格时，您需要仔细考虑如何分割数据，以便JOINs继续有效。
5TB是巨大的 - 尽你所能缩小它 - 使用较小的数据类型，规范化等。但是不要“过度规范化”，你最终可能会遇到糟糕的性能。 （我们需要查看查询！）
有许多方向来获取多TB数据库。在我们更具体之前，我们确实需要有关您的表和查询的更多信息。
答案 1 :(得分：1)
真的不可能为这么广泛的问题提供具体的答案。
一般情况下，我建议您只有在证明自己遇到问题时才会担心表现;如果您担心，最好设置一个测试装备，用代表性数据填充它，看看会发生什么。
“MySQL可以处理5到25 TB的数据吗？”是。不，取决于。如果 - 正如您所说 - 您没有索引，那么您的查询可能会在达到5TB之前减慢很长时间。如果它是5TB /年的高度可索引数据，它可能没问题。
这个问题最常见的解决方案是为所有“常规”工作保留一个“事务”数据库，并使用常规提取/转换/加载作业来报告数据仓库，以便将数据移动并存档。数据仓库通常具有针对查询优化的模式，通常完全不同于原始模式。
如果你想保持所有内容在逻辑上一致，你可以使用sharding和群集 - 一种类似于MySQL的开箱即用功能。
但是，我不会推出自己的“分布式数据库”解决方案。这比你想象的要难得多。