Как хранить данные дерева в индексе Lucene / Solr / Elasticsearch или в базе данных NoSQL?

Question

Скажем, вместо документов у меня есть небольшие деревья, которые мне нужно хранить в индексе Lucene. Как мне это сделать?

Пример узла в дереве:

class Node
{
    String data;
    String type;
    List<Node> children;
}

В вышеприведенном узле переменная-член «data» - это строка слов, разделенных пробелами, так что она должна быть доступна для полнотекстового поиска. Переменная типа "type" - это просто одно слово.

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

Как лучше всего индексировать данные такого рода? Если Lucene не поддерживает индексацию этих данных напрямую, может ли это сделать Solr или Elasticsearch?

Я быстро взглянул на neo4j, но, похоже, в БД хранится целый граф, а не большая коллекция (скажем, миллиарды или триллионы) небольших древовидных структур. Или мое понимание было неверным?

Кроме того, решение NoSQL, не основанное на Lucene, лучше подходит для этого?

Answer 1

Другой подход - сохранить представление текущего местоположения узла в дереве.Например, 17-й лист 3-го узла 2-го уровня 1-го узла 1-го уровня 14-го дерева был бы представлен как 014.001.003.017 .

Предполагая, что 'treepath' являетсяимя поля расположения дерева, вы бы запросили «treepath: 014 *», чтобы найти все узлы и листья в 14-м дереве.Точно так же, чтобы найти всех потомков 14-го дерева, вы бы запросили «treepath: 014. *».

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

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

Answer 2

Это требование и решение приведены здесь: Предложение для вложенных документов

Этот дизайн был впоследствии реализован как в ядре Lucene, так и в Elastic Search.BlockJoinQuery является базовой реализацией Lucene, и Elastic Search, как показано здесь, имеет реализацию, описанную здесь: Вложенные документы для упругого поиска

Answer 3

Я предлагаю Neo4j.В конце концов, дерево - это всего лишь специальный, сдержанный граф.

Посмотрите эту великую дискуссию о том, следует ли хранить дерево в Neo4j:

http://www.mail -archive.com/user@lists.neo4j.org/msg03256.html

Answer 4

Есть проект SIREn http://rdelbru.github.io/SIREn который имеет дело с «глубокими» деревьями, обращаясь. Внутренне использует нумерацию Дьюи (http://www.ipl.org/div/farq/deweyFARQ.html) ....