Во-первых, я не отношусь к NoSQL скептически. Я считаю, что у таких продуктов большое будущее на рынке. Потому, что для них существует огромная ниша, которую они только начинают занимать. В свое время PHP занял такую нишу в качестве массового языка для веб-разработки, хотя многие относились и относятся к нему скептически, и это даже мягко сказано.
Во-вторых, что касается проблем NoSQL. Его главная проблема - та задача, которую он пытается решить.
Итак, у нас был старый добрый RDBMS, которому приходилось исполнять сложные запросы, комбинировать данные из разных таблиц. Это и была причина его торможения. Поэтому перед ним ставили всякие redis, memcached и просто внутренние кеши приложения. И это решало проблему быстродействия.
Потом появились парни в розовых кедах и сказали: "Зачем такая сложная архитектура? Поменяем все это на ОДИН сервер, который будет хранить объемы как oracle и отдавать со скоростью memcached". Это решение выглядело как полностью аналогичное предыдущей схеме, но с меньшим количеством деталей. Аналитики и бизнес ухватились за это и возвели NoSQL на трон, а предыдущий стек технологий отправили в корзину. Все казалось замечательно. Но при этом упустили всего одну мелочь - данные в NoSQL хранятся не в
Нормальной форме, и это неотъемлемое свойство технологии не возможно исправить.
Чем опасно хранение данных не в нормальной форме? Это начали понимать по мере разработки. Когда структура базы подогнана под запросы, эти данные выбирающие, и когда в процессе разработки возникает необходимость выбирать данные как-то по-другому, приходится создавать новые структуры, под новые запросы, то есть ДУБЛИРОВАТЬ ДАННЫЕ. Вот с этого момента эротический сон превращается в кошмар. Когда данные пишутся в одно место, то они тут же мгновенно (или не мгновенно?) должны быть отражены в другом месте. Если производить такую синхронизацию синхронно с записью, то возникают забытые проблемы с производительностью, если асинхронно - то возникают (совсем недавно забытые) проблемы с инвалидацией кешей. Но это - только начало. Следующий кошмар - контроль (ссылочной, например) целостности. Вся грязная работа, которой раньше занимался движок RDBMS, опять ложится на плечи прикладных кодеров. В итоге наступает момент, когда усложнять логику, контролирующую работу с базой (раньше о такой необходимости даже не слушали) становится дороже чем выбросить весь проект в корзину и переписать все обратно на нормальную RDBMS. И тогда приходит философское понимание того, почему эту классическую форму данных в науке называют НОРМАЛЬНОЙ.
