Upload
gojkoadzic
View
675
Download
1
Tags:
Embed Size (px)
DESCRIPTION
From the Gaming Scalability event, June 2009 in London (http://gamingscalability.org). In this talk, Matthew Fowler from NT/e looks at the persistence issues on computing clouds. He discusses architectural principles and problems that cloud persistence presents to application developers and presents a possible solution, focusing on the key ideas, the tooling and the deployment options.Matthew Fowler runs the Java business unit of New Technology/enterprise. Matthew received a BSc in Computer Science from MIT. He has developed and marketed products in many areas of software - LANs, WANs, software tools, language processors and generation of enterprise applications. His current interests are system generation and grid/cloud applications.
Citation preview
1 CloudSave
As fast as the grid,as safe as a database
Matthew Fowler
NT/e
2 CloudSave
Agenda
1. Introduction
2. CloudSave
3. ACID assessment
4. Architecture shift
3 CloudSave
NT/e
• NT/e– New Technology / enterprise– Formed 1996
• 1998 - Server-side Java. BEA Partners• 2007-8: £2.5m turnover, £100k profit• JeeWiz Version 1.0: March 2002• JeeWiz Version 5: 2008, engine open-sourced• Key customers: DeutschePost/SOPERA, UBS,
BEA, GigaSpaces
4 CloudSave
Products
CloudSave
J2EE, Struts
Hibernate, Spring, JSF
Engine
5 CloudSave
Big Data
Blinding Speed
Rock Solid
Scalable - small→huge
CloudSave Hopes
6 CloudSave
Low Reliability
Complicated Programming
ACID has be neutralised
Distributed Transactions
Oracle
CloudSave Fears
7 CloudSave
CloudSave Features
• GigaSpaces XAP Platform– Spaces ... JavaSpaces
• Scalable Architecture– Data Scalability– Processor Scalability– Appropriate for single-space deployment
• IMDG == In-Memory Database– Mapped back to persistence sources
• Distributed Transactions
8 CloudSave
As fast as poss 1: IMDG (database in memory)
Partition 1
BackupsCust/Order
1
Cust/Order
2
Cust/Order
3
Cust/Order
4
Stock1
Stock2
Stock3
Utils
Tables Customer, Order, OrderLine Part, StockItem, Bin Sequences
Partition 2 Partition 3
9 CloudSave
In-Memory Data Bases - Are You Crazy?
• What's it worth:– Loss of sales - down by 7% from 5 - 6 seconds
• Business justification for $100m/year co:– $7m/year for performance– cost of Amazon 8Gb AMI: $2,400/yr– *4 for software costs? = $10,000/yr say– PAYS FOR 700 SERVERS, 500Gb in-memory DB
10 CloudSave
IMDG == SOR
• The grid is the System Of Record• Need to allocate PKs in grid
– No database auto allocation
• Same problem for unique– transaction IDs– anything else
• Grouping - 50 at once
Utils
Sequences
Partition 3
11 CloudSave
As fast as poss 2: Locality
• Bulk up your entities– Customer main entity
• Subsidiary entities: Order; OrderLine
• Locality of reference: same node• Avoid network calls
(as far as poss.)• Routing from master PK• "Rows" ...
IMDG entries like DB rows
12 CloudSave
As fast as poss 3: TxB - Transaction Buffer
• It's the Gear Box!• Holds transactions in mem• Yes to client, then commit
– Critical path speed-up
• Commit threads:1. saves to local tx log
2. commits tx in grid
3. sends to persistence
• Pluggable targets - even XA!
TxB
13 CloudSave
Persistence Management• Multi-threading
– Necessary for performance– Order must be preserved– Mustn't start save before
overlapping save complete
• Back-end resilience– Persistence targets are slaves– The show must go on!– Continuous efforts to persist– Roll out tx's to disk if no DB
T T T T
14 CloudSave
Atomicity
• 100% or 0% - Commit or abort completelyTxB and IMDG must kept in synch
• TxB controls rollback and timeout
15 CloudSave
Consistency
• Changes must be database-like– observe DB constraints– commit transactionally
• (sounds like distributed transactions to me)
• Nodes in different partitions kept in sync– e.g. indexes– must be consistent with transaction
16 CloudSave
Isolation / Durability
• Isolation– Repeatable_Read isolation– Transactions can choose to
• wait
• return busy immediately
• Durability– Running system survives n-1 failures– Transactions logged to disk off critical path– Critical path: TxB survives n-1 failures
17 CloudSave
Failures and Timeouts
• All transactions should have a timeout– Killed by TxB if timeout exceeded– Grid nodes informed too– Grid nodes can query TxB for status
• Design of failure handling...– Where did Q1 go?
18 CloudSave
The Layers
GigaSpaces ProxyCRUD/commit/abort
start/buffer/commit/abort
start/commit/abort
TransactionManagement
GigaSpaces-aware DB server
Generate Classes Save/Load
Java APIData
Management
Plug-in Committer[e.g. Queues]
Generic User
Client PartitionsTransaction
Buffer
19 CloudSave
Java/DB Viewpoint
• Some config to distribute/size grids• Some architectural understanding
– Basically SOA• Business Objects represented as services
• GigaSpaces as embedded product
20 CloudSave
Cloud-Private DB Link-up
• Web-app + IMDG in cloud
• Real DB in Data Centre
21 CloudSave
Virgin Airways
LastMinute.com
In-Cloud Federated Applications
FederatedTransaction Buffer
22 CloudSave
DIY
• Don't– The Darwin Award?
• Out-of-the-box solution makes more sense
23 CloudSave
Why not start here?
• Appropriate for a small architecture– IMDG: faster to read– CloudSave: faster to commit– Scalable– Greener
• Average 10-15% utilisation on servers
• Use virtual machines or small machines
• Then scale out to real/big
24 CloudSave
Questions?
More information: www.nte.co.uk/java