Чем оно лучше других решений, вроде CouchDB или MongoDB?

в целом быстрее и эффективнее, немного больше похоже на традиционные rdbms. разрабатывалось для facebook, где и используется(как и в твиттерр, дигг, реддит и т.д., и ни единого разрыва). mongodb вообще херня, которая тормозит безбожно и данные теряет, зря ты про него написал.

mongodb я просто не пробовал, но много про него слышал. А вот couchdb пробовал - вполне приятная штука. Нагрузок больших не было, так что в общем-то недостатков не увидел. Зато угробищный реляционный EAV не надо делать.

Делаем ставки, господа линуксоеды

Компания Riptano даёт денег на доработку Apache Cassandra NoSQL и закрывает код, который разработан на её деньги. А что — лицензия APL дозволяет в отличие от GPL. :))

>mongodb я просто не пробовал, но много про него слышал.

у меня он неоднократно падал раньше, наверное сейчас, в 1.0+ с этим получше. а ты знал что в mongo ключ не может содержать, например, точку? даже не смешно как-то.

в остальном, коуч и кассандра разных весовых категорий проекты. кассандра создана для _по-настоящему_ распределенных вещей и позиционируется как замена bigtable.

>а ты знал что в mongo ключ не может содержать, например, точку? даже не смешно как-то.

хм, это правда очень грустно

в остальном, коуч и кассандра разных весовых категорий проекты. кассандра создана для _по-настоящему_ распределенных вещей и позиционируется как замена bigtable.

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

Крутота.

хм

Непонятно просто, чем плох мускуль...

Oracle же.

>Непонятно просто, чем плох мускуль...

Ага, только запаришься ручками шардить и реплицировать когда кластер перерастает десяток-другой машин.

> Непонятно просто, чем плох мускуль...

Вот и школьники подтянулись.

День Apache на моем ЛОРе

>Вот и школьники подтянулись.

Прошу прощения за лень (лень искать/читать) - кассандра подойдёт в качестве «кэша глобальных данных» на локальной ноде (а-ля распределённая транзакционная БД), при этом «отдавая» «локальные данные» отложенно/по мере надобности, а не блокируя транзакцию до окончания глобальной синхронизации?

> даёт денег на доработку и закрывает код, который разработан на её деньги

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

Не подойдет.

>Не подойдет.

чудес на свете не бывает :(

mwahahahahh

http://bash.org.md

>Прошу прощения за лень (лень искать/читать) - кассандра подойдёт в качестве «кэша глобальных данных» на локальной ноде (а-ля распределённая транзакционная БД), при этом «отдавая» «локальные данные» отложенно/по мере надобности, а не блокируя транзакцию до окончания глобальной синхронизации?

memcached, не? Или я не понял вопроса?

да-с, фраза былых времён «бумага всё стерпит» на фоне «самовыражения» некоторых в инете - детский лепет...

>memcached, не? Или я не понял вопроса?

посмотрю, может и оно :)

cassandra умеет multi-master, в отличие от mongodb

>Компания Riptano даёт денег на доработку

Она их не дает она их просит. Не тормози.

>Непонятно просто, чем плох мускуль...

Тем что в случае структуры, не вписывающейся в реляционную схему, надо либо динамически создавать таблицы с костылями (что зло), либо городить «справочники», отчего производительность сильно страдает, а размер БД растёт.

Причем такой случай встречается чаще, чем кажется.

> Непонятно просто, чем плох мускуль...

размерами и тем, что не может динамически добавлять ноды в кластер. и тем более не тянет по 1000 нод данных.

Из всего NoSQL сейчас можно использовать разве что HBase & Cassandra; мы используем первый, потому что лучше дружит с MapReduce в лице Hadoop. Хотя Cassandra тоже очень скоро обещали поддержку + из-за Facebook/Digg/Twitter - сообщество у них быстрее растет.

Еще хороши Neo4J(Graph), Redis(KV). Из документных - все очень сырые, я бы даже JCR какой-нибудь типа JackRabbit взял, чем MongoDB или CouchDB.

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

По мне так ценность этих БД именно в schema-less. Девелоперы CouchDB просрали все полимеры — она у них не ACID. Итого: имеем бд которая масштабируется на over 9000 мифических нод в вакууме, но простейшие приложения для которых ACID необходим сделать просто невозможно.

Жопу с пальцом сравнил, касандра это key-value store, а mongodb с заявками на собственно базу данных. Уж лучше Redis использовать, там хоть зависимости от жабы нет.

> Непонятно просто, чем плох мускуль...

LOL. Он всем плох. Современные инструментарии и средства разработки заточены под модель предметной области, которую невозможно в достаточной мере реализовать через ORM. И не важно мускуль там или другое говно которое было актуально для задач пршлого века.

A highly scalable, eventually consistent

eventually consistent

А в задницу такие storage.

>A highly scalable, eventually consistent > eventually consistent

А в задницу такие storage.

man CAP theorem.

И чо? Надо давать выбор, а блокировки можно и нужно делать тогда, когда они нужны.

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

По мне так ценность этих БД именно в schema-less. Девелоперы CouchDB просрали все полимеры — она у них не ACID.

Все распределенные СУБД на более чем 100 нод не ACID. Кассандра тоже не АСИД. Так что любые NoSQL чаще всего тоже не ACID. и как на них строить софт типа банковского не понятно ;)

> как на них строить софт типа банковского не понятно ;)

Еще более простой пример — при размещении заказа изменить кол-во продуктов.

Впрочем для CouchDB у меня лежит плагин который позволяет сделать эти самые блокировки. И при правильном использовании она становится ACID. Пока работает на одной ноде, но легко можно довести его до состояния когда блокировки будут храниться на одном узле, и другие ноды будут опрашивать этот узел каждый раз когда ситуация требует использования API блокировок. Таким образом если лочить надо — лочишь, и оверхед будет всего в одном дополнительном POST запросе — создание блокировки. После любого POST/PUT/DELETE блокировки в любом случае независимо от результата освобождается, либо по таймауту если ты прослоупочил. Ну а если лочить не надо (например добавить комментарий к посту) то не лочишь. Вот и все дела. Все православно, без патчинга кода couchdb.

> Все распределенные СУБД на более чем 100 нод не ACID.

Это просто игнорирование проблемы. Придумали ей красивое имя Eventual consistency (тоесть когда угодно вывалится совершенно иное состояние системы или другими словами — не важно что ты там записал, в любой момент это может оказаться недействительным), CAP и забили. Блогпосты пишутся с космическими скоростями, бложики пишутся в три строчки кода на javascript. Принцип везде один — тупо репликация. Это как брать две отсоединенные ноды с мускулем и произвольно выбирать коннекты к базе — один реквест на одну ноду, другой на другую, а потом взять и среплицировать друг в друга. Похрен что будет немеряное кол-во конфликтов, уникальности записей не будет (гудбай любая бизнес-слогика). Даже простую регистрацию юзеров сделать невозможно.

Еще пряник, в Couchdb везде UUID в кач-ве ID. Другие сделать невозможно (не ACID же). И мне снятся сайты с урлами вида /page/1067a7be52ec8deb208ce46a82f16ed8d0199bd5 Buld by web for the web. Lol.

Продолжу мысль

Блогпосты пишутся с космическими скоростями, бложики пишутся в три строчки кода на javascript.

пользователи, которые задают «неприятные» вопросы типа «как жеш с таким раскладом софт писать поцаны» в листах рассылки посылаются нахер.

там тоже multi-master нет

>и как на них строить софт типа банковского не понятно ;)

Мля что за тупизм. Сначала пихали мускуль и ораклы туда где они нахер не впираются. Теперь пытаются запихнуть вские кассандры туда где они нахер не впираются.

Когда млять хоть чуть чуть думать начнут перед тем как пользоваться.

>> Все распределенные СУБД на более чем 100 нод не ACID.

Это просто игнорирование проблемы. Придумали ей красивое имя Eventual consistency (тоесть когда угодно вывалится совершенно иное состояние системы или другими словами — не важно что ты там записал, в любой момент это может оказаться недействительным), CAP и забили.

в каком то смысле игнорирование. нет возможности добиться одновременно масштабируемости на 100 мастеров и ACID. Либо ACID и все мастера общаются друг с другом и знаю про последние изменения... а значит эффективно система работает до 4-8 мастеров, затем увеличение кол-ва мастеров только тормозит систему из-за необходимости меж-master подтверждений.

Либо ты действительно скалируешься до огромных чисел master... но мастера развязаны друг с другом, а значит минус Integrity ... вот и получаешь Eventual consistency.

Впрочем для CouchDB у меня лежит плагин который позволяет сделать эти самые блокировки. И при правильном использовании она становится ACID.

тем самым ты создаешь Single Point of Failure во первых и убиваешь скорость во вторых. Зачем такой велосипед когда есть нормальные РСУБД? даже MySQL смотрится лучше сего лисапеда.

Eventual consistency это плата за скалируемость на большое количество нод и развязанность работы master-ов.

> ачем такой велосипед когда есть нормальные РСУБД?

РСУБД говно.

> тем самым ты создаешь Single Point of Failure

Можно подумать прокси сервер перед парком диванчиков не single point.

>> тем самым ты создаешь Single Point of Failure

Можно подумать прокси сервер перед парком диванчиков не single point.

не знаю что ты называешь парком диванчиков. в больших системах типа google/facebook/vkontakte вряд ли стоит ОДИН прокси перед всеми серверами выдающими контент.

Я предложил только один простейший вариант, каким-то образом это в настоящее время решается ведь, РСУБД масштабируются как-то, ноэскуэльщики же просто забивают на насущные проблемы, потому что это типа не COOL!!!.