Как да комбинирам използването на 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, за да извличам ключови думи от елементи, които да се съхраняват в базата данни, и да съхранявам обекти, които наричам „разширение на ключова дума“, които сочат към съответните обекти на домейна. Това направи обектите на домейна откриваеми по ключова дума (също така позволявайки произтичане) и раздели проблемите с ключовите думи. Базата данни беше изградена от голям статичен набор от данни (базата данни за хранителни вещества на USDA), така че не трябваше да се тревожа за промени по време на изпълнение. Следователно това решение е ограничено в настоящата си форма ...

Първата част от решението беше да се напише малка част от кода, който взема малко текст и извлича както ключовите думи, така и съответните стъбла (използвайки „снежната топка“ на Lucene) в карта. Използвате това, за да извлечете ключовите думи/стъблата от някои обекти на домейн, които съхранявате в базата данни. Запазих оригиналните ключови думи, за да мога да създам някаква статистика за направените търсения.

Втората част беше да конструирам обекти, които нарекох „разширения на ключови думи“, които съхраняват основите като масив и съответните ключови думи като друг масив и имат указател към съответните обекти на домейн, които имат ключовите думи (използвах масиви, защото работят по-лесно с DB4O). Също така подкласирах моя клас KeywordExtension, за да съответства на типа на обектите на конкретния домейн - така че например съхранявах обект на домейн „Nutrient“ и съответен обект „NutrientKeywordExtension“.

Третата част е да се събере въведения от потребителя текст за търсене, отново да се използва stemmer за извличане на стъблата и търсене на обектите NutrientKeywordExtension с тези стъбла. След това можете да вземете обектите Nutrient, към които сочат тези разширения, и накрая да ги представите като резултати от търсенето.

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

Надявам се този ограничен пример да помогне.

person Sam Stainsby    schedule 30.04.2011
comment
@Sam - благодаря за отговора. Можете ли да ми дадете представа за размера на индекса и колко време е отнело изграждането на първоначалния индекс на телефона. - person Soumya Simanta; 03.05.2011
comment
@Soumyama индексите в този случай са въплътени от набора от обекти KeywordExtension. В базата данни има много повече данни и не съм разбрал какво място заемат тези конкретни обекти. По-голямата част от пространството, което подозирам, е заето от 555 726 обекта за въвеждане на хранителни вещества във всеки случай, което води до файл с база данни от 45 MB. Всичко това е в уеб приложение на Granite (Granite е нашият стек Scala/Wicket/DB4O с отворен код), а не на телефон. Отнема малко повече от минута на 6-ядрен десктоп, за да генерира цялата DB4O база данни от нулата. - person Sam Stainsby; 04.05.2011
comment
@Sam - това е полезна информация. 45 MB е размерът на файла DB4O db или размерът на индекса Lucene? - person Soumya Simanta; 04.05.2011
comment
@Soumya 45 MB е общият размер на файла DB4O db - 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