NoSQL databases should not be chosen just because a system is slow or to replace RDBMS. The appropriate choice depends on factors like the nature of the data, how the data scales, and whether ACID properties are needed. NoSQL databases are categorized by data model (document, column family, graph, key-value store) which affects querying. Other considerations include scalability based on the CAP theorem and operational factors like the distribution model and whether there is a single point of failure. The best choice depends on the specific requirements and risks losing data if chosen incorrectly.

1. NoSQL database
for great good
@huydx
hanoi.rb

2. $> whoami
huy
Software developer
Tokyo base
ruby/scala user
nickname: @huydx

3. Disclaimer
This talk is not going to go
detail about any NoSQL
I'm going to talk about: when
we need to choose a nosql
db, how should we think?

4. What people often think
about NoSQL?

5. • As cache
• As a magic which can
make "any" web system
faster

6. Your system is slow
Just use NoSQL
RDBMS is shit

7. RDBMS is not slow
NoSQL is not the cure for everything

8. RDBMS is awesome
• Can scan 7m rows / sec with index!
• Can handle very big data (facebook)
• Has very flexible query language (SQL)
• Has some awesome analytics feature
(window function-postgresql)
• Has ACID properties
https://www.percona.com/blog/2008/04/09/how-fast-can-mysql-process-data/

9. Why ACID is important
• Atomicity : protect transaction (all or nothing)
• Consistency: protect data correctness
• Isolation : protect data from concurrency
• Durability : protect data from failure
ACID makes a database something you can
TRUST

10. So
• RMDBS is way better than you thought
• You should learn to do RMDBS the right way
• How to make the best performance from
RMDBS (index tuning, query optimize, data
modeling, master-slave replication,
monitoring, shard-ing the right way....)
https://www.percona.com/blog/2014/03/27/a-conversation-with-5-facebook-mysql-gurus/

11. But this talk is about
NoSQL!!!!!!

12. Where RMDBS is not fit for?
• Nature of data: When data is not row-column
style (multidimensional data)
• How your data scale : Data shard-ing (You
don't want to shard-ing)
• ACID is great, but it degrade performance
• Single point of failure : single master
• Data usage : when you need realtime, fast data
https://www.percona.com/blog/2009/08/06/why-you-dont-want-to-shard/

13. Let's talk about NoSQL

14. We have plenty of players
But when, and how to use them?

15. We have a decent answer:
It depends!!

16. What do you want to store?
• Geo-partial data?
• Users important data? (password, paying
information..)
• Cache data?
• Analytics realtime data (write/read intensive)

17. Where do you want to store?
• On memory?
• On disk?
• On Slow Disk (HDD)
• On Fast Disk (SSD)

18. How big is your data
• Able to fit into memory?
• Able to fit into single machine?
• Not able to fit into hundreds of machine?

19. It's there any factor to category
NoSQL database

21. Data Model
Query Model
+

22. NoSQL categorized by how data model
Document
pair each key with a complex
data structure known as a
document (JSON, BSON).
MongoDB, CouchDB, RethinkDB
Column
Family
One row key pair with many
column (rows in RDBMS) (easy
for block partition)
Cassandra, HBase, Hypertable
Graph
Store data as nodes + link
between nodes
Neo4j, FlockDB
KVS
Just a key + a value (a value can
be complex, but will not be able
to as wide as column family)
Riak, Memcached, Redis,
CouchBase

23. What about
merit / demerit
of each data model?

24. Data model affect how we
query data
User always want query method
to be as flexible as possible
But sometimes, we have to face
the trade-off between
flexibility and scalability

25. • Document : query can be very flexible because
document is examinable (mongodb has very rich
query language). Data model can change very flexible
• Column Family : just a key value with a very wide
fields, which make it very fast to look up a bunch of
values
• Graph : for very special cases when you need to store
and query relationship (followers in twitters)
• KVS : when you really need high performance, and just
need to look up for simple value

26. So it really depends, right?

27. Data model for NoSQL is hard!
So be careful with your selection

28. Sometimes the borderline of
data modeling is blurred
We need other factor to consider

29. Scalability

30. First we need to know about
CAP theorem

31. http://webpages.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf

32. We can only have two of
them!!!!!!!!
NO MORE!!!!

33. http://blog.flux7.com/blogs/nosql/cap-theorem-why-does-it-matter

34. Just ask your self: what do you
care about
• You need very fast write and read, data can be a
little bit stale -> A + P
• You need transaction, and every one must see the
same view, but sometimes something must be
lock -> C + P
• You don't need a distributed system which is false-
tolerance with network problem -> C + A

35. So we have two options to
think about, what's more?

36. Operation

37. Programmer may not care
but
Infrastructure engineer care

38. What factors affect
operation?
• What is your database distributed model, how
they shard, and replicate (master-slave or p2p)
• Do your database run on JVM? (operating a
JVM system is waaaayyy bothersome than a
system written in C or C++)
• Do your database has single point of failure?
• Do your database optimized for SSD only?

39. Operation is hard
When you fail at operation,
you lost your data
So choose what you know
very well about

40. Conclusion
• It's really depends!!!!
• Ask your self: Is it really needed to use nosql?
• First know your requirement, know your data
• Investigate carefully before choosing any
solution (when you fail to choose, you lost
your data)