https://www.opennet.ru/openforum/vsluhforumID3/74960.html Сальвадор Санфилиппо (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.<br><br><br><br>В отличие от Memcached, Redis обеспечивает постоянное хранение данных на диске и гарантирует сохранность БД в случае аварийного завершения работы. Поддерживается два режима хранения...<br><br>URL: http://twitter https://www.opennet.ru/openforum/vsluhforumID3/74960.html#34 Tue, 22 Oct 2013 04:40:13 GMT Ну во первых, стукнутая финдиректорша , самый главный владелец компании, а во вторых на сколько я знаю, если б не она, где б были твои познания. И pegas pay не покойник, между прочем. <br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#33 Fri, 25 Feb 2011 12:42:03 GMT &gt; Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация<br>&gt; конкретно моего случая. Что ж, попробуем, посмотрим.<br><br>Еще рекомендуется 32-бит сборку ставить на 64-бит систему, экономия памяти выходит существенная.<br><br>Что касается апдейтов в реляционных СУБД, все не так весело, как вы говорите. Например, при вставке записей в таблицу даже с относительно небольшим количеством записей (десятки миллионов), время на обновление индексов сильно возрастает. Когда многие выборки идут по недавно добавленным записям, то и тысячи транзакций в секунду становятся недостижимым результатом. В постгресе из-за версионности записей при наличии продолжительных транзакций начинает быстро накапливаться "мусор" и размер таблицы и индексов резко увеличивается. Разумеется, есть способы борьбы с такими явлениями, но скорость работы все равно значительно снижается плюс требуется регулярное администрирование. Есть и другие проблемы. В случае, когда поддержка SQL не требуется, к чему платить за нее такую цену?...<br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#32 Fri, 25 Feb 2011 11:49:17 GMT &gt;&gt; Плюс еще стоит вспомнить про компактное хранение данных. Это третье.<br>&gt; А вот тут редис и сливает постгресу и мускулу. Потому как не <br>&gt; знает никаких типов данных. На моих задачах редис проигрывает тому же <br>&gt; постгресу в три раза по потреблению памяти, потому как не умеет <br>&gt; integer.<br><br>Времена меняются. В changelog'е к 2.2 отдельно подчёркнута оптимизация конкретно моего случая. Что ж, попробуем, посмотрим.<br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#31 Fri, 25 Feb 2011 08:37:26 GMT &gt;Чем лучше SQL-подобных БД ?<br><br>проще =&gt; меньше ошибок, быстрее работает в качестве операционной БД<br><br>вообще говоря стоит наверное рассмотреть хранилище данных, где NoSQL, как операционная БД, а с SQL аналитическая.<br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#30 Fri, 25 Feb 2011 08:02:29 GMT &gt; Как-то меня звали на работу в одну платёжную систему, ну, у которой <br>&gt; терминалы в метро. И там на собеседовании мужик такой говорит: "Когда-то <br>&gt; у нас было всего 3 сотрудника и 10 терминалов, а сейчас <br>&gt; у нас 20 сотрудников и 200 терминалов в двух городах, и <br>&gt; мы продолжаем расти!" Я его спрашиваю: а кому от этого стало <br>&gt; лучше? Комиссия за платежи снизилась, или у сотрудников зарплата выросла? Вы <br>&gt; мне, наверно, сейчас $60000 в год предложите, раз у вас такая <br>&gt; преуспевающая компания? А он кряхтит да жмётся, не знает, что ответить. <br>&gt; Чего-то я, наверно, не понимаю.<br><br>200 терминалов это очень мало для платежной системы. У ныне покойного Pegas Pay было около 1000, при том, что особо с ним никто не хотел работать из-за стукнутой на голову финдиректорши<br><br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#29 Fri, 25 Feb 2011 00:25:49 GMT &gt; Вы принципиально не читаете статьи, на которые ссылаетесь?..<br><br>А Вы принципиально не читаете сообщения, на которые отвечаете? :)<br><br>&gt; В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз).<br><br>А вот не рассказывайте сказки. Просто апдейты тоже надо уметь писать, и таблицы нормально проектировать. Именно что во избежание блокировок. На своих задачах с getset я получил отставание постгреса от редиса всего в полтора раза. При этом в редисе это один getset, а в постгресе селект+апдейт.<br><br>&gt; Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. <br><br>Кто бы спорил.<br><br>&gt; Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе https://www.opennet.ru/openforum/vsluhforumID3/74960.html#28 Thu, 24 Feb 2011 21:51:02 GMT У редис есть append-only журнал, аналог журналов реляционных СУБД. И точно так же, как и у мускуля и постгреса fync вызывается не после каждой транзакции, и целостность данных у всех названных решений идентична (если не учитывать возможные ошибки в реализации, естественно). Способ дальнейшего повышения надежности - построение кластера.<br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#27 Thu, 24 Feb 2011 21:44:17 GMT Вы принципиально не читаете статьи, на которые ссылаетесь?.. В названной вами статье есть небольшая ремарка - в случае, если кроме чтения есть и операции модификации, то результат будет совершенно иной. В самом деле, в отсутствие блокировок можно получить красивый результат... но добавка даже небольшого количества апдейтов ухудшает результат на порядки (в 10,100,100,... раз). Как правило, чтобы в БД были данные, их туда нужно писать... Это первое. Второе - редис старается эффективно работать в ситуации, когда БД не помещается в ОЗУ, в то время как мускуль и постгрес в такой ситуации совершенно неэффективны. Это второе. Плюс еще стоит вспомнить про компактное хранение данных. Это третье. А также учесть, что редис предоставляет быстрые выборки элементов списка и множество других операций, которые медленны или вовсе не реализованы в реляционных СУБД. Это четвертое. Можно и продолжить, но смысла нет, раз уж вы не удосужились прочитать названную вами же статью...<br> https://www.opennet.ru/openforum/vsluhforumID3/74960.html#26 Thu, 24 Feb 2011 14:20:57 GMT &gt; МАСШТАБИРУЕМОСТЬЮ и ВЫСОКИМИ НАГРУЗКАМИ - как правило, от жадности<br><br>Это у тебя может быть от жадности, а у других 700 миллионов просмотров в месяц.<br>