Как эффективно загружать FAST ESP гигабайтами данных с помощью .NET

Question

Это будет сложный вопрос, но я все равно попробую: наша задача - обеспечить Microsoft FAST ESP гигабайтами данных. Окончательный объем проиндексированных данных находится где-то в районе 50-60 ГБ.

FAST имеет .NET API, но основные компоненты написаны на Python (обработка конвейеров для индексации документов). Задача состоит в том, чтобы надежно обмениваться данными с системой, передавая ей гигабайты данных для индексации.

Проблемы, которые возникают с FAST здесь:

1. система странная, когда в нее подается слишком много данных одновременно хочет переиндексировать свои данные, в течение которых система остается недоступной часами. Неприемлемо.

2. нельзя поставить в очередь все данные и последовательно передать один элемент в то время, как это займет слишком много времени (несколько дней).

3. когда элемент не может быть проиндексирован с помощью FAST, клиент должен повторно заполнить вещь. Чтобы это работало, система должна вызвать обратный вызов способ сообщить клиенту о неудаче. Однако всякий раз, когда тайм-аут системы клиент подачи не может реагировать на тайм-аут потому что этот обратный вызов никогда не вызывается. Следовательно, клиент голодает. Данные находятся в очереди, но не могут быть переданы в систему. очередь рушится. Данные потеряны. Вы поняли.

Примечания:

1. кормление предмета может занять несколько секунд для мелкого предмета и до 5-8 часов для одного крупного предмета.
2. индексируемые элементы являются двоичными и текстовыми.
3. цель состоит в том, чтобы полная индексация заняла "только" 48-72 ч, т.е. должно произойти в выходные дни.
4. Конвейеры обработки документов FAST (код Python) здесь имеют около 30 этапов каждый. На данный момент существует 27 трубопроводов. письменная форма.

В итоге:

Основная задача - снабдить систему предметами, большими и маленькими, только на правильной скорости (не слишком быстро, потому что он может рухнуть или бежать в проблемы с памятью; не слишком медленно, потому что это займет слишком много времени), одновременно, параллельно, как асинхронно работающие потоки. В мое мнение должен быть алгоритм, который решает, когда кормить какие предметы и сколько сразу. На ум приходит параллельное программирование.

Также может быть несколько «очередей», для которых каждая очередь (процесс) выделена элементы определенного размера, которые загружаются в очередь и затем подаются по одному (в рабочих потоках).

Мне любопытно, делал ли кто-нибудь что-нибудь подобное или как бы вы справились с такой проблемой.

РЕДАКТИРОВАТЬ: Опять же, я не ищу, чтобы "исправить" БЫСТРО ESP или улучшить его внутреннюю разработки. Задача состоит в том, чтобы эффективно использовать его!

Answer 1

Звучит так, как будто вы работаете с множеством проблем, выходящих за рамки проблемы скорости подачи C #.

Несколько вопросов наперед - эти 60-гигабайтные данные будут использоваться каждые выходные или это начальная засыпка системы? Существуют ли данные как элементы в файловой системе, локальной для установки ESP или в другом программном обеспечении? Это единое внутреннее развертывание ESP или решение, которое вы хотите тиражировать в нескольких местах? Установка одного узла или нескольких (или, точнее ... сколько - ограничение одного узла составляет 20 документов)?

Производительность ESP обычно ограничена количеством обрабатываемых документов, а не количеством файлов. Если предположить, что ваши данные находятся в диапазоне между размером электронной почты 35 КБ и размером файловой системы 350 КБ, то ваши 60 ГБ равны от 180 КБ до 1,8 млн. Документов, поэтому для подачи данных в течение 48 часов вам необходимо обрабатывать от 3750 до 37500 документов в час. Не очень высокая цель на современном оборудовании (если вы установили это на ВМ ... ну ... все ставки сняты, на ноутбуке было бы лучше).

Для подачи у вас есть выбор между более быстрым кодированием и более широким контролем с управлением пакетами, подаваемыми самостоятельно, или с использованием инфраструктуры DocumentFeeder в API, которая абстрагирует большую часть пакетной логики. Если вы просто используете 37,5 тыс. Документов в час, я бы сэкономил накладные расходы и просто использовал DocumentFeeder, хотя позаботился о его параметрах конфигурации. Податчик документов позволит вам обрабатывать ваш контент отдельно для каждого документа, вместо того, чтобы создавать пакеты самостоятельно, он также даст некоторую меру автоматической повторной попытки на основе конфигурации. Общая цель должна быть максимум 50 МБ контента на пакет или 100 документов, в зависимости от того, что наступит раньше. Большие документы следует отправлять небольшими партиями ... поэтому, если у вас есть файл размером 50 Мб, в идеале он должен отправляться сам по себе и т. Д. Вы фактически потеряете контроль над пакетами, формируемыми устройством подачи документов ... так что логика есть это лучшее усилие со стороны вашего кода.

Используйте обратные вызовы, чтобы отслеживать, насколько хорошо контент попадает в систему. Установите ограничения на количество документов, для которых вы еще не получили окончательные обратные вызовы. Цель должна состоять в том, чтобы X партий были представлены в любой момент времени - или Y Mb, пауза в любой отсечке. X должно быть около 20 + # процессоров документов, Y должно быть в области 500-1000Mb. С фидером документов это просто прохождение / отказ на документ, с традиционной системой это более подробно. Ждать только «защищенного» обратного вызова ... который сообщит вам, что он был обработан и будет проиндексирован ... ждать, пока его можно будет найти, бессмысленно.

Установите некоторые ограничения для вашего контента ... в общем случае ESP сломается с очень большими файлами, есть жесткое ограничение в 2 ГБ, поскольку это все еще 32-битные процессоры, но на самом деле все, что превышает 50 МБ, должно иметь только метаданные. ... избегайте подачи данных журнала, это сокрушит внутренние структуры, убив перфорацию, если не произойдет ошибка. В конвейере можно сделать что-то, чтобы изменить то, что нужно искать, чтобы облегчить боль некоторых данных журнала.

Также необходимо убедиться, что ваш индекс настроен хорошо, по крайней мере, 6 разделов с акцентом на то, чтобы нижние порядка были достаточно пустыми. Трудно вдаваться в детали этого, не зная больше о развертывании. Конфигурация конвейера также может оказать большое влияние ... ни один документ не должен занимать 5-8 часов. Обязательно замените любые этапы searchexport или htmlexport, используемые с пользовательскими экземплярами, на нормальное время ожидания (30-60 секунд) - по умолчанию время ожидания отсутствует.

Последний пункт ... Скорее всего, независимо от того, как настроена подача, конвейер будет давать ошибки в некоторых документах. Вам нужно быть готовым либо принять это, либо ссылаться только на метаданные (есть и другие варианты, но здесь они выходят за рамки возможного).

удачи.

Answer 2

Прежде всего, вы должны использовать задачи для такой задачи.
Их можно запускать синхронизировать, асинхронно, в пуле потоков и т. Д., И намного дешевле в памяти, чем модели с блокировкой потоков.

Я думаю, Task.ContinueWith идеально подходит для вашей задачи.

Алгоритм будет выглядеть так:

1. Соберите очередь с данными, которые нужно опубликовать.
2. Запустите задачу (или задачи, если вы рискуете :), которая берет более тяжелый объект из очереди (и самый маленький объект с другой стороны), и начинайте загрузку.
3. Создайтеметод окончания загрузки, при котором запускается новое задание для нового элемента очереди.
4. Вы можете использовать токены отмены для тайм-аутов.
5. Каждый раз, когда вы можете определить, по какому элементу система получит ошибку.

Answer 3

База данных, как вы ее описали, непригодна для использования . Вы можете найти какую-то работу, но в будущем вы столкнетесь с такими же большими проблемами. ~ 10gb, занимающий день для передачи и случайных переиндексаций, звучит абсурдно.

Я бы посоветовал вам либо потребовать от вашего провайдера перевести базу данных в работоспособное состояние (исправить ошибки), либо предоставить вам извлечение данных, а вы сами создадите базу данных.

Answer 4

Можете ли вы просто использовать BULK INSERT непосредственно в базе данных?Если нет, я предлагаю вам поработать с поставщиком стороннего продукта, чтобы вместе вы могли сформулировать работоспособное решение.