Хранение небольшого количества изображений: блоб или фс?
В Apache Spark есть специальный Rdd, pipedRdd, который обеспечивает вызовы внешних программ, таких как программы C ++ на основе CUDA, для ускорения вычислений.
Я добавляю небольшой пример, чтобы объяснить здесь.
Сценарий оболочки: test.sh
#!/bin/sh
echo "Running shell script"
while read LINE; do
echo ${LINE}!
done
Передача данных rdd в сценарий оболочки
val scriptPath = "/home/hadoop/test.sh"
val pipeRDD = dataRDD.pipe(scriptPath)
pipeRDD.collect()
Теперь создайте scala программа для вызова этой трубы RDD
val proc = Runtime.getRuntime.exec(Array(command))
new Thread("stderr reader for " + command) {
override def run() {
for(line <- Source.fromInputStream(proc.getErrorStream).getLines)
System.err.println(line)
}
}.start()
val lineList = List("hello","how","are","you")
new Thread("stdin writer for " + command) {
override def run() {
val out = new PrintWriter(proc.getOutputStream)
for(elem <- lineList)
out.println(elem)
out.close()
}
}.start()
Spark RDD
val data = sc.parallelize(List("hi","hello","how","are","you"))
val scriptPath = "/root/echo.sh"
val pipeRDD = dataRDD.pipe(scriptPath)
pipeRDD.collect()
Результаты:
Array[String] = Array(Running shell script, hi!, Running shell script, hello!,
Running shell script, how!, Running shell script, are!, you!)
7 ответов
Ответить на части Вашего вопроса:
Как клиенты идут с кэшированием изображений от DB по сравнению с от файловой системы?
Для базы данных: Имейте last_modified поле в своей базе данных. Используйте Измененный в последний раз HTTP-заголовок, таким образом, браузер клиента может кэшироваться правильно. Обязательно отправьте соответствующие ответы, когда браузер запрашивает на изображение, "если более новый" (не может вспомнить то, чем это называют; некоторый заголовок Запроса HTTP).
Для файловой системы: Сделайте то же самое, но с измененным временем файла.
Если БЛОБЫ, сохраненные в DB, являются способом пойти - там что-нибудь, что я должен знать о том, где сохранить их? Так как я предполагаю, что большинство моих пользователей не будет загружать картинку, я должен составить user_pics таблицу к (внешнему) соединению к таблице обычных пользователей при необходимости?
Я поместил бы BLOB и связанные метаданные в его собственной таблице с некоторым отношением между ним и Вашей пользовательской таблицей. Выполнение этого поможет оптимизировать метод устройства хранения данных таблицы для Ваших данных, делает вещи более опрятными, и оставляет место для расширяемости (например, общая таблица "файлов").
Что было бы более удобным, с точки зрения обслуживания их, написания кода для обслуживания их, процедур резервного копирования, и т.д.? Вы хотите правильный ответ для Вас, не правильный ответ для кого-то еще.
Я когда-то столкнулся с подобным вопросом с маленьким DMS для файлов PDF. Сценарий отличался от Вашего: максимум может быть 100 файлами с размерами до 10 МБ каждый - не, что Вы ожидаете для фотографий профиля. Но ответ, который друг дал мне тогда, относится к Вашему случаю также:
Используйте каждую систему хранения для того, что она разработана, чтобы сделать.
Храните данные в базе данных. Храните файлы в файловой системе.
Это не окончательный ответ (*), но это - хорошее эмпирическое правило для начинающих.
Я никогда не слышал о Windows FS, являющемся медленным и иногда ненадежным, как Aaron Digulla заявляет в своем ответе. Если существуют такие проблемы, это, конечно, должно быть включено в. Но для изображений аватара, это не кажется мне важный.
(*) я знаю, я знаю, 42...
С моей точки зрения что-либо, что можно оставить за пределами базы данных, должно остаться снаружи. Это может быть файловой системой или разделить таблицы, которые Вы не копируете или копируете каждый день. Это делает базу данных намного легче, это становится медленнее и это легче понять и поддержать.
Если Вы находитесь на MSSQL, удостоверяются, что блобы хранятся в отдельном файле данных. Не в ОСНОВНОМ как все остальное.
В Windows, помещенном так, как Вы можете в базе данных. Файловая система является несколько медленной и иногда даже ненадежной.
На Linux у Вас есть больше опций. Здесь, необходимо рассмотреть движущиеся большие файлы в файловую систему и просто сохранить имя в DB. При использовании современной файловой системы как Ext3 или ReiseFS можно даже создать много маленьких файлов с довольно хорошей производительностью.
Также необходимо принять во внимание, как можно получить доступ к данным. Если у Вас есть все в DB, у Вас есть один путь доступа, не должен волноваться о другом наборе полномочий, но необходимо иметь дело с дополнительной сложностью чтения/записи БЛОБОВ. Во многих DBS не могут искаться БЛОБЫ.
В файловой системе можно выполнить другие инструменты на данных, которые не возможны, если файлы хранятся в DB.
Я думаю, что существует преимущество managability, хранящее их в базе данных; они могут быть сохранены и последовательно восстанавливаться с другими данными - Вы не забудете удалять устаревшие (хорошо, Вы могли бы, но это немного менее вероятно), и если Вы перемещаете базу данных на другую машину, изображения идут с ним.
Я сохранил бы их в базе данных:
- Резервное копирование/восстановление легко (если Вы файлы резервных копий и также база данных, восстановление момента времени более сложно),
- Транзакции в дб означают, что Вы никогда не должны заканчивать тем, что указали на имя файла, которое не является там
- Меньше шанса кто-то собирается выяснить подлый способ поместить сценарий на Ваш сервер через изворотливый взлом загрузки изображения
Так как Вы говорите о небольшом количестве изображений, простота использования/администрирования должна взять предпочтение по проблемам производительности, которые обсуждены в связанных вопросах.