[spoiler]Надо прежде всего отметить, что Couchbase -- поставщик одной из самых популярных опенсорсных NoSQL-систем, поэтому ее опрос (как минимум его стиль и направленность) в определенной степени ангажирован.
И тем не менее было крайне интересно ознакомиться с его результатами.
Основная масса, почти половина опрошенных недовольна негибкостью РСУБД и невозможностью менять схему БД на лету. Напомню, что NoSQL-серверы хранят не таблицы, а иерархические документы свободной структуры (как правило, в формате JSON/BSON), в которых, впрочем, общие для всех поля можно индексировать и работать с ними так же, как и с полями реляционных таблиц.
Более трети недовольны проблемами с масштабируемостью РСУБД, а NoSQL-системы способны почти линейно наращивать свои возможности подключением бэк-серверов в горячем режиме. Более высокая в сравнении с РСУБД производительность достигается активным применением схем "субд-в-памяти" и мощными модулями кэширования, эксплуатирующими простоту архитектуры, и соответственно способность без проблем поддерживать БД из миллиардов документов на весьма ограниченных аппаратных ресурсах.
Стоимость важна значительно меньше -- как справедливо отмечает Андрей Колесов, сейчас она играет малую роль на фоне общих проектных затрат (в опросе так же -- цена актуальна лишь для 16% респондентов), но NoSQL как раз отличаются еще и крайне простой инсталляцией, а то и полным ее отсутствием: просто скачай exe-файл и запусти (для обновления и перехода к новой версии просто перезапиши экзешник), и нуль-администрированием.
В дополнение к Couchbase -- в феврале вышла версия не менее популярного свободного NoSQL-сервера MongoDB 2.1, среди нововведений которого поддержка агрегации в SQL-стиле group by.
Упомяну и минусы NoSQL-подхода, о которых Couchbase не говорит:
- сложность поддержки ненормализованных данных;
- трудоемкость создания сложных запросов, отсутствие JOIN-соединений и, как следствие, большой объем ручного программирования;
- нестандартность, слабая интеграция; нету единого языка запросов типа SQL, каждую NoSQL-СУБД надо изучать с нуля.
Но -- отклики разработчиков в отношении РСУБД весьма показательны:
“Replace as much as possible of Microsoft SQL Server”
“My hope is that I can finally stop using MySQL in 2012”
“Free us from Oracle? Increase performance?”
“Help us deploy new features faster without having to manage SQL patch scripts and migrations”
“Allow us to shard billions of documents across multiple commodity servers”
Условно: система массового видеонаблюдения, когда в реальном времени в индексируемом видеопотоке надо распознавать его смысл (типа, какую галку за кого в бюллетене человек поставил
Почему используется несколько типов БД: разные заказчики, разные СУБД, и для сервера приложений приходится реализовывать к ним разные внутренние интерфейсы доступа. Кстати, по трудозатратам реализации этого интерфейса, MS SQL Server ну совсем уныл получается (правда, интерфейс к нему реализовывал не я).
Какой разброс запросов (т.е. различных, а не однотипных)?
Невысокий.
Какой процент выборок/вставок данных?
Когда несколько сотен одновременных пользователей, совсем усредненно 70/30. От конкретного проекта зависит, но сильного перекоса в какую-либо сторону нету.
Кстати, из доков, стандарные ТТХ для NoSQL примерно такие: по времени 10 выборок равны 7 вставкам.
Как обеспечивается атомарность?
Штатными средствами. Но обеспечить ее полностью не удается в силу специфики больших объемов (десятки гиг) как сырых данных для движка аналитики, так и его неструктурированной выдачи.
Вот например про атомарность в MongoDb
http://joydevel.blogspot.com/2011/08/mongodb.html
Да, у вас весьма специфическая задача. Я с подобной не сталкивался ни разу, но из того, что вы описал и правда похоже, что NoSQL должна справляться лучше.
А MongoDb доступна в исходных текстах, с ней попроще:)