Hacker News Reader

Comment by eksith | Hacker News Reader

"A 2 terabyte hard drive costs $94.99, 4 terabytes is $169.99. Buy one and stick it in a desktop computer or server. Then install Postgres on it."

Done! Although with more drives and a backup server. Right now, we're pushing 15Tb with no loss in performance.

View on HN

Do you use standard off-the-shelf consumer hard drives at those prices?

Most companies I've worked for have shelled out quite a bit more for "enterprise" class hard drives. I've always struggled to understand what these bring to the table, and my understanding is that it's some combination of greater reliability and a service agreement.

It's always seemed to me, in my software-centric naivete, that it would be more cost-effective to get off-the-shelf drives, RAID them for redundancy to increase uptime, and make regular backups to increase data longevity.

One of the most important things is that enterprise drives are much more likely to be telling you the truth when they tell you your data is written to disk. Even if it hasn't actually hit the platter, they'll have a battery or cap backup power supply that allows them to write anything still pending to disk before they run out of power. Consumer drives often lie horribly about whether data is truly durable.

Not really an issue for building a reporting/aggregation database.

But certainly something to think about when processing realtime financial transactions.

That's totally understandable. Honestly, we haven't seen any appreciable difference in performance or failure rates between "enterprise" class drives and "consumer" drives (usually WD). Matching RPMs and cache sizes, there's just no way to justify the extra cost for them.

The one area we didn't penny-pinch on was the tape backup. Glacially slow compared to HDDs, obviously, but absolutely necessary.

MTTF should (and probably is) higher. Perhaps some other things like reallocated sectors count can be higher without affecting performance/stability much.

But from what I've seen, the most important thing is the service agreement, i.e. having new disk ready the next day without any questions asked (or money spent for a new drive).

> or money spent for a new drive

To put it other way - expected vs. unexpected expenses.

Hard drives are tricky little beasts.

On the one hand, cheap disks are much more prone to start operating slowly when they begin to fail, instead of transitioning directly from working to not working (or setting themselves as failed).

On the other hand, RAID write speeds are roughly that of the slowest drive in the set. The more drives you have, the higher the probability of a malfunctioning hard drive making the whole thing go slow. Slow drives mean I/O bottlenecks, rendering the whole server unusable.

Pair both things and you have actually increased your effective downtime instead of decreasing it. Now use expensive disks (that work more reliably and either work or don't with a higher probability) and just calculate wether the price increase is lower than the cost of the downtime/slowdowns when running cheap disks.

Oftentimes the price premium is worth it.

For the most part, you're right. Enterprise hard drives tend to come with better agreements, especially for situations where data protection standards make it prohibitive to send a dead drive back to RMA it; often they'll just say to send back the controller board or the like. Oddly, however, one of the big design features for enterprise hard drives is that they'll give up faster if there's a mis-read, etc. Because you're striping your data over a large set of spindles, it's often faster to just throw your hands up and work from the parity disk until you can diagnose the issue. This is also why most good sized arrays will have hot-spares, so you can begin the rebuild while you figure out if the drive was just having a temporary glitch or not.

> it's often faster to just throw your hands up and work from the parity disk until you can diagnose the issue.

One of the advantages of enterprise drives is how long the drive spends error checking. Consumer drives spend considerably longer when it detects an error, and that can cause the RAID controller to drop the drive as malfunctioning. Then it has to rebuild the array or operate on hot spare.

There used to be a firmware setting you could toggle on the WD Caviar Black drives to effectively turn them into the RE (enterprise) drives. They've since made some design changes so that's no longer possible.

You would probably want some RAID + Backups, (and a very generous amount of RAM there) but this is ok.

In fact, I wouldn't doubt that for several "big data" users even SQLite would be enough.

I wouldn't doubt that either.

We do use RAID 6 (I think) + tape backups and the backup server itself is a hot standby. If you're curious, this is the chassis : http://www.supermicro.com/products/chassis/3U/836/SC836A-R12...

The motherboard is also Supermicro running dual AMD Opterons ( single processor on the backup server ) with 256Gb RAM.

I migrated from MongoDB to SQLite for a project a few years ago, it was much more performant:

http://www.stavros.io/posts/using-sqlite-for-great-science-p...

I think the data size ended up being a GB or so.

What is the price / performance tradeoff for using SSD in these applications nowadays?

From my experience SQLite is great when only one process with no parallelism needs to write to the DB and where no other process will frequently overlap reads with writes. However, for CPU-heavy computations that needs multiple cores to compute and write to the DB PostgreSQL has a much better fit for me even for fairly small data-sets. And the ease of use and setup of PostgreSQL is not that much more than SQLite.

As date guy that uses both, there is a higher level of expertise required to properly maintain PostgreSQL. SQLite is something that I can call instantly from Python without much forethought.

Reply on news.ycombinator.com