[Tiulkin]

Буду рад услышать любые высказывания относительно опыта использования MongoDB в полевых условиях.
Как себя ведет репликация/шардинг, сильно ли тормозит aggregation framework и т.п..

[pmp]

что Вы имеете ввиду под серьезной нагрузкой ?
А вообще для моих специфических задач - намного быстрее Mysql

[Tiulkin]

что Вы имеете ввиду под серьезной нагрузкой ?

Пара тысяч одновременно работающих пользователей и несколько сотен гигабайт данных.

А вообще для моих специфических задач - намного быстрее Mysql

Для моего проекта не вариант абсолютно (нужно очень много написать, чтобы объяснить почему).

[maxwallaby]

Пара тысяч одновременно работающих пользователей и несколько сотен гигабайт данных.

Facebook и Twitter используют MySQL и процветают, а для Вашего нового проекта это не вариант?
MySQL прекрасно справляется со всеми нагрузками и требованиями, и вопрос выбора между ним и Mongo должен появляться только там где идут различия в хранимых структурах данных. Если у Вас древовидная структура разной глубины вложенности и отсутствие связных данных, то пожалуйста, но для простых структур данных, независимо от количества информации реляционная модель будет всегда на первом месте.

[Ems]

Господа, давайте не будем создавать холивар. Mysql - это совсем другая опера и опера эта неновая. Твиттер и Фейсбуки - забудьте. Это достаточно уже старые компании. И используют старый инструментарий, им нет уже смысла менять всю архитектуру. Процедура достаточно затратная и долгая. Может со временем они изменятся. А пока же, теперь чего равняться на них что ли всем?

MongoDB - это большая производительность, это отличная масштабируемость. Это даже другая философия.
Для решения поставленных задач, советую посмотреть ещё в сторону Tornado и Twisted. Возможна связка.

[maxwallaby]

Это достаточно уже старые компании. И используют старый инструментарий, им нет уже смысла менять всю архитектуру.

Старые компании?? Да им по 6-7 лет от силы.. Это Mercedes или Ford старые компании.
Twitter в своё время думали так же как Вы сейчас и хотели отказаться от MySQL в пользу Cassandra, но в итоге, спустя три года, они используют MySQL, Cassandra не смогла его заменить в полном объеме.
Данные сами по себе реляционные и связанные, и key-value подход не всегда поможет логично обработать такие данные. Производительность отличная и в MySQL, масштабируемость? - А нужна ли она в контексте этого обсуждения? Не думаю что автор будет разворачивать кластер или хотя бы впираться в такие обьемы, при которых нужны будут столь кардинальные решения.

[Ems]

Старые компании?? Да им по 6-7 лет от силы.

Для IT-сектора это очень много.

Facebook, вообще писан на php. Сейчас никто в здравом уме не будет писать подобный проект на php. Но опять же, на форумах куча умников, которые приводят этот факт и пишут, что php - панацея для всего. Но мы сейчас не об этом.

А когда автору понадобится создавать кластер? Когда объёмы станут большими? Рвать волосы и думать, что теперь делать с этим mysql?

MongoDB - как минимум в данном случае, поведёт себя не хуже MySQL. А в будущем, имеет большую адекватность в поведении и масштабируемости.

[Tiulkin]

maxwallaby, Если есть опыт использования MongoDB, все будут рады его услышать, а размышления на тему что лучше MySQL или MongoDB уместны исключительно в контексте конкретной задачи. Я больше 10 лет работал с большими SQL (от Sybase до MSSQL) базами и в курсе всех их достоинств и недостатков. Для задачи, относительно которой был задан вопрос, альтернативы MongoDB на текущий момент нет.
p.s. Даже если не рассматривать необходимость в проекте NoSQL-подхода, назовите еще один движок, для установки которого под любую(!) мэйнстримную ось достаточно тупо скопировать исполняемый файл(даже для винды) и который, при этом, в случае необходимости, может обеспечить практически неограниченное горизонтальное масштабирование.

[maxwallaby]

Для задачи, относительно которой был задан вопрос, альтернативы MongoDB на текущий момент нет.

Ну если так, то пусть. Может это просто моя любовь к реляционным базам проявляется...
Хотя где-то в глубине я уверен что все Ваши задачи можно решить и без NoSQL, во многих местах его очень переоценивают.

[Tiulkin]

Хотя где-то в глубине я уверен что все Ваши задачи можно решить и без NoSQL

Конечно. EAV-антипаттерн еще никто не отменял