Difference between revisions of "NoSQL"
(→Summary) |
|||
| Line 2: | Line 2: | ||
== Summary == | == Summary == | ||
| − | + | Presently, majority of OpenStack relies on relational databases for storing state. There are some limitations of such relational databases which might affect the overall scalability and maintainability (operationally) of a deployed cloud. This wiki tries to list down all the properties which NoSQL databases will bring to OpenStack world, along with some of their trade-offs. This wiki will take Cassandra as the reference NoSQL database, but the concepts should apply to most of the key-value store NoSQL databases. | |
== Why == | == Why == | ||
Revision as of 10:31, 13 April 2015
Revised on: 4/13/2015 by Rushiagr
Contents
Summary
Presently, majority of OpenStack relies on relational databases for storing state. There are some limitations of such relational databases which might affect the overall scalability and maintainability (operationally) of a deployed cloud. This wiki tries to list down all the properties which NoSQL databases will bring to OpenStack world, along with some of their trade-offs. This wiki will take Cassandra as the reference NoSQL database, but the concepts should apply to most of the key-value store NoSQL databases.
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?
