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

«Cassandra может быть ключевым компонентом облачных и других приложений, имеющих дело с крупными массивами данных и большими объемами запросов, — полагает Джонатан Эллис, вице-президент по проекту Apache Cassandra и сооснователь компании Riptano, оказывающей профессиональные услуги поддержки распределенной СУБД. — В наибольшей степени преимущества Cassandra проявятся при использовании в основе крупных сайтов, характеризующихся высокими темпами роста посещаемости».

Cassandra используется в ряде популярных веб-сервисов, таких как Digg, Twitter и Facebook (компания Facebook является одновременно разработчиком технологии, положенной в основу СУБД). Как утверждают авторы проекта, самый крупный на сегодня кластер с Cassandra состоит более чем из 400 серверов.

В предыдущих версиях СУБД ограничения на количество столбцов в строке не было, однако предельный размер каждой строки составлял около 2 Гбайт. В Cassandra 0.7 это ограничение устранено.

Благодаря поддержке больших строк системы пользователи Cassandra смогут «на лету» создавать практически неограниченное количество столбцов, утверждает Эллис.

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

В числе других новых особенностей Cassandra 0.7 — поддержка вторичных индексов, благодаря которой обеспечивается простой способ опроса данных на локальных машинах, и возможность вносить изменения в схему базы данных без перезапуска всего кластера.

Cassandra относится к классу нереляционных СУБД. Такие системы обеспечивают возможность быстрого и простого сохранения очень больших объемов данных и, как правило, работают в кластеризованной среде.

Исходный вариант Cassandra был разработан программистами Facebook для используемого в социальной сети механизма поиска по входящим сообщениям. Ввиду потребности в управлении большими объемами данных в Facebook решили воспользоваться архитектурой Google Big Table, поскольку на ее основе можно было создать строчно-столбцовую СУБД, способную работать на множестве узлов.

Недостаток механизма Big Table состоял в том, что эта архитектура опирается на мастер-узел, объяснил Эллис в интервью Службе новостей IDG на конференции ApacheCon в ноябре прошлого года. Вся работа Big Table зависит от единственного узла, который координирует операции чтения и записи, выполняемые всеми остальными узлами. Если он дает сбой, вся система становится неработоспособной, указал Эллис.

Поэтому в основе Cassandra используется гибрид из Big Table и разработанной в Amazon архитектуры Dynamo. Благодаря последней удалось устранить уязвимое звено в виде головного узла, обеспечив при этом простоту масштабирования системы. Архитектура Dynamo не предполагает наличия головного узла. Любой узел может принимать данные для всей системы и отвечать на запросы. Данные при этом тиражируются между множеством хостов.

Cassandra — не единственная кластеризованная СУБД, созданная с использованием идей Big Table и Dynamo. Начинающая компания Cloudant на основе аналогичных технологий разработала кластеризованную версию СУБД с открытым кодом CouchDB — BigCouch. Совсем недавно компания объявила, что количество пользователей размещаемой версии BigCouch достигло 2,5 тыс.