| |
| |
| |
| |
| 5.25, Аноним (-), 17:02, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Какие именно разные такие задачи?
> Скорость против надёжности.
Фу блин не туда ответил :)))
| | |
|
|
|
|
| |
| 2.4, Аноним (-), 14:44, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в секунду". Ни на каком железе.
| | |
| |
| 3.6, Игнат (?), 15:10, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Скоростью. RDBMS не в состоянии работать в темпе "десятки тысяч транзакций в
> секунду". Ни на каком железе.
А чем тогда SQL ные лучше этого Redisa?
| | |
| |
| 4.15, Аноним (-), 15:36, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> А чем тогда SQL ные лучше этого Redisa?
Транзакциями, реляционностью.
| | |
|
| 3.10, Anonymousmouse (?), 15:22, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Вы есть говорить чушь, уважаемый. Вы просто не умеете их готовить.
Вот человек умеет:
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for
Даже до перехода на NoSQL модель работы с MySQL/InnoDB он имел более ста тысяч операций в секунду, обратите внимание. После - все семьсот тысяч. Сравните с цифрами той же обсуждаемой редиски.
Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе, типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет меньше, чем Redis, между прочим.
| | |
| |
| 4.17, Аноним (-), 15:47, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Могу также расказать, что цифры в 50К запросов в секунду вполне достижимы
> и с MySQL, и с PostgreSQL, даже на довольно дешёвом железе,
> типа стандартного домашнего компьютера за 15К деревянных. И памяти есть будет
> меньше, чем Redis, между прочим.
Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции. А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора с диском в её конце.
Жёсткий диск не может делать sync быстрее чем крутится его блин. Это просто невозможно физически, головка диска пролетает над сектором всего лишь 7200 / 60 = 120 раз в секунду.
А если Вы будете делать нормальный RAID, то в стоимость стандартного домашнего компьютера за 15К деревянных Вы не уложитесь.
| | |
| |
| 5.18, Anonymousmouse (?), 15:53, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Транзакций или запросов? Количество запросов никому не интересно, интересуют транзакции.
> А пишущая транзакция - это обязательная синхронизация хотя бы одного сектора
> с диском в её конце.
Redis тоже не мгновенно на диск данные сбрасывает.
Смысл поста был в том, что если вам очень хочется использовать нормальную СУБД в том стиле, в котором обычно используют NoSQL, то это возможно, и скорости будут вполне сравнимые. И просто "скоростью" не является достаточным ответом на вопрос "Чем лучше SQL-подобных БД?".
| | |
| |
| 6.23, Аноним (-), 16:10, 24/02/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Redis тоже не мгновенно на диск данные сбрасывает.
Разве у Redis это не асинхронно происходит? У него же нет транзакций в понимании реляционных СУБД, поэтому ему не нужно блокировать работу в ожидании ответа диска, он просто пишет в память, отсюда высокая скорость и отсутствие гарантий целостности при аварии.
Если же Вы включите журнал в режиме "fsync every time a new command is appended to the AOF. Very very slow, very safe.", то получите теже 120 sync'ов в секунду на стандартном диске (Very very slow). Чудес то не бывает.
| | |
| |
| 7.28, Veter (??), 00:51, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
У редис есть append-only журнал, аналог журналов реляционных СУБД. И точно так же, как и у мускуля и постгреса fync вызывается не после каждой транзакции, и целостность данных у всех названных решений идентична (если не учитывать возможные ошибки в реализации, естественно). Способ дальнейшего повышения надежности - построение кластера.
| | |
|
|
|
| 4.27, Veter (??), 00:44, 25/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы принципиально не читаете статьи, на которые ссылаетесь?.. В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз). Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе. Плюс еще стоит вспомнить про компактное хранение данных. Это третье. А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...
| | |
| |
| |
| 6.32, Anonymousmouse (?), 14:49, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Плюс еще стоит вспомнить про компактное хранение данных. Это третье.
> А вот тут редис и сливает постгресу и мускулу. Потому как не
> знает никаких типов данных. На моих задачах редис проигрывает тому же
> постгресу в три раза по потреблению памяти, потому как не умеет
> integer.
Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация конкретно моего случая. Что ж, попробуем, посмотрим.
| | |
| |
| 7.33, Veter (??), 15:42, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация
> конкретно моего случая. Что ж, попробуем, посмотрим.
Еще рекомендуется 32-бит сборку ставить на 64-бит систему, экономия памяти выходит существенная.
Что касается апдейтов в реляционных СУБД, все не так весело, как вы говорите. Например, при вставке записей в таблицу даже с относительно небольшим количеством записей (десятки миллионов), время на обновление индексов сильно возрастает. Когда многие выборки идут по недавно добавленным записям, то и тысячи транзакций в секунду становятся недостижимым результатом. В постгресе из-за версионности записей при наличии продолжительных транзакций начинает быстро накапливаться "мусор" и размер таблицы и индексов резко увеличивается. Разумеется, есть способы борьбы с такими явлениями, но скорость работы все равно значительно снижается плюс требуется регулярное администрирование. Есть и другие проблемы. В случае, когда поддержка SQL не требуется, к чему платить за нее такую цену?...
| | |
|
|
|
|
|
| 2.31, Аноним (-), 11:37, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Чем лучше SQL-подобных БД ?
проще => меньше ошибок, быстрее работает в качестве операционной БД
вообще говоря стоит наверное рассмотреть хранилище данных, где NoSQL, как операционная БД, а с SQL аналитическая.
| | |
|
| 1.8, Аноним (-), 15:13, 24/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности. Когда любая сраная доска объявлений или платёжная система хочет всех юзеров захапать себе и стать монополистом. И начинаются наполеоновские планы: построим свой дата-центр, будет у нас 100 серваков под базу данных, и всё масштабируется, во круть-то! А юзерам оно зачем? Мне лично всё равно, на каком сервере находятся почтовые ящики моих корреспондентов, например, или их жаббер-аккаунты. И весь интернет изначально так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие. И изначально весь мир так устроен. Как только любая система становится слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились, поделом им. И гугль с фейсбуком та же судьба ждёт рано или поздно, с их имперскими амбициями. Так что у меня к этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал, зачем оно может понадобиться мне на десктопе или на сервере в маленькой компании, и так и не придумал. Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж - сиюминутное нишевое решение для буржуев, лол.
| | |
| |
| 2.9, исчо_адын_аноним (?), 15:17, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> так устроен, когда один сервер перестаёт справляться с нагрузкой, появляются другие.
> И изначально весь мир так устроен. Как только любая система становится
> слишком большой, рядом вырастают другие. Так динозавры вымерли и империи развалились,
> поделом им. И гугль с фейсбуком та же судьба ждёт рано
> или поздно, с их имперскими амбициями. Так что у меня к
> этому хайпу вокруг NoSQL и горизонтальной масштабируемости сложное отношение. Долго думал,
> зачем оно может понадобиться мне на десктопе или на сервере в
> маленькой компании, и так и не придумал. Давайте лучше развивать P2P
> и всякие децентрализованные штуки, вот за ними реальное будущее, а сабж
> - сиюминутное нишевое решение для буржуев, лол.
Бери и развивай, только по причине того что ты аноним, фигу ты что сделаешь ;)
| | |
| 2.11, Аноним (-), 15:27, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
спрашиваю, как аноним анонима, а вы с веб проектов денег не зарабатываете? а я зарабатываю, и работаю (как сейчас модно) с хайлоад проектами, и редис юзаю, и рад релизу до жопы.
| | |
| |
| 3.13, Аноним (-), 15:34, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.
| | |
| |
| 4.16, Аноним (-), 15:46, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> У меня старорежимная компания, поставляет готовый софт, зарабатывает на поддержке.
а вот если у вас будет больше клиентов, чем вы можете обслужить - вы не станете нанимать людей (это таже масштабируемость)? вроде как пусть люди идут к другим? сомневаюсь. так что не совсем понятно откуда вся это ненависть к затее с масштабируемостью.
| | |
|
|
| 2.12, Аноним (-), 15:34, 24/02/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Как-то меня звали на работу в одну платёжную систему, ну, у которой терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то у нас было всего 3 сотрудника и 10 терминалов, а сейчас у нас 20 сотрудников и 200 терминалов в двух городах, и мы продолжаем расти!" Я его спрашиваю: а кому от этого стало лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы мне, наверно, сейчас $60000 в год предложите, раз у вас такая преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. Чего-то я, наверно, не понимаю.
| | |
| |
| 3.30, FilimoniC (?), 11:02, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Как-то меня звали на работу в одну платёжную систему, ну, у которой
> терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то
> у нас было всего 3 сотрудника и 10 терминалов, а сейчас
> у нас 20 сотрудников и 200 терминалов в двух городах, и
> мы продолжаем расти!" Я его спрашиваю: а кому от этого стало
> лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы
> мне, наверно, сейчас $60000 в год предложите, раз у вас такая
> преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить.
> Чего-то я, наверно, не понимаю.
200 терминалов это очень мало для платежной системы. У ныне покойного Pegas Pay было около 1000, при том, что особо с ним никто не хотел работать из-за стукнутой на голову финдиректорши
| | |
| |
| 4.34, pegas (??), 08:40, 22/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Ну во первых, стукнутая финдиректорша , самый главный владелец компании, а во вторых на сколько я знаю, если б не она, где б были твои познания. И pegas pay не покойник, между прочем.
| | |
|
|
| 2.14, User294 (ok), 15:35, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Я, может, глупость скажу, но все эти затеи с МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ
> НАГРУЗКАМИ - как правило, от жадности.
Действительно, сервера в большом количестве - сцуко дорогое удовольствие. И если некая технология позволяет уменьщить количество потребных серверов в разы - PROFIT очевиден :)
> Давайте лучше развивать P2P и всякие децентрализованные штуки, вот за ними реальное будущее
Одно другому не мешает. Кстати, большинство DHT являются всего лишь большой базой ключ-значение, раскиданной на всех. В силу распределенности оно спокойно живет с МИЛЛИОНАМИ одновременных операций поиска, вставки и чего там еще и это даже никому ничего не стоит толком :)
| | |
| 2.26, uF0 (?), 17:20, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности
Это у тебя может быть от жадности, а у других 700 миллионов просмотров в месяц.
| | |
|
| 1.20, _v_s_g_ (?), 16:02, 24/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну так всё-равно скажите, чем Redis лучше couchdb? Я интересуюсь, а не усмехаюсь....
| | |
|
