在我们的研究所，我们很快就需要定期共享大量数据（多 TB 范围）。
使用 BitTorrent 来完成这个任务有意义吗？
与常见的 FTP 服务器相比，预计 CPU/内存开销有多大？
从一个 BitTorrent 对等体（原始存储服务器）复制到另一个对等体时，是否可以实现与直接 FTP 传输匹配的速度？
非常感谢。
答案1
- 我认为是这样。选择块大小时要小心，因为对于如此大量的数据，块大小需要大于标准大小
- 在传输过程中并不重要，瓶颈是带宽而不是 CPU。首先生成 torrent 元文件（涉及对每个块和整个数据集进行哈希处理）将花费相当长的时间，客户端上传输完成后的最终哈希检查也将花费相当长的时间
- 是的。除非您的连接提供商、客户的提供商或两者之间的某个提供商正在选择性地调整 P2P 流量。
为了缓解第 1 点和第 2 点的问题，如果您可以将数据分割成更小的块，并为每个块提供单独的种子，您可能会发现数据大小更容易处理。
另请注意，如果任何它们所覆盖的文件中的数据已更新。如果一小部分数据发生变化而其余部分不变，您可能会发现 rsync 是一种更高效的解决方案。
数据集中的文件有多大，分布情况如何（几个多 GB 的文件？许多较小的文件？......）？
答案2
您没有提到您的 bittorrent“网格”中将有多少台机器；如果只有几台，那么 bittorrent 可能不值得您费心设置 torrent 文件并将它们发送给人们，再加上运行跟踪器。
我时不时也会想到这一点，而且总是会回想起 BT 的真正用途：在互联网上共享文件，每个人只需贡献一部分带宽。在家庭或工作 100Mbs 网络上，我使用 Web 服务器并传递链接。
答案3
- 是的，很有可能，它可以为您节省大量的带宽成本，但可能会以牺牲每用户平均下载速度为代价。
- 总体来说相当低，显然取决于服务器，但一般来说，一个服务器作为一个相当大规模群体的 BT 对等体，其 CPU 使用率将低于同一服务器通过 FTP 将同一文件发送到许多客户端。
- 一切皆有可能，可能会更快或更慢，这取决于特定时间的群体规模以及许多其他你永远无法确定的因素。
最需要关注的是客户体验，如果您不能让客户感到生气，那么就选择 FTP，因为它是可控的 - 如果他们精通技术，并且了解对您和他们的好处，那么 BT 就没问题。祝您好运。