Product overview > WebSphere eXtreme Scale overview
WebSphere eXtreme Scale major concepts
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.
Since it is not an in-memory database, consider the specific configuration requirements for eXtreme Scale. The first step to deploying an eXtreme Scale data grid is to start a core group and catalog service, which will act as coordinator for all other Java™ Virtual Machines participating in the data grid and manage configuration information. WebSphere eXtreme Scale processes are started with simple command script invocations from the command line.
The next step is to start WebSphere eXtreme Scale server processes for the data grid to store and retrieve data. As servers are started, they automatically register themselves with the core group and catalog service allowing them to cooperate in providing data grid services. More servers increase both data grid capacity and reliability.
A local data grid is a simple, single-instance grid where all the data is in the one grid. To effectively use eXtreme Scale as an in-memory database processing space, you can configure and deploy a distributed data grid. The data in the distributed grid is spread out over the various eXtreme Scale servers containing it such that each server contains only some of the data, called a partition.
A key distributed data grid configuration parameter is the number of partitions in the grid. The grid data is partitioned into this number of subsets, each of which is called a partition. The catalog service locates the partition for a given datum based on its key. The number of partitions directly affects the capacity and scalability of the data grid. A server may contain one or more data grid partitions. Thus the server's memory space limits the size of a partition. Conversely, increasing the number of partitions increases the capacity of the data grid. The maximum capacity of a data grid is the number of partitions times the usable memory size of each server. A server can be a JVM, but you can define the eXtreme Scale server to suit the deployment environment.
The data of a partition is stored in a shard. For availability, a data grid may be configured with replicas, which may be synchronous or asynchronous. Changes to the grid data are made to the primary shard, and replicated to the replica shards. The total memory consumed or required by a data grid is thus the size of the data grid times (1 (for the primary) + the number of replicas).
WebSphere eXtreme Scale distributes the shards of a data grid over the number of servers comprising the grid. These servers may be on the same machine, separate physical machines, or both. For availability, replica shards are placed in separate machines from primary shards.
WebSphere eXtreme Scale monitors the status of its servers and moves shards among them should either they, their containing physical machines, or both fail and subsequently recover. For example, if the server containing a replica shard fails, eXtreme Scale will allocate a new replica shard, and replicate data from the primary to the new replica. Should a server containing a primary shard fail, the replica shard is promoted to be the primary shard, and, as before, a new replica shard is constructed. If you start an additional server for the data grid, the shards will be distributed over all servers so that the load on each is as balanced as possible. This is called scale-out. Similarly, for scale-in, you may stop one of the servers to reduce the resources consumed by a data grid, and again the shards will be balanced over the remaining servers, just as in a failure situation.
Parent topic:
WebSphere eXtreme Scale overview
Related concepts
Integrate with WebSphere products
Program and Administration Guides
Related reference
New and deprecated features in this release