| | {include:pageTitle=OG_HEADER} |
| | |
| | {excerpt}The ObjectGrid is a primary storage database that fits in the _Extreme Transaction Processing_ middleware segment. It is not a traditional database and as such does not use secondary storage (writing to disk), as its mechanism for persistence. |
| | {excerpt} |
| | ---- |
| | Gartner defines *Extreme Transaction Processing*: |
| | {quote}We define XTP as "an application style aimed at supporting the design, development, deployment, management and maintenance of distributed TP applications characterized by exceptionally demanding performance, scalability, availability, security, manageability and dependability requirements." This definition matches the profile of applications such as online business-to-consumer services (such as online trading, betting and travel booking), but also of other classes of applications, such as micro-commerce, real-time monitoring and management (such as "intelligent car" applications), radio frequency identification-based tracking, automated financial trading, convergent network services in telecommunications, real-time fraud detection or real-time risk management. These applications generate orders of magnitude more transactions than those created by traditional TP systems because of their wider (multi-enterprise, national and global) reach. |
| | +Gartner RAS Core Research Note G00131036+{quote} |
| | ---- |
| | |
| | h3. Overview |
| |  | The ObjectGrid keeps the data close to the application logic, freeing up expensive or slow persistent storage devices. By operating in both a local or distributed mode, the ObjectGrid can provide solutions to several common problems. |
| | | The ObjectGrid keeps the data close to the application logic, freeing up expensive or slow persistent storage devices. By operating in both a local or distributed mode, the ObjectGrid can provide solutions to several common problems. The following sections describe some of the high level scenarios where ObjectGrid can be used. See topic: [ObjectGrid cache scenarios] for more detailed information. |
| | |
| | h4. An in-memory cache |
| | In the simplest case, the ObjectGrid can be used as an in-memory cache. It can be used to provide consistent, transactional access to temporary data within a single JVM. This can especially benefit high-concurrency applications where multiple threads need to access and modify transient data. The data kept in a local ObjectGrid can be indexed and retrieved using our query support or continuous query support. The ability to query the data can help developers greatly when working with large in memory datasets versus the limited data structure support provided with the JVM out of the box. |
| | |
| | !OG_IMAGES^ogover_inmemorycache.jpg|align=center! |
| | |
| | h4. A shared coherent cache |
| | The ObjectGrid can be used as a shared coherent cache, to provide transactional access to data to multiple components where a traditional database would otherwise be used. This can enhance the ease of development and deployment of the application by eliminating the need to configure the database. The cache is coherent from the point of view that all clients see the same cache, each piece of data is stored in exactly one server in the grid thus avoiding wasteful copies of records which would usually also be different versions. A coherent cache can also hold more data as more servers are added to the cluster. Each JVM holds a unique subset of the total data set. Larger clusters can both hold more data and service more requests for that data. This characteristic means it scales linearly as the cluster size grows. It also eliminates the need to push invalidation data around the cluster because there is no stale data, the coherent cache only holds the latest copy of each piece of data. |
| | |
| | !OG_IMAGES^ogover_sharedcache.jpg|align=center! |
| | |
| | h4. A traditional database "shock absorber" |
| | The ObjectGrid can be used to front a traditional database and offload some of the work pushed to the database by eliminating read activity normally pushed to the database. A coherent cache can be used with an application directly or indirectly using an object relational mapper. The coherent cache can then offload the database or backend from reads. In a slightly more complex scenario, such as transactional access to a data set where only some of the data requires traditional persistence guarantees, filtering can be used to offload even write transactions. |
| | |
| | !OG_IMAGES^ogover_shockabsorber.jpg|align=center! |
| | |
| | h4. A scalable, low latency, highly available, data store |
| | The ObjectGrid is built to be extremely scalable and still provide the lowest possible latencies by providing the capability to execute logic local to the data thus eliminating network latency as well as serialization costs normally incurred. |
| | |
| | In this scenario, the ObjectGrid is dynamically managed and is replicated and fault tolerant. However, the application is communicating with the local grid instance and the lifecycle of the application is coupled with the placement of the ObjectGrid. |
| | |
| | !OG_IMAGES^ogover_clusterinmem.jpg|align=center! |
| | |
| | h3. Getting started |
| | Visit the following topics for an overview of the various ObjectGrid features: |
| | |
| | * [ObjectGrid introduction] -- {excerpt-include:ObjectGrid Introduction|nopanel=true} |
| | * [ObjectGrid architecture] -- {excerpt-include:ObjectGrid architecture|nopanel=true} |
| | * [ObjectGrid high scalability] -- {excerpt-include:ObjectGrid High Scalability|nopanel=true} |
| | * [ObjectGrid high availability] -- {excerpt-include:ObjectGrid High Availability|nopanel=true} |
| | * [ObjectGrid Performance|ObjectGrid Performance Overview] -- {excerpt-include:ObjectGrid Performance Overview|nopanel=true} |
| | * [ObjectGrid Security] -- {excerpt-include:ObjectGrid security|nopanel=true} |
 | | * [ObjectGrid cache scenarios] -- {excerpt-include:ObjectGrid cache scenarios|nopanel=true} |
| | |
| | |
| | {include:pageTitle=OG_FOOTER} |
