Solr: FileListEntityProcessor выполняет подсущности несколько раз

Я настроил dih-import.xml, как показано ниже. FileListEntityProcessor проходит через некоторые папки, а затем выполняет XPathEntity и DB-Entity для каждого файла.

Когда я выполнил полный импорт примерно 30 000 файлов, импорт занял почти 3 часа. Вернувшись к консоли DIH-debug, он показал мне, что для первого найденного файла было сделано 2 db-вызова, для второго 4, затем 6, 8, ..

гугл мне ничего не показал по этому поводу, так что надеюсь на вас :)

заранее спасибо

<?xml version="1.0" encoding="UTF-8"?>
<dataConfig>
    <dataSource 
        name="cr-db"
        jndiName="xyz"
        type="JdbcDataSource" />
    <dataSource 
        name="cr-xml" 
        type="FileDataSource" 
        encoding="utf-8" />


    <document name="doc">
        <entity 
            dataSource="cr-xml" 
            name="f" 
            processor="FileListEntityProcessor" 
            baseDir="/path/to/xml" 
            filename="*.xml" 
            recursive="true" 
            rootEntity="true" 
            onError="skip">
            <entity
                name="xml-data" 
                dataSource="cr-xml" 
                processor="XPathEntityProcessor" 
                forEach="/root" 
                url="${f.fileAbsolutePath}" 
                transformer="DateFormatTransformer" 
                onError="skip">
                <field column="id" xpath="/root/id" /> 

                <field column="A" xpath="/root/a" />
            </entity>

            <entity 
                name="db-data" 
                dataSource="cr-db"
                query="
                    SELECT  
                        id, b
                    FROM 
                        a_table
                    WHERE 
                        id = '${f.file}'">
                <field column="B" name="b" />
            </entity>
        </entity>
    </document>
</dataConfig>

EDIT нашел проблему в Google, но и там нет ответа: http://osdir.com/ml/solr-user.lucene.apache.org/2010-04/msg00138.html


и еще одно изменение

обновил solr с 3.6 до 4.1 и выполнил импортер. Проблема все еще существует, только в том, что больше нет 2n (2, 4, 6, 8, ..) вызовов для подсущностей, а только n.


person harpax    schedule 01.03.2013    source источник
comment
Просто уточнение? Вы пытаетесь создать один документ Solr для каждого файла? Что означает, что у вас есть только одна запись /root? Это правильно?   -  person Alexandre Rafalovitch    schedule 07.03.2013
comment
Это верно. Один документ Solr должен содержать id, A и B, которые работают должным образом, просто не в нужное время и с большой нагрузкой на БД.   -  person harpax    schedule 07.03.2013


Ответы (1)


Если основной проблемой является количество обращений к базе данных при использовании JdbcDataSource, вы можете попробовать переключиться на CachedSqlEntityProcessor. .

Вы также можете отслеживать SOLR-2943, так как они хотят адресовать именно ваш проблема, надеюсь, для предстоящего Solr 4.2

person Alexandre Rafalovitch    schedule 07.03.2013
comment
Спасибо за Ваш ответ. Подобно тому, что я получил здесь: lucene.472066.n3.nabble.com/. Однако это не решение, так как для каждого файла существует 1 запись в базе данных (1:1), поэтому нет ничего, что можно было бы кэшировать. Один процессор (думаю, это FileListEntity) просто делает слишком много вызовов: (n * ( n + 1)) / 2 - person harpax; 11.03.2013
comment
То же самое происходит с файлами, которые находятся в xpathed между прочим. Они вызываются n раз, где n — позиция в возвращаемом наборе FileListEntityProcessor. - person harpax; 11.03.2013
comment
Я заметил, что вы используете источник данных cr-xml как во внешних, так и во внутренних объектах. Можете ли вы проверить, что произойдет, если у вас есть два разных источника данных. Возможно, что источник данных повторно инициализируется во внутреннем объекте и каким-то образом прерывает цикл внешнего объекта. Просто удвойте определение dataSource и дайте им разные имена. - person Alexandre Rafalovitch; 11.03.2013
comment
Я пробовал это, но, к сожалению, с тем же результатом. Сейчас я собираюсь опубликовать сообщение, хотя мне действительно хотелось бы использовать DIH Еще раз спасибо - person harpax; 12.03.2013
comment
Попробуйте еще раз с только что выпущенной версией 4.2. Может, исправили. - person Alexandre Rafalovitch; 13.03.2013