5

这将是一个棘手的问题，但无论如何我都会尝试：我们的任务是为 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 或改进其内部运作。挑战在于有效地使用它！

4

4 回答 4

1

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

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

算法将如下所示：

  1. 收集包含您需要发布的数据的队列。
  2. 启动一个任务（或多个任务，如果你有风险的话：）它从队列中获取较重的对象。（以及从另一侧获取的最小对象），然后开始上传它。
  3. 创建一个用于结束上传的方法，该方法将为新队列项启动新任务。
  4. 您可以将取消令牌用于超时。
  5. 每次您都可以定义系统出错的项目。
于 2011-09-06T11:59:01.277 回答
1

听起来您正在处理一组问题，而不是特定的 C# 馈送速度问题。

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

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

对于喂食，您可以在更快的编码和更多控制之间进行选择，既可以管理自己喂食的批次，也可以使用 API 中的 DocumentFeeder 框架，该框架抽象了很多批处理逻辑。如果您只需要 37.5k 文档/小时，我会节省开销并只使用 DocumentFeeder - 尽管要注意其配置参数。Document feeder 将允许您基于每个文档处理您的内容，而不是自己创建批次，它还将允许基于配置自动重试的某种措施。一般目标应该是每批最多 50mb 的内容或 100 个文档，以先到者为准。较大的文档应该以较小的批次发送...因此，如果您有一个 50mb 的文件，理想情况下它应该自己发送，等等。您实际上会失去对文档进纸器形成的批次的控制...

使用回调来监控内容进入系统的情况。设置您尚未收到最终回调的文档数量的限制。目标应该是在任何给定时间提交 X 个批次 - 或 - Y Mb，在任一截止时间暂停。X 应该是大约 20 + # 个文档处理器，Y 应该在 500-1000Mb 的范围内。使用文档进纸器，它只是每个文档的通过/失败，使用传统系统，它更详细。只等待“安全”回调...告诉您它已被处理并将被索引...等待它可搜索是没有意义的。

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

还需要确保您的索引配置得很好，至少有 6 个分区，重点是保持较低顺序的分区相当空。如果不了解有关部署的更多信息，很难深入了解该细节。管道配置也会产生很大的影响......任何文档都不应该花费 5-8 小时。确保将用于自定义实例的任何 searchexport 或 htmlexport 阶段替换为合理的超时（30-60 秒） - 默认为无超时。

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

祝你好运。

于 2011-09-10T06:48:54.807 回答
0

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

于 2011-09-06T12:01:57.747 回答
0

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

我的建议是要么要求您的提供商让数据库处于可用状态（修复错误），要么他们为您提供数据提取，然后您制作自己的数据库。

于 2011-09-06T12:32:13.953 回答