On October 1, 2013, HealthCare.gov launched with much fanfare. An estimated 250,000 users attempted to connect to the system, and it came crashing down. Although a government report identified many different factors that contributed to the failure, ultimately the system was unable to keep up with demand.
Most businesses and enterprises will never have to scale their applications to meet demand like that seen by HealthCare.gov, but failure to properly plan capacity can have similar catastrophic consequences. Unfortunately, very few businesses have the luxury of spending the resources needed to satisfy the most optimistic forecasts. Over-building for demand that does not yet exist is expensive and consumes resources that may never be utilized. Balancing the costs of under-forecasting against the cost of over-forecasting has, and may always be, a difficult task.
The best defense against being held hostage to capacity planning missteps is to choose a platform that scales well, eliminating the need to accurately forecast capacity because you can always easily add more after the system is initially deployed. Scalability is one of the key strengths of Oracle Exadata. Oracle Exadata elastic configurations let customers add capacity while the system is deployed, and the databases are online. More importantly, overall system performance scales linearly as capacity is added. In addition, storage scales independently from compute, ensuring customers can scale their critical resources to eliminate bottlenecks without being forced to scale less scarce resources.
Many vendors claim scalability, but if you look closely, your mileage may vary. Scaling CPU for many workloads is subject to licensing rules. Oracle engineered systems like Exadata support not just scaling across servers, but scaling within a server, in a manner that is fully compliant with licensing rules. Exadata combined with Oracle RAC effectively and linearly scale database workloads across multiple servers, with no application changes—a pitfall that affects scalability solutions that rely on partitioning and sharding.
Perhaps the hardest component to scale is storage and IO. On the surface, scaling storage and associated IO resources seem as simple as adding storage to an array. However, in practice this does nothing to scale the performance of a database system. Even modern SANs and networks dedicated to a database can quickly bottleneck the IO of an array as storage is added. The only viable workaround is to bring the processing to the storage devices, where the effective bandwidth of devices can be leveraged. Only Exadata is capable of doing this, as it requires cooperation between the database servers and the storage subsystems. That’s why a full rack of Exadata can provide 10x the IO resource of a typical all-flash storage array, and why the most demanding and scalable workloads are run on Exadata.
This is the seventh in a series of blog posts celebrating the 10th anniversary of the introduction of Exadata, exploring the unique features of Exadata, and why they are important. Next, we will look more closely at the true cost of ownership of a database system, and why Exadata can save you a lot of money.
Bob Thome is a Vice President at Oracle responsible for product management for Database Engineered Systems and Cloud Services, including Exadata, Exadata Cloud Service, Exadata Cloud at Customer, RAC on OCI-C, VM DB (RAC and SI) on OCI, and Oracle Database Appliance. He has over 30 years of experience working in the Information Technology industry. With experience in both hardware and software companies, he has managed databases, clusters, systems, and support services. He has been at Oracle for 20 years, where he has been responsible for high availability, information integration, clustering, and storage management technologies for the database. For the past several years, he has directed product management for Oracle Database Engineered Systems and related database cloud technologies, including Oracle Exadata, Oracle Exadata Cloud Service, Oracle Exadata Cloud at Customer, Oracle Database Appliance, and Oracle Database Cloud Service.