stanislavv
работа лытдыбр riak Повис (именно повис, сволочь!) один из узлов риака. После прибития и поднятия — весь кластер в таком состоянии, что не все данные может выдать.
Запустил перезапуск всего кластера...
stanislavv
работа лытдыбр 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 как был самый большой процент, так и остался.
stanislavv
работа лытдыбр 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.

При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?
Zert
Erlang WTF riak Никак не могу отделаться от мысли что Риак — это абсолютно бесполезная поделка из разряда «а смотрите, как мы можем». Он, кстати, не загнулся ещё? Чёт про него ничего не слышно в последние года два.
zinid
Jabber XMPP ejabberd SIP riak В новой версии ejabberd'а будет поддержка SIP outbound (RFC 5626) и поддержка Riak в качестве бэкенда (ростеры, авторизация, оффлайны и т.д.). Если успеем. Ориентировочно выйдет в конце июля.
В следующую версию я хз чего в него пихать — идей ваще нет.
stanislavv
работа riak Выяснили, что в текущей версии riak (1.4.x) из leveldb практически ничего не удаляется.
Бекапы в s3 накрылись медным тазом до версии 2.0, где обещали починить.
Впрочем, как услугу всё равно продавать можно. Отдавать всякую статику сиё не помешает.
netneladno
говно офесное riak кто тут разбирается в перфоманс тюнинге риака?
ато у нас на E5-2660 эта сучка выжрала 1200% cpu, тоесть все физические ядра и нихуя не работает
тоесть медленно
kb
riak Если мне никто не расскажет как работают индексы для wildcard'ов я же пойду и тупо руками нагружу базу чтоб прикинуть сложность! (хотя можт это и тупо)
kb
? lucene riak solr Помогите, пожалуйста, понять, как работают dynamic-поля в lucene (те, по которым можно делать wildcard-поиск). Конкретно интересует, какой по ним строится индекс и какова сложность поиска по нему. А то прямо магия какая-то, ничего найти не могу по этому поводу.
kb
riak накатал большую телегу "почему нам не стоит использовать riak", отдал двум архитекторам на "почитать". завтра посмотрим, чем сериал окончится.
kb
riak Нет, всё классно. Но если вы вставите несколько данных, а потом им всем сделаете delete() — оно удалит эти данные через НЕСКОЛЬКО СЕКУНД. То есть еще несколько секунд оно вам будет их возвращать.
kb
riak а теперь о такой вещи, как линки (они же ссылки). в riak можно одними данными ссылаться на другие (ну, обычные внешние ссылки, только извращены немного), а при map/reduce можно делать целую фазу "пройтись по ссылкам и подтянуть результат". если призадуматься, то это хорошее решение древнего костыля RDBMS. вот представьте: у вас есть табличка продуктов, из которой вы делаете select хитрый. а для продуктов еще надо подтянуть компании. делать JOIN тупо, потому что продукты, скажем, могут повторяться. ну или типа того, вы поняли. так вот, вы далете сначала выбор продуктов, а потом делаете сразу же "пройтись по ссылкам". и никаких туда-сюда тяганий данных, или подзапросов. хорошо.
kb
riak Ну и, собственно, архитектура riak хороша. Распределённый hashtable, но при этом очень красиво репликация ввёрнута еще.
kb
riak Идеологически riak блещет красотой то тут то здесь. К примеру, операция map/reduce обобщена просто в "цепочка операций", и вы, как бы, выстраиваете в цепочку: "сделать выборку таких-то данных" -> "сделать map на таком-то языке" -> "пройтись по внешним ссылкам, подтянуть их" -> "сделать reduce такой-то" -> "сделать еще map" -> "и еще reduce". красота.
kb
ЖЖ riak По-моему, на канале #riak меня сейчас отошлют к чертовой матери, столько вопросов глупых задаю, не понимая концепции (хотя прогресс есть). Да я бы и сам отослал, если честно, но я-то знаю, что с Монгой было гораздо проще, значит есть вероятность, что таки у них просто документация сложная.
kb
юмор 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")
kb
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.
kb
riak А еще, как результат REST, получается при вставке документа в заголовке ответа увидите что-то типа "Location: /riak/test/bzPygTesROPtGGVUKfyvp2RR49". Класно, но, снова таки, руками парсить как-то — не кошер (а чтоб драйвер научить пришлось его пилить, кстати).
kb
riak GET /riak/bucket/key # Old format
GET /buckets/bucket/keys/key # New format

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

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

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

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

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

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

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