Introduction to NoSQL

Transcript

1. Introduction to NoSQL
2. HISTORY
3. 1980s - Rise of Relational Databases
4. Persistence SQL Concurrency through Transactions Integration Reporting
5. PROBLEMS
6. Structure of objects. Cohesive units. Stripped out to tables and rows.
8. OBJECT RELATIONAL IMPEDANCE MISMATCH
9. Two different models. Have to be matched. Causes difficulties.
10. Awkward problem. Leads to ORM Frameworks.
11. PREDICTION Mid 1990s
12. Fall of Relational Databases. Rise of Object Databases.
13. Take in-memory structures, map them directly to disk.
14. NOPE
15. TOTAL RELATIONAL DOMINANCE
16. WHY?
17. SQL became an integration mechanism.
19. Fast seek times of tables on mechanical disks.
20. 20 YEARS OF RELATIONAL DOMINANCE INTO 2000s
21. 2000s saw rise of internet traffic. Google. Amazon. etc.
22. Large amounts of data. Scalability issues.
23. Scale vertically. Bigger boxes. More cost. Hit the limit.
24. Scale horizontally. Lots and lots of small boxes. Cheap commodity hardware. Massive grids.
25. PROBLEM
26. Designed to run on one system. Not for large clusters of boxes.
27. Orgs tried to spread SQL without much success.
28. Google - Bigtable Amazon - Dynamo
29. #nosql movement
30. Fall of mechanical disks. Enter flash memory. SSD. No more spindles.
31. WHO NEEDS TABLES?
32. MongoDB HYPERTABLE
 Cassandra Apache HBase CouchDB Dynomite Project Voldemort
33. Non-Relational Cluster-Friendly, exceptions Open Source, exceptions 21st century web origin Schema-less
34. Data Model different from Relational Model
35. KEY-VALUE STORE
36. Hashmap on the disk.
37. DOCUMENT DATA MODEL
38. Storage of mass of documents. Each document is a complex data structure.
39. Usually JSON. XML. Uncool.
40. Query portions of a document. Update portions of a document.
41. Schema less. Shove anything you like.
42. Not the entire truth.
43. Because we retrieve specific pieces of data:
46. Assumption that “quantity”, “price” exist in the document structure.
47. Implicit schema has to be managed. Just like a relational database. But with flexibility.
48. BLURRY LINE KV and Document Stores
49. Key-Value stores let you add metadata to values. Helps to index.
50. Document data stores are queried through an “id”. Kind of like a key.
51. Common notion of a single unit being saved to the database.
52. Transparent document. Opaque value.
53. Aggregate-Oriented
54. Aggregate
55. While modelling, group things into natural aggregates.
56. In Relational DBs, aggregate is splattered across a lot of tables.
57. In Aggregate DBs, aggregate can be saved as a single unit.
58. KVS, aggregate == value DDM, aggregate == document
59. COLUMN FAMILY DB
60. A row key, with multiple column families.
61. Column family, aggregate with columns that fit together.
64. Aggregates in clusters run efficiently
65. ADVANTAGE
66. Same aggregate to push data back and forth.
67. DISADVANTAGE
68. Slicing and dicing data in different ways.
69. GRAPH DATABASES
70. Not aggregates, nodes and arcs data model.
71. Easy to move across relationships between things.
72. Relational DBs are not good at relationships. “Relational” comes from set theory. Joins, intersects, etc.
74. Aggregate oriented databases lump together. Graph oriented databases break things apart into smaller units.
75. CONSISTENCY
76. RDBMS == ACID NoSQL == BASE
77. Atomic. Consistent. Isolated. Durable.
78. Basically Available. Soft state. Eventual consistency.
79. Graph DBs do ACID. Decompose better than RDBMS.
80. Aggregate Oriented Databases don’t need transactions. Aggregates are a single unit. Atomic.
81. CONSISTENCY PROBLEMS
82. Booking a railway ticket at the same time on different nodes.
83. Interview question: 100 people shopping for 10 items on Amazon.
84. CAP THEOREM
85. Between Consistency, Availability and Partition Tolerance. PICK ANY TWO.
86. For the user, consistency vs response time.
87. In concurrency terms, safety vs liveliness.
88. Amazon: we always want to always get people shopping fast. Because what’s the most important thing in America?
89. SHOPPING.
90. NOSQL: WHEN AND WHY?
91. Easy development.
92. Large data.
93. Natural aggregate: newspaper articles, user profiles
94. Integration Problems?
95. Service oriented interaction
96. FUTURE
97. POLYGLOT PERSISTENCE
98. MongoDB, PostgreSQL, Redis, ElasticSearch, Amazon RDS, Redshift
100. FIN.