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)

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

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

Ну и, опять-таки, тут фултекст, а мне он не совсем подходит. Мне б индекс по двум-трем колонкам + like матчинг по еще одной. Сейчас юзаем просто mysql, но он загибается под нагрузкой.

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

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

Токенизатор/стеммер там выключается; запросы по диапазону значений (дат/чисел) реализованы довольно эффективно

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

Токенизатор/стеммер там выключается; запросы по диапазону значений (дат/чисел) реализованы довольно эффективно

Это ты про lucene или riak?

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

только ведь nosql ниже уровнем

Ничего подобного. NoSQL предметно ориентирован - он решает специализированные задачи. Он более высокоуровневый, просто не обладает всем набором фич SQL. Например expire в Redis вполне себе высокоуровневая конструкция не доступная в SQL (хотя ее можно реализовать, но это не такая тривиальная задача, да и производительность с учетом «дефрагментации» таблиц будет страдать.

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

За деньги это не интересно. За деньги мы и сами сделаем.

Вперёд и с песней. Можешь еще выложить потом под GPL3.

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

Постгрес на 65000 строках будет думать так, что устанешь ждать?

Что-то не понял что вы ругаете: выборка в монго по запросу не по индексу может занять несколько секунд или даже минут (если всего записей несколько миллионов) - да, правда. Ибо концепция иная, в отличие от субд и других баз (некоторые кэшируют сразу нескольк результатов, а то и все сразу): скан -> проверка -> выдача результата -> скан -> проверка и т.д. В некоторых случаях, таких как, кол-во нужных записей более 90%, а общий размер не велик, возможно, удобней делать выборку на стороне клиента: запрос в бд без уточнения. В таком случае, ваши 65к из скажем 70к легко вычислит клиент за доли секунды. Однако, понятно, что такое возможно в исключительных ситуациях, а там где необходим быстрый поиск - увы, без индексов не обойтись, даже в субд. Я вообще слабо представляю какие приложение вы пишите, если индексы для вас ничто :)

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

Прочитайте уже тред? Там речь была не про минуты, мы просто не сумели дождаться - надоело. Это раз. Рассказывать мне про концепции не нужно, я с ними знаком. Индексов в то время риак ещё не умел, это тоже в треде отмечено.

Binary ★★★★★
()

Глючное падучее поделие. А поддержка есть только у коммерческой версии по цене 6 килобаксов за ноду.

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

Человек написал про то, что сабж может просто зависнуть по-тихому. И в целом он прав.

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