The document discusses the comparison between SQL, NoSQL, and NewSQL databases, emphasizing the importance of choosing the right tool based on data structure and user needs. It highlights the limitations of legacy systems while detailing the advantages of SQL for analytics and performance. The conclusion suggests considering VoltDB for businesses needing consistency and performance without the complexities of current vendor solutions.

1. page
WHY YOU REALLY WANT SQL IN A REAL-
TIME ENTERPRISE ENVIRONMENT

2. page© 2016 VoltDB PROPRIETARY
WHO YOU WILL BE HEARING
2
Dennis Duckworth, Director
Product Marketing
VoltDB
David Rolfe, Director
Solutions Engineering EMEA
VoltDB
See
it
here:
voltdb.com/webinars

3. page© 2016 VoltDB PROPRIETARY
SQL OR NOSQL? THAT IS MANY QUESTIONS
• SQL = SQL Language
• SQL = Relational, Structured, Schema-on-Write
• Tables (Rows, Columns), Primary/Foreign Keys,
Data Types, Constraints, Normal Form
• NoSQL = No! SQL or Not only SQL
• NoSQL = Schema-on-Read
• NoSQL = Variety of data (vs only structured)
3

4. page© 2016 VoltDB PROPRIETARY
SQL OR NOSQL? THE REAL QUESTIONS
• How do you access the data?
• How do you store the data?
• Which do you use for a particular application:
• [Old]SQL
• NoSQL
• NewSQL
4

5. page© 2016 VoltDB PROPRIETARY
HOW DO YOU ACCESS THE DATA?
Who knew the future of NoSQL was
SQL?
Alistair Croll, Co-­‐Chair
Strata Conference, February 2013
5

6. page© 2016 VoltDB PROPRIETARY
HOW DO YOU ACCESS THE DATA?
• Key reasons for using SQL (language)
• Familiarity
• Lingua Franca of business analytics
• Productivity
• Declarative (allows optimization by system)
• Portable
6

7. page© 2016 VoltDB PROPRIETARY
HOW DO YOU STORE THE DATA?
• Now that’s a question!
7

8. page© 2016 VoltDB PROPRIETARY
ORIGINAL DRIVERS FOR NOSQL MOVEMENT
• Need to handle web-scale user base
• Scale out on cheap hw, not scale up on pricey hw
• Write it all reliably, make sense out of it later
• Lower TCO and $/TB for large DWs
• $40K+/TB down to < $1K/TB
• Need to store and process unstructured data
• Big driver for Open Source
8

9. page© 2016 VoltDB PROPRIETARY
TWO DIFFERENT APPROACHES: NOSQL AND NEWSQL
• NoSQL – traditional RDBMS can’t scale so
throw them out and start new, building from
scratch
• NewSQL – traditional RDBMS can’t scale but
there are critical/important elements to them
so see what can be eliminated to let them
scale with high performance
9

10. page© 2016 VoltDB PROPRIETARY
PROBLEMS WITH LEGACY DATABASE SYSTEMS
• You will be slow if you try to do too much
• Legacy DBs got slow because they added too much
stuff/complexity/baggage to their code
• Try to be everything to everyone
• One system for both OLTP and OLAP? Both equally
poorly
• They scale up – add bigger/faster/more expensive
machine
• Designed/created when “cloud” meant water
vapor
10

11. page© 2016 VoltDB PROPRIETARY
POTENTIAL PROBLEMS WITH NEW DATABASE SYSTEMS
• You can be real fast if you do very little
• Alternative solutions try to do fewer things really
well (and fast)
• But be careful of those that do too little
• Like questionable “durability”
• http://www.mongodb-is-web-scale.com
11

12. page© 2016 VoltDB PROPRIETARY
NOSQL FALLACIES
• Big Data = Hadoop
• Anything from Facebook | Twitter | LinkedIn |
Google | Yahoo *must* be really good and
perfect for me
• Web scale means NoSQL
• RDBMS’s just can’t handle it
12

13. page© 2016 VoltDB PROPRIETARY
THREE QUESTIONS TO HELP YOU DECIDE
• What type of data?
• Structured, Unstructured, Both
• Who will be doing the analytics/queries?
• Business Analysts? => SQL good choice
• Computer Science Grads? => Python, Java, Scala
• What Other Data Management Systems are
being used?
13

14. page© 2016 VoltDB PROPRIETARY
WHY ACID MAKES LIFE EASIER?
• ACID vs CAP vs BASE
• Availability Consistency Isolation Durability
• Consistency Availability Partition Tolerance
• Basically Available Soft State Eventual
Consistency
• Lack of strict ACID = Application Complexity
• Be aware of evolving needs/requirements and
emerging complexity
14

15. page© 2016 VoltDB PROPRIETARY
SPEAKING OF COMPLEXITY
• Be careful about using too many components
• The latest fashionable “stack”
• Components themselves are well tested...
• ... but glue code likely not so
• Make the solution as simple as possible, but
no simpler
15

16. page© 2016 VoltDB PROPRIETARY
FINAL THOUGHTS:
USE THE RIGHT TOOL FOR THE RIGHT JOB
• Shouldn’t be a religious war
• Full ACID doesn’t necessarily mean “slow”
• Legacy DW apps working just fine?
• Need to add unstructured data storage and
analytics?
• Business analysts want access to all data?
• No Computer Science grads/Java/Cassandra talent?
16

17. page© 2016 VoltDB PROPRIETARY
FINAL THOUGHTS: CONSIDER VOLTDB IF...
• Licensing fees and policies of your current
vendor (Oracle, IBM, KDB, ...) are driving you
nuts (like for virtualization)
• You really could use full consistency and
Cassandra’s eventual consistency is making your
applications (and life) way too complicated
• Your current database can’t perform fast enough
to meet your SLAs
17