Demystifying NoSQL. Erik Ljungstrom

Transcription

1 Demystifying NoSQL Erik Ljungstrom

2 Traditional Relational Databases

3 Strengths o Tried and tested - very few nasty surprises there o Versatile A lot of tools and solutions at your disposal o Decent performance Not bad, not bad at all o Easily managed Most people have some proficiency in some RDBMS o Plenty of tools and literature available - RTFM o Numerous Lots to chose from o Large feature set character sets, storage engines, replication features...

4 Weaknesses o Versatile versatility comes at a cost! Workarounds, generic cases etc. o Large feature set Developer attention, bugs, bloat, workarounds o Backwards compatibility More bloat, restrictive for developers, old_passwords=1 anybody? o Traditionally difficult to scale Many RDBS not built for high concurrency and high availability etc. Often implemented in afterhand or in OS

5 NoSQL NotonlySQL

6 What is NoSQL? o Not a product! o A concept way of thinking o Collective name for various tools and products o Usually a complement to an RDBMS o Cassandra, Hadoop/Hbase, Hypertable, CouchDB, MongoDB, Memcached, Redis, LightCloud, Tokyo Cabinet/Tokyo Tyrant o I could go on...

7 What NoSQL is not o A straight up replacement for the more traditional RDBMS o The solution to world hunger o Overly easy to implement o A magic bullet

8 What is on offer? o Column family o Object databases o Grid databases o XML databases o Multi-value databases o Document stores o Key/Value stores o Graph stores

9 Document stores o MongoDB, CouchDB, Terrastore etc. o Forget word documents! o A document is essentially a collection of related data retrieved using an indexed key o All related data stored in the same place o Often represented by XML, YAML or JSON o Usually entirely schema-less. No concept of field length or sizes. o Good for realtively unstructured data, where relationships aren't important o An example of a document can be: Model= Ford, Make= Taurus, BHP=200, Owners=( Harris, Steve, Dickinson,Bruce, Murray,Dave ) o No link tables or foreign keys! o Not ideal if you want to find out all cars owned by Bruce Dickinson! o Plan your document structure carefully!

10 Key/Value stores (KV) o Memcached, Redis, Tokyo cabinet/tyrant... o Indexes and stores values based on a key o Each value has one and only one key o Ideal for things such as UserID->User Info mapping. o Value can be anything, often serialised objects/data o Typically used in a caching scenario, or a specialised database with a subset of your data o No relationship between data whatsoever o Can usually replace any simple PK lookups you are doing in an RDBMS

11 Graph stores o Neo4j, Bigdata, Allegrograph... o A way of representing data. Especially relationships between data o Also exists as implementations (storage engines) in a few RDBMS o Structured into 'nodes', 'properties' and 'edges' o A node is an object, which has properties. Nodes are connected via edges. Edges also have properties. o If car is a node, it's properties might be vehicle, van. The node boat would share the property vehicle via an edge o Edges connects nodes with other nodes, or nodes with properties. They are what makes sense of the data. o Typical usage is friends of friends on social networks. Customers who bought x also bought y

12 Graph stores cont d

13 Why NoSQL might help o Purpose written tools o No baggage! o Solving new problems with new technology o Specific solutions to specific situations o Keeps things neat no dirty hacks or workarounds o Often built in redundancy o Often scales itself, more or less o Speed! It's all about the user experience o Cutting costs

14 Considerations with NoSQL o Do I need it now? Yesterday? In the future? Never? o Means to an end not an end. o Wade in slowly do not rush. Plan carefully - shop around! o Explore the offerings o Is my data suitable for use with NoSQL? (ACID/BASE/CALM) o Is there a connector/driver/interface for your language? Far from all projects have bindings for all popular languages o If unsure I am sure your hosting company can help you out!

15 When worlds collide... HandlerSocket! A look at what 20 years of baggage and added features can do to performance. o Concieved by Yoshinori Matsunobu at DeNA o Circumvents MySQL's connection handling, input parsing, execution planner, mutex locks, query optimiser etc. Straight in to InnoDB o Seven times faster than going through MySQL for primary key lookups o Memcached performance but with the durability of InnoDB

16 Picture: Nathan Hurst (nahurst.com)