Optimal neighborhood indexing for protein similarity search

Background Similarity inference, one of the main bioinformatics tasks, has to face an exponential growth of the biological data. A classical approach used to cope with this data flow involves heuristics with large seed indexes. In order to speed up this technique, the index can be enhanced by storing additional information to limit the number of random memory accesses. However, this improvement leads to a larger index that may become a bottleneck. In the case of protein similarity search, we propose to decrease the index size by reducing the amino acid alphabet. Results The paper presents two main contributions. First, we show that an optimal neighborhood indexing combining an alphabet reduction and a longer neighborhood leads to a reduction of 35% of memory involved into the process, without sacrificing the quality of results nor the computational time. Second, our approach led us to develop a new kind of substitution score matrices and their associated e-value parameters. In contrast to usual matrices, these matrices are rectangular since they compare amino acid groups from different alphabets. We describe the method used for computing those matrices and we provide some typical examples that can be used in such comparisons. Supplementary data can be found on the website . Conclusion We propose a practical index size reduction of the neighborhood data, that does not negatively affect the performance of large-scale search in protein sequences. Such an index can be used in any study involving large protein data. Moreover, rectangular substitution score matrices and their associated statistical parameters can have applications in any study involving an alphabet reduction.


Background
One fundamental task in bioinformatics concerns large scale comparisons between proteins or families of proteins. It often constitutes the first step before further investigations. A typical comparison, for example, is to query a database with a newly discovered sequence. Observed similarities witness a putative common biological function and direct further studies.
In this paper, we focus on massive protein sequence comparisons: a large database is iteratively compared with relatively short queries (such as newly sequenced data). A possible approach is to use the exact dynamic programming method [1]. For a given similarity model, this method provides optimal alignments within a quadratic computation time. Some optimizations achieve a subquadratic complexity [2], but the computation time remains prohibitive for large scale comparisons. Thus, in practice, the full dynamic programming approach is applied to comparison of short sequences.
A successful family of similarity search methods is provided by seed-based heuristics, starting with Fasta [3] and Blast [4] and including specific methods for protein similarities such as Blastp [5]. Seed-based heuristics were recently enhanced by advanced seeding tools like the spaced seeds used in PatternHunter [6] or Yass [7] (see [8] for a recent survey). Authors of this paper also worked on the alliance between advanced seeds techniques and reconfigurable architectures [9].
The main idea of seed-based heuristics is to anchor the detection of similarities using matching short words or short subsequences occurring in both compared sequences. The form of these words or subsequences is provided by a pattern called a seed. A word that respects the seed is called a key. For instance, MVK is one of 20 3 possible keys for the seed of three consecutive characters on the protein alphabet. Detection of similarities between two strings is done in three stages, as presented in Figure 1: • Stage 1: search for keys that occur in both strings, • Stage 2: extension of these matching keys with an ungapped alignment, keeping only the alignments with a score greater than a given threshold , • Stage 3: full dynamic programming algorithm, applied only to successfully extended matching keys.
In this work, we consider comparisons between a set of protein queries against a large protein database of N amino acids. A common usage of Blast is to index the queries, and then to scan the full database at the runtime. If the size of the query and the database allow it, a full indexation of both leads to advantageous results [10]. In our work, we applied approach used e.g. in Blat [11] where the database is indexed once and each query is successively processed.
To be efficient, the database positions are indexed by seed keys. The usual indexing scheme is shown Figure 2: for each key, a list of all its occurrences is stored. At Stage 1, each query position corresponds to a seed key (or, for the Blastp approach, a set of seed keys that are similar to the query seed key). An index access provides the list of key occurrences in the database, enabling Stage 2. We call such an approach the offset indexing approach. In this case, for each seed position, an offset of Llog 2 NO bits is stored. The index size is thus equal to S offset = N × Llog 2 NO bits.
For each query position, each execution of Stage 2 needs to access all the occurrences of the corresponding key. This leads to numerous random memory accesses that are time consuming: memory accesses at random positions are not efficiently cached and require high latencies [12]. A way to  Schematic view of a Blast-like 3-stage algorithm Figure 1 Schematic view of a Blast-like 3-stage algorithm. Representation of the three stages of comparison of a query (vertical) against a database (horizontal): Stage 1: identify seeds, i.e. small patterns occurring in both the query and the database (black diagonals). Stage 2: compute seed extensions and keep only those for which the score verifies at threshold (brown diagonals). On the Figure, seeds (a) and (b) are successfully extended. Stage 3: perform a full dynamic programming computation (white squares) on remaining seeds. In this example, only seed (b) leads to a significant alignment. reduce the computation time is thus to avoid as far as possible such random memory accesses. For that purpose, it is possible to additionally store, for each key occurrence, its left and right neighborhoods in the sequence, as illustrated in Figure 3. Thus, given a position in the query and its corresponding key, all neighborhoods of this key occurrences in the database are obtained through a single random memory access. For each database position, two neighborhoods are additionally stored. We call this indexing approach the neighborhood indexing approach. The overall index size is then equal to S neighborhood = N × (Llog 2 NO + 2 L) bits, where • is the number of bits for coding a character (amino acid), and • L is the length of each neighborhood.
As seen in Figure 4, the main advantage of the neighborhood indexing is that it speeds up the execution time by a factor ranging between 1.5 and 2 over the offset indexing.
The actual speed gain depends on the database length and on many implementation and architecture parameters (such as memory and cache sizes, cache strategies and access times) that will not be discussed here. An obvious drawback of the neighborhood indexing is the additional memory it requires to store neighborhoods. Comparing the two indexing schemes, the ratio r between the overall index sizes of the neighborhood indexing and the offset indexing is In common experiments, Llog 2 NO is between 20 and 40, L is between 20 and 200, hence r is between 2 and 21. It is worth mentioning that the Llog 2 NO value is often raised to a more practical 32 or 64 bits, reducing the ratio r even more. Storing neighborhoods becomes then relevant with the reduction of memory prices. For instance, the modern technology brings the possibility to get gigabytes of Flash memory in a personal computer for some hundred dollars. It is thus interesting to exploit this storage space as much as possible. It can be used for treating larger databases, but also, as in this work, for speeding up widely used applications.
However, the index size still remains the main limitation.
In this paper, we study how the size of a large neighborhood index can be reduced while preserving the result quality. For this purpose, we worked on reducing as much as possible the ratio r. A way for doing this is to reduce the factor L. We propose to simultaneously increase the neighborhood length (L) and reduce the alphabet size (2· ). We limit the alphabet size by partitioning amino acids into groups. This reduces a by encoding neighborhood characters in less than 5 bits required for coding 20 amino acids. Partitioning the amino acids into 16 groups enables to encode each group using 4 bits, and partitioning into 8, 4 or 2 groups enables to encode each group by 3, 2, and 1 bits respectively. All these reduced alphabets are tested in this paper.
Grouping amino acids was studied in several papers [13][14][15][16]. Groups can rely on amino acid physical-chemical properties or on a statistical analysis of alignments. For example, the authors of [13] computed correlation coefficients between pairs of amino acids based on the BLOSUM50 matrix and used a greedy algorithm to merge them. A branch-and-bound algorithm for partitioning the amino acids was proposed in [14]. Those papers mainly deal with the construction of reduced alphabets, but none  of them studies how the alphabet reduction affects the sensitivity of similarity search, or undertakes a quantitative analysis of the trade-off between search sensitivity and index size for those alphabets. This raises the following problem that is solved in this paper: Can reduced alphabets allow one to decrease the factor L while preserving the quality of similarity search results?

Results and discussion
The main result of our work is an effective reduction of the index size without deteriorating the quality of the results of similarity search. Moreover, we provide substitution score matrices and e-value parameters to be used with reduced alphabets. Our results are based on the alphabets defined by the amino acids groups proposed by Li and al.
( Table 2 of [15]). This choice was motivated by empirical tests showing their relevancy with seeds matching. However, our method can be applied to any other amino acids partitions. The website [17] provides data for all the alphabets reported in [16].
In the rest of the paper, the original alphabet of 20 amino acids is denoted by Σ 20 , where each character is encoded by 5 bits. Reduced alphabets Σ 16 , Σ 8 , Σ 4 and Σ 2 , respectively of size 16, 8, 4 and 2, have each character encoded by 4, 3, 2 and 1 bits respectively. Those alphabets, taken from Table 2 of [15], are defined by The main idea is to represent the neighborhoods of keys stored in the index (see Figure 3) over a reduced alphabet. Consequently, at Stage 2 of the similarity search, amino acid sequences are compared with sequences over the reduced alphabet. By an alignment over Σ × Σ', we understand an alignment between a sequence over Σ and a sequence over Σ'. Thus, in this paper we will consider alignments over In the next sections, we describe how to evaluate the quality of Stage 2 and how a substantial index size reduction can be obtained by using longer neighborhoods on reduced alphabets. As presented in Figure 5, using a reduced alphabet involves several parameters that we study in the following sections. In section Rectangular substitution score matrices, we present substitution score matrices used for alignments over Σ 20 × Σ 8 and Σ 20 × Σ 16 . We then present the computation of e-value to estimate the significance of alignments over reduced alphabets. The last section, Experimental validation, describes a practical application of reduced alphabets to real biological data.

Stage 2 algorithm and quality
A detailed description of Stage 2 is given in Algorithm 1 (Table 1). Query and database neighborhoods of a matching key (detected during Stage 1) are compared character by character over L positions. During this comparison that uses substitution score matrices (lines 1 and 1), the highest scores for the left and right neighborhoods are kept (lines 1 and 1). If the sum of the highest scores exceeds a threshold , the alignment is kept for Stage 3 (line 1), otherwise it is rejected (line 1). Note that in the offset indexing case, a random memory access is performed in order to retrieve neighborhoods left db and right db (line 1). This is not the case for the neighborhood indexing, as the neighborhoods are stored directly in the index.  The quality of Stage 2 is measured by a trade-off between its sensitivity (ability to extend true alignments) and selectivity (ability to filter out spurious seed hits). Computation of those values is described page 10.
Increasing the threshold or decreasing the neighborhood length L makes Stage 2 more selective but less sensitive (faster execution at the price of worse quality results) while decreasing or increasing L increases the sensitivity and decreases the selectivity (better quality results at the price of a slower execution).

Reducing the index size by 35% without loss of quality
As shown in Figure 6, the sensitivity/selectivity trade-off follows a convex curve. We propose here to achieve an equivalent trade-off with a reduction of the index size.
Clearly, for a fixed neighborhood length L (in Figure 6, 16 amino acids), the sensitivity/selectivity trade-off is always better when using the full amino acid alphabets than a reduced alphabet. This is easily explained by the fact that reducing the alphabet size decreases the alignment accuracy. In order to keep up with the sensitivity/selectivity ratio, the neighborhood length L should be increased. In Figure 7, all reduced alphabets, used with increased neighborhood lengths, now perform equivalently (or slightly better) than the full alphabet. Figure 8 shows the dependency, for different reduced alphabets, between the number of bits needed to store both neighborhoods (X axis) and the selectivity (Y axis), for an equivalent quality (fixed sensitivity). Those results are obtained with the use of special substitution score matrices, adapted to reduced alphabets, that are presented in the next section. Our main result is that for any given selectivity, using any of the reduced alphabets for storing neighborhoods leads to a smaller L factor than for the Σ 20 alphabet. Therefore, for a fixed memory usage, the sensitivity/selectivity trade-off is always better with a reduced alphabet than with the full Σ 20 alphabet.
In practice, this result enables a reduction of the index size without any sacrifice in running time or in result quality. Table 2 shows the memory requirements for different alphabets. We obtain a practical reduction of 42% of the factor L using the reduced alphabet Σ 2 instead of Σ 20 . The ratio r on the overall index size is then reduced by 35%. Parameters involved in alphabet reduction Figure 5 Parameters involved in alphabet reduction. Once an alphabet and a sensitivity/selectivity ratio are chosen, several parameters are computed. Substitution score matrix and evalue parameters depend only on the alphabet and the model probabilities, whereas the optimal neighborhood size and the threshold depends also on the sensitivity/selectivity level.

Rectangular substitution score matrices
We designed a method for computing substitution score matrices for any pair of possibly reduced amino acid alphabets. As this method is based on the original pro- Such matrices can be applied in any method reducing the amino acid alphabets by residue grouping. As one may be interested in using any other pair of alphabets, we additionally propose a web interface [17]. This web interface computes REBLOSUM matrices for other alphabets listed in [16] and for any custom alphabets provided by the user.

Parameters for e-value computation
The e-value, or expected value, provides the expected number of alignments with a given score, when comparing a text T and a query Q of length |T | and |Q| respectively. Local alignment methods like Blast sort results by increasing e-value, thus reflecting their decreasing significance. In the Blast algorithm, the e-value of an alignment is obtained by where s is the score of the alignment obtained with substitution matrices. Parameters and K are two constants that fit the Gumbel law, computed using methods described in [19]. Table 7 provides those parameters for several REBLO-SUM substitution matrices.

Experimental validation
In a model where the Stage 2 alignments are ungapped, using reduced alphabets and alignments on longer neighborhoods can however affect the result quality. Indeed, the longer the neighborhoods are, the bigger is the chance to meet a gap in the sequences. More generally, the probabilities distributions used in theoretical sensitivity and selectivity computations do not truly reflect the nature of the biological sequences.
We thus validated our approach with large-scale tests on biological sequences. We set a database to be the hardmasked human chromosome 21 (UCSC Release hg18) translated according to the six possible reading frames. The query set was a set of seven archea and bacteria proteomes derived from a study of mitochondrial diseases. This set was selected for is interest toward the detection of potential insertions of mitochondrial genes in the human genome. Moreover, testing out our approach comparing such distant species represents one of the hardest application case. Indeed more typical homology searches on closer sequences is easier. Tests on such homology Sensitivity/selectivity trade-off using different alphabets with adapted neighborhood lengths Figure 7 Sensitivity/selectivity trade-off using different alphabets with adapted neighborhood lengths. Sensitivity/ selectivity trade-off for two neighborhoods with the adapted lengths of Table 2. Now all reduced alphabets are equivalent (or slightly better, due to integer rounding of the neighborhood lengths) than the original alphabet Σ 20 × Σ 20 .  Alphabet size 20x20 16x20 8x20 4x20 2x20 searches could have hidden potential issue on our approach.
The database contained 12 700 507 amino acids whereas the query was composed by 5 321 439 amino acids. Using the ssearch method [20], 650 alignments were obtained between the database and the query (maximal e-value: 10 -3 ). This set of exhaustive optimum alignments was sufficient to validate our method in comparison with results obtained using different alphabets. The seed used in Stage 1 was a subset seed (see [21]), as in [9]. For the neighborhood indexing, we indexed the database using each of the alphabets Σ 20 , Σ 16 , Σ 8 , Σ 4 and Σ 2 . We selected the neighborhood length to have a theoretical sensitivity close to 0.95 and a theoretical selectivity close to 0.01. Theoretical sensitivity and selectivity are defined according distributions presented on page 10.
This leads to indexing 2 × 11 characters for Σ 20 , 2 × 12 characters for Σ 16 , 2 × 14 characters on Σ 8 , 2 × 19 characters for Σ 4 , and 2 × 32 characters for Σ 2 (Figure 7). The database index sizes are reported in Table 9. Using alpha-bet Σ 2 instead of Σ 20 reduces the overall index size: the ratio r goes from r 20 = 5.58 to only r 2 = 3.67, that is a 35% reduction. The initial assumption of ungapped alignments in the Stage 2 can be wrong with a neighborhood length of 2 × 32. Thus one could prefer to use the alphabet Σ 4 with 2 × 19 characters, giving a 25% reduction of the overall index size (r 4 = 4.17).
As shown in Table 8, each of the reduced alphabets yields a practical full sensitivity, as all the 650 alignments are found in each test. Moreover, the practical selectivity, close to 10 -3 , is here better than the theoretical one (0.01).

Conclusion
We proposed a method for reducing the index size when storing neighborhoods of seed keys in protein databases. This approach is based on reducing the alphabet of indexed data while using a longer neighborhood. We save 35% of the index size without any modification on the result quality assuming an ungapped alignment model. We provided optimal lengths for selected alphabets.
REBLOSUM62 matrix for alphabet Σ 20 × Σ 16 . Scores located on the "diagonal" are shown in bold.
REBLOSUM62 matrix for alphabet Σ 20 × Σ 8 . Scores located on the "diagonal" are shown in bold.
Furthermore, the proposed method requires unusual substitutions score matrices that are called REBLOSUM, for rectangular BLOSUM matrices. These matrices provide substitution scores between letters from different alphabets. We extended the computation of traditional BLOSUM matrices in order to compute REBLOSUM matrices, and adapted the computation of and K parameters for e-value estimation to reduced alphabets. We provided REBLOSUM matrices and their corresponding and K values for selected alphabets. Other matrices and parameters can be obtained from the website [17].

Methods
In this section, we describe the methods we used to compute the sensitivity and selectivity of similarity search on reduced alphabets as well as the neighborhood length. We further describe the computation of REBLOSUM substitution score matrices and of the e-value parameter. Moreover, we explain how the threshold is computed at Stage 2 depending on the e-value specified by the user. Finally, we describe how we estimated the time gain of the the neighborhood indexing over the offset indexing.

Selectivity and sensitivity computation
The sensitivity of Stage 2 is defined by the ratio of retained "true alignments" (a "true alignment" is an alignment known to be relevant, according to a model or to a reference set like the BLOCKS database): The selectivity is defined as the ratio of retained "random alignments" (a "random alignment" means an alignment of randomly chosen amino acid pairs drawn according to an appropriate probability distribution): Note that here we focus on the behavior of Stage 2 and do not take into consideration the sensitivity/selectivity of Stage 1. In particular, in the above fractions we consider only alignments that extend a hit presumably reported at Stage 1.
The sensitivity and the selectivity of Stage 2 rely on three parameters: the alphabet choice, the neighborhood length, and the score threshold . Given these three parameters, we applied a dynamic programming algorithm to compute the probability for the filter to retain an alignment drawn according to a given amino acid pair distribution. Applied to distributions of "true" and "random" alignments (foreground and background distributions, respectively), the algorithm gives a theoretical estimation of the sensitivity and the selectivity of the filter. The two distributions were the Bernoulli models (namely the expected and the observed probabilities, see below), obtained with the BLOSUM programs on the BLOCKS protein database when processing the BLOSUM-62 matrix.
In our Algorithm 1, two neighborhoods (left and right) are processed. We thus consider the sum of two maximal scores, reached in the left and right neighborhoods. The probability that this sum reaches a given threshold at least once is computed as follows. First, we compute the probability for each neighborhood independently to reach any given maximal score s (s ≥ 0) within the neighborhood length. Then, these two independent discrete distributions are combined to compute the threshold requirement.
 sensitivity # successfully extended true alignments # true = a alignments , selectivity # successfully extended random alignments # ran = d dom alignments .
   REBLOSUM62 matrix for alphabet Σ 20 × Σ 4 . Scores located on the "diagonal" are shown in bold. For our experiments, we calibrated the neighborhoods lengths to have a sensibility close to 0.95 and a selectivity close to 0.01, and computed related thresholds values (available of the REBLOSUM website).

Computing REBLOSUM matrices
There are several substitution score matrices for the regular Σ 20 × Σ 20 alphabet, and the most common of them are matrices from the BLOSUM family [22] (BLOcks SUbstitution Matrix). They are built from the BLOCKS database of ungapped multiple alignments [23]. For a given identity level X and two amino acids i and j, the BLOSUMX score B i, j are log-likelihoods of amino acid pair frequencies: where p i · p j is the expected probability of aligning i against j, and q i, j is the observed probability of the same event in a subset of alignments of the BLOCKS database that have at least × percent of identity. (Note that the computation of q i, j takes into account different contributions provided by alignments with different identity levels.) In our case, sequences over diferent alphabets are compared and we then have to adapt the matrix computation to compute appropriate rectangular matrices. For this purpose, the original data file (BLOCKS database version 5) was downloaded and the original programs of [18] (downloaded from [24]) were modified in order to take into account the reduced alphabet on "one side" of the matrix and compute new log-likelihood scores. Given two alphabets Σ and Σ', we compute such matrices for several identity levels X, using the log-likelihood of groups of amino acid pair frequencies: where p I ·p J is the expected frequency of aligning any amino acids from group I ⊆ Σ against any other amino acid from group J ⊆ Σ', and q I, J is the observed frequency of the same event in a subset of alignments of the BLOCKS database that have at least × percent of identity. The recent paper [25] discovered flaws in the original BLOSUM implementation, but shows that a corrected program does not improve (and even in some cases decreases) the results quality. Therefore, we did not take the proposed modifications into account.
The website [17] proposes a selection of REBLOSUM matrices for several alphabets, as well as an interface to compute REBLOSUM matrices for any alphabet and identity level specified by the user.

Prototype for estimating the time gain of offset indexing over neighborhood indexing
For comparing the execution time between offset indexing and neighborhood indexing, a prototype was created. In the case of the offset indexing, the index stores positions of all seeds in an unique integer array. For each seed key, a pointer provides the first occurrence in this array. In the case of the neighborhood indexing, the index uses a (unique) structure array instead of an integer array. For each key occurrence, the structure contains the key position together with two neighborhoods.
Tests reported in Figure 4 were run on a 2 GHz PC with an AMD Opteron processor. The database size was selected so that the index fits into the main memory (4 GB) but   Similarity search results obtained on reduced alphabets. The number of positions tested (validating Stage 1 only and independent from the chosen alphabet) is 1.59 * 10 9 . The practical selectivity is computed dividing the number of positions validating both Stage 1 and Stage 2 by the number of positions tested. Database index size for neighborhood indexing on different alphabets. The first three columns are the same as in Table 2, the other two columns refer to the experience described in section "Practical results". The index size is equal to N × (Llog 2 NO + 2 L), as explained in the beginning of the paper. Here N = 12 700 507 and Llog 2 NO = 24. The ratio r is against the size of the index for offset indexing, which is here S offset = N × Llog 2 NO = 0.30 * 10 9 bits = 38 MBytes.