| | {include:pageTitle=OG_HEADER} |
| |  | {excerpt}This topic defines the inherently scalable nature of the ObjectGrid through the use of partitioned data. |
| | | {excerpt}ObjectGrid is inherently scalable through the use of partitioned data. |
| | {excerpt} |
| | |
 | | ObjectGrid can scale to thousands of containers. This is because each container is independent from the others. There are two exceptions where containers communicate between themselves. One is the availability management, or core grouping, protocol. This is an O(N ^2^) heartbeating and view maintenance algorithm but is mitigated by keeping the core group membership around 20. The other container communication is replication which is only peer to peer between shards. |
| | | ObjectGrid can scale to thousands of containers. This scalability is possible because each container is independent from the other containers. Two exceptions are when containers communicate between themselves. One exception is the availability management, or core grouping, protocol. This is an {{O(N ^2^)}} heart beating and view maintenance algorithm, but is mitigated by keeping the core group membership around 20. The other exception is replication, which is only peer to peer between shards. |
| | |
| | h3. Partitioning |
| | Partitioning is the mechanism that ObjectGrid uses to scale out an application. Partitioning is the separation of the application state into parts where each part contains some set of complete instance data. It is not like RAID striping which slices each instance across all stripes. Thus, each partition hosts the complete data for individual entries. This is a very effective means for scaling but is not applicable to all applications. Applications that require transactional guarantees across large sets of data will not scale and can not be made to partition effectively. ObjectGrid does not currently support two-phase commit across partitions. |
| | | Partitioning is the mechanism that ObjectGrid uses to scale out an application. Partitioning is the separation of the application state into parts where each part contains some set of complete instance data. It is not like Redundant Array of Independent Disks (RAID) striping, which slices each instance across all stripes. Each partition hosts the complete data for individual entries. This is a very effective means for scaling, but is not applicable to all applications. Applications that require transactional guarantees across large sets of data do not scale and cannot be partitioned effectively. ObjectGrid does not currently support two-phase commit across partitions. |
| | |
| | {note:title=Choose your number of partitions carefully} |
| | The number of partitions defined in the deployment policy directly affects the number of containers an ObjectGrid application can scale to. Each partition is made up of a Primary Shard and the configured number of Replica Shards. So (Number_Partitions*(1 + Number_Replicas)) is the number of containers that can be used to scale out a single application. |
| | | The number of partitions that are defined in the deployment policy directly affects the number of containers to which an ObjectGrid application can scale. Each partition is made up of a primary shard and the configured number of replica shards. So the {{(Number_Partitions*(1 + Number_Replicas))}} formula is the number of containers that can be used to scale out a single application. |
| | {note} |
| | |
| | h3. Distributed Clients |
| | The ObjectGrid client protocol supports very large numbers of clients. The partitioning strategy helps here assuming all clients are not always interested in all partitions because connections can then be spread across multiple containers. Clients connect directly to the partitions so latency is limited to one hop. |
| | | h3. Distributed clients |
| | The ObjectGrid client protocol supports very large numbers of clients. The partitioning strategy helps in this situation by assuming that all clients are not always interested in all partitions because connections can then be spread across multiple containers. Clients connect directly to the partitions so latency is limited to one hop. |
| | |
| | For more details on ObjectGrid partitioning, refer to the following pages: |
| | * [Introduction to partitioning] |
| | * [Clients and partitioning] |
| | * [DataGrid APIs and partitioning] |
| | |
| | {include:pageTitle=OG_FOOTER} |
