Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IO Devices and Latency

planetscale.com

Post reply on HN
Print view View original

141–150 of 159 posts

Re: IO Devices and Latency

#141

Post by bddicken »

anymouse123456 wrote: post #129
bddicken wrote: post #3

Author of the blog here. I had a great time writing this. By far the most complex article I've ever put together, with literally thousands of lines of js to build out these interactive visuals. I hope everyone enjoys.

I love this kind of datavis. We are generally bad at internalizing comparisons at these scales. The visualizations make a huge difference in building more detailed intuitions. Really nice work, thank you!

Yeah I think the visuals really add to this one, especially given the time element of explaining latencies.

Re: IO Devices and Latency

#143

Post by bob1029 »

crazygringo wrote: post #133
392 wrote: post #99

Earlier quoted context omitted.

Sqlite can be run in process. Latency and bandwidth can be made 10x worst by process context switching alone. Plus being able to get away with n+1s could save a lot of dev time depending on the crew, before Claude (tho the dev still needs to learn that the speed problem is due to this and refactor the query, or write it fast the first time)

> Latency and bandwidth can be made 10x worst by process context switching alone. No they can't. That doesn't even make sense as a claim regarding bandwidth since SQLite doesn't use any, but please re-read what I said about being a 1% or 5% difference in speed. Not 10x.

Yes they absolutely can.

Same-core context switching costs a few microseconds.

Going across core complexes can cost tens to hundreds of microseconds.

These figures are several orders of magnitude (5-6) slower than L1 access on the same thread.

Re: IO Devices and Latency

#144

Post by andai »

spratzt wrote: post #126
chatmasta wrote: post #105

Earlier quoted context omitted.

That’s a limitation you’ll hit pretty quickly unless you’ve specifically planned your architecture to be mostly read-only SQLite or one SQLite per session.

You certainly won’t hit it with most corporate OLAP processing, which is nearly all read-only SQlite. Writes are generally batched and processed outside ‘normal’ business hours, where the limitations of SQlite writing are irrelevant.

Where are they batched?

Re: IO Devices and Latency

#145

Post by bob1029 »

diziet_sma wrote: post #140
bob1029 wrote: post #124

Earlier quoted context omitted.

https://www.infoq.com/presentations/LMAX/

These aren't financial exchanges, they're a sports betting and an expense management system. I share OPs skepticism. Market makers invest in microwave towers, FPGAs, etc. I would be surprised if sqlite backed by NVME is on the other end of all that specialized hardware. Order matching is a single threaded thing though. I would be curious if anyone knows how electronic trading systems are actually implemented.

> I share OPs skepticism

> I would be surprised if sqlite backed by NVME is on the other end of all that specialized hardware.

I was not making this assertion. I am surprised anything like it got inferred (i.e., my use of the word "premise" regarding single thread/writer policy).

I agree that what you describe would be ridiculous in practice.

> I would be curious if anyone knows how electronic trading systems are actually implemented.

> Order matching is a single threaded thing though.

I think you answered your own question.

Re: IO Devices and Latency

#146

Post by Nezteb »

bddicken wrote: post #30
gozzoo wrote: post #27

Can someeone share their expirience in creating such diagrams. What libraries and tools can be useful for such interactive diagrams?

For this particular one I used d3.js, but honestly this isn't really the type of thing it's designed for. I've also used GSAP for this type of thing on this article I wrote about database sharding. https://planetscale.com/blog/database-sharding

Your diagrams are fantastic; I'd enjoy a short blog post or snippet just on how you used D3 for this!

As someone who has also use GSAP a decent amount, these days I usually have a better experience with SVG.js [1].

[1] https://github.com/svgdotjs/svg.js

Re: IO Devices and Latency

#147

Post by chatmasta »

andai wrote: post #144
spratzt wrote: post #126

Earlier quoted context omitted.

You certainly won’t hit it with most corporate OLAP processing, which is nearly all read-only SQlite. Writes are generally batched and processed outside ‘normal’ business hours, where the limitations of SQlite writing are irrelevant.

Where are they batched?

In a separate system maintained by the DuckDB cargo cultists.

Re: IO Devices and Latency

#148

Post by conradev »

chatmasta wrote: post #105
conradev wrote: post #62

Earlier quoted context omitted.

Until you hit the single-writer limitation in SQLite, you do not need to spend more CPU cycles on Postgres

That’s a limitation you’ll hit pretty quickly unless you’ve specifically planned your architecture to be mostly read-only SQLite or one SQLite per session.

I'm having a hard time imagining this. Aren't most CRUD apps using OLTP mostly read-only in the first place?

I just feel like you'd need thousands of concurrent users on a typical CRUD app to even get close to straining SQLite.

Re: IO Devices and Latency

#149

Post by immibis »

bob1029 wrote: post #67
crazygringo wrote: post #47

Earlier quoted context omitted.

> I've been advocating for SQLite+NVMe for a while now. Why SQLite instead of a traditional client-server database like Postgres? Maybe it's a smidge faster on a single host, but you're just making it harder for yourself the moment you have 2 webservers instead of 1, and both need to write to the database. > Latency is king in all performance matters. This seems misleading. First of all, your performance doesn't matt…

The entire point is to avoid the network hop. Application SQLite NVMe has orders of magnitude less latency than Application Postgres Client Network Postgres Server NVMe > You should be avoiding serial database queries as much as possible in the first place. I don't get to decide this. The business does.

If you're concerned about the overhead of IPC when using postgres on the same server, weigh your intuition of it against your intuition of the savings from having a persistent process. SQLite can't cache a lot of things because some other process might have completely changed the database between transactions. Postgres knows everything that happens to the database.

Re: IO Devices and Latency

#150

Post by immibis »

bob1029 wrote: post #92
sedatk wrote: post #72

Earlier quoted context omitted.

"...has orders of magnitude less latency than..." [citation needed]. Local network access shouldn't be much different than local IPC.

> Local network access In what production scenarios do MySQL, Postgres, DB2, Oracle, et. al., live on the same machine as the application that uses them? I am pretty sure most of these vendors would offer strict guidance to not do that.

In the scenario where you were choosing between it and SQLite...
Post reply on HN