Real-time computing. Real-time news.
December 03, 2007
A New Face in Data Caching
1 | 2 | 3 | 4 | 5 | 6 All »
In this Q&A, ScaleOut Software founder and CEO William Bain discusses his company's distributed data caching solutions, including how they are being adopted by e-commerce and financial services customers, as well as how ScaleOut's products differentiate themselves from the competition.
-----
GRIDtoday: First, can you give an explanation of ScaleOut Software's distributed caching technology? How does it work and what are the important distinctions between distributed caching and traditional database-driven architectures?
WILLIAM BAIN: ScaleOut StateServer (SOSS) creates a distributed, in-memory object cache that spans the servers in a grid or server farm. Stored objects are globally accessible across the grid using intuitive application programming interfaces (APIs). SOSS employs a highly integrated architecture that combines automatic data partitioning and dynamic load balancing for scalability, transparent local caching for fast access, and intelligent data replication for high availability. For fast deployment and simplified management, caching servers automatically discover and join the distributed cache, which self-heals after server or network outages.
SOSS automatically partitions all of the distributed cache's stored objects across the grid and simultaneously processes access requests on all servers. This reduces access times and scales the overall throughput of the distributed cache. It also avoids "hot spots" that can arise if objects are stored on the servers where they are created.
As servers are added to the grid, SOSS automatically repartitions and rebalances the storage workload to scale throughput. Likewise, if servers are removed, SOSS coalesces stored objects on the surviving servers and rebalances the storage workload as necessary.
Two levels of internal caching are employed to ensure the fastest possible access times. These caches are integrated into SOSS to automatically accelerate performance without involving the developer in configuring and coordinating multiple caches. One level of internal caching holds objects within the StateServer service process on each server. This speeds up repeated accesses to these objects by avoiding the networking overheads required to copy them from remote hosts. A second level of internal caching holds de-serialized objects within SOSS's client libraries. This cache sidesteps CPU overheads required to retrieve objects when they are repeatedly accessed from the distributed cache.
SOSS ensures that cached data is never lost -- even if a server in the grid fails -- by replicating all cached objects on up to two additional servers. If a server goes offline or loses network connectivity, SOSS retrieves its objects from replicas stored on other servers in the grid, and it creates new replicas to maintain redundant storage as part of its "self-healing" process. SOSS uses a patent-pending, scalable, point-to-point heartbeat architecture that efficiently detects failures without flooding the server grid's network with multicast heartbeat packets. Heartbeat failures automatically trigger SOSS's self-healing technology, which quickly restores access to cache partitions and dynamically rebalances the storage load across the grid.
Using a distributed cache in place of a database server (DBMS) to store data has the dual advantages of very high performance with essentially unlimited scalability. The most common data stored in a distributed cache is mission-critical, but relatively short-lived data, called "workload data." This type of data includes session-state, shopping carts, cached database results, SOAP requests, financial data, grid computing results, and other rapidly accessed, fast-changing application data. To provide global accessibility, applications historically have stored workload data in a centralized, back-end DBMS so that it can be retrieved from any server and preserved in case of server outages. However, database servers are designed to handle long-term, line-of-business data, such as inventory, purchase orders, billing records, and other long lived business data. As the following table illustrates, workload data have different characteristics that make it poorly suited for storage in database servers:
