Nikolay Shestakov:
Подход обозначенный Вами либо вытекает из вашего непрофессионализма, либо является простым троллингом. Так или иначе, расскажу свое мнение.
1. Несколько лет назад участвовал в разработке проекта со сложной логикой на стороне сервера приложения. База данных использовалась в качестве простого реляционного хранилища и взаимодействие с ней было реализовано через ORM Hibernate. Поддерживаемыми СУБД были MS SQL, Oracle и Postgres. Мы проводили нагрузочное тестирование на базе размером около 500Gb на не топовых серверах (памяти было толи 32Gb, то ли 64Gb. Точно не больше). Сервер приложений и СУБД находились на разных серверах. Нагрузка подавалась эмитацией работы реального пользователя через силениум (были несколько базовых сценариев работы пользователи и мы их полностью воспроизводили). Так вот: самой быстрой базой при нашем профиле использования оказалась MS SQL, а Oracle и Postgres были примерно одинаковыми (разрыв не превышал 10% от самой "быстрой" и самой "медленной" БД).
2. На текущем месте работы мы пытались использовать MongoDB в нескольких проектах.
В одном из них размер базы около 250Gb (около 150M записей в одной таблице). База шардирована и реплицирована.
При эксплуатации MongoDB такого объема возникла проблема с добавлением новых нод: на ребалансеровку шардов стало уходить до нескольких недель. В итоге конкретно в этом проекте от использования MongoDB отказались.
При этом MongoDB продолжает использоваться в проектах где объем базы гораздо меньше.
3. Так получилось, что нам приходится для анализа хранить логи за последние 3 года (а в некоторых проектах и дольше). Ежедневный размер логов только сервиса в разработке которого принимаю участие я около 30Gb. Итого за три года 3*365*30Gb ~ 32Tb. При этом по этим логам периодически считается всякая статистика.
Ни postgresql ни MongoDB для этой задачи не подходят. Для хранения логов мы используем хранилище с возможностью выполнения Map/Reduce .
Как можно догадаться,
* в первом примере хорошо себя показывает Postgres, и совершенно не пригодны ни MongoDB, ни Map/Reduce;
* во втором примере есть как удачный опыт использования MongoDB, так и неудачный;
* в третьем не подходит ни MongoDB, ни Postgres.
Так, что не надо говорить, что одна база лучше другой, а надо говорить, что в конкретно этой задаче база такая-то показала себя лучше чем база такая-то.
