All Data Grid Topologies

  Search Here
Searching XAP 6.0 Documentation

                                               

Summary: Deploying common topologies: replicated (sync/async), partitioned (with/without backup), ownership cluster.

Overview

Cluster topology is defined as a relationship between individual space instances. The relationship is composed of a combination of replication, load-balancing, and failover policies. This section describes the built-in supported topologies and how to run these.

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

Distributed unicast-based lookup service is now supported. For more details, refer to the Space URL section.

GigaSpaces supports the following built-in topologies via cluster schema configuration files. Please consult GigaSpaces support before you create new schemas or modify these:

Schema file Schema name Description More Details
sync_replicated-cluster-schema.xsl sync_replicated This topology replicates data in a synchronous manner between source and target spaces. Provides the highest level of coherency but impacts the client performance. Replicated Space Topology – Synchronous Replicated
async_replicated-cluster-schema.xsl async_replicated This topology replicates data in an asynchronous manner between source and target space. Data may not be coherent across the different spaces. Replication does not effect application performance. Replicated Space Topology – Asynchronous Replicated
partitioned-cluster-schema.xsl partitioned The partitioned topology provides best performance for large data sets. This topology allows to you store unlimited amount of data within the cluster by utilizing the accumulated memory size of all cluster machines. The partitioned topology routes the application's operations into difference spaces, thus storing different portions of the data in separate spaces. Partitioned Space Topology
async-repl-sync2backup-cluster-schema.xsl async-repl-sync2backup Mix between the async_replicated and the sync_replicated topologies. This topology replicates data between cluster members in an asynchronous manner and constructs backup(s) space for each cluster space where replication to backup spaces is done in a synchronous manner. This topology provides good data coherency between primary and backup spaces with minimal performance impact when replicating data to other cluster members. Replicated Space Topology – Asynchronous Replicated
primary_backup-cluster-schema.xsl primary_backup This topology constructs backup(s) spaces for a primary space. Replication from source space to backup space(s) is done in synchronous manner. Replicated Space Topology - Replicated Primary-Backup
partitioned-sync2backup-cluster-schema.xsl partitioned-sync2backup This topology constructs backup(s) for each partitioned space. Replication from each partition to its backup space is done in a synchronous manner. Partitioned Space Topology – Adding Backup to Each Partition
ownership-replicated-cluster-schema.xsl ownership-replicated To ensure data coherency for update operations you may use the ownership model. With this approach each space is responsible for performing updates on different segments of the data – i.e. there is no option to perform update operations on two copies of the same object located in different spaces at the same time – updates are always routed to the space that owns the Entry. Replicated Space Topology – Replicated Ownership Space

More in this Section


GigaSpaces 6.0 Documentation Contents (Current Page in Bold)

    Java

    C++

    .NET

    Middleware Capabilities

    Configuration and Management

Add GigaSpaces wiki search to your browser search engines!
(works on Firefox 2 and Internet Explorer 7)

Labels

 
(None)