Administration guide > Plan the WXS environment
Grid Container server
The grid container server stores application data for the data grid. This data is broken into partitions, which are hosted across multiple container servers. Each container server in turn hosts a subset of the complete data. A JVM might host one or more container servers and each container server can host multiple shards.
Partitions host a subset of the data in the grid. WXS automatically places multiple partitions in a single container server and spreads the partitions out as more container servers become available.
Choose the number of partitions carefully before final deployment because the number of partitions cannot be changed dynamically. A hash mechanism is used to locate partitions in the network and WXS cannot rehash the entire data set after it has been deployed. As a general rule, you can overestimate the number of partitions
Shards are instances of partitions and have one of two roles:
The primary shard and its replicas make up the physical manifestation of the partition. Every partition has several shards that each host all of the data contained in that partition. Replicas are redundant copies of the data in the primary shard. A primary shard is the only partition instance that allows transactions to write to the cache.
A replica shard is a mirrored instance of the partition that receives updates synchronously or asynchronously from the primary shard.
The replica shard only allows transactions to read from the cache. Replicas are never hosted in the same container server as the primary and are not normally hosted on the same machine as the primary.
To increase the availability of the data, or increase persistence guarantees, replicae the data. However, replicaion adds cost to the transaction and trades performance in return for availability.
Synchronous vs. asynchronous replication
WXS supports both synchronous, asynchronous replication, as well as hybrid replicaion models using both synchronous and asynchronous replicaion.
- A synchronous receives updates as part of the transaction of the primary shard to guarantee data consistency.
A synchronous replica can double the response time because the transaction has to commit on both the primary and the synchronous replica before the transaction is complete.
- An asynchronous replica shard receives updates after the transaction commits to limit impact on performance, but introduces the possibility of data loss as the asynchronous replica can be several transactions behind the primary.
Parent topic:Plan the WXS environment
Related conceptsPlan overview
Hardware and software requirements
Cache topology: In-memory and distributed caching