Difference between revisions of "MagnetoDB"
m (→Why not Trove?) |
|||
Line 10: | Line 10: | ||
=== Why it is needed? === | === Why it is needed? === | ||
To provide hight level database service with DynamoDB API interface | To provide hight level database service with DynamoDB API interface | ||
− | === | + | === Integration with Trove? === |
Initially suggested as [https://blueprints.launchpad.net/trove/+spec/http-accessible-storage blueprint] for Trove it was rejected as not following the programm mission. | Initially suggested as [https://blueprints.launchpad.net/trove/+spec/http-accessible-storage blueprint] for Trove it was rejected as not following the programm mission. | ||
MagnetoDB is not one of existing database provisioned by Trove, but storage with HTTP API where Trove is used for provisioning and managing underlaying database. | MagnetoDB is not one of existing database provisioned by Trove, but storage with HTTP API where Trove is used for provisioning and managing underlaying database. | ||
+ | |||
== Overall architecture == | == Overall architecture == | ||
It two layer horizintally scalable web application | It two layer horizintally scalable web application |
Revision as of 21:12, 29 October 2013
Contents
Status
Scope
Document describes the idea and technical concept of DB service for OpenStack like Amazon DynamoDB. There is no implementation yet.
What is MagnetoDB?
MagnetoDB is Amazon DynamoDB API for OpenStack world.
Why it is needed?
To provide hight level database service with DynamoDB API interface
Integration with Trove?
Initially suggested as blueprint for Trove it was rejected as not following the programm mission. MagnetoDB is not one of existing database provisioned by Trove, but storage with HTTP API where Trove is used for provisioning and managing underlaying database.
Overall architecture
It two layer horizintally scalable web application
API
The API consists of the following methods
- BatchGetItem
- BatchWriteItem
- CreateTable
- DeleteItem
- DeleteTable
- DescribeTable
- GetItem
- ListTables
- PutItem
- Query
- Scan
- UpdateItem
- UpdateTable
Implementation
Pluggability
The most suitable data source is Cassandra. But it is better to make datasource plugguble and give the framework for implementation of interface for any other underlying storage.
OpenStack component reusage
Purpose | OS component |
---|---|
Provisioning of web tire | Heat, Mistral (Convection) |
Load balancer | LBaaS, Neutron |
Autoscaling of web tier | Heat autoscaling, Ceilometer |
Data Source provisioning and management | Trove |
Monitoring | Ceilometer |
Authentication | Keystone |
Autoscaling
- Web autoscaling is suggested to implement with HEAT autoscaling group resource
- Datasource scalability based on future Trove autoscaling