Сальвадор Санфилиппо (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
лучше чем couchdb, кто знает?
Разные решают задачи они
Какие именно разные такие задачи?
> Какие именно разные такие задачи?Скорость против надёжности.
>> Какие именно разные такие задачи?
> Скорость против надёжности.Фу блин не туда ответил :)))
Чем лучше SQL-подобных БД ?
Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в секунду". Ни на каком железе.
> Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в
> секунду". Ни на каком железе.А чем тогда SQL ные лучше этого Redisa?
> А чем тогда SQL ные лучше этого Redisa?Транзакциями, реляционностью.
Не такие тормозные на вьюхах, например!
Вы есть говорить чушь, уважаемый. Вы просто не умеете их готовить.Вот человек умеет:
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-a...
Даже до перехода на NoSQL модель работы с MySQL/InnoDB он имел более ста тысяч операций в секунду, обратите внимание. После - все семьсот тысяч. Сравните с цифрами той же обсуждаемой редиски.Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе, типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет меньше, чем Redis, между прочим.
> Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы
> и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе,
> типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет
> меньше, чем Redis, между прочим.Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции. А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора с диском в её конце.
Жёсткий диск не может делать sync быстрее чем крутится его блин. Это просто невозможно физически, головка диска пролетает над сектором всего лишь 7200 / 60 = 120 раз в секунду.
А если Вы будете делать нормальный RAID, то в стоимость стандартного домашнего компьютера за 15К деревянных Вы не уложитесь.
> Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции.
> А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора
> с диском в её конце.Redis тоже не мгновенно на диск данные сбрасывает.
Смысл поста был в том, что если вам очень хочется использовать нормальную СУБД в том стиле, в котором обычно используют NoSQL, то это возможно, и скорости будут вполне сравнимые. И просто "скоростью" не является достаточным ответом на вопрос "Чем лучше SQL-подобных БД?".
> Redis тоже не мгновенно на диск данные сбрасывает.Разве у Redis это не асинхронно происходит? У него же нет транзакций в понимании реляционных СУБД, поэтому ему не нужно блокировать работу в ожидании ответа диска, он просто пишет в память, отсюда высокая скорость и отсутствие гарантий целостности при аварии.
Если же Вы включите журнал в режиме "fsync every time a new command is appended to the AOF. Very very slow, very safe.", то получите теже 120 sync'ов в секунду на стандартном диске (Very very slow). Чудес то не бывает.
У редис есть append-only журнал, аналог журналов реляционных СУБД. И точно так же, как и у мускуля и постгреса fync вызывается не после каждой транзакции, и целостность данных у всех названных решений идентична (если не учитывать возможные ошибки в реализации, естественно). Способ дальнейшего повышения надежности - построение кластера.
Вы принципиально не читаете статьи, на которые ссылаетесь?.. В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз). Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе. Плюс еще стоит вспомнить про компактное хранение данных. Это третье. А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...
> Вы принципиально не читаете статьи, на которые ссылаетесь?..А Вы принципиально не читаете сообщения, на которые отвечаете? :)
> В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз).
А вот не рассказывайте сказки. Просто апдейты тоже надо уметь писать, и таблицы нормально проектировать. Именно что во избежание блокировок. На своих задачах с getset я получил отставание постгреса от редиса всего в полтора раза. При этом в редисе это один getset, а в постгресе селект+апдейт.
> Как правило, чтобы в БД были данные, их туда нужно писать... Это первое.
Кто бы спорил.
> Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе.
И тут спорить не буду, редис в такой ситуации не тестировал.
> Плюс еще стоит вспомнить про компактное хранение данных. Это третье.
А вот тут редис и сливает постгресу и мускулу. Потому как не знает никаких типов данных. На моих задачах редис проигрывает тому же постгресу в три раза по потреблению памяти, потому как не умеет integer.
> А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...
Да нет, что Вы, мы все с удовольствием почитаем. Вы в четвёртом пункте своей разгромной речи наконец-то стали говорить о реальных, а не маркетоидных преимуществах. И Вы такой первый во всём обсуждении. По четвёртому пункту с моей стороны никаких возражений не будет.
Ещё раз. Всё, что я хотел сказать: просто "скоростью", как было написано выше, не является достаточно полным ответом на вопрос "Чем сабж лучше SQL-подобных БД?". Скорее наоборот, вводит в заблуждение. А фраза про недостижимость цифры в десятки тысяч транзакций на классических СУБД и вовсе неверна.
>> Плюс еще стоит вспомнить про компактное хранение данных. Это третье.
> А вот тут редис и сливает постгресу и мускулу. Потому как не
> знает никаких типов данных. На моих задачах редис проигрывает тому же
> постгресу в три раза по потреблению памяти, потому как не умеет
> integer.Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация конкретно моего случая. Что ж, попробуем, посмотрим.
> Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация
> конкретно моего случая. Что ж, попробуем, посмотрим.Еще рекомендуется 32-бит сборку ставить на 64-бит систему, экономия памяти выходит существенная.
Что касается апдейтов в реляционных СУБД, все не так весело, как вы говорите. Например, при вставке записей в таблицу даже с относительно небольшим количеством записей (десятки миллионов), время на обновление индексов сильно возрастает. Когда многие выборки идут по недавно добавленным записям, то и тысячи транзакций в секунду становятся недостижимым результатом. В постгресе из-за версионности записей при наличии продолжительных транзакций начинает быстро накапливаться "мусор" и размер таблицы и индексов резко увеличивается. Разумеется, есть способы борьбы с такими явлениями, но скорость работы все равно значительно снижается плюс требуется регулярное администрирование. Есть и другие проблемы. В случае, когда поддержка SQL не требуется, к чему платить за нее такую цену?...
>Чем лучше SQL-подобных БД ?проще => меньше ошибок, быстрее работает в качестве операционной БД
вообще говоря стоит наверное рассмотреть хранилище данных, где NoSQL, как операционная БД, а с SQL аналитическая.
Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности. Когда любая сраная доска объявлений или платёжная система хочет всех юзеров захапать себе и стать монополистом. И начинаются наполеоновские планы: построим свой дата-центр, будет у нас 100 серваков под базу данных, и всё масштабируется, во круть-то! А юзерам оно зачем? Мне лично всё равно, на каком сервере находятся почтовые ящики моих корреспондентов, например, или их жаббер-аккаунты. И весь интернет изначально так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие. И изначально весь мир так устроен. Как только любая система становится слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились, поделом им. И гугль с фейсбуком та же судьба ждёт рано или поздно, с их имперскими амбициями. Так что у меня к этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал, зачем оно может понадобиться мне на десктопе или на сервере в маленькой компании, и так и не придумал. Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж - сиюминутное нишевое решение для буржуев, лол.
>[оверквотинг удален]
> так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие.
> И изначально весь мир так устроен. Как только любая система становится
> слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились,
> поделом им. И гугль с фейсбуком та же судьба ждёт рано
> или поздно, с их имперскими амбициями. Так что у меня к
> этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал,
> зачем оно может понадобиться мне на десктопе или на сервере в
> маленькой компании, и так и не придумал. Давайте лучше развивать P2P
> и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж
> - сиюминутное нишевое решение для буржуев, лол.Бери и развивай, только по причине того что ты аноним, фигу ты что сделаешь ;)
спрашиваю, как аноним анонима, а вы с веб проектов денег не зарабатываете? а я зарабатываю, и работаю (как сейчас модно) с хайлоад проектами, и редис юзаю, и рад релизу до жопы.
У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.
> У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.а вот если у вас будет больше клиентов, чем вы можете обслужить - вы не станете нанимать людей (это таже масштабируемость)? вроде как пусть люди идут к другим? сомневаюсь. так что не совсем понятно откуда вся это ненависть к затее с масштабируемостью.
Как-то меня звали на работу в одну платёжную систему, ну, у которой терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то у нас было всего 3 сотрудника и 10 терминалов, а сейчас у нас 20 сотрудников и 200 терминалов в двух городах, и мы продолжаем расти!" Я его спрашиваю: а кому от этого стало лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы мне, наверно, сейчас $60000 в год предложите, раз у вас такая преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. Чего-то я, наверно, не понимаю.
> Как-то меня звали на работу в одну платёжную систему, ну, у которой
> терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то
> у нас было всего 3 сотрудника и 10 терминалов, а сейчас
> у нас 20 сотрудников и 200 терминалов в двух городах, и
> мы продолжаем расти!" Я его спрашиваю: а кому от этого стало
> лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы
> мне, наверно, сейчас $60000 в год предложите, раз у вас такая
> преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить.
> Чего-то я, наверно, не понимаю.200 терминалов это очень мало для платежной системы. У ныне покойного Pegas Pay было около 1000, при том, что особо с ним никто не хотел работать из-за стукнутой на голову финдиректорши
Ну во первых, стукнутая финдиректорша , самый главный владелец компании, а во вторых на сколько я знаю, если б не она, где б были твои познания. И pegas pay не покойник, между прочем.
> Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ
> НАГРУЗКАМИ - как правило, от жадности.Действительно, сервера в большом количестве - сцуко дорогое удовольствие. И если некая технология позволяет уменьщить количество потребных серверов в разы - PROFIT очевиден :)
> Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее
Одно другому не мешает. Кстати, большинство DHT являются всего лишь большой базой ключ-значение, раскиданной на всех. В силу распределенности оно спокойно живет с МИЛЛИОНАМИ одновременных операций поиска, вставки и чего там еще и это даже никому ничего не стоит толком :)
> МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадностиЭто у тебя может быть от жадности, а у других 700 миллионов просмотров в месяц.
Ну так всё-равно скажите, чем Redis лучше couchdb? Я интересуюсь, а не усмехаюсь....