Здравствуйте, gandjustas, Вы писали:

G>>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>>>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>>>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>>>В итоге твоя система с легкостью продает два билета на одно место.

V>>Не продаёт.
G>Да-да, только я вживую видел как подобная система делала две подтверждающих транзакции во внешней системы вместо одной. Хорошо что это не списывание денег было, но просто отправка писем.

Такие бока и на MS SQL накрутить можно и скорее всего и было накручено, бо объем данных вокруг кинотеатров, сеансов и мест ничтожен.


V>>Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
G>Ага, это и называется WAL в ручную поверх NoSQL.

Не важно как это называется.
Важно отсутствие локов в нескольких таблицах одновременно.
Все эти сценарии можно свести к тому, что в каждый момент времени лочится ровно одна запись.


G>А потом еще наступает понимание, что нужны еще и транзакции на несколько строк\документов.

Да хоть на тысячи.
Lock-free алгоритмы позволяют в своём теле создавать тяжеловесные данные:
http://www.rsdn.org/forum/flame.comp/7205453.1

Создай master-документ в состоянии "Initializing" — никто его менять не будет, пока он в этом состоянии.
Неспешно напихай к нему slave-строки и остальные зависимые сущности.
Тоже пихай без одновременной блокировки половины базы, а сугубо построчно.
Как закончишь, попытайся атомарно изменить состояние только лишь master-документа, т.е. одной всего записи.
Если не получилось по каким-то прикладным причинам, то см. п.4. по ссылке.

Далее всё происходит согласно прикладного сценария.
Их два основных:
— дать отлуп всей операции с удалением всех зависимых slave-сущностей и потом самого документа;
— модификация самого master-док-та и, возможно, его строк с учётом изменившейся обстановки с заходом на новый круг.

Что будет, если свет неожиданно выключат в середине процесса?
Клиенту придёт "потеря связи".
А база в процедуре подготовки к работе удаляет док-ты вместе со связанными сущностями, которые (документы) находятся в состоянии "Initializing".


V>>На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
V>>Собсно, суть всех lock-free алгоритмов примерно такая же.
G>Да-да, и все эти алгоритмы уже реализованы в РСУБД в механизме ЛОГА.

Мне нужны "разрывы" в этих алгоритмах, для обеспечения их легковесности.
Я же обладаю знаниями о том, что происходит в прикладных алгоритмах и какая роль у каждой сущности, верно?
А серваку БД всё это неведомо.


V>>В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.
G>Ты сам понял что написал?

Я-то понял, бо последние лет 8 плотно занят именно lock-free алгоритмами.
Они чуть более чем везде в моём коде.
Сходи по ссылке, там приведён "скелет" самого большого класса таких алгоритмов.
Мем "неподвижная точка" — он о сохранении неких значений в процессе преобразования.
В более широком смысле — о сохранении св-в.
Т.е. алгоритм продвинется только если будут соблюдены некоторые гарантии, иначе будет вращаться (в самой популярной своей разновидности) до момента соблюдения этих гарантий.

Единственно какая доработка требуется в этом скелете — это очередь, бо мы имеем дело со СМО.
Поэтому, неудачный цикл отправляется на повтор не сразу, а становится в конец очереди заданий.

В своих аналогичных алгоритмах уровня проца я в этот момент вызываю asm pause — эта команда отдаёт ресурсы проца конкурирующим аппаратным потокам.
Бо если столкновение уже произошло, то лучше дать конкурирующему потоку быстрее отработать, а не продолжать бороться с ним за ресурс.


G>Для пользователя все равно мьютексы так или еще что-то.

Мы не пользователи, нам не всё-равно.

Здравствуйте, gandjustas, Вы писали:

G>>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>>>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>>>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>>>В итоге твоя система с легкостью продает два билета на одно место.

V>>Не продаёт.
G>Да-да, только я вживую видел как подобная система делала две подтверждающих транзакции во внешней системы вместо одной. Хорошо что это не списывание денег было, но просто отправка писем.

Такие бока и на MS SQL накрутить можно и скорее всего и было накручено, бо объем данных вокруг кинотеатров, сеансов и мест ничтожен.


V>>Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
G>Ага, это и называется WAL в ручную поверх NoSQL.

Не важно как это называется.
Важно отсутствие локов в нескольких таблицах одновременно.
Все эти сценарии можно свести к тому, что в каждый момент времени лочится ровно одна запись.


G>А потом еще наступает понимание, что нужны еще и транзакции на несколько строк\документов.

Да хоть на тысячи.
Lock-free алгоритмы позволяют в своём теле создавать тяжеловесные данные:
http://www.rsdn.org/forum/flame.comp/7205453.1

Создай master-документ в состоянии "Initializing" — никто его менять не будет, пока он в этом состоянии.
Неспешно напихай к нему slave-строки и остальные зависимые сущности.
Тоже пихай без одновременной блокировки половины базы, а сугубо построчно.
Как закончишь, попытайся атомарно изменить состояние только лишь master-документа, т.е. одной всего записи.
Если не получилось по каким-то прикладным причинам, то см. п.4. по ссылке.

Далее всё происходит согласно прикладного сценария.
Их два основных:
— дать отлуп всей операции с удалением всех зависимых slave-сущностей и потом самого документа;
— модификация самого master-док-та и, возможно, его строк с учётом изменившейся обстановки с заходом на новый круг.

Что будет, если свет неожиданно выключат в середине процесса?
Клиенту придёт "потеря связи".
А база затем при старте удаляет док-ты вместе со связанными сущностями, которые (документы) находятся в состоянии "Initializing".


V>>На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
V>>Собсно, суть всех lock-free алгоритмов примерно такая же.
G>Да-да, и все эти алгоритмы уже реализованы в РСУБД в механизме ЛОГА.

Мне нужны "разрывы" в этих алгоритмах, для обеспечения их легковесности.
Я же обладаю знаниями о том, что происходит в прикладных алгоритмах и какая роль у каждой сущности, верно?
А серваку БД всё это неведомо.


V>>В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.
G>Ты сам понял что написал?

Я-то понял, бо последние лет 8 плотно занят именно lock-free алгоритмами.
Они чуть более чем везде в моём коде.
Сходи по ссылке, там приведён "скелет" самого большого класса таких алгоритмов.
Мем "неподвижная точка" — он о сохранении неких значений в процессе преобразования.
В более широком смысле — о сохранении св-в.
Т.е. алгоритм продвинется только если будут соблюдены некоторые гарантии, иначе будет вращаться (в самой популярной своей разновидности) до момента соблюдения этих гарантий.

Единственно какая доработка требуется в этом скелете — это очередь, бо мы имеем дело со СМО.
Поэтому, неудачный цикл отправляется на повтор не сразу, а становится в конец очереди заданий.

В своих аналогичных алгоритмах уровня проца я в этот момент вызываю asm pause — эта команда отдаёт ресурсы проца конкурирующим аппаратным потокам.
Бо если столкновение уже произошло, то лучше дать конкурирующему потоку быстрее отработать, а не продолжать бороться с ним за ресурс.


G>Для пользователя все равно мьютексы так или еще что-то.

Мы не пользователи, нам не всё-равно.