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

Продолжение. Начало > "Чего не хватает в NoSQL-хранилищах. Часть I".

6. Более тонкая авторизация. Заглянув в прошлое, можно увидеть: с момента официального выпуска 1-й версии CouchDB, в вопросах защиты информации от постороннего взгляда проделана большая работа. Причина в том, что одним из пунктов идеологии этой свободно распространяемой системы системы было сделать информацию общедоступной. Чудесная идея. Но войны требуют секретов. А современный рынок - это война и политика, здесь пока нет места для помощи. И разработчики пошли рынку реальности навстречу.
7. Доступность ленты изменений в представлениях. Одна из уникальных особенностей CouchDB в том, что в неё можно сразу (сразу!) положить данные в любом (в любом!) виде и получать информацию в нужной нам форме тогда, когда (когда!) в этой информации возникла потребность. В этом нам помогают представления CouchDB. Но хочется большего! И быстро трансформировать ленту изменений http://127.0.0.1:5984/database/_changes своим представлением - одно из этих "хочу".
8. Богатая поддержка reduce-функций. Google ввела в мир вычислений модель "Map/Reduce". CouchDB использует эту технологию... в накопительном виде: документ проходит обработку функциями map/reduce, достраивая B-деревья, только при добавлении / изменении документа. Это быстро. Так быстро, что позволяет писать map/reduce запросы на JavaScript. С одной стороны, бывает необходимо, чтобы свёртка (reduce) проходила ещё быстрее (частично это решается использованием встроенных функций); с другой, не хочется не эффективно создавать свёртки на JS для стандартных случаев (например, когда требуется получить список уникальных записей или сгруппировать элементы по ключу, суммируя их значения; тем более, что в MongoDB это есть).
9. Частичное чтение документов. Можно запросто получать часть документов и сейчас, формируя нужный View. Но счастье это будет продолжаться ровно до тех пор, пока Вы не предложите CouchDB действительно много - по теперешним меркам, более 1 млн. - документов (записей). Тут вдруг оказывается, что 100 Гб на базу - это вовсе не "немеряно места". Копаем глубже - и видим: созданные нами view-представления довольно прожорливы. Лучший (и, похоже, наиболее эффективный) способ умерить их аппетит - извлекать из хранилища минимум информации, а приложением отправлять отдельный запрос при необходимости вытянуть нужные части документа. В не таком уж далёком прошлом, когда файлы не рекомендовалось хранить в SQL-базах, желание читать часть документа (записи) ни у кого не возникало: просто получали всю запись и были счастливы. CouchDB вполне может заменить привычную файловую систему. И разработчики рекомендуют использовать эту возможность. В результате, неожиданно, ага, можем получить хранилище, в котором документы весят по сотне мегабайт. К счастью, CouchDB не отправляет бинарные файлы вместе с документом. Но если необходимо обрабатывать содержимое файлов view-выборками, хранение содержимого в поле документа оказывается единственным выходом. И тогда может спасти только чтение нужных сейчас полей, оставляя тяжёлые данные на сервере.
10. Расширение и рефакторинг протокола view-cервера. Для тех, кому JavaScript язык не родной, CouchDB предоставляет возможность создавать представления (view) практически на любом известном сегодня языке программирования. Мне не приходилось создавать свой view-сервер (я люблю JavaScript). Наверное, в реализации протокола действительно не всё хорошо, раз это пожелание вошло в первую десятку. Тем не менее, сейчас уже есть view-серверы для многих языков.

Продолжение (чит. дальше) >>