Principles and best practices for building high-performance and highly resilient WebSphere EXtreme scale applications

Brief introduction

Data is the core element of all computing systems used to manage, mine, and manipulate data. In the Internet age, applications require not only instant access to data, but often an overwhelming, almost simultaneous request to try that access. Although database technology has improved significantly, centralized data storage is problematic for this requirement and responsiveness application.

IBM WebSphere EXtreme Scale provides centralized data access choices for high-capacity and high SLA (service level agreement) applications. The WebSphere eXtreme Scale brings data closer to the application by caching technology. Moving data closer to an application can have the following advantages:

Local data can improve the performance of your application. This includes both caching data close to the application and copying the application logic near the (partitioned) data to enable parallel processing.

Providing caching for frequently accessed data can save time or reduce the contention and overall request capacity of the database. This in turn lowers the hardware and licensing costs at the database level, and improves the overall database responsiveness of the application that shares the resource.

Bringing data closer to your application increases usability. The WebSphere EXtreme Scale also provides the characteristics of replicating data throughout the environment to further improve resiliency.

Caching data in the form of a final native application (object) reduces the path length compared to accessing sql-based data.

Caching the results of complex business logic can speed up subsequent calls and reduce overall solution costs.

WebSphere EXtreme Scale is a general-purpose, high-speed caching solution that can be configured and used in a variety of different designs. However, you cannot blindly use the APIs provided by the WebSphere EXtreme Scale and take it for granted that it eases the workload of your database and makes your application run faster. As a strategy for improving application performance, caching should be wisely and judiciously applied. Likewise, you cannot take for granted that your application is resilient when it encounters a hardware failure, unless you have a conscious plan in place to do so. This article examines a number of best practices to help you build high-performance and resilient WebSphere eXtreme Scale applications.

Reasonable use of the query

One of the primary design principles to consider when you want to know how to use WebSphere eXtreme Scale in a caching solution is simple but important:

WebSphere EXtreme Scale is not a relational database.

However, many of the first WebSphere EXtreme Scale implementations will be guilty of assuming such a common fault. But how could this idea have come about? Sometimes it is caused by not taking into account the different aspects of the performance impact of the WebSphere eXtreme Scale API.

The WebSphere eXtreme Scale has two different APIs that define how objects are put into the cache and retrieved from the cache:

The first is the Map API, which is based on the Java.util.Map API. When using the Map API, you want to treat objects in the grid effectively as if they were objects that were hit locally hash map. Use methods such as insert (), put (), and get () to place objects in the grid and retrieve them from the grid. With the Map API, the most reasonable use of the grid becomes clear: You only need to put the object in the appropriate keys and use the same key to query the object. Database clutter is generated when you consider the second available WebSphere EXtreme Scale API, the Entitymanager API.

The Entitymanager API is modeled on the JPA (Java™persistence API) entity model. When you use the Entitymanager API, you use annotations to describe the entities that are placed in the WebSphere eXtreme Scale cache. Use the Entitymanager.persist () method to store objects in a grid, just as you do with JPA. However, the similarity to JPA sometimes leads developers to make some inefficient choices that lead to suboptimal use of the product. You can use the Find () method or Query method to query the entity, which retrieves the object based on the key of the object, and the latter queries the object based on a series of attribute values.

Users who first use the WebSphere EXtreme Scale may rely too much on the query capabilities of the WebSphere EXtreme Scale Entitymanager API, especially when you include WebSphere EXtreme Scale in a specially designed Database to access a custom existing application. The WebSphere EXtreme Scale is basically a caching provider. Query functionality is a convenient feature of a product, but it is not supported by all advanced query optimizer in a high-end database. As a result, WebSphere eXtreme Scale is most adept at finding objects based on the key of an object, rather than locating the object based on a query. This, in turn, involves another key principle: