WebSphere eXtreme Scale Product Overview >



WebSphere eXtreme Scale overview


WebSphere eXtreme Scale is an elastic, scalable, in-memory data grid. It dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers. WebSphere eXtreme Scale performs massive volumes of transaction processing with high efficiency and linear scalability, and provides qualities of service such as transactional integrity, high availability, and predictable response times.

The elastic scalability is possible through the use of distributed object caching. Elastic means the grid monitors and manages itself, allows scale-out and scale-in, and is self-healing by automatically recovering from failures. Scale-out allows memory capacity to be added while the grid is running, without requiring a restart. Conversely, scale-in allows for immediate removal of memory capacity.

WebSphere eXtreme Scale can be used in different ways. It can be used as a very powerful cache or as a form of an in-memory database processing space to manage application state or as a platform for building powerful Extreme Transaction Processing (XTP) applications.

It is important to note, however, that eXtreme Scale cannot be considered an actual in-memory database, much of which is because the latter is too simple to handle some of the complexities that eXtreme Scale can manage. You would have some of the same advantages with both scenarios because they are each in memory, but if an in-memory database has a machine that fails, it is not immediately capable of repairing the issue. Such an event would be particularly disastrous if the entire environment is on that one machine.

To tackle the problem of this type of failure, eXtreme Scale splits the given dataset into partitions, which are equivalent to constrained tree schemas. Each partition exists as a primary copy, or shard, and also replica shards for backing up the data. An in-memory database cannot provide this kind of functionality because it is not structured and dynamic in this way, requiring you to do manually what eXtreme Scale does automatically. Furthermore, because an in-memory database is a database, it can allow SQL operations, and works as a great improvement in terms of processing speed compared to databases that are not in memory. WebSphere eXtreme Scale has its own query language rather than SQL support, but is significantly more elastic, allows for partitioning of data, and provides dependable failure recovery.

The write-behind cache feature allows WebSphere eXtreme Scale to serve as a front-end cache for a database to increase throughput while reducing database load and contention. WebSphere eXtreme Scale provides predictable scaling in and scaling out at predictable processing cost.

The following image shows that in a distributed, coherent cache environment, the eXtreme Scale grid clients send and receive data from the grid, which can be automatically synchronized with a backend data store. The cache is coherent because all of the clients see the same data in the cache. Each piece of data is stored on exactly one writable server in the cache, preventing wasteful copies of records that could potentially contain different versions of the data. A coherent cache holds more data as more servers are added to the grid, and scales linearly as the grid grows in size. The data can also be optionally replicated for additional fault tolerance.

High level topology

WebSphere eXtreme Scale has servers that provide its in-memory data grid. These servers can run inside WebSphere Application Server, or on simple Java™ Standard Edition (J2SE) Java virtual machines, allowing more than one of these per physical machine. Thus, the in-memory data grid may be quite large. The grid is not limited by, and does not have an impact on, the memory or address space of the application or the application server. The memory can be the sum of the memory of several hundred, or thousand, Java virtual machines, running on many different machines.

As an in-memory database processing space, WebSphere eXtreme Scale can still be backed by disk, database, or both.

While eXtreme Scale provides several Java APIs, many uses require no user programming, but rather just configuration and deployment in the WebSphere infrastructure.


Basic paradigm

The fundamental grid paradigm is a key-value pair, where the grid stores values (Java objects), with an associated key (another Java object), by which the value is subsequently retrieved. In eXtreme Scale, a map consists of entries of such key-value pairs.

WebSphere eXtreme Scale offers a number of grid configurations, from a single, simple local cache, to a large distributed cache, using multiple Java virtual machines or servers.

In addition to storing simple Java objects, objects with relationships can be stored. You can use a query language that is similar to SQL, with SELECT … FROM … WHERE) statements, to retrieve these objects. For example, an order object might have a customer object and multiple item objects associated with it. WebSphere eXtreme Scale supports one-to-one, one-to-many, many-to-one and many-to-many relationships.

WebSphere eXtreme Scale also supports an EntityManager programming interface, for storing entities in the cache, much like Java Enterprise Edition entities. Entity relationships may be automatically discovered from an entity descriptor XML file or annotations in the Java classes. Thus, an entity may be retrieved from the cache by primary key using the EntityManager find method. Entities may be persisted to the grid, as well as removed from it, all within a transaction boundary.

WebSphere eXtreme Scale provides extreme transaction processing (XTP) capabilities that ensure a smarter application infrastructure to support the most demanding business-critical applications. You can overcome traditional IT performance limitations to generate the levels of global scale, process efficiencies, and business intelligence needed for smarter outcomes and for sustainable competitive business advantage.

Before deploying eXtreme Scale in a production environment, there are several options to consider, including the number of servers to use, the amount of storage on each server, and synchronous or asynchronous replication.

Consider a distributed example where the key is a simple alphabetic name. The cache might be split into 4 partitions by key: partition 1 for keys starting with A-E, partition 2 for keys starting with F-L, and so on. For availability, a partition has (is stored in) a primary shard and a replica shard. Changes to the cache data are made to the primary shard, and replicated to the secondary shard. For a distributed cache, (or grid or ObjectGrid in eXtreme Scale vocabulary), you configure the number of eXtreme Scale servers that will contain the grid data, and eXtreme Scale distributes the data into shards over these server instances. For availability, replica shards are placed in separate machines from primary shards.

WebSphere eXtreme Scale uses a catalog service to locate the primary shard for each key. It handles moving shards among eXtreme Scale servers should they or their containing physical machines fail and subsequently recover. For example, if the server containing a replica shard fails, eXtreme Scale allocates a new replica shard. If a server containing a primary shard fails, the replica shard is promoted to be the primary shard, and, as before, a new replica shard is constructed.

The simplest eXtreme Scale programming interface is ObjectMap, which is a simple map interface: a map.put(key,value) method to put a value in the cache, and a map.get(key) method to subsequently retrieve the value.

For a discussion of the best practices that you can use when you are designing the WebSphere eXtreme Scale applications, read the following article on developerWorks: Principles and best practices for building high performing and highly resilient WebSphere eXtreme Scale applications.


+

Search Tips   |   Advanced Search