3 ms·

For workloads that are on the same node -- Putting the database in the same memory space as my code as well as the same I/O and scheduling contexts isn't always

by sargun 4y ago

For workloads that are on the same node -- Putting the database in the same memory space as my code as well as the same I/O and scheduling contexts isn't always what I want. I want to be able to prioritize database I/O far above app I/O. In addition, I want to make sure my database isn't prioritized "lower" than my application, as this can trigger priority inversion issues. Also, the scaling characteristics of database nodes vs service nodes are very different. I might not want to put reliable storage into every node I have, but I'm probably willing to shell out a couple bucks for my database server's storage. An example from my last project that used a lot of postgres. The database node was about ~20x the price as the workers. From an operational perspective, having the database be maintained separately from the app also has its benefits.

api 4y ago
One scaling paradigm that's occurred to me for SQLite would be to run lots of small replicated instances in a system like Nomad or Kubernetes and even allow many running on the same physical node. So you're replicating multiple times on the same box which wastes some space but storage is cheap. Wouldn't be good for huge data sets but these days huge means like a terabyte or more. You don't really have to start thinking about sharding or smart fractional replication until you hit many terabytes. Even many successful SaaS companies don't have databases that big. Several hundred gigs these days is not too big for a brute force replicate everywhere approach and it comes with some benefits like less locking and stronger fault tolerances. If you have 50 replicas the odds of them all being screwed at once gets very low.
treis 4y ago
To add to this, you want you application to be stateless and immutable. This makes your life so much easier in so many different ways: (1) You can know exactly what code was running when debugging past issues (2) Scaling can be done dynamically and relatively easy. Just turn on/off application nodes. (3) Rollbacks are (relatively) trivial. Just go back to the know good immutable version (4) Memory leaks can be "solved" by restarting nodes every so often (5) If, for whatever reason, your application node dies you shrug your shoulders and start a new one Once you add DBs with state to your application all of become much harder. You want that state in something that's rock solid and rarely changes to avoid all the above problems.
tomcam 4y ago
You just gave me a tiny database education in about 8 sentences.

by sargun 4y ago

api 4y ago

One scaling paradigm that's occurred to me for SQLite would be to run lots of small replicated instances in a system like Nomad or Kubernetes and even allow many running on the same physical node. So you're replicating multiple times on the same box which wastes some space but storage is cheap. Wouldn't be good for huge data sets but these days huge means like a terabyte or more. You don't really have to start thinking about sharding or smart fractional replication until you hit many terabytes. Even many successful SaaS companies don't have databases that big. Several hundred gigs these days is not too big for a brute force replicate everywhere approach and it comes with some benefits like less locking and stronger fault tolerances. If you have 50 replicas the odds of them all being screwed at once gets very low.

treis 4y ago

To add to this, you want you application to be stateless and immutable. This makes your life so much easier in so many different ways: (1) You can know exactly what code was running when debugging past issues (2) Scaling can be done dynamically and relatively easy. Just turn on/off application nodes. (3) Rollbacks are (relatively) trivial. Just go back to the know good immutable version (4) Memory leaks can be "solved" by restarting nodes every so often (5) If, for whatever reason, your application node dies you shrug your shoulders and start a new one Once you add DBs with state to your application all of become much harder. You want that state in something that's rock solid and rarely changes to avoid all the above problems.

tomcam 4y ago

You just gave me a tiny database education in about 8 sentences.