Краткий обзор membase — нового NoSQL решения от авторов memcached

[@romka777]

где скачать?

[@FractalizeR]

www.membase.org

[@romka777]

ага, нашёл, спасибо

[@Sannis]

Интересная новость. Разработчики молодцы, интересно только почему это не стали делать как развитие memcached.

[@akalend]

мухи отдельно, котлеты отдельно
разные задачи у них

[@burunduk2]

м-да. по-богатому.
wiki.membase.org/bin/view/Main/MembaseDocumentation

[@Albertum]

В последнее время разработчиков радуют релизами NoSQL решений.

[@corbenov]

[холивар] я так понимаю что они за Redis-ом пытаются угнаться — в нём персистентное хранение уже реализовано и оказалось очень востребованным разработчиками. [/холивар]

[@Zada]

Здесь удобно то, что протокол остается неизменным и в принципе подменить одно на другое — легко.

[@Zada]

Кажеться хорошо, но редис и быстрее, и функциональнее.
Попробовать стоит, хотя за 2 минуты сбилдать не удалось. Не находит скрипта configure.

[@OdobenusRosmarus]

> но редис и быстрее, и функциональнее.

Где то есть бенчмарки, редис против мембазы? Если есть — дайте пожалуйста, я с удовольствием почитаю.

[@Zada]

Redis vs Membase — нет, такого еще не находил, однако Redis vs Memcache есть.
А так как мембаза, это дополнительный обвес к мемкешу, то врядли он будет от этого быстрее.

www.ruturaj.net/redis-memcached-tokyo-tyrant-mysql-comparison
nosql.mypopescu.com/post/392578627/a-very-specific-benchmark-files-vs-mysql-vs-memcached
systoilet.wordpress.com/2010/08/09/redis-vs-memcached/
axonflux.com/redis-vs-memcache-benchmarks-on-a-realistic-m

Результаты этих бенчей, конечно, очень противоречивы, однако…
Лучше самому протестировать. Так как к примеру на Mac OS, Редис, просто тормоз и в виртулке с убунтой на этой же системе, он дает раза в 3-4 лучшие результаты.

[@akalend]

спасибо за ссылки
сам собираюсь сделать бенчмарки редис и мемкеш
правда относительно к очередям

[@akalend]

редис хорош для малых объемов данных
которые помещаются в ОП

[@akuznetsov]

Да только redis пока в кластере не работает. Эту часть дописывать нужно, либо ждать пока реализуют.

[@akzhan]

wiki.membase.org/bin/view/Main/MembaseSource

[@Zada]

Тут лучше сорцы?
Я их и пытался собрать. У вас вышло?

[@akzhan]

Жесть… я чуть позже вас начал и там же остановился )

[@catap]

Я в свое время ее собрал. Счастье так и не стало :)

[@Davert]

Это они просто осваивают новый рынок, сегмент игр для программистов: Закрома Веселого Фермера… =)

[@catap]

Да какая она новая… :)

[@Sartor]

Сколько дурных слов пишут на русском языке! Зачем вы убиваете язык? Можно же обойтись без этих иноземных слов, обойтись обычным русским языком!

По теме: спасибо, обязательно попробую. Интересно бы графики сравнения производительности.

[@Azy]

Тогда рекомендую начать с того что убрать слово «график» из употребления, как иностранное.

[@FractalizeR]

«Компьютер» (англ. computer) и «программирование» (греч. programma) тоже рекомендую убрать :)

[@Sartor]

Не перегибайте палку. Это новые по смыслу слова были для нас. Вы же понимаете, что я имел ввиду.

[@corbenov]

а в каких NoSQL системах существуют транзакции?
«это не баг, это фича» (с)

[@tripiz]

У Redis появились транзакции, можно пачку SET'ов в транзакцию засунуть — так что фича фиче не мешает.

[@FractalizeR]

Многие NoSQL не имеют транзакций потому что

* First, in sharded environments, distributed locks could be expensive and slow. Mongo DB's goal is to be lightweight and fast.
* We dislike the concept of deadlocks. We want the system to be simple and predictable without these sort of surprises.
* We want Mongo DB to work well for realtime problems. If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time. (We don't claim Mongo DB is perfect yet in regards to being «real-time», but we certainly think locking would make it even harder.)

www.mongodb.org/display/DOCS/Atomic+Operations

[@TEHEK]

М… А как у нее с шифрованием и защитой? Или она как мэмкэш не спрашивая принимает и отдает данные?

[@SMiX]

Конечно. В данном продукте это принципиально ненужная функция, потому что авторизация замедлит время ответа.

[@alekciy]

Т.е. выходит, что они сделали к memcached-у писанному на сях обвес в виде «Cluster Manager» писанному на Erlang-е?

[@rPman]

Интересно, в отличии от memcached эта БД гарантирует что данные будут получены если их туда помещали или нет? memcached не гарантирует, а ведь трубуется иногда исключительно memory-based решений (пока redis для этого использую, настроив на очень редкую запись на диск).

[@ikatkov]

интересно, что имеено из FarmVille они хранят в такой базе. Ясно, что профайл игрока и прочую ценную инфу не хранят, тогда что?

[@ikatkov]

а как ясно, что это «те самые» авторы memcached? Вроде Brad Fitzpatrick за ними не стоит? Заголовок для привлечения внимания?

[@kolesnevg]

к слову, FarmVille в последнее время очень даже стабильно работает, еще пол года назад у них были проблемы, возможно это из за падения популярности. Однако стабильно не значит быстро, как раз в последнее время если ферма игрока содержит большое количество объектов… то играть вообще нереально… хотя это уже конечно проблема флэша.

[@maxcom]

насколько я понимаю нет никакой гарантии целостности сохранения на диск?

[@hellroy]

Да. Все делается в ПХП. А что бы не перебирать все записи, для поиска нужной — придется делать аналог индекса таблицы.