To SQL or No(t)SQL - PFCongres 2012

1,272 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,272
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • Vragen gewoon tussendoor stellen\n
  • Onze projecten moeten de lekkerste gerechten zijn voor de klant\nAlleen maar doen met de beste ingredienten\nzodat klant een magische ervaring heeft\n\nDaar we hebben we personen zoals jullie voor nodig\n
  • Onze projecten moeten de lekkerste gerechten zijn voor de klant\nAlleen maar doen met de beste ingredienten\nzodat klant een magische ervaring heeft\n\nDaar we hebben we personen zoals jullie voor nodig\n
  • Onze projecten moeten de lekkerste gerechten zijn voor de klant\nAlleen maar doen met de beste ingredienten\nzodat klant een magische ervaring heeft\n\nDaar we hebben we personen zoals jullie voor nodig\n
  • Onze projecten moeten de lekkerste gerechten zijn voor de klant\nAlleen maar doen met de beste ingredienten\nzodat klant een magische ervaring heeft\n\nDaar we hebben we personen zoals jullie voor nodig\n
  • WHAT IS THIS?\n
  • \n
  • AND THIS?\n
  • \n
  • Courtesy of Tim Anglade who inspired me to do this talk\n
  • \n\n
  • \n
  • \n\n
  • Biggest bang for buck\n- JS, media\n- HTTP Caching\n- CDN caching\n\n\n
  • WANT TO USE NOSQL OR HAVE TO USE NOSQL\n\nIn 2009 talk, DPC, Scott MacViccar, Alternative databases\n
  • NOSQL USE FOR BOTH SCALABILITY AND PERFORMANCE\n
  • NO SCALABILITY ISSUES?\n
  • SQL, name says it all\nACID for transactions\nBuy support, hire a db consultatnt\nOpen source -> change it to your needs\n\n
  • SQL\nACID for transaction\nBuy support, hire a db consultatnt\nOpen source -> change it to your needs\n\n
  • SQL\nACID for transaction\nBuy support, hire a db consultatnt\nOpen source -> change it to your needs\n\n
  • VERTICAL = performance\nHORIZONTAL = distribution\n
  • VERTICAL = performance\nHORIZONTAL = distribution\n
  • VERTICAL = performance\nHORIZONTAL = distribution\n
  • PEOPLE STARTED TO LOOK FOR NEW SOLUTION FOR STORING DATA INDEPENDENTLY\n
  • PEOPLE QUESTION THEMSELVES\n\nDOES THE WORLD GO DOWN WHEN A REPLY ON FACEBOOK IS GONE?\nEXPERIENCE MORE IMPORTANT THEN ALWAYS CONSISTENT DATA\n
  • EVENTUAL CONSISTENCY\n
  • A DISTRIBUTED SYSTEM CAN ONLY SATISFY TWO OF THE GUARANTEES\n\nDROP P -> You have 2 use one machine\nDROP A -> On partition people will have to wait before the data is consistent again\nDROP C -> What if 2 people buy the same book where there is just one in stock....?\n\n
  • \n
  • GENERALLY SEEN, 4 TYPES\n\nBUT OTHER PEOPLE MIGHT HAVE OTHER OPINIONS\n\n
  • \n
  • \n
  • \n
  • \n
  • Far from complete, as there are 122 NoSQL databases listed on nosql-database.org\n\n\n\n
  • My explanation will be from the point of view of ...\n
  • What to tell about KV\nEvery body knows memcached? Used it?\n
  • PHP ASSOCIATIVE ARRAY = KV STORE\n\n
  • GET IN TOUCH WITH ROSS TUCK\n\nPIETER NOORDHUIS\n
  • \n\n
  • DATA STORED IN RING... make it endless\n
  • EXPLAIN CONSISTENT HASHING\n
  • SHA1 partitioning\n\n
  • \n
  • \n
  • FIRST NODE JOINS THE CLUSTER, CLAIMS THE COMPLETE RING\n
  • \n
  • READ & WRITE QUORUM\n
  • VECTOR CLOCKS\n\n
  • HINTED HANDOFF\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • BETWEENNESS CENTRALITY\n\nIMPORTANT PERSON FOR CONNECTING NETWORKS\n
  • DEGREE CENTRALITY\n\nTHE ONE WITH THE MOST RELATIONS\n
  • CLOSENESS CENTRALITY\n\nSOMEONE WHO CAN CREATE EASY CONTACTS\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • - Best use case -> rapid changing data\n- For example -> analytics, real-time data collection\n
  • - Best use case -> very good availability\n- For example -> no downtime allowed\n
  • - Best use case - rich interconnected data\n- For example - social networks, network topologies\n
  • - Best use case - any data you would store in MySQL\n- For example\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • To SQL or No(t)SQL - PFCongres 2012

    1. 1. To SQL OR No (T) SQL?PFCongres 2012 Jeroen van Dijk
    2. 2. JEROEN VAN DIJK∂ Nerd chief @ ENRISE∂ PHPBenelux board member∂ Zend Certified Engineer∂ Web technology freak∂ Open source addict JEROEN@ENRISE.COM @NEOREY
    3. 3. THE ENRISE RESTAURANT∂ We want to prepare the best dishes∂ With the best ingredients∂ To create a magical client experience!∂ You engineers are our top chefs!
    4. 4. WHAT ISACID?
    5. 5. EVER HEARD OFCAP THEOREM?
    6. 6. KNOWABC?∂ Courtesy of Tim Anglade
    7. 7. Always∂ Courtesy of Tim Anglade
    8. 8. Always Be∂ Courtesy of Tim Anglade
    9. 9. Always Be Caching∂ Courtesy of Tim Anglade
    10. 10. Always Be Caching∂ Courtesy of Tim Anglade
    11. 11. JOIN THE HYPE?WANT!==HAVE 13
    12. 12. HAVE TO USE NOSQL? SCALABILITY & PERFORMANCE 14
    13. 13. HAVE TO USE NOSQL? SCALABILITY & PERFORMANCE 15
    14. 14. RECAP RDBMS GREATNESS∂ Standard Query Language∂ ACID: Atomicity, Consistency, Isolation, Durability∂ Supported by everyone and everything∂ Tuning options∂ Battle tested!∂ Open source?! NOT ENOUGH? 16
    15. 15. MAKING LOADS OF MONEY? 17
    16. 16. BUY A BIGGER BOX 18
    17. 17. NOT SO GREAT RDBMS FEATURES∂ Vertical scalability 19
    18. 18. NOT SO GREAT RDBMS FEATURES∂ Vertical scalability∂ Horizontal scalability 20
    19. 19. NOT SO GREAT RDBMS FEATURES∂ Vertical scalability∂ Horizontal scalability∂ Schema changes! 21
    20. 20. SINCE 2004DATA++++++ 22
    21. 21. WHO NEEDSACID!?
    22. 22. CAP THEOREM AVAILABILITY A C P CONSISTENCY PARTITION TOLERANCE
    23. 23. CAP THEOREM AVAILABILITY A CA AP PICK TWO C P CONSISTENCY PARTITION TOLERANCE CP
    24. 24. CAP THEOREM AVAILABILITYMySQL (InnoDB, not MyISAM) A Dynamo VoldemortPostgreSQL SQL Server Cassandra CouchDB CA APOracle RAC Neo4J SimpleDB Riak PICK TWO C P CONSISTENCY PARTITION TOLERANCE CP Hypertable Hbase BigTable MongoDB Terrastore Couchbase MemcacheDB Redis
    25. 25. 4 NOSQL TYPES
    26. 26. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT
    27. 27. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT
    28. 28. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT
    29. 29. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT
    30. 30. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT∂ 122 known NoSQL databases
    31. 31. 4 NOSQL TYPES KEY-VALUE COLUMN GRAPH DOCUMENT∂ Focus from Redis, Riak, Neo4J, MongoDB
    32. 32. KEY - VALUE KEY-VALUE ∂ Schema-less design ∂ Just strings of data ∂ Hard to query COLUMN ∂ Mostly in memory GRAPH DOCUMENT
    33. 33. KEY - VALUE KEY-VALUE [ COLUMN “key1” => “value1”, “key2” => “value2”, GRAPH “key3” => “value3”, DOCUMENT ]
    34. 34. REDISKEY-VALUE ∂ Blazing fast key-value implementation ∂ Master - slave replication ∂ Lots of methods to query dataCOLUMN ∂ Notable options ∂ Data types : Strings, hashes, lists, setsGRAPH ∂ Data expiration ∂ Pub/Sub for messagingDOCUMENT ∂ Reconsider when using Memcached
    35. 35. COLUMN KEY-VALUE ∂ BigTable or Dynamo style ∂ Consistent hashing ∂ Vector clocks COLUMN ∂ Hinted hand off GRAPH DOCUMENT
    36. 36. COLUMN KEY-VALUE COLUMN GRAPH DOCUMENT∂ Data stored in a ring
    37. 37. COLUMN DKEY-VALUECOLUMN C AGRAPHDOCUMENT B ∂ Consistent hashing with 4 nodes
    38. 38. COLUMNKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Partitioning as done by Riak
    39. 39. COLUMNKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Read / Write....
    40. 40. COLUMNKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Anywhere in the ring
    41. 41. COLUMNKEY-VALUECOLUMNGRAPHDOCUMENT ∂ First node joins the cluster, claims all partitions
    42. 42. COLUMNKEY-VALUE N=3 A B CCOLUMNGRAPHDOCUMENT ∂ Reading / writing is done to 3 nodes
    43. 43. COLUMNKEY-VALUE N=3 A B W=2 CCOLUMN R=2GRAPHDOCUMENT ∂ Reading / writing succeeds with 2 valid responses
    44. 44. COLUMNKEY-VALUE N=3 A [ Ov1,v2 ] B W=2 C [ Ov1 ]COLUMN R=2 D [ Ov1,v2 ]GRAPHDOCUMENT ∂ Node C down, while new write action
    45. 45. COLUMNKEY-VALUE N=3 A [ Ov1,v2 ] B W=2 C [ Ov1,v2 ]COLUMN R=2 D [ Ov1,v2 ]GRAPHDOCUMENT ∂ Node D hands the new version off
    46. 46. RIAK KEY-VALUE ∂ Dynamo implementation ∂ MapReduce query style ∂ Multiple storage backends COLUMN ∂ Notable options § Link walking (like Graph solutions) GRAPH § Solr-like search interface § Secondary indexes DOCUMENT
    47. 47. GRAPH KEY-VALUE ∂ Relations more important then entities ∂ From RDBMS perspective : SELF JOINS COLUMN GRAPH DOCUMENT
    48. 48. GRAPH KEY-VALUE COLUMN GRAPH DOCUMENT∂ Facebook style
    49. 49. GRAPHKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Betweenness centrality
    50. 50. GRAPHKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Degree centrality
    51. 51. GRAPHKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Closeness centrality
    52. 52. GRAPHKEY-VALUECOLUMNGRAPHDOCUMENT ∂ Twitter style
    53. 53. GRAPHKEY-VALUE 2COLUMN 1 9 3 2 1 2 1GRAPH 2 3 3DOCUMENT ∂ TomTom style
    54. 54. GRAPHKEY-VALUE 2COLUMN 1 9 3 2 1 2 1GRAPH 2 3 3DOCUMENT ∂ TomTom style
    55. 55. GRAPHKEY-VALUE 2COLUMN 1 9 3 2 1 2 1GRAPH 2 3 3DOCUMENT ∂ TomTom style
    56. 56. NEO4JKEY-VALUE ∂ ACID compliant ∂ Enterprise product for HA ($$$) ∂ Custom query languageCOLUMN ∂ Notable options § Self contained web adminGRAPHDOCUMENT
    57. 57. DOCUMENT KEY-VALUE ∂ Largest resemblance with RDBMS ∂ MapReduce ∂ Software architect more important COLUMN GRAPH DOCUMENT
    58. 58. MONGODB KEY-VALUE ∂ MySQL of it’s generation?! ∂ Master - slave structure ∂ MapReduce COLUMN ∂ Notable options § Geo indexes GRAPH DOCUMENT SMALLEST LEARNING CURVE!
    59. 59. USE CASES ∂ Rapid changing data which fits in memory KEY-VALUE ∂ Analytics, logging, real-time data collection COLUMN GRAPH DOCUMENT
    60. 60. USE CASES ∂ Rapid changing data which fits in memory KEY-VALUE ∂ Analytics, logging, real-time data collection ∂ Very good availability & fault tolerance COLUMN ∂ Applications where seconds of downtime hurt GRAPH DOCUMENT
    61. 61. USE CASES ∂ Rapid changing data which fits in memory KEY-VALUE ∂ Analytics, logging, real-time data collection ∂ Very good availability & fault tolerance COLUMN ∂ Applications where seconds of downtime hurt ∂ For rich interconnected data GRAPH ∂ Social relational data, geo & maps data DOCUMENT
    62. 62. USE CASES ∂ Rapid changing data which fits in memory KEY-VALUE ∂ Analytics, logging, real-time data collection ∂ Very good availability & fault tolerance COLUMN ∂ Applications where seconds of downtime hurt ∂ For rich interconnected data GRAPH ∂ Social relational data, geo & maps data ∂ MySQL like usage with indexes DOCUMENT ∂ Any type of data you’d fit in MySQL
    63. 63. ONE USEFUL INGREDIENT 65
    64. 64. MORE GREAT TASTES 66
    65. 65. ∂ KLIK VOOR FOOTER 67
    66. 66. Polyglot persistence?∂ KLIK VOOR FOOTER 68
    67. 67. ∂ THANK YOU! FEEDBACK? JOIND.IN/7084
    68. 68. ∂ MORE DETAILS? SCAN THIS CODE.

    ×