Re: Solid State Drives and mySQL / RDBMS?
Obviously doesn't work for extremely large datasets, but nothing stops you from stuffing a server full of memory, assigning a huge block to ramfs, and using that as the second leg of a mirror, with the first leg a real disk device set to write-mostly. Obviously you'll need to create an init script to hot-add the ramfs block device at boot time, as all mirror volume headers are lost at power down :-) Also, note that I specifically said ramfs, NOT tmpfs - the former only takes sizing parameters at boot time, but creates block devices in /dev, while the latter may be resized on-the-fly, but creates a *filesystem*, not a block device, so you a) have to mess with loopback devices and b) are stuck with the filesize limits of tmpfs, whatever they are. Additionally, ramfs allocates the full amount of memory as soon as you use the block device, so you won't unexpectedly run into memory issues months after starting your server. On Sun, Feb 8, 2009 at 8:09 AM, mos mo...@fastmail.fm wrote: At 04:53 PM 2/6/2009, you wrote: While SSD's (Solid State Disks) have traditionally not been the best hardware to use for rewrite-intensive operations like databases, over the last few months, some leading Linux kernel engineers have been raving about next generation Intel SSD's that are close to 20x faster than the fastest disk drives for random access. If robust enough, these next generation SSD's may greatly improve relational database performance. Is anyone using SSD drives currently and can share their experiences? Also, even if they are currently poor for writing, they would make a fantastic slave drive for mega-fast access I would think right? Our current DB is about 80GB and over 1/2 billion rows in each of two of the tables. Reports are starting to take as long as 20 seconds to generate. ...and don't get me started on export/import (it can take DAYS to import). There are Flash SSD's and DDR SSD's. I assume you mean DDR SSD's. You may want to try something like HyperDrive and use Raid to increase the size of the volume. See http://www.hyperossystems.co.uk/. It was reviewed at http://www.techreport.com/articles.x/16255/9. For random access, these solid state devices are extremely fast. But sequential access they are slightly faster than the fastest hard drive. These devices are also getting quite cheap compared to what they cost 5 years ago. I haven't tried it, but would love to get my hands on a few of these. Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be -- Celsius is based on water temperature. Fahrenheit is based on alcohol temperature. Ergo, Fahrenheit is better than Celsius. QED.
Re: Solid State Drives and mySQL / RDBMS?
On Fri, Feb 6, 2009 at 5:53 PM, Daevid Vincent dae...@daevid.com wrote: While SSD's (Solid State Disks) have traditionally not been the best hardware to use for rewrite-intensive operations like databases, over the last few months, some leading Linux kernel engineers have been raving about next generation Intel SSD's that are close to 20x faster than the fastest disk drives for random access. If robust enough, these next generation SSD's may greatly improve relational database performance. You are confusing me here. What is an SSD by your definition? (I'll be on Wikipedia right after I make this post.) If you mean a purely RAM-based device, it should work fine with great performance. If you mean a FLASH/EEPROM-based device, you might have a RAM front end to it, but there would be limits to how much data you can change how quickly. What is your definition of an SSD? Got a typical manufacturer and model number?
Re: Solid State Drives and mySQL / RDBMS?
At 04:53 PM 2/6/2009, you wrote: While SSD's (Solid State Disks) have traditionally not been the best hardware to use for rewrite-intensive operations like databases, over the last few months, some leading Linux kernel engineers have been raving about next generation Intel SSD's that are close to 20x faster than the fastest disk drives for random access. If robust enough, these next generation SSD's may greatly improve relational database performance. Is anyone using SSD drives currently and can share their experiences? Also, even if they are currently poor for writing, they would make a fantastic slave drive for mega-fast access I would think right? Our current DB is about 80GB and over 1/2 billion rows in each of two of the tables. Reports are starting to take as long as 20 seconds to generate. ...and don't get me started on export/import (it can take DAYS to import). There are Flash SSD's and DDR SSD's. I assume you mean DDR SSD's. You may want to try something like HyperDrive and use Raid to increase the size of the volume. See http://www.hyperossystems.co.uk/. It was reviewed at http://www.techreport.com/articles.x/16255/9. For random access, these solid state devices are extremely fast. But sequential access they are slightly faster than the fastest hard drive. These devices are also getting quite cheap compared to what they cost 5 years ago. I haven't tried it, but would love to get my hands on a few of these. Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Solid State Drives and mySQL / RDBMS?
While SSD's (Solid State Disks) have traditionally not been the best hardware to use for rewrite-intensive operations like databases, over the last few months, some leading Linux kernel engineers have been raving about next generation Intel SSD's that are close to 20x faster than the fastest disk drives for random access. If robust enough, these next generation SSD's may greatly improve relational database performance. Is anyone using SSD drives currently and can share their experiences? Also, even if they are currently poor for writing, they would make a fantastic slave drive for mega-fast access I would think right? Our current DB is about 80GB and over 1/2 billion rows in each of two of the tables. Reports are starting to take as long as 20 seconds to generate. ...and don't get me started on export/import (it can take DAYS to import).
