LINUX.ORG.RU

Riak 1.2

 ,


0

2

Компания Basho объявила о выходе новой версии Riak — отказоустойчивой распределенной документо-ориентированной «NoSQL» СУБД.

В этой версии:

  • более эффективный процесс добавления одновременно нескольких новых узлов в кластер;
  • улучшенная процедура внесения изменений в структуру кластера и осуществления поэтапных обновлений узлов;
  • улучшен мониторинг производительности;
  • добавлена поддержка FreeBSD, пакеты для Ubuntu 10.04 (Lucid), 11.04 (Natty) и 12.04 (Precise);
  • в коммерческой (enterprise) версии добавлено SSL шифрование соединений; улучшено управление репликацией данных в конфигурациях с несколькими датацентрами;
  • и другие изменения.

>>> Подробности

★★★★★

Последнее исправление: Binary (всего исправлений: 5)

Ответ на: комментарий от plm

хзхз. может мы просто готовить не умеем, но у нас оно встало в ступор при выборке на жалких 65000 документов по не ключевому полю.

Binary ★★★★★
()

годно, пользовал - ничего так

petyuna
()
Ответ на: комментарий от punya

В теории может масштабироваться на бесконечное число нод, на практике получается, что работать это может только при выборке по ключу, и то не реактивно. Хотя может мы и правда не научились готовить.

Binary ★★★★★
()

Интересно, откуда же все-таки в последнее время полезли все эти nosql решения, как грибы после дождя. При том, что в 90% проектов вся эта распределенность - явный overengineering, да и качество всех этих бд не сильно поднимается над уровнем наколеночных поделий.

Nagwal ★★★★
()

СУБД это как-то язык не поворачивается назвать. Просто хранилище данных, чтоли.

d9d9 ★★★★
()
Ответ на: комментарий от Binary

А, ну и развитие веба, где часто требование консистентости является оверхедом.

При условии того, что дай бог 1% этих веб-проектов дорастет до состояния, когда почувствует этот оверхед...

Nagwal ★★★★
()

Поддержу анонимуса: слишком уж много NoSQL развелось в последнее время. Чем оно лучше CouchDB?

X-Pilot ★★★★★
()

Хоть бы написали что оно на Erlang-е. Я бы не качал, ибо заюзать всё-равно не смог бы.

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

Хоть бы написали что оно на Erlang-е

OMFG. До сих пор с ejabberd мучаюсь. И от Эрланга посему идиосинкразия...

KRoN73 ★★★★★
()
Ответ на: комментарий от raystlin

Вы говорите «NoSQL» словно это что-то хорошее.

Конечно! Ведь невозможность использовать стандартизированный структурированный язык запросов является неоспоримым преимуществом!

anonymous
()
Ответ на: комментарий от Binary

NIH-синдром и лень прочитать, что многие фишки и без того есть в постгресе?

Нет, просто в погроммисты пишутся все кому не лень, эдакая компенсация расходов, правда из их поделий единственное что растёт, так это расходы на железо, ну да, и память и воркеры и диски всё дёшево, только по моему опыту, эти светочи инноваций достаточно скоро начинают отрабатывать убытки похапэ-кодерами.

iBliss
()
Ответ на: комментарий от vladimir-vg

Расскажи

Ну как бы реляционную алгебру придумали ещё тогда, когда ты папе яйца щекотал, и с тех пор задачи только усложняются. Надо объяснять глупость твоего вопроса?

iBliss
()
Ответ на: комментарий от Binary

Лол. У вас любая nosql бд не заведется, ибо запрос не по индексированному полю равен обычному перебору всех значений поля и сравнение с заданным значением. Смысл nosql это хранение сложных структур с возможностью индексирования. Mongo поддерживает как простые индексы из одного ключа, так и вложенные. Вообщем, изучайте доки. Выборка по индексу (в том числе комплексному) или с хинтами в монго просто летает даже на нескольких миллионах. На нынешнем железе монго рекомендуется сегментирование (размазывание данных по серверам), когда вы перевалили потребление ОЗУ в 100Гб, это примерно 300+ миллионов документов размером менее 100 байт. Какие возможности у Riak в этом отношении ?

gh0stwizard ★★★★★
()
Ответ на: комментарий от iBliss

и с тех пор задачи только усложняются.

Именно по этому и появляются NoSQL. Потому что SQL очень многого не умеет.

theos ★★★
()
Ответ на: комментарий от theos

только ведь nosql ниже уровнем, чем sql. так что всё нормально: долгое время на асме продолжали писать те, кто не осилил сишечку.

anonymous
()
Ответ на: комментарий от theos

А язык C придумали неассиляторы ассемблера, а питон - ниассиляторы сишечки.

Совершенно верно.

Suigintou ★★★★★
()
Ответ на: комментарий от shimon

Riak интересен в первую очередь тем что multimaster, так что сравнивать его с PostgreSQL не очень правильно

maxcom ★★★★★
() автор топика
Ответ на: комментарий от Binary

Выборка по не ключевому полю это fullscan чтоль? От такого всё что угодно колом встанет.

Reset ★★★★★
()
Ответ на: комментарий от gh0stwizard

Постгрес на 65000 строках будет думать так, что устанешь ждать? (Реально - не дождались) Не смешите, а? Про индексирование, конечно, в курсе, но только нет там средств нужных. (Могу врать, непосредственно этой таской занимался другой человек, но в итоге то с риака свалили, хоть клиент и очень на нём настаивал)

Binary ★★★★★
()
Ответ на: комментарий от Binary

Про индексирование, конечно, в курсе, но только нет там средств нужных.

nosql без возможности построения вторичных индексов? не верю!

Reset ★★★★★
()
Ответ на: комментарий от Reset

Посмотри доки, если я не прав, ткнёшь носом, скажу спасибо. Как я понял, выехать хотят на map-reduce, т.е. при повышении числа нод, скорость выборок увеличивается, но когда одна нода не может справиться с таким смешным числом, желание поднимать ещё как-то улетучивается.

Binary ★★★★★
()
Ответ на: комментарий от maxcom

Хм, а сравнения а cassandra существуют в природе, раз уж про multimaster речь пошла?

Nagwal ★★★★
()
Ответ на: комментарий от Reset

Окей, спасибо, да только вот появилось это лишь в октябре прошлого года.

Binary ★★★★★
()
Ответ на: комментарий от Reset

помоему только в коммерческой версии

maxcom ★★★★★
() автор топика
Ответ на: комментарий от maxcom

Riak интересен в первую очередь тем что multimaster, так что сравнивать его с PostgreSQL не очень правильно

Я говорил о NoSQL вообще.

shimon ★★★★★
()
Ответ на: комментарий от AngryElf

Это можно обойти, добавлением нового поля 'index-key1-key2: key1-value, key2-value', правда тогда объем данных увеличится.

Reset ★★★★★
()

Странная база, если честно. Вроде и партиционирование, и мультимастер, и вторичные индексы, и многоэтапный map/reduce, а работать у себя нормально так и не заставил.

Может тут кто подскажет?

База для хранения access-логов (допустим, nginx).

Комплексных индексов нету. Поэтому получается, что искать могу, например, либо по хосту, либо по периоду времени. Либо по префиксу пути :)

Но даже, например, поиск за промежуток времени с выборкой тыщи строк и сортировкой уходит подумать на минуту-полторы. Я их понимаю, js выполнять для десятка тыщ записей - не быстрая работа. Тот же запрос, без JS отрабатывает очень быстро, но нафига он мне нужен, если больше чем по одному полю выбрать надо?

Поделитесь, кто riak юзает, где и как map-reduce используете?

Из разрабов я смог выдавить только то, что map-reduce - не рилтайм ни разу, можно юзать только для offline работы.

AngryElf ★★★★★
()
Ответ на: комментарий от Reset

Это можно обойти, добавлением нового поля 'index-key1-key2: key1-value, key2-value', правда тогда объем данных увеличится.

Блин, а ведь да. А мне и в голову не пришло.

Надо будет еще раз попробовать...

AngryElf ★★★★★
()
Ответ на: комментарий от AngryElf

А в чем смысл логи обрабатывать в real-time? Для логов как раз map-reduce самое оно. Тут же невозможно заранее знать по каким полям тебе нужен индекс, да и поля не постоянны и зависят от поставщиков логов.

Reset ★★★★★
()
Ответ на: комментарий от shimon

NoSQL вообще не бывает, каждая СУБД имеет свои особенности

maxcom ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

Имхо тут задача не для Riak'а. Если хочешь быстрые сложные поиски то смотри в сторону ElasticSearch

maxcom ★★★★★
() автор топика
Ответ на: комментарий от Reset

А в чем смысл логи обрабатывать в real-time? Для логов как раз map-reduce самое оно. Тут же невозможно заранее знать по каким полям тебе нужен индекс, да и поля не постоянны и зависят от поставщиков логов.

Искать по ним надо в реальном времени. Зашел юзер и хочет найти последние запросы по хосту такому-то за последние 3 дня, содержащие такое-то слово. Сейчас это делается грепом, но не очень удобно, так скажем.

С фултекстом я пока разбираюсь, но не очень его хочется, если честно. Запросы у нас обычно четкие, т.е. нужно точное попадание, включая всякие спец-символы, которые токенизатор просто отбросит.

AngryElf ★★★★★
()
Ответ на: комментарий от maxcom

Имхо тут задача не для Riak'а. Если хочешь быстрые сложные поиски то смотри в сторону ElasticSearch

Который lucene, который жава. У меня к ней такая же идиосинкразия, как у кого-то там выше по треду к эрлангу :)

Честно пробовал, но жава меня не любит, не осилил даже инсталляцию.

AngryElf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.