LINUX.ORG.RU

Проект Apache Cassandra NoSQL получает коммерческую поддержку

 , ,


0

0

Компания Riptano (эксперт в области поддержки, обучения и предоставления профессиональных услуг, связанных с Apache Cassandra) начала осуществление коммерческой поддержки Apache Cassandra NoSQL, для повышения востребованности проекта в enterprise-сегменте рынка.

Несмотря на свою молодость, компания имеет самое прямое отношение к проекту, поскольку основана, в том числе, председателем проекта Джонатаном Эллисом (Jonathan Ellis). Помимо Riptano, привлечена также крупная хостинговая компания Rackspace, чьими бывшими сотрудниками являются и Эллис, и еще один соучредитель Riptano Мэтт Пфайль (Matt Pfeil).

СУБД с открытым исходным кодом Apache Cassandra NoSQL уже используется в таких сервисах, как Twitter, Digg, Facebook и других крупных онлайн-проектах.

>>> Источник (англ.)



Проверено: isden ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

volh ★★ ()
Ответ на: комментарий от volh

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

anonymous ()

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

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

iZEN ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

volh ★★ ()
Ответ на: комментарий от volh

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

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

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

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

anonymous ()

хм

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

anonymous ()
Ответ на: хм от anonymous

Re: хм

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

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

anonymous ()
Ответ на: хм от anonymous

Re: хм

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

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

anunymuos ()

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

irq ()
Ответ на: Re: хм от anunymuos

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

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

yyk ★★★★★ ()
Ответ на: Делаем ставки, господа линуксоеды от iZEN

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от anunymuos

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

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

yyk ★★★★★ ()
Ответ на: комментарий от yyk

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

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

YogSagot ★★ ()
Ответ на: комментарий от anonymous

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

yyk ★★★★★ ()
Ответ на: комментарий от YogSagot

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

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

yyk ★★★★★ ()
Ответ на: хм от anonymous

Re: хм

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

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

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

anonymous ()
Ответ на: хм от anonymous

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

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

VoDA ★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от maxcom

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

anonymous ()
Ответ на: хм от anonymous

Re: хм

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

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

anonymous ()

A highly scalable, eventually consistent

eventually consistent

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

anonymous ()
Ответ на: комментарий от anonymous

>A highly scalable, eventually consistent > eventually consistent

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

man CAP theorem.

volh ★★ ()
Ответ на: комментарий от volh

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

VoDA ★★ ()
Ответ на: комментарий от VoDA

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

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

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

anonymous ()
Ответ на: комментарий от VoDA

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от VoDA

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

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

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

r ★★★★★ ()
Ответ на: комментарий от anonymous

>> Все распределенные СУБД на более чем 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-ов.

VoDA ★★ ()
Ответ на: комментарий от VoDA

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

РСУБД говно.

anonymous ()
Ответ на: комментарий от VoDA

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

VoDA ★★ ()
Ответ на: комментарий от VoDA

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.