Существуют ли какие-либо библиотеки или компоненты, которые управляют хранением и быстрым поиском пользовательского контента?

Question

Учитывая случай наличия большой и активной пользовательской базы, где каждый пользователь хочет сохранить изображение профиля и некоторые дополнительные изображения или другие артефакты, существуют ли какие-либо библиотеки или структуры, которые позволяют легко хранить и запрашивать такие данные?

Эталонной реализацией будет Haystack Photo Инфраструктура Facebook .

Важны следующие характеристики

• Хранилище данных должно хорошо масштабироваться: добавление ресурсов должно быть прозрачным для приложения, использующего хранилище ( аналогичный вопрос получил ответ, относящийся к Волдеморту LinkedIn ).
• Возможность добавлять метаданные вместе с хранимыми данными.
• Метаданные могут запрашиваться с хорошей производительностью (например, храниться в настраиваемом индексе, таком как Lucene / Solr).
• Быстрый доступ на основе ключей и некоторый промежуточный уровень кэширования

Приветствуются любые рекомендации по библиотекам или инфраструктурам, которые могут быть легко интегрированы в веб-приложение Java.

Обновление : спасибо за первые несколько ответов. Я должен вдаваться в подробности о том, какие ответы ожидаются. Ответ Тобу , хотя не связанный с Java, очень хорош (только что проголосовал). Можно реализовать решение с сочетанием доступа к файловой системе и БД и добавить некоторый промежуточный уровень кэширования, но я считаю, что это пустая трата времени, если кто-то более квалифицированный, чем я, уже спроектировал, внедрил и выполнил лучший решение. Что-то, основанное на решении с базовыми реализациями DB или JCR, хорошо подходит, но реализация другой инфраструктуры - это не то, что я хочу делать.

Answer 1

MogileFS - это то, что использует LiveJournal. Не особенно Java, хотя.

Answer 2

Мы приобрели хороший опыт работы с репозиторием мультимедиа от Fedora Commons (http://www.fedora -commons.org / ), который позволяет вам хранить медиаресурсы вместе с соответствующими метаданными. У нас не было никаких проблем с масштабируемостью или настройкой, и при этом не было трудно обменять базовый уровень хранения с тройным хранилищем (если это потребуется в вашем случае). Если вам нужно проиндексировать данные с помощью Solr, вы можете использовать предопределенное поле метаданных («RELS-EXT») для хранения данных на основе XML.

Answer 3

Зависит от количественной оценки "большой и активной пользовательской базы" ...

80% веб-сайтов могут просто использовать подход без схемы NoSQL, например, y_serial:

модуль y_serial.py :: хранилище объектов Python с SQLite

"Сериализация + постоянство :: в несколько строк кода сжимают и аннотируют объекты Python в SQLite, а затем извлекают их в хронологическом порядке по ключевым словам без какого-либо SQL. Наиболее полезный" стандартный "модуль для базы данных для хранения данных без схемы . "

http://yserial.sourceforge.net

Если фотографии и артефакты на пользователя сжаты не более 2 МБ, производительность должна быть хорошей.

Для оставшихся 20% случаев можно легко импортировать данные из yserial в Cassandra, который теперь используется Facebook, Digg и Twitter.

Answer 4

Apache Jackrabbit - полностью соответствующая реализация API хранилища контента для технологии Java (JCR, определенная в JSR 170 и 283). Но у него есть некоторые проблемы с производительностью (по крайней мере, в двухлетней версии, которую я использую), лучший способ их преодоления - репликация статических изображений на веб-сервер. (С использованием WebDAV, davfs и rsync)

Answer 5

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

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