Joh*_*ohn 5 .net c# database parallel-processing fast-esp
这将是一个棘手的问题,但无论如何我都会尝试:我们的任务是为数据提供千兆字节的Microsoft FAST ESP.索引数据的最终数量在50-60GB左右.
FAST有一个.NET API,但核心组件是用Python编写的(处理管道索引文档).面临的挑战是与系统可靠地通信,同时为其提供数十亿字节的数据以进行索引.
这里FAST出现的问题是:
当系统一次输入过多数据时系统很古怪,因为它想重新索引数据,在此期间系统几小时内无法连接.不能接受的.
它不是一个选项,可以排队所有数据并一次连续输入一个项目,因为这将花费太长时间(几天).
当一个项目无法通过FAST索引时,客户端必须重新提供该项目.为此,系统应调用回调方法来通知客户端故障.但是,每当系统超时时,馈送客户端都无法对超时做出反应,因为永远不会调用该回调.因此客户正在挨饿.数据在队列中但不能传递给系统.队列崩溃了.数据丢失.你明白了.
笔记:
- 为一件小物品喂食一件物品可能需要几秒钟,而对于一件大件物品而言可能需要多达5-8小时.
- 被索引的项目都是二进制和基于文本的.
- 目标是完全索引"仅"48-72h,即它必须在周末发生.
- 这里的FAST文档处理管道(Python代码)大约有30个阶段.在撰写本文时,共有27个管道.
综上所述:
主要的挑战是以合适的速度为系统提供大小物品(不要太快,因为它可能会崩溃或遇到内存问题;不要太慢,因为这需要太长时间),同时,并行像异步运行线程的方式.在我看来,必须有一个算法,决定何时提供什么项目和一次多少.想到并行编程.
还可能存在多个"队列",其中每个队列(进程)专用于某些大小的项目,这些项目被加载到队列中然后逐个进给(在工作线程中).
我很好奇,如果有人做过这样的事情,或者你将如何解决这样的问题.
编辑:同样,我不打算"修复"FAST ESP或改善其内部运作.挑战是有效地使用它!
小智 1
听起来您正在处理一系列问题，而不仅仅是特定的 C# 进给速度问题。
前面有几个问题 - 这 60GB 数据是每个周末都会消耗还是系统的初始回填？数据是否作为 ESP 安装或其他软件本地文件系统上的项目存在？这是单个内部 ESP 部署还是您希望在多个地方复制的解决方案？单节点安装还是多个（或者更确切地说......有多少 - 单节点上限为 20 个 docproc）？
ESP 性能通常受到要处理的文档数量多于文件数量的限制。假设您的数据范围介于电子邮件大小 35k 数据和文件系统大小 350k 数据之间，则 60GB 相当于 180k 文档到 180 万个文档，因此要在 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 阶段 - 默认为无超时。
最后一点...很可能，无论您的馈送配置如何，管道在某些文档上都会出错。您需要准备好接受该选项或仅重新提供元数据（还有其他选项，但有点超出了此处的范围）。
祝你好运。