For the record, I'm a NoSQLer and a big data guy. After nearly 20 years of dealing with what I've come to refer to as "the beast" (aka Oracle), I've turned coat and decided I prefer solving the problem rather than mitigating it.
That said, many companies I work with have spent 20 years painting themselves into an Oracle corner. While they may have one eye on a brighter future, they still must ensure their Oracle database is high-performance and highly available -- and scales as well as possible. Despite what you may read in NoSQL vendor marketing materials (or even in my blog), it is possible to scale Oracle.
[ Also from Andrew Oliver: Which freaking database should I use? | Which freaking PaaS should I use? | Download InfoWorld's PDF of tips and trends programmers need to know in our Developers' Survival Guide. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
There's just one catch: Nothing I'm going to suggest costs less than my house for a nontrivial installation. Heck, when you include the hardware and data center resources, some cost more than my whole neighborhood.
What availability and scalability really mean
Before I describe how to accomplish high availability or scalability, we'd all be better served if you know what I mean by those terms.
High availability means close to zero downtime -- in other words, a system that can tolerate a one-node failure with either zero downtime or minimal downtime (usually less than 5 minutes) for the failover process. Sometimes this can be done across data centers to allow for high availability even in a disaster scenario.
As for scalability, it's important to understand from the outset that performance is a different concept. Performance is the time it takes to service a request. Scalability means flexibility in expanding or reducing your server capacity and infrastructure. Higher scalability means handling a larger number of requests within our expectation of performance.
There is some overlap, however, in performance and scalability. Ideally, a database and its related infrastructure handles all availability issues under the hood so that the client can stay "dumb." However, if certain aspects of transaction logic are outsourced to the client, then performance and scalability can both be at risk.
Take sharding, for example. The dragon is always complexity -- and including sharding logic in application code introduces a bug risk associated with the sharding algorithm "rolled" by the developer. This threatens scalability because the sharding algorithm might not be very good or correct (for example, Foursquare in October 2010).
What do you need? You need fault tolerance against server outages, storage outages, and data center outages (aka disaster). You'll also need a way to balance load against servers and/or CPU cores as well as disks. Several products and techniques can accomplish this.