The presentation discusses the integration of VoltDB and Erlang, highlighting their unique technological approaches for scalability, reduced costs, and flexibility in data management. VoltDB is presented as an in-memory, distributed SQL database designed for high throughput, while Erlang is introduced as a functional programming language beneficial for reliability and low hardware requirements. The document also outlines their applications, benchmarks, and resources for getting started with both technologies.

1. VoltDB and Erlang
TechPlanet 2012
H. Diedrich
http://www.eonblast.com – twitter @hdiedrich

2. Your Host
Henning Diedrich
• Founder, CEO Eonblast
• Maintainer of Emysql, Erlvolt

3. This Presentation
Review With Leasure
• Video & Slides will be online at SK planet
• Slides will be online at slideshare.net

4. Eonblast

5. VoltDB and Erlang
Open Source Tech for Scale
1. What makes Them Special?
2. How do They Look?
3. Are They For Me?

6. 
Made for a Concrete Need

Made for Distribution

Made for Multi-Core

Truly Different Approaches

Based on Parallelism

Improving on Previous Solutions

Corporate-Created

Open Source

Professional Support

Known by Those in the Know

7. The free, scaling, SQL DB
Redis + SQL + Scale = VoltDB

8. Why VoltDB?
Business Perspective
• Reduce Costs
• Scale Seamlessly
• Maintain Strategic Flexibility

9. Why VoltDB?
Production Perspective
• Keep The Good of SQL
• Use the Speed of In-Memory
• Take Pain out of Scaling

10. In-Memory
The Redis of clusters
• Today good for 100s of GB of data
• Sheds 75% of DBM system activity
• Made from scratch for distribution
• Full disk persistence

11. SQL
The MySQL of NewSQLs
• SQL Has Flaws
• Essentially Math, Not Syntax
• You'd be missing Queries
• VoltDB is even 'more SQL than SQL'

12. CAP
• Distributed
• Consistent
• Highly-Available
• Partition-Tolerant
… have it all!
Brewer on CAP 2012: http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

13. ACID
• Atomicity
• Consistency
• Isolation
• Durability
… for granted?

14. Double Bookkeeping
• Not Every App needs It
• Requires ACID Transactions
• Neigh Impossible to emulate
• Impossible With BASE
(Eventual Consistency)

15. The Magic
• Compiled-In Queries
• Single-Thread Execution
• Snowflakes & Clones

16. Partitions
State
#

17. K Safety 1
State
#

18. Snowflake Structures
FK
FK FK
PK
PK
FK FK
FK

19. Snowflake Structures
FK
FK
FK
PK FK
FK

20. Other Data
PK
PK
PK

21. Partitions
State
#
ABC EFG HIJ KLM NOP

22. Partitions
State
#
ABC EFG HIJ KLM NOP
A-Z A-Z A-Z A-Z
A-Z

23. Single Thread Execution
• One Thread per Partition
• One Thread per Transaction
• One Thread can't race itself
• Main Design Criterion

24. Benchmark
• Node.js
• Amazon EC2
• 64 core node.js clusters + 96 core VoltDB cluster
• 695,000 transactions per second (TPS)
• 2,780,000 operations per second
• 100,000 TPS per 8 core client
• 12,500 TPS per node.js core
• Stable even under overload
• Pretty much linear scale
Details: http://voltdb.com/company/blog/695k-tps-nodejs-and-voltdb

25. Benchmark
TV Contest
• Millions of callers
• Small set of candidates
• Massive peak
• One transaction is one vote
• Callers are identified by their telephone number
• Callers must not be allowed to vote more than once

26. Benchmark
CREATE TABLE contestants
(
contestant_number integer NOT NULL
, contestant_name varchar(50) NOT NULL
, CONSTRAINT PK_contestants PRIMARY KEY
(
contestant_number
)
);
CREATE TABLE votes
(
phone_number bigint NOT NULL
, state varchar(2) NOT NULL
, contestant_number integer NOT NULL
);
CREATE TABLE area_code_state
(
area_code smallint NOT NULL
, state varchar(2) NOT NULL
, CONSTRAINT PK_area_code_state PRIMARY KEY
(
area_code
)
);

27. Benchmark
The Transaction in 4 Operations
// Check if the vote is for a valid contestant
SELECT contestant_number FROM contestants WHERE contestant_number = ?;
// Check if the voter has exceeded their allowed number of votes
SELECT num_votes FROM v_votes_by_phone_number WHERE phone_number = ?;
// Check an area code to retrieve the corresponding state
SELECT state FROM area_code_state WHERE area_code = ?;
// Record a vote
INSERT INTO votes (phone_number, state, contestant_number) VALUES (?, ?, ?);

28. Drivers
• Java
• C, C++
• node.js
• Python
• Ruby
• Go
• Erlang

29. • VoltDB, Inc. 2009 – commercial developer, support
• Open Source – 100% dictatorial by VoltDB, Inc
• Made for OLTP – fast cheap writes, high throughput
• CA of CAP – 100% consistent & highly available
• Simple SQL – real queries
• In-memory – 100x faster than MySQL
• ACID transactions – double bookkeeping
• Distributed – for painless growth
• Linear scale – predictable, low cost
• Replication, Snapshots – disk persistence, hot backup
• More SQL than SQL – clean separation of data

30. Getting Started
• Download and Install from voltdb.com
• Open Getting Started inside the installation
• Run Hello World locally
• Read M.I.T. Paper A New Architecture
• Watch webinars at voltdb.com
• Free Help also from VoltDB staff
http://community.voltdb.com/forum
• Use EC2 to benchmark your ideas

31. Upcoming Blog Post
• Looking at 14 databases
• Riak, Cassandra, Membase, H-Base, Voldemort, MySQL, MySQL Cluster, Redis, Redis
Cluster, Tokyo Cabinet, Memcached, CouchDB, Couchbase, VoltDB, MongoDB, Postgres
• In the light of what games need
• Unbiased comparison
• Twitter @hdiedrich

33. Erlang may be to Java
what Java was to C++
C++ – pointers = Java
Java – deadlocks = Erlang

34. Why Erlang?
Business Perspective
• Reduce Costs
• Reduce Downtimes
• Shorten Time To Market

35. Why Erlang?
Production Perspective
• High Productivity
• Low Hardware Requirements
• Fewer Errors

36. Who Is using It?
“You probably use systems
based on Erlang/OTP every day
without knowing it.“
Mike Williams

37. Erlang Game Servers
Zynga: FarmVille via membase, Activision Blizzard: Call of Duty, Bigpoint: Battle Star Galactica, Wooga: Magic Land

38. Erlang Poster Childs
Klarna AB
• Financial Services for E-Commerce
• 30 seconds downtime in 3 years
Distributed Databases
• Membase
• Riak
• BigCouch

39. Sweet Spots
• Stateful Servers with High Throughput
• Cluster Distribution Layers
• Chats

40. Origins
PLEX
• Ericsson makes billions with telecom switches
• They used PLEX, an all proprietary software
• PLEX delivers, but has bad productivity

41. Origins
• The 80's: Ericsson Computer Science Lab
Joe Armstrong, Robert Virding, Mike
Williams
„What aspects of computer languages
make it easier to program telecom
systems?“

42. Erlang was Built For
• Reliability
• Maintenance
• Distribution
• Productivity

43. Concurrency Built In
• In the Language, not OS
• Easier Testing
• Massively Battle-Tested
• Closer To Real Problems

44. The Magic
• Microprocesses
• Pattern Matching *
• Immutable Variables
* Not your familiar Regex string matching

45. Thinking Erlang
• The Actor Model
• Thinking Parallel
• Thinking Functional
• Thinking Processes
• Pattern Matching
• Let It Crash!

46. The Actor Model
Carl Hewitt 1973
• Behavior
• State Actor
• Parallel
• Asynchronous Messages Data
Data
Code
Code
• Mailboxes
• No Shared State
• Self-Contained Machines
Object
Process
Benefits
• More true to the real world
• Better suited for parallel hardware
• Better suited for distributed architectures
• Scaling garbage collection (sic!)
• Less Magic

47. Asynchronous Messages
Pid ! Msg
Message dispatch is one-way, truly asynchronous.
Not function calls but something in their own right.
Clean break from the FP paradigm.

48. Thinking Processes
What should be a Process?
Processes “It's easy!”
Joe Armstrong
• Don’t share State
• Communicate Asynchronously
• Are Very Cheap to create And keep
• Monitor Each Other
• Provide Contention Handling
• Constitute the Error Handling Atom

49. Objects share Threads
Multiple objects share threads.
Objects can be accessed across threads.
Threads - and objects - share state.

50. Actors are Processes
State, code and process form a unity: the actor.
Like processes, actors do not share state.
In fact, like humans. Who mostly work quite well.

51. Objects and Threads
C C++ C# Java JavaScript Node Lua Python

52. Objects and Threads
Idle Threads

53. Objects and Threads
Leeroy Jenkins!!!
Unwanted surviving objects

54. Objects and Threads
2*B || !2*B ?
Prematurely destroyed objects

55. Erlang Actors
Erlang Actors: State + Code + Process

56. Erlang Actors
One dies.

57. Erlang Actors
It's restarted.

58. Errors propagate
Loss of state can affect multiple modules.
State errors cross thread boundaries.
Defensive code multiplies.

59. Objects need Locks
Worker 1 Doing X1
Resource Locked Locked
Worker 2 Waiting Doing X2
●
System design is disrupted by explicit locks.
●
Overly cautious locking slows things down.
●
Forgotten locks create errors that show under load.

60. Crashed Locks Stall
Worker 1 Doing X1
Resource Locked Locked
Worker 2 Waiting Doing X2
●
Locks can need cross-thread error handling.
●
Stalling and time outs aggravate load.

61. Processes are Transactional
Do X1 for me!
Funnel Doing X1 Doing X2
Do X2 for me!
●
One actor is one process, obviously cannot “race itself”.
●
Mandating a job type to an actor creates a transactional funnel.
●
Only one such job will ever be executing at any one time.

62. Thinking Parallel
• The Generals’ Problem
• Lamport Clocks
• No Guarantees
“It's not easy.”
Robert Virding

63. Generals’ Problem
State
Two generals need to agree when to attack.

64. Generals’ Problem
State
One sends a messenger.

65. Generals’ Problem
State
Acknowledge.

66. Generals’ Problem
State
ACK the ACK. Etc.

67. Generals’ Problem
State
The messenger may get lost.

68. Byzantine Generals
State
The generals, actually, too.

69. Lamport Clocks
Order matters more than time.
Source: Lamport http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf

70. Thinking Functional
Small Functions
+ Immutable Variables
→ Don’t assign variables: return results!
Complete State in Plain Sight
→ Awful for updates in place.
→ Awsome for debugging & maintenance.
Erlang is not side-effect free at all.

71. Immutable Variables
Can’t assign a second time:
A = A + 1.
A = 1, A = 2.

72. Immutable Variables
It has to be:
B = A + 1.
A = 1, B = 2.
●
Prevent Coding Errors
●
Provide Transactional Semantic
●
Allow For Pattern Matching Syntax
●
Can be a Nuisance

73. Pattern Matching
This can mean two things:
A = func().
The meaning depends on whether
A is already assigned.

74. Pattern Matching
The common, mixed case:
{ok, A} = func().
ok is an assertion AND
A is being assigned.

75. Pattern Matching
The common, mixed case:
{ok, A} = func().
“This makes it hard to give Erlang a
syntax like e.g. Lua.”
Robert Virding

76. Let It Crash!
• No Defense Code
• On Error, restart Entire Process
• Built-In Process Supervision & Restart
• Missing Branches, Matches cause Crash
→ Shorter, Cleaner Code
→ Faster Implementation
→ More Robust: handles All Errors

77. Syntax
●
Small
●
Easy
●
Stable
●
Declarative
●
Inspired by Prolog and ML
●
Obvious State, Implicit Thread

78. Fibonacci
Looks like the math description
fib(0) -> 0;
fib(1) -> 1;
fib(N) when N>1 -> fib(N-1) + fib(N-2).

79. Hello, World!
-module(hello).
-export([start/0]).
start() ->
io:format("Hello, World!~n").

80. Hello, World!
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

81. Start
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

82. Output
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

83. Process Spawning
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() -> New Process
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

84. Blocking Receive
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

85. Message Passing
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

86. Pattern Matching
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

87. Tail Recursion
-module(hello).
-export([start/0, loop/0]).
start() ->
Pid = spawn(hello, loop, []),
Pid ! hello.
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop()
end.
From Edward Garson's Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html

88. Productivity
Motorola Study running 2002 – 2006:
“Erlang shows …
• 2x higher throughput
• 3x better latency
• 3 - 7x shorter code
… than the equivalent
C++ implementation.”

89. Erlang
• Ericsson AB 1983 – commercial developer, support
• Open Source – 100% dictatorial by Ericsson
• Professional Support – by veterans at Erlang Solutions
• Made for telecom – complexity & robustness
• Functional – improves maintainability
• Actors Model – better than OO for parallel worlds
• Distributed – seemless use of multi-cores
• Parallel – Processes as basic building block
• Simple Language – Easy to learn and maintain
• Huge Library – OTP is made for server development
• Battle-tested – billion $ projects, 1 million LOC
• Great Community – bright and friendly devs

90. Learning Erlang
• Scour Post-Mortems
• Download and Install from erlang.org
• Fred’s site Learn You Some Erlang!
• Joe’s book Programming Erlang
• IRC #erlounge
• Erlang Mailing List
• Local Erlounge Meetings
• Erlang Factories & User Conferences

91. Erlvolt

92. Erlvolt
• The Erlang VoltDB Driver
• Stable Synchronous Version
• Upcoming Asynchronous Version
https://github.com/Eonblast/Erlvolt

93. Erlvolt
Insert
erlvolt:callProcedure(Connection, "Insert", ["안녕하세요", "세계", "Korean"]),
Select
Response = erlvolt:callProcedure(Connection, "Select", ["Korean"]),
Row = erlvolt:fetchRow(Table, 1),
io:format("~n~n~s, ~s!~n",
[ erlvolt:getString(Row, Table, "HELLO"),
erlvolt:getString(Row, Table, "WORLD") ]);

94. Resources
Erlang VoltDB
Web Download
http://www.erlang.org/ http://voltdb.com/products-services/downloads
http://learnyousomeerlang.com/
http://www.erlang.org/static/getting_started_quickly.html Webinars
http://community.voltdb.com/weninars
List
Forum
http://erlang.org/mailman/listinfo/erlang-questions
http://community.voltdb.com/forum
http://groups.google.com/group/erlang-programming
Voter Example
Books https://github.com/VoltDB/voltdb/tree/master/examples/voter
http://pragprog.com/book/jaerlang/programming-erlang
http://shop.oreilly.com/product/9780596518189.do Benchmark Blog Post
http://voltdb.com/company/blog/695k-tps-nodejs-and-voltdb
References
http://erldocs.com/ Volt’s Magic Sauce
http://www.erlang.org/doc/ http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf
Post Mortems
http://www.facebook.com/note.php?note_id=14218138919
http://www.slideshare.net/wooga/erlang-the-big-switch-in-social-games
Erlvolt
https://github.com/Eonblast/Erlvolt
Eonblast
https://www.eonblast.com

95. Upcoming
• Erlvolt 2 – asynchronous Erlang VoltDB driver
• 14 New Databases for Games – Blog Post
TBA on Twitter @hdiedrich

96. Questions
• Email: hdiedrich*eonblast.com
• Twitter: @hdiedrich
• VoltDB: http://community.voltdb.com/forum
• Erlang: erlang-questions@erlang.org
• Eonblast: http://www.eonblast.com
• Game News: @eonblast