如何使用.NET高效地向FAST ESP提供以GB计的数据

Question

这将是一个棘手的问题，但我会尝试回答： 我们的任务是向Microsoft FAST ESP提供数千兆字节的数据。最终索引数据量约为50-60GB。

FAST具有.NET API，但核心组件是用Python编写的（处理索引文档的处理管道）。挑战在于可靠地与系统通信，同时向其提供大量数据进行索引。

FAST面临的问题有：

1. 当一次输入太多数据时，系统会变得古怪，因为它想要重新索引其数据，此时系统将在数小时内无法访问。这是不可接受的。 2. 不能将所有数据排队并逐个串行地提供，因为这将需要太长时间（几天）。 3. 当FAST无法对项目进行索引时，客户端必须重新提供该项目。为了使其正常工作，系统应调用回调方法来通知客户端发生故障。然而，每当系统超时时，馈送客户端就无法对超时做出反应，因为从未调用过该回调。因此，客户端处于饥饿状态。数据在队列中，但无法传递到系统。队列崩溃。数据丢失。你懂的。

注意事项：

1. 对于小型项目，馈送可能需要几秒钟，对于单个大型项目，可能需要5-8小时。 2. 正在索引的项目既是二进制的，也是基于文本的。 3. 目标是全面索引仅需48-72小时，即必须在周末完成。 4. FAST文档处理管道（Python代码）每个管道大约有30个阶段。截至本篇写作时，共有27个管道。

总之：

主要挑战是以恰当的速度（不要太快，因为可能会崩溃或遇到内存问题；不要太慢，因为这将需要太长时间），同时以并行方式（如异步运行线程）提供大小不同的项目。我认为应该有一个算法来决定何时提供哪些项目以及一次提供多少个项目。并行编程是一个好方法。

还可以有多个“队列”，其中每个队列（进程）专门用于加载特定大小的项目，然后逐个提供（在工作线程中）。

我很想知道是否有人做过这样的事情，或者您如何解决这个问题。

编辑：再次强调，我不是要“修复”FAST ESP或改进其内部工作原理。挑战在于有效地使用它！

- John

---

你有多少个“大件物品”？看起来除此之外的所有问题都可能阻止你达到72小时的标志。 - Yuck

你需要提供一些我们可以使用的东西。目前来看，由于我们没有上下文，回答你的问题将非常困难。你需要提供更多信息，并尽可能详细地描述。 - Security Hound

目前很难确定您的问题是来自第三方产品中的错误还是其他原因。数据丢失等问题听起来像是该产品中的错误。也许一个非技术的方法是请求修复这些错误。 - Daniel Hilgarth

请备份数据库并将其重新编写为易于理解的格式。 :) - Tom Squires

@大家好：我现在可以告诉你们，我们正在使用微软的FAST ESP作为索引产品。虽然我们正在与微软合作，但该问题根深蒂固，我对于FAST系统内部内存问题和其他限制是否有可行的解决方案持怀疑态度。 - John

Answer 1

首先，您应该为这样的问题使用任务。
它们可以同步、异步、在线程池中启动等，而且比具有线程锁定的模型更节省内存。

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

算法将如下：

1. 收集需要发布的数据队列。
2. 启动一个任务（或者如果您冒险的话，可以启动多个任务），从队列中取出较重的对象（从另一侧取出最小的对象），并开始上传。
3. 创建一个上传结束的方法，该方法将为新的队列项启动新的任务。
4. 您可以使用取消令牌来设置超时时间。
5. 每次您都可以确定系统在哪个项目上出错。

- VMAtm

---

谢谢。这正是我所寻找的输入类型。 - John

Answer 2

听起来你正在处理一系列的问题而不是特定的C#喂食速度问题。

首先有几个问题 - 这60GB的数据每个周末都要使用吗？还是它是系统的初始回填？数据是否存在于ESP安装本地文件系统中的项或其他地方？这是单个内部ESP部署还是您要在多个位置复制的解决方案？单节点安装还是多个（或者......有多少-单节点容量为20 docprocs）？

ESP性能通常受到要处理的文档数量的限制，而不是文件数量。假设你的数据范围介于电子邮件大小的35k数据和文件系统大小的350k数据之间，那么你的60GB相当于180k文档和1.8百万文档之间，因此在48小时内喂养需要每小时喂养3750到37500个文档。对于现代硬件来说并不是一个很高的目标（如果你将其安装在虚拟机上......好吧......所有的赌注都取消了，最好是在笔记本电脑上）。

在馈送方面，您可以选择更快的编码和更多的控制，要么自己管理馈送批次，要么使用API中的DocumentFeeder框架，该框架抽象了很多批处理逻辑。如果您只需要每小时37.5k个文档，我建议您节省开销并使用DocumentFeeder - 但是请注意其配置参数。文档馈送器将允许您按照每个文档的方式处理内容，而不是自己创建批次，它还将允许根据配置进行一定程度的自动重试。一般目标应为每批最大50mb内容或100个文档，以先到者为准。较大的文档应分批发送...因此，如果您有一个50mb的文件，最好单独发送。您实际上会失去由文档馈送器形成的批次的控制...因此，那里的逻辑在您的代码方面是最佳努力。

使用回调函数来监控内容是否成功进入系统。设置限制，即有多少文档已被提供，但尚未收到最终回调。目标应该是在任何给定时间提交X批次 -或- Y Mb，达到任一截止点时暂停。X应该约为20 +文档处理器的数量，Y应该在500-1000Mb左右。使用文档馈送器只需每个文档进行通过/失败测试，而传统系统则更加详细。只等待“已安全”回调...这告诉您它已被处理并将被索引...等待其可搜索是毫无意义的。

对内容设置一些限制...通常情况下，ESP会因非常大的文件而崩溃，在32位处理器上有一个硬性限制为2GB，但实际上，超过50MB的任何内容都应该只提供元数据。此外...避免提供日志数据，否则会破坏内部结构，如果没有错误，则会影响性能。可以在管道中执行操作以修改可搜索的内容，以缓解某些日志数据的痛苦。

还需要确保您的索引配置良好，至少有6个分区，并专注于保持较低顺序的分区相对较空。如果不了解部署的详细信息，很难深入讨论这一点。管道配置也可能会产生很大影响...没有任何文档应该花费5-8小时。请确保使用具有合理超时时间（30-60秒）的自定义实例替换任何正在使用的searchexport或htmlexport阶段 - 默认情况下没有超时。

最后一点...无论您的馈送如何配置，管道都可能在某些文档上出现错误。您需要准备好接受这一点或仅重新提供元数据（还有其他选项，但有点超出范围）。

祝你好运。

- sbaker

---

非常抱歉让您等了这么久，这是单节点安装。我还没有确定文档的确切数量，但您对解决这个问题的一般方法非常出色。我猜想您在这方面有实际经验？:) 再次感谢您。 - John

嗨，不用担心延迟...我自己回复也不是很快。是的，有很多现实世界的经验...在 MS 之前曾为 Fast 工作，并将其作为我的日常工作。如果只是为了将文件导入（没有外部元数据），可能需要查看您是否已获得 filetraverser 的许可；这是 Fast 生产的最佳饲料器（具有讽刺意味的是用 Python 编写），但可以像冠军一样处理所有批处理和重试。使用单个节点安装，处理起来会更容易一些...如果只是一次性推送 60Gb，那就更简单了（相对于每周 60Gb）。当它运行良好时，fast/esp 是非常好的...但容易出现问题。 - sbaker

嗨，不知何故stackoverflow没有通知我有新评论，但无论如何。目前我们正在使用一个手写的C#组件来减缓数据流到文档调度程序/文档处理器，因为文档进来得太快了，索引就会关闭（据我所知，它需要重新索引数据，大约需要8小时）。因此，他们使用一堆线程将其减速到最大数量的文档或MB。然后，每个线程等待FAST API的异步回调来通知调用者。此时，我们仍在调查是否实际上需要这样做。你的想法是什么？ - John

Answer 3

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

- Kieren Johnstone

Answer 4

你所描述的数据库是无法使用的。你可能会找到一些解决方法，但未来你将遇到类似的大问题。 ~10gb需要一天时间传输和随机重建索引听起来很荒谬。

我的建议是要么要求你的供应商使数据库处于可用状态（修复错误），要么让他们提供数据提取并自己创建数据库。

- Tom Squires