Александр Дегтярев какие выборки нужны? Нужны ли выборки внутри документа по разным критериям или может key-value достаточно и документно-ориентированная не нужна?
слабосвязанные данные, например новости - краткое описание новостей точнее
В общем, если нужны сложные выборки и несколько разных индексов - берите Монгу, если выборки только по одному ключу - посмотрите key-value: если вам для основного хранения (т.е. НЕ для кэша), то попробуйте Riak, если для кэширования чего-то, что уже и так есть в какой-то другой (основной) БД, то неплохо подойдет Redis.
Александр Дегтярев в целом говорить не совсем правильно, т.к. моделей данных и моделей хранения действительно разных очень много. Есть близкие к SQL, "почти-SQL", вроде Кассандры, а есть максимально простые хранилища вроде Redis. NoSQL базы обычно выигрывает по мастабируемости (т.к. СУБД проще и не такая гибкая как SQL-СУБД) - репликация настраивается проще и почти всегда из коробки, и простотой использования в простых сценариях, но проигрывают в гибкости (например, в документно-ориентированных базах обычно нет понятия, аналогичного JOIN в SQL) и иногда в надежности и атомарности/изоляции транзакций. Например, Монга гарантирует атомарность транзакции только в рамках документа. Это значит, что если вы просто не можете гарантированно записать два и более документов так, чтобы параллельные транзакции увидели сразу конечный результат. Это, в свою очередь, делает эту СУБД непригодной для финансовых транзакций.
Еще есть два фактора, которые зависят не сколько от самих NoSQL моделей данных, сколько от текущей ситуации: 1) многим SQL-базам уже не один десяток лет, и они набили много шишек, и вылечили "детские" болезни, с которыми можно столкнуться в более молодых СУБД; 2) NoSQL-решения, позволяющие работать с данными в отсутствие схемы иногда играют злую шутку с разработчиком, и отсутствие той дисциплины, которая нужна при проектировании SQL-базы приводит к превращению базы в кучу неуправляемого хлама.
В целом, главный критерий, который защитит вас от многих бед - выбирать базу либо исходя из жестких требований к производительности/масштабируемости, если таковые есть, либо исходя из модели данных вашего приложения. Есть данные, которые естественно укладываются в реляционную базу, есть данные, которые просятся в документную. Любимый мой пример: информация о товаре может быть разрознена и отличаться от товара к товару, поэтому обычно лучше её хранить в документной базе с необходимыми индексами. А вот информация о покупках обычно однотипная, т.к. указывается артикул или иной код товара, код клиента, количество. Или учет этих товаров на складе. Надежность и изоляция транзакций в этом случае будет очень важна, и мой выбор - реляционная СУБД.
Александр Дегтярев и еще третий субъективный критерий: если вы пользовались до этого SQL-базами, обязательно внимательно читайте документацию и возможности той NoSQL-базы, которую вы выбрали. Многие из них внезапно могут не иметь тех свойств и гарантий, которые кажутся обязательными и само-собой разумеющимися в мире SQL. Это прямое следствие других подходов к архитектуре и других требований к СУБД. Есть проекты, где "быстро" важнее чем "точно" (см. eventual consistency).
Простой
