Building a highly-available web service without a database • Hacker News Board

Re: Building a highly-available web service without a database

#121

Post by gtirloni » Sat, Aug 10, 2024, 4:37 PM UTC

tdrhq wrote: post #102

oefrha wrote: post #14

Seems weird to start with “not talking about using something like SQLite where your data is still serialized”, then end up with a home grown transaction log that requires serialization and needs to be replicated, which is how databases are replicated anyway. If your load fits entirely on one server, then just run the database on that damn server and forget about “special architectures to reduce round-trips to your da…

I think it's important to understand that every startup goes through three phases: Explore, Expand, Extract. What's simple in one phase isn't simple in the other. A transactional database is simple in Expand and Extract, but adds additional overhead during the Explore phase, because you're focusing on infrastructure issues rather than product. Data reliability isn't critical in the Explore phase either, because you j…

I'd assume in the beginning you do not want to spend time writing a bunch of highly difficult code until you've proven your idea/product. Then when you're big enough and have the money, start replacing things where it makes sense. It seems to be the strategy used by many companies.

Unless, of course, your startup is in the business of selling DBMSes.

Re: Building a highly-available web service without a database

#122

Post by rrrix1 » Sat, Aug 10, 2024, 4:38 PM UTC

oefrha wrote: post #53

Groxx wrote: post #24

Earlier quoted context omitted.

I do feel like this largely summarizes as "we built our own sqlite + raft replication", yeah. But without sqlite's battle-tested reliability or the ability to efficiently offload memory back to disk. So, basically, https://litestream.io/ . But perhaps faster switching thanks to an explicit Raft setup? I'm not a litestream user so I'm not sure about the subtleties, but it sounds awfully similar. That overly-simplified…

They basically only save on serialization & deserialization at query time, which I would consider an infinitesimal saving in the vast majority of use cases. They claim to be able to build some magical index that's not possible with existing disk-based databases (I didn't read the linked blog post). They lose access to a nice query language and entire ecosystems of tools and domain knowledge. I fail to see how this li…

You should probably RTFA before making broad assumptions on their solution and how it works. Most of what you wrote is both incorrect and addressed in the article.

Re: Building a highly-available web service without a database

#123

Post by rrrix1 » Sat, Aug 10, 2024, 4:49 PM UTC

ozim wrote: post #110

tdrhq wrote: post #107

Earlier quoted context omitted.

> but checking his socials he is not really experienced person. I'm not sure what qualifies as experience if Meta/Google doesn't. ;)

Well he is not Kent Beck or Jon Skeet, Martin Fowler - that is what I call experienced to take seriously a blog post. Just working at Meta/Google doesn’t impress me much just like Shania Twain would sing.

> he is not Kent Beck or Jon Skeet, Martin Fowler

Just FYI, you are (perhaps unintentionally) showing your lack of experience.

There are many thousands of brilliant engineers for every brilliant engineer who also is a author/speaker/publisher. These are very different skills.

Also, perhaps the author _is_ the next Martin Fowler? You never know...

Re: Building a highly-available web service without a database

#124

Post by gtirloni » Sat, Aug 10, 2024, 4:51 PM UTC

ActorNightly wrote: post #68

lpapez wrote: post #64

I once saw a project in the wild where the "database" was implemented using filesystem directories as "tables" with JSON files inside as "rows". When I asked people working on it if they considered Redis or Mongo or Postgres with jsonb columns, they just said they considered all of those things but decided to roll out their own db anyway because "they understood it better". This article gives off the same energy. I r…

This isn't innovation though. You literally just write your server like you would for a single machine, then wrap it any of the available Raft libraries. AWS and other cloud providers are money printers because a lot of engineers are insanely tied into established patterns of doing things and can't think through things at a fundamental level. Ive seen company backends where their entire AWS stacks could be replaced b…

Software Engineering is different than CS though.

Re: Building a highly-available web service without a database

#125

Post by troupo » Sat, Aug 10, 2024, 4:52 PM UTC

oefrha wrote: post #14

Seems weird to start with “not talking about using something like SQLite where your data is still serialized”, then end up with a home grown transaction log that requires serialization and needs to be replicated, which is how databases are replicated anyway. If your load fits entirely on one server, then just run the database on that damn server and forget about “special architectures to reduce round-trips to your da…

> ”. If your data fits entirely in RAM, then use a ramdisk for the database if you want, and replicate it to permanent storage with standard tools

Then you get used to near-zero latency that in-RAM data gives you, and when it outgrows your RAM, it's a pain in the butt to move it to disk :)

Re: Building a highly-available web service without a database

#126

Post by rrrix1 » Sat, Aug 10, 2024, 5:08 PM UTC

ksec wrote: post #118

>RAM is super cheap I think this has to be the number one misunderstanding for developers. Yes, SSD in terms of throughput or IOPs has gone up by 100 to 10000x. vCPU performance per dollar has gone up by 20 - 50x. We went from 45/32nm to now 5nm/3nm, and much higher IPC. But RAM price hasn't gotten anywhere near the same fall as CPU or SSD. It may have gotten a lot faster, you may be even getting to stick lots of mem…

An alternative interpretation is that the maximum RAM capacity for an individual node has drastically increased over the last couple of decades.

A simplistic example, if a given node was limited to 16GB of RAM 20 years ago, I would need 256 nodes to have 4TB of RAM for my system (not including overhead for each OS).

Compared to today, where a single node can have that entire 4TB all in one chassis.

The total cost of RAM chips themselves may not have changed, but the actual cost of using that RAM in a physical system has dropped dramatically.

Re: Building a highly-available web service without a database

#127

Post by rrrix1 » Sat, Aug 10, 2024, 5:13 PM UTC

jmull wrote: post #104

lpapez wrote: post #64

I once saw a project in the wild where the "database" was implemented using filesystem directories as "tables" with JSON files inside as "rows". When I asked people working on it if they considered Redis or Mongo or Postgres with jsonb columns, they just said they considered all of those things but decided to roll out their own db anyway because "they understood it better". This article gives off the same energy. I r…

I get your point and I don’t doubt the project you’re talking about was a mess, but the file system is a database, and can be a very good choice, depending on exactly what you’re doing.

The file system is a database and an API.

Magic!

Re: Building a highly-available web service without a database

#128

Post by SoftTalker » Sat, Aug 10, 2024, 5:20 PM UTC

paxys wrote: post #96

There is so much wrong with this I don't know where to even start. You want to "keep things simple" and not stand up a separate instance of MySQL/Postgres/Redis/MongoDB/whatever else. So, you: 1. Create your own in-memory database. 2. Make sure every transaction in this DB can be serialized and is simultaneously written to disk. 3. Use some orchestration platform to make all web servers aware of each other. 4. Synchr…

Yeah and good luck when the CEO starts asking for reports and metrics (or anything else that databases have been optimized over the last 50 years to do very well).

Surely this is a parody article of some sort?

Re: Building a highly-available web service without a database

#129

Post by Groxx » Sat, Aug 10, 2024, 5:21 PM UTC

kitd wrote: post #43

Groxx wrote: post #24

Earlier quoted context omitted.

I do feel like this largely summarizes as "we built our own sqlite + raft replication", yeah. But without sqlite's battle-tested reliability or the ability to efficiently offload memory back to disk. So, basically, https://litestream.io/ . But perhaps faster switching thanks to an explicit Raft setup? I'm not a litestream user so I'm not sure about the subtleties, but it sounds awfully similar. That overly-simplified…

Rqlite would be a better comparison. It is actually SQLite + raft https://github.com/rqlite/rqlite

I'll throw in a "ehh... sorta" though rqlite is quite neat and very much worth considering.

The main caveat here is that rqlite is an out-of-process database, which you communicate with over http. That puts it on similar grounds as e.g. postgres, just significantly lighter weight, and somewhat biased in favor of running it locally on every machine that needs the data.

So minimum read latency is likely much lower than postgres, but it's still noticeable when compared to in-process stuff, and you lose other benefits of in-process sqlite, like trivial extensibility.

Re: Building a highly-available web service without a database

#130

Post by Groxx » Sat, Aug 10, 2024, 5:25 PM UTC

tdrhq wrote: post #102

oefrha wrote: post #14

Seems weird to start with “not talking about using something like SQLite where your data is still serialized”, then end up with a home grown transaction log that requires serialization and needs to be replicated, which is how databases are replicated anyway. If your load fits entirely on one server, then just run the database on that damn server and forget about “special architectures to reduce round-trips to your da…

I think it's important to understand that every startup goes through three phases: Explore, Expand, Extract. What's simple in one phase isn't simple in the other. A transactional database is simple in Expand and Extract, but adds additional overhead during the Explore phase, because you're focusing on infrastructure issues rather than product. Data reliability isn't critical in the Explore phase either, because you j…

Having Explored with a transactional database: I really can't agree. Just change your database, migrations are easy and should be something you're comfortable doing at any time, or you'll get stuck working around it for 100x more effort in the future.