If NoSQL is your answer, youare probably asking the wrong          question.
Hi, my name isLukas Kahwe     Smith
and I am not a     troll
@lsmith
@lsmith77
SQL
For the conference werelooking for someone who can be a part of the Databases - short talks presentations togive a lightni...
SQL
NoSQL
NoSQL?
Not Only SQL?
Time for some pseudo math
Given that most relational databases have an SQL        interface
RDBMS - SQL = NoSQL ?
NoSQL + SQL = RDBMS ?
Key-Value-Store + Complex Queries          = NoSQL ?
I am about to blow your mind
I have created a database API      for unstructuredhierarchical documentson top of an RDBMS with     an SQL-like interface
And I wasn’t even the first    person to do it ..
Can we agree to stop using    the term NoSQL ?
Using NewSQL is not any        better!
Instead talk about RDBMS, Doc-Stores, Key-Value-Stores, Graph-Databases ..
There is clearly a growingnumber of people considering alternatives to RDBMS
Actually Key-Value-Stores have been popular for many        years already
So clearly the current trend is not just about shardingunstructured documents in  an elastically scaling            cluster
Its also not about getting rid ofSQL, after all the CAP theorem    doesn’t talk about what   query languages to use
RDBMS - relational model = ?
We still love RDBMS for what their good for   Storing and retrievingstructured relational small to    large data sets with...
And yes we also still love SQL Running ad-hoc search  queries and schemaupdates even if we are not    rocket scientistshtt...
And while JSON queries mightbe easier parsed by computers  SQL is definitely easy to     parse for humans
So what do we really worry         about .. ?
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries,CAP Theorem, ColumnOriented, Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
ACID, Asynchronous, AtomicUpdates, BigData, Binaries, CAPTheorem, Column Oriented,Elastic Scaling, EventualConsistency, Fa...
RDBMS vendors got stuck  as a result of their own          success
Innovators Dilemma
“The two biggest issues that stand out to me are that current leading relational databases never   solved scale out very w...
The good news is thatRDBMS vendors have been       unstuck
However its hard to move on    from a monolithic architecture, Drizzle is a  radical attempt at trying it
In many ways its easier to  start from scratch
But lets look at someexamples of things that have  happened in the RDBMS            world
VoltDB, ScaleBase and NuoDB promise elastic scaling ontop of an RDBMS with SQL    and ACID* compliance        http://voltd...
Both PostgreSQL andMySQL have native support     for JSON (and XML)
PostgreSQL performs reads  on par with MongoDB, especially for larger data setshttp://www.slideshare.net/stormdb_cloud_dat...
MySQL Server and MySQLCluster allow by passing SQLvia the Memcache protocolhttp://blog.ulf-wendel.de/downloads/nosql_in_my...
MySQL and PostgreSQL    both have forks providing   Multi-Master replicationhttp://www.enterprisedb.com/products-services-...
OQGRAPH Engine to store  graphs in Maria DB http://openquery.com/products/graph-engine
MySQLND plugins forclient side query caching,   transaction aware load         balancing             http://php.net/mysqln...
Conclusion
SQL is not a scalability enemy
SQL is not a scalability enemy
How big is your data ..      really?
Operational experience only comes over time, havingsomething solid that just       works matters
There can be innovation in   the RDBMS world
Using an RDBMS is fine
So is using Doc-Stores, Key- Value-Stores, Graph DBs
Using NoSQL is not fine
Just pick the right tool for          the job ..
Duh!
Fin
If NoSQL is your answer, you are probably asking the wrong question.
Upcoming SlideShare
Loading in …5
×

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

6,213 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 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
6,213
On SlideShare
0
From Embeds
0
Number of Embeds
139
Actions
Shares
0
Downloads
23
Comments
3
Likes
5
Embeds 0
No embeds

No notes for slide

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

  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

×