91–100 of 159 posts
Earlier quoted context omitted.
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.
"...has orders of magnitude less latency than..." [citation needed]. Local network access shouldn't be much different than local IPC.
Earlier quoted context omitted.
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.
"...has orders of magnitude less latency than..." [citation needed]. Local network access shouldn't be much different than local IPC.
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.
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.
The animations are fantastic and awesome job with the interactivity. I find myself having to explain latency to folks often in my work and being able to see the extreme difference in latencies for something like a HDD vs SSD makes it much easier to understand for some people. Edit: And for real, fantastic work, this is awesome.
Earlier quoted context omitted.
> Your "1 in a million" comment on durability is certainly too pessimistic once you consider the briefness of the downtime before a new server comes in and re-replicates everything, right? Absolutely. Our actual durability is far, far, far higher than this. We believe that nobody should ever worry about losing their data, and thats the peace of mind we provide.
> Instead of relying on a single server to store all data, we can replicate it onto several computers. One common way of doing this is to have one server act as the primary, which will receive all write requests. Then 2 or more additional servers get all the data replicated to them. With the data in three places, the likelihood of losing data becomes very small. Is my understanding correct, that this means you propag…
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.
The visualizations are excellent, very fun to look at and play with, and they go along with the article extremely well. You should be proud of this, I really enjoyed it.
Earlier quoted context omitted.
> Instead of relying on a single server to store all data, we can replicate it onto several computers. One common way of doing this is to have one server act as the primary, which will receive all write requests. Then 2 or more additional servers get all the data replicated to them. With the data in three places, the likelihood of losing data becomes very small. Is my understanding correct, that this means you propag…
For PlanetScale Metal, we use semi-sync replication. The primary need to get an ack from at least one replica before committing.
Earlier quoted context omitted.
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.
"...has orders of magnitude less latency than..." [citation needed]. Local network access shouldn't be much different than local IPC.
Earlier quoted context omitted.
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.
Perhaps I wasn't clear enough in my comment. When I said "database latency is generally miniscule compared to internet round-trip latency", I meant between the user and the website. Because they're often thousands of miles away, there are network buffers, etc. But no, a local network hop doesn't introduce "orders of magnitude" more latency. The article itself describes how it is only 5x slower within a datacenter for…
I think something about distributed storage which is not appreciated in this article: 1. Some systems do not support replication out of the box. Sure your cassandra cluster and mysql can do master slave replication, but lots of systems cannot. 2. Your life becomes much harder with NVME storage in cloud as you need to respect maintenance intervals and cloud initiated drains. If you do not hook into those system and dr…
Good points. PlanetScale's durability and reliability are built on replication - MySQL replication - and all the operational software we've written to maintain replication in the face of servers coming and going, network partitions, and all the rest of the weather one faces in the cloud. Replicated network-attached storage that presents a "local" filesystem API is a powerful way to create durability in a system that…