Как совместить использование db4o для хранения данных и Lucene для индексирования данных для быстрого поиска?

Я новичок и в db4o, и в Lucene.

В настоящее время я использую db4o для сохранения своих данных в приложении для Android. Мне нужна возможность выполнять быстрый поиск, а также предлагать пользователю предложения (например, автозаполнение предложений).

В плакате SO упоминалось об использовании Lucene для индексации данных и db4o для их хранения.

Кто-нибудь реализовал этот подход? Если да, я был бы признателен, если бы они разделяли общий подход? Какие есть альтернативы?


person Soumya Simanta    schedule 27.04.2011    source источник
comment
Я бы пошел использовать lucene только как хранилище данных. нет необходимости в db4o или зачем вам его использовать? (просто сохраните документ как json в сохраненном и неиндексированном, вероятно, сжатом поле)   -  person Karussell    schedule 20.10.2011


Ответы (1)


Я использовал Lucene для извлечения ключевых слов из элементов, которые будут храниться в базе данных, и для хранения объектов, которые я называю «расширениями ключевых слов», которые указывают на соответствующие объекты предметной области. Это сделало объекты предметной области доступными для поиска по ключевому слову (а также позволило определить основу) и разделило проблемы ключевых слов. База данных была создана на основе большого статического набора данных (база данных о пищевых веществах Министерства сельского хозяйства США), поэтому мне не нужно было беспокоиться об изменениях во время выполнения. Таким образом, это решение ограничено в его нынешнем виде...

Первая часть решения заключалась в написании небольшого фрагмента кода, который берет некоторый текст и извлекает оба ключевые слова и соответствующие основы (используя основу Lucene «Snowball») на карту. Вы используете это для извлечения ключевых слов/основ из некоторых объектов предметной области, которые вы храните в базе данных. Я сохранил исходные ключевые слова, чтобы создать своего рода статистику по выполненным поискам.

Вторая часть заключалась в создании объектов, которые я назвал «расширениями ключевых слов», которые хранят основы в виде массива и соответствующие ключевые слова в виде другого массива и имеют указатель на соответствующие объекты предметной области, содержащие ключевые слова (я использовал массивы, потому что они легче работают с ДБ4О). Я также разделил свой класс KeywordExtension на подклассы, чтобы они соответствовали типу объектов предметной области — так, например, я хранил объект домена «Nutrient» и соответствующий объект «NutrientKeywordExtension».

Третья часть состоит в том, чтобы собрать введенный пользователем текст поиска, снова использовать стеммер для извлечения основ и поиска объектов NutrientKeywordExtension с этими основами. Затем вы можете получить объекты Nutrient, на которые указывают эти расширения, и, наконец, представить их в качестве результатов поиска.

Как я уже сказал, моя база данных была статической — она создавалась при первом запуске приложения. В динамической базе данных вам нужно будет беспокоиться о синхронизации питательных веществ и соответствующих расширений ключевых слов. Одним из решений было бы объединить расширение ключевого слова питательного вещества и питательного вещества в один класс, если вы не возражаете против того, чтобы эти вещи были внутри ваших объектов домена (мне это не нравится). В противном случае вам необходимо учитывать расширения ключевых слов каждый раз, когда вы создаете/редактируете/удаляете свои объекты домена.

Я надеюсь, что этот ограниченный пример поможет.

person Sam Stainsby    schedule 30.04.2011
comment
@Sam - спасибо за ответ. Можете ли вы дать мне представление о размере индекса и сколько времени ушло на создание начального индекса на телефоне. - person Soumya Simanta; 03.05.2011
comment
@Sumyama индексы в этом случае воплощены в наборе объектов KeywordExtension. В базе данных гораздо больше данных, и я не понял, какое место занимают эти конкретные объекты. В любом случае, я подозреваю, что большую часть места занимают 555 726 объектов ввода питательных веществ, что приводит к файлу базы данных размером 45 МБ. Все это в веб-приложении Granite (Granite — это наш собственный стек Scala/Wicket/DB4O с открытым исходным кодом), а не в телефоне. Для создания всей базы данных DB4O с нуля на настольном компьютере с 6 ядрами требуется чуть больше минуты. - person Sam Stainsby; 04.05.2011
comment
@Sam - это полезная информация. 45 МБ - это размер файла базы данных DB4O или размер индекса Lucene? - person Soumya Simanta; 04.05.2011
comment
@Soumya 45 МБ - это общий размер файла базы данных DB4O. - person Sam Stainsby; 04.05.2011
comment
@Сэм - спасибо. Не могли бы вы сказать мне размер индекса Lucene? - person Soumya Simanta; 04.05.2011
comment
@Soumya Как я уже говорил, индексы в этом случае представлены набором объектов KeywordExtension ... и я не выяснил, какое пространство занимают эти конкретные объекты. . Это часть размера базы данных, но без дальнейшей работы я не знаю, какая часть. Все, что я могу сказать, это то, что здесь есть один объект расширения для каждого объекта домена. - person Sam Stainsby; 05.05.2011
comment
@Sam Это проект с открытым исходным кодом? Вы собираетесь выпустить код? Сообщество db4o может извлечь пользу из того, что вы сделали (это здорово) - person German; 20.05.2011
comment
В настоящее время не с открытым исходным кодом — это был действительно тестовый пример для нашего фреймворка Granite (с открытым исходным кодом). Буду думать, что с этим делать. - person Sam Stainsby; 21.05.2011
comment
@German — теперь вы можете увидеть базовый веб-интерфейс для базы данных пищевых питательных веществ здесь: nutrients.ofthings.net - person Sam Stainsby; 12.08.2011