Browse Prior Art Database

The efficient way of database resource management at Cloud Disclosure Number: IPCOM000243043D
Publication Date: 2015-Sep-10
Document File: 8 page(s) / 330K

Publishing Venue

The Prior Art Database


DataBase service is an important service at Cloud Computing. Database-as-a-Service (DBaaS) is a service that is managed by a cloud operator (public or private) that supports applications. It could help release the database maintain effort from the organization, and delicate the job to the cloud operator. The cloud operator is responsible for provision the database service to the client and the management of the database lifecycle. There is traditional database service and NoSQL data service, our solution targets on the traditional database service by default. There are a lot of known solutions to provide the database service. However, they all bind the database constantly with the specific machine (physical or virtual). Once the database is provisioned, the DB is usually up and occupies the hardware resource continuously, which will last for the whole DB lifecycle until the client explicitly end the provision. To reuse the resource more efficiently and provision more appropriate DB to the client, we provide the dynamic database service solution as described in this paper.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 8

The efficient way of database resource management at Cloud


OLAP - On-Line Analytical Processing,

OLTP - On-Line Transaction Processing,

DB - Data Base,

SQL - Structured Query Language,

APPID - Application ID,

HWM - Hard Ware Monitoring.

The core idea of this invention includes:

1. The DB is no longer bind to the specific machine for the whole provision lifecycle. DB instances could walk among different virtual machines at Cloud. The elastic scale out is supported for high volume requirement.

2. The client won't notice the change occurred at above 1, as all are happened at backend. The client will be rerouted to the new DB server automatically.

3. There are several rules to apply the DB host machine change or elastic scale out. A monitor matrix is generated or maintained to guarantee the appropriate operation and resource reuse efficiently.

The advantage of this invention is to leverage the valuable resource at Cloud and save the cost of the client on Cloud. Moreover, the advantages are based


Page 02 of 8

on the guarantee of the stability of the existed client's system.

This invention introduces a dynamic database service management at Cloud. The following is detailed description.

1.1 How it works

Below are the rules to apply the host machine change, DB resource rebalance or elastic scale out.

1). OLTP & OLAP rules.

The traditional database transactions are mainly two types, OLTP and OLAP. OLTP stands for the online business transaction processing, OLAP stands for the analytics to answer multi-dimensional queries. They have different requirement of the host machines. OLTP requires the CPU with high speed as the high concurrency of transactions. OLAP requires the disk with best throughput to query large volume of data from the disk.

 In the cloud environment, we manage different machines for different OLTP or OLAP requirement. It's better for the client to know its application focus on OLTP or OLAP before they make the database service request. However, sometime they may don't know exactly of what kind of transactions they will use or they change their mind after the provision established. Our invention will use the monitor to analyze the SQL they usually issued, and get the result of what kind of SQL they use most. If we get they are on the wrong type machine, we will do the transfer to the appropriate machine.


Page 03 of 8

2). Hot & Cool DB instance rules.

The monitor will monitor the connection or the transaction activeness to judge one DB instance is hot or cool. For the current relational database design, if all the connections against one database are terminated, then the DB is deactivated at the backend, all the memories the DB allocated could be released. And we have the monitor...