It’s Always a Hard Choice SQL vs NoSQL It’s Always a Hard Choice Denis Reznik Data Architect at Intapp Microsoft MVP (SQL Server)

About me Denis Reznik Kyiv, Ukraine Former Kharkov Citizen Data Architect at Intapp Microsoft MVP (SQL Server) Leader of Kyiv SQL Server User Group Co-author of “SQL Server MVP Deep Dives 2” Database Geek and Community Enthusiast 2 |

RDMS Commercial Success Database History Amazon Dynamo Paper RDBMS Ingress System R Object Databases CODASYL IMS Google BigTable Paper SQL NewSQL (?) 1960s 1970s 1980s 1990s 2000s Nowadays E.F. Codd’s Paper RDMS Commercial Success NoSQL (Johan Oskarsson)

NoSQL SQL

Agenda Criteria #1 Criteria #2 Criteria #3 Criteria #4 Criteria #5

Criteria #1 Tools

Databases Key-Value Relational Column-Family Graph Document

Criteria #2 Domain

Q&A Web Site (StackOverflow)

Domain Model Questions Answers Users Comments Votes

Criteria #3 Workload

Sample Workload 4 million users 8 million questions 40 million answers As a network #54 site for traffic in the world 560 million page views a month Peak is more like 2600-3000 requests/sec on most weekdays. source: https://www.youtube.com/watch?v=t6kM2EM6so4

Criteria #4 Scalability

Scalability Scale up Scale-out Very easy to scale Always have a limit Hardware is expensive Scale-out Relatively tricky scaling Theoretically infinite scale Can be done on commodity hardware

Criteria #5 Durability

ACID Durability D – for Durability Not all NoSQL databases are durable (at least by default)

Criteria #6 Cost

Cost Hardware License Support Big servers are expensive Small servers are cheep Small servers can be easily replaced License A lot of NoSQL databases are free There are free RDBMS as well Scale Out is more useful for free software Support MSSQL forgives you more than MySQL

Criteria #7 Knowledge

Criteria #8 Polyglot Persistence

Real Architecture of StackOverflow source: https://www.youtube.com/watch?v=t6kM2EM6so4

Summary Tools Domain Workload Scalability Durability Cost Knowledge Polyglot Persistence

More Points “Respect the problem” (c) Think about the future workload grows Think about the future application changes Database itself, even if it is blazing fast, is not a purpose of not to use cache Consider cloud database offers Consider Polyglot Persistence Consider using service tier for data access in application Easier database exchange Tire scaling A/B testing

Thank you! Denis Reznik Twitter: @denisreznik Email: denisreznik@live.ru Blog: http://reznik.uneta.com.ua Facebook: https://www.facebook.com/denis.reznik.5 LinkedIn: http://ua.linkedin.com/pub/denis-reznik/3/502/234