Nutch 1.17 Web爬网和存储优化

如何解决Nutch 1.17 Web爬网和存储优化

我正在使用Nutch 1.17来爬行超过百万个网站。为此，我必须执行以下操作。

将爬网程序作为深度爬网程序运行一次，以便它应从给定的（100万个）域中获取最大的URL。第一次，您最多可以运行48小时。
此后，在5到6个小时后运行具有相同100万个域的搜寻器，并仅选择这些域上的新URL。
工作完成后，在Solr中索引URL
以后，无需存储原始HTML，因此可以节省存储（HDFS），仅删除原始数据并维护每个页面的元数据，因此在下一个作业中，我们应避免再次重新获取页面（之前预定时间）。

没有任何其他处理或后期分析。现在，我可以选择使用中等大小的Hadoop集群（最多30台机器）。每台机器都有16GB RAM，12个核心和2 TB存储。 Solr机器的空间也相同。现在，要保持上述状态，我对以下内容感到好奇：

a. How to achieve above document crawl rate i.e.,how many machines are enough ? 
b. Should I need to add more machines or is there any better solution ?
c. Is it possible to remove raw data from Nutch and keep Metadata only ?
d. Is there any best strategy to achieve the above objectives.

解决方法

a。如何达到上述文档爬网率，即多少台计算机就足够了？

假设选择了在连续两次提取到同一域之间的礼貌延迟：假设每个域最多可以提取10页，分钟为最大值。抓取速度为每小时6亿页（10^6*10*60）。具有360个核心的群集应足以接近该速率。是否可以在48小时内彻底抓取一百万个域，取决于每个域的大小。请记住，上述提到的每个域每分钟10页的抓取速度，只能在48小时内提取每个域10*60*48 = 28800个页面。

c。是否可以从Nutch删除原始数据并仅保留元数据？

索引段后，您可以将其删除。 CrawlDb足以确定在100万个主页之一中找到的链接是否是新的。

工作完成后，在Solr中索引URL

也许在每个周期之后立即进行索引细分。

b。我应该添加更多计算机还是有更好的解决方案？ d。有什么最佳策略可以实现上述目标。

很大程度上取决于域的大小是否相似。如果它们显示出幂律分布（很可能），则您的域很少有几百万个页面（很难详尽地爬网），而域长的尾巴则只有几页（最多几百页）。在这种情况下，您需要较少的资源，但是需要更多的时间来达到预期的效果。