Gentle into to DataGrid technology and customer use cases

XTP using WebSphere eXtreme Scale @billynewport IBM Distinguished Engineer

Agenda
Gentle introduction to DataGrids
General usage Patterns
What they are good for and bad for
Customer use cases

Traditional Cache Operation EIS Invalidation chatter App App App App A A A A App Invalidation chatter

WXS based Cache Operation EIS Cache is 4x larger! Cache is 5x larger! Cache cluster can be co-located with the application or run in it ’s own tier. App App App App A B D C C ’ D ’ A A App A B ’ A ’

First, what ’s a cache?
A database cache? A page fragment cache? A service Cache?
TOO SPECIFIC !
A cache is a tool for reducing application path length
OR the distance data has to travel before it gets to the customer/ data sink
DB OR Map Logic Data Service Web Channel Mobile Channel Akamai

Retailers
Insurance Companies
Health care
Retail Banking
Hotel
Travel Agencies
Investment Banking
Telco
Government
Utilities
Trucking Companies
Customer Diversity Data Grids are not just for investment banks!

Market Drivers 1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008.

Market Drivers
The competition is only a click away in today's web-facing world.
Response times are critical to giving customers a good experience and generating revenue.
Customer sessions are becoming more critical.
The cost of attracting new customers to your web site for enrollment is significant.
Losing the data that they have entered will likely create a negative impression and result much higher abandonment rates

Market Drivers
Customers are looking to control the growth of their enterprise systems.
A caching tier in front of it can allow more growth without expanding the existing enterprise systems.
Customers are looking at building front ends more independent from the back ends.
Public and private cloud like systems will need elastic state management solutions such as IBM WebSphere eXtreme Scale.
More resilient front ends decoupled from back ends.

IBM WebSphere eXtreme Scale
Proven mature product:
Third major release of product with V7.0
Public References
Private References
Used at some of the largest web sites/companies in the world
Lightweight runtime footprint (15MB jar)
Integrates with all versions of WebSphere and almost any Java-based application container or Java Virtual Machine
Proven multi-data center capabilities
Proven low-latency access to data

Common set of patterns
Side Cache
Hibernate/ OpenJPA L2 cache
Dynacache (ND 6.1/ ND 7.0)
Page fragment cache
Web services cache
Command cache
SOA State store
SOA Result cache
App App App App

Inline backend cache
Loaders used to integrate with an existing data service
Read through cache
Write through cache
System of Record Data Store
Cache is used as the system of record
Write behind technology pushes changes asynchronously to the backend.
App App App App Loader

HTTP Session Store
Application uses standard HTTPSession APIs
Can be shared between applications sharing same domain name
Grid runs inside web cluster JVMs using affinity
Application Session
Application uses WXS APIs to manipulate the shared session
Works even when web apps use different domain names
Multi data center support for sessions

XTP (eXtreme Transaction Processing)
Lowest possible latency
Application code runs in grid itself
Think Grid + Stored Procedures
Write behind
Databases relegated to durable log/ search and reports

CRUD Evolves with KV or NoSQL stores
Traditionally, we think of the big four operations:
(C)reate
(R)ead
(U)pdate
(D)elete
This changes now to become:
(P)ut
(R)etrieve by key
(D)elete
** (Q)uery (this is different than search)

Schema becomes more flexible
Traditionally, the data store understands the data schema and enforces constraints.
KV or NoSQL separates the schema management from the storage.
Schema is more like a JSON value
Developers more in control
More flexible to evolve than SQL oriented approach
Remember, it ’s about retrieval, not query/search!

SQL Benefits
Relationships through joins
Easy indexing
No consistency issues, one copy/system of record
No need to partition data model.

SQL means domain centric
Think about the data, find the nouns
Nouns become tables
identify attributes/keys
normalize the tables to Nth normal form…

Domain centric
Use SQL to ask any question
Use indexes to speed up SQL queries.
Think Data Model first, worry about questions/access patterns later.

Question Centric
NoSQL seems to start with the questions rather than the data.
Once we know the questions then we can layout the data using some partitioned model.
We can now scale it out and all is good
What could you do if scale wasn ’t an issue?

Question Centric Ask a different question maybe?

Table scans aka Map/Reduce…
Multi-machine table scans won ’t work for anything online.
Google doesn ’t map/reduce for every google search!
Offline complex queries can be done using Map/Reduce
You need to write code for most complex searches!

SOME USE CASES

Client Usage: One of the largest retail US banks Retail Banking & Investments 35x reduced response times 22 Million online banking users
Next-generation Online Banking
Before: 700ms to login with 2 backend calls
After: 20ms to login with profile cache access
$6M/year cost savings in MIPs reduction
700k logins per hour across 3 data centers
8Gb of data transfer per hour between DC ’s
60 million page views/day
10 million logins per day
3 active data centers
$500k reduced costs per month 20x reduction in “lost sessions”

Session Persistence Results Sample chart that shows response gains with Session & without Session persistence changes.

Market Drivers 1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008. 2 seconds

Session Persistence Results
Data represents the number of Session Recovery events logged each day
Key dates:
5/30, Session Recovery turned on & available for 60% of customers
Rollouts on 6/13 (to 80%) and 6/20 (to 100%)
Very high volume day on 6/15

Client Usage: Telco Mobile Application Load profile for cell phone 3ms Response time 160 million customers 46k tps
Mobile phone profile/feature checking
Before: DBMS uses to read profile. Mobile applications and web sites generate too much load.
After: 3.1ms response time. 46k profile look ups per second.
Data distributed amongst several data centers using the grid.
Linear Scaling for more throughput

Client Usage: eCommerce Retailer Catalog page cache 1k page views/sec Faster startup JVM restarts are nondisruptive Cache consistency
One of the largest ecommerce sites
Before: Existing WebSphere Commerce Server customer.
Per JVM catalog cache lead to lots of memory wastage and cache warming problems on cluster start as well as JVM restarts
After:
Moving to a shared cache using WXS, speeds cluster start time by 60%
customer response times see no impact from JVM restarts.
Memory is dramatically reduced.
Catalog consistency is better (time based promotions)
Less CPU used

Client Usage: Social Media Website Entertainment 10x reduced response times 7 Billion requests per day
Fantasy Sports Web Infrastructure
Before: 60ms response time against database
After: WXS improved to 6ms response time
450k concurrent users
80k requests per second up to 1M in 2011
6 weeks from concept to production
Oracle ORM WXS App ORM WXS ORM WXS

Client Usage: Investment Bank Investment Banking 4x increase in revenue 12 Million orders per day
Next-generation Order Management System
Before: Oracle RAC based architecture unable to scale to necessary demands
After: 300K transactions / day  12M / day
Revenue up 4X and growing … “all because of WebSphere eXtreme Scale”
Response time drops to 2.5ms
Moving to “22 x 7” operations (more than 9AM - 4PM)
40x number of transactions supported

Client Usage: Insurance Company (SOA Result Cache) Insurance Policies reduced response times 125,000 policies concurrently processed
Reduce Database Processing
Before: Changes to policies required time consuming and costly access to multiple databases (e.g. drivers, accident history, previous claims, etc.)
After: Construct policy once, from multiple data sources, for fast access (in-memory) and fault tolerance (using replication)
Policies can be processed for up to 1 hour +
100 requests / second
1 MB of XML per policy, ¼ terabyte stored in cache
reduced costs per month better availability

Client Usage: Travel Web Site Holiday Inventory reduced response times 2,500,000 Package combinations
Improve response times
Before: Database cached inventory from SAP system
After: Cache allows faster searches and reductions in load on SAP system
reduced costs per month (SAP) better availability

Client Usage: Investment Bank Global Risk Management reduced response times 250,000 40ms Counterparties SLA
Handle peaks
Before: Database held risk information information, batch daily exposure calculation
After: Data held in memory, Monte Carlo exposure calculations, multi-master global replication.
Multiple Global Data centers (US, Asia, Europe), executing trades concurrently against counterparty risk limits.
Local grids in each data center allow fast responses versus centralized repository
Multi-master asynchronous replication between data centers provides consistency.
Handles peaks better Authorize trades Higher profits

Client Usage: Investment Bank Stock price service reduced response times 200,000 Prices updates/sec
Handle dramatic volume increases
Provides latest and 20 minute old prices for each stock
Before: Z/390 application using VSAM kept latest and 20 minute old price for each stock
After: WXS Grid maintains the same data.
200k stocks
200k price update/sec
20k price lookups/day
reduced costs per month better availability

Client Usage: Investment Bank Algorithmic Trading reduced response times 144 cores 2m TPS @ 800uS
Handle dramatic volume increases
Grid is system of record for algo trading application which runs embedded
Before: Home grown infrastructure
After: 144 cores hosting application. 800uS response time 90% of time. 4 WXS transactions for each response. Approx 2m tps at peak possible.
800uS 24/7

Client Usage: Insurance company – SOA Result Cache Mainframe service calls reduced response times 25% reduction
Reduce mainframe spend
Before: All service calls went to mainframe
After: 25% of calls are serviced using results from prior invocation within 24 hours.
25% reduction in backend transaction costs using a cache to intercept calls on an ESB.
reduced costs per month CICS ORM WXS App ORM WXS WXS Filter ESB

Client Usage: Trucking company HTTP Sessions in DB/390 reduced response times
HTTP Sessions were stored in DB/390
Before: All session persistence used DB/390
After: All session persistence provided by WebSphere eXtreme Scale.
Significant reduction in application response time
Reduction in MIPS cost on 390.
reduced costs per month

Client Usage: Telco LDAP caching Cache LDAP Directory reduced response times
Credential or data is stored in an LDAP directory
Before: Slow access to data in LDAP (84ms), Complex striped LDAP server arrangement.
After: Sub millisecond access to same data stored in WXS.
Significant reduction in application response time
Smaller LDAP infrastructure.
reduced costs per month

So how do I get started?

Getting Started
Two New Service Offerings
IBM Project Discovery Workshop for WebSphere eXtreme Scale
IBM QuickStart for WebSphere eXtreme Scale
ibm.com/developerworks/websphere/services/contacts.html
WebSphere Education
ibm.com/software/websphere/education/
YouTube IBM eXtreme Scale channel
youtube.com/ibmextremescale
DeveloperWorks Blog for XTP Community
ibm.com/developerworks/mydeveloperworks/blogs/xtp/?lang=en_us
Follow us on Twitter
twitter.com/WebSphereXTP
WebSphere eXtreme Scale V7 Solution Architecture Redbook
redbooks.ibm.com/redpieces/abstracts/redp4602.html
Download Replay and Presentation
ibm.com/developerworks/websphere/services/buzztalk.html
Contact your IBM Representative

Learn More About Dynamic Application Infrastructure! Application Foundation ibm.com/appfoundation Intelligent Management ibm.com/intellmgmt Extreme Transaction Processing ibm.com/xtp ibm.com/appinfrastructure

Gentle into to DataGrid technology and customer use cases

by Billy Newport

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Gentle into to DataGrid technology and customer use cases Presentation Transcript