The HSF Conditions Database Reference Implementation

TL;DR

The paper tackles the lack of shared standards for HEP conditions data, which exhibit heterogeneous structure and very high read rates. It introduces a reference implementation based on PostgreSQL and a Django REST API (NoPayloadDB), a C++ client (nopayloadclient), and a POSIX filesystem payload store, deployed via OKD with Helm and designed to separate metadata from payload retrieval. Key contributions include a NoPayloadDB schema with PayloadIOV, PayloadList, PayloadType, and GlobalTag, plus a high-performance REST endpoint using optimized SQL and a robust client-side workflow for payload management and synchronization. Performance testing demonstrates robust, scalable read throughput—well above 100 Hz in challenging scenarios and up to tens of millions of IoVs—validating the approach for large-scale experiments like sPHENIX with thousands of concurrent jobs. The work provides a practical, interoperable framework for conditions data across experiments, supporting scalable deployment and real-world usage.

Abstract

Conditions data is the subset of non-event data that is necessary to process event data. It poses a unique set of challenges, namely a heterogeneous structure and high access rates by distributed computing. The HSF Conditions Databases activity is a forum for cross-experiment discussions inviting as broad a participation as possible. It grew out of the HSF Community White Paper work to study conditions data access, where experts from ATLAS, Belle II, and CMS converged on a common language and proposed a schema that represents best practice. Following discussions with a broader community, including NP as well as HEP experiments, a core set of use cases, functionality and behaviour was defined with the aim to describe a core conditions database API. This paper will describe the reference implementation of both the conditions database service and the client which together encapsulate HSF best practice conditions data handling. Django was chosen for the service implementation, which uses an ORM instead of the direct use of SQL for all but one method. The simple relational database schema to organise conditions data is implemented in PostgreSQL. The task of storing conditions data payloads themselves is outsourced to any POSIX-compliant filesystem, allowing for transparent relocation and redundancy. Crucially this design provides a clear separation between retrieving the metadata describing which conditions data are needed for a data processing job, and retrieving the actual payloads from storage. The service deployment using Helm on OKD will be described together with scaling tests and operations experience from the sPHENIX experiment running more than 25k cores at BNL.

Figures (5)

• Figure 1: The relational database schema of NoPayloadDB. Every PayloadIOV references an external payload and stores its metadata including the IoV. A PayloadList contains a sequence of PayloadIOVs and has one associated PayloadType. Each GlobalTag has at most one PayloadList per PayloadType and a GlobalTagStatus.
• Figure 2: The NoPayloadDB deployment on OKD. The Django application together with the web server, the database pooler and a Kubernetes cron job for the period database backups are included in the Helm chart.
• Figure 3: Overall layout of the application. The client-side library nopayloadclient communicates with the server-side application, nopayloaddb, through a REST interface. The actual payloads reside in the remote payload storage (e.g. a /cvmfs/ Buncic:2010zz file system).
• Figure 4: Results of an example test campaign making 10.000 random requests from a single client using asynchronous multithreading. The left shows the distribution of the recorded response times, the right shows the mean response frequency for each second over the duration of the campaign.
• Figure 5: Mean response frequency for 10000 random requests as a function of the database occupancy scenario for three different implementations of the payloadiovs query.