0

The question says it all. But, is it true? Can someone explain what's the differentiating factor here (how one type of disk is better than another for a specific purpose)?

(FYI, I've tried searching, and could fine just one article, which was written like 3 yrs ago.)

  • 1
    Also see the comments here at the following link describing the differences between current SATA and nearline/midline SAS disks: http://serverfault.com/questions/331499/how-can-a-single-disk-in-a-hardware-sata-raid-10-array-bring-the-entire-array-to/331504#331504 – ewwhite Nov 20 '11 at 14:14

2 Answers2

1

Not anymore. You can quite well also run databases of SATA discs - WD Velociraptors are quite comparable to many SAS drives unless you get REALLY high performance (so, database != database).

The larger step is 3.5" to 2.5" - you save a lot of moeny (per gb) when you use large& slow 3.5" drives.

The differencing factors are:

  • SAS discs are normally faster and support longer command queues than SATA (32 limit vs. a LOT more).
  • SSD are nother story. Talking of 60.000 IOPS versus 450.

In general databases are heavy use when they get heavier, with totally random IO, so you dont count gigabytes or RPM, you cound IOPS (IO operations per second).

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • So, over all, I can go with this - - since SATAs come in larger disk sizes, it's best for serving static files and storage. Whereas SSD are great for databases, correct? –  Nov 20 '11 at 13:09
  • 1
    Pretty much. With high performance database yo uare often with discs not limited in space but - in IOPS. Basically you can have 2gb discs, but when you have a 100gb database and need 500 discs to get the IO need solved, the large discs are useless. This is why you still can buy 75-150gb SAS discs with 15000 RPM - for the IO. SSD are IO monsters. Plus a good storage system can use SOME ssd for caching (read and write these days) so you combine both. – TomTom Nov 20 '11 at 13:14
  • do you think I can note the point like this (I mean, is this what you meant?): `For STORAGE, use a combination of SATAs and SSDs, wherein SSDs cache read/writes or at least the most popular reads.` –  Nov 20 '11 at 13:22
  • 1
    Yes. Note that high end raid controlles (Adaptec) can handle SSD as caches and ZFS does that on a file system level. – TomTom Nov 20 '11 at 14:52
0

Whilst I cant say to have ever heard of the rule, static content has advantages that database servers are unable to provide as easily.

SATA drives usually have lower mean times to failure, are slower and perform less well at random I/O. The upshot is their cost per GB is cheaper.

When you store media such as static content, the system typically will cache the content so its not normally read much from disk, this negates the need to have a high speed disk so much.

This is especially true for websites where 90% of the data presented makes up 99% of the requests.

Databases on the other hand typically have an IO profile that is a lot more random. Databases also usually dont rely on the caching subsystem of the kernel to manage its content, so it can benefit to using faster disks. They also tend to perform many more writes than static content which is where the SAS drives can really help.

Bear in mind, there are so many shades of grey that its not as simple or as straight forward as that.

  • Maybe your database is not used much?
  • Perhaps you know exactly what tables will be read and the probability of the data being used?
  • Maybe database writes are hardly ever done?
  • Perhaps the response times your looking and concurrency numbers you have can be acheived effectively with SATA?

I wouldn't say there is a 'rule of thumb'. Instead, why not get some I/O measurements for your application now and what you anticipate your need might be in 2 years. Do you think that SATA will be suitable then? What about SAS, would that be? Maybe SSD is better still? If your talking 30ms faster retrieval times with SAS, is it really worth spending more? Do your customers demand that 30ms extra speed?

For most of the work I do, the numbers being generated by our operation dont really warrant SAS. And - anyway the margin of performance you get versus the cost-per-GB isn't that attractive for me. Now with SSD on the market I am even less impressed with SAS offerings.

That doesnt mean I am saying SAS is not right for you. But figure out your cost per GB, figure out what your performance needs are probably going to be now and in a few years then compare the results against what your clients specific needs would be.

Matthew Ife
  • 22,927
  • 2
  • 54
  • 71
  • 2
    The difference between SAS and SATA is neglegible these days if you shop smart. I have a 1000gb disc here, 2.5", enterprise grade (5 years full warranty) and it gets delivered with SAS or SATA, depending what you want. SAS is expensive in electronics... and often simply not needed. But it has no intrinsic quality issue and ny companies sell "near line" discs these days with ood qarranty and SATA. – TomTom Nov 20 '11 at 13:16