The resultPool index maintains the information about the query results of the queries processed previously, whose function is to provide a physical cache for the results such that the queries selecting a subset of some previous query can be processed efficiently. Assuming that each query can be identified by an unique queryID, as shown in Figure 4, for each q _i , four parts of information are maintained in resultPool.

a) The query statement is the formal representation of the query q _i .

The queries stored in resultPool come from two parts. One part includes the queries processed before, and the other part includes some queries maintained in previous, which are represented by q _i s and q i ∗ s, respectively. Intuitively, since the queries appear in an ad-hoc way, if only q _i s are maintained, a totally new query will cause poor performance, therefore, some typical queries which can improve the performance of more general queries are also maintained. The details of how to choose the queries q i * s will be introduced in the following.

Example 3. Continue with Example 2, given the graph shown in Figure 2, as shown in Figure 4, the index structure related with a special query history {q ₁ , q ₂ , … } contains two parts, q _i s and q i * s. The query q ₁ is requested by the users before, according to resultPool , it can be known that 1) q ₁ is a 2-dimensional range query whose statement is (A ₂ = NY) ∧ (20 ≤ A ₃ ≤ 30), and 2) the result is q ₁ (V) = {a}. The query q 1 * do not need to be requested by the previous users, but the related information is still maintained. According to resultPool, it can be know that 1) q 1 * is a 1-dimensional range query with statement 0 ≤ A ₁ ≤ 20, and 2) the result set q 1 * ( V ) is of size 1 and only contains the node a.

Algorithm 2

IndexOperations.

The resultPool makes it possible to utilize previous query answers to accelerate the evaluation of current query. To make it work, given a special query q, it still needs to support efficient extraction of helpful queries of q from all queries maintained by resultPool. Before introducing the index structure queryPool with the above abilities, the concepts of query covering and redundant queries are explained first.

Given two range queries q ₁ and q ₂ , q ₁ is contained by q ₂ , denoted by q ₁ ⊆ q ₂ , if for every data instance D there is q ₁ (D) ⊆ q ₂ (D). Specially, if q ₁ ⊆ q ₂ and q ₂ is a 1-dimensional range query, a.k.a. a predicate, we say q ₂ covers q ₁ . For a set of queries {q ₁ , … , q _n }, if there is q _i ⊆ q _j (i ≠ j), q _j is called to be a redundant one in the following.

The queryPool index maintains the relations between keys and queries, where a key is some predicate utilized in the queries. For all queries q _i s previously processed, queryPool organizes those predicates into groups by the dimension size. Each key is assigned with an unique keyid. For each special key p, qlist maintains the queryIDs of the queries which contain p. Moreover, the queryIDs are sorted into the ascending order and stored, which will facilitate the process of searching queries. The following example will explain how to search the related queries utilizing queryPool.

Example 4. Continue with Example 3, the corresponding queryPool index is shown in Figure 5B. The rows with k = 2 maintains the information about the 2-dimensional queries previously used. For the predicate with statement A ₂ = NY, its keyid is k2 and the corresponding qlist contains two queries q ₁ and q ₃ , which are sorted in the ascending order. For the predicate A ₃ ∈ [20, 30], although it appears in both q ₁ and q ₅ , its corresponding qlist only contains q ₁ , because q ₁ is a 2-dimensional query but q ₅ is not. The related information for the queries q i * s are stored in the group with k = 0 of queryPool.

Next, the principles of using the two index structures to improve the performance of range query evaluation are introduced.

The SearchQueryPool function is shown in Algorithm 2, which will return a query Q′ for given a query Q such that the result Q(V) can be obtained efficiently based on Q′(V). First, a set candidate is initialized to be empty (line 2), which will be used to store the candidates of Q′. Then, an iteration from the group with k = |Q| to the one with k = 1 is done to generate the queries in candidate (line 3–21). For each fixed i ∈ [1, |Q|], a merge-style method is used to extract the queries containing Q efficiently by the following steps. (a) The keys covering some predicate of Q are collected, and a pointer is initialized at the front of the corresponding qlist for each key found (line 4–7). The details of obtaining keys covering some predicate will be introduced later. (b) Using the pointers initialized above, the merge-style method works by counting the appearing times of the current smallest queryID and inserting the query appearing no less than i times to the candidate set (line 8–19). At the end of each iteration, if the candidate is not empty, the iterations will stop. Finally, after the iterations, if the candidate set is not empty, an arbitrary non-redundant query in candidate is returned (line 22–24). Otherwise, null is returned (line 26).

As shown in Figure 5B, to efficiently search the keys covering some predicate, for the numerical attribute we can use a tree based search structure to achieve a O(log  n) time cost for search operation where n is the number of distinct values appearing in the query predicates, and for the category values a hash table can be utilized to achieve an expected O(1) time cost.

• For each numerical attribute A, a standard binary search tree is built. The search keys are chosen from the set of all distinct values appearing in the queries. In each leaf node with search key m, the keyID of each predicate q _A over A satisfying m ∈ q _A is stored. For example, as shown in Figure 5B, the leaf node with search key 25 includes K4 and K5 whose corresponding predicates in the queryPool are A ₃ ∈ [20, 30] and A ₃ ∈ [25, 50] respectively. Then, given a predicate with range [lbound, rbound], the leaf node lnode is obtained by finding the smallest search key no less than lbound, and the leaf node rnode is obtained by finding the largest search key no larger than rbound. Finally, the intersection of the two keyID sets associated with lnode and rnode is returned.

Example 5. Continue with Example 4, given a query Q: (A ₂ = NY) ∧ (25 ≤ A ₃ ≤ 40), the candidate queries which contain Q can be found as follows. First, Q can be divided into two predicates q ₁ : A ₃ ∈ [25, 40] and q ₂ : A ₂ = NY. Then, for the group of keys with k = 2 in the queryPool index, as shown in Figure 5B, q ₁ can be processed in the search tree structure with keys 25 and 40, and the query obtained is {K4,K5}∩{K5} = {K5}. Similarly, the queries obtained for q ₂ are {K2K3} using the hash map structure. After that, the corresponding qlists of {K2,K3,K5} in queryPool are extracted and merged as the following steps. q 1 ̲ q 3 q 2 ̲ q 3 ̲ q 4 ⇒ q 3 ̲ q 2 ̲ q 3 ̲ q 4 ⇒ q 3 ̲ q 3 ̲ q 4 ⇒ { } q 4 ̲ ⇒ { } { } { } (17) Here, the underline indicates the position of the related pointer for each list. During the merge procedure, the query q ₃ will be inserted into the candidate set, since in the third step q ₃ appears at the front of two lists. To verify the correctness, it can be found that the statement of q ₃ is (A ₃ ∈ [25, 50]) ∧ (A ₂ = NY) and obviously we have Q ⊆ q ₃ .

Algorithm 3

IndexRQE (Index Based Range Query Evaluation).

Now, we will show how to obtain the exact result of a given query based on the techniques shown above. As shown in Algorithm 3, given a k − dimensional query Q, the function SearchQueryPool is first invoked to search a candidate query set q whose item will contain the query Q (line 2). The structure qres is utilized to maintain a superset of Q(V) and initialized to be empty (line 3). If q is not null, the results of q will be collected into qres (line 5), otherwise, qres will be built based on the queries q i * s as follows (line 7–12). The selectivity δ _A of each attribute A involved in Q is calculated based on the assumption that all appearing values of A are chosen in an uniform random way. Here, δ _A is defined to be | r b o u n d − l b o u n d | | D o m A | , where lbound and rbound is the range of A in Q and Dom _A is the domain size of A. Intuitively, δ _A can tell us how many items can be filtered using the predicate of A in Q. The attribute X with the smallest δ _X will be chosen (line 8), since it is expected to filter the largest part of the data. Then, the predicates of X maintained in the group with k = 0 in queryPool will be scanned, and the results of the predicates having intersections with Q will be collected together into qres (line 9–12). Then, the items in qres will be checked one by one to obtain S = Q(V) (line 13–16). Finally, if | S | | q r e s | is smaller than a predefined threshold α, the query Q will be inserted into the index resultPool and queryPool (line 17–18), where the details are omitted here since it can be implemented trivially. Essentially, the value | S | | q r e s | can represent the ratio of truly useful items in the set pres, and a smaller value means that more useless items are collected in the previous step.

Example 6. Continue with Example 5, suppose the query Q′: A ₃ ∈ [10, 40] is given. Obviously, there are no predicates covering Q′, therefore, the function SearchQueryPool (Q′) will return null. Then, according to the function IndexRQE, the results of q 1 * and q 2 * maintained in resultPool will be collected into qres. Finally, only the nodes a, c, d, e and f will be checked, but not all nodes in V.

To maintain the related information of random RR sets, three index structures are utilized, NodeToRR , RRSet , and RRInvertedList .

In the RRSet, for each random RR set rr _i , there is an unique RRid, and all nodes contained in rr _i are stored as nodeList. Within RRSet, the items are maintained in the ascending order of RRid. In the NodeToRR, for each node v ∈ V, the nodeID of v is stored and the corresponding rrList includes the list of RRids of the random RR sets which are obtained by sampling from node v. In the RRInvertedList, for each node v ∈ V, the nodeID of v is stored and the corresponding rrCoverList maintains the list of RRids of the random RR sets which cover the node v .

Example 7. As shown in Figure 6B, a set of samples are listed in the RRSet, where there are 9 samples in total and the first random RR set is rr ₁ = {a, b}. According to the information in RRSet, as shown in Figure 6A, the NodeToRR structure maintains the list of samples beginning from some special node. There are totally two samples rr ₁ and rr ₂ in RRSet beginning from the node a, then, the corresponding rrList of nodeID a includes rr ₁ and rr ₂ . In the RRInvertedList structure, the rrCoverList of nodeID a includes 5 items rr ₁ , rr ₂ , rr ₄ , rr ₇ and rr ₉ , each of them contains the nodeID a in the corresponding nodeList.

Algorithm 4

AdaptiveSampling.

In this part, we will explain how to sample the random RR sets adaptively under the help of indexes introduced above. As shown in Algorithm 4, the inputs of AdaptiveSampling include the network graph G, a target node set T and a sampling size θ, and the output R is a sample set of random RR sets. For each node v ∈ T, a variable cnt _v will be used to record the number of samples needed starting from v and initialized to be 0 (line 3–4). Then, θ nodes are randomly selected from T with replacement, different from the commonly used sampling methods this step does not start the random walking but just increases the counter variable cnt _v to remember that one sample is needed (line 5–7). After that, we will know the number of samples needed for each node, all left we need to do is to reuse the samples maintained in RRSet to build R and collect more samples adaptively by random walking when there are no enough samples in RRSet. The details can be explained as follows. For each node v ∈ T, if NodeToRR [v].rrList.size() is as large as cnt _v , the samples maintained in RRSet is enough and no further real sampling operations are needed (line 9–10). Otherwise, we use Δ _v to represent the difference between NodeToRR [v].rrList.size() and cnt _v (line 12), and Δ _v times random walking will be executed to collect extra samples needed which will be inserted into NodeToRR at the same time (line 13). After updating the RRInvertedList (line 14), those new samples will be inserted into R (line 15). Since the RRInvertedList is a commonly used inverted list, the update can be implemented in a natural way whose details are omitted here.

Example 8. Let us consider the case that cnt _g and cnt _f are assigned to be 1 and 2, respectively, when running AdaptiveSampling. As shown in Figure 6, the information shown in black is the index structures before invoking AdaptiveSampling. Since cnt _g = 1 and there are no items with nodeID = g, one random walking will be made to obtain a new sample rr ₁ 0. Then, the parts in Figure 6 shown in red will be added. For the node f, since cnt _f = 2 and there are three RRids in the rrList of the item with nodeID = f in NodeToRR, no more random walking are needed, AdaptiveSampling will choose two samples from {rr ₇ , rr ₈ , rr ₉ }.

To study the efficiencies of the RIS-MSTIM algorithm proposed, for each real dataset, both the RIS-MSTIM algorithms with and without indexes are executed to solve the targeted influence maximization problem. To measure the performance of RIS-MSTIM fairly when considering different queries, 10 range query groups, each of which contain 50 queries, are generated randomly. For each group of queries, RIS-MSTIM algorithm is invoked to solve the corresponding targeted influence maximization problem. Within each group, the performance of RIS-MSTIM will become better as the increase of the number of queries processed, assuming that there are enough space costs to maintain the corresponding indexes. For each same setting, the algorithm is ran 5 times and the average time costs are recorded.

As shown in Figure 7, executing the RIS-MSTIM algorithms with and without indexes over the four datasets, when the seed size k is increased from 5 to 80, the average time costs for evaluating each group of queries generated are reported. Here, for the previous three datasets, the average time cost of 10 group of queries are reported, while for the youtube dataset the average time cost of 3 group of queries are reported since it will take much longer time than other datasets. Based on the above results, we have two observations. The first one is that as the seed size increases in an exponential speed both the index and no-index versions of RIS-MSTIM can scale well, where it should be noted that the seed size is enlarged twice each time. The second one is that using the indexes the RIS-MSTIM algorithm performances much better, where the indexes can help the reduce the time costs to about 50% for all datasets. It is verified that the index based idea of improving the performance of RIS-MSTIM is effective and can be utilized in rather diverse settings for which within the experiments there are about 500 queries and five different seed sizes. Moreover, since the datasets used here have different characteristics, it has been also verified that our index based method is proper for different types of data.

Also, it is verified that the index based solution can be applied to other sophisticated method within RIS framework also. As shown in Figure 8, using BCT method in [1] which is the state of the art and the same setting, for wiki-vote and google datasets, the average time costs of BCT methods with and without index are compared. It can be observed that the index solution proposed by this paper can improve the performance of BCT based method significantly also. The second key observation is that, although BCT is better than the standard RIS method, the total time costs caused by BCT and RIS methods are nearly same. The reason is that the cost of performing targeted influence maximization is highly dominated by the cost of evaluating multi-dimensional queries.

As shown in Figure 9, fixing the seed size to be 20, the time costs for evaluating each query group are reported. In Figure 9A, over the wiki-vote dataset, the results for 10 groups of queries are shown, where as discussed above each of the group contains 50 queries and the label n of x-axis means the group id. Similarly, the experimental results over google dataset is shown in Figure 9B. It can be observed that over those two datasets the performance of RIS-MSTIM method can be improved by using indexes for all the query group randomly generated.

To evaluate the effects of index sizes, the memory size used by the indexes are controlled by limiting the total number of queries and random RR sets cached by the indexes. The total size is changed between 1 and 1000 K, where each time it is increased by 10 times. For each dataset, the average time costs of evaluating the targeted influence maximization algorithm for the 10 groups of queries generated are recorded. As shown in Figure 10, when increasing the index size, the time costs over all four datasets are reduced. Since increasing the index size can enlarge the probability that a random chosen query share random RR sets with previous queries, such an observation is just what are expected. Therefore, it can be verified that the indexes using by the algorithm is the essential part for improving the performance of RIS-MSTIM, and when being allowed, the threshold for controlling index size should be assigned to a value as large as possible.

Intuitively, to let the index based method more general and usable, the space cost of the indexes used should be well controlled. Intuitively, when it is assumed that the memory is enough large to contain all possible index items, without considering the maintaining and searching costs of the indexes, the performance of the influence maximization algorithms can only become better when more items are indexed. Although, the maintaining and searching costs are relatively small comparing with the total time cost of RIS-MSTIM, it still needs huge space cost to store the sampled random RR sets temporally. If the indexes consume too many space costs, there may be only few space to store the new samples needed and the algorithm will perform very bad because of no enough memory space. In this part, fixing the index control size as 1000 K, for the four datasets, we run RIS-MSTIM algorithm over them for the parameter settings k ∈ {5, 10, 20, 40, 80}. Then, the sizes of indexes for query results and random RR sets are reported. As shown in Table 2, the space cost of RIS-MSTIM with index over the youtube dataset is the largest and the cost over the wiki-vote dataset is the smallest, which is expected based on the observation about the execution time costs. Generally speaking, when the seed size becomes larger, the space cost increases also. For the google and wiki-vote datasets, when the seed size is rather smaller, because that the space cost of all samples generated is still smaller than the threshold, the cost labelled by random-RR is significantly smaller than the case with larger k value. Moreover, it can be observed that the cost of query-result is much smaller than the cost of random-RR, which is as expected since each random RR set is essentially a node set.

Since the two versions of the RIS-MSTIM algorithm are the same one in principle, the effects of solving targeted influence maximization problem should be the same also. However, the key idea utilized in the index version is to reuse the samples obtained before, therefore, the detailed execution of the two RIS-MSTIM algorithms may be different. In this part, we should verify that the difference discussed above is very tiny such that we can ignore them when considering the qualities of the solutions obtained.

Since for each parameter setting, 50 queries in total are ran, we randomly select one query for each setting, record the seed node set, evaluate and compare their corresponding influence obtained. The results are shown in Table 3. It can be observed that there are tiny differences between the influence values obtained by RIS-MSTIM with and without indexes. This is as expected since the algorithm is a randomized one which only makes sure that a (1 − 1/e − ϵ) approximation solution is obtained with at least (1 − δ) probability. Also, it can be observed that the differences are acceptable for each dataset when considering the total dataset sizes.