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

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

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

4. NoSQL
SQL

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

6. Criteria #1
Tools

7. Databases
Key-Value
Relational
Column-Family
Graph
Document

8. Criteria #2
Domain

9. Q&A Web Site (StackOverflow)

10. Domain Model
Questions
Answers
Users
Comments
Votes

11. Criteria #3
Workload

12. 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 requests/sec on most weekdays.
source:

13. Criteria #4
Scalability

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

15. Criteria #5
Durability

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

17. Criteria #6
Cost

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

19. Criteria #7
Knowledge

21. Criteria #8
Polyglot Persistence

22. Real Architecture of StackOverflow
source:

23. Summary Tools Domain Workload Scalability Durability Cost Knowledge
Polyglot Persistence

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

25. Thank you! Denis Reznik Twitter: @denisreznik
Blog:
Facebook:
LinkedIn: