   |  |
Computing Technical Design Report
| | |
Computing Technical Design Report
There are two broad categories of data storage in ATLAS: file-based data and database-resident data or, more specifically, relational-database-resident data. The two storage approaches are complementary and are used in appropriate contexts in ATLAS. File storage is used for bulky data such as event data and large volume conditions data; for contexts in which the remote connectivity (usually) implied by database storage is not reliably available; and generally for cases where simple, lightweight storage is adequate. Database storage is used where concurrent writes and transactional consistency are required; where data handling is inherently distributed, typically with centralized writers and distributed readers; where indexing and rapid querying across moderate data volumes is required; and where structured archival storage and query-based retrieval is required.
While these two storage categories cover ATLAS needs very well, their mapping to the software environments of ATLAS is not obvious or trivial, and achieving a low-impedance mapping of programmatic data access to data storage has engendered much work in recent years, with some success. ATLAS software environments both online and offline are primarily object-based, with C++ the most widely used language and the standard in offline (used for the offline Athena framework).
File-based storage of C++ objects is made possible through the use of ROOT I/O, which provides high-performance and highly-scalable object serialization to self-describing, schema-evolvable, random-access files. This capability relies on the foundation of a C++ object dictionary, providing the object introspection needed for automatic serialization. ATLAS employs ROOT I/O via the POOL persistency framework, which isolates applications from the storage technology used (a capability utilized in relational storage as discussed below), and provides the added value of data navigation at the object level with navigational support extending Grid-wide through an interface to file-catalogue services, which may be Grid-based. POOL supports persistent object references, which record not only in-file object location but file identity (via a unique identifier, the GUID) with support for automatic navigation to the required physical file through a catalogue lookup (GUID dereferenced to a physical file location). Thus ROOT provides the bridge from our transient objects to highly efficient file-based storage, and POOL provides the further bridge from these files to a catalogued, navigable, distributed file-management infrastructure.
For database storage, ATLAS and LHC experience over many years has narrowed the technologies of interest to SQL-based relational databases but has shown the value of flexibility in the choice of relational database engine (vendor). While Oracle is CERN IT's choice for their large-scale DB service, MySQL has emerged as the preferred engine for installations outside of institutional IT departments, and SQLite combines SQL relational DB with local file-based storage which is very attractive in some contexts. Oracle, and specifically CERN IT's Physics Database Service, will be the key central database service acting as archival repository for ATLAS DB-resident data and often the `write master' with replication from CERN Oracle to other technologies for distributed read-only use. Vendor neutrality in the DB interface (with implemented support for the three mentioned vendors) has been addressed through the development of the Relational Access Layer (RAL) within the POOL project to provide performance-optimized, vendor-neutral, C++-based DB access, with a transparent mapping to DB schema such that RAL-accessed DBs can also be accessed through conventional DB tools. ATLAS utilizes RAL both directly and through layered services for DB storage via C++ with either Oracle, MySQL or SQLite back-end engines.
The RAL layer is used both directly by simple applications and indirectly as the foundation of higher-level DB-based storage services provided by POOL and by the conditions database software COOL. POOL offers RAL-based relational DB storage via the same StorageManager interface as the complementary ROOT file storage. Object-relational POOL provides for the storage of C++ objects of moderate complexity in relational DBs through exactly the same interfaces as ROOT file-based storage. POOL (and ATLAS) uses this capability to support the storage of event collections (tag databases) as either ROOT files (TTree based, usable directly in the ROOT environment for TTree based analysis) or DB-based collections; both these storage modes are very useful in the context of event collections. Object-relational POOL is also being deployed to store conditions data in a relational DB, via an interface that allows easy switching between POOL file-based and DB-based conditions-data storage as conditions DB storage and access is optimized.
COOL (developed in a collaboration between LCG AA and ATLAS) is another DB-based storage service layered over RAL and is the basis for ATLAS conditions data storage. It provides for interval-of-validity (IOV) based storage and retrieval of conditions-data objects, which may be stored by a variety of means: `inline' with the IOV information for small simple data, in another user-defined DB table, in a POOL object stored via either object-relational POOL or POOL ROOT files, or in a file of arbitrary type (referenced and accessed via the services of the distributed data management system).
All storage systems used by ATLAS are interfaced to offline software via the Athena service and persistency conversion infrastructure. Developments are under way to make ATLAS data stores accessible also from a native ROOT environment, anticipating its use for analysis. Storage systems important to online, in particular COOL, are supported for online via dedicated interfaces to online data and information systems.
The bridge from ATLAS file and database-storage systems to their full availability at scale in the distributed ATLAS computing environment is the least developed area at the time of writing, and is under intensive development following strategic and architectural paths that are for the most part clearly established. The key here is, on the one hand, to extend the foundational tools of ATLAS data storage, POOL, RAL, COOL and ROOT, outwards over the Grid through their integration with distributed computing tools and services, and, on the other hand, to build an ATLAS distributed-data management system proper, to support distribution and discovery of ATLAS data across the collaboration. The end objective is to ensure that all ATLAS physicists wherever they are located have equal access to all ATLAS data (extending to support for small institutes and personal computers), within the constraints of available resources. A vital element is close collaboration between ATLAS and a strong LCG Distributed Deployment of Databases (3D) project. In the context of the 3D project the infrastructure and service relationships to support databases needed throughout the computing tiers and data replication between them are being developed. 3D is also developing the software systems to support authentication, monitoring at both server and client sides, server selection supporting load balancing and failover, and multi-tiered data-access systems to provide scalable retrieval of DB-resident data. These software systems are being integrated with or interfaced to RAL, COOL and POOL. Another vital element is the work under way to expand ROOT's support for the distributed grid environment. As the foundation for file-based data storage by POOL, COOL, etc., ROOT's interfaces to distributed storage services can be leveraged directly. ROOT provides interfaces to distributed storage tools such as dCache, xrootd, GFAL, and soon SRM. Grid authentication tools developed by ROOT are being integrated at higher levels by POOL and 3D.
The distributed data-management system, which is heavily based on relational databases, is being developed to leverage much of the same work: POOL file catalogue interfaces and implementations, RAL, the 3D distribution/replication infrastructure. It also will leverage mature components of Grid middleware infrastructure, such as authentication services and file-transport tools.
The following sections address the specifics of database and data management work in the various domains, and they describe how the architectural approaches just outlined are developed and applied in those domains.
| | |
Copyright © CERN 2005