voltdb
play

VoltDB David Rolfe Director of Solution Architecture, EMEA Doug - PowerPoint PPT Presentation

May 09, 2023 •457 likes •651 views

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

  1. VoltDB David Rolfe Director of Solution Architecture, EMEA Doug Jauregui Sr. Solutions Engineer

  2. 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)

  3. 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”

  4. 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;

  5. 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

  6. 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

  7. If we tried this in a supermarket…

  8. Dr. Michael Stonebraker found a solution.. Useful Work 12% Index Management 11% Logging 20% Buffer Management 29% Locking 18% Latching 10%

  9. 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

  10. How a supermarket works…

  11. VoltDB’s Role Scale Batch NoSQL Processing/ HDFS ACID Milliseconds Tranactions Transactions Legacy OL TP

  12. 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.

  13. 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.

  14. VoltDB & Machine Learning

  15. 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

  16. 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

  17. ML Example – User Defined Function in H20

  18. ML Example – Calling JPMML from a Procedure

  19. For more information: www.voltdb.com drolfe@voltdb.com

More recommend