Solr - Есть ли способ ускорить мой импорт

Question

У меня есть реляционная модель базы данных Это основа моих данных-config.xml

<entity name="MyMainEntity" pk="pID" query="select ... from [dbo].[TableA] inner join TableB on ..."> 
    <entity name="Entity1" pk="Id1" query="SELECT [Text] Tag from [Table2] where ResourceId = '${MyMainEntity.pId}'"></entity> 
      <entity name="Entity1" pk="Id2" query="SELECT [Text] Tag from [Table2] where ResourceId2 = '${MyMainEntity.pId}'"></entity> 
    <entity name="LibraryItem" pk="ResourceId" 
      query="select SKU 
        FROM [TableB] 
        INNER JOIN ... 
        ON ... 
        INNER JOIN ... 
        ON ... 
        WHERE ... AND ...'"> 
    </entity> 
</entity> 

Теперь, это занимает много времени.
10000 строк в первом запросе, а затем вторые внутренние объекты выбираются позже (около 10 строк каждая).

Если я использую профилировщик db, я вижу, что запрос на три внутренних объекта работает снова и снова (3 выбирает предложения, чем снова 3 выбирает предложения снова и снова)
Это действительно неэффективно.
И импорт может работать более 40 часов()
Теперь,
Каковы мои возможности запускать его быстрее.

1. Очевидно, что есть возможность поместить столы в один большой стол, но это создаст много других побочных эффектов. Мне бы очень хотелось избежать дополнительных усилий и запустить solr на моих реляционных таблицах.
   Пока это отлично работает, и я ищу здесь, если есть настройка конфигурации.
2. Если я буду выравнивать строки, которые - тоже нужно изменить schema.xml? или те же поля, которые являются многозначными, будут оставаться многозначными.

Спасибо.

Answer 1

без изменения схемы БД, первое, что нужно попробовать - caching. Если внутренние объекты кэшируются хорошо, выигрыши будут существенными.

Возможно, вики не устарели, поэтому вы должны проверить проблемы с jira, а именно solr-2382 и, возможно, взгляните на solr-2948.

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