Proteomics is the comprehensive study of expressed proteins from one organism for a certain time point; in contrast metaproteomics is the investigation of samples containing proteins from di erent organisms [ 1, 2, 3 ]. Proteomics and metaproteomics use mass spectrometry (MS) as an analytical technique to characterize proteins and detect their accurate masses, which relies upon a protein identi cation algorithm for cataloging of proteins present in a sample [ 4 ]. The protein identi cation process is based on the study of peptides generated by proteolytic digestion [ 5, 6 ]. Algorithms such as X! Tandem [ 7 ], MASCOT [ 8 ], SEQUEST [ 9 ], OMSSA [ 10 ] identi es peptides from MS spectra by searching them against a database of known peptides [ 11, 12, 13 ]. Balgley et al. [ 14 ] found OMSSA and X! Tandem to perform better than SEQUEST and MASCOT with respect to the number of peptide identi cations per protein and Quandt et al. [ 15 ] in their analysis declared X! Tandem to be more robust than OMSSA and MASCOT when there were changes in the precursor mass error and fragment mass error. Also being an open source software with periodical updates, X! Tandem appears to be a popular choice among biologists.

X! Tandem reads the input data (MS spectra and a protein sequence database) as les and writes the output into a le as well, so any analytical study would require parsing them. The algorithm deals with huge protein libraries (containing over million peptide sequences) and spectra data, which makes it laborious to manipulate and visualize the data as well as the results [ 16 ]. Moreover, redundant data tracking and version control is di cult with les. These issues have already been resolved by DBMS. Therefore our project aims to replace the conventional le-based approach with a DBMS. We have implemented a general adapter inside X! Tandem, which can be connected to any DBMS, by keeping its business logic intact and only changing the I/O logic. In this paper we have realized an RDBMS (MySQL) adapter. An RDBMS facilitated us to well represent the underlying relation of input and output data [ 17, 18 ].

This paper compares X! Tandem successfully integrated with an RDBMS, the core X! Tandem algorithm and MetaProteomeAnalyzer [ 19 ].

Further we discuss basic concepts in the section Fundamentals, proposed solution in the section Our Approach, followed by Implementation, Evaluation, and Conclusion.

Zeeberg et al. in their work on GoMiner [ 20 ] and Ahmad et al. in their work on nucleolar proteome database [ 21 ] have used RDBMS as an e cient storage engine. Yu et al. have realized an RDBMS as a tool for safe warehousing and analysis of quantitative proteomic data [ 22 ]. Bjornson et al. have worked towards parallelization of X! Tandem [ 23 ] whereas He et al. implemented a parallel X! Tandem with Many Integrated Core (MIC) [ 24 ]. Field et al. [ 25 ] while working on proteome mass spectral analysis have used RDBMS for storing processed data and customized reporting. MetaProteomeAnalyzer developed by Muth et al. [ 19 ], comes closest to our work as they perform protein search using X! Tandem and use RDBMS for storing search results. 3.

In this section, we explain the basics of a protein search engine with the focus on X! Tandem and brie y about the MPA tool. 3.1

A protein identi cation algorithm attempts to assign mass spectra to proteins/peptides. Inputs to the algorithm are: Protein sequence database (usually found by genetics) Experimental spectra (tandem mass spectrometry data usually in MGF1)

Con guration parameters

In Figure 1, we show how the experimental spectra relate to the protein sequences in the database. 3.2

Experimental spectra are the result of tandem MS/MS (multiple steps of mass spectrometry, with some form of molecular fragmentation occurring between the stages). These spectra are commonly stored in a MASCOT Generic Format (MGF) le [ 26 ] that encodes a collection of spectra. X! Tandem is built to use DTA, PKL or MGF les. We use MGF for our evaluation. 3.3

Protein sequence database (stored in a le) is a library of known protein sequences that are represented in a standard format [ 27 ]. In our work, we used protein sequences stored 1MASCOT Generic Format in a FASTA format le. For every protein sequence in the FASTA le, the rst line is the de nition line containing an access identi er along with some optional description. The lines following the de nition line represent sequence data. The protein search algorithm uses these peptide sequences to create theoretical spectra and matches them with the experimental spectra. 3.4

The output le is in the BIOML (Biopolymer Markup Language) [ 28 ] format, which features complex annotations of proteins in a hierarchical manner and can be processed using standard XML parsers. 3.5

The MetaProteomeAnalyzer (MPA) tool [ 19 ] employs X! Tandem internally with an advanced user interface view. It extracts the MGF and FASTA information from a MySQL DB and converts them into .mgf and .fasta les. Once the protein search is initiated, using these les X! Tandem identi es the proteins and generates the output. The MPA tool then parses the output le and stores it in DB. Hence, it uses both le and DB information for completing the process. 4.

With growing size of data it is di cult for biologists to manage hundreds of thousands of les where each le is in gigabytes. Furthermore DBMS have been considered an appropriate and bene cial data storage strategy as they form a classic framework for representing and analyzing huge metaproteomics data [ 3 ]. We have seen in subsection 3.5 that the MPA tool stores data in DB but does not read from it directly, during protein identi cation. Their process of converting data between DB and le representation is ine cient as it introduces an overhead of parsing. Rather than using les if we manage to directly read input from and write output to a DB, it would remove the parsing step, thus reducing load on the entire process of protein identi cation. Our goal was to design and develop a new architecture for X! Tandem connecting it to a DBMS without altering the protein identi cation algorithm inside. To store the MGF, FASTA and output les we designed a database schema preserving their hierarchical structure (see Figure 2, 3 and 4). We developed a special adapter interface which could communicate with any database without in uencing the functionality of X! Tandem. We used the con guration le input.xml to dene the database credentials, MGF and FASTA data source identi er, and parameters.xml to de ne the calculation criteria to match the protein sequences. Other con guration information was kept as a le.

Our work is implemented in C++ as we have modi ed X! Tandem classes to read and write data, from and to, MySQL instead of les. We have developed a MySQL adapter interface, which can be modi ed to connect X! Tandem to any other DB without changing its business logic. Further we study the database design for MGF, FASTA and output les.

In this section, we discuss the structure of tables for spectra, FASTA and output data in detail. 6.1

MS spectra information is stored into tables: ms dataset and fragment ion list. While ms dataset stores peptide mass, charge, precursor intensity, retention time (RT) and spectrum title, the peak-list of mass and intensity pairs for each spectrum is stored in fragment ion list table. Records in fragment ion list table are mapped to a speci c spectrum in ms dataset using a foreign key constraint `Map ID' (see Figure 2). Although a join operation on these two tables for reading spectra information would introduce a performance penalty, we do get the exibility of studying selective spectra as and when required instead of reading the entire le.

Understanding its structure (see subsection 3.3), we split each protein sequence into access identi er, description and sequence data and store them in protein reference data(see Figure 3). The protein reference data info table stores the information about the FASTA library loaded into DB.

The X! Tandem output data objects are stored in the tables out group (original mass spectrum), out protein (protein containing matching peptides), out domain (peptide sequences that match to a spectrum), out gaml trace histograms (histograms about statistics of an identi cation), out gaml attributes (histogram attributes), out gaml xy data (histogram values) and out parameters info (input parameters and performance statistics). The output tables conform to the output standards2 of core X! Tandem. The complete structure of output tables can be observed in Figure 4.

Factory adapter interface is developed to establish a database connection with X! Tandem. Its implementation only modi es the I/O logic of X! Tandem. The database entities are not coupled with C++ objects of X! Tandem, which means X! Tandem functions without any knowledge of the DB schema. This provides a generic interface where any database can be connected to X! Tandem with changes in input and output schema (pertaining to the DB used) without even worrying about the access and manipulation of data. In our case, we developed a factory adapter interface for MySQL. 8.

We evaluated our work to study the feasibility of integrating X! Tandem with a DBMS with an aim to perform as good as the core X! Tandem. The evaluation was performed on the following hardware:

RAM : 8GB Processor : i5 6th Generation Intel core 2.3 GHz Operating System : Windows 10

We conducted experiments with varying sizes of spectra and FASTA data. FASTA datasets used for evaluation100K FASTA.fasta and 552K FASTA.fasta, which contained 100,000 and 552,884 protein sequences respectively were 2http://www.thegpm.org/docs/X series output form.pdf taken from `UniProt Knowledgebase'. Spectra datasets used were 100 le.mgf, 2k le.mgf and 20K le.mgf which were 100, 2000 and 20000 in spectra counts respectively.

The evaluation was done by assessing the outcomes of all experiments on three performance measures namely computation time, CPU usage, and RAM usage for original lebased X! Tandem, the MPA Tool and our approach- X! Tandem using DBMS (MySQL).

For each performance measure, comparing the aforementioned systems, the results were presented in two graphs, one for 100K FASTA and another for 552K FASTA against all the three datasets of spectra. Consequently we veri ed them and concluded that there was no information loss from our approach. 8.1

For small-sized input data (100 spectra with 100K, 552K FASTA and 2000 spectra with 552K FASTA) our work (8.48, 24.67 and 32.34 seconds) outperforms the core X! Tandem (9.06, 46.56 and 73.25 seconds). For 2000 spectra with 100K FASTA our approach (32.34 seconds) was slightly slower than the core X! Tandem (23.67 seconds). However instead for input spectra of size 20K with 100K and 552K FASTA, our approach (606.06 and 1168.33 seconds) was considerably slower than core X! Tandem (185.34 and 449.94) as it takes almost 3 times more time to execute. To deal with this issue, batch processing of data should be included in our approach. In comparison to the MPA tool, our approach performs signi cantly better in all cases (see Figure 5 and 6.

We studied CPU usage of the three systems when no other process was running on the machine. We noticed that CPU usage is remarkably less for our approach (varying from 8.88 to 17.95%) irrespective of the size of data whereas in case of core X! Tandem and the MPA tool, CPU usage varies from 71.69% to 100% and 85-100% respectively (see Figure 7 and 8). Higher CPU usages could lead to performance issues in the system. 8.3

We can observe from Figure 9 and 10 that RAM usage is comparatively same in all the systems for small-sized input data (100 spectra with 100K & 552K FASTA) with core X! Tandem, MPA and our work having 66.69 & 190.61, 56.96 & 177.54, 54.48 & 248.04 bytes consumption respectively. However, our approach consumes signi cantly more amount of RAM (2429.94 & 2974.06 bytes) for large input data (20K spectra with 100K/552K FASTA) against that of core X! Tandem (237.94 & 392.83 bytes) and the MPA tool (47.93 & 177.34 bytes). RAM consumption increases linearly with data size, in our case. The MPA tool recorded lowest RAM consumption in all the cases.

The evaluation results show that core X! Tandem is the fastest as it is highly optimized. Our approach was noted to be faster than core X! Tandem while dealing with small-sized data whereas for larger data it was almost 3 times slower, further drawing our attention to a necessary implementation of batch processing. Our approach was quicker than the MPA tool in all the cases. However our approach exhibited e cient CPU usages across all the experiments, outshining the other two systems by a wide margin. In terms of RAM usage, our approach needs improvement as it consumed a lot more memory than the other two systems when data size increased.

We have not only engineered a connector interface between X! Tandem and a DBMS but also systematically investigated the feasibility of moving from le-based protein search algorithm to DBMS based algorithm without any information loss. We observed that DBMS o ers accessibility to data in a structured manner that was much needed for biologists. A biologist may create SQL queries on results to create customized reports without going through the hassle of parsing the les. Also in le-based approach, FASTA data was separated with respect to taxon, in di erent les. However with a connection to DBMS, all the FASTA data could be stored in one database and could be selectively used for experiments.

During evaluation we observed core X! Tandem to be the fastest of the three systems as it is highly optimized. Our work was faster than core X! Tandem for small datasets but needed batch processing for handling large datasets e ciently. We were signi cantly faster than MPA in all the cases. There was no overhead noticed on database access in our approach for small-sized input spectra, but a drastic overhead was noticed for large input spectra. This implies our approach needs multi-threading for cost-e ective RAM usage. Our approach exhibited e cient CPU usages across all the experiments, outshining the other two systems by a wide margin.

We have successfully developed an adapter to connect X! Tandem to any database (Section 7), opening up many possibilities for future improvements. For instance, an implementation of NoSQL database using our approach would provide an easy scale-out architecture with e cient performance whereas le-based X! Tandem could not scale. Also our work provides a basis for realizing protein identi cation algorithms in cloud environments while utilizing features of BigData. 10.

Our connector interface for MySQL could be exchanged (Section 7) for cloud-based endpoints such as Cassandra. Such cloud-based endpoints provide elastic scalability, high availability and fault tolerance with high performance. That way protein identi cation could be developed as a service, which would bring an e ective way of collaboration amongst biologists because of its central storage. Multi-threading approach should be adopted to tackle high RAM usage in our work. 11.

The authors sincerely thank Xiao Chen, Sebastian Krieter, Andreas Meister and Marcus Pinnecke for their support and advice. This work is partly funded by the de.NBI Network (031L0103), the DFG (grant no.: SA 465/50-1), the European Regional Development Fund (grant no. 11.000sz00.00.0 17 114347 0, the German Federal Ministry of Food and Agriculture (grants nos. 22404015) and dedicated to the memory of Mikhail Zoun. 12.