Overview

The partitioned space provides the ability to form a space that has unlimited data storage capacity. A replicated space instance is limited in the amount of data it can store by the capacity of a single node JVM heap size. In many cases, it is desirable to combine the memory of separate space instances and to make them behave as a single large space. This can be achieved by partitioning the data among the different instances to have only a portion of the data in each instance. The application will view the clustered spaces as one space, where the space proxy running at the client, routes each operation call to the correct space instance to fetch/store the object.

Maximum scalability is achieved when your application is multithreaded allowing the partitioned space to handle client requests in parallel.

For limitations and considerations when working with a partitioned space; and details regarding multi-space operations, refer to the Partitioned Space Considerations section.

For more details on load-balancing and partitioning options, refer to the Load-balancing Group Options section.

To deploy a partitioned space without using the SpaceFinder or the gsInstance CLI option, use the Service Grid Deployment Wizard.

The Service Grid Deployment Wizard allows you to deploy large space clusters very easily without specifying the member's ID. A clustered space deployed via the Service Grid supports dynamic reallocation, enhanced resiliency, and self-healing capabilities.

For more details, refer to the following section:

• OpenSpaces Service Grid Processing Unit Container

Routing Field

When running a partitioned space (using the hash-based load-balancing policy) operations are routed to the relevant partition, based on the Entry's content. The content is determined using an Entry field that should be marked as the Routing Field. The Routing Field hashcode value is used by the clustered space client proxy to calculate the matching partitioned space (primary and all of its backups) to rout the operation (write, read, take, or notify registration) into.

When calling the read, take, or notify registration operations, the template used to instruct the space to perform the matching must have a value in case you want the matching to be performed at a specific partition. If you don't define a value (meaning defining null as the value) in the Routing Field template object, the read, take, readMultiple, takeMultiple, or notify registration operations are routed to all partitions.

For more details on the load-balancing policy Broadcast mode, refer to the Load-Balancing Group - Cluster Schema section.

write, update, writeMultiple, and updateMultiple must have the Routing Field value as part of their Entries. An exception is thrown when the Routing Field has a null value when calling these operations with a partitioned space.

• The Routing Field for Entry-based classes is the first indexed field name returned from the String[] __getSpaceIndexedFields() method. The Routing Field is determined only once while the class is introduced to the space, so there are no performance implications for this behavior.
• POJO-based Entries use the @SpaceRouting annotation to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards).
• ExternalEntry-based Entries use the routingFieldName to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards).
• PONO-based Entries use the RoutingIndex attribute to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards).

If Routing Field is not defined, the first indexed field value hashcode is used as the routing value.

If there is no indexed defined and implicit indexing is turned on, the first Entry field value hashcode is used to determined the target partition. The first Entry field is calculated by sorting all Long and String type fields using their names in an ascending order. The first field in this list is the routing field.

When using a template that has a null value as part of the Routing Field with batch operations (takeMultiple, readMultiple) in a partitioned space, a parallel query is executed against all partitions, resulting in a result set that is accumulated from all partitions. The result set might be large, since the matching population target can span all Entries across all partitions.

Running Partitioned Space

To set up a partitioned space, you should use the partitioned cluster schema as part of the space URL that starts the space, together with the total cluster members and space instance member ID.

To start partitioned space where each partition runs as a stand alone process with 3 partitions, you should have the following setup:

JavaSpace API:

Member1
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=1"
Member 2
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=2"
Member 3
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=3"

Map API:

Member1
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=1"
Member 2
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=2"
Member 3
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=3"

To access the partitioned space from the application have the following as part of your code:
JavaSpace API:

IJSpace space =(IJSpace)SpaceFinder.find("jini://*/*/mySpace");

Map API:

IMap cache =(IMap)CacheFinder.find("jini://*/*/mySpace");

Embedded Partitioned Space

You might want to run the partitioned clustered space as part of your application – this means the space running in the same memory address as the application. Any interaction between the application instances (running the embedded spaces) and the space itself does not involve any remote call. Interaction between the application instances and other space partitions using the regular remote calls mechanism – this is done in an implicit way. You may have other application instances, which do not run embedded space, interacting with the spaces running within other application instances.

This architecture allows the application instances to access the data stored within their embedded spaces in relatively fast way while this data is also available to other application instances in transparent manner.

Running Embedded Partitioned Space Cluster

To start partitioned space with 2 partitions running in embedded mode, your application should start the spaces in the following way:

JavaSpace API:

Member1
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=2&id=1");

Member 2
IJSpace space =
(IJSpace)SpaceFiner.find
("/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=2&id=2");

Map API:

Member1
IMap space = (IMap)CacheFiner.find
("/./mySpace?schema=cache&cluster_schema=partitioned&total_members=2&id=1");

Member 2
IMap space = (IMap)CacheFiner.find
("/./mySpace?schema=cache&cluster_schema=partitioned&total_members=2&id=2");

To allow applications that do not run the embedded space to access the partitioned space have the following as part of your code:

JavaSpace API:

IJSpace space =(IJSpace)SpaceFinder.find("jini://*/*/mySpace");

Map API:

IMap cache =(IMap)CacheFinder.find("jini://*/*/mySpace");

Adding Backup to Each Partition

In partitioned space topology, each space instance contains a different portion of the application data. Every space instance can be brought down or fail. To ensure the high availability of each partition, a backup instance should be set for each space partition. In this case you should use the partitioned-sync2backup schema.

When writing data into the partitioned space, each space replicates the data to its backup space.

Setting up a partitioned space with two primary partitions and one backup per primary partition is done using the following setup:

Partition 1
gsInstance 
"/./mySpace?cluster_schema=partitioned-sync2backup&total_members=2,1&id=1"
 
Partition 2
gsInstance
"/./mySpace?cluster_schema=partitioned-sync2backup&total_members=2,1&id=2"
 
Partition 1 backup
gsInstance 
"/./mySpace?cluster_schema=partitioned-sync2backup&total_members=2,1&id=1&backup_id=1"
 
Partition 2 backup
gsInstance
"/./mySpace?cluster_schema=partitioned-sync2backup&total_members=2,1&id=2&backup_id=1"

total_members={number of primary instances, number of backup instances per primary} – e.g., total_members=2,1, means that this cluster contains two partitions having one backup instance each. The backup_id is used to define whether the instance is a backup instance or not. If this attribute is not defined, the instance will be considered a primary instance. The container name will be translated in this case to <space name>container<id><backup_id>. e.g., mySpace_container1_1.

For details on how a network of processors elects a unique processor (a leader), and how to avoid split-brain scenarios, refer to the Active Election and Avoiding Split-Brain Scenarios section.

Failover of a Partitioned Space with Backup

When running a partitioned space with backups, and one of the partitions fails or shuts down, the backup instance moves from standby mode into active mode take over. All operations are routed into the backup instance. When the master is running in transient mode and is restarted, it will recover its data from its backup instance. If the master is running in persistent mode you may recover all its data from its backup partner, or use its persistent data source to recover and get only the updates from the time it failed from its backup instance – see the <force-cold-init> parameter as part of the space schema file <persistent> tag. After the original space completes the recovery phase, it is not available for clients (standby mode) until its turn to be the active space – i.e. the current backup that is running in active mode will continue to serve the clients even after the original master has fully recovered. You may change this behavior and let the original master move into active mode immediately after completing the recovery using the <fail-back> cluster schema failover group configuration.

Workers Running Partitioned Space in Embedded Mode

You may configure the cluster to allow each application instance running an embedded partitioned space to access only its embedded space and have other application instances that do not run any embedded space to access all partitions to feed the data into the different partitions. This architecture is useful when the application instances acting as workers, performing take operations on incoming requests written by a remote master.

You may run this architecture using backup spaces and other application instance to insure high availability in case one of the processes running the application instances and its embedded space (running in primary mode) failed. In this case , as long as the primary space instance is running , the application instance running the backup space access the primary space and not its backup instance - this involves remote calls. When the primary failed, the application running the backup instance access its embedded space where no remote calls involved.

In this case the cluster schema load balancing policy should be modified to have:

<load-bal-policy>
	<load-bal-impl-class>com.gigaspaces.cluster.loadbalance.LoadBalanceImpl
	</load-bal-impl-class>
	<write>
		<policy-type>hash-based</policy-type>
		<broadcast-condition>broadcast-if-null-values
		</broadcast-condition>
	</write>
	<default>
		<policy-type>local-space</policy-type>
		<broadcast-condition>broadcast-disabled
		</broadcast-condition>
	</default>
</load-bal-policy>

For cluster schemas that you can use, refer to: partitioned schema without backup space partitioned schema with backup space

Running partitioned space with two partitions where the application running an embedded space done using the following setup:

Partition 1
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=1");
 
Partition 2
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=2");

Running partitioned space where the application running an embedded space with two primary partitions and one backup per primary partition done using the following setup:

Partition 1
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=1");
 
Partition 2
IJSpace space= (IJSpace)SpaceFiner.find("/./mySpace?
cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=2");
 
Partition 1 backup
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=1&backup_id=1");
 
Partition 2 backup
IJSpace space= (IJSpace)SpaceFiner.find
("/./mySpace?cluster_schema=partitioned-sync2backup_emb_worker&total_members=2,1&id=2&backup_id=1");

To allow applications that do not run the embedded space to access the partitioned space have the following as part of your code:

IJSpace space =(IJSpace)SpaceFinder.find("jini://*/*/mySpace");

Partitioned Space with IWorker Implementation

You may run partitioned space cluster where each space running IWorker implementation . With this topology you may use the partitioned schema as is since the IWorker implementation can access only the space hosting the worker.

With this architecture the IWorker implementation managed by the space and cannot access remote partitions in transparent way.

Cleaning the space will initialize the IWroker implementation.

Applications can access the partitioned space as usual.

Partitioned Space with Backup and Local space

The Partitioned Space with Backup and Local space topology allows you to store unlimited amount of data within a remote partitioned cache while having a local cache running at the client side. The local cache is updated with the master partitioned space changes via a push or pull update mechanism. Data from the client local cache is evicted based on the selected policy. This topology is optimal when your application is read mostly – i.e. 80% read and 20% updates.

Only changes to objects at the master spaces are propagated into the client local cache. New objects are not pushed into the local cache. When one of the partitioned spaces fails, its backup space takes over.

Lease renew and cancel Operations are Passed to the Backup Space lease.renew sets a new lease time, and lease.cancel removes the Entry from the space. If the cancel/renew operation is performed on a partitioned space that has already failed, or fails at the exact time the operation is being performed, the system passes immediately to the backup space, and cancels/renews the lease there.

To set up a partitioned space with a local cache, you should use the partitioned cluster schema as part of the space URL that starts the space together with the total cluster members and space instance member ID.

To start partitioned space where each partition runs as a stand alone process with 3 partitions, you should have the following setup:

JavaSpace API:

Member1
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=1"
Member 2
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=2"
Member 3
gsInstance
"/./mySpace?schema=defualt&cluster_schema=partitioned&total_members=3&id=3"

Map API:

Member1
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=1"
Member 2
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=2"
Member 3
gsInstance
"/./mySpace?schema=cache&cluster_schema=partitioned&total_members=3&id=3"

To access the partitioned space from the application, have the following as part of your code:

JavaSpace API:

IJSpace space = (IJSpace)SpaceFinder.find("jini://*/*/mySpace?useLocalCache");

Map API:

IMap cache =(IMap)CacheFinder.find("jini://*/*/mySpace?useLocalCache");