twitter.com 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 как был самый большой процент, так и остался.
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 как был самый большой процент, так и остался.
Наблюдаю в логах 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.
При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?
2016-02-15 09:22:07.687 [info] <0.4996.18> Merged {["/var/lib/riak/bitcask/28544953854119197621165719388989902727654932480/304.bitcask.data", ...... ,[]} in 637.526956 seconds.
При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?
Никак не могу отделаться от мысли что Риак — это абсолютно бесполезная поделка из разряда «а смотрите, как мы можем». Он, кстати, не загнулся ещё? Чёт про него ничего не слышно в последние года два.
Презенташка от Riot Games о том, как они построили чат на базе ejabberd'а для 70 миллионов игроков: slideshare.net
В качестве бэкенда юзают Riak.
В качестве бэкенда юзают Riak.
Как и обещал, вышел ejabberd 14.07. Из основного:
* Поддержка Riak в качестве бэкенда БД
* Поддержка SIP outbound (RFC 5626)
* Исправления в Stream Management (XEP-0198)
* Улучшения системы журналирования
blog.process-one.net
* Поддержка Riak в качестве бэкенда БД
* Поддержка SIP outbound (RFC 5626)
* Исправления в Stream Management (XEP-0198)
* Улучшения системы журналирования
blog.process-one.net
В новой версии ejabberd'а будет поддержка SIP outbound (RFC 5626) и поддержка Riak в качестве бэкенда (ростеры, авторизация, оффлайны и т.д.). Если успеем. Ориентировочно выйдет в конце июля.
В следующую версию я хз чего в него пихать — идей ваще нет.
В следующую версию я хз чего в него пихать — идей ваще нет.
Выяснили, что в текущей версии riak (1.4.x) из leveldb практически ничего не удаляется.
Бекапы в s3 накрылись медным тазом до версии 2.0, где обещали починить.
Впрочем, как услугу всё равно продавать можно. Отдавать всякую статику сиё не помешает.
Бекапы в s3 накрылись медным тазом до версии 2.0, где обещали починить.
Впрочем, как услугу всё равно продавать можно. Отдавать всякую статику сиё не помешает.
кто тут разбирается в перфоманс тюнинге риака?
ато у нас на E5-2660 эта сучка выжрала 1200% cpu, тоесть все физические ядра и нихуя не работает
тоесть медленно
ато у нас на E5-2660 эта сучка выжрала 1200% cpu, тоесть все физические ядра и нихуя не работает
тоесть медленно
Изучил кучи доки по монгодб. Теперь двигаюсь в сторону риака. Ведь он на ерланге.
Better understanding latency vs. consistency trade-offs in Riak
lists.basho.com
lists.basho.com
Если мне никто не расскажет как работают индексы для wildcard'ов я же пойду и тупо руками нагружу базу чтоб прикинуть сложность! (хотя можт это и тупо)
Помогите, пожалуйста, понять, как работают dynamic-поля в lucene (те, по которым можно делать wildcard-поиск). Конкретно интересует, какой по ним строится индекс и какова сложность поиска по нему. А то прямо магия какая-то, ничего найти не могу по этому поводу.
накатал большую телегу "почему нам не стоит использовать riak", отдал двум архитекторам на "почитать". завтра посмотрим, чем сериал окончится.
Нет, всё классно. Но если вы вставите несколько данных, а потом им всем сделаете delete() — оно удалит эти данные через НЕСКОЛЬКО СЕКУНД. То есть еще несколько секунд оно вам будет их возвращать.
а теперь о такой вещи, как линки (они же ссылки). в riak можно одними данными ссылаться на другие (ну, обычные внешние ссылки, только извращены немного), а при map/reduce можно делать целую фазу "пройтись по ссылкам и подтянуть результат". если призадуматься, то это хорошее решение древнего костыля RDBMS. вот представьте: у вас есть табличка продуктов, из которой вы делаете select хитрый. а для продуктов еще надо подтянуть компании. делать JOIN тупо, потому что продукты, скажем, могут повторяться. ну или типа того, вы поняли. так вот, вы далете сначала выбор продуктов, а потом делаете сразу же "пройтись по ссылкам". и никаких туда-сюда тяганий данных, или подзапросов. хорошо.
Ну и, собственно, архитектура riak хороша. Распределённый hashtable, но при этом очень красиво репликация ввёрнута еще.
Идеологически riak блещет красотой то тут то здесь. К примеру, операция map/reduce обобщена просто в "цепочка операций", и вы, как бы, выстраиваете в цепочку: "сделать выборку таких-то данных" -> "сделать map на таком-то языке" -> "пройтись по внешним ссылкам, подтянуть их" -> "сделать reduce такой-то" -> "сделать еще map" -> "и еще reduce". красота.
По-моему, на канале #riak меня сейчас отошлют к чертовой матери, столько вопросов глупых задаю, не понимая концепции (хотя прогресс есть). Да я бы и сам отослал, если честно, но я-то знаю, что с Монгой было гораздо проще, значит есть вероятность, что таки у них просто документация сложная.
The combination of bucket properties allow_mult=true and last_write_wins=true has undefined behavior and should not be used.
Пошел и пошутил на канале #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")
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")
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
а еще у них нету банального функционала по вытягиванию списка ключей / бакетов с лимитом и оффсетом.
GET /buckets/bucket/keys/key # New format
а еще у них нету банального функционала по вытягиванию списка ключей / бакетов с лимитом и оффсетом.
Авторы честно признаются, что "драйвер фиговый", "этот кусок у руби переписывали" и вообще. Эх, времени бы мне, да побольше, глядишь и разобрался бы поглубже в этом всём.
И сюда похвастаюсь. Таки пул реквест в драйвер риака один не удержался и сделал. github.com
Питоновский драйвер для риака — какой-то отстой (с первого и второго взгляда).
Один из плохих побочных эффектов "свободы", или, скорее даже, наверное, выигрыш от просто добавления еще одного слоя абстракции — база Riak с её файловым хранилищем Luwak, у которого отсутствует понятие "папки" (коллекции / бакета). Если надо — сам бери и городи префикс какой. Очень неудобно, если хочется при тестах иметь тестовую коллекцию. Будем думать.
CouchDB vs Riak: сравнение скорости индексации и отдачи результата map/reduce запроса
blogs.digitar.com
blogs.digitar.com
Переезд с CouchDB на Riak
labs.linkfluence.net
Надо сказать, что описанные проблемы вполне реальны и о них нужно знать.
Тут решений только два:
— быть up-to-date, благо активно развиваются и от версии к версии становятся все лучше и лучше.
— использовать кластеризацию через тот же BigCouch либо дробить базу на множество мелких баз и связывать их уже программной логикой.
BigCouch появился не так давно и еще не проверен временем, хотя работает и работает как заявлено.А вот дробить базу можно было всегда и по разному, но тут стоит выделить два решения:
— по типу документа
— по дате
Первый случай часто советуют, но у него серьезный недостаток — кросстиповые views теряются и весь смысл использовать CouchDB исчезает. Поверьте, склеивать результаты программно не самое приятное занятие, уж не будем упоминать о скорости.
Дробление по дате выглядит уже более перспективно и намного гибче, останется только понять в каком периоде времени находится документ с нужным нам id. Тут решение простое — отдельная база с индексом кто где лежит. Пограничные выборки, охватывающие сразу две базы уже намного проще склеивать.
Проблема тут только одна — не забывать синхронизировать дизайны документов.
Вот такие пироги. А Riak действительно крут, если так посмотреть, жаль только что masterless-репликации и система упраления доступны лишь в платной версии.
labs.linkfluence.net
Надо сказать, что описанные проблемы вполне реальны и о них нужно знать.
Тут решений только два:
— быть up-to-date, благо активно развиваются и от версии к версии становятся все лучше и лучше.
— использовать кластеризацию через тот же BigCouch либо дробить базу на множество мелких баз и связывать их уже программной логикой.
BigCouch появился не так давно и еще не проверен временем, хотя работает и работает как заявлено.А вот дробить базу можно было всегда и по разному, но тут стоит выделить два решения:
— по типу документа
— по дате
Первый случай часто советуют, но у него серьезный недостаток — кросстиповые views теряются и весь смысл использовать CouchDB исчезает. Поверьте, склеивать результаты программно не самое приятное занятие, уж не будем упоминать о скорости.
Дробление по дате выглядит уже более перспективно и намного гибче, останется только понять в каком периоде времени находится документ с нужным нам id. Тут решение простое — отдельная база с индексом кто где лежит. Пограничные выборки, охватывающие сразу две базы уже намного проще склеивать.
Проблема тут только одна — не забывать синхронизировать дизайны документов.
Вот такие пироги. А Riak действительно крут, если так посмотреть, жаль только что masterless-репликации и система упраления доступны лишь в платной версии.