Database Server Storage Recommendations

[bioprez]

Hello,

I am currently in the process of shopping for a new server that will host the database (RavenDB) for an API project i'm working on, and am looking for some advice / recommendations on what type of storage to use.

The server itself will probably be Quad or 8 core, 8-16GB of RAM, and now i'm trying to figure what storage to buy.

Initially, i'd like to have at least 500GB of space on the server, as the database could grow quickly depending on usage. A programmer on my team suggested that i get an SSD for the server as the reads / writes would be blazing fast, but after looking at pricing on server SSD's ($6K for an 400GB server SSD from Dell), i don't think i can afford that.

My main question is:

For a database server, what type of storage hardware is typically used?

Should i get several SAS drives of 500GB each (was considering RAID 10), or is there an better alternative solution such as a SAN or NAS that would be more appropriate for this situation?

Another concern is that what do i do when the database outgrows the 500GB and i need more space?

Would greatly appreciate advice and recommendations from anyone with experience in this field, thanks!

 

[Brovane]

Ok usually for DB servers using direct attached storage.

I usually have a

RAID 1 for the OS 2-Disks
RAID 1 for the logs 2-Disks

Now for data. This part can get ticky depending on capacity storage needs.
RAID 5 say spread across 3x600GB Disks should give you about 1TB of usuable capacity.
RAID 10 spread across 4x600GB Disks should give you about 1TB of capacity with better performance.

Also your concern about if you outgrow your current storage capacity and need more storage and you are using direct attached disks is spot on. On a SAN it isn't a issue you just grow the disk if you have the extra capacity. Using direct attached storage things become a little more difficult. If you have the extra slots for more disks you can add the disks and most new RAID cards will support a restriping if you add more disks that is dynamic. This could allow more capacity as long as you have the space.

Hope this helps.

 

[bioprez]

@Brovane - Thanks for the input man, it is much appreciated.

I didn't think to split the DB logs into separate drives in RAID1, makes total sense though.

Performance is a concern, obviously looking for the best possible, so i think RAID10 will be the way to go with 4+ 600GB SAS Drives which are much cheaper compared to Enterprise SSD's but still perform well.

I'll probably end up rolling with that config for now...will make sure to have some extra slots available on the SAS board incase i need to drop in a few extra drives for more storage.

If i outgrow that then moving to a SAN is probably the next best step.

Thanks again for your input, greatly helps.

 

[Lifted]

For a database server, what type of storage hardware is typically used?

RAID, either local, direct attached, or SAN.

Should i get several SAS drives of 500GB each (was considering RAID 10), or is there an better alternative solution such as a SAN or NAS that would be more appropriate for this situation?

You're asking us about size, and in a roundabout way performance, but you haven't given us any indication of how large you expect the database to grow to, how many simultaneous users will be hitting it, and what load, if any, those users activity will have on the IO. Without knowing what level of IO for the application your developing will generate, there's no way for you to properly size the server. You're just shooting in the dark. Any solution built this way may provide 1,000x more IO than you need, or even worse 1,000x less.

Another concern is that what do i do when the database outgrows the 500GB and i need more space?

As Brovane mentioned a SAN will provide you with the ability to grow the disk. There are many direct attached storage options that also provide options for expansion via the RAID adapter and an expansion chassis. Dell, HP, and IBM have such options, and dedicated storage vendors such as Promise can do this as well.

It wouldn't be a bad idea to start with a simple server that you can use for both development and sizing purposes. Give 2 disks to the log (RAID 1) and 4+ disks for the db (RAID 5/6/10 depending upon IO requirements), put a load on the db, and monitor the IO.

 

[beginner99]

You could also get smaller ssd(s) for the log only. But if that offers any benefit depends on workload.

 

[LokutusofBorg]

You're asking specifically about RavenDB. Have you consulted their documentation at all yet? With them being a NoSQL implementation they might have different hardware usage than a typical SQL solution (MS SQL, Oracle, MySQL) and so the answers you're getting above may not apply completely.

For a typical SQL hardware setup, you will generally want to look at the read/write ratio of your application under load. A system that runs 80/20 read-heavy will need different hardware than something that has a write ratio higher than 1:1.

Also for typical SQL setups, the log file is almost completely sequential IO, so SSDs are only going to give you marginal gains. Most any SAS drive in RAID (1 or 10) will do you just fine for the log file. The data file is where you want the SSDs, as the IO usage is more random than sequential. For that same reason, you'll get better performance out of a RAID 10 array than either RAID 5 or 6 for your data files, especially if the IO is write-heavy.

One other huge thing to note there, is that if you're hosting more than one database on the same server/storage, then the above advice can pretty much all be thrown out and you'll want to optimize your entire storage setup for random IO. One log file on a volume is almost purely sequential. Two or more log files is not.

The main Anandtech site has a review from a few years ago where they tested SSDs compared to SAS drives for database usage that is well worth the read.

One of the main problems when using a SAN is that unless you spend a lot of money for fiber channel then you're going to have high latency compared to a DAS (local) solution. For a high-traffic database, this will prove to be problematic. Also, even if your project has the needs and budget for a high-priced SAN solution, there is a very viable alternative in PCIe SSD solutions and redundant servers. Go read some of the case study whitepapers on Fusion IO's website for details. Very enlightening, and may give you ideas even if you don't have a huge budget.