Чего не хватает в NoSQL-хранилищах (на примере CouchDB) - Часть I

На днях завершился опрос о плюшках, которых не хватает в NoSQL-хранилище CouchDB. С этой базой я знаком уже года два, последний - активно. И, читая новости, вижу, что много вопросов по NoSQL могло быть не задано, не пытайся люди одеть рубашку, не сняв пальто применить свои знания SQL-парадигмы к тому, что к SQL отношения не имеет. Пример? Oracle у многих ассоциируется с SQL. Да, сам сервер, в отличии от сервиса, хорош. Но тот NoSQL что они сваяли выглядит хилым зародышем по сравнению с тем, что уже давно есть в бесплатных системах. Новое лучше воспринимать с пустой головой.

Оказалось, больше всего жгут ждут (прокомментирую некоторые пункты, опираясь на собственный опыт работы с CouchDB):

1. Мощный язык запросов. Наверное, ожидают что-то типа SQL, но, если задуматься, так ли горячо он нужен для прикладных задач? А ведь на решение таких задач и нацелены NoSQL-решения. Новый язык - значит, больше времени на изучение, более дорогая поддержка готового продукта (много в мире окажется специалистов по этому языку?), выше "порог входа"... Японский мобильный оператор NTT DoCoMo (на март 2012 г. почти 60 млн. абонентов) почему-то выбрал CouchDB не заморачиваясь вопросом об эскьюэль-подобном языке.
   
2. Ждут документацию. Что странно, т.к. информации в Интернете и в списках рассылки CouchDB - крайне много. И разработчики - грамотные люди - ждать ответа не заставляют.
3. Цепочки map/reduce. Да, получить "в коробке" такую функциональность было бы неплохо. С другой стороны, как отдельный "плагин", она давно есть.
4. Частичное обновление документов. Небольшой экскурс. CouchDB при обновлении делает копию документа (близкая аналогия документа в SQL - запись). Документ копируется целиком. Это быстро. Но бывает накладно; особенно, когда документы большие и обновляются часто. В общем-то, всегда можно спроектировать хранилище так, что о частичном обновлении вспоминать не будете. Но проектирование = время. А чем мне нравится CouchDB, это возможностью за две-три недели создать продукт, который "уже можно дать пощупать". Признаюсь, после Lisp, Java, [T-]SQL, PHP, JavaScript и С++ скорость NoSQL-разработки меня очень впечатлила.
5. API для управления фоновыми процессами. У NoSQL-баз есть интересная особенность: они выдают результат мгновенно... если им дали время подготовить его. Иначе, к примеру, при миллионе записей, временем на кофе / почитать / поспать (всё это вместе - не редкое исключение) Вы себя обеспечили. Бывает полезно отключить тяжёлые процессы, ускорив тем самым "нужные сейчас вычисления". Например, отменить репликацию или сжатие базы, т.к. вдруг узнали что "много клиентов, а компьютеры сегодня очень тормозят"... Нужное требование. Но вверху списка? Нет, далеко не для всех.

Здесь ещё более 20-ти пунктов. Бооольшой список...

Скриншот (см. ниже) и продолжение (чит. дальше) >>