47,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A data grid is a means of combining computing resources. Data grids provide a way to distribute object storage and add capacity on demand in the form of CPU, memory, and network resources from additional servers. All three resource types play an important role in how fast data can be processed, and how much data can be processed at once. WebSphere eXtreme Scale provides a solution to scalability issues through caching and grid technology. Working with a data grid requires new approaches to writing highly scalable software; this book covers both the practical eXtreme Scale libraries and design patterns that will help you build scalable software.
Starting with a blank slate, this book assumes you don't have experience with IBM WebSphere eXtreme Scale. It is a tutorial-style guide detailing the installation of WebSphere eXtreme Scale right through to using the developer libraries. It covers installation and configuration, and discusses the reasons why a data grid is a viable middleware layer. It also covers many different ways of interacting with objects in eXtreme Scale. It will also show you how to use eXtreme Scale in new projects, and integrate it with relational databases and existing applications.
This book covers the ObjectMap, Entity, and Query APIs for interacting with objects in the grid. It shows client/server configurations and interactions, as well as the powerful DataGrid API. DataGrid allows us to send code into the grid, which can be run where the data lives. Equally important are the design patterns that go alongside using a data grid. This book covers the major concepts you need to know that prevent your client application from becoming a performance bottleneck. By the end of the book, you'll be able to write software using the eXtreme Scale APIs, and take advantage of a linearly scalable middleware layer.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 357
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
IBM WebSphere eXtreme Scale 6
Anthony Chaves
IBM WebSphere eXtreme Scale 6
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: November 2009
Production Reference: 1271009
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847197-44-3
www.packtpub.com
Cover Image by Paul Bodea (<[email protected]>)
Credits
Author
Anthony Chaves
Reviewers
Billy Newport
Jeremiah Small
Acquisition Editor
James Lumsden
Development Editor
Dhiraj Chandiramani
Technical Editors
Bhupali Khule
Pallavi Kachare
Copy Editor
Leonard D'Silva
Indexer
Monica Ajmera
Hemangini Bari
Rekha Nair
Editorial Team Leader
Akshara Aware
Project Team Leader
Lata Basantani
Project Coordinator
Joel Goveya
Proofreader
Joel T. Johnson
Graphics
Nilesh Mohite
Production Coordinator
Shantanu Zagade
Cover Work
Shantanu Zagade
About the Author
Anthony Chaves is a software developer interested in application scalability. He started the Boston Scalability User Group (BostonSUG) in 2007. BostonSUG features monthly guests who give talks about their work on building more highly scalable software.
After graduating from college, Anthony went to work for a large phone company in the Enterprise Services division. He developed software on Z/OS and Linux, bridging the gap between legacy applications written in COBOL and new projects using J2EE.
Anthony currently runs a software consulting company based in north-east Massachusetts. In the past, he has worked with large financial companies, data security companies, and early-stage start-ups.
Anthony's favorite development interests include many different methods of webapp user authentication and mobile sensor networks created with cell phones.
Anthony writes about software at http://blog.anthonychaves.net.
I would like to thank my beautiful wife Christina and daughter Olivia for encouraging me to face the challenge of writing this book. Thank you for putting up with me when working all night and well into the morning, and my grumpiness during the day.
I also have to thank Billy Newport for fielding my phone calls and emails filled with questions. He pointed me in new directions and helped me find what would be most useful to developers learning about WebSphere eXtreme Scale.
I would like to thank Packt Publishing for asking me to write this book and trying as best they could to keep me on any schedule.
About the Reviewers
Billy Newport is a Distinguished Engineer working on WebSphere eXtreme Scale and on WebSphere high availability. He's worked at IBM since September 2001. Besides his current activities, he helped add advanced APIs like the WorkManager APIs (JSR 236/237). Prior to IBM, he worked as an independent consultant at a variety of companies in investment banking, telcos, publishing, and yellow pages over the previous 13 years in over 10 countries. He graduated from the Waterford Institute of Technology in Ireland with a Bachelors in Applied Computing in 1989.
When not working at IBM, he's busy racing cars and running his drivers' education portal (http://www.trackpedia.com).
Jeremiah Small holds a BS degree in Computer Science from the University of Massachusetts at Amherst, and a Masters Certificate in Information Security from Boston University. He has over 13 years of experience as a software engineer and has designed and built highly-scalable, distributed systems in the education, security, and telecommunications industries. He is currently working for RSA, the Security Division of EMC.
Preface
This is a book about in-memory data grids, particularly IBM WebSphere eXtreme Scale. An in-memory data grid (IMDG) lets us build more scalable data stores by partitioning data across many different servers. By "scaling out" across many servers instead of "scaling up" by using more powerful servers we can support more clients and data while keeping hardware costs low. One of the nicest things about working with eXtreme Scale is that it's easy to use. We don't need any special hardware or complicated software configuration wizards. It's as easy as downloading the light weight eXtreme Scale JAR file. The eXtreme Scale APIs are well defined and give us a lot of functionality.
This book explores many features of using an in-memory data grid starting from the object cache and going through using the compute grid functionality that lets us use the computing resources of the grid for business logic. We also explore how we can structure our data in a way that lets us take advantage of partitioned data stores.
What this book covers
Chapter 1: What is a Data Grid gets us up and running with IBM WebSphere eXtreme Scale. We download eXtreme Scale, add it to the build path, and get a small sample program running. We also explore some general in-memory data grid concepts.
Chapter 2: The ObjectMap API focuses on using eXtreme Scale as a key/value object cache. ObjectMap gives us a way to interact with the cache using familiar concepts associated with map-like data structures. We also look at working with distributed maps.
Chapter 3: Entities and Queries goes beyond a basic key/value object store. The Entity API lets us work with our objects using relationships between them. The Query API lets us use a SQL-like syntax to work with certain Entity objects in the cache.
Chapter 4: Database Integration explores areas where using a data grid makes sense and some areas where it may not make sense. Many applications already use a database and we can do some integration with eXtreme Scale to make cached objects persistent in the database.
Chapter 5: Handling Increased Load starts to look at some of the eXtreme Scale features that let us scale out across many servers. We cover configuration and dynamic deployments as well as the eXtreme Scale building blocks.
Chapter 6: Keeping Data Available covers more of the eXtreme Scale features that let us survive server or even data center failure. We also explore what happens when we add resources to or remove resources from a deployment.
Chapter 7: The DataGrid API goes beyond an object cache; a data grid provides compute grid functionality. By co-locating code with our data we're able to improve application performance and responsiveness.
Chapter 8: Data Grid Patterns looks at some problems that data grids can help us solve. We also show how we can structure our data to take the best advantage of a partitioned data store.
Chapter 9: Spring Integration deals with the popular Spring framework, which is used in many applications. Using eXtreme Scale with Spring is easy, and there are a few integration points that we cover. We can configure eXtreme Scale with Spring-managed beans. We can also instantiate eXtreme Scale objects using Spring.
Chapter 10: Putting It All Together provides an example of using eXtreme Scale with an existing project. Where do we start? What should we be aware of when migrating to a data grid? We also take a last look at what we can cache and where it is most helpful.
What you need for this book
You need a Java SDK to work with IBM WebSphere eXtreme Scale. Detailed instructions are provided in Chapter 1. Familiarity with a Java build environment is recommended. In this book, we occasionally mention the Eclipse IDE, though Eclipse is not required. The IBM JDK will require the least amount of effort to use these examples. Again, detailed instructions are provided in Chapter 1.
Who this book is for
This book is aimed at intermediate-level JavaEE Developers who want to build applications that handle larger data sets with massive scalability requirements. No previous experience of WebSphere eXtreme Scale is required.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an email to<[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or web site name immediately so that we can pursue a remedy.
Please contact us at <[email protected]>with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]>if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. What is a Data Grid
We have many software packages which make up the so-called "middleware" layer. Application servers, message brokers, enterprise service buses, and caching packages are examples of this middleware layer that powers an application. The last few years have seen the introduction of more powerful caching solutions that can also execute code on objects stored in the cache. The combination of a shared cache and executable code spread over many processes is a data grid.
Caching data is an important factor in making an application feel more responsive, or finish a request more quickly. As we favor horizontal scale-out more, we have many different processes sharing the same source data. In order to increase processing speed, we cache data in each process. This leads to data duplication. Sharing a cache between processes lets us cache a larger data set versus duplicating cached data in each process. A common example of a shared cache program is the popular Memcached. A shared cache moves the cache out of the main application process and into a dedicated process for caching. However, we trade speed of access for caching a larger data set, this trade is acceptable when using larger data sets.
Typically, our applications pull data from a data source such as a relational database and perform some operations on it. When we're done, we write the changes back to the data source. The cost of moving data between the data source and the point where we execute code is costly, especially when operating on a large data set. Typically, our complied source code is much smaller than the size of data we move. Rather than pulling data to our code, a data grid lets us push our code to the data. Co-locating our code and data by moving code to data is another important feature of a data grid.
Because of their distributed nature, data grids allow near-linear horizontal scalability. Adding more hardware to a data grid lets it service more clients without diminishing returns. Additional hardware also lets us have redundancy for our cached data. Ease of scalability and data availability are two major benefits of using data grids.
A shared cache and a container to execute application code are just two factors which make up a data grid. We'll cover those features most extensively in this book. There are several different data grid platforms available from major vendors. IBM is one of those vendors, and we'll use IBM WebSphere eXtreme Scale in this book. We will cover the major features of eXtreme Scale, including the APIs used to interact with the object cache, running code in the grid, and design patterns that help us get the most out of a data grid.
This chapter offers a tutorial on how to get IBM WebSphere eXtreme Scale, configure our development environment to use it, and write a "Hello, world!" type application. After reading this chapter, you will:
Data grid basics
One part of a data grid is the object cache. An object cache stores the serialized form of Java objects in memory. This approach is an alternative to the most common form of using a relational database for storage. A relational database stores data in column form, and needs object-relational mapping to turn objects into tuples and back again. An object cache only deals with Java objects and requires no mapping to use. A class must be serializeable though.
Caching objects is done using key/value tables that look like a hash table data structure. In eXtreme Scale terminology, this hash table data structure is a class that implements the com.ibm.websphere.objectgrid.BackingMap interface. A BackingMap can work like a simple java.util.Map, used within one application process. It can also be partitioned across many dedicated eXtreme Scale processes. The APIs for working with an unpartitioned BackingMap and a partitioned BackingMap are the same, which makes learning how to use eXtreme Scale easy. The programming interface is the same whether our application is made up of one process or many.
Using a data grid in our software requires some trade-offs. With the great performance of caching objects in memory, we still need to be aware of the consequences of our decisions. In some cases, we trade faster performance for predictable scalability. One of the most important factors driving data grid adoption is predictable scalability in working with growing data sets and more simultaneous client applications.
An important feature of data grids that separates them from simple caches is database integration. Even though the object cache part of a data grid can be used as primary storage, it's often useful to integrate with a relational database. One reason we want to do this is that reporting tools based on RDBMS's are far more capable than reporting tools for data grids today. This may change in the coming years, but right now, we use reporting tools tied in to a database.
WXS uses Loaders to integrate with databases. Though not limited to databases, Loaders are most commonly used to integrate with a database. A Loader can take an object in the object cache and call an existing ORM framework that transforms an object and saves it to a database. Using a Loader makes saving an object to a database transparent to the data grid client. When the client puts the object into the object cache, the Loader pushes the object through the ORM framework behind the scenes. If you are writing to the cache, then the database is a thing of the past.
Using a Loader can make the object cache the primary point of object read/write operations in an application. This greatly reduces the load on a database server by making the cache act as a shock absorber. Finding an object is as simple as looking it up in the cache. If it's not there, then the Loader looks for it in the database. Writing objects to the cache may not touch the database in the course of the transaction. Instead, a Loader can store updated objects and then batch update the database after a certain period of time or after certain number of objects are written to the cache. Adding a data grid between an application and database can help the database serve more clients when those clients are eXtreme Scale clients since the load is not directly on the database server:
This topology is in contrast to one where the database is used directly by client applications. In the following topology the limiting factor in the number of simultaneous clients is the database.
Applications can start up, load a grid full of data, and then shut down while the data in the grid remains there for use by another application. Applications can put objects in the grid for caching purposes and remove them upon application completion. Or, the application can leave them and those objects will far outlive the process that placed them in the grid.
Notice how we are dealing with Java objects. Our cache is a key/value store where keys and values are POJOs. In contrast, a simple cache may limit keys and values to strings. An object in a data grid cache is the serialized form of our Java object. Putting an object from our application into the cache only requires serialization. Mapping to a data grid specific type is not required, nor does the object require a transform layer. Getting an object out of the cache is just as easy. An object need only be deserialized once in the client application process. It is ready for use upon deserialization and does not require any transformation or mapping before use. This is in contrast to persisting an object by using an ORM framework where the framework generates a series of SQL queries in order to save or load the object state. By storing our objects in the grid, we also free ourselves from calling our ORM to save the objects to the database if we choose. We can use the data grid cache as our primary data store or we can take advantage of the database integration features of eXtreme Scale and have the grid write our objects to the database for us.
Data grids typically don't use hard disks or tapes for storing objects. Instead, they store objects in the memory, which may seem obvious based on the name in-memory data grid. Storing objects in the memory has the advantage of keeping objects in a location with much lower access time compared to physical storage. A network hop to connect to a database is going to take the same amount of time as a network hop to a data grid instance. The remote server storing or retrieving of the data from the grid is much faster than the equivalent operation on a database due to the nature of the storage medium. A network hop is required in a distributed deployment. This means that an object isn't initially available in the same address space where it will be used. This is one of those trade-offs mentioned earlier. We trade initial locality of reference for predictable performance over a large data set. What works for caching small data sets may not be a good idea when caching large data sets.
Though the access time of storing objects in memory is an advantage over a database hit, it's hardly a new concept. Developers have been creating in-memory caches for a long time. Looking at a single-threaded application, we may have the cache implemented as a simple hash-map (see below). Examples of things we might cache are objects that result from CPU-intensive calculations. By caching the result, we save ourselves the trouble of recalculating it again the next time it is needed. Another good candidate for caching is storing large amounts of read-only data.
In a single-threaded application, we have one cache available to put data. The amount of data that fits in our cache is limited by the amount of JVM heap size available to it. Depending on the JVM settings, garbage collection may become an issue if large numbers of objects are frequently removed from the cache and go out of the application scope. However, this typically isn't an issue.
This cache is located in the same address space and thread as the code that operates on objects in the cache. Cached objects are local to the application, and accessing them is about as fast as we can get. This works great for data sets that fit in the available heap space, and when no other processes need to access these cached objects.
Building multi-threaded applications changed the scope of the cache a little bit. In a single-threaded application, we have one cache per thread. As we introduce more threads, this method will not continue to work for long:
Each cache contains the same key/value pairs as the other caches.
As each of our N threads has its own cache, the JVM heap size must now be shared among N caches. The most prominent problem with this method of caching is that data will be duplicated in multiple caches. Loading data into one cache will not load it into the others. Depending on the eviction policy, we could end up with a cache hit rate that is close to 0 percent over time. Rather than maintaining a cache per thread, developers started to use a singleton cache:
The singleton cache is protected by the Singleton design pattern in Java. The Singleton design pattern (almost) assures us that only one instance of a particular object exists in the JVM, and it also provides us with a canonical reference to that object. In this way, we can create a hash-map to act as our cache if one doesn't already exist, and then get that same instance every time we look for it. With one cache, we won't duplicate data in multiple caches and each thread has access to all of the data in the cache.
With the introduction of the java.util.concurrent package, developers have safer options available for caching objects between multiple threads. Again, these strategies work best for data sets that fit comfortably in one heap. Running multiple processes of the same application will cache the same data in each process:
What if our application continues to scale out to 20 running instances to do the processing for us? We're once again in the position of maintaining multiple caches that contain the same data set (or subset of the same data set). When we have a large data set that does not fit in one heap, our cache hit rate may approach 0 percent over time. Each application instance cache can be thought of as a very small window into the entire data set. As each instance sees only a small portion of the data set, our cache hit rate per instance is lower than an application with a larger window into the data set. Locality of reference for an object most likely requires a database hit to get the object and then cache it. As our locality of reference is already poor, we may want to insert a shared cache to provide a larger window into the data set. Getting an object from an object cache is faster than retrieving the object from a database, provided that object is already cached.
What we really want is an object cache where any thread in any application process can access the data. We need something that looks like this:
A data grid is made up of many different processes running on different servers. These processes are data grid, or eXtreme Scale processes, not our application processes. For each eXtreme Scale process, we have one more JVM heap available to an object cache. eXtreme Scale handles the hard work of distributing objects across the different data grid processes, making our cache look like one large logical cache, instead of many small caches. This provides the largest window possible into our large data set. Caching more objects is as simple as starting more eXtreme Scale processes on additional servers.
We still have the same number of application instances, but now the cache is not stored inside the application process. It's no longer a hash-map living inside the same JVM alongside the business logic, nor is it stored in an RDBMS. Instead, we have conscripted several computers to donate their memory. This lets us create a distributed cache reachable by any of our application instances. Though the cache is distributed across several computers, there is no data duplication. The data is still stored as a map where the keys are stored across different partitions, such that the data is distributed as evenly as possible.
When using an object cache, the goal is to provide a window as large as possible into a large data set. We want to cache as much data as we can in memory so that any application can access it. We accept that this is slower than caching locally because using a small cache does not produce acceptable cache hit rates. A network hop is a hop, whether it is to connect to a database or data grid. A distributed object cache needs to be faster than a database for read and write operations, only after paying the overhead of making a network connection.
Each partition in a distributed object cache holds a subset of the keys that our applications use for objects. No cache partition stores all of the keys. Instead, eXtreme Scale determines which partition to store an object in, based on it's key. Again, the hard work is handled by eXtreme Scale. We don't need to have knowledge of which partition an object is stored in, or how to connect to that partition. We interact with the object cache as if it were a java.util.Map and eXtreme Scale handles the rest:
In-memory data grids can do a lot more than object caching, though that's the use we will explore first. Throughout this book, we will explore additional features that make up a data grid and put them to use in several sample applications.
Getting IBM WebSphere eXtreme Scale
IBM WebSphere eXtreme Scale is an in-memory data grid formerly known by the brand name Object Grid. There are two ways to get eXtreme Scale. First, eXtreme Scale is integrated with certain versions of IBM WebSphere Application Server. If you have a WebSphere Application Server 6.1 (or higher) deployment capable of integrating with WebSphere eXtreme Scale, then you should follow the instructions provided with your WebSphere software. WebSphere Application Server 6.1 contains additional features that are enabled only when WebSphere eXtreme Scale is present.
If you do not have an installation of WebSphere eXtreme Scale by using your WebSphere Application Server 6.1 license, then you can use the standalone edition. The standalone WebSphere eXtreme Scale trial edition is functionally equivalent to the full licensed version. Everything that can be done with the licensed edition can be done with the trial edition. The programming and configuration interfaces are identical. If you develop an application using the trial edition, it can be deployed to the full edition. All of the examples in this book have been tested with the WebSphere eXtreme Scale 6.1.0.4 FIX2 trial edition available as a multi-platform download. You can download the trial edition from IBM Developer Works at http://www.ibm.com/developerworks/downloads/ws/wsdg/. The file you're looking for is named objectgridtrial610.zip.
IBM strongly recommends that you use an IBM JVM for developing and running your WebSphere eXtreme Scale application. In the event that you use a non-IBM JVM, you should manually integrate the IBM Object Request Broker (ORB) with your JVM. Other ORBs might work, but they are not tested by IBM. The Sun JVM ORB does not work as of this writing. Please see http://www.ibm.com/developerworks/wikis/x/niQ for more information. You can download IBM Java developer kits from http://www.ibm.com/developerworks/java/jdk/. I created the examples with the IBM Development Package for Eclipse, though these examples will work with any of the JVMs listed there.
Setting up your environment
Unzip the objectgridtrial610.zip into an empty directory. Unzipping the file produces a directory named ObjectGrid. This directory contains everything you need to run local and distributed WebSphere eXtreme Scale instances.
In order to use the Object Grid classes in our first example, we need to add a few JAR files to our Java classpath. If you're using the command line tools, then add the following classpath option to your javac and java commands, while replacing the paths here with the appropriate paths for your environment and operating system:
That's all the setup you need for the command line tools at this time. If you're using the Eclipse environment, then we need to add these JAR files to the project build path:
We're now ready to work with a short sample to get our feet wet in the WebSphere eXtreme Scale world.
