После десяти месяцев разработки увидел свет (http://www.mail-archive.com/user@cassandra.apache.org/m...) релиз распределённой БД Apache Cassandra 1.2.0 (http://cassandra.apache.org/), относящейся к классу 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 (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).Из новшеств (https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=bl...), представленных в версии 1.2, можно отметить:
- Поддержка виртуальных узлов (http://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2) (vnode), изменяющих подход к привязке диапазонов данных к узлу кластера за счёт возможности представления одного физического узла как набора виртуальных узлов. Если раньше для каждого узла определялся только один диапазон хранимых данных, то сейчас к узлу могут быть привязаны несколько диапазонов. Хранения на узле независимой группы мелких диапазон, вместо одного крупного, позволяет быстрее заполнять узлы кластера, проще выводить узлы из эксплуатации, проводить восстановление и ребалансировку;
<center><a href="http://www.datastax.com/wp-content/uploads/2012/10/VNodes2.p... src="https://www.opennet.ru/opennews/pics_base/0_1357221295.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
<center><a href="http://www.datastax.com/wp-content/uploads/2012/10/VNodes3.p... src="https://www.opennet.ru/opennews/pics_base/0_1357221030.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
- Переход на финальную версию языка запросов CQL 3.0 (http://www.datastax.com/dev/blog/whats-new-in-cql-3-0) (Cassandra Query Language), которая теперь используется по умолчанию. Среди новшеств CQL 3.0 можно выделить возможность использования значений нескольких столбцов в качестве первичного ключа, поддержку конструкций управления доступом (GRANT, REVOKE, LIST PERMISSIONS), расширенные функции маппинга данных;- Поддержка (http://www.datastax.com/dev/blog/atomic-batches-in-cassandra...) выполнения пакетных операций (BATCH (http://www.datastax.com/docs/1.1/references/cql/BATCH), аналог SQL ACID транзакций) в атомарном режиме, что позволяет гарантировать целостность крупных транзакций и обеспечить откат внесённых в рамках транзакции изменений в случае сбоя. Следует иметь в виду, что атомарные BATCH-операции выполняются примерно но 30% медленнее, поэтому для операций, требующих высокой скорости, следует использовать конструкцию без ведения лога изменений - "BEGIN UNLOGGED BATCH";
- Поддержка (http://www.datastax.com/dev/blog/tracing-in-cassandra-1-2) трассировки запросов, что позволяет контролировать как именно запросы выполняются в БД. Для включения рассировки следует использовать команду "tracing on", после чего для каждого запроса будет выведен подробный план его выполнения;
- Серия (http://www.datastax.com/dev/blog/performance-improvements-in...) оптимизаций производительности: собственное управление размещением внутренних структур в памяти вне кучи JVM, увеличение параллелизма сохранения изменений, асинхронная доставка данных в процессе репликации, новый метод партицирования Murmur3Partitioner, увеличение производительности индексов столбцов, сериализация коллекций в бинарном виде (вместо JSON) и т.д.
- Новый бинарный протокол (http://www.datastax.com/dev/blog/binary-protocol) для CQL3, поддерживающий асинхронные соединения, подписку на уведомления со стороны сервера и передачу данных в сжатом виде;
- Расширенные (http://www.datastax.com/dev/blog/configuration-changes-in-ca...) опции конфигурации: отдельные варианты опции rpc_timeout_in_ms для чтения, записи, единичных и групповых операций; опция client_encryption_options для управления шифрованием; опция cross_node_timeout для защиты от перегрузки;
- Поддержка (http://www.datastax.com/dev/blog/handling-disk-failures-in-c...) обработки сбоя отдельного диска без остановки всего узла.
URL: https://blogs.apache.org/foundation/entry/the_apache_softwar...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35749
а зачем нужен урезанный SQL (=CQL) без OrderBy?
P.S.
ORDER BY конечно же :)
а зачем он нужен если это nosql - никаких столбцов и таблиц, только ключ/значение
гость, точнее - бобер - выдыхай
Если у тебя БД до примерно 40 Тб (ну как у меня), то тебе вполне достаточно MySQL, так что не заморачивайся.
> Если у тебя БД до примерно 40 Тб (ну как у меня),
> то тебе вполне достаточно MySQL, так что не заморачивайся.Ты хочешь сказать, что паршивый мускуль способен терабайты обмолачивать с приемлемой задержкой???? Трындишь, косой. Этот шибздик неспособен сколько-нибудь значимые объемы даже хранить, не то, что вытаскивать. Иначе мордокнига не держала бы 7000 с чем-то инстансов мускуля в бакэнде.
ППКС, мускул - для школьных поделок. Шардинг спасает, но лучше сразу закладывать что-то более приспособленное к росту объёмов и нагрузок.
Вопрос в другом: зачем нужена БД на яве?
>и рассчитанной на создание высокомасштабируемых и надёжных хранилищ огромных массивов данныхКак-то так. То есть не для домашних проектов.
гыгыгыгыгыг а причём тут ява ? - она же распределённая, если ява не производительная на сингл сервере это же не означает, что в кластере всё будет тормозить. и ваще измерение производительности в кластере не сводится измерением на одной ноде, так что я думаю тут смысла нет говорить почему ява, а не С++
> гыгыгыгыгыг а причём тут ява ? - она же распределённая, если ява
> не производительная на сингл сервере это же не означает, что в
> кластере всё будет тормозить. и ваще измерение производительности в кластере не
> сводится измерением на одной ноде, так что я думаю тут смысла
> нет говорить почему ява, а не С++Жаба? В моем Уютненьком бакэнде? Нет пути!!!
хммм и твиттер отказался от рельсов в пользу жабы - зачем ?
> Поддержка обработки сбоя отдельного диска без остановки всего узла.Что за чушь? Причем тут СУБД? Если у тебя аппаратный RAID, например RAID 6 с горячей заменой, то отказоустойчивость обеспечивается не самой СУБД и даже не операционной системой, которая видит только виртуальный диск, показываемый ей контроллером.
В кассандре есть уже свой механизм дублирования данных, поэтому в большинстве задач, где она применяется, использовать RAID, тем более аппаратный, будет слишком неэффективно и дорого. Для кассандры как раз оптимально использовать недорогие HDD с дублированием данных по нескольким узлам. Так вот теперь если один из таких дисков помрёт, узел где это произошло, и кассандра в целом продолжат работу без всяких проблем.
Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40 Тб из 48 Тб реальных (24 диска по 2 Тб) при допустимости поломки любых двух дисков без потери данных.
> Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
> пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
> Тб из 48 Тб реальных (24 диска по 2 Тб) при
> допустимости поломки любых двух дисков без потери данных.Эффективность сроду не обходилась дешево. И, BTW, анон, самое эффективное и надежное решение (это не я говорю, а вендоры считают - и обоснованно) - это RAID-10. Опачки?
>> Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
>> пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
>> Тб из 48 Тб реальных (24 диска по 2 Тб) при
>> допустимости поломки любых двух дисков без потери данных.
> Эффективность сроду не обходилась дешево. И, BTW, анон, самое эффективное и надежное
> решение (это не я говорю, а вендоры считают - и обоснованно)
> - это RAID-10. Опачки?Кстати, ZFS mirror позволяет выйти из строя _половине_ дисков массива без заметного снижения перфоманса. Сам лично проверял. Так-то! Всегда ваш, К.О.
PS. И, да, массив имел в несколько раз меньшую емкость, чем сумма исходных шпинделей. Но когда терабайт стоит как лопата дерьма, сие не принципиально, верно?
Привет, тезка! Ведроны считают как бы подороже впарить. Это же очевидно. А об эффективности RAID - посмотри хотя бы Вики. Чтобы чепуху о RAID 10 не писать.
> Дублирования? Где же тут эффективность и дешевизна, если вам нужно удвоенное дисковое
> пространство? Тот же аппапратный RAID 6, к примеру, делает доступными 40
> Тб из 48 Тб реальных (24 диска по 2 Тб) при
> допустимости поломки любых двух дисков без потери данных.Кассандра интересна с того момента, как данные физически не влезают в один сервер. А поднимать целое хранилище только для хранения ОДНОЙ БД + сервера, которые умеют этой БД управлять - обходятся намного дороже, чем Кассандра.
Плюс переход от ACID к BASE позволяет множеству мастеров работать в режиме записи данных. Что опять же интересно только на больших объемах.
Таким образом тот объем данных, что влезает в аппаратный RAID, можно гонять и на RAID. "Эффективность и дешевизна" Cassandra проявится на тех, объемам и нагрузках, которые не влезают ни в один адекватный сервер.
> Если у тебя аппаратный RAID... то в результате прорыва трубы или визита судебных приставов Вы теряете сразу весь RAID-массив :b
