Комментарии 19
BTW если надо ОЧЕНЬ быстро и внутри процесса, то рекомендую Хеш-таблицу с транзакциями
а, ну еще можно эффективно создавать Структуры данных второго порядка внутри ЛЮБОГО key-value store
Посмотрите на FoundationDB. Все что описано у вас, там и используется, только в большом масштабе.
это другое :)
смотрите https://en.wikipedia.org/wiki/FoundationDB#Design_limitations
FoundationDB does not support transactions running over five seconds.
Transaction size cannot exceed 10 MB of total written keys and values.
Keys cannot exceed 10 kB in size. Values cannot exceed 100 kB in size.
пять секунд - это стыдно. и остальное тоже.
Нет стыдно. Есть заранее известные ограничения и обоснование этих ограничений. Ограничения в нормальных системах придумываются не просто так и дают какие-то плюсы взамен.
У обычных sql баз тоже куча ограничений. Мы просто к ним привыкли и воспринимаем как должное.
Не могу представить, для чего могут понадобиться транзакции 5 секунд и более. На случай если что то пошло не так?
вы механизм пессимистичных блокировок хоть раз в своей жизни реализовывали програмно? С юзер UI-ем. Там время обычно минутами исчисляется
Какие пессимистичные блокировки в распределенных системах о_О? Если они вам нужны, транзакции вам в помощь, реализуем распределенную блокировку + подписка на ключ и вот вам "оптимистичная блокировка" хоть на сутки.
Есть примитивы, достаточно надёжные, далее из них строим все что нужно на уровне приложения.
распредененные системы на бекенде все равно в одну базу сходятся. Те же билеты на поезда лежат в БД, и один конкретный билет на поезд Москва-Сочи на 12.05.2025 на место 33 лежит в одном месте, он не может быть распределен, это вам не запутанные кванты. И его надо блокировать при продаже, и тут вот именно что "транзакции вам в помощь". А если у вас транзакции живут 5 секунд - придется забыть про транзакции на уровне БД и городить псевдо транзакции на уровне приложения.
городить псевдо транзакции на уровне приложения
А это прям так плохо и ужасно? Могу конечно ошибаться, но транзакция живет, пока живо соединение с БД, получается, если мы решим перезапустить инстанс приложения, то все наши транзакции (брони) слетают? Иначе наши сервисы из stateless превращаются в statefull.
Что значит блокировать, не дать другому купить его? Зачем для этого длинная транзакция? Добавляем поле status (и другие если надо), помечаем что забронировано, все, теперь хоть через 1с, хоть через 10, хоть через сутки другие не смогут его забронировать и это будет работать на любой БД с транзакциями достаточными для выполнения простого обновления.
Ну да, не от хорошей жизни все это эмулируется полем status , а именно из-за того что в половине случаев бд тебе заявляет "Не могу представить, для чего могут понадобиться транзакции 5 секунд и более" а в другой половине программисты вообще не умеют ими пользолваться на уровне бд. А потом даже доходит до эмуляции распределенных транзакций всякими SAGA.
то все наши транзакции (брони) слетают
слетает не бронь, а ВРЕМЕННАЯ блокировка пока клиент билет выбрал, но не оплатил (Ну так она и должна слетать если сессия клиента отвалилась). А вот в програмной эмуляции - придется огород городить, если во время блокировки клиент отвалился.
После оплаты - проходит update - и всё зафиксированно надежно как буква D в абревиатуре ACID.
"Не могу представить, для чего могут понадобиться транзакции 5 секунд и более"
все хуже, на самом деле.
эти 5 секунд жестко встроены в Архитектуру. и возможность поднять их до 10 неизбежно означает, что что-то ухудшится в те же 2-4 раза.
слетает не бронь, а ВРЕМЕННАЯ блокировка пока клиент билет выбрал, но не оплатил (Ну так она и должна слетать если сессия клиента отвалилась). А вот в програмной эмуляции - придется огород городить, если во время блокировки клиент отвалился.
Т.е. вы предлагаете:
получаем запрос на один из N инстов и открываем транзакцию
держим эту транзакцию до завершения
при обработке все действия с этим платежом роутим на этот же инст где транзакция, иначе как мы ее закроем
получили оплату, закрываем транзакцию
PROFIT
Если верно понял схему то сходу возникают задачи, которые нужно решать:
sticky session
таймаут на транзакцию все равно нужен, т.к. (если коговорим про web) пользователь может закрыть/обновить страницу, потерять соединение и это нормально, но в итоге у нас разорвется соединение, как следствие клиент типо ушел, транзакция висит, но он же не ушел никуда. Да и вообще процессы оплаты бывают очень разные
как перезапустить сервис, чтобы не сбросить пользователей, которые в процессе оплаты (прервать happy path)
Видится мне, что это не сильно проще чем просто временная блокировка, а поддержка возможно и сложнее.
Если очень хочется, можете поднять лимит, но зачем?
В остальном он предлагает аналогичную концепцию создания структур второго порядка на базе мамы и транзакций.
То что описано у вас хорошо, но как это использовать в реальной жизни? Если говорим про сервис, то нужно минимум 2 экземпляра, следовательно надо решать проблемы синхронизации и тд.
как это использовать в реальной жизни?
все согласно Концепции: это продвинутая хеш-таблица для тех, кому уже не хватает обычной. т.е. удобный и быстрый кэш, а не медленная БД.
ЗЫ и обратите внимание на колбэки check_cb и write_cb метода commit() -- это абсолютно уникальные возможности!
auto err=tr->commit(updateTotal, &fileSize); // call_back и аргумент
это вот этот пример?
судя по всему callback синхронный, для репликации во внешнее хранилище минус, так же не вижу как прервать транзакцию внутри этого метода или такой возможности нет или нужно исключение кидать?
И код приложен zip архивом, а не в публичной репке о_О?
лучше смотреть вызов t->commit(test07_wrt_cb, mp, test07_chk_cb, mp); в code\test_mem_db\main.cpp из https://ders.by/cpp/deque/code.zip
в публичной репке о_О?
вы ж понимаете, что ко всему закроют доступ.
С каких пор Apache Spark стал СУБД?
Рад за Кликхаус
DB-Engines представила январский рейтинг популярности СУБД