如何用.net有效地为FAST ESP提供千兆字节的数据

本文关键字：字节 数据 ESP net 何用 有效地 FAST | 更新日期: 2023-09-27 18:07:57

这将是一个棘手的问题，但我将尝试:我们的任务是为微软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条管道写作。
在简介:

主要的挑战是为系统提供大大小小的项目，以合适的速度(不要太快，因为它可能会崩溃或运行)记忆问题;不要太慢，因为这会花很长时间)，同时，以类似异步运行线程的并行方式。在我的观点是，必须有一个算法来决定何时喂食什么项目，一次多少。我想到了并行编程。

也可以有多个"队列";每个队列(进程)专用于哪里在队列中加载一定大小的项，然后一个接一个地(在工作线程中)提供。

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

编辑:再一次，我不指望"修复";快速ESP或改善其内部运作。挑战在于如何有效地利用它!

如何用.net有效地为FAST ESP提供千兆字节的数据

听起来你在处理一系列问题，而不仅仅是一个特定的c#馈送速度问题。

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

ESP性能通常受到要处理的文档数量而不是文件数量的限制。假设您的数据大小介于电子邮件大小(35k)和文件系统大小(350k)之间，那么60gb相当于180k到180万文档之间，因此要在48小时内提供这些文档，您需要每小时提供3750到37500个文档。在现代硬件上，这不是一个非常高的目标(如果您将其安装在VM上…嗯…所有的赌注都没有了，最好是笔记本电脑)。

对于馈送，您可以选择更快的编码&通过管理自己提供的批处理或使用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阶段——默认情况下没有超时。

最后一点……无论如何配置馈送，管道都可能在某些文档上出错。您需要准备好要么接受它，要么只重新提供元数据(还有其他选项，但有点超出了这里的范围)。

好运。

首先，您应该使用针对此类问题的任务。
它们可以同步启动，异步启动，在线程池中启动等，并且比具有线程锁定的模型占用内存少得多。

我想，任务。ContinueWith非常适合你的问题。

算法如下:

  1. 收集需要发布的数据队列。
  2. 启动一个任务(或多个任务，如果你是冒险的:)，从队列中取出较重的对象。(和最小的对象从另一边)，并开始上传。
  3. 创建一个上传结束方法，为新的队列项启动新的任务。
  4. 可以对超时使用取消令牌
  5. 每次你可以定义系统在什么项目上得到错误。

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

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

我的建议是，要么要求你的提供者获得可用状态的数据库(修复错误)，要么他们给你一个数据提取，你做你自己的数据库。

相关文章：