Организация Apache Software Foundation проедставила (https://blogs.apache.org/foundation/entry/the_apache_softwar...) релиз распределённой СУБД Apache Cassandra 3.0 (http://cassandra.apache.org/), относящейся к классу noSQL-систем и рассчитанной на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, хранимых в форме ассоциативного массива (хэша). Код проекта написан на языке Java и распространяется в рамках лицензии Apache 2.0. Изначально СУБД Cassandra была разработана в недрах компании Facebook и в 2009 году передана под покровительство фонда Apache. Промышленные решения на базе Cassandra, хранящие сотни терабайт данных, охватывающие сотни серверов и способные обрабатывать тысячи запросов в секунду, развернуты для обеспечения сервисов таких компаний и организаций, как Adobe, CERN, Cisco, IBM, HP, Comcast, Disney, eBay, Netflix, Sony, Rackspace, Reddit и Twitter.
Основные новшества (https://git1-us-west.apache.org/repos/asf?p=cassandra.git;a=...):
- Поддержка материализованных представлений (http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materi...), позволяющих сформировать виртуальную таблицу на основе произвольного CQL-запроса, содержимое которой не генерируется на лету как в обычных представлениях, а кэшируется между запросами в форме индекса. Материализованное представление может применяться в качестве более эффективной альтернативы вторичным индексам для запросов по непервичным ключам, денормализация данных с разных узлов в которой выполняется на стороне сервера;
- Полностью переработан (https://issues.apache.org/jira/browse/CASSANDRA-6230) механизм хранения информации о репликах для сбойных узлов ("hinted handoff"), вместо одного файла system.hints хинты теперь записываются в отдельные файлы, что значительно увеличивает эффективность диспетчеризации;
- Поддержка режима EACH_QUORUM для обеспечения заданного уровня согласованности для запросов на чтение;
- Поддержка ограничения выборки любых компонентов ключей раздела или кластера через выражение "IN" в директивах UPDATE и DELETE;
- В директиву DELETE добавлена поддержка отсеивания одно- или многостолбцовых слайсов при помощи операторов ">", ">=", "<=" и "<";
- В команде "nodetool rebuild_index" теперь можно указывать индекс, без необходимости указания связанной с ним таблицы;
- Повышена эффективность хранения данных, что привело к экономии места в хранилище в среднем на 50%;
- Обеспечен вывод предупреждений в лог, если операция сборки мусора выполняется дольше 1000мс.
СУБД Cassandra объединяет в себе полностью распределённую hash-систему Dynamo, обеспечивающую практически линейную масштабируемость при увеличении объема данных. Cassandra использует модель хранения данных на базе семейства столбцов (ColumnFamily), отличающуюся от систем подобных memcachedb, которые хранят данные только в связке ключ/значение, возможностью организовать хранение хэшей с несколькими уровнями вложенности.
Для упрощения взаимодействия с БД поддерживается язык формирования структурированных запросов CQL (http://crlog.info/2011/03/29/cassandra-query-language-aka-cq.../) (Cassandra Query Language), напоминающий SQL, но урезанный по функциональности. Из возможностей можно отметить поддержку пространств имён и семейств столбцов, создание индексов через выражение "CREATE INDEX".
СУБД позволяет создавать устойчивые к сбоям хранилища: помещаемые в БД данные автоматически реплицируются на несколько узлов распределённой сети, которая может охватывать разные центры обработки данных. При сбое узла, его функции на лету подхватываются другими узлами. Добавление новых узлов в кластер и обновление версии Cassandra производится на лету, без дополнительного ручного вмешательства и переконфигурирования других узлов. Драйверы с поддержкой CQL подготовлены для языков Python (https://github.com/datastax/python-driver), Java (https://github.com/datastax/java-driver) (JDBC/DBAPI2), Ruby (https://github.com/datastax/ruby-driver), PHP (https://github.com/datastax/php-driver), C++ (https://github.com/datastax/cpp-driver) и JavaScript (https://github.com/datastax/nodejs-driver) (Node.js).
URL: https://blogs.apache.org/foundation/entry/the_apache_softwar...
Новость: http://www.opennet.me/opennews/art.shtml?num=43298
В своей нише (расшадить БД на 10.000 нод) у отой базыне нет альтернантив.
http://www.opennet.me/opennews/art.shtml?num=43017
СцЫллу только начали писать, и функционал до Кассандры не дотянули даже близко. Внедрений ноль. А тут уже под 10 лет эксплуатации на жирнейших задачах.
> СцЫллу только начали писатьДелаем ставки, за сколько месяцев выпрут жабу на помойку после того как СцЫллу допишут.
после того как СцЫллу допишутЕСЛИ допишут. После этого лет через 5-10. Печаль фанбоям си?
Допишут-допишут, не волнуйся так. Хоть ты и пытаешься сучить ножками, осознавая, что против плюсового решения у жабы нет шансов, факта это не изменит.
10000 нод потому что жаба на меньшем не шевелится даже? а постгрес один справился бы?
Так набрасываешь, аж вспотел наверное? А у нас на некоторых задачах джава работает быстрее приплюснутого си. В случае с Кассандрой всё ещё интереснее - она просто работает, а все остальные поделены на ноль и существуют только в сферическо-вакуумных мечтах сишных фанатовПро постгрес посмеялся...
>>А у нас на некоторых задачах джава работает быстрее приплюснутого си.1) Выгоните своих кодеров на плюсах.
2) Расскажите про задачи, на которых жаба задушила плюсы, мы тут посмеяться хотим.
http://blog.carlesmateo.com/2014/10/13/performance-of-severa.../JIT (в идеале) написав саму программу 1 РАЗ, позволяет запустить её используя МАКСИМУМ производительности на КОНКРЕТНОМ компе (задействовав оптимальные инструкции КОНКРЕТНОГО процессора)
вместо компиляции С/С++ с флагами оптимизации под каждый тип процессора в "серверной" (а потом ещё и деплоить на каждый сервер "истинно-верную версию" - тоже гемор ещё тот).Будущее лвиной доли программ Прикладного уровня однозначно за JIT.
А JIT (на данный момент времени) одна из лучших реализаций всё-таки - Oracle Java ...
(к моему сожалению)
Ну например берем список недействительных российских паспортов (с сайта ФМС). 94 млн записей. Надо выделять дельту, т.е. скачали сегодня (сунули в SQL), через пару дней там 94млн+~20k. Надо найти эти 20k и засунуть в SQL.На джаве за 40 сек отрабатывает на древнем 2.5ггц ксеоне. Сишечка грубо на 20% дольше, плюс саму программу писали в разы дольше.
Жалко, что я в map-reduce не силён, так бы можно было ещё в 4 раза ускорить джавку ;)
p.s. для умников собирающихся покричать "сделай сразу 100млн инсертов", сразу отвечаю - это примерно полчаса средствами ОрацлеЕЕ.
Вариант что ты в сишечке анскиллед лузер - в рассчёт не принимается?
Words are cheap (c)Show you code, Luke! И сюда ссылочку на свой гитхабчик с кучей реактивного кода. Я на том же железе запущу ;)
>Ну например берем список недействительных российских паспортов (с сайта ФМС). 94 млн записей. ....
>На джаве за 40 сек отрабатывает на древнем 2.5ггц ксеоне. Сишечка грубо на 20% дольше, плюс саму программу писали в разы дольше.А попробуй тупо: sort list_old > list_old_s; sort list_new > list_new_s; diff list_old_s list_new_s :-)
А то я пару раз уже наступал когда это уделывало все кассандры\шмасардры\оракакелы :)
В sqlite на десктопной машине с iCore 5 загрузка за 2.5 минуты.
Есть у вас абстрактный класс. Есть массив, который содержит объекты классов-потомков этого класса. Заранее НЕВОЗМОЖНО знать какие конкретно потомки в этом массиве. Вы перебираете массив, получаете объект и вызываете какой-то метод.Это в C++ ОЧЕНЬ медленно, т.к. нужно ВСЕГДА залезать в специальную табличку, чтобы понять где находится исполняемый код конкретного потомка.
В Java в рантайме определяется какой конкретный класс в массиве и вызов испоняемого кода инлайнится. Т.о. лезть в табличку при КАЖДОМ вызове метода не нужно. (Раньше было ограничение на то, что в массиве не боле 2-х различных классов. Сейчас не знаю, но в реальной жизни два возникает очень часто).
А таких оптимизаций во время выполнения ОЧЕНЬ много.
Выкидываешь абстрактный класс, и этот кусок пишешь на шаблонах. Всё, жаба начинает реактивно сливать.
Теретически задача неплохая. А вот каково практическое применение? И главное - нельзя ли конечную практическую задачу решить более простыми методами?
можно поподробнее, каким образом жава определяет где какой метод инлайнить?
я лично вижу только один способ: хранить в объекте флаг и в вызове метода делать что-то типа:
if(flag)
do_method1();
else
do_methd2();
Через switch/case можно расширить на большее разнообразие подклассов.
Но как-то это всё неизящно что-ли.
Дак как там на самом деле? реально интересно
>1) Выгоните своих кодеров на плюсах.да! потому что аноним опеннета так сказал!
Справедливости ради, даже несмотря на все "прелести" явы и ставшее притчей во языцех "ява не тормозит(с)" сама по себе кассандра довольно шустрая штука, когда надо писать в базу МНОГО данных.
Ошибаетесь. Намекну на правильный метод: самой базе необязательно что-либо знать о шардировании.
java.. недешево наверно содержать в такой базе данные
На самом деле дешевле чем в любой реляционной БД написанной на C, т.к. обычно нужно не только хранить, а еще читать и писать.
В ней CAS (прочитать значение и время создания значения - изменить значение с указанным временем создания) реализован?
хочу хранить ключ в нескольких копиях (для надежности) но чтобы не было возможно расслоение сети и изменения значения ключа в разных сетях... как тут это можно сделать?как у меня это сделано сейчаc: я храню ключ в postgres при этом синхронно этот postgres реплицирую. если вдруг postgres сдохнет я его вообще выключу из работы и буду работать с другим.
как бы сделать так же чтобы у ключа были копии но использовались бы они только когда сдох основной сервер при этом копия на сдохшем сервере уже не участвовала в работе.
вообщем меня пугает расслоение данных которое описывали люди ранее, когда есть ключ и есть его копия, потом сеть распадается, в одной копии ключ меняется по одному, в другой по другому и в результате мы теряем данные
EACH_QUORUM is now a supported consistency level for read requests.те можно хранить скажем 4 копии ключа и требовать чтобы при чтении были доступны все 4 копии, что делать если все 4 не доступны?
я бы тебе посоветовал проверить сетевой кабель и кабель питания у всех 4 серверов
А если они все на разных континентах?
тогда нужно или переносить севера в один датацентр или читать документацию такого типа http://www.datastax.com/dev/blog/deploying-cassandra-across-...
а что говорят относительно производительности и потребления/требований к памяти в новой версии? (по сравнению с 2.2)