Какую облачную технологию лучше всего использовать для серверов баз данных MongoDB / GridFS [закрыто]
Мы собираемся запустить службу, которая потребует от 1 до 2 ГБ для хранения файлов на каждого платного пользователя. Я собираюсь использовать GridFS для хранения файлов. GridFS - это модуль для MongoDB, который позволяет хранить большие файлы в базе данных.
Я обдумываю различные варианты хранения базы данных.
Но поскольку у меня нет опыта развертывания и я впервые работаю с Mongodb, мне нужен ваш опыт.
Критерии:
- Я хочу тратить свое время на развитие своего основного бизнеса, то есть своего собственного приложения. Я разработчик Ruby on Rails. Не люблю возиться с настройкой сервера. Следовательно, я хотел бы полностью управляемое решение для хостинга. Но хотелось бы узнать о любом другом варианте, если вы считаете, что оно того стоит.
- Он должен уметь масштабироваться. Облачный стиль. Плати как сможешь.
- Чем ниже цена, тем лучше.
На данный момент мне известны эти услуги:
- https://mongohq.com/pricing
- https://mongomachine.com/pricing
- https://mongolab.com/about/pricing/
- http://cloudcontrol.com/add-ons/mongodb/
И они, похоже, подходят для общих нужд, то есть без хранилища файлов. Но я собираюсь использовать GridFS, поэтому размер имеет значение. Эти услуги, кажется, плохо масштабируются по цене.
MongoHQ: Максимальный объем хранилища для большего плана составляет 20 ГБ. Похоже, для GridFS очень мало хранилища.
MongoMachine: фиксированная цена, 2,5 доллара за ГБ. Я не нашел предела. Похоже, хорошая цена, по сравнению с другими.
MongoLab: максимум 3,984 ГБ, я не думаю, что удастся его использовать, так что отлично. 8 долларов за ГБ, довольно дорого.
CloudControl: больший план - 20 Гб. Индивидуальная услуга начинается с 250 евро плюс некоторая неуказанная плата за ГБ.
Каков ваш опыт работы с этими услугами? Есть простои? Другие возможности?
Изменить: добавлено значение GridFS
Я думаю, что Вы неправильно читаете спецификации MongoLab. Это имеет значение по умолчанию приблизительно 3,9 ГБ - не макс. 3 984 ГБ! Это - американская десятичная метка, не тысячи разделителя (почему американцы настаивают на том, чтобы делать этот путь??). Макс. для большого плана составляют 20 ГБ ;)
Обновление:
Я просто посмотрел немного больше на сайт MongoHQ и нашел интересное обсуждение их сайта поддержки парнем, спрашивающим вид того же вопроса. Их ответ был:
Наши пределы являются мягкими пределами большого значения, что мы не отключим Вас, после того как Вы идете мимо 20 ГБ. Это там как измерительный инструмент, чтобы решить, соответствуете ли Вы на общем плане.
Мы также предлагаем выделенные планы и поощряем людей начинать изучать их, после того как их данные получают это большое. Одна из главных причин - то, что для запросов базы данных, что размер Вам будут нужны эффективные индексы и необходимо будет сохранить некоторую часть их в памяти. При совместном использовании сервера с другой базой данных, Вы не можете обоснованно сохранить много своей базы данных в памяти. Таким образом, это находится в everyones интересах переместить людей с большими наборами данных к специализированному плану.
Если Ваши данные еще не к тому размеру, может иметь смысл запускаться на общих планах и когда Вы растете, изучают специализированные планы.
Я действительно изо всех сил пытаюсь ответить на этот вопрос как есть, таким образом, я собираюсь ответить на это, поскольку я интерпретирую его.
"Что лучшая технология должна использовать для серверов баз данных MongoDB/GridFS"
Я, вероятно, начался бы с несколькими узлами хранения, сказал бы 4 300 ГБ (или 600 ГБ) диски SAS каждый, хорошее быстрое устройство хранения данных, закупорил бы их в RAID 10 (или возможно RAID 6) массив для хорошего компромисса дублирования и скорости. Удостоверьтесь, что Вы получаете достойную плату RAID с BBWC (Кэш записи С аварийным батарейным питанием). Удостоверьтесь, что у Вас есть достойные сети между узлами, таким образом, можно получить достойные скорости записи по сети.
Я не настолько знаком с GridFS, но если бы я хотел копируемые файловые системы, то я перешел бы прямо к GlusterFS и создал бы дублируемую пару из тех двух узлов.
Я подозреваю, что это, вероятно, не правильное место, чтобы спросить об оценке и так далее.
Кроме того, если Вы - разработчик, я предлагаю, чтобы Вы наняли / получают системного администратора по контракту / держатель на некоторое время, в то время как Вы получаете инфраструктуру, созданную / и выполнение. Особенно, если Вы хотите сконцентрироваться на бизнес-здании.
Это должно смочь масштабироваться. Облачный стиль. Оплата по мере использования.
Тот бит имеет очень мало смысла. Масштабируемость является одной вещью. Облако является маркетинговым модным словечком, PAYG, ну, в общем, это снижается полностью на Вашу тарификационную платформу.
Чем ниже цена, тем лучше
Понизить цену для Вас или Ваших клиентов? Существует старая поговорка в системном проектировании, "Дешева, хороша или быстра; выберите два".. Вы смогли создавать систему, это дешево для Вас, но будет wank для Ваших клиентов, и они уедут в их толпах. Не упустите это, тем более, что у Вас есть конкуренция, люди могут голосовать их ногами.