Rob Harrop- Key Note The God, the Bad and the Ugly - NoSQL matters Paris 2015
•
1 gefällt mir•1,012 views
The impact that NoSQL has had on the technology community cannot be overstated. The proliferation of new and exciting data systems has led to a slew of interesting solutions to problems that were once solved the relational way. In this session we explore all that is great and good about NoSQL: the innovative software, the clever storage paradigms and the reigniting of developer interest in data access. It is unfortunate that NoSQL is not only a force for good in our community. We'll explore some of the darker corners of NoSQL: the disregard for years of proven technology, the overbearing hype, the overblown marketing and the ever present arguments over which technology is best. We close the session by exploring what can be done to extract even more value from the NoSQL movement, where we can improve how the community interacts with the larger technology community and what the future holds for data access technologies.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Rob Harrop- Key Note The God, the Bad and the Ugly - NoSQL matters Paris 2015
Ähnlich wie Rob Harrop- Key Note The God, the Bad and the Ugly - NoSQL matters Paris 2015 (20)
Mehr von NoSQLmatters
Mehr von NoSQLmatters (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Rob Harrop- Key Note The God, the Bad and the Ugly - NoSQL matters Paris 2015
- 1. NoSQL: The Good, the Bad and the Ugly Rob Harrop
- 2. About Me
- 3. • Co-founder of Spring Source • Writer of books • Now co-founder and CTO at Bamboo • UK-based consumer finance startup
- 5. • I like data • My business likes data • NoSQL matters to me!
- 6. Naming
- 7. NoSQL
- 8. Not Only SQL
- 9. –Martin Fowler “When we say "x is a NoSQL database" I think it's silly to interpret NoSQL as "Not Only" because that would render the term meaningless. (You could then reasonably argue that SQL Server (say) is a NoSQL database.)”
- 10. • Not using the relational model (nor the SQL language) • Open source • Designed to run on large clusters • Based on the needs of 21st century web properties • No schema, allowing fields to be added to any record without controls
- 12. IMHO…
- 13. Landscape
- 14. Data Model • Relational • Key-value • Document • Column • Graph • And many more…
- 15. Query Model • SQL • Key/value • Map/reduce • JSON path • Search
- 16. Storage • Distributed • Replicated • In-memory
- 17. Durability • Ephemeral stores • System-of-record stores • Archive store
- 18. Consistency • Linearised • Eventual • Causal
- 19. Operations • Backup • Failover • HA • SaaS
- 20. Good, Bad and Ugly
- 21. Good: Choice
- 22. • Right tool for the job • Choose the simplest tool • Have more fun
- 23. Bad: Choice
- 24. • Making the choice is hard • Danger of analysis paralysis • Might head down the wrong road
- 25. Bad: Complexity
- 26. • Consistency is front and centre • Data models aren’t always straightforward • Might head down the wrong road
- 27. Good: Complexity
- 28. • Illusions of reliability and consistency are removed • Deeper understanding cannot hurt
- 29. Bad: Marketing
- 30. • Many elaborate claims • Plenty of dis-information • Difficult for beginners to find the kernel of truth
- 31. Good: Science!
- 33. • Good quality experience reports • Solid base of literature • Deep analysis • Kyle Kingsbury - Jepsen • Testing isn’t all that hard
- 34. Ugly: Trolling
- 35. • Sheer number of choices leads to many opinions • Exaggerated claims compound with opinions • Claims can be difficult to verify • Evangelism leads to emotional investment
- 37. • No longer one big data model • Compose models to solve a problem • Different models with different requirements • Model per micro-service?
- 38. • Split by use-case • Read model for analytics • Search model • Low latency write model • Layer within use-case • Caching • System of record • Separate write model (CQRS)
- 39. Good: SaaS
- 40. • AWS • Redshift, DynamoDB, Elasticache, S3, RDS • Google Cloud • SQL, Storage, BigQuery, Datastore • Azure • SQL, DocumentDB, Redis, Storage
- 42. Doing NoSQL
- 43. Learn • Understand the concepts • Don’t get overwhelmed! • Read the literature • The Morning Paper from Adrian Colyer
- 44. Specify • What are your performance/reliability/scalability requirements? • How will you handle differing consistency models? • Who owns what data? • How long does data live for? • Does data live in only one place?
- 45. Get Started • Implement something small • Caching, search, analysis • Use ancillary technologies • Blob store • Archive storage
- 46. Get Serious • Get the best out of your SQL database • Identify core functional areas for NoSQL • Low-latency • Document • Migrate gradually • Consider parallel runs
- 47. Get Sophisticated • Segment system into multiple models • Identify consistency/durability/reliability boundaries • Fit the right store to each model • Layer stores within a model as needed