Solr схема вопросов - PullRequest
Новая
       13

Solr схема вопросов

1 голос
/ 16 ноября 2011

только что скомпилировал некоторые, как мы надеемся, основные вопросы относительно схем.

Моя ситуация: ранее был многоядерный экземпляр solr, каждое ядро ​​которого содержало свою структуру документа. Хотя информация в документах в одном ядре была связана с документами в других разных ядрах, конкретные правовые ограничения заставляли нас разбирать эти данные в отдельных случаях. Поэтому каждый раз, когда отправлялся запрос к экземпляру solr, запрашивалось несколько ядер, и клиентское приложение «объединяло» и структурировало ответы нескольких отдельных ядер. Для примера: предположим, что мы были музыкальным магазином и, как это ни глупо, у нас было ядро ​​для компакт-дисков, ядро ​​для DVD, ядро ​​для лент и т. Д., У каждого из которых была своя собственная схема; а затем, когда сотрудник проверил запас, все эти ядра вернули свои ответы для приложения на компьютере сотрудника, чтобы прочитать, обработать различные структуры и представить результаты в виде единого списка.

Что ж, юридические ограничения были сняты, и теперь мы объединяем ядра, в значительной степени полагаясь на динамические поля для гибкости схемы. Это, однако, приносит много новых проблем, а также несколько сомнений:

1 - Что лучше: иметь меньшее количество документов, каждое из которых содержит огромное количество полей (мы говорим сотни, иногда тысячи здесь или там, все проиндексированы), или вместо этого разбрасывать информацию в нескольких небольших документах? Исходя из того, что я читал в теории, первый подход был бы целесообразным, но я не думаю, что в каком-либо из случаев рассматривалось такое количество полей.

2 - Можно ли выполнить какой-либо реляционный поиск? Я имею в виду что-то вроде следующих документов: 

     <doc>
        <ID>ALB@1234</ID>
        <artist_t>Metallica</artist>
        <album_t>Saint Anger</album>        
      </doc>

      <doc>
        <ID>PROD@12</ID>
        <AlbID>ALB@1234</AlbID>
        <format_t>CD</format_t>
        <price_m>8.99</price_m>     
      </doc>

      <doc>
        <ID>PROD@13</ID>
        <AlbID>ALB@1234</AlbID>         
        <format_t>MP3</format_t>
        <price_m>3.99</price_m>     
      </doc>

и после поиска Metallica все три документа были найдены? Имейте в виду, что подход к сохранению информации о двух последних документах в первом как многозначном на самом деле не вариант, потому что, насколько я знаю, не будет никакого способа p.e. поиск правильного формата, соответствующего поиску диапазона по цене.

3 - В качестве альтернативы, возможно ли определить какую-либо структуру поддокумента как часть документа, как в многоуровневом документе? Опять же, я не имею в виду многозначные или многозначные поля, поскольку, насколько я знаю, они не подходят для более сложной и структурированной информации. Было думать о чем-то вроде: 

    <doc>
        <ID>ALB@1234</ID>
        <artist_t>Metallica</artist>
        <album_t>Saint Anger</album>        
        <formats>
            <format_x><ID>PROD@13</ID><AlbID>ALB@1234</AlbID><format_t>MP3</format_t><price_m>3.99</price_m></format_x>     
            <format_x><ID>PROD@12</ID><AlbID>ALB@1234</AlbID><format_t>CD</format_t><price_m>8.99</price_m></format_x>      
        </formats>          
      </doc>

4. Следует учитывать: конечно, эту ситуацию можно исправить, смоделировав схему, как описано в 2), и выполнив более одного запроса к серверу, но на самом деле это не самое желаемое решение.

Ждем любого комментария или предложения. Избиение немного менее приветствуется, но все же приемлемо, просто будь осторожен со мной. ;) И я извиняюсь, если эти вопросы звучат глупо, но здесь действительно нужна помощь.

1 Ответ

5 голосов
/ 16 ноября 2011

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

Для реляционного поиска Solr ввел функцию Solr Join , которая поможет вам объединять документы.
Однако это доступно только для Solr Trunk.Поэтому, если вы не можете работать со сборкой Solr Trunk, это не вариант для вас.

У Solr отсутствует структура поддокумента.Однако вы можете попробовать использовать многозначные поля для сопоставления содержимого.Или даже использовать значения с разделителями.

<album>
    <cd_id>
        <str>cd_1</str>
        <str>cd_2</str>
    </cd_id>
    <cd_price>
        <str>cd_1_price</str>
        <str>cd_2_price</str>
    </cd_price>
</album>

Порядок многозначных полей следует сохранить (чтобы вы могли сопоставить cd_1 с cd_1_price с позицией 1), и вы сможете воссоздать данные на стороне клиента.

...