|Developing with Pivotal GemFire / Partitioned Regions|
To use partitioned regions, you should understand how they work and your options for managing them.
During operation, a partitioned region looks like one large virtual region, with the
same logical view held by all of the members where the region is defined.
For each member where you define the region, you can choose how much space to allow
for region data storage, including no local storage at all. The member can access
all region data regardless of how much is stored locally.
A distributed system can have multiple partitioned regions, and it can mix partitioned regions with distributed regions and local regions. The usual requirement for unique region names, except for regions with local scope, still applies. A single member can host multiple partitioned regions.
GemFire automatically determines the physical location of data in the members that host a partitioned region's data. GemFire breaks partitioned region data into units of storage known as buckets and stores each bucket in a region host member. Buckets are distributed in accordance to the member’s region attribute settings.
When an entry is created, it is assigned to a bucket. Keys are grouped together in a bucket and always remain there. If the configuration allows, the buckets may be moved between members to balance the load.
You must run the data stores needed to accommodate storage for the partitioned region’s buckets. You can start new data stores on the fly. When a new data store creates the region, it takes responsibility for as many buckets as allowed by the partitioned region and member configuration.
You can customize how GemFire groups your partitioned region data with custom partitioning and data colocation.
A partitioned region operates much like a non-partitioned region with distributed scope. Most of the standard Region methods are available, although some methods that are normally local operations become distributed operations, because they work on the partitioned region as a whole instead of the local cache. For example, a put or create into a partitioned region may not actually be stored into the cache of the member that called the operation. The retrieval of any entry requires no more than one hop between members.
Partitioned regions support the client/server model, just like other regions. If you need to connect dozens of clients to a single partitioned region, using servers greatly improves performance.