Организация Apache Software Foundation представила (https://blogs.apache.org/foundation/entry/the_apache_softwar...) релиз распределённой БД Apache Cassandra 1.1.0 (http://cassandra.apache.org/), относящейся к классу noSQL-систем и рассчитанной на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша. Изначально проект был разработан в недрах Facebook и в 2009 году передан под покровительство фонда Apache. Промышленные решения на базе Cassandra развернуты для обеспечения сервисов таких компаний, как Adobe, Cisco, IBM, Rackspace и Twitter. Наиболее крупный кластер серверов, обслуживающих единую БД Cassandra, размер данных в которой превышает 300 Тб, насчитывает более 400 машин.
БД Cassandra написана на языке Java и объединяет в себе полностью распределённую hash-систему Dynamo, обеспечивающую практически линейную масштабируемость при увеличении объема данных. Cassandra использует модель хранения данных на базе семейства столбцов (ColumnFamily), отличающуюся от систем подобных memcachedb, которые хранят данные только в связке ключ/значение, возможностью организовать хранение хэшей с несколькими уровнями вложенности. Cassandra относится к категории хранилищ повышенно устойчивых к сбоям: помещаемые в БД данные автоматически реплицируются на несколько узлов распределённой сети или даже равномерно распределяются по нескольким дата-центрам. При сбое узла, его функции на лету подхватываются другими узлами. Добавление новых узлов в кластер и обновление версии Cassandra производится на лету, без дополнительного ручного вмешательства и переконфигурирования других узлов.
Для упрощения взаимодействия с БД поддерживается язык формирования структурированных запросов CQL (http://crlog.info/2011/03/29/cassandra-query-language-aka-cq.../) (Cassandra Query Language), на первый взгляд напоминающий SQL, но существенно урезанный по функциональности. Например, можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки. Добавление и обновление данных производится через единое выражение UPDATE, операция INSERT отсутствует (если записи нет, при выполнении UPDATE она создаётся). Из возможностей можно отметить поддержку пространств имён и семейств столбцов, создание индексов через выражение "CREATE INDEX". Драйверы с поддержкой CQL подготовлены для языков Python (http://www.apache.org/dist/cassandra/drivers), Java (https://github.com/racker/node-cassandra-client) (JDBC/DBAPI2) и JavaScript (https://github.com/racker/node-cassandra-client) (Node.js).
Улучшения (http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blo...), представленные (http://www.mail-archive.com/user%40cassandra.apache.org...) в новой версии:- Переработан (http://www.datastax.com/dev/blog/the-schema-management-renai...) процесс обновления схемы данных и реализована поддержка автоматического разрешения конфликтов при возникновении одновременных обновлений;
- Значительно расширен язык формирования запросов CQL (Cassandra Query Language), осуществлён переход на обратно не совместимую версию CQL 3.0 (http://www.datastax.com/dev/blog/whats-new-in-cql-3-0), но оставлена поддержка и старой версии CQL 2.0, которая пока используется по умолчанию (для включения CQL 3.0 следует использовать опцию "--cql3"). Основные изменения в CQL 3.0 касаются поддержки использования составных ключей для упрощения денормализации;- Изоляция (http://www.datastax.com/dev/blog/row-level-isolation) выполнения обновлений на уровне строк. Многостолбцовые обновления теперь выполняются не только атомарно, но и изолированно на уровне отдельных строк, т.е. теперь пользователь увидит сразу все изменения, а не как раньше, имеет шанс прочитать смесь старых и новых данных;
- Реализованы (http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-1-...) средства для гибкого управления размещением данных по директориям, которые позволяют вынести хранение семейства столбцов (ColumnFamily) на отдельных раздел, например, на более быстрый SSD-накопитель;- Упрощена конфигурация кэшей столбцов и ключей, которые отныне являются глобальными .
URL: https://blogs.apache.org/foundation/entry/the_apache_softwar...
Новость: http://www.opennet.me/opennews/art.shtml?num=33676
если нет сортировки, то зачем там индексы?
Мо быть, для поиска??
самое сложное в таких системах это индексы
фигачить туда сюда по хешу много ума не надо
не удивлюсь что с индексами там всё херово и на большых обьёмах просто не работает
Точно работает на 300 миллионов записей ( ключей ) .
В среднем около 6 колонок , размер записи около 3к .
<С очень скиптическим видом>Так вот почему Facebook начинает тормозить если туда больше 10-ти пользователей одновременно зайдет</С очень скиптическим видом>
Кому-то надо быстро выходить из фейсбука, выключать компьютер со своим тормозным интернетом и учить русский язык.
Мечтаете обанкротить фейсбук и озолотить преподавателей русского? )))))
> Мечтаете обанкротить фейсбук и озолотить преподавателей русского? )))))Давно пора :))) А то сейчас тенденция прямо обратная, к сожалению.
Индексы в привычном виде в Cassandra только на вторичные атрибуты(на value), и то есть ограничение, что они работают только в пределах одного узла.
>на первый взгляд напоминающий SQL, но существенно урезанный по функциональностизачем тогда его используют?
Видимо для того, чтобы упростить вход в разработку на кассандре уже знающим SQL. Или есть какие-то другие варианты?
> Видимо для того, чтобы упростить вход в разработку на кассандре уже знающим
> SQL. Или есть какие-то другие варианты?нет, я имел ввиду а почему нельзя было использовать SQL, если CQL все равно хуже?
Потому что нет JOIN-ов, которые классика SQL. для джоинов потребуется создание специальных серверов и мержинг различных потоков данных со всего хранилища. Что суть накладно, да и не особо адекватно на тех объемах для которых создан subj.
> Потому что нет JOIN-ов, которые классика SQL. для джоинов потребуется создание специальных
> серверов и мержинг различных потоков данных со всего хранилища. Что суть
> накладно, да и не особо адекватно на тех объемах для которых
> создан subj.То бишь первые версии MySQL были NoSQL на самом деле? )))
Или не только первые? (:TrollFace:)
> То бишь первые версии MySQL были NoSQL на самом деле? )))
> Или не только первые? (:TrollFace:)Первые версии были багодромом. Вообще почитай про ANSI SQL, прочисть чакры.
> Потому что нет JOIN-ов, которые классика SQL.Вы о чем вообще? Какие нафиг джойны в «ColumnFamily» СУБД?
Рекомендую прочитать пост к которому и относится мой ответ.
и почему меня кто то уже минусить начал, я же не тролю, мне просто интересно
Это не хабр, тут всем пофиг на плюсики/минусы, и карма не играет никакой роли. Так что не парьтесь :)
> нет, я имел ввиду а почему нельзя было использовать SQL, если CQL все равно хуже?Странный вопрос. SQL — это язык общения с реляционными БД. Cassandra таковой не является. Она как бы «из другой оперы». Да и собственно внешний вид языка запросов, по-моему, здесь не особо важен.
SQL-компилер весч очень прожорливая и уничтожающая простоту и скорость. В данном случае нафиг не нужна.
> SQL-компилер весч очень прожорливая и уничтожающая простоту и скорость. В данном случае
> нафиг не нужна.Компилер даже SQL на распределенных системах вещь копеечная. Основная проблема в том, что сейчас система работает подобно ndb нодам MySQL. Для поддержки SQL придется сделать аналог sql нод MySQL (что не сложно) куда нужно сливать все данные выборки, и где уже производить JOIN. Сама необходимость слить все данные запроса в одну ноду убивает основных бонусы распределенных хранилищ.
300 машин (= серверов?) и 400 Тб??? Т.е. по 1,3 Тб на сервер? Что-то фуфловенько как-то...
Не забывайте про то, что данные ещё и дублируются на нескольких нодах для отказоустойчивости.
...и индексы могут быть в несколько раз больше данных.