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

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

Gentle into to DataGrid technology and customer use cases

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Gentle into to DataGrid technology and customer use cases

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Gentle into to DataGrid technology and customer use cases (20)

Plus récents (20)