2012-01-13 2 views
0

Я хочу хранить объекты Java как часть документа Solr. Их не нужно анализировать или искать, их можно вернуть только как часть документа. Я могу преобразовать их в json или XML и сохранить текст, но я предпочитаю что-то более эффективное. Если бы я мог использовать сериализацию Java, а затем добавить двоичный блок в документ, это может быть идеальным. Я знаю о возможности конвертировать двоичный блок с base64, но мне было интересно, есть ли более эффективный способ.Как хранить объекты Java на Solr

+0

Благодарим за предоставление отличных альтернатив. Мои объекты очень маленькие, и я хотел бы сравнить эффективность их возврата непосредственно с результатами запроса solr и опцией базы данных. –

ответ

0

Я не разделяю мнения первых двух ответов.

Дополнительный вызов базы данных в некоторых сценариях может быть совершенно ненужным, Solr также может работать как база данных NoSQL.

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

Посмотрите на BinaryField и ленивые декларации полей загрузки внутри вашего schema.xml.

+0

SOLR не может использовать сжатие. Некоторое время назад это устарело. Однако вы можете сжать поле самостоятельно, прежде чем отправлять его в SOLR, это либо BinaryField, либо строка с кодировкой base64. –

+0

@ Майкл Диллон Спасибо за указание на это обстоятельство - кажется, что мои знания немного устарели в этой области – Omnaest

2

Поскольку вы можете построить идентификатор в Solr для передачи с любым документом, вы можете сохранить этот объект другим способом (например, базу данных) и запросить его, когда вы вернете идентификатор из solr.

Например, мы храним веб-страницы в Solr. Когда мы индексируем его, мы создаем идентификатор, который соответствует идентификатору объекта WebPage, созданного ORM в базе данных.

Когда поиск выполняется, мы возвращаем идентификатор и загружаем java-объект из базы данных

нет необходимости хранить его в Solr (которое было сделано для хранения и индексирования документов)

+1

Я согласен, что Solr на самом деле не предназначен как хранилище персистентности, особенно для двоичных объектов. –

+0

Я второй, что полностью. Хотя я уверен, что вы могли бы придумать какой-нибудь хак, чтобы помещать сериализованный объект Java в свой индекс Solr, я бы не рекомендовал его. Храните его в другом месте. В конечном итоге использование вашего индекса Solr таким образом повредит вам. Производительность будет уменьшаться, размер индекса увеличится, репликация master/slave займет больше времени и т. Д. – rfeak

+0

Спасибо. Я начал с этого варианта, но хотел сравнить производительность с решением Solr. –

0

Я согласен, что вы не должны использовать Solr в качестве базы данных, особенно для двоичных данных.

Я предлагаю вам использовать одну из баз данных NoSQL (например, Neo4j, MongoDB, CouchDB, Riak, ...) cuz 'Большинство из них поддерживают json/bson и отлично работают с Solr, что на самом деле также является NoSQL, document тип, хранилище данных, предназначенное для поиска.

Вы можете, например, создать свой собственный обработчик запросов Solr, который будет использовать doc ID (первичный ключ) возвращенных документов для запроса хранилища данных NoSQL и составления поискового ответа. Кроме того, вы можете напрямую запросить NoSQL db из своего клиентского приложения после получения ответа Solr.

Смежные вопросы