Your SlideShare is downloading. ×
If NoSQL is your answer, you are probably asking the wrong question.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

If NoSQL is your answer, you are probably asking the wrong question.

2,663
views

Published on

This session is not about bad mouthing MongoDB, CoachDB, big data, map reduce or any of the other more recent additions to the database buzzword bingo. Instead it is about looking at how NoSQL is a …

This session is not about bad mouthing MongoDB, CoachDB, big data, map reduce or any of the other more recent additions to the database buzzword bingo. Instead it is about looking at how NoSQL is a confusing term and a more realistic assessment how old and new approaches in databases impact todays architectures...

Published in: Technology

3 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,663
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
18
Comments
3
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. If NoSQL is your answer, youare probably asking the wrong question.
  • 2. Hi, my name isLukas Kahwe Smith
  • 3. and I am not a troll
  • 4. @lsmith
  • 5. @lsmith77
  • 6. SQL
  • 7. For the conference werelooking for someone who can be a part of the Databases - short talks presentations togive a lightning talk about SQL.
  • 8. SQL
  • 9. NoSQL
  • 10. NoSQL?
  • 11. Not Only SQL?
  • 12. Time for some pseudo math
  • 13. Given that most relational databases have an SQL interface
  • 14. RDBMS - SQL = NoSQL ?
  • 15. NoSQL + SQL = RDBMS ?
  • 16. Key-Value-Store + Complex Queries = NoSQL ?
  • 17. I am about to blow your mind
  • 18. I have created a database API for unstructuredhierarchical documentson top of an RDBMS with an SQL-like interface
  • 19. And I wasn’t even the first person to do it ..
  • 20. Can we agree to stop using the term NoSQL ?
  • 21. Using NewSQL is not any better!
  • 22. Instead talk about RDBMS, Doc-Stores, Key-Value-Stores, Graph-Databases ..
  • 23. There is clearly a growingnumber of people considering alternatives to RDBMS
  • 24. Actually Key-Value-Stores have been popular for many years already
  • 25. So clearly the current trend is not just about shardingunstructured documents in an elastically scaling cluster
  • 26. Its also not about getting rid ofSQL, after all the CAP theorem doesn’t talk about what query languages to use
  • 27. RDBMS - relational model = ?
  • 28. We still love RDBMS for what their good for Storing and retrievingstructured relational small to large data sets with highconsistency and reliability
  • 29. And yes we also still love SQL Running ad-hoc search queries and schemaupdates even if we are not rocket scientistshttp://2012.nosql-matters.org/cgn/slides/#olaf_bachmann
  • 30. And while JSON queries mightbe easier parsed by computers SQL is definitely easy to parse for humans
  • 31. So what do we really worry about .. ?
  • 32. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 33. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 34. ACID, Asynchronous, AtomicUpdates, BigData, Binaries,CAP Theorem, ColumnOriented, Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 35. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 36. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 37. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 38. ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Failover, FullTextSearch, Graphs, Low Latency, InMemory, MapReduce, Master-Master, Sharding, Smart Clients
  • 39. RDBMS vendors got stuck as a result of their own success
  • 40. Innovators Dilemma
  • 41. “The two biggest issues that stand out to me are that current leading relational databases never solved scale out very well, and online operations are too expensive. [..] Theinnovation hasnt been in the language, but in the design of database engines themselves. “ Brian Aker (Drizzle, previously MySQL) http://blog.krow.net/2013/03/mysql-vs-nosql-vs-postgres-vs-sql.html
  • 42. The good news is thatRDBMS vendors have been unstuck
  • 43. However its hard to move on from a monolithic architecture, Drizzle is a radical attempt at trying it
  • 44. In many ways its easier to start from scratch
  • 45. But lets look at someexamples of things that have happened in the RDBMS world
  • 46. VoltDB, ScaleBase and NuoDB promise elastic scaling ontop of an RDBMS with SQL and ACID* compliance http://voltdb.com/tao-volt/five-principles.php http://www.scalebase.com/solution/ http://www.nuodb.com/explore/sql-cloud-database-how-it-works/
  • 47. Both PostgreSQL andMySQL have native support for JSON (and XML)
  • 48. PostgreSQL performs reads on par with MongoDB, especially for larger data setshttp://www.slideshare.net/stormdb_cloud_database/postgres-xc-askeyvaluestorevsmongodb http://jathanism-event-notes.readthedocs.org/en/latest/scale11x/talks/ postgres_as_a_schemaless_db.html
  • 49. MySQL Server and MySQLCluster allow by passing SQLvia the Memcache protocolhttp://blog.ulf-wendel.de/downloads/nosql_in_mysql.pdf
  • 50. MySQL and PostgreSQL both have forks providing Multi-Master replicationhttp://www.enterprisedb.com/products-services-training/products-overview/xdb- replication-server-multi-master http://www.codership.com/content/using-galera-cluster
  • 51. OQGRAPH Engine to store graphs in Maria DB http://openquery.com/products/graph-engine
  • 52. MySQLND plugins forclient side query caching, transaction aware load balancing http://php.net/mysqlnd_qc http://php.net/manual/en/book.mysqlnd-ms.php
  • 53. Conclusion
  • 54. SQL is not a scalability enemy
  • 55. SQL is not a scalability enemy
  • 56. How big is your data .. really?
  • 57. Operational experience only comes over time, havingsomething solid that just works matters
  • 58. There can be innovation in the RDBMS world
  • 59. Using an RDBMS is fine
  • 60. So is using Doc-Stores, Key- Value-Stores, Graph DBs
  • 61. Using NoSQL is not fine
  • 62. Just pick the right tool for the job ..
  • 63. Duh!
  • 64. Fin