4 ms·
Well put! Having worked on corporate cash accounting and inventory systems, it's pretty clear that accounting is handled by banking systems _does_ not rely on S
by elcritch 9y ago
Well put! Having worked on corporate cash accounting and inventory systems, it's pretty clear that accounting is handled by banking systems _does_ not rely on SQL-transactions. It's handled by auditing and transaction based system (e.g. event systems) encoded in double entry accounting. ATM's for example will generally dispense money up to a given limit (say $500) as the cost of lost consistency is outweighed under those limits by providing high availability. If the user double draws and goes over their limit, they are held accountable at a later point (usually this is bounded by hard cash transfer limits).
In a warehouse inventory setting, when you _do_ have inconsistencies (e.g. lost items, misplaced orders, etc), a system which strictly enforces "inventory limits" will as often prevent employees from doing their job and shipping an item which could be sitting right in front on them but is not counted for in the system. Auditing combined with optimistic locking resolves this and allows both accountability, tracking, and flexibility.
Those are two real world examples which underly the idea that ACID guarantees and locking / transactions are two separate intents. CouchDB & Couchbase both provide ACID guarantees per document making it straightforward to implement multi-service applications using event base systems. It's equivalent to MongoDB's CAS operations. Really all that you need is to ensure that your changes are atomic and generally ACID compliance at a key/document level enables you to do this readily.
Personally, I find that SQL-style transactions just cause lots of issues with performance and locking contention while enabling developers to skimp on thinking deeply about how to appropriately design their data flow. Sometimes that's the right call for a team, but sometimes it's not.
- calafrax 9y agoTransactions are never needed with a fully normalized model so if transactions are needed it is probably because your model sucks. Or it is because you denormalized your model because your db engine's performance sucks in which case the transactions will probably just make it worse. Good schema design and lock-free/wait-free (transaction-free) algorithms are not "reimplementing transactions in the client." OPs example is garbage but his proposed transaction solution is garbage too.
- pjc50 9y agoEh? If you don't have transactions of some sort you can't update multiple tables simultaneously, which you need for a denormalised model?
- calafrax 9y agoIf your schema is fully normalized then you never have two instances of the same data in more than one place therefore you never have to update two things simultaneously. Anytime you need a transaction it is because you have the same data, or some calculated derivative of the same data, stored in different places, which is why they both have to be updated at the same time to maintain consistency.
- deleted 9y ago[deleted]
- elcritch 9y agoOdd, never thought of the distributed implementations as normalized or not, though that's exactly what the underlying design is about. Thanks! You must design at a minimum a normalized way to store data reference keys, but the prevalence of SQL makes me implicitly associate 'normalization' only with SQL. It's also good to note that adding in vector clocks / revision keys lets you store denormalized data (e.g. Caching with staleness detection) in various data stores as long as the parent id and revision keys are normalized somewhere. Re: pjc50, yes that's what calafrax means.
- weddpros 9y ago"Transactions are never needed with a fully normalized model": I just don't agree. Fully normalized most likely means many tables for everything, and transactions are needed to maintain consistency. "you denormalized your model because your db engine's performance sucks": you're most likely to denormalize because joins are costly no matter what DB you're using. "the transactions will probably just make it worse": denormalization is most often used to reduce the number of operations (so transactions are unlikely to make things worse). I agree about the amount of garbage in the article though.
- codedokode 9y ago> I find that SQL-style transactions just cause lots of issues with performance and locking contention while enabling developers to skimp on thinking deeply about how to appropriately design their data flow "Designing data flow" would mean having to spend more time and money for the same task?
- teej 9y agoYou always have to spend time and money to get performance and consistency at scale.
- MVorlm 9y agoWould you happen to have any articles/papers/blogs/talks that demonstrate how to perform the traditional bank transaction/shopping cart examples using an event-sourced system? Curious to learn more.