Стоит ли использовать Mongo и Node.js для сервиса аналога Яндекс.Метрики и Google Analytics?

Question

[Пума Тайланд]

Есть один проект для анализа данных от посещения сайтов, по сути собирает данные юзера от просмотров страниц (ip, страны, города, браузеры, расширения экрана и прочее) и потом строит отчеты.
Данных очень много.
Все сейчас крутиться на perconadb + php. Таблицы Innodb
Когда идет на сайтах наплыв посещаемости то percona затыкается на запись.
Так же построение отчетов работает не очень быстро особенно по большим промежуткам времени. Запросы и индексы оптимизировали как могли, даже данные для этого местами денормализировали и нормализировали.
Вопрос имеет ли смысл перейти на mongo для данных?
Имеет ли смысл перевести место через которое собирается статистика на node.js
Бекенд с отчетами хочу оставить на php.

Comments

[Пума Тайланд]

данных уже несколько десятков млн

Answer 1

[Андрей]

Нода тут вас никак не спасёт, потому что узкое место у вас в БД.
Монга только отсрочит неминуемое.
А неминуемое состоит в том, чтобы перейти на очереди.
То есть, как бы сделал я - на машине, которая собирает статистику (принимает запросы от сайтов), все данные пишутся в очередь. Можно использовать RabbitMQ например. И больше эта машина ничем не занимается.
Вторая машина достает из очереди данные и кладет их в БД, делая дополнительно какую-то обработку этих данных.
При этом как первых, так и вторых машин у вас может быть несколько. А можно всё это запустить и на одной. В любом случае, работать это будет быстрее, а записывать в БД будет не 100 потоков, а один, предварительно консолидируя данные.

Comments

[webus]

Что произойдет, когда очередь переполнится ?

[codercat]

@webus а вот и нужно не допускать этого, а записывать данные тогда, когда в очереди уже очень много данных.

[webus]

@codercat вроде RabbitMQ как и ZeroMQ все данные хранят в оперативке. тогда при переполнении очереди все зависнет, и мы можем потерять эту самую очередь совсем.

[Андрей]

Очередь не должна переполняться. Очередь - это труба. C одной стороны туда наливают фронтальные сервера. Делают они это очень быстро (потому что очередь - быстрая штука, в принципе). Тут можно и про ноду подумать, чтобы соединение к очереди было поднято постоянно. С другой стороны вычерпывают из этой трубы данные скрипты, которые работают в фоне. Их тоже может быть много (очередь гарантирует атомарность, то есть, что два скрипта не получат один и тот же пакет). Эти скрипты делают следующее: вытаскивают из очереди пакеты данных и формируют запрос к БД на вставку. Например, если делать вставку миллиона строк по одной, БД будет такую вставку обрабатывать существенно дольше, чем если делать ее одним махом (формировать один инсерт для всего миллиона записей и сразу отправлять в БД). Плюс, так же соединение c БД у этих скриптов будет постоянное. При таком подходе вам будет просто масштабировать решение в любой пропорции. Стали подтормаживать фронты - добавили еще фронтов. Стала тормозить очередь - добавили еще один сервер очереди. Стала тормозить БД - добавили сервер в кластер БД (тут конечно монга сделает sql по простоте кластеризации). Плюс, чтобы не тормозило формирование запросов, надо озаботиться каким-то префетчем данных в фоне. То есть, помимо сырых данных, собранных из очереди, хранить так же некие дополнительно обработанные данные, собранные как надо. Но тут уже я вам точно подсказать не смогу, не зная всех подробностей структуры отчетов.

Answer 2

[Тимур Шемсединов]

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

Answer 3

[direct_inject]

MongoDB + шардирование.

Answer 4

[BasilioCat]

Если у вас проблема в записи, сделайте так, чтобы запись была быстрее. Mongo вас спасет в том смысле, что запись можно вести не на один сервер/диск, а на несколько. Того же эффекта можно достичь, заменив медленый шпиндель (у вас же SATA?) на SSD, или на два SSD в страйпе, или на 4 ssd под каждую из тяжелых таблиц =) И, скорее всего, вы слишком много данных пишете в базу. Пишите меньше =) Чтение, агрегацию, склеивание и прочее надо вести на реплике (а то и нескольких) этой БД на другой машине. По IOPSам она должна быть не хуже мастера - то есть тоже на SSD. Если реплики воткнут, это не повлияет на реалтайм запись - просто реплики начнут отставать от мастера.
Ну и банальный совет - добавьте RAM, настройте innodb buffer pool - может он просто неэффективно используется.

Переводить запись на node возможно имеет смысл, если сложных вычислений при дергании счетчика не делается, а просто входные параметры пишутся в БД. Но если у вас этим сейчас справляется PHP - то зачем менять? Снесите на отдельную машину - лишние 100 (200 для двух машин) баксов в месяц куда дешевле оплаты программиста для переписывания этого добра.

Answer 5

[Алексей]

Делал сбор статистики на RabbitMQ + Mysql + PHP. В легкую перемалывал по несколько тысяч сообщений в секунду в один поток (PHP). Так что нода + очередь на фронт как минимум, снизит нагрузку на остальное + позволит сделать как уже писали ранее легко масштабируемую систему.

Comments

[Андрей]

Я думаю, можно рассчитывать не несколько десятков тысяч RPS на одной машинке c очередью.

Answer 6

[Дмитрий Кайгородов]

Да. В смысле Mongo или какой ещё недо-sql для big data. Но лучше чистое решение на распределённой базе данных, типа casandra. Если совсем уже "no-sql и не big data", но данных много то Riak.