Abstract

This paper studies dynamic pricing for cloud service where different resources are consumed by different users. The traditional cloud resource pricing models can be divided into two categories: on-demand service and reserved service. The former only takes the using time into account and is unfair for the users with long using time and little concurrency. The latter charges the same price to all the users and does not consider the resource consumption of users. Therefore, in this paper, we propose a flexible dynamic pricing model for cloud resources, which not only takes into account the occupying time and resource consumption of different users but also considers the maximal concurrency of resource consumption. As a result, on the one hand, this dynamic pricing model can help users save the cost of cloud resources. On the other hand, the profits of service providers are guaranteed. The key of the pricing model is how to efficiently calculate the maximal concurrency of resource consumption since the cost of providers is dynamically varied based on the maximal concurrency. To support this function in real time, we propose a data structure based on the classical B+ tree and the implementation for its corresponding basic operations like insertion, deletion, split, and query. Finally, the experiment results show that we can complete the dynamic pricing query on 10 million cloud resource usage records within 0.2 seconds on average.

1. Introduction

In recent years, the development of cloud computing is extremely rapid [1]. With the cloud computing, we can deploy different kinds of computing resources in the cloud, rather than a specified server [2]. In other words, there is no need to use hardware equipment, which is very convenient for the companies or organizations so they can focus on their core businesses rather than expending resources on computer infrastructure and maintenance [37]. Therefore, more and more users are looking for the cloud computing, which makes the cloud resource providers emerge. Due to the reason that the service deployed in the cloud may migrate between different resources, and in the meantime mobile users such as smart devices cause the dynamic change in resource consumption, hence, a dynamic pricing scheme is needed for both service providers and consumers.

The traditional cloud resource pricing models can generally be divided into two categories. The first one is on-demand service; i.e., the users should pay for the fee, which is based on the using time and the actual resource consumption. This pricing model is suitable for the short-term users. The second one is reserved service; i.e., each user pays a fixed fee for a month or year and could use the cloud resource during this period of time without limitation.

However, both of the two pricing models have disadvantages. For the first one, users are required to pay a huge fee if they use the cloud resource for a long time. But in this case, the concurrency for these users maybe little; e.g., only one computer is online, and compared with users who have multiple computers online simultaneously, it is unfair to charge users with little concurrency. As for the second one, it is unfair for the users who use the cloud service for little time monthly. They must pay for the same fee with the users who use the cloud resource for a long time. Therefore, it is meaningful to design a more reasonable pricing model for the cloud resources service.

In this paper, for cloud resource, we propose a flexible dynamic pricing model which takes into account occupying time, resource consumption, and maximal concurrency. In our pricing model, the fee of cloud service for the user is mainly composed of three parts: the monthly rental, the fee of his maximal concurrency, and the fee of his using time and resource consumption. As we all know, it is inevitable that many users use the cloud resources at the same time, which may cause a great concurrency of resource consumption on the cloud servers. The greater number of concurrency is, the higher load is on the cloud servers, which results in the higher cost for the cloud resource providers. In other words, the cost of the cloud resource providers is mainly determined by the maximal concurrency of all the users. In fact, many service providers also price their service based on the maximal concurrency of resource consumption that the user needs, which also motivates our work.

However, the dynamic of service migration and user mobility causes a large number of records for the resource consumption, which makes it challenging to find the maximal concurrency of resource consumption in real time when we calculate the fee of the cloud servers for users in our dynamic pricing model.

Suppose that there are 100,000 users using the cloud resources with their usage records. In order to calculate the cost, the cloud resource provider needs to query their usage records and work out the maximal concurrency. However, it is difficult to find the maximal concurrency of resource consumption since it may occur at an arbitrary instant time. It would be extremely inefficient if we calculate the concurrency for each timestamp when data amount is large. Therefore, we should design a new efficient algorithm to find the maximal concurrency. As we know, this problem is similar to the aggregation query [8] since both of them calculate the overall information at a given time. However, different from the aggregation which has a time interval as a given condition, our problem needs to calculate the maximal concurrency without a time interval. Therefore, there is no existing algorithm that can solve this problem directly as far as we know. In order to solve the problem, we propose a data structure called B++-tree and corresponding operations including insertion, deletion, and split. Additionally, query processing algorithm based on B++-tree is also presented. Basically, we solve the efficiency issue by storing all users records into B++-tree and calculating the maximal concurrency of resource consumption by traversing all leaf nodes of B++-tree.

The contribution in this paper can be summarized as follows:

(1) We propose a more reasonable pricing model of cloud resource, which takes into account occupying time, resource consumption, and maximal concurrency.

(2) We propose a data structure called B++-tree and the operational algorithm based on B++-tree to calculate the maximal concurrency which is the fundamental of the cost for the cloud resource providers.

(3) We performed extensive experiments to test our algorithm. The experiment results show that we can complete the maximal concurrency query on 10 million data within 0.2 seconds.

The rest of this paper is organized as follows. Section 2 discusses the related work. Section 3 introduces the pricing models we proposed. Section 4 introduces the B++-tree and the implementation details for its corresponding operations. Section 5 presents the experiment. Section 6 is our conclusion.

Our problem can be divided into two major subproblems: (1) how to design a reasonable pricing model and (2) how to find the maximal concurrency of resource consumption. Therefore, we investigate related work from these two parts, respectively.

For the first part, cloud computing is different from the classic distributed system. The pricing model of the cloud service should take the pricing fairness, evolving system dynamics, and cost of failures into account [9]. The existing pricing schemes in the cloud market can be summarized into three types: trading on-demand service, reserved service, and spot service, respectively [10]. Trading on-demand service means that the cost of a user is based on the time he used for cloud resources. But users pay a fixed fare for cloud resources in the reserved service. These two static pricing schemes are the main pricing models in the current cloud market [11, 12]. Different from them, the spot service is a dynamic pricing scheme where users’ payments depend on the relation of their demand and the available cloud resource. Based on the main idea of the spot model, many kinds of dynamic pricing model have been proposed in recent literature, like auction mechanisms [1316]. Zheng et al. [17] developed a predator-prey model which can simulate the interactions between demand and resource and compute the fare of cloud service. Zhang et al. [18] proposed a joint pricing and scheduling strategy and proved the worst-case competitive ratios of the pricing functions. However, none of above works consider the dynamic pricing for cloud service that we do since the algorithm proposed in this paper can efficiently report the total cost for the providers no matter how the service migrates or user behaves.

For the second part, as far as we know, there are few algorithms that can find the maximal concurrency of resource consumption to solve our problem directly. But we find a closed problem called temporal aggregations, in which there are some temporal aggregations operators such as count, sum, and average. These operators are similar to the method of calculating the maximal concurrency. There are also many algorithms to solve temporal aggregations problem. Kline and Snodgrass [19] proposed aggregation tree, which is a data structure, to support incremental computation for temporal aggregation. However, the aggregation tree is unbalanced whose time complexity is for constructing a tree, where is the number of intervals. Moon et al. [20] presented a balanced tree algorithm whose time complexity is , where is the number of intervals. Besides, Moon et al. [21] also proposed a bucket algorithm and parallelized it on a shared-nothing architecture. Yang and Widom [22] presented a data structure called SB-Tree which combines B-tree [23, 24] and segment tree [25]. SB-Tree can feedback a query in and an update in , where is the number of intervals. However, there is a difference between our problem and temporal aggregation. The time interval is a condition given in the temporal aggregation. But in our problem, we do not know when the concurrency of resource consumption is maximal. In other words, we do not have a certain time interval in our problem which needs to be calculated by our algorithm. Therefore, the algorithms for temporal aggregation cannot solve our problem directly.

3. Pricing Model

As mentioned in Section 1, the maximal concurrency of resource consumption plays an important role in pricing the cloud service. In other words, the price is mainly decided based on the maximal concurrency on cloud servers at the same time.

To further illustrate the meaning of the maximal concurrency, we give an example as follows. Table 1 and Figure 1 show the using time and usage records of four users, A, B, C, and D. Each user record consists of a time interval and its concurrency. The time interval represents the time range of users using the cloud resources. We can easily see that user A uses the cloud resources in time interval and his concurrency is 2.

According to Table 1 and Figure 1, we can split the original interval again, which is shown in Table 2. In Table 2, obviously we can see that 11 is all the users’ maximal concurrency of resource consumption. So we find out the cost of the cloud resource provider. After that, we can calculate the user’s price based on his usage data and the profit for the cloud resource provider.

Next, based on the maximal concurrency of resource consumption, we can design the following price model.

3.1. Pricing Model

Modeling the Concurrency. Suppose that there is a rate , which means the cost of each concurrency for the cloud service provider. In addition, in a certain month, the total number of users is and the maximum concurrency of resource consumption is . Therefore, the cost of the cloud service provider is . As for users, we propose a new pricing model. Firstly, each user needs to pay for as the monthly rental. In addition, the provider will charge a fee for each user based on his maximal concurrency. Therefore, a user should pay for his resource consumption. Finally, the profit of the cloud service provider is

Example. As shown in Figure 2, assume that the user’s monthly fare , the rate . From time 1 to 7 is a month. The maximum concurrency of each user , , and is 4, 7, and 5, respectively. The cloud service fare of users , , and is , , and . The maximum concurrency of resource consumption is the dotted line part in the figure, which is . Therefore, the profit of the cloud service provider is .

However, this pricing model has some drawbacks. For example, the user uses the cloud server for a little time. But he needs to pay for more fare than user because of his higher concurrency. Therefore, the merely using concurrency model is not reasonable in some special cases, and we further improve this model by taking resource consumption into account.

Combining Resource Consumption. Assume that a user has records of cloud resource consumption on the current month and each record starts at and ends at . The concurrency of the record is . Therefore, the cloud consumption of is . In addition, the maximal concurrency of user is . The final cloud service fare of can be calculated by following equation:where is a factor that adjusts the using time and the maximum concurrency of users. is the resource consumption rate which means the cost of each resource consumption. is the maximum concurrency rate. is the monthly rental of cloud service. The values of , , , and can be adjusted according to actual needs.

Example. Still using Figure 2 as an example, assume that the user’s monthly rental , the maximum concurrency rate , the usage rate , and is 0.5. Then the consumption of users , , and is , , . The maximum concurrency of each user , , and is 4, 7, and 5, respectively. Therefore, the cloud service pare of users , , and is , , and . The profit of cloud service providers is .

This pricing model compensates for the defect of the former price model which only takes the maximum concurrency of resource consumption into account. This pricing model adds the factor of users’ resource consumption, which makes the model more reasonable. Besides, we can adjust the coefficient α to adapt to different cloud resources and make the model more flexible.

4. Algorithm Description

In Section 3, we propose a flexible dynamic pricing model for cloud resources. As the maximal concurrency of resource consumption plays an important role in the pricing model, how to efficiently calculate the maximal concurrency of resource consumption is a difficulty in our problem. Because when we calculate the price for resource consumption in cloud service, we should calculate the maximal concurrency of resource consumption first. Therefore, we propose a new data structure and the operational algorithms based on it to solve this problem.

In this part, we will introduce the new data structure called B++-tree which extends from B+ tree. We first introduce the structure of the B+ tree and then introduce the structure of the B++-tree. Finally, we introduce the insertion, deletion, and split operations of B++-tree, which can calculate the maximal concurrency of resource consumption.

The nodes of B+ tree can store a lot of index entries, which helps reduce the height of the tree. Besides, the leaf nodes of B+ tree are connected by pointers. It is very suitable for the query. The following is a brief introduction for the B+ tree.

Each B+ tree has a parameter called capacity , which determines the maximal capacity for each node. For each interior node, it contains () elements and points to child nodes. For each leaf node, it contains () elements and have a pointer to its right sibling node as shown in Figure 3. In this way, it is efficient to traverse all leaf nodes by utilizing their pointers rather than traversing from the root.

But a simple B+ tree cannot solve our problem, because we need to store the concurrency of resource consumption into the tree. So we propose a new data structure called B++-tree, which extends from B+ tree.

4.1. Structure of B++-Tree

Different from B+ tree, we add an addition attribute for each leaf node of B++-tree, which is used to store the concurrency of each interval. Note that the interior nodes keep the same structure as the B+ tree and do not have the additional attribute. In this way, the concurrency of all intervals is stored in leaf nodes, and we can only traverse leaf nodes to obtain the final result, which improve the performance of our algorithm efficiently.

In the B++-tree, each node can hold up to timestamps. If the number of timestamps stored in the node exceeds , we should call split (Section 4.4) process to split the overflowed node into two new nodes. Actually, two adjacent timestamps in a node represent an interval. The interval is a criterion which can help us determine the child node that we need to traverse when we need to insert or delete a new record. The detailed structures of interior nodes and leaf nodes are as follows.

Interior Node. The structure of an interior node is shown in Figure 4. Each interior node contains () intervals, . to are the corresponding pointer to the child nodes. is associated with .

is the th interval. There are two special conditions:

(1) The start time of is , if node is the root node or it is the first child. Otherwise, the start time of is , where is the parent node of and points to .

(2) The end time of is , if this node is the root node or it is the last child. Otherwise, the end time of is , where is the parent node of and points to .

Leaf Node. Figure 5 shows the structure of a leaf node. Compared with interior nodes, leaf nodes have additional attributes which store the concurrencies of intervals. The definition of leaf nodes’ intervals is the same as interior nodes. Moreover, each leaf node has a pointer which points to its next sibling leaf node. Specially, the last leaf node has no pointer. In addition, there is a header pointer pointing to the first leaf node.

For example, Figure 6 plots the example of B++-tree. The first interval of is and the last interval of is , because it is a root node. The first interval of is , because it is the first child of its parent, and the concurrency of the interval is 0. The first interval of is , and the concurrency of the interval is 2.

4.2. Insertion

Main Idea. In this section, we introduce the insert operation. We define the procedure as an insert operation, where indicates the user’s usage interval, such as , indicates the user’s concurrency, and indicates the node that to insert. Insertion will be firstly processed from the root node . We firstly traverse the root node and find the intervals which intersect with . If intersects with , we search in the and traverse it in the same way until the leaf nodes. When we traverse to a leaf node , we find the intervals which intersect with and add the to its corresponding concurrency.

Description. Algorithm 1 shows the pseudo code of insertion. The input is the interval , and the output is the B++-tree after insert . Suppose that now we want to insert the record into the tree. Start from the root node (line (1)), for each interval of :

Input: Interval .
Output: B++-tree after inserting .
(1)   Start from the root node
(2)   for each interval in . do
(3)   if interval intersects with
(4)   if   is the leaf node
(5)   Set the common interval of and as the new
  interval, add of and of to the new
  interval
(6)   else
(7)   search into the child node of , insert to
  , back to step (2).
(8)   end if
(9)   end if
(10) end for

(1) If intersects with the time interval and is a leaf node, and if interval contains , then add to directly (line (5)). If interval does not contain but only intersects with it, then we take their intersecting interval as a new interval and add to the new interval. The original interval keeps unchanged (line (2)~(5)).

(2) If intersects with the time interval but is an interior node, then call , i.e., regarding as N, executed the algorithm start from the second step (line (6)~(7)).

Example. For example, we want to insert to the tree in Figure 6. As for , only interval intersects with interval , so we insert to its child node. Then we find the second interval of , which is contained by the interval that we want to insert. So we add to directly, as shown in Figure 7.

As a slightly more complicated example, suppose that we want to insert to the tree in Figure 6. Firstly we start from the root node . We can see that only interval intersects with the interval , so we should still call . Now is the leaf node and the interval and both intersect with the interval . As for , it is contained by , so add directly. As for , , they have an intersecting interval . So we create a new interval and its concurrency is . Other intervals keep unchanged. Then we complete the insertion of , as shown in Figure 8.

4.3. Deletion

The deletion operation is similar to the insertion operation. We can regard the deletion operation as an opposing operation to the insertion. Specifically, if we want to delete the record , we can insert a record . Therefore, deletion operation can be easily understood without extra explanation.

4.4. Split

Main Idea. As records are inserted, the number of leaf nodes’ intervals gradually increases. As mentioned above, each node can hold up to intervals. Therefore, when a node becomes overflowed, i.e., its number of intervals exceeds , we should split into two nodes and . The first half intervals of are assigned to and the remaining intervals of are assigned to . Suppose is the parent node of . Because of the split of , the numbers of interval in will be added 1. If also become overflowed, split .

Description. Algorithm 2 shows the pseudo code of split. The input is the node which is overflowed and the output is nodes and which are split from . Suppose that node is overflowed and currently stores intervals. We define the procedure as . Specific operations are as follows:

Input: Node which is overflowed;
Output: Node and which are split from .
(1)   create new node and
(2)   retains the first half intervals of the original node
  ; retains the rest of intervals
(3)   if is the interior node
(4) retains the first half pointers, retains the
  rest of pointers
(5)   if is the leaf node
(6) retains the first values, retains the rest values
(7)   if is the root node
(8)   create a new root node , make it be the
  parent node of and . Make be the new
  root node
(9)   else if is not the root node
(10)   suppose is the parent node of , make
be the parent of and
(11)   end if
(12)   If is overflowed
(13)   Split
(14)   end if
(15)   end
(16) end

(1) Node splits into and . Node retains the first half intervals of the original node ; i.e., retains the first time points. If is an interior node, also retains the pointer from to . If is a leaf node, also retains the first values from to . Node retains the rest of intervals, which means retains the time points from to . If is the interior node, also retains the pointer from to . If is the leaf node, also retains the value from to (lines (1)~(6)).

(2) If node is the root node, then create a new root node , which is the parent node of and . Make , , and (line (7)~(8)).

(3) If node is not the root node, suppose that is the parent node of , and . Keep the first intervals of unchanged. Then starting from the th interval to the end, move them to the right one. Make , , and . If node is overflowed, call (lines (9)~(13)).

Example. For example, Figures 9-10 show us how the nodes split. Suppose that the capacity of the tree is 4. This means if the number of node’s intervals exceeds 4, the node needs to be split. The node in Figure 9 has 5 intervals, , , , , and , whose intervals are bigger than 4, so the node should be split.

According to the split rules, node split into and . keeps the first 3 intervals: , , and . keeps the remaining intervals: , . Because the node is leaf node, so keeps the first 3 values and keeps last 2 values. Move to . The result of the split is shown in Figure 10.

4.5. Query for the Maximal Concurrency

When the index building is complete, we can traverse all leaf nodes to acquire each interval and corresponding concurrency. Since all leaf nodes are connected by pointers, we can easily traverse these leaf nodes sequentially without traversing any interior node.

For example, in Figure 6, traversing the leaf node we can get the result: , , , , , , , . It is easy to see that the maximum number of concurrent users is 7.

When we get the maximal concurrency, we get the cost of cloud resource provider. Then we can use our pricing model to charge each user.

5. Experiment

In this section, we provide experimental evaluation of our algorithm. We simulate five datasets which contain 10,000, 100,000, 500,000, 1 million, and 2 million records, respectively. Each record in the dataset contains the user’s name, time interval, and the concurrency. For example, “-->2017-07-31 11:46:15, 2017-07-31 21:02:56, 4” is a record. “” is the user’s name, and his time interval is from “2017-07-31 11:46:15” to “2017-07-31 21:02:56”; the concurrency is 4. We design a series of experiments in the construction of the B++-tree and the performance of operations, like query, insertion, and deletion. There are two explicit factors in our experiments, which are the data size and the capacity . Thus, we conduct two sets of experiments by changing the data size and the capacity. For the one set of experiments, we change the data size while fixing the value of capacity. For the other set of experiments, we change the capacity while fixing the data size.

5.1. Construction of the B++-Tree

Firstly, we test the performance of the construction of B++-tree. In this experiment, we change the data size and capacity to compare with the time needed to build a B++-tree.

In Figure 11(a), we vary the data size from 10,000 to 2,000,000, while fixing the capacity to 50. We denote the time of constructing a B++-tree as CT, which means the construction time. As we can see, when the data size is small, for example 10,000 and 100,000, their CTs are very small and similar. But with the growing of data size, CT is also increasing. The greater the size of data is, the more CT consumed. Because with the increment of data size, the structure of B++-tree will be more complicated. Therefore, the construction operation consumes more time.

In Figure 11(b), we vary the capacity of B++-tree from 10 to 100, while fixing the data size to 1,000,000. It is easy to find that CT is the shortest when the capacity . If the capacity is too small, the tree will be very high. If the capacity is too big, the node will store too many intervals. Neither of these conditions contributes to the construction of the B++-tree. Therefore, the capacity is the most suitable for the construction of B++-tree, while the data size is 1,000,000.

5.2. Performance of Operations

In this subsection, we test the performance of operations, which includes the query performance, the insertion performance, and the deletion performance. Then we analyze the reason of the performance and give the conclusion of experiments.

Query. Firstly we test the performance of query. Figure 12 gives the result of the experiment. We change and the data size separately to conduct comparative experiments. We denote the time of traversing the leaf nodes as TT, which means the traversal time.

In Figure 12(a), we vary the data size from 10,000 to 2,000,000 while fixing the capacity to 50. From the figure, we can see that the greater the data size is, the bigger the TT is. Because the larger the data size is, the more leaf nodes the B++-tree has. Therefore, it takes more time to traverse the B++-tree.

In Figure 12(b), we vary the capacity from 10 to 100 while fixing the data size to 1,000,000. The trend of TT is decreasing first but increasing again. Because when the capacity is small, there will be too many leaf nodes in B++-tree, which cost much more time to traverse the B++-tree. When the capacity is too big, the B++-tree will has too many leaf nodes. So when , the query performance is the best, while the data size is 1,000,000.

But the most important is that TT is very small all the time, which means query speed is very fast. Even the data size is 2 million; the query time is less than a second. This shows that the B++-tree we proposed is very suitable for the query operation.

Insertion. Secondly we investigate the insertion performance of B++-tree. Data insertion is the most common operation in constructing a B++-tree. We still test the insertion performance by changing the data size and capacity. We compare the time of inserting a bunch of data and the time of inserting a piece of data. The time of inserting data is called IT, which means the insertion time.

In Figure 13, we compare the time of inserting a bunch of data. In Figure 13(a), we vary the data size from 10,000 to 2,000,000 while fixing the capacity to 50 and the inserting data size to 5000. From the figure, we can see that with the data size increasing, the IT increases as well. Because with the data size increasing, the B++-tree becomes more complicated. We need traverse more nodes to insert a record.

In Figure 13(b), we vary the capacity from 10 to 100 while fixing the data size to 1,000,000 and the inserting data size to 5000. Same as the previous experiment of query, IT is the shortest when , because the structure of the B++-tree is the best at this capacity. When the capacity , B++-tree will not have too many nodes or too many intervals in a leaf node.

In Figure 14, we compare the time of inserting a piece of data. In Figure 14(a), we vary the data size from 10,000 to 2,000,000 while fixing the capacity to 50. We can see that the trend of Figure 14(a) is similar to Figure 13(a). It only takes 2 ms to insert a piece of data when the data size is 2,000,000.

In Figure 14(b), we vary the capacity from 10 to 100 while fixing the data size to 1,000,000. The time of inserting a piece of data is only about 1 ms. It is obvious that B++-tree is very efficient in data insertion.

Deletion. Thirdly we investigate the deletion performance of B++-tree. Actually the principle of deletion is the same as the principle of insertion. Like the data insertion, we also test the deletion performance by changing the data size and capacity. We compare the time of deleting a bunch of data and the time of deleting a piece of data. The time of deleting data is called DT, which means the deletion time.

In Figure 15, we compare the time of deleting a bunch of data. In Figure 15(a), we vary the data size from 10,000 to 2,000,000 while fixing the capacity to 50 and the deleting data size to 5000. The result of Figure 15 is similar to Figure 13. With the increment of data size, the time of deletion increases as well, because of traversing more nodes.

In Figure 15(b), we vary the capacity from 10 to 100 while fixing the data size to 1,000,000 and the deleting data size to 5000. Same as Figure 13(b), DT is the shortest when . And the reason is the same as in Figure 13(b).

In Figure 16, we compare the time of deleting a piece of data. Figure 16 shows the same result as Figure 14. In Figure 16(a), we vary the data size from 10,000 to 2,000,000 while fixing the capacity to 50. The time of deleting a piece of data is very similar to the time of inserting a piece of data.

In Figure 16(b), we vary the capacity from 10 to 100 while fixing the data size to 1,000,000. The time of deleting a piece of data is only about 1 ms. The result shows that B++-tree is suitable for data deletion.

Finally we give the conclusion of experiment. We combine the results of the previous experiments and put them into Figure 17.

For ease of viewing, we set the ordinate of Figure 17 to a logarithmic scale of 10. From the figure we can see IT is almost the same as DT, because those two operations are the same in principle. With the increment of data size, TT, CT, IT, and DT increase at the same time. But the growth rate of the TT is not very big. Because according to the description, the query operation only needs to traverse leaf nodes, which is very fast and efficient. Besides, we can see from Figure 17 that the time of query is very short and less than a second.

As we can see from our experiments, the B++-tree we proposed in this paper is well suited for calculating the maximal concurrency for our pricing model.

6. Conclusion

In this paper, we propose a dynamic pricing model, which takes into account using time, resource consumption, and maximum concurrency to make the price of cloud resources more reasonable for both users and providers. In order to calculate the maximal concurrency of all the users, we propose a new data structure, named B++-tree, which extends from B+tree and has additional information in leaf nodes. Besides, we introduce the insertion, deletion, split, and query operation of B++-tree, which can calculate the maximal concurrency.

Finally, we performed extensive experiments to study the performance of the construction, query, insertion, and deletion operations with different data sizes and capacities of B++-tree. The result of the experiments shows that the B++-tree we proposed in this paper is well suited for calculating the maximal concurrency for our pricing model. We can complete the query operation on 10 million data in only 0.2 seconds. For the future work, we plan to find a much more reasonable pricing model which can take more factors into account.

Data Availability

The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This research was partially supported by the National Natural Science Foundation of China (nos. 61602411 and 61572437) and Key Research and Development Project of Zhejiang Province (no. 2015C01034).