Чё ещё за crotchDB?

Ничего там не рип, сейчас Cloudant вольет свой форк в основную ветку - считай шардинг. Не надо ляля. Они сами послали нахрен этого Кэца. Он, кстати уже год как тихо свалил, сейчас это лишь объявили.

Если они еще догадаются вернуть транзакций, которые были до 0.9 в виде опции, то получат такую большую базу пользователей, что ни в сказке сказать ни пером описать. Но они всеже не догадаются, я задолбался убеждать.

crotchDB

К логопеду!

А CouchDB - одна из самых популярных документо-ориентированных СУБД.

Сейчас учу эрланг. Отличный, мощный, довольно быстрый ЯП с параллельностью искаропки. А про перевод на сишечку - наверное скорости не хватило.

А то что изначальный разраб поступил так как поступил, то что вы ожидали? Фамилию же все знаем?

А с Couchbase тогда что будет?

довольно быстрый ЯП

А про перевод на сишечку - наверное скорости не хватило.

/0

Ну попу с пальцем сравнивать то не надо. Для компилируемых в байт-код - довольно быстрый. Ваша реплика имела-бы смысл, если-бы они его на джаву переписывали.

Мне плевать что с ней будет. Я буду использовать ту, где впервые появятся транзакции, даже если она будет платной. Пока меня устраивает CouchDB.

всё бóльшую часть ядра на C/C++

Чем их NIF не устраивают? Может о них и речь идет.

[мопед не мой] Erlang для песочницы. Для реальной работы C/C++

Да вы что, издеваетесь? Подряд прямо две темы про одно и то же

Скорее, их всех не устраивает не самая лучшая сопровождаемость кода на эрле.

CouchDB без транзакций нужна только упоротым облачникам, типичный пример «СУБД» с профорсеной преждевременной оптимизацией. Мне не нужна БД которая масштабируется до усрачки, мне нужна БД с которой просто работать. Без транзакций 99% приложений на ней сделать невозможно. От SQL ада пришли к Eventual Consistency (мягкий термин, означающий ее отсутствие) аду.

Так что они обе будут жить, но какбы нужны будут мало кому.

Комментарии писать надо.

Чем CouchDB лучше MongoDB?

Не заметил того треда. Если модераторам угодно, пусть мой выпилят.

Тем что ей не надо всю базу в оперативке хранить чтобы нормально работать.

Erlang всё ещё отличный язык, но если вам нужна максимальная производительность и контроль на низком уровне, то вряд ли что-то может сравниться с C.

Да там не в одних комментариях дело.

Много чего в эрле нет (строк хороших, например), синтаксис неудобен, типов доступных мало. Читать дебажный вывод обычно пытка - как раз из-за того, как сложные структуры ложатся на эрловскую систему типов.

Все что ты перечислил им не нужно, а в дебажные выводы в новом релизе эрланга добавили номера строк.

Ну, это так себе аргумент. Для эрла можно писать ноды на C/C++/Java и чем угодно. И не только ноды.

Сомнительно, что дело только в одной скорости. Очень странно. Скорее всего, вопрос с сопровождаемостью тоже имел место быть.

Например, лицензией. И нормальным map/reduce с JS-ом. И тем, что REST.

У них есть btree рабочий, все остальное там ерунда. Это JSON-store, а в нем всего 3 типа.

А еще скорее то, что их клиенты блогодеятели боятся erlang'a

Вообще, можно сказать иначе. На эрле очень сложно писать _быстрый_ код (поскольку MQ, поскольку иммутабельность, поскольку нет шаред-памяти). Но очень легко писать _надежный_. И довольно сложно писать _понятый и сопровождаемый_.

Про первые два пункта, по идее, все и в начале разработки должно быть ясно, а вот когда утыкаются в последний - вспоминают про первый, оправдывая миграцию на другую технологию.

Впрочем это так, скромное мнение.

И это тоже. К слову, бим относительно жруч. Точнее, минимальные требования у него, все же, куда выше нативного кода.

Очевидно, что no-sql не нужен

mongodb в памяти хранит только индексы если что :)

Еще бы добавили лимит на память, а то говорят что MongoDB очень любит съедать всю оперативку. Пока что только это останавливает меня от его использования.

Вобщем, erlang оказался не-труЪ. Ч.т.д.

Это тот чувак который написал пост про эрланг в котором сказал что язык говно потому что ифы не как в С, нехватает фигурных скобок и деструктивного присваивания нет?:)

ну если на сервере 48 гигов памяти но можно не беспокоится :)

Мне, например, не очевидно.

Почему это он не нужен? Ему уже есть альтернатива?

Потому что в 99% случаев ноускуль нужен только неосиляторам скуля. Для оставшегося 1% хватило бы одного допиленного решения, а не стопицот недопиленных поделок: коуч, монго, кассандра, и прочая, и прочая.

Коуч, монго, кассандра - все для разных целей.

А носкуль для случаев, когда скуль не нужен или не уместен. К оисляторству или неосиляторству скуля это никак не относится.

Потому что в 99% случаев ноускуль нужен только неосиляторам скуля.

То-то для вариабельных атрибутов жуткие костыли сооружают (см. решение френдфида). Эмулируют nosql средствами реляционок.

Это и есть тот самый один процент случаев. Хотя зачастую Variable атрибуты произрастают из врожденной тупизны архитектора.

А теперь список этих случаев в студию. Для чего лично ты используешь коуч?

wolfy уже опередил.

зачастую Variable атрибуты произрастают из врожденной тупизны

Ой ли? Скажи еще, что они вообще не нужны.

Да чо ты с ним споришь, он наверное недавно был на курсах по СУБД.

s/СУБД/РСУБД

Нужны, почему же. Вот, например, для каталогов вроде Я.Маркета - нужны. А вы для чего их используете?

Повторюсь: для чего лично ты используешь коучдб?

Ага, 20 лет, живу с мамой...

Лично я его и не использую :) Ставил когда-то посмотреть, что за зверь, да не пересекся он с моим юзкейсом :)

Очевидно, что no-sql не нужен

Но ведь и SQL тоже не нужен:
http://ru.wikipedia.org/wiki/D_(определение_информационного_языка)

Инторнет-могозын, лол.

Не магазин - каталог. Чего угодно, с тысячами различных характеристик у разных групп. Без вариабельных атрибутов сложно. А ваши юзкейсы можно?

В нашем случае - именно каталог инторнет-гамазина же.