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

121–127 of 127 posts

Re: What Does a Database for SSDs Look Like?

#121

Post by saghm »

evanelias wrote: post #71
saghm wrote: post #64

Earlier quoted context omitted.

I'm not sure I totally understand the timeline you're describing, but my understanding is that relational databases themselves were only invented in the 1970s. Is your reference to the 60s just giving context for when he started but before this link happened (with the idea that the problems predated the solution)?

Non-relational databases existed in the 60s, and many programmers who worked in the 60s presumably continued working into the 70s, so either way I don't see any problems with the timeline GP mentions.

Sure, I never claimed that relational databases were the first ones. I was confused because they were trying to explain a specific timeline different from the article, but only mentioned a single time period that didn't seem likely to be what they intended, and I thought it might make sense to clarify what that time period was. I'm sure this isn't the case for everyone, but at least to me, it's surprising not to be explicit in the information they were trying to claim the article glossed over.

Re: What Does a Database for SSDs Look Like?

#122

Post by saghm »

formerly_proven wrote: post #87
saghm wrote: post #64

Earlier quoted context omitted.

I'm not sure I totally understand the timeline you're describing, but my understanding is that relational databases themselves were only invented in the 1970s. Is your reference to the 60s just giving context for when he started but before this link happened (with the idea that the problems predated the solution)?

Hierarchical databases, which are often more similar to what we would consider a file system today, predate relational ones by a decade or two.

The parent comment was pretty explicit in what types of databases it was talking about:

> I should add that the bond between relational databases and spinning rust goes back further.

It's certainly possible I failed to infer the point they were trying to make, but personally I would find it confusing for them to only mention one type of database (relational) and one time period (the 60s) if they actually meant a different type of database or a different time period in their central point of there being a relationship with, in their words, relational databases and spinning rust, in a specific time period other than what the article describes.

Re: What Does a Database for SSDs Look Like?

#123

Post by hinkley »

threeducks wrote: post #15
crazygringo wrote: post #12

Earlier quoted context omitted.

Can you clarify? I thought a major benefit of SSDs is that there isn't any difference between sequential and random access. There's no physical head that needs to move. Edit: thank you for all the answers -- very educational, TIL!

Lets take the Samsung 9100 Pro M.2 as an example. It has a sequential read rate of ~6700 MB/s and a 4k random read rate of ~80 MB/s: https://i.imgur.com/t5scCa3.png https://ssd.userbenchmark.com/ (click on the orange double arrow to view additional columns) That is a latency of about 50 µs for a random read, compared to 4-5 ms latency for HDDs.

That’s literally faster to do a full table scan below a particular table size.

Re: What Does a Database for SSDs Look Like?

#124

Post by mythoughtsexact »

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.

I keep seeing this crap ass design where developers or some product a-hole decides their schema for users needs a field in their table where it shows the last_login_time. It's a shit design, it does not scale, nor is it necessary at all to get that one piece of information.

Use a damned log/journal table if you absolutely must, but make sure it's a fire away and forget non-transactional insert because you morons keep writing software that requires locking the whole users table and that causes huge performance issues.

Re: What Does a Database for SSDs Look Like?

#125

Post by jiggawatts »

mythoughtsexact wrote: post #124
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.

I keep seeing this crap ass design where developers or some product a-hole decides their schema for users needs a field in their table where it shows the last_login_time. It's a shit design, it does not scale, nor is it necessary at all to get that one piece of information. Use a damned log/journal table if you absolutely must, but make sure it's a fire away and forget non-transactional insert because you morons keep…

Your rant is mostly valid except for one thing: most DBMS systems don’t lock the whole table for a point update. Almost all of them will take a short lived row lock only.

Re: What Does a Database for SSDs Look Like?

#126

Post by formerly_proven »

saghm wrote: post #122
formerly_proven wrote: post #87

Earlier quoted context omitted.

Hierarchical databases, which are often more similar to what we would consider a file system today, predate relational ones by a decade or two.

The parent comment was pretty explicit in what types of databases it was talking about: > I should add that the bond between relational databases and spinning rust goes back further. It's certainly possible I failed to infer the point they were trying to make, but personally I would find it confusing for them to only mention one type of database (relational) and one time period (the 60s) if they actually meant a diff…

Relational databases didn't exist in the 60s but if you change/strike that one word, the entire comment becomes cromulent.

Re: What Does a Database for SSDs Look Like?

#127

Post by saghm »

formerly_proven wrote: post #126
saghm wrote: post #122

Earlier quoted context omitted.

The parent comment was pretty explicit in what types of databases it was talking about: > I should add that the bond between relational databases and spinning rust goes back further. It's certainly possible I failed to infer the point they were trying to make, but personally I would find it confusing for them to only mention one type of database (relational) and one time period (the 60s) if they actually meant a diff…

Relational databases didn't exist in the 60s but if you change/strike that one word, the entire comment becomes cromulent.

There are some circumstances where striking a word pretty clearly changes the intent (e.g. if I removed the word "relational" from your comment in the same way, it would be pretty clearly not what you're trying to say), and there are others where it's fine. If you're capable of figuring this out easily, these types of questions probably don't seem necessary to you, but when I ask questions like the one I did to gain clarify, I'm not being pedantic for it's own sake. Trying harder to understand what others are saying is a genuine attempt to improve communication on my part.

Without going out of my way to infer more intent than you're stating, it's not clear if you're actually saying that you're confident this is what the parent comment was intending or if you're just proposing it's one plausible explanation. I can think of a few other ones as well, and my point in asking was to try to understand which one they actually meant. If I were to go out on a limb and try to infer your actual intent though, it honestly seems like you're intentionally trying to come across as dismissive based on the presumption that I was intentionally trying to be difficult. Having to make this sort of judgment is exactly what I'm trying to avoid in the first place by asking clarifying questions though, so it's a bit jarring to be getting these types of terse responses from someone who wasn't the original commenter I was responding to that don't really help me understand the situation at all and only make me more confused about why someone would take the time to respond to what I said without really addressing my actual question.

Post reply on HN