to post messages and comments.

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

Status Ring Pending Node
-------------------------------------------------------------------------------
valid 8.6% 8.6% '[email protected]'
valid 8.2% 7.8% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 8.2% 7.4% '[email protected]'
valid 9.4% 9.4% '[email protected]'
valid 0.0% 7.4% '[email protected]'
-------------------------------------------------------------------------------
Valid:13 Leaving:0 Exiting:0 Joining:0 Down:0

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

Наблюдаю в логах 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.

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

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

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

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

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

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

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

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

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

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

По-моему, на канале #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.

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

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

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

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

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

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

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

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

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

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

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

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