The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлена БД Apache Cassandra 1.2

03.01.2013 17:55

После десяти месяцев разработки увидел свет релиз распределённой БД Apache Cassandra 1.2.0, относящейся к классу noSQL-систем и рассчитанной на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, хранимых в форме ассоциативного массива (хэша). Код проекта написан на языке Java и распространяется в рамках лицензии Apache 2.0.

Изначально проект был разработан в недрах компании Facebook и в 2009 году передан под покровительство фонда Apache. Промышленные решения на базе Cassandra, способные обрабатывать тысячи запросов в секунду, развернуты для обеспечения сервисов таких компаний, как Adobe, Cisco, IBM, Disney, eBay, Netflix, Rackspace, Reddit и Twitter. Наиболее крупный кластер серверов, обслуживающих единую БД Cassandra насчитывает более 400 машин и используется для хранения более 300 Тб данных.

БД Cassandra объединяет в себе полностью распределённую hash-систему Dynamo, обеспечивающую практически линейную масштабируемость при увеличении объема данных. Cassandra использует модель хранения данных на базе семейства столбцов (ColumnFamily), отличающуюся от систем подобных memcachedb, которые хранят данные только в связке ключ/значение, возможностью организовать хранение хэшей с несколькими уровнями вложенности.

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

Для упрощения взаимодействия с БД поддерживается язык формирования структурированных запросов CQL (Cassandra Query Language), на первый взгляд напоминающий SQL, но существенно урезанный по функциональности. Например, можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки. Добавление и обновление данных производится через единое выражение UPDATE, операция INSERT отсутствует (если записи нет, при выполнении UPDATE она создаётся). Из возможностей можно отметить поддержку пространств имён и семейств столбцов, создание индексов через выражение "CREATE INDEX". Драйверы с поддержкой CQL подготовлены для языков Python, Java (JDBC/DBAPI2) и JavaScript (Node.js).

Из новшеств, представленных в версии 1.2, можно отметить:

  • Поддержка виртуальных узлов (vnode), изменяющих подход к привязке диапазонов данных к узлу кластера за счёт возможности представления одного физического узла как набора виртуальных узлов. Если раньше для каждого узла определялся только один диапазон хранимых данных, то сейчас к узлу могут быть привязаны несколько диапазонов. Хранения на узле независимой группы мелких диапазон, вместо одного крупного, позволяет быстрее заполнять узлы кластера, проще выводить узлы из эксплуатации, проводить восстановление и ребалансировку;


  • Переход на финальную версию языка запросов CQL 3.0 (Cassandra Query Language), которая теперь используется по умолчанию. Среди новшеств CQL 3.0 можно выделить возможность использования значений нескольких столбцов в качестве первичного ключа, поддержку конструкций управления доступом (GRANT, REVOKE, LIST PERMISSIONS), расширенные функции маппинга данных;
  • Поддержка выполнения пакетных операций (BATCH, аналог SQL ACID транзакций) в атомарном режиме, что позволяет гарантировать целостность крупных транзакций и обеспечить откат внесённых в рамках транзакции изменений в случае сбоя. Следует иметь в виду, что атомарные BATCH-операции выполняются примерно на 30% медленнее, поэтому для операций, требующих высокой скорости, следует использовать конструкцию без ведения лога изменений - "BEGIN UNLOGGED BATCH";
  • Поддержка трассировки запросов, что позволяет контролировать как именно запросы выполняются в БД. Для включения трассировки следует использовать команду "tracing on", после чего для каждого запроса будет выведен подробный план его выполнения;
  • Серия оптимизаций производительности: собственное управление размещением внутренних структур в памяти вне кучи JVM, увеличение параллелизма сохранения изменений, асинхронная доставка данных в процессе репликации, новый метод партицирования Murmur3Partitioner, увеличение производительности индексов столбцов, сериализация коллекций в бинарном виде (вместо JSON) и т.д.
  • Новый бинарный протокол для CQL3, поддерживающий асинхронные соединения, подписку на уведомления со стороны сервера и передачу данных в сжатом виде;
  • Расширенные опции конфигурации: отдельные варианты опции rpc_timeout_in_ms для чтения, записи, единичных и групповых операций; опция client_encryption_options для управления шифрованием; опция cross_node_timeout для защиты от перегрузки;
  • Поддержка обработки сбоя отдельного диска без остановки всего узла.


  1. Главная ссылка к новости (https://blogs.apache.org/found...)
  2. OpenNews: Для MariaDB/MySQL представлено хранилище Cassandra. Обновление MySQL 5.1.66, 5.5.28 и 5.6.7
  3. OpenNews: Релиз БД Redis 2.6
  4. OpenNews: Релиз БД Couchbase Server 2.0, сочетающей возможности CouchDB, memcached и Membase
  5. OpenNews: Компания Oracle представила открытую БД Oracle NoSQL Database 2.0
  6. OpenNews: Новая версия NoSQL базы данных OrientDB 1.3
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/35749-cassandra
Ключевые слова: cassandra, nosql, database
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (20) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Guest (??), 18:49, 03/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а зачем нужен урезанный SQL (=CQL) без OrderBy?
     
     
  • 2.2, Guest (??), 18:51, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    P.S.
    ORDER BY конечно же :)
     
     
  • 3.4, Sw00p aka Jerom (?), 20:22, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а зачем он нужен если это nosql - никаких столбцов и таблиц, только ключ/значение
     
  • 2.3, Troll (?), 20:20, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    гость, точнее - бобер - выдыхай
     
     
  • 3.5, Аноним (-), 20:46, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя БД до примерно 40 Тб (ну как у меня), то тебе вполне достаточно MySQL, так что не заморачивайся.
     
     
  • 4.13, Аноним (-), 12:00, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если у тебя БД до примерно 40 Тб (ну как у меня),
    > то тебе вполне достаточно MySQL, так что не заморачивайся.

    Ты хочешь сказать, что паршивый мускуль способен терабайты обмолачивать с приемлемой задержкой???? Трындишь, косой. Этот шибздик неспособен сколько-нибудь значимые объемы даже хранить, не то, что вытаскивать. Иначе мордокнига не держала бы 7000 с чем-то инстансов мускуля в бакэнде.

     
     
  • 5.20, YetAnotherOnanym (ok), 23:13, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ППКС, мускул - для школьных поделок. Шардинг спасает, но лучше сразу закладывать что-то более приспособленное к росту объёмов и нагрузок.
     
  • 2.7, rshadow (ok), 20:55, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос в другом: зачем нужена БД на яве?
     
     
  • 3.9, Sinot (ok), 21:01, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >и рассчитанной на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных

    Как-то так. То есть не для домашних проектов.

     
  • 3.11, Sw00p aka Jerom (?), 01:40, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    гыгыгыгыгыг а причём тут ява ? - она же распределённая, если ява не производительная на сингл сервере это же не означает, что в кластере всё будет тормозить. и ваще измерение производительности в кластере не сводится измерением на одной ноде, так что я думаю тут смысла нет говорить почему ява, а не С++
     
     
  • 4.14, Аноним (-), 12:00, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > гыгыгыгыгыг а причём тут ява ? - она же распределённая, если ява
    > не производительная на сингл сервере это же не означает, что в
    > кластере всё будет тормозить. и ваще измерение производительности в кластере не
    > сводится измерением на одной ноде, так что я думаю тут смысла
    > нет говорить почему ява, а не С++

    Жаба? В моем Уютненьком бакэнде? Нет пути!!!

     
     
  • 5.19, Sw00p aka Jerom (?), 19:51, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    хммм и твиттер отказался от рельсов в пользу жабы - зачем ?
     

  • 1.6, Аноним (-), 20:48, 03/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Поддержка обработки сбоя отдельного диска без остановки всего узла.

    Что за чушь? Причем тут СУБД? Если у тебя аппаратный RAID, например RAID 6 с горячей заменой, то отказоустойчивость обеспечивается не самой СУБД и даже не операционной системой, которая видит только виртуальный диск, показываемый ей контроллером.

     
     
  • 2.8, pkdr (?), 21:00, 03/01/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В кассандре есть уже свой механизм дублирования данных, поэтому в большинстве задач, где она применяется, использовать RAID, тем более аппаратный, будет слишком неэффективно и дорого. Для кассандры как раз оптимально использовать недорогие HDD с дублированием данных по нескольким узлам. Так вот теперь если один из таких дисков помрёт, узел где это произошло, и кассандра в целом продолжат работу без всяких проблем.
     
     
  • 3.12, Аноним (-), 11:20, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40 Тб из 48 Тб реальных (24 диска по 2 Тб) при допустимости поломки любых двух дисков без потери данных.
     
     
  • 4.15, Аноним (-), 12:02, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
    > пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
    > Тб из 48 Тб реальных (24 диска по 2 Тб) при
    > допустимости поломки любых двух дисков без потери данных.

    Эффективность сроду не обходилась дешево. И, BTW, анон, самое эффективное и надежное решение (это не я говорю, а вендоры считают - и обоснованно) - это RAID-10. Опачки?

     
     
  • 5.16, Аноним (-), 12:04, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
    >> пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
    >> Тб из 48 Тб реальных (24 диска по 2 Тб) при
    >> допустимости поломки любых двух дисков без потери данных.
    > Эффективность сроду не обходилась дешево. И, BTW, анон, самое эффективное и надежное
    > решение (это не я говорю, а вендоры считают - и обоснованно)
    > - это RAID-10. Опачки?

    Кстати, ZFS mirror позволяет выйти из строя _половине_ дисков массива без заметного снижения перфоманса. Сам лично проверял. Так-то! Всегда ваш, К.О.

    PS. И, да, массив имел в несколько раз меньшую емкость, чем сумма исходных шпинделей. Но когда терабайт стоит как лопата дерьма, сие не принципиально, верно?

     
  • 5.17, Аноним (-), 13:45, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Привет, тезка! Ведроны считают как бы подороже впарить. Это же очевидно. А об эффективности RAID - посмотри хотя бы Вики. Чтобы чепуху о RAID 10 не писать.
     
  • 4.18, VoDA (ok), 15:25, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
    > пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
    > Тб из 48 Тб реальных (24 диска по 2 Тб) при
    > допустимости поломки любых двух дисков без потери данных.

    Кассандра интересна с того момента, как данные физически не влезают в один сервер. А поднимать целое хранилище только для хранения ОДНОЙ БД + сервера, которые умеют этой БД управлять - обходятся намного дороже, чем Кассандра.

    Плюс переход от ACID к BASE позволяет множеству мастеров работать в режиме записи данных. Что опять же интересно только на больших объемах.

    Таким образом тот объем данных, что влезает в аппаратный RAID, можно гонять и на RAID. "Эффективность и дешевизна" Cassandra проявится на тех, объемам и нагрузках, которые не влезают ни в один адекватный сервер.

     
  • 2.21, YetAnotherOnanym (ok), 23:17, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если у тебя аппаратный RAID

    ... то в результате прорыва трубы или визита судебных приставов Вы теряете сразу весь RAID-массив :b

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру