Gentle into to DataGrid technology and customer use cases
Download as PPT, PDF2 likes1,425 views
WebSphere eXtreme Scale (WXS) is a data grid that can be used to cache data and improve response times for applications. It allows building scalable front ends that are decoupled from back-end systems. The document discusses common usage patterns for WXS including caching database queries, web service results, and HTTP sessions. It also provides examples of how large companies have used WXS to significantly improve performance and scale for applications in areas like online banking, telecommunications, ecommerce, and travel. Response times were typically reduced to single digit milliseconds.
Gentle into to DataGrid technology and customer use cases
- 1. XTP using WebSphere eXtreme Scale @billynewport IBM Distinguished Engineer
- 2. © 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!
- 23. © IBM 2010, @billynewport SOME USE CASES 23
- 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
- 43. © IBM 2010, @billynewport 43 43
Editor's Notes
- #31: 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."
- #43: Speakers: you can change the content of this slide to more specific follow up links if you’d like