MongoDB большого объема с потоковым API Twitter, Ruby on Rails, настройкой Heroku

Question

Я хочу перекодировать приложение, чтобы лучше обрабатывать всплески в твитах.Я перехожу к Heroku и MongoDB (либо MongoLab, либо MongoHQ) для решения базы данных.

Во время определенных новостных событий объем твита может достигать 15000 в секунду.Как правило, с каждым твитом я анализирую твит и сохраняю различные фрагменты данных, такие как пользовательские данные и т. Д. Моя идея состоит в том, чтобы хранить необработанные твиты в отдельной коллекции, а отдельный процесс позволяет получать необработанные твиты и анализировать их.Цель здесь в том, что когда в твитах наблюдается огромный всплеск, мое приложение не пытается проанализировать все эти запросы, а, по сути, задерживает необработанные твиты в другой коллекции.Поскольку объем замедляется, процесс может позаботиться о отставании с течением времени.

Мой вопрос в три раза:

1. Может ли MongoDB обрабатывать этот тип тома в отношениивставляет в коллекцию со скоростью 15 000 твитов в секунду?

2. Есть идеи по лучшей настройке: MongoHQ или MongoLab?

3. Любые отзывыпо общей настройке?

Спасибо!

Answer 1

Полностью согласен с необходимостью проверить это.В общем, Монго может обрабатывать такое количество записей, но на практике это зависит от размера вашей установки, других операций, индексов и т. Д.

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

Мне было бы интересно посмотреть, как это работает для вас по цене, по сравнению с VPS, как линода.(Я большой поклонник Heroku, но с некоторыми архитектурами это может быстро стать дорогим)

Answer 2

1. Объем записи, который он будет обрабатывать, зависит от множества факторов - аппаратного обеспечения, индексов, размера каждого документа и т. Д. Лучше всего протестировать его в среде, которую вы планируете использовать.Если требования нагрузки записи превышают емкость одного сервера mongo, вы всегда можете использовать только несколько шардов.

2. Они очень похожи, но есть некоторые различия в ценах, и фактический дизайн сайта имеет кучу различий.Здесь есть нить обсуждения: https://webmasters.stackexchange.com/questions/20782/mongodb-hosting-mongolab-vs-mongohq-vs-mongomachine

3. В целом, кажется, имеет смысл.Похоже, вы, вероятно, захотите конкретизировать, как вы будете обрабатывать отставание.Будете ли вы опрашивать его, периодически запрашивая, удаляя твиты из журнала невыполненных работ по мере их обработки и т. Д.