The OpenNET Project / Index page

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

Релиз БД Apache Cassandra 2.0 с поддержкой триггеров и легковесных транзакций

05.09.2013 10:34

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

БД 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).

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

Особенности новой версии:

  • Поддержка легковесных транзакций, позволяющих гарантировать порядок выполнения последовательности операций и обеспечить изоляцию, защищающую от возникновения конфликтов при выполнении конкурирующих запросов;
  • Экспериментальная поддержка триггеров, позволяющих вынести выполнение критичного к производительности кода на сторону сервера, ближе к обрабатываемым данным. Пример задания триггера: "CREATE TRIGGER myTrigger ON myTable USING 'org.apache.cassandra.triggers.InvertedIndex'", где обработчик org.apache.cassandra.triggers.InvertedIndex задаётся в виде Java-класса;
  • Расширение языка CQL3 (Cassandra Query Language) в направлении удобства использовании в data-driven-приложениях (отделение данных от логики из обработки в форме бэкенд/фронтэнд) и упрощения миграции с реляционных СУБД.
    • Добавление в выражение SELECT поддержки псевдонимов (alias), задаваемых при помощи ключевого слова "AS", например, " SELECT name AS user_name FROM users;". В блоках "WHERE" и "ORDER BY" псевдонимы не поддерживаются;
    • Возобновлена поддержка выражения "ALTER TABLE DROP" для таблиц CQL3;
    • В выражениях CREATE для пространств ключей, таблиц и индексов (CREATE KEYSPACE, CREATE TABLE и CREATE INDEX) добавлена поддержка условной операции "IF NOT EXISTS", позволяющей выполнять операцию только при отсутствии объекта с указанным именем;
    • В выражение добавлена поддержка условия "IF NOT EXISTS";
    • В выражение UDPATE добавлена поддержка условия "IF";
    • Поддержка вторичных индексов для столбцов, отмеченных как первичные ключи (PRIMARY KEY);
  • Поддержка библиотеки JEMalloc с реализацией высоко эффективных функций распределения памяти, позволяющих заметно снизить уровень фрагментации памяти;
  • Оптимизация упаковки данных в хранилище, позволяющая сохранить высокую производительность чтения в конфигурациях с большой нагрузкой на запись;
  • Режим горячего повтора операции для избежания возникновения таймаутов при выполнении запроса - если после отправки первого запроса прошло слишком много времени без ответа отправляется дополнительные запросы к другим репликам;
  • Собственная реализация Thrift-сервера, созданная на основе библиотеки LMAX Disruptor, предоставляющей средства обмена сообщениями между нитями с минимальной задержкой.


  1. Главная ссылка к новости (https://blogs.apache.org/found...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37824-cassandra
Ключевые слова: cassandra, apache, couchdb, nosql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.16, Аноним (-), 12:21, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки

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

     
     
  • 2.17, VoDA (ok), 12:26, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки
    > Если так использовать любую нормальную реляционную базу данных, то она запросто сможет
    > "обрабатывать тысячи запросов в секунду".

    А репликацию и автоматическое восстановление после сбоев вы как сделаете?

    PS не считая того, что Cassandra - multi-master, чем далеко не все РСУБД могут похвастаться.

     
     
  • 3.18, Аноним (-), 12:36, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А репликацию и автоматическое восстановление после сбоев вы как сделаете?

    В нормальных промышленных реляционках уже давно сделано.

     
     
  • 4.23, Аноним (-), 13:09, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    назовите их, пожалуйста
     
     
  • 5.25, Аноним (-), 13:29, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Oracle
    Из бесплатного Postgress
     
     
  • 6.27, Фтщтнь (?), 14:43, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Oracle
    > Из бесплатного Postgress

    В Postgres нету встроенного multi-master-а, только stream master-slave. Все остальное реализуется PG-комьюнити и работает далеко не всегда гладко.

     
     
  • 7.34, drake (?), 15:32, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Postres-XC
     
     
  • 8.35, Фтщтнь (?), 16:11, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мы с вами прям как в анекдоте про ту ти ту ту Я грю Нет встроенной мастер-ма... текст свёрнут, показать
     
  • 2.19, MVK (??), 12:45, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если так использовать любую нормальную реляционную базу данных, то она запросто сможет
    > "обрабатывать тысячи запросов в секунду".

    - на массиве в 300 Тб?


     
     
  • 3.20, Аноним (-), 12:51, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И что тут такого?
     
     
  • 4.28, Фтщтнь (?), 14:45, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > И что тут такого?

    SELECT-ы из Postgres и MySQL при больших размерах БД это жопа, я вам скажу, так что как бы ничего, они просто тормозят.

     
     
  • 5.31, Аноним (-), 15:00, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Postgres вполне активно ворочает сотни терабайт информации, на простых то запросах. Oracle тоже этим славен.
    А к чему вы приплели MySQL  вообще не понятно. Сия база данных никогда и не собиралась возится с большими объемами данных. Её вотчина - мелкие простые БД.
     
     
  • 6.33, Фтщтнь (?), 15:10, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Postgres вполне активно ворочает сотни терабайт информации, на простых то запросах. Oracle
    > тоже этим славен.
    > А к чему вы приплели MySQL  вообще не понятно. Сия база
    > данных никогда и не собиралась возится с большими объемами данных. Её
    > вотчина - мелкие простые БД.

    Приплел потому что с точки зрения здравого смысла MySQL вроде как и не годится для чего-то более серьезного, чем сайты-визитки, но в реальности Activision (точнее их сетевое подразделение Daemonware) используют оную в качестве одной из своих подсистем вполне успешно, ну о Facebook я надеюсь вам не стоит говорить. Так что в теории вроде как "фу, брось каку", а на практике совсем-совсем по другому все выходит.

     
     
  • 7.40, agent_007 (ok), 10:17, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > на практике совсем-совсем по другому все выходит.

    на практике так выходит по вполне очевидной причине: на заре проекта им занимались ниасиляторы. в любых проектах, которые изначально делали люди с головой, никакого mysql нет, и не может быть в принципе.

     
  • 5.32, Аноним (-), 15:01, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> И что тут такого?
    > SELECT-ы из Postgres и MySQL при больших размерах БД это жопа, я
    > вам скажу, так что как бы ничего, они просто тормозят.

    Нууу, если Postgres попилить как Кассандру на кучу нод, то будет уже не жопа...

    Правда, инструментов для этого этого нет.  Но если если сделать формат данных аля Кассандра (простые столбцы, никакой поддержки целостности на уровне вторичных ключей и тому подобного), то делать не так уж и много.

    Тогда возникает разумный вопрос - а не проще было просто инструментарий для готовой БД накрутить, чем весь этот огород на Java городить?

     
  • 5.37, Аноним (37), 18:12, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > SELECT-ы из Postgres

    Смотрим план запроса, разбираемся в причинах, оптимизируем запрос и/или строим недостающие индексы. Вообще изучаем матчасть в области повышения производительности реляционных БД и скорости выполнения отдельных запросов.

     
     
  • 6.38, Фтщтнь (?), 22:54, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> SELECT-ы из Postgres
    > Смотрим план запроса, разбираемся в причинах, оптимизируем запрос и/или строим недостающие
    > индексы. Вообще изучаем матчасть в области повышения производительности реляционных БД
    > и скорости выполнения отдельных запросов.

    Да, но зачем, если например в NOSQL это можно сделать без лишних телодвижений?

     

  • 1.21, MaMoHT (?), 12:54, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как они jemalloc в код на Java привернули???
    Они отрубили GC Java oo_O ??
     
     
  • 2.29, Stax (ok), 14:46, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В кассандре off-heap кэш, аллоцируемый через нативные вызовы malloc/free.
     
  • 2.30, ДяДя (?), 14:58, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В Netty его тоже используют. GC только для кучи работает. Есть способы не размещать данные в куче.
     

  • 1.22, Т0т самый ан0ним (?), 13:08, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, транзакции для хранилищ огромных массивов данных, для чего они в принципе?
     
     
  • 2.24, Аноним (-), 13:22, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    чтобы обеспечить ту самую атомарность обновления данных
     

  • 1.36, Фтщтнь (?), 17:25, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чота кажется мне, что скоро Cassandra NOSQL превратится в CassandraSQL.
     
  • 1.39, Dmitry77 (ok), 01:02, 06/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тысячи запросов в секунду.. тут "слегка" приуменьшили.
    вот в этом тесте  например - больше милиона
    http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.htm

    Тест прмечателен тем, что в кластере было до 288 нод. Все ноды поднимались на Амазоне, на 2 часа. Несмотря на такой огромный кластер тестирование стоило всего 500$

    и судя по тесту масштабрование было линейное и миллион в секунду - далеко не предел. посто добавляй серваки.

     
     
  • 2.41, Вонни пух (?), 14:16, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Java это минус
     
     
  • 3.42, Вонни пух (?), 14:22, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Java это минус

    http://hypertable.org/

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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