VoltDB David Rolfe Director of Solution Architecture, EMEA Doug Jauregui Sr. Solutions Engineer
Legacy database technology is obsolete Legacy RDBMS designs date from about • Internet Traffic (GB Month), Transistors per CPU and Cost of RAM over time 100.000.000.000 $10.000.000 1985. 10.000.000.000 $1.000.000 1.000.000.000 Vendors are finding legacy databases • 100.000.000 $100.000 increasingly uneconomic. 10.000.000 $10.000 1.000.000 Legacy databases struggle to scale beyond • 100.000 $1.000 10.000 2 nodes. $100 1.000 100 But demand for transactions is increasing • $10 10 all the time. 1 $1 1980 1990 2000 2010 Total Internet Bandwidth (GB/Mo) Meanwhile Moore’s law means hardware • Transistors per CPU and RAM keeps getting cheaper Price of Ram ($/GB)
21 st Century Requirements for transaction processing • Virtualization friendly . • ACID transactions. • Millisecond response times. • No ”Long Tail” • Supports complicated logic • Easily scalable beyond 2 nodes. • HA “Just Happens” • Geo replication • “Translytics”/”HTAP”
BMS - How We Thought an RDBMS Worked RD RDBM SELECT * FROM PRODUCTS WHERE ID = 1 FOR UPDATE OF qty; CPU ID=1, Qty= 200, LastDate= 23 /March/18 UPDATE users SET BAL = 190 WHERE ID =1; INSERT INTO sales Iuserid, productId, cost) VALUES (42,1,10); UPDATE products SET qty = 199 WHERE ID = 1; COMMIT; SELECT * FROM PRODUCTS WHERE ID = 1 FOR UPDATE OF qty; RAM DISK DATA DATA ID=1, Qty= 200 UPDATE users SET BAL = 190 WHERE ID =1; WAΙTΙNG INSERT INTO sales Iuserid, productId, cost) VALUES (43,1,10); WAΙTΙNG UPDATE products SET qty = 199 WHERE ID = 1; Inflight Transactions COMMIT;
BMS - What Actually Happens – Part 1… RD RDBM CPU SELECT * FROM PRODUCTS WHERE ID = 1 FOR UPDATE OF qty; ID=1, Qty= 200, LastDate= 23 /March/18 UPDATE users SET BAL = 190 WHERE ID =1; INSERT INTO sales Iuserid, productId, cost) VALUES (42,1,10); RAM DISK DATA DATA UPDATE products SET qty = 199 WHERE ID = 1; COMMIT; SELECT * FROM PRODUCTS WHERE ID = 1 FOR UPDATE OF qty; WAΙTΙNG WAΙTΙNG ID=1, Qty= 200 Inflight Transactions UPDATE users SET BAL = 190 WHERE ID =1; INSERT INTO sales Iuserid, productId, cost) VALUES (43,1,10); UPDATE products SET qty = 199 WHERE ID = 1; COMMIT; CPU
BMS - What Actually Happens – Part 2 RD RDBM RAM DATA SAN CPU WAΙTΙNG WAΙTΙNG CORE Inflight Transactions RAM DATA CPU WAΙTΙNG WAΙTΙNG CORE Inflight Transactions
If we tried this in a supermarket…
Dr. Michael Stonebraker found a solution.. Useful Work 12% Index Management 11% Logging 20% Buffer Management 29% Locking 18% Latching 10%
How VoӏtDB works RAM Local File BOOK PAY Bay Bay DATA CORE BOOK BOOK Item 1 Item 2 System PAY PAY WAΙTΙNG WAΙTΙNG BOOK BOOK Bay Bay Inflight Transactions CORE BOOK PAY Item 1 Item 2 PAY BOOK RAM BOOK PAY Bay Bay Local File DATA CORE BOOK BOOK Item 1 Item 2 System PAY PAY WAΙTΙNG BOOK BOOK WAΙTΙNG Bay Bay BOOK PAY Item 1 Item 2 Inflight Transactions CORE PAY BOOK
How a supermarket works…
VoltDB’s Role Scale Batch NoSQL Processing/ HDFS ACID Milliseconds Tranactions Transactions Legacy OL TP
The only 3 ways to interact with any database Approach Examples Strengths Weaknesses Many SQL JDBC, ODBC, Liked by Doesn’t handle scaling OLTP loads well – DB spends its • Statements + developers, time figuring out who can see what instead of working Commit or Rollback initial • Constant locking problems for shared, finite resources development is Failure of a client to Commit or Rollback causes a • rapid temporary resource leak Move all the data NoSQL, KV Very developer • Multiple updated copies of the data can arrive at the to the client and Stores friendly same time for scaling OLTP loads back again All of the data gets moved across the network, every • time. Stored Procedures VoltDB, Predictable Not in fashion with developers. • PL/SQL speed and best PL/SQL created perception of complexity. • possible scaling Other implementations of Java Stored Procedures really • characteristics slow.
A Proven and Reliable Partner Telco Billing/rights management, subscriber data, etc. Financial Services Risk, market data management, customer mgt. Personalize, Customize, Target Ad optimization, audience segmenting, customer service loT Platforms, Energy, Sensor Smart grid/meters, asset tracing & management Infrastructure, Dashboards, KPIs Data pipeline, system performance, streaming ETL.
VoltDB & Machine Learning
Application/Use Case • Fraud Prevention • Single sign-in of all Huawei phones VoltDB • Consumer banking risk management Fraud Credit Card & VoltDB Prevention Mobile Pay Why VoltDB? Message Queue Real-Time • > 50% reduction in fraud cases Decision Making Single Sign-on Mobile log-in Manager • > $15M/year saved from fraud loss • 10k complex Transactions Per Second Rules New Data Consumer Consumer • 99.99% transactions finish < 50ms Banking Risk Banking Management System Spark + Hadoop • 10x better performance than Near Real Time Data for traditional fraud detection Models and Rules
VoltDB & Machine Learning • VoltDB has a C++ core with a Java layer on top for running stored procedures • VoltDB implements High Availability by running the same code in two places at once. • Any Java class can be used in a stored procedure call provided: • It’s deterministic (all copies of the code have to act the same way…) • It doesn’t access network resources (which would make it non-deterministic) • Examples: H20.AI and (J)PMML
ML Example – User Defined Function in H20
ML Example – Calling JPMML from a Procedure
For more information: www.voltdb.com drolfe@voltdb.com
Recommend
More recommend
