Customers
WireCache customers come from a range of industries and have a variety of different problems that they are solving with WireCache. Here are some examples, with names removed to protect customer privacy.
Operational BI
Company A collided head-on into the conflict between efficient operations and real-time operational reporting. Their order management system was highly tuned to be able to accept orders from a world-wide channel community, and it worked well. Problems arose when operational managers demanded real-time access to the operational data so that they could better serve the customers. The database analysts tore their hair out as they saw the performance of their exquisitely tuned database attacked at random times by long-running complex queries.
At first, the system managers believed they could solve the problem with a data warehouse that could handle the query load, but closer analysis showed that the business value of the warehoused data would be significantly less than that of the real-time data. Additionally, they realized they would have to heavily modify their reporting suite to use the warehouse data.
The solution was to use a WireCache Transparent Database Accelerator configured to handle the customer service queries. WireCache offered the business analysts real-time data, the load on the operational database dropped back to normal, and DBAs slept at night again.
Dealing With Load Spikes
An RDBMS is a rather fragile piece of software - ask any Database Administrator who is constantly tweaking and tuning it to maintain adequate performance. In particular, it is very fragile under increasing load. One of the DBA’s major tasks is to hold the RDBMS back from its zone of fragility.
Database fragility was Company B’s predicament. Most of the time their RDBMS behaved well, but in some periods of the day, operational reporting placed huge spikes of load on the system, moving it well into the unstable zone – crashing it in some cases. Even after lengthy and detailed analysis, the team could not completely identify the origin of the problem.
The solution was to place a WireCache Transparent Database Accelerator in the query path. The Accelerator detected the spike load and built a cache plan to deal with it. Using the same cache plan, it was also able to pick up a reasonable fraction of the steady state load. The result was that WireCache handled the spikes without this traffic being seen by the DBMS at all. The RDBMS never strayed out of its sweet spot, performance remained acceptable, and the system was able to easily handle the bursts of heavy activity.
Cube Building
Many companies use data warehouses that implement sophisticated multi-dimensional data structures to perform intricate historical analyses. These data structures are created by performing complex queries against the operational database, usually in times of minimal load – at nights or over weekends. However, for large databases with a heavy inflow of new data, the queries that build the cubes can place unmanageable loads on the database.
This was the experience of Company C. The cube building queries placed such a heavy load on the RDBMS that it was unsuitable for normal operations during the cube building period. However, as the company became more successful, the data volumes grew, and database administrators watched the time taken to build cubes extend continuously until it was clear that it would soon exceed the available time window.
They called on WireCache. A WireCache Transparent Database Accelerator was able to reduce the RDBMS CPU load by over 60% during cube building. In addition, it reduced overall cube building time by almost 70%. Suddenly the time window was more than adequate and an anticipated system upgrade could be deferred for several years, resulting in a saving of millions of dollars.
