MongoDB для вирусного сайта. AWS + MongoDB хорошее решение?

Question

Мы рассматриваем MongoDB для веб-сайта, который, как мы ожидаем, станет вирусным (подумайте миллионы пользователей в течение первых 1-2 месяцев).

Нам понадобится много памяти, потому что нам нужно, чтобы это было быстро. Мы смотрим на 32 ГБ памяти как минимум. Проблема с выделенными серверами заключается в том, что ежемесячная стоимость 32-64 ГБ памяти очень высока.

Основным преимуществом AWS является то, что вы платите по ходу или в масштабе.

Я посмотрел на Amazon EC2 «Двойной очень большой экземпляр с высокой памятью», у него 34,2 ГБ памяти и 850 ГБ.

Этот веб-сайт будет похож на Twitter, который будет перегружен обновлениями статуса, но он не ограничивается 160 символами (потенциально неограниченными символами).

Сложность в том, как на домашней странице Twitter есть список всех последних твитов от людей, на которых вы подписаны. Я ожидаю, что в Твиттере есть две таблицы / «коллекции»: одна, в которой хранятся твиты, которые вы твитнули, и отдельная, в которой хранятся полученные вами твиты (но не значит ли это, что они делают от тысячи до сотен тысяч записей в БД каждый раз, когда кто-то с тоннами подписчиков публикует обновление статуса?)

Backend использует Node.js, поэтому MongoDB идеален.

Мои вопросы:

1) Нужно ли 32 ГБ памяти в нашей ситуации? 2) Достаточно ли 850 ГБ дискового пространства, предоставляемого EC2? 3) EC2 или выделенный сервер лучше для размещения обновлений статуса в MongoDB? Почему?

Answer 1

1. Когда у вас действительно есть пользователи, вам нужно столько же памяти, сколько размер активного набора данных. Сейчас это 0 ГБ, так что пока не покупайте все эти экземпляры.

2. У вас есть более 850 ГБ данных для хранения? Вы строите копию библиотеки конгресса? Если эти миллионы пользователей не будут загружать большие двоичные объекты, почему вы даже спрашиваете, достаточно ли 850 ГБ?

3. Оба будут работать нормально, но наличие собственного оборудования дает вам больше контроля. Вы, безусловно, можете повысить производительность ввода-вывода AWS с помощью собственных RAID-массивов или SAN. Если вы не можете разместить всю свою базу данных в оперативной памяти, то дисковый ввод-вывод является вашим основным узким местом.

4. Является ли AWS правильным выбором, когда вы уже жалуетесь на цену? Точно нет. Вы потратите гораздо больше, либо арендуете сервер, либо создаете его самостоятельно и размещаете в центре обработки данных. ECC RAM для сервера стоит около $ 25 за гигабайт; это, вероятно, будет стоить вам более $ 25 за гигабайт в месяц при настройке аренды. Хотели бы вы построить один сервер за 1500 долларов один раз или заплатить Amazon $ 720 в месяц за одно и то же?

Что вы должны вероятно сделать, реально, это получить себе VPS за 20 долларов в месяц. Это даст вам пол гигабайта ОЗУ или около того. Напишите свой сайт. Начните продвижение. Если у вас есть реальные пользователи, и они создали более половины записей базы данных, обновите систему до более крупного VPS. Это 5-минутный процесс, который вы выполняете одной ночью на большинстве VPS-хостов, таких как Linode. Когда вы перерастаете их более крупные экземпляры, вы создаете себя или арендуете собственный сервер. На данный момент у вас есть реальная потребность и вы знаете достаточно о том, как работает ваше приложение, чтобы знать, какие спецификации вам действительно нужны.

Есть один момент, который я упустил: почему MongoDB? Есть ли причина, по которой вы считаете, что СУБД, такие как MySQL или SQL Server, не подходят для вашего приложения, но не ошиблись для Facebook, не ошиблись для Twitter, не ошиблись для MySpace, не ошиблись для eBay, не так ли? не так ли для любого крупного сайта, который вы можете назвать?

Единственное узнаваемое имя, которое быстро масштабировалось и сделало это с MongoDB недавно, было foursquare, и их установка MongoDB потерпела крах и сгорела. Когда произошел сбой и произошел сбой, главным образом потому, что это не проверенная технология, и они не до конца понимали, как она работает в распределенной масштабной среде, несмотря на то, что у нее 32 высокотехнологичных сотрудника, они не работали в течение 11 часов * 1030. * выяснить, как собрать его воедино.

Answer 2

Если у вас когда-нибудь будет достаточно посетителей, чтобы довести свой веб-сервер до предела, вам, возможно, будет намного лучше с несколькими меньшими серверами;кто-то, кто просто создает и обслуживает веб-страницы, кто-то, кто просто кэширует предварительно созданные страницы, и несколько серверов баз данных с репликацией.Таким образом, у вас также не будет единой точки отказа.

Я также не вижу точки в 850 ГБ хранилища для «обновлений состояния».Предполагая, что каждое Обновление будет иметь размер 1 КБ, этого будет достаточно для 891 289 600 Обновлений или 821 Обновления для каждого пользователя, если вы нажмете 1 миллион (активных) пользователей.

Answer 3

Я думаю, вы обнаружите, что ответ на этот вопрос «кто знает?». Мы понятия не имеем, на что похожи ваши шаблоны доступа к данным. Будете ли вы запускать кэши перед этим сервером БД? Как много? В какой конфигурации? Как часто вы собираетесь писать данные? Насколько важны данные, как часто они должны быть записаны на диск? Если вы действительно получите 2 миллиона обращений, вы можете столкнуться с проблемами пропускной способности, прежде чем столкнетесь с проблемами с памятью, но опять же, это зависит от того, насколько эффективны ваши обновления.

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

Хорошее место для начала - прочитать блог о высокой масштабируемости на http://highscalability.com/