https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html Анонсирован (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. <br><br><br><br>Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений. В качестве единицы хранения данных выступает документ, имеющий уникальный https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#17 Mon, 15 Jul 2013 19:12:44 GMT 1. Couch поддерживает code reuse в view через CommonJS-подобные require(). В старых версиях не составляло труда написать макросы которые вставляли исходники прямо в текст view &#8211; ведь view &#8211; всего лишь данные дизайн-документа. <br><br>2. В Clojure, Scheme и Common Lisp (и даже в OCaml!) тоже нет referential transparency, к слову. Как и в большинстве популярных ЯП вообще кроме Haskell, который популярным можно назвать с некоторой натяжкой.<br><br>Другое дело, что у концепции CouchApp есть серьёзные ограничения, обойти которые часто очень сложно: к примеру, невозможность write-only настройки авторизации без дополнительного прокси-сервера, или параметризированные view, или простейшие отношения многие-ко-многим, типа простейших тэгов, для которых необходимо поднимать дополнительный отдельный от коуч индекс и т.д..<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#16 Mon, 15 Apr 2013 06:51:00 GMT Вот именно из за такой квалификации среднестатистического разработчика и не стоит использовать монгу без предварительного нагрузочного тестирования. Про память можно посмотреть в гугле по "mongodb memory limit".<br>Тут можно сказать типа руки кривые если то чьи это проблемы? Проблемы получаются заказчика сервиса, а косяк монги в том что ее пиарят умалчивая серьезные особенности (читай недостатки) данной БД.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#15 Sun, 14 Apr 2013 11:47:52 GMT &gt; Вполне. Собственно на это и было рассчитано. До моего знакомства с каучом <br>&gt; я жс вообще не признавал как что-то серьезное, но сейчас мое <br>&gt; мнение изменилось.<br><br>Интересно, что так повлияло на ваше мнение, может невозможность code reuse во вьюхах? Или необходимость поддерживать ссылочную прозрачность в языке, который для этого не пригоден, мягко говоря?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#14 Sun, 14 Apr 2013 11:41:44 GMT Скорее всего гражданин Кац упарывался чем-то тяжелым и тужился написать кауч на С++. Потом, во время реабилитации, методом херак-херак и в продакшен наваял вполне работающий сервер на Эрленге. Теперь вот, видать, опять сорвался, потому как сейчас пилит каучбейс уже на Си, слив каучДБ орлам из апача.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#13 Sat, 13 Apr 2013 00:28:39 GMT Когда уже, наконец, наработки Bigcouch в него вмержат?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#12 Fri, 12 Apr 2013 19:23:04 GMT &gt; Zachem? Esli est MongoDB!<br><br>ну как минимум наверно по тому что MongoDB не может обновить атомарно сразу 2~3 документа, по принципу "либо изменятся сразу все, либо не изменится ни один" :-).<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#11 Fri, 12 Apr 2013 19:19:33 GMT &gt; Mongo она по сути inmemory,<br><br>Приснилось, что-ли? Или трава крепкая попалась? <br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#10 Fri, 12 Apr 2013 16:31:06 GMT &gt; А как там с правами доступа?<br><br>Фигово. В пределах одной базы разграничение на доступ к записям пользователям сделать нельзя. То есть читать писать могут все кто авторизовался. Выход - создавать на каждого пользователя свою БД и да их может быть много, например если в БД хранить почту пользователей. И делать общие БД с которыми синхронизировать пользовательские БД если нужны общие данные.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89574.html#9 Fri, 12 Apr 2013 14:51:31 GMT &gt; Если сюда забредут юные борцы за юниксвей, они обязательно возмутятся по поводу СУБД со встроенным веб-сервером :)<br><br>А что с юниксвеем-то?<br>