Достаточно ли быстр и надежен GridFS для производства?

86

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

Тесты с GridFS, обслуживаемой nginx, показывают, что это не так быстро, как обычная файловая система, обслуживаемая nginx.

Тест с nginx

Есть ли кто-нибудь, кто использует GridFS уже в производственной среде или будет использовать ее для нового проекта?

Railsmechanic
источник
1
Сообщение в блоге о хранении изображений в mongodb для будущих искателей, у которых было такое же намерение, как и у меня: menge.io/2015/03/24/storing-small-images-in-mongodb (сравнивает GridFS с простым добавлением его в документ как двоичный data)
При принятии решения о хранении двоичных данных в MongoDB необходимо учитывать множество компромиссов - см .: alexmarquardt.com/2017/03/02/…
Александр Марквардт

Ответы:

118

Я использую gridfs на работе на одном из наших серверов, который является частью сайта для сравнения цен с хорошей статистикой посещаемости (около 25 тысяч посетителей в день). У сервера не так много оперативной памяти, 2 гигабайта, и даже процессор не очень быстрый (Core 2 duo 1.8Ghz), но на сервере достаточно места для хранения: 10 ТБ (sata) в конфигурации raid 0. Работа сервера очень проста:

У каждого продукта на нашем устройстве сравнения цен есть изображение (согласно нашей базе данных продукта существует около 10 миллионов продуктов), и задача серверов заключается в том, чтобы загрузить изображение, изменить его размер, сохранить его в gridfs и доставить в браузер посетителей. .. если его нет в сетке ... или ... доставить его в браузер посетителей, если он уже сохранен в сетке. Итак, это можно назвать «традиционной схемой cdn».

Мы сохранили и обработали 4 миллиона изображений на этом сервере с момента его запуска. Изменение размера и сохранение выполняется с помощью простого скрипта php ... но наверняка скрипт python или что-то вроде java может быть быстрее.

Текущий размер данных: 11,23 г

Текущий объем памяти: 12,5 г

Индексы: 5

Размер индекса: 849,65 м

О надежности: Это очень надежно. Сервер не загружается, размер индекса в порядке, запросы быстрые

О скорости: конечно, это не так быстро, как локальное хранилище файлов, может быть, на 10% медленнее, но достаточно быстро, чтобы использовать его в реальном времени, даже когда изображение необходимо обработать, что в нашем случае очень зависит от php. Время обслуживания и разработки также сократилось: стало так просто удалить одно или несколько изображений: просто запросите базу данных с помощью простой команды удаления. Еще одна интересная вещь: когда мы перезагружали наш старый сервер с локальным хранилищем файлов (то есть миллион файлов в тысячах папок), он иногда зависал на несколько часов, потому что система выполняла проверку целостности файла (это действительно занимало часы ...). У нас больше нет этой проблемы с gridfs, наши изображения теперь хранятся в больших чанках mongodb (файлы 2gb)

Итак ... на мой взгляд ... Да, gridfs достаточно быстр и надежен, чтобы его можно было использовать в продакшене.

Ману Эйденбергер
источник
9
Я шокирован тем, что кто-то будет использовать raid 0 в качестве основного хранилища на рабочем веб-сайте. Даже при наличии хороших резервных копий повышение вероятности сбоя хранилища - довольно высокая цена за повышение производительности.
mikerobi
67
Мы используем raid 0, потому что в нашем конкретном случае данные изображения могут быть непостоянными. Не имеет значения, потеряно ли изображение, поскольку мы снова загрузим его с сайта продавца. Прагматически мы могли бы считать, что наш сервер является простым сервером кеширования изображений.
Ману Эйденбергер
Но вы активно увеличиваете вероятность отказа (начальный коэффициент отказа диска, умноженный на количество шпинделей). Raid 10 будет идеальным вариантом, если вам нужно больше операций записи, чем чтения, или Raid 5/6, если вам нужно больше операций чтения, чем записи.
NeuroScr
9
@ManuEidenberger Почему вы используете GridFS для хранения изображений, которые лучше хранить в документе MongoDB? Я предполагаю, что вы не достигли предела размера документа в 16 МБ. А сохранение изображения как BLOB в документе MongoDB было бы более эффективным, поскольку вам не нужен слой GridFS поверх документов MongoDB.
Арно Буше
1
Мне также интересно узнать о вопросе @ArnaudBouchez. Было ли какое-то преимущество, которое заставило вас выбрать GridFS, а не просто хранить его в виде двоичных данных в документе, Ману? Благодарность!
12

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

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

Том
источник
6

Однако не стоит забывать о ремонте больших БД - новая система, которую мы разрабатываем, mongo не вышла полностью, а восстановление GridFS на 7 ТБ, похоже, займет 130 часов.

Из-за этого я думаю, что посмотрю на переход на OpenStack Swift или Ceph. Тем не менее, до тех пор это было хорошо. И модуль nginx-gridfs хорош.

Ник
источник
Так как ты прошел?
Mukus 01
5

Модуль nginx-gridfs от mdirolf великолепен, и его довольно легко настроить. Мы используем его в производстве на paint.ly, чтобы обслуживать все картины, и пока никаких проблем не возникло.

Schallis
источник
3
Похоже, что paint.ly больше не доступен. :(
Marian
2

Я не рекомендую использовать gridfs, если вы не знаете, что делаете. GridFS - это просто уровень абстракции, который разбивает файлы на куски и сохраняет файлы в двух коллекциях. Больше файлов - больше накладных расходов. Если вы ожидаете, что файлы будут примерно одинакового размера, не превышающего 32M или около того - вы на правильном пути. Не пытайтесь хранить большие файлы в gridfs. Зачем?

  1. Драйверы на разных языках могут читать файл целиком (например, фрагменты) при чтении небольшой части файла.
  2. Изменение файла может повлиять на все фрагменты и увеличить нагрузку на базу данных. Если ваша файловая система растет, вам придется решить сегментировать gridfs. Быть осторожен! При инициализации сегментирования согласованность не гарантируется!

Если вы думаете о чтении загруженного проекта - подумайте о загрузке файлов напрямую в документы (если размер 16M или меньше) или выберите другой clusterfs и свяжите имя файла / индексный дескриптор с вашей логикой.

Надеюсь это поможет.

Виталий Грек
источник
4
Я новичок в GridFS, хотя, насколько я понимаю, GridFS - это больше, чем просто уровень абстракции, удваивающий количество файлов. GridFS предоставляет простой способ воспользоваться функциями репликации и сегментирования MongoDB. Я считаю, что другие также упоминали, что файлы хранятся в блоках по 2 ГБ, что, как я полагаю, уменьшит общее количество файлов, особенно если у кого-то есть очень большое количество небольших изображений.
+1 Вы правы. Файлы даже меньшего размера не будут полезны для хранения в GridFS. Если ваш файл может быть сохранен в документе MongoDB (т.е. <предельного размера 16 МБ), вы бы предпочли сохранить файл как большой двоичный объект в документе MongoDB. Это позволит избежать накладных расходов на использование GridFS поверх хранилища MongoDB. См. Compose.io/articles/gridfs-and-mongodb-pros-and-cons
Арно Бушез,