Down The Rabbit Hole

И пол года не прошло, дошли наконец руки написать продолжение эпопеи с Mongo . В общем на радостях, что получили прирост 30% на двух шардах решили мы это дело выкатить в стейджинг и потестить на реальном датасете. На реальном датасете прирост производительности равнялся 0%. Но т.к. новый монго уже вышел на тот момент, а распределение данных по шардам достаточно дорогостоящая операция, то решили задеплоить 2.2 на стейджинг и тоже погонять на живых данных. Изменить PATH в init.d скрипте дело не хитрое и деплоймент занял минут 5 вместе закачкой. Тестирование показало, что производительность осталась примерно на том же уровне. В общем javascript так и остался однопоточным и map(), reduce(), sort() так и выполняются в одном и том же потоке, не смотря на все чаяния и надежды ( http://docs.mongodb.org/manual/faq/concurrency/#faq-concurrency-operations-locks ).

tl;dr: это б....дь п........ц Ну а те кто хочет прочесть историю печальную сию - ниже ее изложение. Итак, "посчастливилось" мне попробовать MongoDB в реальном проекте (больше такого счастья не хочется почему-то). Основа проекта - бэкенд который делает интенсивный data crunching и расчет различных метрик основываясь на данных, которые хранятся в монго. Ну а поскольку в версии 2.0.x монго единственный способ делать агрегацию данных (sum, avg, etc) - MapReduce то именно при помощи его все это и считается. Одна незадача - статистика роста количества входных данных показывает что если все оставить как есть и ничего не менять то в ближайшем будущем упремся в потолок - для подсчета статистики и метрик будет уходить более суток, что не приемлемо. Соответственно возникла задача все это оптимизировать/отмасштабировать чтобы "считалось быстрее" и "все были счастливы" (product owner и customer'ы). С этого и началась моя "эпопея", которой могут позав...