6 ms·
The reason the database is the bottleneck is that in traditional architectures everything can be duplicated and run in parallel except writing to the database w
by dorfsmay 7y ago
The reason the database is the bottleneck is that in traditional architectures everything can be duplicated and run in parallel except writing to the database which has to be done serially one write at a time. How fast you can write (and commit to "permanent" storage like disc and SSD) is constrained by hardware.
There are ways to alleviate this issue but they have different trade offs. One of the most used pattern is "eventual consistency".
You might want to read about the CAP theorem if you have not heard about it: https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem
- wbl 7y agoDatabases can handle multiple concurrent writes just fine and have since the 1970's.
- madmax96 7y agoI think that parent was trying to state that maintaining sequential consistency is a bottleneck for traditional databases.
- ericpauley 7y agoNot a charitable interpretation of the parent comment. Even though databases allow concurrent transactions, commiting these transactions with complete sequential consistency is still an inherently serial process, at least insofar as it cannot be generally split across machines.
- adamfeldman 7y agoThere are distributed databases that support serializable transactions across clusters of machines. https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb https://www.cockroachlabs.com/blog/serializable-lockless-dis...
- dorfsmay 7y agoTo the same table? To the same row? Say you're an ecomm, how do you update inventory on an item "concurrently"? If you're going to say "locks" or "atomic commit", that's exactly what I mean by "you have to serialize your writes".
- mcguire 7y agoHow much contention are you expecting?
- dorfsmay 7y agoThis is a business prediction/problem and exactly what defines your bottleneck.
- hultner 7y agoJust thinking out loud here but the particular case of inventory of an item should be possible to decrement/increment using a PN-Counter CRDT as long as you are fine with eventual consistency. Of course there's a risk of overcommitment which has to be considered but such risks usually exists in commerce any way due to or factors.
- dorfsmay 7y agoYes, eventual consistency, which is exactly the alternative I mention in my original post. If you can tolerate eventual consistencies (most problem can), than the database is no longer the slower piece.
- scardine 7y agoI think parent is talking about things like MVCC[1] in contrast with simple read-write locks. [1] https://en.wikipedia.org/wiki/Multiversion_concurrency_control https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...
- mattmanser 7y agoI've fixed a lot of performance problems over my career. This is not true, and not what we talk about when we say it's almost always the db. The usual cause of database problems is a single big query that is causing a slow page, or a lot of medium size queries inside a poorly written loop. Whether it be bad joins, missing indexes, select statements in the select statements, operations in select statements that force the db to run the query line by line instead of as a set (the technical term suddenly escapes me), it's the queries that almost always cause db slowdowns. It rarely has anything to do with writes, and then in my experience usually had to do with escalating locks, and I haven't seen that problem in ages as hardwares got faster.
- dorfsmay 7y ago> This is not true, and not what we talk about when we say it's almost always the db. It depends who's talking and what they are talking about. If we're talking about fixing slow website, then sure, bad big ugly queries are one dominant issue, but not the only one. If we're talking about architecture of a greenfield project, then balancing between concurrent writes and consistency is going to be your ultimate problem, everything else can be "duplicated" (read-duplicated DB servers, caching strategies, multiple apps server, etc...).
- mattmanser 7y agoAnd who ever needs to think about that stuff? A tiny number of companies. Again, I just think you're not considering the vast majority of us here work in terms of thousands, 10s of thousands or millions of users, not the sort of scales where anything you're saying ever becomes relevant. For most of us, if you spend any time thinking about that, you're utterly wasting it. It's pointless. Greenfield or not.
- scarface74 7y agoI have no idea where the mindset comes from that only large companies have large datasets.
- WhiteOwlLion 7y agolet's put the entire database on a ram disk (or at least the write logs)
- yibg 7y agoWhat happens when someone trips over the power cord?
- parliament32 7y agoRedundancy, and snapshots + replay logs
- neverartful 7y agoThat's why you would use non-volatile memory (e.g., NVMe) if you needed a persistent store with that degree of performance.