URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 74960
[ Назад ]

Исходное сообщение
"Релиз БД Redis 2.2"

Отправлено opennews , 24-Фев-11 14:20 
Сальвадор Санфилиппо (Salvatore Sanfilippo), работающий в компании VMWare, представил (http://twitter.com/antirez/status/40103885683040256) новую стабильную ветку БД Redis 2.2 (http://redis.io/). Redis относится к классу NoSQL-систем, предоставляя похожие на Memcached функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества.  Для управления данными поддерживаются такие команды, как инкремент/декремент, стандартные операции над списками и множествами (объединение, пересечение), переименование ключей, множественные выборки и функции сортировки. Исходные тексты проекта распространяются в рамках лицензии BSD. Клиентские библиотеки доступны для большинства популярных языков, включая Perl, Python, PHP, Java, Ruby и Tcl.

В отличие от Memcached, Redis обеспечивает постоянное хранение данных на диске и гарантирует сохранность БД в случае аварийного завершения работы. Поддерживается два режима хранения...

URL: http://twitter.com/antirez/status/40103885683040256
Новость: http://www.opennet.me/opennews/art.shtml?num=29702


Содержание

Сообщения в этом обсуждении
"Релиз БД Redis 2.2"
Отправлено _v_s_g_ , 24-Фев-11 14:20 
лучше чем couchdb, кто знает?

"Релиз БД Redis 2.2"
Отправлено ученик_йоды , 24-Фев-11 14:29 
Разные решают задачи они

"Релиз БД Redis 2.2"
Отправлено _v_s_g_ , 24-Фев-11 16:04 
Какие именно разные такие задачи?

"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 17:00 
> Какие именно разные такие задачи?

Скорость против надёжности.


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 17:02 
>> Какие именно разные такие задачи?
> Скорость против надёжности.

Фу блин не туда ответил :)))


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 14:28 
Чем лучше SQL-подобных БД ?

"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 14:44 
Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в секунду". Ни на каком железе.

"Релиз БД Redis 2.2"
Отправлено Игнат , 24-Фев-11 15:10 
> Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в
> секунду". Ни на каком железе.

А чем тогда SQL ные лучше этого Redisa?


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:36 
> А чем тогда SQL ные лучше этого Redisa?

Транзакциями, реляционностью.


"Релиз БД Redis 2.2"
Отправлено _v_s_g_ , 24-Фев-11 16:05 
Не такие тормозные на вьюхах, например!

"Релиз БД Redis 2.2"
Отправлено Anonymousmouse , 24-Фев-11 15:22 
Вы есть говорить чушь, уважаемый. Вы просто не умеете их готовить.

Вот человек умеет:
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-a...
Даже до перехода на NoSQL модель работы с MySQL/InnoDB он имел более ста тысяч операций в секунду, обратите внимание. После - все семьсот тысяч. Сравните с цифрами той же обсуждаемой редиски.

Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе, типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет меньше, чем Redis, между прочим.


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:47 
> Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы
> и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе,
> типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет
> меньше, чем Redis, между прочим.

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

Жёсткий диск не может делать sync быстрее чем крутится его блин. Это просто невозможно физически, головка диска пролетает над сектором всего лишь 7200 / 60 = 120 раз в секунду.

А если Вы будете делать нормальный RAID, то в стоимость стандартного домашнего компьютера за 15К деревянных Вы не уложитесь.


"Релиз БД Redis 2.2"
Отправлено Anonymousmouse , 24-Фев-11 15:53 
> Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции.
> А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора
> с диском в её конце.

Redis тоже не мгновенно на диск данные сбрасывает.
Смысл поста был в том, что если вам очень хочется использовать нормальную СУБД в том стиле, в котором обычно используют NoSQL, то это возможно, и скорости будут вполне сравнимые. И просто "скоростью" не является достаточным ответом на вопрос "Чем лучше SQL-подобных БД?".


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 16:10 
> Redis тоже не мгновенно на диск данные сбрасывает.

Разве у Redis это не асинхронно происходит? У него же нет транзакций в понимании реляционных СУБД, поэтому ему не нужно блокировать работу в ожидании ответа диска, он просто пишет в память, отсюда высокая скорость и отсутствие гарантий целостности при аварии.

Если же Вы включите журнал в режиме "fsync every time a new command is appended to the AOF. Very very slow, very safe.", то получите теже 120 sync'ов в секунду на стандартном диске (Very very slow). Чудес то не бывает.


"Релиз БД Redis 2.2"
Отправлено Veter , 25-Фев-11 00:51 
У редис есть append-only журнал, аналог журналов реляционных СУБД. И точно так же, как и у мускуля и постгреса fync вызывается не после каждой транзакции, и целостность данных у всех названных решений идентична (если не учитывать возможные ошибки в реализации, естественно). Способ дальнейшего повышения надежности - построение кластера.

"Релиз БД Redis 2.2"
Отправлено Veter , 25-Фев-11 00:44 
Вы принципиально не читаете статьи, на которые ссылаетесь?.. В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз). Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе. Плюс еще стоит вспомнить про компактное хранение данных. Это третье. А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...

"Релиз БД Redis 2.2"
Отправлено Anonymousmouse , 25-Фев-11 03:25 
> Вы принципиально не читаете статьи, на которые ссылаетесь?..

А Вы принципиально не читаете сообщения, на которые отвечаете? :)

> В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз).

А вот не рассказывайте сказки. Просто апдейты тоже надо уметь писать, и таблицы нормально проектировать. Именно что во избежание блокировок. На своих задачах с getset я получил отставание постгреса от редиса всего в полтора раза. При этом в редисе это один getset, а в постгресе селект+апдейт.

> Как правило, чтобы в БД были данные, их туда нужно писать... Это первое.

Кто бы спорил.

> Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе.

И тут спорить не буду, редис в такой ситуации не тестировал.

> Плюс еще стоит вспомнить про компактное хранение данных. Это третье.

А вот тут редис и сливает постгресу и мускулу. Потому как не знает никаких типов данных. На моих задачах редис проигрывает тому же постгресу в три раза по потреблению памяти, потому как не умеет integer.

>  А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...

Да нет, что Вы, мы все с удовольствием почитаем. Вы в четвёртом пункте своей разгромной речи наконец-то стали говорить о реальных, а не маркетоидных преимуществах. И Вы такой первый во всём обсуждении. По четвёртому пункту с моей стороны никаких возражений не будет.

Ещё раз. Всё, что я хотел сказать: просто "скоростью", как было написано выше, не является достаточно полным ответом на вопрос "Чем сабж лучше SQL-подобных БД?". Скорее наоборот, вводит в заблуждение. А фраза про недостижимость цифры в десятки тысяч транзакций на классических СУБД и вовсе неверна.


"Релиз БД Redis 2.2"
Отправлено Anonymousmouse , 25-Фев-11 14:49 
>> Плюс еще стоит вспомнить про компактное хранение данных. Это третье.
> А вот тут редис и сливает постгресу и мускулу. Потому как не
> знает никаких типов данных. На моих задачах редис проигрывает тому же
> постгресу в три раза по потреблению памяти, потому как не умеет
> integer.

Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация конкретно моего случая. Что ж, попробуем, посмотрим.


"Релиз БД Redis 2.2"
Отправлено Veter , 25-Фев-11 15:42 
> Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация
> конкретно моего случая. Что ж, попробуем, посмотрим.

Еще рекомендуется 32-бит сборку ставить на 64-бит систему, экономия памяти выходит существенная.

Что касается апдейтов в реляционных СУБД, все не так весело, как вы говорите. Например, при вставке записей в таблицу даже с относительно небольшим количеством записей (десятки миллионов), время на обновление индексов сильно возрастает. Когда многие выборки идут по недавно добавленным записям, то и тысячи транзакций в секунду становятся недостижимым результатом. В постгресе из-за версионности записей при наличии продолжительных транзакций начинает быстро накапливаться "мусор" и размер таблицы и индексов резко увеличивается. Разумеется, есть способы борьбы с такими явлениями, но скорость работы все равно значительно снижается плюс требуется регулярное администрирование. Есть и другие проблемы. В случае, когда поддержка SQL не требуется, к чему платить за нее такую цену?...


"Релиз БД Redis 2.2"
Отправлено Аноним , 25-Фев-11 11:37 
>Чем лучше SQL-подобных БД ?

проще => меньше ошибок, быстрее работает в качестве операционной БД

вообще говоря стоит наверное рассмотреть хранилище данных, где NoSQL, как операционная БД, а с SQL аналитическая.


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:13 
Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности. Когда любая сраная доска объявлений или платёжная система хочет всех юзеров захапать себе и стать монополистом. И начинаются наполеоновские планы: построим свой дата-центр, будет у нас 100 серваков под базу данных, и всё масштабируется, во круть-то! А юзерам оно зачем? Мне лично всё равно, на каком сервере находятся почтовые ящики моих корреспондентов, например, или их жаббер-аккаунты. И весь интернет изначально так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие. И изначально весь мир так устроен. Как только любая система становится слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились, поделом им. И гугль с фейсбуком та же судьба ждёт рано или поздно, с их имперскими амбициями. Так что у меня к этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал, зачем оно может понадобиться мне на десктопе или на сервере в маленькой компании, и так и не придумал. Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж - сиюминутное нишевое решение для буржуев, лол.

"Релиз БД Redis 2.2"
Отправлено исчо_адын_аноним , 24-Фев-11 15:17 
>[оверквотинг удален]
> так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие.
> И изначально весь мир так устроен. Как только любая система становится
> слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились,
> поделом им. И гугль с фейсбуком та же судьба ждёт рано
> или поздно, с их имперскими амбициями. Так что у меня к
> этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал,
> зачем оно может понадобиться мне на десктопе или на сервере в
> маленькой компании, и так и не придумал. Давайте лучше развивать P2P
> и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж
> - сиюминутное нишевое решение для буржуев, лол.

Бери и развивай, только по причине того что ты аноним, фигу ты что сделаешь ;)


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:27 
спрашиваю, как аноним анонима, а вы с веб проектов денег не зарабатываете? а я зарабатываю, и работаю (как сейчас модно) с хайлоад проектами, и редис юзаю, и рад релизу до жопы.

"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:34 
У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.

"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:46 
> У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.

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


"Релиз БД Redis 2.2"
Отправлено Аноним , 24-Фев-11 15:34 
Как-то меня звали на работу в одну платёжную систему, ну, у которой терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то у нас было всего 3 сотрудника и 10 терминалов, а сейчас у нас 20 сотрудников и 200 терминалов в двух городах, и мы продолжаем расти!" Я его спрашиваю: а кому от этого стало лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы мне, наверно, сейчас $60000 в год предложите, раз у вас такая преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. Чего-то я, наверно, не понимаю.

"Релиз БД Redis 2.2"
Отправлено FilimoniC , 25-Фев-11 11:02 
> Как-то меня звали на работу в одну платёжную систему, ну, у которой
> терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то
> у нас было всего 3 сотрудника и 10 терминалов, а сейчас
> у нас 20 сотрудников и 200 терминалов в двух городах, и
> мы продолжаем расти!" Я его спрашиваю: а кому от этого стало
> лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы
> мне, наверно, сейчас $60000 в год предложите, раз у вас такая
> преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить.
> Чего-то я, наверно, не понимаю.

200 терминалов это очень мало для платежной системы. У ныне покойного Pegas Pay было около 1000, при том, что особо с ним никто не хотел работать из-за стукнутой на голову финдиректорши


"Релиз БД Redis 2.2"
Отправлено pegas , 22-Окт-13 08:40 
Ну во первых, стукнутая финдиректорша , самый главный владелец компании, а во вторых на сколько я знаю, если б не она, где б были твои познания. И pegas pay не покойник, между прочем.

"Релиз БД Redis 2.2"
Отправлено User294 , 24-Фев-11 15:35 
> Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ
> НАГРУЗКАМИ - как правило, от жадности.

Действительно, сервера в большом количестве - сцуко дорогое удовольствие. И если некая технология позволяет уменьщить количество потребных серверов в разы - PROFIT очевиден :)

> Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее

Одно другому не мешает. Кстати, большинство DHT являются всего лишь большой базой ключ-значение, раскиданной на всех. В силу распределенности оно спокойно живет с МИЛЛИОНАМИ одновременных операций поиска, вставки и чего там еще и это даже никому ничего не стоит толком :)


"Релиз БД Redis 2.2"
Отправлено uF0 , 24-Фев-11 17:20 
> МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности

Это у тебя может быть от жадности, а у других 700 миллионов просмотров в месяц.


"Релиз БД Redis 2.2"
Отправлено _v_s_g_ , 24-Фев-11 16:02 
Ну так всё-равно скажите, чем Redis лучше couchdb? Я интересуюсь, а не усмехаюсь....