Анонсирован (https://blogs.apache.org/couchdb/entry/apache_couchdb_1_3_0) релиз распределенной, документ-ориентированной базы данных Apache CouchDB 1.3.0 (http://couchdb.apache.org/downloads.html), относящейся к классу NoSQL-систем. Запросы к CouchDB и индексация данных могут выполняться в соответствии с парадигмой MapReduce (http://ru.wikipedia.org/wiki/MapReduce), используя для формирования логики выборки данных язык JavaScript. Ядро системы написано на языке Erlang, оптимизированного для создания обслуживающих множество параллельных запросов распределенных систем. View-сервер написан на языке Си и базируется на JavaScript-движке Mozilla Spidermonkey. Исходные тексты проекта распространяются (http://couchdb.apache.org/downloads.html) под лицензией Apache 2.Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений. В качестве единицы хранения данных выступает документ, имеющий уникальный идентификатор, версию и содержащий произвольный набор именованных полей в формате ключ/значение. Для организации псевдо-структурированного набора данных из произвольных документов (агрегирования и формирования выборок) применяется концепция формирования представлений (view), для определения которых используется язык JavaScript. На JavaScript также можно определять функции для проверки корректности данных при добавлении новых документов в рамках определенного представления.
CouchDB хранит (http://couchdb.apache.org/docs/overview.html) данные в формате упорядоченного списка и позволяет производить частичную репликацию данных между несколькими БД в режиме «мастер-мастер» с одновременным обнаружением и разрешением конфликтных ситуаций. Каждый сервер хранит свой локальный набор данных, синхронизированный с другими серверами, которые могут переводиться в offline-режим и периодически реплицировать изменения. В частности, данная возможность делает CouchDB привлекательным решением для организации синхронизации настроек программ между разными компьютерами. Решения на базе CouchDB внедрены в таких компаниях как BBC, Apple и CERN.
Основные улучшения, добавленные в CouchDB 1.3.0:
- В HTTP-интерфейсе добавлена поддержка протокола Server-Sent Events (http://www.w3.org/TR/eventsource/) для информирования приложения об изменении базы. Реализована экспериментальная поддержка спецификации Cross-Origin Resource Sharing (http://www.w3.org/TR/cors/) (CORS). Обеспечена возможность ограничения уровня рекурсивной вложенности при перезаписи URL. Обеспечена возможность синхронного хэширования паролей при использовании API /_config/admins.- В системе репликации, для увеличения эффективности средств восстановления, в состав идентификатора контрольной точки включен новый серверный UUID;
- В системе хранения устранены конфликты при удалении и создании документа в рамках одного пакетного задания;
- В сервере обработки представлений добавлена поддержка изменения дополнительных заголовков ответа до выполнения вызова send().
- В web-интерфейсе Futon добавлен вывод продолжительности запроса на создание представлений, по умолчанию отключены кнопки для нажатия которых у текущего пользователя нет прав доступа;- Для хэширования паролей задействован алгоритм PBKDF2 (http://ru.wikipedia.org/wiki/PBKDF2) с возможностью настройки рабочих параметров;
- Тестовый инструментарий перемещён в CLI-интерфейс;
- Добавлен новый алгоритм генерации UUID - utc_id;
- В системе сборки улучшено определение компиляторов C/C++.
URL: https://blogs.apache.org/couchdb/entry/apache_couchdb_1_3_0
Новость: http://www.opennet.me/opennews/art.shtml?num=36675
> Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений.А как там с правами доступа? Приложение только на couchdb + js построить реально?
И как быть с тем, что браузеры не дают выполнять json кросдоменно. Оно умеет оборачивать в jsonp?
> А как там с правами доступа?Все в порядке. Система немного непривычная, но вполне логичная:
http://guide.couchdb.org/draft/security.html
http://wiki.apache.org/couchdb/Security_Features_Overview> Приложение только на couchdb + js построить реально?
Вполне. Собственно на это и было рассчитано. До моего знакомства с каучом я жс вообще не признавал как что-то серьезное, но сейчас мое мнение изменилось.
> И как быть с тем, что браузеры не дают выполнять json кросдоменно. Оно умеет оборачивать в jsonp?
Умеет, но все-же там больше рассчитано, что само веб-приложение будет лежать в самом кауче. В смысле каучдб не столь база данных, сколько целиком сервер приложений. К примеру, у нас на кауче крутится система сбора данных со счетчиков электроэнергии. Сами счетчики по https используя только rest шлют показания на кауч, кауч их сохраняет в базу и он же эти данные обрабатывает, там же лежат html'ки с жавоскриптом которые уже обработанные данные показывают в красивом и удобном виде.
> Сами счетчики по https используя только rest шлют показания на кауч, кауч их сохраняет в базу и он же эти данные обрабатывает, там же лежат html'ки с жавоскриптом которые уже обработанные данные показывают в красивом и удобном виде.Если сюда забредут юные борцы за юниксвей, они обязательно возмутятся по поводу СУБД со встроенным веб-сервером :)
> Если сюда забредут юные борцы за юниксвей, они обязательно возмутятся по поводу СУБД со встроенным веб-сервером :)А что с юниксвеем-то?
> Вполне. Собственно на это и было рассчитано. До моего знакомства с каучом
> я жс вообще не признавал как что-то серьезное, но сейчас мое
> мнение изменилось.Интересно, что так повлияло на ваше мнение, может невозможность code reuse во вьюхах? Или необходимость поддерживать ссылочную прозрачность в языке, который для этого не пригоден, мягко говоря?
1. Couch поддерживает code reuse в view через CommonJS-подобные require(). В старых версиях не составляло труда написать макросы которые вставляли исходники прямо в текст view – ведь view – всего лишь данные дизайн-документа.2. В Clojure, Scheme и Common Lisp (и даже в OCaml!) тоже нет referential transparency, к слову. Как и в большинстве популярных ЯП вообще кроме Haskell, который популярным можно назвать с некоторой натяжкой.
Другое дело, что у концепции CouchApp есть серьёзные ограничения, обойти которые часто очень сложно: к примеру, невозможность write-only настройки авторизации без дополнительного прокси-сервера, или параметризированные view, или простейшие отношения многие-ко-многим, типа простейших тэгов, для которых необходимо поднимать дополнительный отдельный от коуч индекс и т.д..
> А как там с правами доступа?Фигово. В пределах одной базы разграничение на доступ к записям пользователям сделать нельзя. То есть читать писать могут все кто авторизовался. Выход - создавать на каждого пользователя свою БД и да их может быть много, например если в БД хранить почту пользователей. И делать общие БД с которыми синхронизировать пользовательские БД если нужны общие данные.
Zachem? Esli est MongoDB!
Это несколько разные вещи. Хотя, конечно, mongodb лучше :)
Mongo она по сути inmemory, во всяком случае нужно обязательно тестить ситуации когда данных будет больше чем оперативы.
А тут база на дискею
В этом смысле CouchDB ближе в всем знакомым и понятным SQL базам.
он понятен тем, кто знаком с Lotus Domino Notes, и логика взята оттуда, да и сам разработчик занимался Notes
причина тоже понятна - индусы много чего испортили в домино, и под ИБМ Кацу стало скучно ;)
http://www.leadershipbynumbers.com/ms.nsf/d6plinks/BMAA-7LQP2J
http://damienkatz.net/2010/02/migrating_notesdomino_to_couch...
Скорее всего гражданин Кац упарывался чем-то тяжелым и тужился написать кауч на С++. Потом, во время реабилитации, методом херак-херак и в продакшен наваял вполне работающий сервер на Эрленге. Теперь вот, видать, опять сорвался, потому как сейчас пилит каучбейс уже на Си, слив каучДБ орлам из апача.
> Mongo она по сути inmemory,Приснилось, что-ли? Или трава крепкая попалась?
Вот именно из за такой квалификации среднестатистического разработчика и не стоит использовать монгу без предварительного нагрузочного тестирования. Про память можно посмотреть в гугле по "mongodb memory limit".
Тут можно сказать типа руки кривые если то чьи это проблемы? Проблемы получаются заказчика сервиса, а косяк монги в том что ее пиарят умалчивая серьезные особенности (читай недостатки) данной БД.
> Zachem? Esli est MongoDB!ну как минимум наверно по тому что MongoDB не может обновить атомарно сразу 2~3 документа, по принципу "либо изменятся сразу все, либо не изменится ни один" :-).
А есть тесты производительности CouchDB vs Couchbase?
Когда уже, наконец, наработки Bigcouch в него вмержат?