Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Хм, а ведь не теперь, пожалуй, причин не иcпользовать гридФС для хранения статических ресурсов
nginx-gridfsЭто лишено смысла. Считайте, что на текущий момент нет такого модуля в nginx, поскольку существующий блокирует рабочий процесс на всех операциях.
Вместо этого пункта рекомендую другой:
- Настроить nginx
После фразы настройки Nginx/1.4.1 стандартные можно выкидывать результаты nginx из теста.
При таких объемах на современном сервере можно озаботиться полным кешированием картинок в память. Интереснее посмотреть результаты именно в рабочих условиях, на мощном железе, идеально настроенном софте и 30-50 гб данных.
А если через nginx раздавать — то и заботиться не надо, pagecache сделают всю работу сам.
30-50 Гб тоже довольно легко помещаются в память :) только сервер немного дороже. Если хочется сравнивать реальную производительность файловой системы против GridFS — то надо несколько сотен гигабайт данных и рандомно обращаться к данным.
30-50 Гб тоже довольно легко помещаются в память :) только сервер немного дороже. Если хочется сравнивать реальную производительность файловой системы против GridFS — то надо несколько сотен гигабайт данных и рандомно обращаться к данным.
1200-1400 rps для статики по одному URL — это очень, очень мало для nginx даже на слабом железе. На упомянутой конфигурации (одно ядро, ext4, память в данном случае роли не играет) при чтении одного файла nginx (как и lighttpd) должен отдавать что-то под 7-10 тыс. ответов в секунду.
Если пустить не на одном ядре, а на 4, то производительность подскочит ещё раза в три. 20..25 тыс. rps для nginx и одного файла — вот это нормальный уровень для средней машины.
А 1200..1400 — это больше тянет на тормозной Apache с mpm_itk.
Если пустить не на одном ядре, а на 4, то производительность подскочит ещё раза в три. 20..25 тыс. rps для nginx и одного файла — вот это нормальный уровень для средней машины.
А 1200..1400 — это больше тянет на тормозной Apache с mpm_itk.
у знакомых был опыт хранения картинок в МонгоДБ, все бы ничего пока не легла база и на ее восстановление потребовалось очень большое время.
Сами картинки, закодированные в base64? А картинки большие были?
В этом плане начал недавно присматриваться к OpenStack Swift. Оно, правда, без файловой системы, только для документов, но зато решает основную задачу GridFS — репликацию. При этом, в отличие от решений, типа Ceph, полностью распределено, без выделенного мастер-сервера метаданных.
Но до экспериментов пока не дошёл.
Но до экспериментов пока не дошёл.
Для этого можно поднять репликационную ноду для бекапа — всегда будет копия свежих данных.
Мы используем монгодб в продакшне, всем устраивает, объемы данных большие, очень.
Может Вы просто не использовали реплику-сет, раз у Вас легла вся база?
Да и за полтора года бд ни разу не упала, в чем у Вас причина падения была?
Может Вы просто не использовали реплику-сет, раз у Вас легла вся база?
Да и за полтора года бд ни разу не упала, в чем у Вас причина падения была?
простите, а что вы в монго храните? объем данных? сруктура?
У меня в один из проектов: объем около 20Гб, содержит около 200-350 типов данных, файлов не более 2Гб, внутри пользовательская информация: сообщения, документы, комментарии, настройки и т.п. проекту 3 года, работает стабильно.
Несколько разных нод, одна, работающая без реплики-сета (и шардинга, соответственно), обслуживает 60гб данных (~57 млн объектов) на одном сервере.
Другое хранилище содержит 3.8тб данных (1,6млрд объектов) на 4-ех серверах с шардингом.
БОльшая часть объектов в среднем размером 2 кб каждый.
У нас преимущественно одноуровневые объекты в коллекциях, они работают быстрее многоуровневых.
А по поводу падения — мы как-то специально закиллили один шард, восстанавливается он и правда долго(на 30гб данных и 25млн записей около 15-20 минут), так как разгребает свой журнал и проверяет целостность данных, без реплики-сета это и правда был бы провал.
P.S. После кропотной работы с монгой создаешь поневоле «рецепты её приготовления», которые помогают работать с ней и практически забыть о её обслуживании.
Другое хранилище содержит 3.8тб данных (1,6млрд объектов) на 4-ех серверах с шардингом.
БОльшая часть объектов в среднем размером 2 кб каждый.
У нас преимущественно одноуровневые объекты в коллекциях, они работают быстрее многоуровневых.
А по поводу падения — мы как-то специально закиллили один шард, восстанавливается он и правда долго(на 30гб данных и 25млн записей около 15-20 минут), так как разгребает свой журнал и проверяет целостность данных, без реплики-сета это и правда был бы провал.
P.S. После кропотной работы с монгой создаешь поневоле «рецепты её приготовления», которые помогают работать с ней и практически забыть о её обслуживании.
Со мной лишь поделились опытом, сайт очень посещаемый. В начале кэш был на уровне memcache, холодный запуск был тяжелый. Маленькие картинки (превьюшки) читать с диска было тяжело и было принято решение хранить это все монгоДБ, в каком виде к сожалению я не знаю. Знаю что восстанавливали после падения несколько часов. И своим комментом выше хотел просто напомнить, что бывают и такие случаи. А то по статье и комментам казалось что вообще нет минусов в таком решении.
Повторюсь, это все лишь слышал на словах. Подробностей к сожалению не знаю.
Повторюсь, это все лишь слышал на словах. Подробностей к сожалению не знаю.
Минусы есть везде и всегда, нужно только попытаться их заставить работать на Вас и стать плюсами!
Просто после продолжительного времени работы БД под рельной большой нагрузкой мне сомнительно, что монго сама упала, хотя в Вашей формулировке это звучит именно так. Скорее я поверю, что вылетел сам сервер с битой памятью, развалившемся рейдом или оом-киллер убил монгу, потому что на сервере еще что-то располагалось кроме базы данных.
А вообще проблема, которую мы тут обсуждаем, — это издержки неправильной архитектуры (которая, к сожалению, в некоторых компаниях бывает из-за нежелания руководства выделять финансы на оверхед данных — репликацию).
Просто после продолжительного времени работы БД под рельной большой нагрузкой мне сомнительно, что монго сама упала, хотя в Вашей формулировке это звучит именно так. Скорее я поверю, что вылетел сам сервер с битой памятью, развалившемся рейдом или оом-киллер убил монгу, потому что на сервере еще что-то располагалось кроме базы данных.
А вообще проблема, которую мы тут обсуждаем, — это издержки неправильной архитектуры (которая, к сожалению, в некоторых компаниях бывает из-за нежелания руководства выделять финансы на оверхед данных — репликацию).
Да и за полтора года бд ни разу не упала, в чем у Вас причина падения была?
Добавлю, 3 года используем MongoDB, сейчас активно 4 больших проекта, за это время не было ни одного «падения» (разрушения) БД.
Все большие проекты обязательно используют реплику сет, маленькие проекты просто бекапятся.
В интернете встречал — жаловались на стабильность в версии 1,6 и старше, но сейчас говорят MongoDB стала гораздо стабильней.
PS: не в ту ветку ответил, это ответ к greevex
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Производительность GridFS