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

What Does a Database for SSDs Look Like?

brooker.co.za

Post reply on HN
Print view View original

41–50 of 127 posts

Re: What Does a Database for SSDs Look Like?

#41

Post by einpoklum »

zokier wrote: post #5

Author could have started by surveying current state of art instead of just falsely assuming that DB devs have just been resting on the laurels for past decades. If you want to see (relational) DB for SSD just check out stuff like myrocks on zenfs+; it's pretty impressive stuff.

There has also been some significant academic study of DBMS design for persistent memory - which SSD technology can serve as (e.g. as NVDIMMs or abstractly) : Think of no distinction between primary and secondary storage, RAM and disk - there's just a huge amount of not-terribly-fast memory; and whatever you write to memory never goes away. It's an interesting model.

Re: What Does a Database for SSDs Look Like?

#44

Post by wpietri »

I should add that the bond between relational databases and spinning rust goes back further. My dad, who started working as a programmer in the 60s with just magtape as storage, talked about the early era of disks as a big step forward but requiring a lot of detailed work to decide where to put the data and how to find it again. For him, databases were a solution to the problems that that disks created for programmers. And I can certainly imagine that. Suddenly you have to deal with way more data stored in multiple dimensions (platter, cylinder, sector) with wildly nonlinear access times (platter rotation, head movement). I can see how commercial solutions to that problem would have been wildly popular, but also build around solving a number of problems that don't matter.

Re: What Does a Database for SSDs Look Like?

#45

Post by dist1ll »

formerly_proven wrote: post #27
dist1ll wrote: post #22

Earlier quoted context omitted.

> "surely if I send request to 5 nodes some of that will land on disk in reasonably near future?" That would be asynchronous replication. But IIUC the author is instead advocating for a distributed log with synchronous quorum writes.

But we know this is not actually robust because storage and power failures tend to be correlated. The most recent Jepsen analysis again highlights that it's flawed thinking: https://jepsen.io/analyses/nats-2.12.1

The Aurora paper [0] goes into detail of correlated failures.

> In Aurora, we have chosen a design point of tolerating (a) losing an entire AZ and one additional node (AZ+1) without losing data, and (b) losing an entire AZ without impacting the ability to write data. [..] With such a model, we can (a) lose a single AZ and one additional node (a failure of 3 nodes) without losing read availability, and (b) lose any two nodes, including a single AZ failure and maintain write availability.

As for why this can be considered durable enough, section 2.2 gives an argument based on their MTTR (mean time to repair) of storage segments

> We would need to see two such failures in the same 10 second window plus a failure of an AZ not containing either of these two independent failures to lose quorum. At our observed failure rates, that’s sufficiently unlikely, even for the number of databases we manage for our customers.

[0] https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmo...

Re: What Does a Database for SSDs Look Like?

#46

Post by taffer »

hyperman1 wrote: post #43

Postgres allows you to choose a different page size (at initdb time? At compile time?). The default is 8K. I've always wondered if 32K wouldn't be a better value, and this article points in the same direction.

On the other hand, smaller pages mean that more pages can fit in your CPU cache. Since CPU speed has improved much more than memory bus speed, and since cache is a scarce resource, it is important to use your cache lines as efficiently as possible.

Ultimately, it's a trade-off: larger pages mean faster I/O, while smaller pages mean better CPU utilisation.

Re: What Does a Database for SSDs Look Like?

#47

Post by nextaccountic »

zokier wrote: post #5

Author could have started by surveying current state of art instead of just falsely assuming that DB devs have just been resting on the laurels for past decades. If you want to see (relational) DB for SSD just check out stuff like myrocks on zenfs+; it's pretty impressive stuff.

> myrocks

anything like this, but for postgres?

actually, is it even possible to write a new db engine for postgres? like mysql has innodb, myisam, etc

Re: What Does a Database for SSDs Look Like?

#48

Post by toolslive »

but... but... SSD/MVMes are not really block devices. Not wrangling them into a block device interface but using the full set of features can already yield major improvements. Two examples: metadata and indexes need smaller granularities compared to data and an NVMe can do this quite naturally. Another example is that the data can be sent directly from the device to the network, without the CPU being involved.

Re: What Does a Database for SSDs Look Like?

#49

Post by cornholio »

You know you need to be careful when an Amazon engineer will argue for a database architecture that fully leverages (and makes you dependent of) the strengths of their employer's product. In particular:

> Commit-to-disk on a single system is both unnecessary (because we can replicate across storage on multiple systems) and inadequate (because we don’t want to lose writes even if a single system fails).

This is surely true for certain use cases, say financial applications which must guarantee 100% uptime, but I'd argue the vast, vast majority of applications are perfectly ok with local commit and rapid recovery from remote logs and replicas. The point is, the cloud won't give you that distributed consistency for free, you will pay for it both in money and complexity that in practice will lock you in to a specific cloud vendor.

I.e, make cloud and hosting services impossible to commoditize by the database vendors, which is exactly the point.

Re: What Does a Database for SSDs Look Like?

#50

Post by toolslive »

Sesse__ wrote: post #16
londons_explore wrote: post #3

Median database workloads are probably doing writes of just a few bytes per transaction. Ie 'set last_login_time = now() where userid=12345'. Due to the interface between SSD and host OS being block based, you are forced to write a full 4k page. Which means you really still benefit from a write ahead log to batch together all those changes, at least up to page size, if not larger.

A write-ahead log isn't a performance tool to batch changes, it's a tool to get durability of random writes. You write your intended changes to the log, fsync it (which means you get a 4k write), then make the actual changes on disk just as if you didn't have a WAL. If you want to get some sort of sub-block batching, you need a structure that isn't random in the first place, for instance an LSM (where you write all o…

you can unify database with write-ahead log using a persistent data structure. It also gives you cheap/free snapshots/checkpoints.
Post reply on HN