И пол года не прошло, дошли наконец руки написать продолжение эпопеи с Mongo. В общем на радостях, что получили прирост 30% на двух шардах решили мы это дело выкатить в стейджинг и потестить на реальном датасете. На реальном датасете прирост производительности равнялся 0%. Но т.к. новый монго уже вышел на тот момент, а распределение данных по шардам достаточно дорогостоящая операция, то решили задеплоить 2.2 на стейджинг и тоже погонять на живых данных. Изменить PATH в init.d скрипте дело не хитрое и деплоймент занял минут 5 вместе закачкой. Тестирование показало, что производительность осталась примерно на том же уровне. В общем javascript так и остался однопоточным и map(), reduce(), sort() так и выполняются в одном и том же потоке, не смотря на все чаяния и надежды (http://docs.mongodb.org/manual/faq/concurrency/#faq-concurrency-operations-locks).
https://github.com/mongodb/mongo/blob/master/jstests/parallel/checkMultiThread.js
bin/mongo ~/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js
MongoDB shell version: 2.2.2
connecting to: test
start: Wed Jan 30 2013 03:10:04 GMT+0200 (EEST)
Wed Jan 30 03:10:04 ReferenceError: ScopedThread is not defined /home/commander/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js:5
failed to load: /home/commander/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js
Разбираться дальше не стали и в конечном итоге выкинули расчет метрик через Map/Reduce и переписали на Aggregation Framework, что дало прирост в производительности примерно 40%. В общем если бы проект писался заново, то для Aggregation/Reporting части имело бы смысл использовать обычную RDBMS, а хранение данных с фейсбука - в монго, т.к. их структура часто меняется и документно ориентированная СУБД здесь очень подходит. Data-crunching же лучше делать при помощи чего-то другого - Foursquare экспортирует данные для анализа в Hadoop например. На http://engineering.foursquare.com кстати есть несколько интересных постов и презентаций (раз и два). В общем монго под нагрузкой - это devops heavy DB.
Какие-то итоги
https://github.com/mongodb/mongo/blob/master/jstests/parallel/checkMultiThread.js
bin/mongo ~/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js
MongoDB shell version: 2.2.2
connecting to: test
start: Wed Jan 30 2013 03:10:04 GMT+0200 (EEST)
Wed Jan 30 03:10:04 ReferenceError: ScopedThread is not defined /home/commander/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js:5
failed to load: /home/commander/Downloads/mongodb-linux-i686-2.2.2/bin/checkMultiThread.js
Разбираться дальше не стали и в конечном итоге выкинули расчет метрик через Map/Reduce и переписали на Aggregation Framework, что дало прирост в производительности примерно 40%. В общем если бы проект писался заново, то для Aggregation/Reporting части имело бы смысл использовать обычную RDBMS, а хранение данных с фейсбука - в монго, т.к. их структура часто меняется и документно ориентированная СУБД здесь очень подходит. Data-crunching же лучше делать при помощи чего-то другого - Foursquare экспортирует данные для анализа в Hadoop например. На http://engineering.foursquare.com кстати есть несколько интересных постов и презентаций (раз и два). В общем монго под нагрузкой - это devops heavy DB.
Какие-то итоги
- монго решает некоторые задачи достаточно хорошо - хранение не структурированных данных (документов с разной структурой), шардинг (он автоматический), репликация (replicaSets)
- при росте нагрузки обнаруживаются некоторые bottlenecks которые необходимо решать - см. презентации выше и Scaling Riak to 25 million ops/day at Kiip & Migrating to Riak at Shareaholic, Does everyone hate MongoDB?
- mongodb use cases а также
- если все же решили что вам нужен монго - купите пакет поддержки от 10gen есть подозрение что он вам может пригодиться
Comments
Post a Comment
СООБЩЕНИЕ СПАМЕРАМ: прежде чем пытаться оставить ссылку на свой ресурс в комментарии, прошу обратить внимание на тег nofollow, которым они помечены и зря не терять ни свое ни мое время. А будете упорствовать еще и noindex поставлю