Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ты далек от реальности. G>>Есть лишь единицы nosql движков, которые реализуют транзакции, охватывающие несколько запросов. G>>Также есть лишь единицы nosql движков, которые могут делать запросы сложнее, чем выборка по ключу.
_>Во-первых ты опять же не учитываешь модель данных и требования на запросы. К примеру если нам нужны ограничения только по модификации внутри одного документа, то... )))
Я уже третий раз тебе пишу одно и то же. Сегодня ты думаешь что тебе достаточно модификации одного документа, а завтра внезапно становится недостаточно. Все, ты в жопе.
_>Во-вторых во многих таких СУБД имеется реализация CAS, что соответственно позволяет нам сделать эффективную версионность, откаты и т.п. Что может быть даже интереснее банальных транзакций.
Да что ты? Давай покажи как CAS поможет сделать аналог такой операции:
insert into X values(select count(*) from X)
MS SQL позволяет сделать так, чтобы в X не было повтоярющихся значений. Давай вперед с CAS сделай это.
Причем это даже возможно, только надо будет свой transaction log сделать и блокировки. И тормозить это будет дико.
G>>Вот правила вроде "две записи должны добавляться только парой" возникают\меняются по ходу разработки очень часто, а перестраивать схему nosql хранилища каждый раз не представляется возможным. Поэтому можем спокойно считать, что в долгосрочной перспективе почти все nosql движки не умеют делать транзакции. _>Нууу таким проектировщикам действительно не стоит давать в руки подобные инструменты)))
А при чем тут проектировщики? Они не могут угадать потребности бизнеса через год.
Здравствуйте, gandjustas, Вы писали:
g> _>Да, кстати, и два сервера к тому же дают дополнительную надёжность... ) g> Это только при покупке дополнительных мощностей, сверх необходимого.
Если для системы критичен простой, то такие системы всегда строятся с некоторой избыточностью, т.е. запас мощностей всегда выше, нежели реально необходим при штатной нагрузке.
g> Ты удивишься, но все инстансы редиса, которые я видел в продакшене имеют отключенный persistance. Не нужен он там.
Иногда нужен. Например, в случаях, когда кэш долго "прогревается" и быстрее будет поднять его с диска.
g> А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.
Здравствуйте, gandjustas, Вы писали:
_>>Это в какой ценовой категории интересно? ) G>500к-1М рублей
Ууу) На нормальные сервисы (без гигантских sql баз) хватает в 10 раз меньшего)))
_>>Про ресурсы я ничего такого не говорил. Как раз наоборот, nosql БД обычно летают на совсем дохлых серверах. ))) А вот умений программиста с ними действительно надо больше. G>Ты опять сравниваешь точечные замеры? Не понял еще что отсутствие гарантий замедляет систему?
Это при условие, что ты начнёшь их все восстанавливать в своём коде. Однако я уже не раз писал, что они далеко не всегда нужны.
_>>Stackowerflow и т.п. — это старые проекты. Потому и работают на РСУБД. G>Ты думаешьтам такие лоши работают, что если бы были профит от nosql они бы не отказались от sqlserver?
Я думаю, что там нормальные люди, руководствующиеся принципом "работает — не трогай". ) У них же вряд ли намечается какой-то крупный рост нагрузки в ближайшее время. Так с какой стати им тратиться на переход? ) И в большинстве мест всё тоже самое. А вот в стартапах естественно совершенно другой расклад... )
_>>Речь о текущих стартапах (или уже не совсем стартапах)))). G>Вот тебе о стартапах — http://habrahabr.ru/post/231213/ как раз соцсеть с лайками. Прочитай внимательно прежде чем продолжать писать.
Хыхы, я эту ссылку уже несколько раз тут видел. ))) И соответственно обсуждение тоже уже было. )))
G>Ты удивишься, но все инстансы редиса, которые я видел в продакшене имеют отключенный persistance. Не нужен он там. G>А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.
Ну вот, ты оказывается постоянно используешь nosql решение, правда не совсем по назначению. )))
_>>ОК, давай, приведи эту https://community.nodebb.org БД в неконсистентное состояние. ))) G>На каждый пост выполняется около 5 обращений к монге, любое падение и база в неконсистентном состоянии. Кроме того это плохо будет работать с multimaster репликацией, так как при репликации вместо инкремента в базу уходит новое значение и легко потерять значения в счетчике при параллельной записи в два разных мастера. Даже ниче специально делать не нужно, оно само рассинхронизируется. Думаешь почему в монгу добавили autoincrement поля?
Нуу так можно увидеть эту "рассинхронизацию" где-то на практике? ) Или у нас по прежнему одни слова будут? )))
_>>Вообще то прямой по моей ссылке в меню можно было найти живое демо. Но я на всякий случай уже дал прямую ссылку в предыдущем абзаце. ))) G>Еще раз: Покажи живой инстанс с посещяемостью rsdn
А ты думаешь там сильно отличается?) Вот я захожу туда и вижу сообщение оставленное "15 minutes ago", захожу на rsdn и вижу у последнего сообщения "11 мин". И? ) Хотя конечно посещаемость теоретически может быть не пропорциональной "скорости написания сообщений"... Но вряд ли отличие на порядки. )))
_>>Т.е. переводя на русский язык твои кривые намёки, можно сказать, что ты считаешь описанную ситуацию (с преимуществом оптимизации программистами, над заменой железа) редким случаем? ) G>Я считаю, что такое возникает гораздо реже, чем об этом ты пишешь.
Здравствуйте, gandjustas, Вы писали:
G>Я уже третий раз тебе пишу одно и то же. Сегодня ты думаешь что тебе достаточно модификации одного документа, а завтра внезапно становится недостаточно. Все, ты в жопе.
Вот "внезапно" не должно быть у нормального проектировщика. Если есть шанс подобного, то и не надо использовать подобный инструмент. Но во многих случаях общая схема полностью очевидна изначально и в дальнейшем меняется только в мелочах (которые кстати в nosql БД обычно остаются где-то на уровне внутренностей json объектов).
_>>Во-вторых во многих таких СУБД имеется реализация CAS, что соответственно позволяет нам сделать эффективную версионность, откаты и т.п. Что может быть даже интереснее банальных транзакций. G>Да что ты? Давай покажи как CAS поможет сделать аналог такой операции: G>
G>insert into X values(select count(*) from X)
G>
G>MS SQL позволяет сделать так, чтобы в X не было повтоярющихся значений. Давай вперед с CAS сделай это. G>Причем это даже возможно, только надо будет свой transaction log сделать и блокировки. И тормозить это будет дико.
Там делается не журнал транзакций, а просто версия документа, у каждого своя (и хранится всё в самом документе). И соответственно ты можешь легко цепляться за неё. ) Кстати, а собственно этот список Х у нас хранится в разных документах или в одном? ))) А то разница то принципиальная будет... Это в sql базах только один вариант доступен.
Это не говоря уже о дикой искусственности примера. )))
Здравствуйте, Anton Batenev, Вы писали:
g>> А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.
AB>incr/decr.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>incr/decr. g>> Ух ты, видать починили. С 2010 года не использовал memcached.
AB>Что значит "починили"? Оно там с 2003 года (можно сказать с рождения).
А ты коммит-то смотрел?
value = atoi(ptr);
if (incr)
value += delta;
else
{
if (delta >= value) value = 0;
else value -= delta;
}
sprintf(temp, "%u", value);
res = strlen(temp);
if (res + 2 > it->nbytes)
{
/* need to realloc */
item* new_it;
new_it = item_alloc(it->key, it->flags, it->exptime, res + 2);
if (new_it == 0)
{
out_string(c, "SERVER_ERROR out of memory");
return;
}
memcpy(new_it->data, temp, res);
memcpy((char*) (new_it->data) + res, "\r\n", 2);
item_replace(it, new_it);
}
else
{
/* replace in-place */
memcpy(it->data, temp, res);
memset(it->data + res, ' ', it->nbytes - res - 2);
}
Есть подозрение, что он даже в пределах одного компа не атомарный.
Здравствуйте, artelk, Вы писали:
a> А ты коммит-то смотрел? a> Есть подозрение, что он даже в пределах одного компа не атомарный.
В однопоточном режиме атомарный (в те времена особо ресурсами не раскидывались). Потом, конечно же, приделали по нормальному (но у меня никогда не было нужды это проверять на практике).
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, alex_public, Вы писали:
_>Ещё раз повторяюсь. Нам на практике требуется что-то вроде "две записи должны добавляться только парой", а не требование вида "хотим транзакции на любых видах запросов". Так что если для конкретных двух нужных нам запросов тразакции nosql работают, то тот факт, что они не работают на других видах запросов нам абсолютно безразличен.
Отличная фантазия, я её понял. Проблема — в том, что как правило схитрить на том, чтобы поддерживать сериализуемость для пары модификаций, и не поддерживать её для, скажем, трёх модификаций — не получится. Т.е. либо СУБД поддерживает транзакции, либо вы даже добавить две записи парой не сможете никак.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Во-первых ты опять же не учитываешь модель данных и требования на запросы. К примеру если нам нужны ограничения только по модификации внутри одного документа, то... )))
...то никаких транзакций по-прежнему нет. Не надо делать вид, что одна модификация документа — это несколько модификаций. Вы бы ещё написали, что прибавление 10 к значению — это десять операций по прибавлению 1.
Вся проблема — как раз в том, что консистентность за пределами "одного документа" недостижима в этой чудесной модели самообмана.
_>Во-вторых во многих таких СУБД имеется реализация CAS, что соответственно позволяет нам сделать эффективную версионность, откаты и т.п. Что может быть даже интереснее банальных транзакций.
Вы под CAS что понимаете? Сompare-and-swap?
простите, из него ничего "интереснее банальных транзакций" вы не получите. _>Нууу таким проектировщикам действительно не стоит давать в руки подобные инструменты)))
Проблема — не в проектировщиках, а в том, что мир непостоянен. Требования меняются.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Ещё раз повторяюсь. Нам на практике требуется что-то вроде "две записи должны добавляться только парой", а не требование вида "хотим транзакции на любых видах запросов". Так что если для конкретных двух нужных нам запросов тразакции nosql работают, то тот факт, что они не работают на других видах запросов нам абсолютно безразличен. S>Отличная фантазия, я её понял. Проблема — в том, что как правило схитрить на том, чтобы поддерживать сериализуемость для пары модификаций, и не поддерживать её для, скажем, трёх модификаций — не получится. Т.е. либо СУБД поддерживает транзакции, либо вы даже добавить две записи парой не сможете никак.
Речь не о том две записи или три. А о виде запросов.
Здравствуйте, Sinclair, Вы писали:
_>>Во-первых ты опять же не учитываешь модель данных и требования на запросы. К примеру если нам нужны ограничения только по модификации внутри одного документа, то... ))) S>...то никаких транзакций по-прежнему нет. Не надо делать вид, что одна модификация документа — это несколько модификаций. Вы бы ещё написали, что прибавление 10 к значению — это десять операций по прибавлению 1. S>Вся проблема — как раз в том, что консистентность за пределами "одного документа" недостижима в этой чудесной модели самообмана.
Ужас. Надо всё объяснять на пальцах...
Вот смотри, у тебя есть набор значений, который тебе надо менять взаимосвязанно (собственно это и есть "консистентность БД и для этого служат транзакции). Где ты будешь хранить этот набор? В случае реляционных БД у тебя есть ровно один вариант (если не учитывать нестандартные расширения, типа json в PostreSQL) — набор строк в таблице. И соответственно применение транзакций для сохранения инвариантов связанных значений. В случае же nosql БД выбор обычно побогаче. Если взять к примеру упоминаемую тут mongodb, то наш набор значений можно хранить как в виде набор документов (по одному в документе), так и виде массива внутри одного документа. Всё зависит от используемой модели данных. Соответственно во втором случае мы получим автоматическое сохранение наших инвариантов и без всяких транзакций. Это и есть та архитектура, на которую рассчитаны подобные СУБД. Конечно она подходит не для всех моделей данных, а только для тех, в которых имеется слабая связность между документами. Но это как раз хорошо подходит для современного веба, т.к. например легко можно запихать всё, касающееся отдельного пользователя, в один документ и т.п.
_>>Во-вторых во многих таких СУБД имеется реализация CAS, что соответственно позволяет нам сделать эффективную версионность, откаты и т.п. Что может быть даже интереснее банальных транзакций. S>Вы под CAS что понимаете? Сompare-and-swap? S>простите, из него ничего "интереснее банальных транзакций" вы не получите.
CAS — это универсальный подход, позволяющий организовать конкурентный доступ к ресурсу без блокировок. Как на уровне инструкций процессора, так и на уровне БД. Можно организовать и просто корректные параллельные модификации без блокировок и транзакции и полноценную версионность и ещё много чего интересного.
Кстати, вот http://habrahabr.ru/post/153321/ пример прямо на нашу тему. Правда лично я не особо одобряю конкретно этот подход, потому как считаю, что это не правильное использование nosql БД. Правильнее изменить модель данных так, чтобы работали встроенные механизамы (см. первый абзац в сообщение) СУБД. Ну а если нужная модель данных ну совсем не получается (например в случае сильно связанных документов с важными инвариантами), то тогда лучше выбрать другую СУБД (возможно даже реляционную). Однако не смотря на это, как пример использования CAS в БД данная статья вполне подходит. )))
Здравствуйте, alex_public, Вы писали:
_>Вот "внезапно" не должно быть у нормального проектировщика. Если есть шанс подобного, то и не надо использовать подобный инструмент. Но во многих случаях общая схема полностью очевидна изначально и в дальнейшем меняется только в мелочах (которые кстати в nosql БД обычно остаются где-то на уровне внутренностей json объектов).
Ааааа! Я хочу в этот мир!
Здравствуйте, alex_public, Вы писали:
_>Ужас. Надо всё объяснять на пальцах...
Да-да, меня это тоже угнетает.
_>Вот смотри, у тебя есть набор значений, который тебе надо менять взаимосвязанно (собственно это и есть "консистентность БД и для этого служат транзакции). Где ты будешь хранить этот набор? В случае реляционных БД у тебя есть ровно один вариант (если не учитывать нестандартные расширения, типа json в PostreSQL) — набор строк в таблице.
Ну, вообще-то безо всяких нестандартных расширений мне никто не мешает сваливать данные, для которых мне не нужна гранулярность, в поля типа blob. Этой практике уже несколько десятилетий.
_>И соответственно применение транзакций для сохранения инвариантов связанных значений. В случае же nosql БД выбор обычно побогаче.
В случае NoSQL выбор обычно победнее. _> Если взять к примеру упоминаемую тут mongodb, то наш набор значений можно хранить как в виде набор документов (по одному в документе), так и виде массива внутри одного документа. Всё зависит от используемой модели данных. Соответственно во втором случае мы получим автоматическое сохранение наших инвариантов и без всяких транзакций. Это и есть та архитектура, на которую рассчитаны подобные СУБД. Конечно она подходит не для всех моделей данных, а только для тех, в которых имеется слабая связность между документами. Но это как раз хорошо подходит для современного веба, т.к. например легко можно запихать всё, касающееся отдельного пользователя, в один документ и т.п.
Это вполне себе хреново подходит для современного веба, т.к. в нём пользователи работают над контентом совместно. К примеру, в форумный топик контрибутят много людей.
В итоге даже в этой модели, которая предположительно хорошо ложится в убогие ограничения document database, есть проблемы. К примеру, модерирование конкретного поста затрагивает два документа — "документ" пользователя и "документ" топика. Отсутствие транзакций здесь обходится не моделью данных, а моделью отношения к их целостности. Это уровень консистентности "нам пофиг" — ну и что, что убитый из форума пост сохранился в истории пользователя? Это же форум, а не АЭС, никто не умрёт от потерянного или лишнего поста. Всегда можно привелосипедить всякие решения типа "переиндексации", и переобозвать этот уровень консистентности eventual consistence.
А, скажем, систему складского учёта вы навелосипедить на этом не сможете — потому, что там есть то, что вы называете "сильной связностью", и инварианты важны.
_>CAS — это универсальный подход, позволяющий организовать конкурентный доступ к ресурсу без блокировок. Как на уровне инструкций процессора, так и на уровне БД. Можно организовать и просто корректные параллельные модификации без блокировок и транзакции и полноценную версионность и ещё много чего интересного.
Теоретически — можно. Практически — вы получите производительность и TCO в разы хуже.
Вы попробуйте хотя бы на пальцах прикинуть, как вы обеспечите ACID в банальном переводе денег со счёта A на счёт Б, не складывая все остатки всех счетов всех пользователей в один документ.
_>Кстати, вот http://habrahabr.ru/post/153321/ пример прямо на нашу тему. Прекрасный документ. Он показывает, что можно взять, скажем, interbase образца 1995 года. Заменить в нём подсистему ввода вывода так, чтобы страницу данных она писала не напрямую на диск, а в документ Монги. И опс! У нас получилась полноценная SQL база, с ACID, индексами, и прочими плюшками поверх Монги.
А теперь, внимание, вопрос: во сколько раз этот монстр будет тормознее обычного interbase образца 1995 года, в котором описанный алгоритм реализован напрямую поверх ФС?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Ууу) На нормальные сервисы (без гигантских sql баз) хватает в 10 раз меньшего)))
Покажите ссылку на железку, о который вы говорите. 10-20 килобаксов — это совершенно мейнстримный сервер, что-то вроде Dell R920. Наши партнёры покупают такие сотнями
А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию.
_>Ну вот, ты оказывается постоянно используешь nosql решение, правда не совсем по назначению. )))
Как раз наоборот — он его использует строго по назначению. key-value хороши в качестве кэша — когда есть внешний источник консистентности. Потому что при потере консистентности вернуть её обратно в них невозможно просто никак. Грубо говоря, мы никак не можем отличить ситуацию "форумный пост успел закоммититься в историю пользователя, но не успел в топик" от ситуации "форумный пост успели замодерировать из топика, но не успели из истории пользователя", если у нас нет гарантированно консистентной базы под нашим кэшем. Если есть — мы просто сбрасываем кэш и перечитываем консистентное состояние.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Вот смотри, у тебя есть набор значений, который тебе надо менять взаимосвязанно (собственно это и есть "консистентность БД и для этого служат транзакции). Где ты будешь хранить этот набор? В случае реляционных БД у тебя есть ровно один вариант (если не учитывать нестандартные расширения, типа json в PostreSQL) — набор строк в таблице. S>Ну, вообще-то безо всяких нестандартных расширений мне никто не мешает сваливать данные, для которых мне не нужна гранулярность, в поля типа blob. Этой практике уже несколько десятилетий.
С блобами невозможно производить никакие операции: нет ни индексов, ни поиска, ни модификации. Абсолютно не интересная вещь и даже близко не являющаяся аналогией документа в nosql БД.
_>>И соответственно применение транзакций для сохранения инвариантов связанных значений. В случае же nosql БД выбор обычно побогаче. S> S>В случае NoSQL выбор обычно победнее.
Аргументированно. )))
S>Это вполне себе хреново подходит для современного веба, т.к. в нём пользователи работают над контентом совместно. К примеру, в форумный топик контрибутят много людей.
Само наличие связей между документами ничему не противоречит. Речь была об отсутствие строгих инвариантов между документами.
S>В итоге даже в этой модели, которая предположительно хорошо ложится в убогие ограничения document database, есть проблемы. К примеру, модерирование конкретного поста затрагивает два документа — "документ" пользователя и "документ" топика. Отсутствие транзакций здесь обходится не моделью данных, а моделью отношения к их целостности. Это уровень консистентности "нам пофиг" — ну и что, что убитый из форума пост сохранился в истории пользователя? Это же форум, а не АЭС, никто не умрёт от потерянного или лишнего поста. Всегда можно привелосипедить всякие решения типа "переиндексации", и переобозвать этот уровень консистентности eventual consistence.
Всё там отлично работает, что подтверждают живые примеры (и кстати с открытыми исходниками).
S>А, скажем, систему складского учёта вы навелосипедить на этом не сможете — потому, что там есть то, что вы называете "сильной связностью", и инварианты важны.
Ммм, а я где-то писал, что надо вообще всё писать на nosql БД? ) Я вообще то вполне себе использую sql базы. И на серверах оно у нас живёт для форумов (хотя сейчас я бы уже взял nodebb и nosql БД) и систем регистрации/активации/оплаты. И в приложение sqlite используется (хотя посматриваем на unQLite, кстати, это nosql решение поддерживающее ACID транзакции). Для всего нужны свои инструменты. Просто sql решения в прошлом занимали настолько доминирующее положение исключительно по историческим причинам, а сейчас их хорошо двигают в положенное им реально место. Но естественно никто не собирается отказываться от них вообще.
_>>CAS — это универсальный подход, позволяющий организовать конкурентный доступ к ресурсу без блокировок. Как на уровне инструкций процессора, так и на уровне БД. Можно организовать и просто корректные параллельные модификации без блокировок и транзакции и полноценную версионность и ещё много чего интересного. S>Теоретически — можно. Практически — вы получите производительность и TCO в разы хуже.
Вообще то CAS как раз обычно применяют для ускорения, т.к. при этом можно избежать блокировок. ))) Хотя там есть свои нюансы с быстродействием... Вообще это большая и популярная тема. )
S>Вы попробуйте хотя бы на пальцах прикинуть, как вы обеспечите ACID в банальном переводе денег со счёта A на счёт Б, не складывая все остатки всех счетов всех пользователей в один документ.
А я где-то писал, что собираюсь писать банковское ПО на монге? )))
_>>Кстати, вот http://habrahabr.ru/post/153321/ пример прямо на нашу тему. S> Прекрасный документ. Он показывает, что можно взять, скажем, interbase образца 1995 года. Заменить в нём подсистему ввода вывода так, чтобы страницу данных она писала не напрямую на диск, а в документ Монги. И опс! У нас получилась полноценная SQL база, с ACID, индексами, и прочими плюшками поверх Монги. S>А теперь, внимание, вопрос: во сколько раз этот монстр будет тормознее обычного interbase образца 1995 года, в котором описанный алгоритм реализован напрямую поверх ФС?
Если реально нужна SQL БД с ACID транзакциями и т.п. то зачем трогать монгу? ))) Только вот на практике это как раз не особо часто требуется, а sql используется скорее по историческим причинам (просто ничего другого раньше не было, да и сейчас ещё не все успели изучить современные инструменты).
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alex_public, Вы писали:
_>>Ууу) На нормальные сервисы (без гигантских sql баз) хватает в 10 раз меньшего))) S>Покажите ссылку на железку, о который вы говорите. 10-20 килобаксов — это совершенно мейнстримный сервер, что-то вроде Dell R920. Наши партнёры покупают такие сотнями
Ну а что касается озвученных мною цифр, то даже если брать недешёвый HP, то какой-нибудь DL380e G8/DL180 G9 спокойно потянет приличную нагрузку.
S>А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию.
Ну да, если на винде и с sql server, то может быть)))
_>>Ну вот, ты оказывается постоянно используешь nosql решение, правда не совсем по назначению. ))) S>Как раз наоборот — он его использует строго по назначению. key-value хороши в качестве кэша — когда есть внешний источник консистентности. Потому что при потере консистентности вернуть её обратно в них невозможно просто никак. Грубо говоря, мы никак не можем отличить ситуацию "форумный пост успел закоммититься в историю пользователя, но не успел в топик" от ситуации "форумный пост успели замодерировать из топика, но не успели из истории пользователя", если у нас нет гарантированно консистентной базы под нашим кэшем. Если есть — мы просто сбрасываем кэш и перечитываем консистентное состояние.
Уже же вроде обсуждалось здесь. Redis — это не кэш, т.к. хранит данные на диске (хотя это и можно отключать). Пример кэша — это memcached, который действительно живёт только в оперативной памяти.
(в те времена особо ресурсами не раскидывались). Потом, конечно же, приделали по нормальному (но у меня никогда не было нужды это проверять на практике).
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
