Как хранить изображения в mongodb

Как мне отправить картинку в базу данных MongoDB?

Мне нужно отправить картинку в базу данных, чтобы потом можно было по запросу ее оттуда получить и отобразить на странице. У меня вопрос в реализации. Кааак? Я поизучал этот вопрос, но там и не смог ничего сделать Можно просто закодировать в base64. (типо ты просто кодируешь и отправляешь это в виде строки я так понимаю, а получаешь и Декодируешь обратно в картинку, это так работает? Если да, то как это сделать?) Пишу на NodeJS express, база данных MongoDB

Отслеживать
задан 4 апр 2021 в 20:01
максим фефилов максим фефилов
1 2 2 бронзовых знака
23 ноя 2021 в 7:26
Я думаю в твоем случая самое простое будет заюзать либу node-base64-image — npm
16 фев 2022 в 18:52

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Хранишь картинку на сервере — в базе путь до неё.

Отслеживать
ответ дан 4 апр 2021 в 20:03
Senbonzakuraa Senbonzakuraa
620 4 4 серебряных знака 18 18 бронзовых знаков
Я не очень понимаю, всмысле на сервере?
4 апр 2021 в 20:05
Как можно ханить картинку на сервере?
4 апр 2021 в 20:05
а где по твоему хранится изображение? на сервере.
4 апр 2021 в 20:05

Гугли «загрузка изборажений на сервер Node.js». Твои пикчи будут лежать где-нить в корне проекта, какая-нить папка uploads, например.

4 апр 2021 в 20:07

При всём уважении к ответу и комментариям, это всё таки ответ не на тот вопрос,котрый был задан. В некотрых случаях хренение картинок в базе предпочтительнее храннеия в файловой системе. С другой стороны, я уверен, что такой код гуглится без особых проблем.

4 апр 2021 в 21:33

Я написал методы с base64, конвертацией в буфер и обратно, записью и чтением из MDB может чем-то тебе поможет.

UPD: url для подключения к mdb изменился.

const mongoClient = require("mongodb").MongoClient; const fs = require('fs'); //const url = 'mongodb://username:[email protected]:12345/terba';// deprecated const url = 'mongodb+srv://:@basName.7jsay.mongodb.net/?retryWrites=true&w=majority'; function mdbConnect(operation, data)< mongoClient.connect(url,< useNewUrlParser: true, useUnifiedTopology: true>, function(err, client)< const db = client.db("terba");//Твоё наименование const collection = db.collection("user");//Твоё наименование if (operation === "update"),//команда для вставки значения data в поле photo в документ с _id:"myPhoto" ,//создаст документ с _id:"myPhoto" полем photo и значением data если такого нет в БД function(err, res)else < console.log(res.result.nModified, res.result.upserted)//На что тебе надо обратить внимание >> ); > if (operation === "find")< console.log(photo)//Здесь твоя фотка в виде Buffer`a let string64 = buffer.toString('base64');//можешь конвертировать в base64 если надо >) > client.close(); >); > function fsr() < let path = "C:\\express\\myProject\\img\\0.jpg" //Это путь к картинке на диске let data = fs.readFileSync(path).toString('base64');//читаешь картинку при помощи fs и конвертишь в base64 let buf = Buffer.from(data, 'base64');//конвертируешь обратно в buffer // console.log(data,buf) mdbConnect("update", buf)//пишешь в mdb буфер, можешь base64 попробовать он в data лежит >mdbConnect("find", "myPhoto")//читаешь из mdb function fsw(data)< fs.writeFileSync("C:\\express\\myProject\\img\\0.jpg", data, 'base64',(err)=>); > let htmlTag = ' '/*создаёшь строку тега img с атрибутом src пишешь туда картинку в base64 отправляешь её клиенту*/ //На клиенте что-то из этого // document.getElementById('as').innerHTML="";//Вставляешь на клиенте в контейнер с id "as" например, или куда тебе надо // function createImg (base64) < //Или в тело документа // var image = new Image(); // image.src = "data:image/jpg;base64,"+base64; // document.body.appendChild(image); //>

Хранение изображений в MongoDB — стоит ли?

Нужно авторитетное мнение по данному вопросу. Была задача разобраться с GridFS, записывать и читать оттуда файлы. Всё получилось, но встал вопрос: есть ли какой-то смысл хранить там, например, изображения (фотографии)? Получается ли такое решение более производительным (или наоборот)? Если да, то как (по логике) оптимальнее это реализовать?

Как это происходит сейчас:

На GET-запрос /specialists/:login/photos/:photo (где :login — логин специалиста, :photo — уникальный идентификатор фотографии) происходит запрос в GridFS, откуда по идетификатору достаётся фотография специалиста и отдаётся браузеру.

Соответственно, на странице фотография прописывается, как

<img src="/specialists/:login/photos/:photo" alt="" />

а их может быть и штук 20, что будет означать 20 запросов в базу.

• Вопрос задан более трёх лет назад
• 21627 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 4
php программист

Совершенно не стоит. Зачем вам вообще лишние запросы к базе? Тем более такие обьемные? Люди наоборот все кешируют и на винт складывают, чтоб доступ быстрей был, а вы наоборот думаете как бы кеш (изображения) убрать из под руки и засунуть в базу.

Ответ написан более трёх лет назад
Нравится 6 5 комментариев

Nesvet @Nesvet Автор вопроса
Так можно и закешировать nginx’ом — это не проблема. Что скажете?
Я скажу вот что: зачем кешировать, то что уже по сути закешировано и прекрасно лежит на винте?
+1
Для файлов есть специализированные базы данных, которые называются файловыми системами.
чтобы не решардить, к примеру, когда закончится место на диске

А база находится не на жестком диске? Или на дисках где лежит база место не заканчивается? По моему место является меньшей проблемой чем время запроса и выгрузки данных из базы.

Производительным не получится, если нет большого кластера, который компенсирует сниженную скорость доступа за счёт распараллеливания. Я предпочитаю хранить картинки на отдельном сервере, а в базе ссылки на них. Вот небольшое исследование этого вопроса, правда двухлетней давности: www.coffeepowered.net/2010/02/17/serving-files-out-of-gridfs/

Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать

Смотрите в сторону gridFS (часть mongo) и модуля nginx ( github.com/mdirolf/nginx-gridfs ) если память не изменяет то теряете 50% в производительности, но получаете все плюшки облачного хранения файлов.

Ответ написан более трёх лет назад
Нравится 2 7 комментариев
Теряете более 1000% производительности, превращая nginx в один процесс апача.

VBart, не говорите чушь, я кажется ссылку дал. Nginx будет использовать модуль и никакой apache вообще там не уперся.

Простите, какую чушь? По ссылке модуль в стадии «prove of concept» не предназначенный для использования. Он блокирует nginx полностью на время от установки соединения с базой и авторизации до получения файла целиком. Все это время nginx не может даже принимать соединения. При использовании этого модуля производительность одного воркера упадет в 100-10000 раз. Фактический один воркер nginx превращается в один воркер апача в режиме prefork.

Чушь это писать про апач про который речи и близко не было. То что он блокирует да факт, но сейчас это самое быстрое и простое решение для gridFS. На счет целесобразности использования в данном случае можно спорить. Но если число файлов больше нескольких миллионов я бы предпочел работать с облаком вместо ФС.

Извините, но вы вообще читать умеете? Повторю ещё раз: nginx с этим модулем работает как один процесс апача и даже хуже, иными словами, превращается из мультиплексора в однопоточный последовательный обработчик. Только похоже вам эти слова вообще ни о чем не говорят, раз вы даже не уловили сути сравнения с процессом апача.

Чтобы получить хоть какую-то производительность вам необходимо запустить около 100 воркеров nginx-а и поставить его бэкендом. Это самое медленное решение для GridFS, которое только можно придумать, причем с кучей подводных камней. И самое бессмысленное использование nginx-а.

Я вас понял, просто вместо того что бы назвать такое поведение синхронной работой вы сравниваете с апачем. Это как сказать что тойота без полного привода превращается в опель. Причем здесь опель?

С относительно недавнего времени это не самое быстрое и простое решение)
Мы в скором времени планируем перенести своё хранилище фотографий в GridFS. Из-за отсутствия у Mongo асинхронного драйвера nginx-gridfs не отличается особой производительностью. В свете этого печального события наш технический директор написал и выложил в open source модуль для Apache: bitbucket.org/onyxmaster/mod_gridfs/
Вот пост с анонсом в его блоге: xm.x-infinity.com/2012/04/as-were-to-move-our-terabytes-of-files.html
А тут некоторые цифры: xm.x-infinity.com/2012/04/modgridfs-performance.html

Заклинатель кода

Если стоит вопрос хранения файлов в GridFS, значит есть потребность в облачном хранении и своевременном изменении файла/файлов в облаке, а так же контролируемая файловое хранилище (например вести счетчик использования файла в самом документе в gridfs и удалять при его обнулении). Только в этом случае имеет смысл задуматься о gridfs. Конечно, если использовать в лоб GridFS то потери производительности будут, и чем больше запросов и больше файлов тем больше просадка по производительности. Есть несколько вариантов более-менее производительные решения, но их вся суть сводиться: GridFS — (gridfs-fuse) —> disk0 — (rsync) —> disk1 — (rsync) —> disk2 — … (возможны параллельнык rsync) или GridFS — (gridfs-fuse) —> disk0 — (drbd) —> disk1, disk2,… или их комбинации.

БД для чата на MongoDB — где хранить картинки и иные файлы?

Пишу чат, в качестве БД используется MongoDB.
Сущность сообщения помимо текста может содержать картинки и иные типы файлов.
Каким образом лучше хранить файлы? Хранить в БД только ссылки на файлы, а сами файлы на отдельно файловом сервере? Или хранить файлы, используя GridFS?

• Вопрос задан более трёх лет назад
• 2755 просмотров

Комментировать
Решения вопроса 3

Файлы лучше хранить в файловой системе. Ощутимый бонус от хранения файла в ФС — можно отдавать напрямую веб-сервером (nginx, apach, etc), не надо для этого куда-то лезть.
Если уж не помещается или нужны какие-то особые фишки — тогда можно и GridFS или другие инструменты.

Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Anton @MoonMaster
Программист и этим все сказано

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

Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать

Если картинки/файлы не большие, то можно и в самом сообщении — одним запросом будет получены и сообщения и файлы, если крупные — то выносить в gridfs/файлы (например как в slack).
Если файлы должны отдаваться только авторизованым (имеющим права), то хранение на диске особо преимуществ не даст (т.к. при раздаче веб сервером, он по прямой ссылке отдаст файлы кому угодно).

Ответ написан более трёх лет назад
Нравится 1 4 комментария

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

Можно настроить

RidgeA, наверно, но через адские костыли.
как вы сделаете проверку, если в запросе кука/токен, а вам нужно получить пользователя, его группы и соотвествие файла группам? например в nginx?

lega, чисто в nginx — да, через адские костыли в виде LUA или самописных модулей.
Но есть для nginx модуль nginx.org/en/docs/http/ngx_http_auth_request_modul. с помощью которого можно на бек-энд отправить запрос, где проверить права доступа и вернуть соответствующих http код. Дальше либо nginx заворачивает запрос, либо отдает статику. Важно, что на этапе отдачи статики бэк-энд не учавствует.

Если нужно сделать сложную проверку на бекэнде, то потом можно передать nginx internal redirect, чтобы он отдал файл.

Python-сообщество

• Начало
• » Базы данных
• » Хранение изображений в БД

#1 Июль 26, 2011 10:54:57

dissdoc От: Зарегистрирован: 2009-12-12 Сообщения: 273 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

Всем привет! Это не холивар))) После глубокого изучения MySQL, SQLServer и MongoDB (причем здесь и NoSQL? узнаете позже) пришел к раздумьям и не знаю что делать… Есть изображения — их много. Раньше как делал — в БД хранил ссылку, а картинки на диске.
Теперь, когда появились поля типа BLOB, стал сомневаться — может туда пихать их?
Собственно хочу хранить данные пользователей в БД отдельной, а куда девать изображения не знаю. Имеет смысл в БД аватары хранить или нет?
С условием того, что юзеров переношу в MongoDB, так проще мне в дальнейшем работать.

#2 Июль 26, 2011 13:01:29

masterito От: Зарегистрирован: 2011-06-13 Сообщения: 34 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

Смысла в этом я не вижу. БД для структурированной информации, которой картинка не является.
С этой задачей лучше справится файловая система.

#3 Июль 26, 2011 13:48:46

o7412369815963 От: Зарегистрирован: 2009-06-17 Сообщения: 1986 Репутация: 32 Профиль Отправить e-mail

Хранение изображений в БД

в MongoDB есть GridFS, только я не знаю есть ли там отдача по http.
а вообще в файловой системе — нормально, тем более их ассортимент.

#4 Июль 26, 2011 17:17:18

dissdoc От: Зарегистрирован: 2009-12-12 Сообщения: 273 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

Хм..
может я просто уже перемудрил… Файловая система действительно быстрее и проще… =\
Ох моя голова)))) Рукам покоя не дает)

#5 Июль 26, 2011 19:01:45

villager От: Зарегистрирован: 2008-11-04 Сообщения: 111 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

а если клиент-серверная система на БД MySql, и у клиента нет доступа к сетевым дискам?
как в таком случае поступать?

#6 Июль 26, 2011 19:04:45

doza_and От: Зарегистрирован: 2010-08-15 Сообщения: 4138 Репутация: 252 Профиль Отправить e-mail

Хранение изображений в БД

А может и не перемудрили. Если у вас большая локалка, или интернет, то база данных в отличии от fs обеспечит передачу файлов клиентам и их кеширование на стороне клиента. Кроме того как и обычно, будет обеспечена транзакционная целостность при изменении контента, и будут более разнообразные возможности при разрешении конфликтов доступа. Если перечисленное не нужно тогда — файловая система лучше. правда но… Если картинок много и они мальенькие (100-200-500 байт как у иконок) тогда накладные расходы fs могут быть значительны. (Например вам нужна база данных отпечатков пальцев всего населения). В этом случае БД тоже может выиграть. (не проверял)

#7 Июль 26, 2011 21:07:14

kachayev От: Зарегистрирован: 2011-07-08 Сообщения: 40 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

doza_and
В этом случае БД тоже может выиграть. (не проверял)

Может, но только в том случае, если она поддерживает асинхронный I/O. В противном случае упретесь в тоже самое. Отсюда mysql и подобные сразу отпадают.

#8 Июль 26, 2011 21:25:33

o7412369815963 От: Зарегистрирован: 2009-06-17 Сообщения: 1986 Репутация: 32 Профиль Отправить e-mail

Хранение изображений в БД

doza_and
А может и не перемудрили. Если у вас большая локалка, или интернет, то база данных в отличии от fs обеспечит передачу файлов клиентам и их кеширование на стороне клиента. Кроме того как и обычно, будет обеспечена транзакционная целостность при изменении контента, и будут более разнообразные возможности при разрешении конфликтов доступа. Если перечисленное не нужно тогда — файловая система лучше. правда но… Если картинок много и они мальенькие (100-200-500 байт как у иконок) тогда накладные расходы fs могут быть значительны. (Например вам нужна база данных отпечатков пальцев всего населения). В этом случае БД тоже может выиграть. (не проверял)

1) файловую систему легко сделать распределенной
2) маленькие/большие файлы — выберите себе подходящий тип ФС — их десятки
3) “кеширование на стороне клиента” — это не зависит как хранить файлы на сервере
4) “ обеспечена транзакционная целостность” — это зависит о движка и в том и в том случае.

так что все плюсы перекрыты.

тут надо смотреть конкретную базу, как она по скорости, расширяемости, возможность отдачи по http…

#9 Июль 27, 2011 01:06:44

alexandre От: Зарегистрирован: 2010-11-16 Сообщения: 104 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

Еще есть аналог MongoDB, CouchDB там вообще все просто к каждому документу приатачиваються любые файлы в любом количестве, а при желании эти файлы могут участвовать в запросах. Очень удобно впринцепе.

Отредактировано (Июль 27, 2011 01:08:52)

#10 Июль 27, 2011 09:33:42

Sleepwalker От: Зарегистрирован: 2008-07-18 Сообщения: 68 Репутация: 0 Профиль Отправить e-mail

Хранение изображений в БД

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

Отредактировано (Июль 27, 2011 09:34:02)