Alexander RyndinPgSQLAnonymousпропущено...

It depends. Если полный пересчёт (либо блокировки "пересекаются"), то пересчёт заблокируется (а то Вы не знали ;) ).

Вообще, я уже говорил --- я за гибридный подход (т.е. возможность выбора в одной СУБД как полноценного версионного, так и блокировочного механизма).Это как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?
А вот так, магии-то не существует. ;)

Alexander RyndinХорошо, что я решил задать вам этот вопрос, а не снес Oracle.

Да ладно, снесли бы уж, что Вы всё сидите с не-ACID СУБД ;) (и это в 2015-то году! )

Alexander RyndinА то мне показалось, что вы в прошлый раз сказали вот это:
PgSQLAnonymousВ случае блокировочника во всём отчёте будут выведены данные после изменения, т.е. фактически считается, что он был выполнен после модификации, а в версионнике --- до модификации.
Да, сказал. А в этом случае модификация реально будет выполнена только после отчёта, а не до. ;)
Грубо говоря, в блокировочнике последовательность транзакций совпадает с последовательностью COMMIT-ов.

Yo.!Alexander RyndinЭто как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?

показываю магию. внимательно следите за руками !
вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду. 30 лет так работали и дальше так работать будут, а то, что у конкурентов на версионниках давно все в реалтайме, ну так это детали.
Уж скорее в stale-тайме. ;) Впрочем, на практике это всё не так уж бросается в глаза.

Ggg_oldв споре про 3х дневный отчет не правы обе стороны, т.к. непротиворечивость данных такого мега-отчета должен обеспечиваться не механизмами изоляции транзакций, а логикой хранения данных в базе и учета изменения в них.

Это потому что Вы так сказали? ;) А я вот считаю наоборот, и что?

Ggg_oldИзоляция и обеспечение непротеворечивости в течение непродолжтительного времени (например проведения платежа) или построение быстрого оперативного отчета (например выписка по счету за текущий день) можно и частично переложить на мехнизмы блокировок или версий.

Опять-таки, не согласен. Я считаю, что эта задача (обеспечение непротиворечивости при конкурентном доступе) должна решаться именно СУБД.

Ggg_oldПрактика показала, что версионный механизм так или иначе реализуется в субд. т.к. наличие выбора режима работы - это лучше чем только один вариант.

Согласен.

Ggg_oldЛично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем, которые не параллелятся по типу shared nothing. Например все тяжелые учетные системы, банковские системы. Дисковые стойки масштабируются очень хорошо и линейно, знай добавляй дисков и будет расти iops-ы, версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.
Вообще-то кеширование в основном скрывает эти различия, и как блокировки (которые тоже могут храниться на диске), так и версии (которые тоже можно хранить в RAM) обычно находятся именно в RAM. И, кстати, знай добавляй RAM и "будет расти iops-ы". ;)

Alexander RyndinPgSQLAnonymousпропущено...

Уж скорее в stale-тайме. ;) Впрочем, на практике это всё не так уж бросается в глаза.Пользователь обычно хочет получить согласованный результат. Будь он на время Т или время Т+2.
1) в случае версионника пользователь получит ответ на время Т, писатели данных продолжат менять данные
2) в случае блокировочника пользователь получит ответ на время Т, но писатели данных будут заблокированы
3) в случае блокировочника+грязного чтения пользователь не получит согласованный результат ни на Т, ни на Т+2, писатели продолжат менять данные
Мне кажется, с точки зрения бизнес приемлемы 1) и 2). Иногда может быть приемлем 3), но это нужно всегда оговаривать.
Нет, в случае блокировочника пользователь получит ответ на время Т+2 (по состоянию на конец этой транзакции).

DPH3PgSQLAnonymousВот Вам такой пример: я запускаю 2 транзакции --- отчёт (и он выполняется 3 дня) и какую-то модификацию данных, которые он затрагивает (и она выполняется 1 секунду), и они пересекаются.

Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)
Это да. ;)

DPH31) 95% разработчиков систем вообще не знают о разнице между блокировочниками и версионниками и думают, что у Oracle уровень serializable работает так же, как и у DB2.
В результате у нескольких платежных систем (реально работающих на рынке) при массовых операциях с одним счетом могут пропадать деньги и нарушаться пользовательские лимиты по счетам.

Подпишусь. "Слушайте, слушайте, и не говорите, что не слышали!" ;)

DPH3Ну и для реальных задач выбор между блокировочником и версионником не так уж и важен. А вот как реализовано партиционирование, материализованные представление, инкрементальный бакап, log shipping и сколько это стоит - действительно важно.
Вообще-то да, но с учётом того, что "настоящих" (с полноценным версионным SERIALIZABLE) версионников не так уж и много, выбор всё равно важен. ;)

Yo.!Ggg_oldверсионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.
это не правда. ни postgres, ни mysql/innodb, ни mssql/snapshot не хранят локи в датафайлах. эта мудрая мысль заложена только только в оракл.
Да ладно ;)

In PostgreSQL, tuple level locks are not held in RAM for any length of time; lock information is written to the tuples involved in the transactions.
Но это про predicate locks, которые ничего не блокируют, если честно. ;)
А кроме того, чем плоха эта мысль? Потенциально-то это способствует масштабируемости.

Alexander RyndinPgSQLAnonymousпропущено...

Нет, в случае блокировочника пользователь получит ответ на время Т+2 (по состоянию на конец этой транзакции)....и пусть весь мир подождет.
В худшем случае --- да. ;)

А если вот в версионнике 100500 транзакций пересекаются и конкурируют за один и тот же ресурс, то "пусть весь мир отойдёт". ;) Уже наступил вечер, а транзакции всё откатывались.