Weekend Triple Billionaire
Maintaining a Large RDF Data Set in the Life Sciences
Jerven Bolleman, Thomas Kappler, and the UniProt Consortium
Swiss Institute of Bioinformatics
jerven.bolleman@isb-sib.ch, thomas.kappler@isb-sib.ch

Abstract. The UniProt Knowledgebase offers both manually curated
and automatically generated information on proteins, and is one of theleading biological databases. While it is one of the largest free data setsthat is available in RDF, our infrastructure and website are not basedon RDF. We present numbers about the volume and growth of UniProt
and show why this volume of data prevents using RDF triple stores andSPARQL with currently available tools.

1UniProt Data: Nature and VolumeThe UniProt Knowledgebase (UniProtKB) [1] consists of two parts: UniProtKB/Swiss-Prot, containing manually annotated records describing proteins with information from literature and curator-evaluated computational analysis, andUniProtKB/TrEMBL, with automatically annotated records. The UniProt consortium provides several additional data sets: UniRef [2] with clustered sets ofsequences from UniProt, the amino acid sequence archive UniParc [3], and supporting data sets such as taxonomy and keywords.
UniProt consists of almost three billion triples (see Table 1), making it oneof the largest freely available RDF data sets. The data is maintained at three
consortium member sites, and must be kept in sync and integrated into one
combined public release1 .
This number of triples consumes considerable harddisk space. We show estimates comparing different RDF stores, based on published LUBM 80002 results,
with our solution, in Table 2.

2

Performance

UniProt is released every three weeks. In each such period, there is a time windowof only six days to prepare all source data for publication. When the curators
freeze their work, we need to retrieve all related data from our global partners. We then convert all source data (42 GB as of release 15.8) to RDF/XML1
2

Available for download at http://www.uniprot.org/downloads.
LUBM benchmark, http://swat.cse.lehigh.edu/projects/lubm/.

Table 1. Number of triples in UniProt, releases 15.8 and 15.9
Data set

Triples in 15.8

Triples in 15.9

Difference

Citations
EnzymeGOKeywords
Mapped citationsa
Locations
PathwaysTaxonomy
Tissues
UniParc
UniProtKB
UniRefTotal

8,612,297
36,461
195,249
7,641
84,308,128
4,537
8,661
3,493,485
6551
640,191,073
1,572,097,256
487,209,989
2,796,164,777

8,616,640
36,461
195,249
7,649
82,605,680
4,532
8,673
3,520,871
6551
691,432,967
1,610,723,778
499,947,698
2,897,100,198

0.05%
0%
0%
+0.10%−2.02%−0.11%+0.14%+0.78%
0%+8.00%+2.46%+2.61%+3.61%

aProjection for
September 2010

2,560,000,000
2,433,000,000
775,000,000
5,768,000,000

Automatically generated, not public.

(180 GB, 18 GB compressed), while validating it. This conversion took around16 hours for release 15.8 of September 2009.
The UniProt.org [4] website and its query engine run on an internally developed solution using BDB/je3 and Lucene4 . On a release, data is loaded into
its store in RDF form; the store and query engine themselves, however, are not
RDF-based. Loading and full text indexing all UniProt data sets took 29 hoursfor release 15.8, with 2 GB of memory on a dual core 2.8 GHz XeonTM and asingle hard disk. More than 20,000 unique users visit UniProt.org each workday,
averaging 130,000 queries and 1,710,000 direct lookups, while consuming justunder a terabyte of bandwidth a month. On average, 99.9% of queries finish inless than 0.8 seconds, including the transfer over the internet.
UniProt.org runs on three mirrors, each of which needs to be provisioned withall data in time for a release. Data size is a major factor in our deployment as weare limited by upload speed. UniProt 15.8 as needed for the website consumes
39 GB when gzip compressed, and takes four hours to upload. Larger data sizes
increase the risk of transfer failure.
We also have an internal website for our curators and internal softwaretools. Because it needs to reflect current work, we rebuild the manually curated UniProtKB/Swiss-Prot every night with a time window of 3.5 hours forconverting, loading and validating about 160 million triples.
UniProtKB/TrEMBL with supporting data is converted, loaded, and validated every Sunday. At this occasion we generate about 1.4 billion triples while
checking the data against our validation rules, making us indeed weekend triple
34

http://www.oracle.com/database/berkeley-db/je/index.html
http://lucene.apache.org/java/docs/index.html

billionaires. Current generic RDF stores are unable to handle this amount ofdata on the limited hardware budget available.
Table 2. Rough disk consumption estimates for UniProt release 15.8. The factor 1.4 isthe ratio between the larger number of long literals in UniProt compared to a LUBM
8000 data set.
RDF Store
Data provided
Estimate
Source155
Allegro Graph 155GB/1.1B LUBM 8000
552 GB
× 2.8 × 1.4 (a )1.192
× 2.8 × 1.4 (b )OWLIM
92GB/1.85B LUBM 8000
195 GB
1.85154
Oracle 11G
154GB/1.1B LUBM 8000
549 GB
× 2.8 × 1.4 (c )1.1120Virtuoso
120GB/1.1B various
305GB× 2.8d(e )1.1f
UniProt.org 36GB Store, 36GB Text index 72GB (real)Internal
awww.franz.com/agraph/allegrograph/www.ontotext.com/owlim/OWLIMPres.pdf
cwww.oracle.com/technology/tech/semantic technologies/htdocs/performance.html
dStorage cost of Virtuoso was not multiplied as they used a dataset with a higher
number of triples with large literals in comparison to LUBM8000.
evirtuoso.openlinksw.com/Whitepapers/html/Virt6FAQ.html#StorageCostPerTriplef
Our current custom solution, described in Section 2, not a SPARQL engine
b3

Data Growth

We have to deal with ever growing data volumes (Fig. 3). When evaluating tools,
we need to take into account not just performance on today’s data, but also on
the expected data in five years. The yearly growth rate of the core UniProtKB
data is currently 51%. This is a doubling time of 17 months, faster than Moore’s
Law5 that predicts a doubling time of 24 months.
Assuming that the current growth rate of UniParc does not accelerate fromthe current 270% a year (doubling every 7 months), we will see at least 10 billion
sequences in UniParc in five years. This estimate translates to 3 × 1011 triples,around 470 times the current size.

4Summary

We have met the requirements for data processing speed and query performancefor the near future, unfortunately on a non-RDF technology stack. Currently theavailable tools do not meet our performance needs for UniProt.org, especiallysince any RDF solution must preserve the current user interface and full text
search. We do however aim to deploy a public SPARQL endpoint once it becomesfeasible.
5

http://en.wikipedia.org/wiki/Moores law

Fig. 1. UniProtKB is growing faster over time. This graph does not show the growthof existing entries as more information becomes available.

.

5

Acknowledgments

UniProt is mainly supported by the National Institutes of Health (NIH) grant
2 U01 HG02712-04. Additional support for the EBI’s involvement in UniProt
comes from the European Commission (EC)’s FELICS grant (021902RII3) andfrom the NIH grant 1R01HGO2273-01. Swiss-Prot activities at the SIB are supported by the Swiss Federal Government through the Federal Office of Education and Science and the European Commission contracts FELICS (021902RII3)
and SLING (226073). PIR activities are also supported by the NIH grants andcontracts HHSN266200400061C, NCI-caBIG, and 5R01GM080646-04, and theDepartment of Defense grant W81XWH0720112. This work has benefited fromOracle funding support.

References
1. The UniProt Consortium. The Universal Protein Resource (UniProt). Nucl. Acids
Res. 37: D169-D174 (2009).
2. Suzek B.E., Huang H., McGarvey P., Mazumder R., and Wu C.H. UniRef: Comprehensive and Non-Redundant UniProt Reference Clusters. Bioinformatics 23:12821288 (2007).
3. Apweiler R., Bairoch A., and Wu C.H. Protein sequence databases. Curr. Opin.
Chem. Biol. 8:76-80 (2004).
4. Jain E., Bairoch A., Duvaud S., Phan I., Redaschi N., Suzek B.E., Martin M.J.,
McGarvey P., and Gasteiger E. Infrastructure for the life sciences: design and implementation of the UniProt website. BMC Bioinformatics 10:136 (2009).