Чтобы добавлять сообщения и комментарии, .

@stanislavv:
stanislavv

Повис (именно повис, сволочь!) один из узлов риака. После прибития и поднятия — весь кластер в таком состоянии, что не все данные может выдать.
Запустил перезапуск всего кластера...

@stanislavv:
stanislavv

Риак — странная штука. Вот например, как он планирует распределить место в кластере после добавления ещё одного узла:

Status Ring Pending Node
-------------------------------------------------------------------------------
valid 8.6% 8.6% 'riak@192.168.0.130'
valid 8.2% 7.8% 'riak@192.168.0.131'
valid 8.2% 7.4% 'riak@192.168.0.132'
valid 8.2% 7.4% 'riak@192.168.0.133'
valid 8.2% 7.4% 'riak@192.168.0.134'
valid 8.2% 7.4% 'riak@192.168.0.135'
valid 8.2% 7.4% 'riak@192.168.0.136'
valid 8.2% 7.4% 'riak@192.168.0.137'
valid 8.2% 7.4% 'riak@192.168.0.138'
valid 8.2% 7.4% 'riak@192.168.0.139'
valid 8.2% 7.4% 'riak@192.168.0.140'
valid 9.4% 9.4% 'riak@192.168.0.141'
valid 0.0% 7.4% 'riak@192.168.0.142'
-------------------------------------------------------------------------------
Valid:13 Leaving:0 Exiting:0 Joining:0 Down:0

Обратите внимание на то, что у .141 как был самый большой процент, так и остался.

@stanislavv:
stanislavv

Наблюдаю в логах riak надписи вида:
2016-02-15 09:22:07.687 [info] <0.4996.18> Merged {["/var/lib/riak/bitcask/28544953854119197621165719388989902727654932480/304.bitcask.data", ...... ,[]} in 637.526956 seconds.

При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?

@Zert:
Zert

Никак не могу отделаться от мысли что Риак — это абсолютно бесполезная поделка из разряда «а смотрите, как мы можем». Он, кстати, не загнулся ещё? Чёт про него ничего не слышно в последние года два.

@zinid:
zinid

Презенташка от Riot Games о том, как они построили чат на базе ejabberd'а для 70 миллионов игроков: slideshare.net
В качестве бэкенда юзают Riak.

@zinid:
zinid

Как и обещал, вышел ejabberd 14.07. Из основного:

* Поддержка Riak в качестве бэкенда БД
* Поддержка SIP outbound (RFC 5626)
* Исправления в Stream Management (XEP-0198)
* Улучшения системы журналирования

blog.process-one.net

@zinid:
zinid

В новой версии ejabberd'а будет поддержка SIP outbound (RFC 5626) и поддержка Riak в качестве бэкенда (ростеры, авторизация, оффлайны и т.д.). Если успеем. Ориентировочно выйдет в конце июля.
В следующую версию я хз чего в него пихать — идей ваще нет.

@stanislavv:
stanislavv

Выяснили, что в текущей версии riak (1.4.x) из leveldb практически ничего не удаляется.
Бекапы в s3 накрылись медным тазом до версии 2.0, где обещали починить.
Впрочем, как услугу всё равно продавать можно. Отдавать всякую статику сиё не помешает.

@netneladno:
netneladno

agilord.com
25kk в день это 289 в секунду
блядь, такие смешные. просто ад

@netneladno:
netneladno

кто тут разбирается в перфоманс тюнинге риака?
ато у нас на E5-2660 эта сучка выжрала 1200% cpu, тоесть все физические ядра и нихуя не работает
тоесть медленно

@netneladno:
netneladno

odbms.org

@ber9am0t:
ber9am0t

Изучил кучи доки по монгодб. Теперь двигаюсь в сторону риака. Ведь он на ерланге.

@Kxepal:
Kxepal

Better understanding latency vs. consistency trade-offs in Riak
lists.basho.com

@kb:
kb

Если мне никто не расскажет как работают индексы для wildcard'ов я же пойду и тупо руками нагружу базу чтоб прикинуть сложность! (хотя можт это и тупо)

@kb:
kb

Помогите, пожалуйста, понять, как работают dynamic-поля в lucene (те, по которым можно делать wildcard-поиск). Конкретно интересует, какой по ним строится индекс и какова сложность поиска по нему. А то прямо магия какая-то, ничего найти не могу по этому поводу.

@kb:
kb

накатал большую телегу "почему нам не стоит использовать riak", отдал двум архитекторам на "почитать". завтра посмотрим, чем сериал окончится.

@kb:
kb

Нет, всё классно. Но если вы вставите несколько данных, а потом им всем сделаете delete() — оно удалит эти данные через НЕСКОЛЬКО СЕКУНД. То есть еще несколько секунд оно вам будет их возвращать.

@kb:
kb

а теперь о такой вещи, как линки (они же ссылки). в riak можно одними данными ссылаться на другие (ну, обычные внешние ссылки, только извращены немного), а при map/reduce можно делать целую фазу "пройтись по ссылкам и подтянуть результат". если призадуматься, то это хорошее решение древнего костыля RDBMS. вот представьте: у вас есть табличка продуктов, из которой вы делаете select хитрый. а для продуктов еще надо подтянуть компании. делать JOIN тупо, потому что продукты, скажем, могут повторяться. ну или типа того, вы поняли. так вот, вы далете сначала выбор продуктов, а потом делаете сразу же "пройтись по ссылкам". и никаких туда-сюда тяганий данных, или подзапросов. хорошо.

@kb:
kb

Ну и, собственно, архитектура riak хороша. Распределённый hashtable, но при этом очень красиво репликация ввёрнута еще.

@kb:
kb

Идеологически riak блещет красотой то тут то здесь. К примеру, операция map/reduce обобщена просто в "цепочка операций", и вы, как бы, выстраиваете в цепочку: "сделать выборку таких-то данных" -> "сделать map на таком-то языке" -> "пройтись по внешним ссылкам, подтянуть их" -> "сделать reduce такой-то" -> "сделать еще map" -> "и еще reduce". красота.

@kb:
kb

По-моему, на канале #riak меня сейчас отошлют к чертовой матери, столько вопросов глупых задаю, не понимая концепции (хотя прогресс есть). Да я бы и сам отослал, если честно, но я-то знаю, что с Монгой было гораздо проще, значит есть вероятность, что таки у них просто документация сложная.

@kb:
kb

The combination of bucket properties allow_mult=true and last_write_wins=true has undefined behavior and should not be used.

@kb:
kb

Пошел и пошутил на канале #riak:
Why not "To avoid a pathological divergence you should be able to get your process back in time, kill it's clone to avoid time paradoxes and when you will get to that value — just skip that")

@kb:
kb

It should be noted that if you are trying to resolve conflicts automatically, you can end up in a condition with which two clients are simultaneously resolving and creating new conflicts. To avoid a pathological divergence you should be sure to limit the number of reconciliations and fail once that limit has been exceeded.

@kb:
kb

А еще, как результат REST, получается при вставке документа в заголовке ответа увидите что-то типа "Location: /riak/test/bzPygTesROPtGGVUKfyvp2RR49". Класно, но, снова таки, руками парсить как-то — не кошер (а чтоб драйвер научить пришлось его пилить, кстати).

@kb:
kb

GET /riak/bucket/key # Old format
GET /buckets/bucket/keys/key # New format

а еще у них нету банального функционала по вытягиванию списка ключей / бакетов с лимитом и оффсетом.

@kb:
kb

Авторы честно признаются, что "драйвер фиговый", "этот кусок у руби переписывали" и вообще. Эх, времени бы мне, да побольше, глядишь и разобрался бы поглубже в этом всём.

@kb:
kb

И сюда похвастаюсь. Таки пул реквест в драйвер риака один не удержался и сделал. github.com

@kb:
kb

Питоновский драйвер для риака — какой-то отстой (с первого и второго взгляда).

@kb:
kb

Один из плохих побочных эффектов "свободы", или, скорее даже, наверное, выигрыш от просто добавления еще одного слоя абстракции — база Riak с её файловым хранилищем Luwak, у которого отсутствует понятие "папки" (коллекции / бакета). Если надо — сам бери и городи префикс какой. Очень неудобно, если хочется при тестах иметь тестовую коллекцию. Будем думать.

@Kxepal:
Kxepal

CouchDB vs Riak: сравнение скорости индексации и отдачи результата map/reduce запроса
blogs.digitar.com

@Kxepal:
Kxepal

Переезд с CouchDB на Riak
labs.linkfluence.net

Надо сказать, что описанные проблемы вполне реальны и о них нужно знать.
Тут решений только два:
— быть up-to-date, благо активно развиваются и от версии к версии становятся все лучше и лучше.
— использовать кластеризацию через тот же BigCouch либо дробить базу на множество мелких баз и связывать их уже программной логикой.

BigCouch появился не так давно и еще не проверен временем, хотя работает и работает как заявлено.А вот дробить базу можно было всегда и по разному, но тут стоит выделить два решения:
— по типу документа
— по дате

Первый случай часто советуют, но у него серьезный недостаток — кросстиповые views теряются и весь смысл использовать CouchDB исчезает. Поверьте, склеивать результаты программно не самое приятное занятие, уж не будем упоминать о скорости.

Дробление по дате выглядит уже более перспективно и намного гибче, останется только понять в каком периоде времени находится документ с нужным нам id. Тут решение простое — отдельная база с индексом кто где лежит. Пограничные выборки, охватывающие сразу две базы уже намного проще склеивать.

Проблема тут только одна — не забывать синхронизировать дизайны документов.

Вот такие пироги. А Riak действительно крут, если так посмотреть, жаль только что masterless-репликации и система упраления доступны лишь в платной версии.