a NoSQL Introduction

1. Some
NoSQL

2. By "SQL" we mean :
Relational DBs

3. So NoSQL:
Non-Relational
The biggest difference

4. So, what is relational?

5. Data is represented by
Tables and Relations
Relational model, created by IBM in 69

6. Data manipulation is done
by queries
grouped by transactions

7. What is the problem with
that?

8. "It does not scale"

9. A common, but bad,
answer!

10. Why is it common?

11. ACID
The 4 qualities of transactions on a relational model

12. Atomicity, Consistency,
Isolation, Durability

13. Atomicity
Each transaction is "All or nothing".

14. Consistency
Each transaction brings the Database from a valid state
to another

15. Isolation
Concurrent transactions have no side effects
(reentrancy)

16. Durability
Once a transaction is commited it remains so (even on
shutdown)

17. Brewer's CAP theorem

18. Of Consistency,
Availability and Partition
tolerance
Chose two

19. You cannot scale without
Partition tolerance
no mainframe would be that big!

20. You cannot afford
ignoring availability
Sorry customer our service is down again!

21. So to scale you have to
drop consistency
which means some stale data is ok. that is a
compromise. A risk to be taken and considered.

22. ACID means having
Consistency

23. to scale you need an
alternative

24. BASE

25. Basic Availability Soft-
state Eventual consistency
details here : http://www.cs.berkeley.
edu/~brewer/cs262b-2004/PODC-keynote.pdf

26. You drop Consistency for
Eventual Consistency
That is the most important change for scaling purposes

27. All that is true!

28. So if Relational implies
ACID and ACID does not
scale?
then: relational databases do not scale, right?

29. Wrong!

30. Why is the argument bad?

31. see Facebook
The worlds biggest hive of data

32. Facebook uses several
datastores
polyglotism, we will get to that

33. But most of facebook data
is on MySQL
and it scales

34. You can make your
relational data behave in
a BASE way
Given enough effort, time and money.

35. Should you?
it depends on your data

36. So what is the problem
with the relational model?
The real one?

37. "If all you have is a
hammer, everything looks
like a nail"
Abraham Maslow, The Psychology of Science, 1966, p.
15

38. We use it for
non-relational data

39. Your App
Model Logic (the M in MVC)
Model Translator (ORM usually)
Database Abstraction Layer (avoid lock in)
SQL Generation (souped up concatenation)
SQL Interpreter
Database (Complex Algorithms)

40. Several layers just to
force our data to be
something else
AND to go back being our data!

41. This adds bugs
in each layer

42. This adds performance
costs
in all those translations

43. This adds integration
costs
Ever spent dev time making those layers work?

44. This adds Dev costs
You must jump hoops making your data behave
relationally

45. What about NoSQL ?

46. Several data representations!
● Key-Value
● Document
● Column-Family
● Graph
● XML-bases
● Object
● Grid
● mixed (using several types)
● etc.

47. Key-Value
Redis, Riak, CouchBase, etc.

48. Key-Value Datastore: What is it?
You store keys (identifiers) and values (pretty
much anything, serialized)
Just a quick way to store things under a name
and recover them using that name.

49. Key-Value Datastore: When to use?
● Dictionaries
● Session data
● User preferences
● Shopping cart
● Anything whose content you do not want to
scry or query.

50. Key-Value Datastore: When to avoid?
● You have relations
● You have multi-operational transactions
● You want to query the values
● You want to operate on sets of entries

51. Document
MongoDB, CouchDB, TerraStore, RavenDB, Lotus Notes,
etc.

52. Document Datastore: What is it?
As with the key-value, but your data is not
amorph is a document!
Each document behaves like an Hash-table, it
has entries of a given kind that may
themselves have entries (like a xml or json
file).
documents are schemaless, you have complete
liberty of what goes inside them.

53. Document Datastore: When to use?
● When you have documents!
○ Blogs
○ CMS
● When freedom of schema is required
○ Analytics
○ E-commerce products
● When you wanted a key-value but wanted
to query the values.

54. Document Datastore: When to avoid?
● You need complex/atomic transactions over
different documents
○ in that case you may have a relation, you may need
sql after all!
● The schema-free usage render your queries
impossible.
● You want to force a schema.

55. Column-Family
Hadoop, Cassandra, Amazon SimpleDB, Amazon
DynamoDB etc.

56. Column-Family Datastore:
What is it?
Data in tables of rows and columns like the
relational model but:
● Each row has a varying number of columns
(hence the name)
● Each row is timestamped for comparison,
expiring and conflict resolution.
● There is no master node; writing can be
scaled by adding nodes.
● A column may contain another row.

57. Column-Family Datastore:
When to use it?
● Logging
● Registering events
● Counters
● when you have massive concurrent writes
with small chances of collisions (facebook
uses for their internal messaging system)
● when your information has a due date

58. Column-Family Datastore:
When to avoid it?
● You need ACID
● You need aggregate results (sums,
averages, etc)
● Your data is not tabular

59. Graph
Neo4J, Titan, FlockDB, OrientDB etc.

60. Graph Datastore: What is it?
Data is represented by nodes (objects)
connected by vertices (relations).
The very school definition of a graph.
The same data can represent several graphs.
Graph traversal may be persisted as a relation.

61. Graph Datastore: When to use it?
Anywhere you should already be using Graphs
on your application:
● Any relations (in the relational model
sense) that have no data.
● Social relations (friend of, employee, chief
of, etc)
● Dependency
● Geographical data
● Routing, dispatching etc.

62. Graph Datastore: When to avoid it?
Your application writes over large sets of
nodes commonly (writing to many nodes at
once is expensive)
Your relations carry payloads (in that case you
need sql)

63. Which one to chose?

64. The ones closer
to your data
yes plural

65. Polyglot Persistence
Different Datastores for different Data

66. For each slice of data you
want to store

67. Ask what datastore model
would better represent it

68. Stop nailing screws!

69. How do you diagnose the
correct type of each data?

70. Linagora can help!

72. Questions?