Lucene - пользовательский анализатор/токенизатор для индексирования значений пары ключей JSON

Question

Я собираюсь хранить и индексировать значения пары ключей JSON. В идеале я бы сохранил их в постоянном поле. (Для простоты, «МАРКИ»)

Пример входящего объекта JSON:

"Data": [{ 
     "Key": "DP01", 
     "Value": "Excellent" 
    }, { 
     "Key": "DP02", 
     "Value": "Average" 
    }, { 
     "Key": "DP03", 
     "Value": "Negative" 
    }] 

Объект JSON будет сериализовать и хранили, как она есть, но хотелось бы, чтобы индекс его таким образом, чтобы я мог искать в этом же поле ключ и значение. Основная идея - поиск нескольких значений в пределах одного поля Lucene.

Любые предложения о том, как структурировать индексирование? Представим, например, что я хотел бы найти, используя следующий запрос:

[GRADES: "key:DP01 UNIQUEIDasDELIMITER value:Excellent"] 

Как анализатор клиент/токенизатор этого достичь?

EDIT: попытка изобразить мою цель более точно.

Подумайте об этом типичном реляционном типе структуры (для простоты).

• Каждый документ является веб-сайтом.

• Веб-сайт может иметь несколько изображений (и другие важные метаданные).

• Каждое изображение имеет несколько наборов бесплатных свойств KeyValuePair:

  { 
      "Key": "Scenery", 
      "Value": "Nature" 
  }, { 
      "Key": "Style", 
      "Value": "Vintage" 
  } 
  

• Другой набор:

  { 
      "Key": "Scenery", 
      "Value": "Industrial" 
  }, { 
      "Key": "Style", 
      "Value": "Vintage" 
  } 
  

Моя задача, пришедшего от подобного типа структуры и индексируют в способ, который позволяет мне строить запросы, такие как:

Сайт с изображением пейзажа: промышленные и стиль: старинные.

Возможно, я ошибаюсь, как указал Энди Пок. Любые идеи, как эффективно сгладить эти свойства?

Answer 1

Обычным «проблемы «означает, что индексы и документы имеют согласованный набор полей. Это не то же самое, что реляционная база данных с таблицами фиксированного набора столбцов.

В предыдущей жизни у меня была сущность с набором «атрибутов». Сбор ключевых/ценностей (как и ваши оценки).

Каждый документ был создан с полями, названными для каждого атрибута, т.е. «attr-thing», с добавленной стоимостью «NOT_ANALYZED».

Таким образом, в вашем примере я бы создавать поля как

new Field("grade-"+gradeID, grade, Field.Store.NO, Field.Index.NOT_ANALYZED) 

Тогда вы можете осуществлять поиск с помощью запроса, как «класс-DP01: отлично».

В качестве альтернативы вы можете просто иметь фиксированное имя поля (аналогично @ cris-almodovar) и установить значение в значение «id = grade». Снова NOT_ANALYZED. Поиск «grade: DP01 = отлично».

Любой будет работать. Я использовал оба подхода с успехом, но обычно предпочитаю первый.

Дополнительные в ответ редактировать ...

Я думаю, я понимаю проблему ... Если бы у вас были «декорация = промышленный стиль = марочной» и «декорация = стиль природы = современный» вы Wouldn» я хочу, чтобы он соответствовал, если бы вы искали «природу и марочные», верно?

Вы можете добавить поле «imageType» для каждого набора со значением, например «scenery = industrial style = vintage abc = xyz» с KeywordAnalyzer (просто разделяется пробелом).

Затем выполните поиск с imageType:"scenery=industrial style=vintage"~2. Использование фразы slop гарантирует, что значения находятся в одном и том же поле, а slop позволяет другому быть другим или для дополнительных значений. Номер, который вы должны были бы определить, исходя из количества свойств, которое вы ожидаете в каждом поле. Упрощенно, если вы ожидаете, что будет максимальное значение N, то slop также должен быть N.

Answer 2

Как насчет хранения данных JSON в многозначном поле, например. КЛАССЫ, как это:

GRADES: "Key DP01 Value Excellent" 
GRADES: "Key DP02 Value Average" 
GRADES: "Key DP03 Value Negative" 

Затем можно выполнить запрос так:

сортов: ("Key DP01" и "Значение Excellent")