简介
数据是用于管理、挖掘和操作数据的所有计算系统的核心元素。在 Internet 年代，应用程序不仅要求即时访问数据，通常还以压倒性的近乎同步的请求尝试该访问。尽管 数据库技术有了很大提高，集中式数据存储对这种需求和响应能力的应用程序来说还是存在问 题。
IBM WebSphere eXtreme Scale 为高容量和高 SLA（服务级别协议）应用程序提供 集中式数据访问选择。WebSphere eXtreme Scale 通过缓存技术将数据拉近应用程序。将数据 移近应用程序可获得以下优势：
本地数据可改善应用程序的性能。 这既包括缓存数据 使其接近应用程序，又包括复制靠近（分区）数据的应用程序逻辑，以实现并行处理。
为频繁访问的数据提供缓存可以节省时间或降低数据库的争用和总体请求容量。 这转而降低数 据库级的硬件和许可成本，且可为共享该资源的应用程序提高数据库总体响应能力。
将 数据拉近应用程序可提高可用性。WebSphere eXtreme Scale 还提供了复制整个环境中的数据 的特性，从而进一步提高弹性。
与访问基于 SQL 的数据相比，以最终的本机应用程序 形式（对象）缓存数据可减小路径长度。
缓存复杂业务逻辑的结果可加快后续调用，并 降低总体解决方案成本。
WebSphere eXtreme Scale 是一种通用、高速的缓存解决方案 ，可在各种不同的设计中予以配置和使用。不过，您不能盲目地使用 WebSphere eXtreme Scale 提供的 API，并想当然地认为它会减轻数据库的工作重负，使您的应用程序更快地运行 。作为提高应用程序性能的一种策略，缓存应当被明智谨慎地应用。同样地，您不能想当然地 认为您的应用程序在遇到硬件故障时具有弹性，除非您为此筹备了有意识的计划。本文考查了 大量最佳实践，帮助您构建高性能和高弹性的 WebSphere eXtreme Scale 应用程序。
查询的合理使用
当您想知道如何在一个缓存解决方案中使用 WebSphere eXtreme Scale 时，需要考虑的一个首要设计原则很简洁但很重要：
WebSphere eXtreme Scale 不是一 个关系数据库。
然而，很多首次 WebSphere eXtreme Scale 实现都会犯假设这样一个 通病。但怎么会有这种想法产生呢？有时它是因未考虑 WebSphere eXtreme Scale API 不同方 面的性能影响而产生的。
WebSphere eXtreme Scale 有两个不同的 API，用于定义将对 象放入缓存和从缓存中获取对象的方式：
第一个是 Map API，它基于 java.util.Map API。在使用 Map API 时，您要有效对待网格中的对象，如同它们是本地哈希映射中的对象一 样。使用 insert()、put() 和 get() 等方法将对象放到网格中并从网格中检索它们。有了 Map API，网格的最合理用法就变得一清二楚：您仅需在合适的键处将对象放入，并使用同一个 键查询对象。当考虑第二个可用 WebSphere eXtreme Scale API，即 EntityManager API 时， 就会产生数据库混乱。
EntityManager API 是仿照 JPA (Java Persistence API) 实体模型建模的。使用 EntityManager API 时，会使用注释描述置入 WebSphere eXtreme Scale 缓存中的实体。使用 EntityManager.persist() 方法将对象存储到网格中，与对 JPA 所做的处理一样。不过，与 JPA 的相似性有时致使开发人员做出一些效率低下的选择，从而导致对产品的次佳使用。您可 以使用 find() 方法或查询方法来查询实体，前者根据对象的键检索对象，而后者根据一系列 属性值查询对象。
首次使用 WebSphere eXtreme Scale 的用户可能过多依赖于 WebSphere eXtreme Scale EntityManager API 的查询功能，特别是在将 WebSphere eXtreme Scale 纳入专为数据库访问定制的现有应用程序时。WebSphere eXtreme Scale 基本上是一个 缓存提供者。查询功能是产品的一个便捷特性，但它不受高端数据库中所有高级查询优化器的 支持。因此，WebSphere eXtreme Scale 最精于根据对象的键查找对象，而不是根据查询定位 该对象。这又涉及到另一个主要原则：