11–20 of 104 posts
At desktop resolution, the floating table of contents menu blocks out two of the (excellent) illustrations (second and second-last). Deleting aside.toc was very helpful.
Really love this style of writing. Pairing the diagrams/illustrations with the easy to grok copy is really helpful for folks like myself who have been mainly focused on the front-end. What tool do you use for your diagramming, is it all hand-drawn?
One thing that threw me off is that it says for an SSD a random read is 150μs, but 1MB sequential read is 1ms? Shouldn't sequential reads be faster, or are two different read sizes being compared or something? If so, the ambiguity may confuse some people to think random reads are faster
Earlier quoted context omitted.
[Potentially inaccurate content removed by author]
It's a new article so it's relatively easy to explain: HN automatically combines submissions so that subsequent submissions count as upvotes for the first submission. If a popular source posts a new article, users will "rush" to post it to HN to reap that sweet karma and the winner will "catch" the upvotes of the others.
Is this behavior documented anywhere on news.ycombinator.com?
This is great, the visual explanations work really well One thing that threw me off is that it says for an SSD a random read is 150μs, but 1MB sequential read is 1ms? Shouldn't sequential reads be faster, or are two different read sizes being compared or something? If so, the ambiguity may confuse some people to think random reads are faster
This is great, the visual explanations work really well One thing that threw me off is that it says for an SSD a random read is 150μs, but 1MB sequential read is 1ms? Shouldn't sequential reads be faster, or are two different read sizes being compared or something? If so, the ambiguity may confuse some people to think random reads are faster
AFAIK, on SSD's there is no concept/guarantee that blocks are adjacent, so a sequential read is just a bunch of random reads.
1, .toc-wrap covers the image on desktop
2, the image is way too busy, there's too much going on
I'm not too familiar with redis and this may well help, so thank you. I see some data-types on the right. It surprises me that redis doesn't have a numeric data type. I understand that at its heart it is just a key-value store and doesn't ever need to do range-based lookup but it still surprises me. One consequence of "everything is a string" I've run into (although probably a sign I'm "doing it wrong"), is serialisa…
> BITFIELD player:1:stats SET u32 #0 1000
1) (integer) 0
> BITFIELD player:1:stats INCRBY u32 #0 -900
1) (integer) 100
> BITFIELD player:1:stats GET u32 #0
1) (integer) 100
This is said to have a 10μs latency in the chart. But I'm fairly sure that is a calculation of bandwidth based on 1KB / 1GBps
10μs is about 3Km, so at most a 1.5Km round-trip.
For a chart labelled latency, I'm surprised to see bandwidth calculations included. Any network hop would actually have far greater latency, if nothing else because communication typically involves more than a single round-trip for acknowledgement, etc.
It might be worth making it clear some of the numbers are about bandwidth not latency.