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

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

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

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

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

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

Надо фотку.

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

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

Кстати, Cassandra написана на Java.

Особо успешно Cassandra применяется в Digg — http://techcrunch.com/2010/09/07/digg-struggles-vp-engineering-door/

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

> Cassandra

на продакшене

ССЗБ

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

Распределенное.

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

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

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

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

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

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

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

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

Наш 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 работаю, тут, как и в большинстве других больших компаний, каждый апдейт апача или ядра проходит кучу инстанций. А патчи накладывать вообще все боятся.

Кстати в 0.7.1 обещают поддержку increment