Я разрабатываю новый веб-сайт и хочу использовать GridFS в качестве хранилища для всех пользовательских загрузок, потому что он предлагает много преимуществ по сравнению с обычным хранилищем файловой системы.
Тесты с GridFS, обслуживаемой nginx, показывают, что это не так быстро, как обычная файловая система, обслуживаемая nginx.
Есть ли кто-нибудь, кто использует GridFS уже в производственной среде или будет использовать ее для нового проекта?
Ответы:
Я использую 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 достаточно быстр и надежен, чтобы его можно было использовать в продакшене.
Как уже упоминалось, это может быть не так быстро, как обычная файловая система, но тогда это дает вам преимущества перед обычными файловыми системами, ради которых, я думаю, стоит немного отказаться от скорости.
В конечном счете, с сегментированием вы можете достичь точки, когда хранилище GridFS фактически станет более быстрым вариантом по сравнению с обычной файловой системой и одним узлом.
Однако не стоит забывать о ремонте больших БД - новая система, которую мы разрабатываем, mongo не вышла полностью, а восстановление GridFS на 7 ТБ, похоже, займет 130 часов.
Из-за этого я думаю, что посмотрю на переход на OpenStack Swift или Ceph. Тем не менее, до тех пор это было хорошо. И модуль nginx-gridfs хорош.
Я не рекомендую использовать gridfs, если вы не знаете, что делаете. GridFS - это просто уровень абстракции, который разбивает файлы на куски и сохраняет файлы в двух коллекциях. Больше файлов - больше накладных расходов. Если вы ожидаете, что файлы будут примерно одинакового размера, не превышающего 32M или около того - вы на правильном пути. Не пытайтесь хранить большие файлы в gridfs. Зачем?
Если вы думаете о чтении загруженного проекта - подумайте о загрузке файлов напрямую в документы (если размер 16M или меньше) или выберите другой clusterfs и свяжите имя файла / индексный дескриптор с вашей логикой.
Надеюсь это поможет.