Каморка

Есть такая идея -- делать селективный откат транзакций. Смысл в том, чтобы во время работы ДБ собирать информацию и зависимостях между транзакциями. Потом, если обнаруживается одна плохая транзакция, делать селективный откат этой транзакции и тех транзакций, которые от нее зависили и только их.

Подробности здесь:

http://www.ecsl.cs.sunysb.edu/rdms

Ваше мнение, насколько это может быть применимо в реальных проектах? Будут ли проблемы со скалабилити и с чем-нибудь еще?

А если поверх наложились другие транзакции?

Marmot писал(а):А если поверх наложились другие транзакции?

Who cares?!

А вот можно ли в ДБ сделать versioning?
Не удaлять значения совсем, а записывать их в history?
Тогда что нибудь такое можно было бы сделать
Да и вообще было бы полезно.
Для long running transaction compensation.

Библиотека 'SQL-UNDO 3' для MSSQL2000

http://www.gvu.newmail.ru/sqlundo3.zip

Позволяет откатывать старые закоммиченные транзакции. Готовый сервис UNDO в многопользовательской системе. Подробности в файле Readme. Это следующая версия нижеследующего продукта, но абсолютно переделана и продвинута. Удалось убрать кучу ограничений, свойственной предыдущей версии.

Marmot писал(а):А вот можно ли в ДБ сделать versioning?
Не удaлять значения совсем, а записывать их в history?

PostgreSQL так и работает. При каждом апдейте строки он создает новую копию, а струю делает невидимой. Эта фича MVCC зовется:

http://www.postgresql.org/docs/7.3/static/mvcc.html

Lepsik писал(а):Библиотека 'SQL-UNDO 3' для MSSQL2000

http://www.gvu.newmail.ru/sqlundo3.zip

Позволяет откатывать старые закоммиченные транзакции. Готовый сервис UNDO в многопользовательской системе. Подробности в файле Readme. Это следующая версия нижеследующего продукта, но абсолютно переделана и продвинута. Удалось убрать кучу ограничений, свойственной предыдущей версии.

Ага, видел я это. Насколько я понимаю, эта библиотека -- просто user interface к бинарному логу MS SQL. Идея той системы о которой я говорил выше -- собирать информацию о зависимостях между транзакциями и потом удалять их селективно, а не все сразу.

Xa-xa писал(а):

Marmot писал(а):А вот можно ли в ДБ сделать versioning?
Не удaлять значения совсем, а записывать их в history?

PostgreSQL так и работает. При каждом апдейте строки он создает новую копию, а струю делает невидимой. Эта фича MVCC зовется:

http://www.postgresql.org/docs/7.3/static/mvcc.html

Это не совсем то, что я имел ввиду...
Вот если бы все старые версии оставались бы в ДБ и были бы доступны по transaction ID тогда можно было бы поумному откатывать любую из старых транзакций.

Marmot писал(а):Вот если бы все старые версии оставались бы в ДБ и были бы доступны по transaction ID тогда можно было бы поумному откатывать любую из старых транзакций.

они остаются для начала давайте подумаем что такое транзакция. транзакция это операция переводящая БД из одного целостного состояния в другое. В Оракле насколько я знаю есть механизм спуститься на любую точку времени. В СКЛ Сервере это тоже есть. Все что есть в этой работе это еще один путь к решению проблемы востановления данных. Я говорю что сегодня при правильном построении системы известными способами данный подход не требуется. Я скажу более....

1. Размещение вещей ответственных за целостность и безопасность данных на клиенте не правильно.

2. При наличи в системе одной таблицы которая обновляется при любом изменение в любом месте ведет к локам и потере конкурентности что ведет к удорожанию ТСО и стоимости транзакции что в свою очередь ведет к экспоненциальному графику масштабируемости, когда он должен быть линейным. Я готов утверждать что на некоторых системах это будет не 6-8% оверхед, а гораздо больше. Даже при наличии оверхеда 6-8% приводит к потере 10000 транзакций в минуту для системы в 100-150 тпм, что есть ой-ой.

3. Любая система строится на основе бизнес правил, а не на основе текникал решений. Данная работа позиционируется как универсальный подход для любых систем. Существуют системы с нетривиальной логикой и с зависимыми аггрегатами (например), в конце концов с кривым дизайном.... и при раскрутке транзакций возникает необходимость выборочного коммита "посередине". Т.е. автоматической раскрутки дерева просто не получается.

Я рассматриваю это как хорошую академичискую задачу которая может лечь в основу какой-то более сложной другой задачи, но не вижу практического ее применения как универсальный подход абсолютно. Считаю что для больших систем с не тривиальной бизнес логикой (как много больщих с простой логикой? )эта архитектура не жизнеспособна.

Сейчас есть очень реальная проблема в B2B: компенсация давно закоммиченных транзакций.

>В Оракле насколько я знаю есть механизм спуститься на любую точку времени. В СКЛ Сервере это тоже есть.
Это будет глобальный откат, а хочется инивидуальный... и умный...

ЗЫ компенсация!=rollback

Marmot писал(а):Сейчас есть очень реальная проблема в B2B: компенсация давно закоммиченных транзакций.

>В Оракле насколько я знаю есть механизм спуститься на любую точку времени. В СКЛ Сервере это тоже есть.
Это будет глобальный откат, а хочется инивидуальный... и умный...

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

папа Карло писал(а):

Marmot писал(а):Сейчас есть очень реальная проблема в B2B: компенсация давно закоммиченных транзакций.

>В Оракле насколько я знаю есть механизм спуститься на любую точку времени. В СКЛ Сервере это тоже есть.
Это будет глобальный откат, а хочется инивидуальный... и умный...

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

Так я не про то, что там народ предлагает, а про полный и глубокий versioning!
IMHO тогда компенсацию можно автоматизировать

Marmot писал(а):Так я не про то, что там народ предлагает, а про полный и глубокий versioning!
IMHO тогда компенсацию можно автоматизировать

ты оверхед и стоимость решения представляешь?

папа Карло писал(а):

Marmot писал(а):Так я не про то, что там народ предлагает, а про полный и глубокий versioning!
IMHO тогда компенсацию можно автоматизировать

ты оверхед и стоимость решения представляешь?

Ага, представляю, но CPU,RAM, HDD сейчас дешевеют со страшной скоростью, так что не всё так плохо...
Это может быть новый тип DBs, запатентовать что-ли

папа Карло писал(а):1. Размещение вещей ответственных за целостность и безопасность данных на клиенте не правильно.

Такие вещи физически и не могут быть размещены за пределами досягаемости сервера базы.
Однако предоставление возможности управлять данным процессом со стороны клиента - вполне разумно.
Пример - isolation levels.