LINUX.ORG.RU

Apache Cassandra 0.7

 , , ,


0

1

Фонд Apache Software Foundation анонсировал выход новой версии СУБД Cassandra: 0.7.

Cassandra — отказоустойчивая распределенная система управления базами данных, позволяющая работать с большими объемами данных на кластере из обыкновенных серверов, не имеющая единой точки отказа. СУБД успешно применяется в Cisco, Cloudkick, Digg, Facebook, Rackspace и Twitter.

Основные изменения этой версии:

  • Вторичные индексы (CASSANDRA-749)
  • Строки теперь могут содержать более 2 миллионов колонок
  • Полная online модификация схемы БД
  • Новая стратегия репликации данных по серверам с поддержкой сложных топологий (распределение данных по стойкам/датацентрам)
  • Хранение значений с ограниченным сроком жизни (автоматическое удаление данных при истечении их срока жизни)
  • Различные другие изменения, повышающие скорость работы СУБД

>>> Подробности

★★★★★

Почему успешно не применяется на лоре?

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

потому что нам не нужна распределенная БД, lor живет на одном сервере

maxcom ★★★★★ ()
Ответ на: комментарий от maxcom

реквестирую фотку

выклади фотку сервера чтоли на котором живет лор...поставлю как фон на рабочем столе

anonymous ()

А LOR это теперь уже точно Opennet LE, или еще не совсем?

anonymous ()
Ответ на: комментарий от maxcom

Надо фотку.

Фотки нашего нет, а вообще как-то так: http://www.google.ru/images?q=ibm x3650

Это холодные бездушные фотографии из материалов для прессы, а нужна тёплая ламповая фотка из стойки с проводами. Можно даже с заваленным горизонтом.

Camel ★★★★★ ()
Ответ на: комментарий от anonymous

Где-то недавно читал, что и сам Facebook тоже не в восторге.

pitekantrop ★★★ ()
Ответ на: комментарий от anonymous

Интересно в чем конкретно проблемы =)

PS предсказываю ЛОР-style ответ будет «в java».

VoDA ★★ ()
Ответ на: комментарий от VoDA

Я вот прямо сейчас пытаюсь сбалансировать кластер. Моя проблема в том, что nodetool move зависает. Выяснилось, что после подготовки stream для миграции, Cassandra посылает команду другой ноде «принимай поток». Но если команда не проходит (а кластер под нагрузкой, тайм-аут возможен), то всё, пиши пропало. Нода не будет повторять команду, будет тупо ждать ответа до бесконечности. Из-за этого я уже неделю не могу сбалансровать этот чёртов кластер.

Кстати, по словам девелоперов (которые довольно дружелюбные в IRC), этот баг в 0.7 исправлен. Вот только обновиться с downtime мне на продакшене не дадут.

voronaam ★★ ()
Ответ на: комментарий от voronaam

почему с downtime? она же вся такая супер-пупер распределённая, можно же обновиться постепенно.

PS: кто что скажет про redis? выбрал его для 1 мааахонького сайтика из-за его легковесности, монстр на ДЖАВЕ мне был явно не к месту.

anonymous ()

да не хватает тегов java, тормоза, и ссылку на статью: как собрать обогревать с помощью JVM и мощного процессора.

anonymous ()
Ответ на: комментарий от anonymous

как собрать обогревать с помощью JVM и мощного процессора.

Деплоим lor-source, запускаем внутрь анонимусов, вбрасываем.

power ()
Ответ на: комментарий от anonymous

The Cassandra inter-node protocol is incompatible with 0.6.x releases (and with 0.7 beta1), meaning you will have to bring your cluster down prior to upgrading: you cannot mix 0.6 and 0.7 nodes.

maxcom ★★★★★ ()
Ответ на: комментарий от maxcom

это они круто придумали, ничего не скажешь...

anonymous ()

Чем оно лучше MySQL?

Siado ★★★★★ ()
Ответ на: комментарий от Siado

тем, что в свете последних событий мускул просто отодвинули

kto_tama ★★★★★ ()
Ответ на: комментарий от Siado

> Чем оно лучше MySQL?

Оно другое - там кластер без master-узла, eventual consistency, колоночное хранение

maxcom ★★★★★ ()
Ответ на: комментарий от anonymous

> PS: кто что скажет про redis? выбрал его для 1 мааахонького сайтика из-за его легковесности, монстр на ДЖАВЕ мне был явно не к месту.

Redis это другая весовая категория

maxcom ★★★★★ ()
Ответ на: комментарий от OramahMaalhur

>Кстати, Cassandra написана на Java.
Ничего страшного, она же для кластеров.

Ramen ★★★★ ()

>Новая стратегия репликации данных по серверам с поддержкой сложных топологий (распределение данных по стойкам/датацентрам)

А где про это можно почитать детальнее ?

kred ()
Ответ на: комментарий от kred

> А где про это можно почитать детальнее ?

Кроме сайта самой Кассандры очень много полезного на сайте коммерческой организации ею занимающейся: http://www.riptano.com/

Я вчера был на однодневном курсе от них, много нового узнал. Они молодцы, проблемы признают, неудачные решения выкидывают. Нативный код из Java они, кстати, часто вызывают, и возможности ОС (например по кэшированию дискового IO) испольуют с умом.

Жаль что компания на платную поддержку не раскошелилась. Мне очень хотелось сводить их посмотреть на наш кластер :)

voronaam ★★ ()
Ответ на: комментарий от voronaam

а для каких целей используете cassandra? оправдывает ли оно задачи?

и как оно в сравнении с кластером MySQL один мастер на запись + куча слейвов на чтение и memcached для снижения читающей нагрузки?

VoDA ★★ ()
Ответ на: комментарий от VoDA

Наш use-case: поток новостей. Для каждого пользователя нужно хранить N последних событий. События пишут намного чаще, чем читают, вполне ожидается, что большинство записанных данных никогда не будут прочитаны, а будут просто вытесненными более новыми событиями.

Плюс там же поток от «друзей» (на самом деле там другая связь между юзерами, но это не важно, да и CF называется Friends).

Так вот, MySQL кластер нам тут вообще не помогал, потому что у нас write-intensive. А запись в кластер Cassandra очень быстрая (особенно с учётом того, что мы пишем с минимальной консистентностью). memcached сейчас не используется, потому что читающая нагрузка и так низкая, а на запись он мало помогает. Хотя я лоббирую его включение, исключительно для кооперативной параллельности. Дело в том, что Cassandra не поддерживает atomic increase, который у нас симулируется кодом. Не лучшим образом причём, конфликт там возможен (приведёт к потере одного события, что для наших менеджеров ок).

В общем, в этой задаче Cassandra среди лидеров (хотя лично я бы выбрал MongoDB, хотя бы из-за C++). У нас вообще интересно. На двух из пяти серверов кончилось место на жёстком диске. (Да, да, тот кто его запускал немного баклан и не сбалансировал кольцо). И в таком состоянии кластер работает уже два месяца. И живёт! В общем, на счёт fault tolerant они не врут.

Кстати тут и о минусе. Перебалансировать кольцо - очень трудно. Мы работаем на версии 0.6.5, в которой есть баг с потерей пакетов комманд. В тоге новая нода входит в режим bootstraping, получает 50Gb данных, и сидит дальше. Потому что другие 5 нод в это время загружены прилично и теряют командный пакет. У нас потеря этого пакета происходила в 100% случаев. Перезапуск кассандры на загружающейся ноде приводит к получению её следующих 50Gb. Так по шагам, практически вручную и бутстрапимся. Для этого бага есть патч, но мне не разрешают. Всё из-за корпоративной политики. Я в EA работаю, тут, как и в большинстве других больших компаний, каждый апдейт апача или ядра проходит кучу инстанций. А патчи накладывать вообще все боятся.

voronaam ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.