You've tuned your databases queries, added all of the indexes you can think of and cached all of the queries you can but your database still isn't giving you the performance you need.
So it's time to split up your database into several databases and move each of these new databases off onto separate database servers. Or perhaps a RAID database is the solution to your performance issues.
With RAID hard disk mirroring you have multiple hard disks each with the same information on them. If you want to read information off the RAID disks you can read it off any of the disks and if you want to write information you need to write it to all disks. Basically you can do X times as many reads in the same amount of time for a X disk system as a one disk system. ie 2 mirrored hard disks give twice the read performance, 3 hard disks give three times the performance, etc etc
You can use a similar technique with databases. If you have multiple copies of the same database on separate servers you can implement this fairly easily in ColdFusion.
Building on the data source name singleton code I wrote the other week we have:
<cfset variables.DSN = arraynew()>
<cfset variables.length = 0>
<cffunction name="getDSN" access="public" returntype="string" output="false">
<cfset var i = RandRange(1,variables.length)>
<cffunction name="getAllDSNs" access="public" returntype="string" output="false">
<cffunction name="setDSNs" access="public" output="false">
<cfargument name="DSNs" type="string" required="yes">
<cfset variables.DSN = listtoarray(arguments.DSN)>
<cfset variables.length = arraylen(variables.DSN)>
For any select query with just use the getDSN method like before:
<cfquery name="myquery1" datasource="#dsn.getDSN()#">
For any update, insert or delete queries you must alter all databases so you need to loop over them like so:
<cfloop item="ds" list="#dsn.getAllDSNs()#">
<cfquery name="myquery1" datasource="#ds#">
This technique would only be of benefit for databases that have more reads (ie selects) than writes(ie updates and deletes), but for most web applications that is the case.
The DSN component code could be modified so you can mark data sources as offline and flags datasources that are currently out of action. That way your system will continue to run off the other databases if one (or more) of them are down.
It's also fairly easy to add additional databases to cope with increased load to a running system.
One issue with this method is re syncing the databases once one of them has gone offline and then come back online again. It would be possible to do this re syncing via code by logging and rerunning all SQL update, insert and delete queries but it's probably better to just re sync with your native database tools.