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