После внедрения двух производственных систем поверх нереляционных БД я пришел к выводу, что нереляционные БД должны быть немного ближе к SQL, чтобы быть по-настоящему «альтернативой». Я понимаю альтернативу как «вы получаете одинаковую функциональность без огромной разницы в качестве, усилиях или стоимости».
Краткий ответ: не так часто
Длинный ответ. Основным преимуществом для нереляционных баз данных являются высокая доступность, отсутствие схемы и масштабируемость. Все это идет со значительной ценой. Если вашему приложению нужна гибкость запросов (и / или порядок сортировки, ..) и у вас есть большие требования к данным или производительности, вам лучше использовать традиционные базы данных, такие как mysql или лучше postgres. Основная проблема с нереляционной базой данных заключается в том, что если вам нужен новый способ объединения данных (например, все публикации, которые нравятся пользователю по времени), вам потребуется новый документ для вставки и просмотра для реализации запроса. Couchdb на основе документов хорош для гибкости, так как вам не нужно поддерживать схему в базе данных и можно просто «забыть» старые данные, в которых отсутствуют новые поля. Базы данных документов не реализуют весь потенциал со статически типизированными языками, хотя вам все равно придется более или менее исправить структуру данных в вашем коде.
Нереляционная БД требует push-архитектуры. Все данные для всех возможных запросов (даже редких запросов администратора) необходимо выдвигать при вставке или обновлении данных. Это стоит как процессор и диск, но вы получаете быстрые запросы. В базе данных на основе SQL вы можете просто вставить строку и заплатить цену как медленные запросы. CouchDB строит индексы по первому запросу, некоторые другие базы данных по вставке (MongoDB, Google App Engine)
Запросы Couchdb определяются как мощные, но довольно сложные для написания, поддержки и отладки представления javascript. Просмотр изменений означает, что couchdb необходимо переиндексировать все документы, что очень медленно, если у вас есть миллион или более документов. Сообщения об ошибках от couchdb не могут быть расшифрованы обычным администратором.
Обслуживание Couchdb требует некоторых ручных усилий для сжатия файлов данных и индексов, новые версии имеют автоматическое сжатие, но для его использования требуется некоторая осторожность. Сжатия должны быть запланированы вне пиков и т. Д. Это может быть написано довольно легко, хотя Db dump, резервное копирование и подобные инструменты все еще довольно малы.
Короче говоря, это не стоит усилий, если вам не понадобится производительность или масштабируемость couchdb. Лично я считаю возможным "эмулировать" большинство нереляционных преимуществ производительности БД с помощью стека sql db, redis и memcache. По крайней мере, пока данных не слишком много.