←back to thread

SSDs have become fast, except in the cloud

(databasearchitects.blogspot.com)
589 points greghn | 3 comments | 20 Feb 24 16:59 UTC | HN request time: 0s | source
Show context
siliconc0w ◴[20 Feb 24 17:23 UTC] No.39444011[source]▶
Core count plus modern nvme actually make a great case for moving away from the cloud- before it was, "your data probably fits into memory". These are so fast that they're close enough to memory so it's "your data surely fits on disk". This reduces the complexity of a lot of workloads so you can just buy a beefy server and do pretty insane caching/calculation/serving with just a single box or two for redundancy.
replies(3): >>39444040 #>>39444175 #>>39444225 #
malfist ◴[20 Feb 24 17:36 UTC] No.39444175[source]▶
I keep hearing that, but that's simply not true. SSDs are fast, but they're several orders of magnitude slower than RAM, which is orders of magnitude slower than CPU Cache.

Samsung 990 Pro 2TB has a latency of 40 μs

DDR4-2133 with a CAS 15 has a latency of 14 nano seconds.

DDR4 latency is 0.035% of one of the fastest SSDs, or to put it another way, DDR4 is 2,857x faster than an SSD.

L1 cache is typically accessible in 4 clock cycles, in 4.8 ghz cpu like the i7-10700, L1 cache latency is sub 1ns.

replies(5): >>39444275 #>>39444384 #>>39447096 #>>39448236 #>>39453512 #
LeifCarrotson ◴[20 Feb 24 17:52 UTC] No.39444384[source]▶
I wonder how many people have built failed businesses that never had enough customer data to exceed the DDR4 in the average developer laptop, and never had so many simultaneous queries it couldn't be handled by a single core running SQLite, but built the software architecture on a distributed cloud system just in case it eventually scaled to hundreds of terabytes and billions of simultaneous queries.
replies(5): >>39444867 #>>39444883 #>>39445536 #>>39445790 #>>39448007 #
1. Szpadel ◴[20 Feb 24 19:33 UTC] No.39445790{3}[source]▶
In may day job I often see systems that have the opposite. Especially for database queries, developers tested on local machine with 100s of records and everything was quick and snappy and on production with mere millions of records I often see queries taking minutes up to a hour just because some developer didn't see need for creating indexes or created query in a way there is no way to even create any index that would work
replies(2): >>39446670 #>>39452118 #
2. layer8 ◴[20 Feb 24 20:46 UTC] No.39446670[source]▶
That’s true, but has little to do with distributed cloud architecture vs. single local instance.
3. pooper ◴[21 Feb 24 10:22 UTC] No.39452118[source]▶
This is a different topic and not always a skills issue. The stupid match for "productivity" and "velocity" means you have to cut corners.

Also Sometimes, it is poor communication. Just yesterday I saw some code that requests auth token before every request even though each bearer token comes with expires in (about twelve hours).