форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз БД Redis 2.2"	+/–
Сообщение от opennews on 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.ru/opennews/art.shtml?num=29702
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз БД Redis 2.2"	+3 +/–
Сообщение от _v_s_g_ on 24-Фев-11, 14:20
лучше чем couchdb, кто знает?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Релиз БД Redis 2.2"	+6 +/–
	Сообщение от ученик_йоды on 24-Фев-11, 14:29
	Разные решают задачи они
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	21. "Релиз БД Redis 2.2"	+/–
	Сообщение от _v_s_g_ on 24-Фев-11, 16:04
	Какие именно разные такие задачи?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	24. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 24-Фев-11, 17:00
	> Какие именно разные такие задачи? Скорость против надёжности.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	25. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 24-Фев-11, 17:02
	>> Какие именно разные такие задачи? > Скорость против надёжности. Фу блин не туда ответил :)))
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

2. "Релиз БД Redis 2.2"	–5 +/–
Сообщение от Аноним (??) on 24-Фев-11, 14:28
Чем лучше SQL-подобных БД ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Релиз БД Redis 2.2"	+1 +/–
	Сообщение от Аноним (??) on 24-Фев-11, 14:44
	Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в секунду". Ни на каком железе.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Релиз БД Redis 2.2"	+/–
	Сообщение от Игнат on 24-Фев-11, 15:10
	> Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в > секунду". Ни на каком железе. А чем тогда SQL ные лучше этого Redisa?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:36
	> А чем тогда SQL ные лучше этого Redisa? Транзакциями, реляционностью.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	22. "Релиз БД Redis 2.2"	+/–
	Сообщение от _v_s_g_ on 24-Фев-11, 16:05
	Не такие тормозные на вьюхах, например!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Релиз БД Redis 2.2"	+/–
	Сообщение от Anonymousmouse on 24-Фев-11, 15:22
	Вы есть говорить чушь, уважаемый. Вы просто не умеете их готовить. Вот человек умеет: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-a... Даже до перехода на NoSQL модель работы с MySQL/InnoDB он имел более ста тысяч операций в секунду, обратите внимание. После - все семьсот тысяч. Сравните с цифрами той же обсуждаемой редиски. Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе, типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет меньше, чем Redis, между прочим.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	17. "Релиз БД Redis 2.2"	+1 +/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:47
	> Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы > и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе, > типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет > меньше, чем Redis, между прочим. Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции. А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора с диском в её конце. Жёсткий диск не может делать sync быстрее чем крутится его блин. Это просто невозможно физически, головка диска пролетает над сектором всего лишь 7200 / 60 = 120 раз в секунду. А если Вы будете делать нормальный RAID, то в стоимость стандартного домашнего компьютера за 15К деревянных Вы не уложитесь.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Релиз БД Redis 2.2"	+/–
	Сообщение от Anonymousmouse on 24-Фев-11, 15:53
	> Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции. > А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора > с диском в её конце. Redis тоже не мгновенно на диск данные сбрасывает. Смысл поста был в том, что если вам очень хочется использовать нормальную СУБД в том стиле, в котором обычно используют NoSQL, то это возможно, и скорости будут вполне сравнимые. И просто "скоростью" не является достаточным ответом на вопрос "Чем лучше SQL-подобных БД?".
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	23. "Релиз БД Redis 2.2"	+2 +/–
	Сообщение от Аноним (??) on 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). Чудес то не бывает.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	28. "Релиз БД Redis 2.2"	+/–
	Сообщение от Veter (??) on 25-Фев-11, 00:51
	У редис есть append-only журнал, аналог журналов реляционных СУБД. И точно так же, как и у мускуля и постгреса fync вызывается не после каждой транзакции, и целостность данных у всех названных решений идентична (если не учитывать возможные ошибки в реализации, естественно). Способ дальнейшего повышения надежности - построение кластера.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

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

	29. "Релиз БД Redis 2.2"	–1 +/–
	Сообщение от Anonymousmouse on 25-Фев-11, 03:25
	> Вы принципиально не читаете статьи, на которые ссылаетесь?.. А Вы принципиально не читаете сообщения, на которые отвечаете? :) > В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз). А вот не рассказывайте сказки. Просто апдейты тоже надо уметь писать, и таблицы нормально проектировать. Именно что во избежание блокировок. На своих задачах с getset я получил отставание постгреса от редиса всего в полтора раза. При этом в редисе это один getset, а в постгресе селект+апдейт. > Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. Кто бы спорил. > Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе. И тут спорить не буду, редис в такой ситуации не тестировал. > Плюс еще стоит вспомнить про компактное хранение данных. Это третье. А вот тут редис и сливает постгресу и мускулу. Потому как не знает никаких типов данных. На моих задачах редис проигрывает тому же постгресу в три раза по потреблению памяти, потому как не умеет integer. >  А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью... Да нет, что Вы, мы все с удовольствием почитаем. Вы в четвёртом пункте своей разгромной речи наконец-то стали говорить о реальных, а не маркетоидных преимуществах. И Вы такой первый во всём обсуждении. По четвёртому пункту с моей стороны никаких возражений не будет. Ещё раз. Всё, что я хотел сказать: просто "скоростью", как было написано выше, не является достаточно полным ответом на вопрос "Чем сабж лучше SQL-подобных БД?". Скорее наоборот, вводит в заблуждение. А фраза про недостижимость цифры в десятки тысяч транзакций на классических СУБД и вовсе неверна.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	32. "Релиз БД Redis 2.2"	+/–
	Сообщение от Anonymousmouse on 25-Фев-11, 14:49
	>> Плюс еще стоит вспомнить про компактное хранение данных. Это третье. > А вот тут редис и сливает постгресу и мускулу. Потому как не > знает никаких типов данных. На моих задачах редис проигрывает тому же > постгресу в три раза по потреблению памяти, потому как не умеет > integer. Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация конкретно моего случая. Что ж, попробуем, посмотрим.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	33. "Релиз БД Redis 2.2"	+/–
	Сообщение от Veter (??) on 25-Фев-11, 15:42
	> Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация > конкретно моего случая. Что ж, попробуем, посмотрим. Еще рекомендуется 32-бит сборку ставить на 64-бит систему, экономия памяти выходит существенная. Что касается апдейтов в реляционных СУБД, все не так весело, как вы говорите. Например, при вставке записей в таблицу даже с относительно небольшим количеством записей (десятки миллионов), время на обновление индексов сильно возрастает. Когда многие выборки идут по недавно добавленным записям, то и тысячи транзакций в секунду становятся недостижимым результатом. В постгресе из-за версионности записей при наличии продолжительных транзакций начинает быстро накапливаться "мусор" и размер таблицы и индексов резко увеличивается. Разумеется, есть способы борьбы с такими явлениями, но скорость работы все равно значительно снижается плюс требуется регулярное администрирование. Есть и другие проблемы. В случае, когда поддержка SQL не требуется, к чему платить за нее такую цену?...
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	31. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 25-Фев-11, 11:37
	>Чем лучше SQL-подобных БД ? проще => меньше ошибок, быстрее работает в качестве операционной БД вообще говоря стоит наверное рассмотреть хранилище данных, где NoSQL, как операционная БД, а с SQL аналитическая.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

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

	9. "Релиз БД Redis 2.2"	+/–
	Сообщение от исчо_адын_аноним on 24-Фев-11, 15:17
	>[оверквотинг удален] > так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие. > И изначально весь мир так устроен. Как только любая система становится > слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились, > поделом им. И гугль с фейсбуком та же судьба ждёт рано > или поздно, с их имперскими амбициями. Так что у меня к > этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал, > зачем оно может понадобиться мне на десктопе или на сервере в > маленькой компании, и так и не придумал. Давайте лучше развивать P2P > и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж > - сиюминутное нишевое решение для буржуев, лол. Бери и развивай, только по причине того что ты аноним, фигу ты что сделаешь ;)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Релиз БД Redis 2.2"	+1 +/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:27
	спрашиваю, как аноним анонима, а вы с веб проектов денег не зарабатываете? а я зарабатываю, и работаю (как сейчас модно) с хайлоад проектами, и редис юзаю, и рад релизу до жопы.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	13. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:34
	У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "Релиз БД Redis 2.2"	+/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:46
	> У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке. а вот если у вас будет больше клиентов, чем вы можете обслужить - вы не станете нанимать людей (это таже масштабируемость)? вроде как пусть люди идут к другим? сомневаюсь. так что не совсем понятно откуда вся это ненависть к затее с масштабируемостью.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	12. "Релиз БД Redis 2.2"	+2 +/–
	Сообщение от Аноним (??) on 24-Фев-11, 15:34
	Как-то меня звали на работу в одну платёжную систему, ну, у которой терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то у нас было всего 3 сотрудника и 10 терминалов, а сейчас у нас 20 сотрудников и 200 терминалов в двух городах, и мы продолжаем расти!" Я его спрашиваю: а кому от этого стало лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы мне, наверно, сейчас $60000 в год предложите, раз у вас такая преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. Чего-то я, наверно, не понимаю.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	30. "Релиз БД Redis 2.2"	+/–
	Сообщение от FilimoniC on 25-Фев-11, 11:02
	> Как-то меня звали на работу в одну платёжную систему, ну, у которой > терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то > у нас было всего 3 сотрудника и 10 терминалов, а сейчас > у нас 20 сотрудников и 200 терминалов в двух городах, и > мы продолжаем расти!" Я его спрашиваю: а кому от этого стало > лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы > мне, наверно, сейчас $60000 в год предложите, раз у вас такая > преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. > Чего-то я, наверно, не понимаю. 200 терминалов это очень мало для платежной системы. У ныне покойного Pegas Pay было около 1000, при том, что особо с ним никто не хотел работать из-за стукнутой на голову финдиректорши
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	34. "Релиз БД Redis 2.2"	+/–
	Сообщение от pegas (??) on 22-Окт-13, 08:40
	Ну во первых, стукнутая финдиректорша , самый главный владелец компании, а во вторых на сколько я знаю, если б не она, где б были твои познания. И pegas pay не покойник, между прочем.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	14. "Релиз БД Redis 2.2"	+/–
	Сообщение от User294 (ok) on 24-Фев-11, 15:35
	> Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ > НАГРУЗКАМИ - как правило, от жадности. Действительно, сервера в большом количестве - сцуко дорогое удовольствие. И если некая технология позволяет уменьщить количество потребных серверов в разы - PROFIT очевиден :) > Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее Одно другому не мешает. Кстати, большинство DHT являются всего лишь большой базой ключ-значение, раскиданной на всех. В силу распределенности оно спокойно живет с МИЛЛИОНАМИ одновременных операций поиска, вставки и чего там еще и это даже никому ничего не стоит толком :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	26. "Релиз БД Redis 2.2"	+1 +/–
	Сообщение от uF0 on 24-Фев-11, 17:20
	> МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности Это у тебя может быть от жадности, а у других 700 миллионов просмотров в месяц.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

20. "Релиз БД Redis 2.2"	+/–
Сообщение от _v_s_g_ on 24-Фев-11, 16:02
Ну так всё-равно скажите, чем Redis лучше couchdb? Я интересуюсь, а не усмехаюсь....
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема