Сообщение Re[4]: NoSQL победили от 24.07.2018 17:00
Изменено 24.07.2018 17:02 vdimas
Re[4]: NoSQL победили
Здравствуйте, gandjustas, Вы писали:
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>В итоге твоя система с легкостью продает два билета на одно место.
Не продаёт.
Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Отлуп придёт до списывания денег со счёта, ес-но.
На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
Собсно, суть всех lock-free алгоритмов примерно такая же.
В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые круттся вокруг некоего прикладного условия.
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>В итоге твоя система с легкостью продает два билета на одно место.
Не продаёт.
Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Отлуп придёт до списывания денег со счёта, ес-но.
На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
Собсно, суть всех lock-free алгоритмов примерно такая же.
В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые круттся вокруг некоего прикладного условия.
Re[4]: NoSQL победили
Здравствуйте, gandjustas, Вы писали:
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>В итоге твоя система с легкостью продает два билета на одно место.
Не продаёт.
Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Отлуп придёт до списывания денег со счёта, ес-но.
На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
Собсно, суть всех lock-free алгоритмов примерно такая же.
В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>В итоге твоя система с легкостью продает два билета на одно место.
Не продаёт.
Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Отлуп придёт до списывания денег со счёта, ес-но.
На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
Собсно, суть всех lock-free алгоритмов примерно такая же.
В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.