For the last few years I've had a number of discussions surrounding 'in-memory' databases and this has typically been on the basis that if you get the data into memory then it's as quick as you can go (it misses out on how you work with the data btw).
For the most part, this is accurate (from a high level viewpoint), however, there are some aspects of this that are misunderstood or (dare I say it) not thought through properly. The faster you get your data to the processor the faster you go. Very few people seem to tune much at this level but if you are interested please watch http://sqlbits.com/Sessions/Event9/Finding_the_Limits which is by Thomas Kejser and is truly eye opening.
The presentation makes a massive leap forward (not only with Thomas's approach, knowledge and skills) but also by using FusionIO for the storage.
What happens if you don't have FusionIO and have to rely on traditional mechanical storage ?
This is one of the main problems with relational databases. The approach we take with relational databases and normalising our data goes way back to 1970 for First Normal Form (1NF), Second (2NF) and Third (3NF) followed in 1971 then Boyce-Codd Normal Form (BCNF) in 1974. Back in those days we didn't have much data and the speed that we could work with it was pretty slow. I suspect that one of the main reasons behind normalisation was really to reduce the footprint and the working set of data as the costs of storage were prohibitive.
Since then, hardware has become faster and data has grown in size. Unfortunately we hit a tipping point a while back that I think was somewhat masked. Moore's law gave us faster processing but it didn't do much for the storage. We had SATA and the disks there typically spin at 7,000rpm. SAS came along and the spin speed went up to 15,000rpm. Our data growth was such that what we wanted to do worked and fit onto this storage and we got away with it. SAS drives haven't really changed in the last 10 years or so. Why ? Well, it's to do with physics and the speed that we can get the disks to spin. There isn't really much that can be done to improve on this (probably too complex to delve into here). We can add more platters to get more data on, but that doesn't make it faster. We can short stroke (use the outside of the disks) but that doesn't really help when the disks are full.
The physical head that reads the platter still has to move across the platter to retrieve the data and the more work it does, the more latency that will eventually show through. We can add more spindles and divide the load up so that we hopefully reduce the latency and spread our bets if you like.
So, next up is to move different RAID sets to try and reduce the random IO that you will eventually get.
Following that, dedicated spindles so that you don't wait on someone doing a powerpoint presentation while you try to take a booking on your website. If you follow the Microsoft Fast Track Architecture it basically gives a RAID 5 set of disks to individual cores on the assumption that you have no indexes and table scans will be done everywhere.
If you look at Column Stores they are designed to minimise the disk seek time by addressing how the data is physically stored on the disk so each physical movement is much more effective.
Add to this caching (in memory) so that you hit the storage less.
All the while, our other hardware is getting faster, our data is getting bigger and our expectation on faster systems is getting less tolerant of delays. Most people haven't figured that synchronising the cores on a CPU is getting more complex so there is likely a tail off in performance (again, see Thomas's presentation)
So then we have the 'NOSQL' options. This then trades off certain aspects for speed with some solutions, or moves away from an enforced structure and moves that to the individual document on the assumption that joins are bad and so on (see my other post btw).
'NewSQL' such as VoltDB goes off to address the underlying mechanisms (logging, latching, locking and b-trees) to crank more performance out there.
For 'in-memory' solutions we've stepped away from spinning rust, but what happens when the data set doesn't fit into memory ? Pick your preferred option here if you like but they all essentially work the same at a broad level. We can scale out, but then we need a lot of commodity servers which initially seem cheap, but still need power, cooling and rack space etc...
So now when we throw NAND flash into the mix (my personal preference being FusionIO) then we completely negate the physical limitations of the mechanical storage. We lose the latency and gain speed. So now the argument can be swung back around as the real problems with relational databases is the storage not being able to keep up with the quantity and required performance. Joins aren't then bad unless you do something stupid. Take away the physical limitations and do some sensible work and you can make it fly.
We can get the same gains with NOSQL and NEWSQL because we've binned the fundamental problem. You then have freedom and choice to find the right tool for the job.
No comments:
Post a Comment