Mais conteúdo relacionado Semelhante a Gentle into to DataGrid technology and customer use cases (20) Gentle into to DataGrid technology and customer use cases2. © IBM 2010, @billynewport
Agenda
• Gentle introduction to DataGrids
• General usage Patterns
• What they are good for and bad for
• Customer use cases
2
3. © IBM 2010, @billynewport
Traditional Cache Operation
App
App
App
App
EIS
A
A
A
A
App
Invalidationchatter
Invalidationchatter
3
4. © IBM 2010, @billynewport
WXS based Cache Operation
App
App
App
App
EIS
A
B
D
C
C’
D’
A
A
AppA
B’
A’
Cache is
4x larger!
Cache is
5x larger!
Cache cluster can be co-located with the application or run
in it’s own tier.
4
5. © IBM 2010, @billynewport 5
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
6. © IBM 2010, @billynewport 6
Customer Diversity
Data Grids are not just for investment banks!
• Retailers
• Insurance Companies
• Health care
• Retail Banking
• Hotel
• Travel Agencies
• Investment
Banking
• Telco
• Government
• Utilities
• Trucking
Companies
6
7. © IBM 2010, @billynewport 7
Market Drivers
1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008.
8. © IBM 2010, @billynewport 8
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
9. © IBM 2010, @billynewport 9
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.
10. © IBM 2010, @billynewport 10
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
11. © IBM 2010, @billynewport 11
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
11
AppAppAppApp
12. © IBM 2010, @billynewport 12
Common set of patterns
• 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.
12
AppAppAppApp
Loader
13. © IBM 2010, @billynewport 13
Common set of patterns
• 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
13
14. © IBM 2010, @billynewport 14
Common set of patterns
• 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
14
14
15. © IBM 2010, @billynewport
CRUD Evolves with KV or NoSQL stores
• Traditionally, we think of the big four
operations:
– (C)reate
– (R)ead
– (U)pdate
– (D)elete
15
• This changes now to become:
– (P)ut
– (R)etrieve by key
– (D)elete
– ** (Q)uery (this is different than search)
16. © IBM 2010, @billynewport
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!
16
17. © IBM 2010, @billynewport
SQL Benefits
• Relationships through joins
• Easy indexing
• No consistency issues, one copy/system of
record
• No need to partition data model.
18. © IBM 2010, @billynewport
SQL means domain centric
• Think about the data, find the nouns
• Nouns become tables
• identify attributes/keys
• normalize the tables to Nth normal form…
19. © IBM 2010, @billynewport
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.
20. © IBM 2010, @billynewport
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?
21. © IBM 2010, @billynewport
Question Centric
Ask a different question maybe?
22. © IBM 2010, @billynewport
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!
24. © IBM 2010, @billynewport 24
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”
25. © IBM 2010, @billynewport 25
Session Persistence Results
Sample chart that shows response gains with Session &
without Session persistence changes.
26. © IBM 2010, @billynewport 26
Market Drivers
1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008.
2
seconds
27. © IBM 2010, @billynewport 27
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
28. © IBM 2010, @billynewport 28
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
29. © IBM 2010, @billynewport 29
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
30. © IBM 2010, @billynewport 30
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
Client Usage: Social Media Website
Oracle
ORMWXS
App ORMWXS
ORMWXS
31. © IBM 2010, @billynewport 31
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
32. © IBM 2010, @billynewport 32
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
33. © IBM 2010, @billynewport 33
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
34. © IBM 2010, @billynewport 34
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
35. © IBM 2010, @billynewport 35
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
36. © IBM 2010, @billynewport 36
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
37. © IBM 2010, @billynewport 37
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
ORMWXS
App ORMWXS WXS
Filter
ESB
38. © IBM 2010, @billynewport 38
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
39. © IBM 2010, @billynewport 39
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
40. © IBM 2010, @billynewport 40
40
So how do I get started?
40
41. © IBM 2010, @billynewport 41
41
Two New Service Offerings
1. IBM Project Discovery Workshop for WebSphere eXtreme Scale
2. 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
41
Getting Started
42. © IBM 2010, @billynewport 42
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
Notas do Editor Business growth pushing the traditional IT envelope
Daa & transaction volume growth leading to impacts on application performance
New application patterns
WebSphere eXtreme Scale
Extreme transaction processing is real, happening today across a variety of business areas
WebSphere has the technologies needed to support extreme scalability and is continuing to enhance it to meet client needs (working with clients using this stuff now)
We are making these technologies easier to bring to bear even on existing business applications (via plug-in techniques and handling many of the common exceptions for the developer.)
These technologies integrate nicely into existing monitoring solutions making the operations visible
WebSphere eXtreme Scale V7.0 (shipping later in June 2009) offers the following new capabilities:
Broader applicability: WebSphere eXtreme Scale V7 provides a plug-in for WebSphere Dynacache to enable seamless usage and integration of a "drop-in" cache for WebSphere Application Server applications. This brings the linear scalability of the Object Grid technologies to bear on a broad variety of business applications with minimal invasive changes.
Improved reporting and monitoring: Implementations of metric access adapters improve integration with leading monitoring tools. This enables more comprehensive insight into the operational behavior of business solutions.
Improved ease of use: WebSphere eXtreme Scale V7.0 has been enhanced to handle many of the common retry and exception logic tasks in grid middleware, removing the burden from developers and allowing them to focus on the business logic aspects of application development.
Enhanced XTP capabilities: Implementation of byte array maps reduces the memory footprint of the grid data, resulting into lower memory costs and better performance. Your developers can now create dynamic maps to build more robust and efficient XTP applications for your business. With support for WebSphere Real Time, the industry-leading real-time Java offering, WebSphere eXtreme Scale enables the XTP applications to have more deterministic latency.
Customer Scenarios:
Entertainment:
The client needed to support a global on-line gaming experience. They anticipated up to 80 thousand hits per second (which gets us well over 5 billion per day) where each hit needed to touch the user's profile. Using eXtreme Scale, we worked with the client to deploy a profile application solution that scales to their needs using a reasonable number of servers and reduced their response times tenfold (from 50 ms to 5ms). This business will grow eight times larger of a three year period. As this business grows, our solution will scale up with it.
Financial:
The client set out to build a scalable order routing application that can easily grow to support increasing volumes of order execution requests while maintaining application latency. Given the scale of orders and the requirement that the orders be processed in a tight timeframe, this was a considerable challenge. Using eXtreme Scale technology along with a 64 bit Java Virtual Machine, we worked with the client to deploy a solution that scaled out to easily provide the level of service required while providing improved the millisecond level response times required. This includes, or should we say depends on, eXtreme Scale's automatic replica management and sub-second fail over capabilities."
Speakers: you can change the content of this slide to more specific follow up links if you’d like