Jump to: navigation, search

Difference between revisions of "NoSQL"

Line 2: Line 2:
  
 
== Summary ==
 
== Summary ==
 +
Openstack meant to be used in large public clouds. But rdbms becomes bottleneck in large-scale deployments. NoSQL world is designed for inifinite scalability, hardware failures, at the cost of some features of rdbmses (which might become unnecessary)
  
 
== Why ==
 
== Why ==
 +
RDBMSes: great features: strong consistency, normalization, joins, sorting, and many many more
  
 
=== Problems with RDBMS ===
 
=== Problems with RDBMS ===
 
   
 
   
 
==== Inherent limitations ====
 
==== Inherent limitations ====
 +
 +
 +
1. Doesnt scale -- only vertical scalability
 +
2. Not dc-aware
 +
3. Prone to failures
 +
  
 
=== Solutions to scale RDBMS ===
 
=== Solutions to scale RDBMS ===
Line 24: Line 32:
 
'''TODO'''
 
'''TODO'''
  
Also talk about ugly joins in sql, affecting performance?
+
* Also talk about ugly joins in sql, affecting performance?
 +
* Also talk about this: nosql means no sort keys on any random column?
 +
* ^^ in short, means that openstack already developed it's apis with an assumption that all backends are going to have those functionalities, which becomes false once we throw nosql in the mix. So such api's should be made optional/extensions? E.g. sort keys?

Revision as of 07:28, 13 April 2015

Revised on: 4/13/2015 by Rushiagr

Summary

Openstack meant to be used in large public clouds. But rdbms becomes bottleneck in large-scale deployments. NoSQL world is designed for inifinite scalability, hardware failures, at the cost of some features of rdbmses (which might become unnecessary)

Why

RDBMSes: great features: strong consistency, normalization, joins, sorting, and many many more

Problems with RDBMS

Inherent limitations

1. Doesnt scale -- only vertical scalability 2. Not dc-aware 3. Prone to failures


Solutions to scale RDBMS

NoSQL

Linear scalability

DC-awareness

Robust and designed with failures in mind

Why Cassandra ?

TODO

  • Also talk about ugly joins in sql, affecting performance?
  • Also talk about this: nosql means no sort keys on any random column?
  • ^^ in short, means that openstack already developed it's apis with an assumption that all backends are going to have those functionalities, which becomes false once we throw nosql in the mix. So such api's should be made optional/extensions? E.g. sort keys?