如何使用.NET有效地提供带有千兆字节数据的FAST ESP

Question

这将是一个棘手的问题，但无论如何我会尝试： 我们的任务是为Microsoft FAST ESP提供千兆字节的数据。索引数据的最终数量在50-60GB左右。

FAST有一个.NET API，但核心组件是用Python编写的（处理管道来索引文档）。面临的挑战是与系统进行可靠的通信，同时为其提供数十亿字节的数据以进行索引。

FAST出现的问题是：

  

  

1. 当系统一次输入太多数据时系统很奇怪   想要重新索引其数据，在此期间系统仍然无法访问   用了几个小时。不可接受的。

  

2. 不能选择排队所有数据并连续提供一个项目   因为这将花费太长时间（几天）。

  

3. 当一个项目无法被FAST索引时，客户端必须重新提供   项目。为此，系统应该调用回调   通知客户端故障的方法。但是，每当   系统超时馈送客户端无法对超时做出反应   因为永远不会调用该回调。因此客户正在挨饿。   数据在队列中但不能传递给系统。该   队列崩溃。数据丢失。你明白了。

  

备注：

  

  
1. 为一件物品喂食物品可能需要几秒钟，最多可达5-8件   一个大项目的小时数。
  
2. 被索引的项目都是二进制和基于文本的。
  
3. 目标是完全索引“仅”48-72h，即它   必须在周末发生。
  
4. 这里有FAST文档处理管道（Python代码）   每个约30个阶段。到目前为止共有27条管道   写入。
  

总结：

  

主要的挑战是为系统提供大大小小的物品，   以恰当的速度（不太快，因为它可能会崩溃或运行   进入记忆问题;不要太慢，因为这需要太长时间），   同时，以并行方式，如异步运行线程。在   我认为必须有一种算法决定何时进食   什么项目和一次多少。想到并行编程。

     

每个队列（进程）都可以使用多个“队列”   某些大小的项目，它们被加载到一个队列中，然后逐个进给（在工作线程中）。

我很好奇是否有人做过这样的事情，或者你会如何处理这样的问题。

  

编辑：同样，我不打算“修复”FAST ESP或改善其内在   运作。挑战在于有效地使用它！

Answer 1

首先，您应该将任务用于此类问题 它们可以在线程池等中启动同步，异步，并且比具有线程锁定的模型更便宜。

我认为，Task.ContinueWith非常适合您的问题。

算法将如下所示：

1. 使用您需要发布的数据收集队列。
2. 启动一个任务（或任务，如果你有风险:)从队列中获取较重的对象（和另一方的最小对象），并开始上传它。
3. 为上传结束创建一个方法，该方法将为新队列项启动新任务。
4. 您可以使用取消令牌进行超时。
5. 每次您都可以定义系统出错的项目。

Answer 2

听起来你正在处理一系列问题，而不是特定的C＃进给速度问题。

预先提出几个问题 - 这个60gb数据是每个周末消耗的，还是系统的初始回填？数据是否作为ESP安装或其他软件本地文件系统上的项目存在？这是一个单一的内部ESP部署还是您希望在多个位置复制的解决方案？单节点安装或多个（或者更确切地说......多少个 - 单节点上限是20个docproc）？

ESP性能通常受到要处理的文档数量超过文件数量的限制。假设您的数据范围介于电子邮件大小35k数据和文件系统大小350k数据之间，那么60gb相当于180k文档和1.8mil文档之间的数据，因此要超过48小时，您需要每小时提供3750到37500个文档。在现代硬件上不是一个非常高的目标（如果你在VM上安装它......好吧......所有的赌注都关闭了，在笔记本电脑上的表现会更好）。

对于喂食，您可以选择更快的编码和通过管理自己喂养的批次或在api中使用DocumentFeeder框架来控制更多的批处理逻辑。如果您只需要37.5k docs / hr，我就可以节省开销，只需使用DocumentFeeder - 尽管请注意其配置参数。文档进纸器允许您基于每个文档处理您的内容，而不是自己创建批次，它还允许基于配置自动重试的一些措施。一般目标应为每批最多50mb内容或100个文档，以先到者为准。较大的文档应该以较小的批次发送...所以如果你有一个50mb的文件，理想情况下应该自己发送，等等。你实际上失去了对文件馈送器形成的批次的控制......所以那里的逻辑对你的代码来说，这是最好的努力。

使用回调来监控内容进入系统的程度。设置了尚未收到最终回调的文件数限制。目标应该是在任何给定时间提交X批次 - 或 - Y Mb，暂停在任一截止点。 X应该是大约20 +＃文档处理器，Y应该在500-1000Mb的区域内。对于文档进纸器，它只是每个文档的通过/失败，传统的系统更加详细。只等待'安全'回调...它告诉你它已被处理＆amp;将被索引...等待它可搜索是没有意义的。

对你的内容设置一些限制......一般情况下，ESP会因非常大的文件而崩溃，因为它仍然是32位触发器，所以硬限制为2gb，但实际上任何超过50mb的内容都应该只有元数据输入。 ...避免提供日志数据，它会破坏内部结构，如果没有错误就杀死性能。事情可以在管道中完成，以修改可搜索的内容，以减轻某些日志数据的痛苦。

还需要确保您的索引配置得很好，至少有6个分区，重点是保持较低阶的索引相当空。在不了解部署的情况下，很难深入了解那个细节。管道配置也会产生很大的影响......没有文件需要花费5-8个小时。确保将自定义实例使用的任何searchexport或htmlexport阶段替换为理智超时（30-60秒） - 默认为无超时。

最后一点......可能性是，无论您的喂食方式如何配置，管道都会在某些文件上出错。您需要准备接受或仅重新提供元数据（还有其他选项，但有点超出范围）。

祝你好运。

Answer 3

你能直接在数据库上使用BULK INSERT吗？如果没有，我建议您与第三方产品的提供商合作，以便您可以共同制定可行的解决方案。

Answer 4

您描述的数据库无法使用。你可以找到一些工作，但你将来会遇到类似的大问题。 ~10gb需要一天的转移和随机重新索引听起来很荒谬。

我的建议是要求您的提供商将数据库置于可用状态（修复错误），或者他们为您提供数据提取，并创建自己的数据库。