В рамках одного сервера она практически бесплатная при наличии индексов.

В случае с MongoDB придется либо (в хорошем случае) хранить подчиненные записи в этом же хеше, либо (как в примере со всеми комментами данного автора) делать full index scan (при наличии индекса по author_id, иначе — full table scan).
Предположение MongoDB такое: запросов второго рода у вас почти никогда не возникнет. Мой опыт работы подсказывает, что возникает, да еще как — функционал сервисов часто совсем не так прост, как хотелось бы программисту.

Но в своей нише (простая схема данных, простые запросы, очень выссокая нагрузка) MongoDB смотрится вполне достойно.

Вот это беда, конечно. Держать все базы в RAM не очень хочется — дорого.

Надеюсь, что им удастся в будущем реализовать эффективное кеширование и страниц данных, и страниц индексов.

Я сам его пока не ел :)

У него, как и у остальных NoSQL, есть ограничения, они много перекладывают на сторону приложения:
— организацию сложной схемы данных, целостности, согласованных изменений (транзакций)
— готовность к периодическим сбоям, повторный накат изменений при ошибке (причем, возможно, часть предыдущих изменений все-таки наложилась)
и т.д.
Если вы готовы к таким ограничениям — то да, есть смысл попробовать.

Можно жить и без JOIN. Но грустно:
select id from Companies where domain like '%.ru';
select name from Staff where company_id in (большооой массив интов);

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

Главный плюс, который я увидел в MongoDB — п. 18, т.е. выход за пределы in-memory DB. Это воодушевляет.

А вот, кстати, не осветили тему в видео: как в MongoDB гарантируется уникальность _id в системах с шардингом?

> Да, но редко (статистика к примеру раз в сутки) — тоже делайте вложенными, map/reduse выберет вам все, что нужно без каких либо проблем.

как это — без проблем? это же full scan. такие запросы получаются очень дорогими.

Ключевой ли это функционал — часто не скажешь. Например, на Хабре это есть. Ключевой ли он тут? Вряд ли. Но если каждый запрос этой страницы будет приводить к полному сканированию всего контента сайта — это однозначно уложит систему.

Я, кстати, не вижу нормального решения для выборки всех комментов автора средствами MongoDB, кроме денормализации — хранения предгенеренной копии всех комментов автора в отдельной коллекции авторов.

Пост — да, наверное, можно организовать единым хешом со всеми комментами, проблем будет меньше, чем с целым блогом.
Но я говорил про немного другую проблему: появился популярный пост и все бросились его комментировать. В результате и сама структура (пост+комменты) получается большой, и при каждом следующем комменте она перезаписывается или полностью или, в лучшем случае, в среднем наполовину (комменты — дерево, новые не аппендятся в конец).
В результате такие записи становятся узким местом системы, чего в случае РСУБД мы не наблюдаем.

Торренты раздавать опять же :)

Ну как — зачем? Холодильник не размораживать каждый раз перед отпуском.

Интересно, а если это решение для дома, зачем делать его автономным? Версия, работающая от сети, не имеет же проблем с энергопотреблением.

Дайте догадаюсь — заинтересованности ICQ в вашей персоне? :)

В ICQ — нет, написано же в посте.

Ну раз вы помните его аж с 90-х, может, он не так и плох?

Видеозвонков сейчас где только нет.
И в ICQ, и в Mail.ru агенте, и в QIP.

Видимо, потому же, почему они считают, что доля айфона вдруг передумает расти.
Вот такое у них экспертное мнение. Поди оспорь.

Просто замечательно, что у Вас есть желание глубже разобраться в задаче. :)
Возможно, я был излишне резок, просто мне кажется, что количество туманных анонсов о возможностях алгоритма пока что плохо соотносятся с его качеством.

Дорожки классификации РОМИПа со списками литературы, в принципе, должно быть достаточно. Также настоятельно советую взять тот же набор данных и прогнать свой алгоритм на них, чтобы объективно оценить его качество по сравнению с остальными.
Если РОМИП перерастете, вот тут есть совсем фундаментальная теория. Ваша задача — из области классификации, или обучения с учителем.

Кстати, как раз этот перелом объясним — WPh начнет есть Symbian.

А вот почему айфон упорно рос два года, обоглан Блекберри, а в 2011 году вдруг сдуется — это вопрос века, да.

А остальные задачи в три строчки — слабо? :)

А Вы знаете, что такое Bullshit Bingo?

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