MongoDB — потребляет твиты и подсчитывает данные

#mongodb

#mongodb

Вопрос:

Я использую API потоковой передачи Twitter в реальном времени, чтобы вести активный подсчет определенных дорожек. Например, я хочу отслеживать, сколько раз в твиттере появлялись «яблоко», «апельсин» и «груша». Я использую Mongo для хранения данных твитов, но у меня есть вопрос о том, как лучше всего получить количество для каждого из отслеживаемых мной треков.

Я буду запускать этот запрос раз в секунду, чтобы получить количество, близкое к реальному времени, для каждого трека, поэтому мне нужно убедиться, что я делаю это правильно:

Вариант 1

Запустите запрос count для определенного трека

  db.tweets.count({track: 'apple'})
  

Учитывая, что база данных tweet будет содержать МНОГО данных (потенциально миллионы) Интересно, может ли это быть немного медленным?

Вариант 2

Создайте вторую коллекцию ‘track_count’ и обновляйте атрибут ‘count’ каждый раз, когда поступает новый твит:

 {track:'apple', count:0}
{track:'orange', count:0}
{track:'pear', count:0}
  

Затем, когда приходит новый твит:

 db.track_count.update( { track:"apple" }, { $inc: { count : 1 } } );
  

Затем я могу вести актуальный подсчет для каждого трека, но это означает запись в базу данных дважды, один раз для твита и еще раз для увеличения количества треков. Имея в виду, что может поступать достаточное количество (десятки, возможно, сотни) твитов в секунду.

Есть ли у кого-нибудь предложения относительно наилучшего способа сделать это?

Комментарии:

1. Было интересно, что вы сделали в конце? Вторая коллекция для приращений или, может быть, для работы в памяти, например, с использованием Redis?

Ответ №1:

Без сомнения, используйте отдельную track_count коллекцию, чтобы сохранить общее количество совпадений. В противном случае вы будете повторно запрашивать всю свою tweets коллекцию каждую секунду, что будет становиться очень медленным и дорогостоящим по мере роста объема данных.

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

Ответ №2:

Есть ли у кого-нибудь предложения относительно наилучшего способа сделать это?

Здесь нет «лучшего» метода. Это классический компромисс. Вы можете делать «счетчики», вы можете страдать от медленных запросов, вы можете запускать обычные задания по сокращению карты.

  • Две записи => более быстрые запросы, больше операций записи
  • Одна запись => более медленные запросы, меньшая активность при записи
  • Почасовая оплата => слегка устаревшие данные, немного больше записей

Обычно предлагается использовать счетчики. MongoDB, как правило, довольно хорошо справляется с большими нагрузками на запись, особенно с таким типом «увеличения» или загрузки счетчиков.

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


Примечание: является ли название трека уникальным?

Возможно, вы захотите попробовать следующее:

 {_id:'orange', count:0}
{_id:'pear', count:0}
  

Или для подсчета по дням:

 {_id:'orange_20110528', count:0}
{_id:'orange_20110529', count:0}
{_id:'pear_20110529', count:0}
  

Комментарии:

1. в чем преимущество выполнения этого с использованием стандартного идентификационного номера?

2. Если вы не заполните _id поле, MongoDB предоставит автоматически сгенерированный идентификатор объекта. _id Поле автоматически индексируется. Если вы замените это поле чем-то другим уникальным, то обычно вы можете сохранить индекс.