Linux riak twitter.com Riak усё

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

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

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 как был самый большой процент, так и остался.

работа лытдыбр s3 riak Наблюдаю в логах 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.

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

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

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

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

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

blog.process-one.net

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

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

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

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

NoSQL riak odbms.org

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

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

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

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

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

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

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

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

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

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

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

юмор riak Пошел и пошутил на канале #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")

O_o riak 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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