Database Futures Workshop

Database Futures WorkshopCERN 6.+7.6.2011

Michael Dahlinger, GSI

m.dahlinger@gsi.de

Database Futures Workshop - 2

Anwendungs-Bereiche

•Beschleuniger: 2x•Administration + Engeneering: 1x•CERN Drupal: 1x

•noSQL : 5x•CORAL, COOL, Frontier, HTTP caching: 2x

•Alice: 2x (DCS, DAQ)•CMS: 3x•LHCb: 1x•ATLAS: 3x

Ca. 80 Teilnehmer, meist aus CERN und CERN-Experimenten

Talks aus folgenden Bereichen:

Beschleuniger

Beschleuniger

Controls: Relational, a lot of Oracle databases + featuresMission critical services: Controls Configuration Service (Oracle based) Based on Oracle ADF, 200

users, 12 editing applications. Reports (based on Oracle APEX), History Log Browser. APIs (Java, PL/SQL, C)

Accelerator Alarms (alarms DB). Short + long term storage. PL/SQL jobs. Pack long-long term (4-10 GB/a)

Settings:Mission critical, based on relational model , Oracle DBMSLogging:Oracle, filled by SCADA systems. 20 years of filtered data! 250000 signals, 250

GB/daySimple schema, many Oracle features, e.g. Oracle timestamp (nanosecond)Access only via APIs.

Administration + Engineering

GS: General services

AIS: Administrative Information Services

ASE: Access, Safety and Engineering tools

Drupal

• Ausgewähltes Web CMS, Drupal 6

Drupal

• Ausgewähltes Web CMS

• Database Abstraction Layer benutzen (trotz Möglichkeit direkten Datenbank Zugriffs auf MySQL)

• Nur 12 von 350000 sites benutzen Oracle

• -> MySQL ausgewählt

• MySQL database run by IT/DB ! Spezialfall

Experimente

• CMS– Online Conditions Database (Oracle)– Offline Conditions Database (Oracle)

• ATLAS– All Oracle databases + COOL for many Online/offline databases– Remove hybrid database technologies (SQLite), all now in Oracle for

production dbs– Extensive Verwendung fortgeschrittener Oracle 11g features in

Entwicklung

• LHCb– Use of SQLite (1) and Oracle (many) and MySQL (Drupal, LFC)

• Alice– DCS (Detector Control System), Oracle– DAQ (Data acquisition) mySQL

CMS Offline Summary

• The CMS Offline Condition DB plays a key role in the CMS database infrastructure.

• Focus of its design is the control of a potentially large set of access patterns into a single software supporting predefined use‐cases.

• The successful operation of the system relies on a set of key features that are provided by the IT DB service within the Oracle technology.

• No major change are expected in the system in the near future

06/06/11 Giacomo Govi

CERN Datenbank Schnittstellen

• CERN IT + ATLAS, CMS, LHCb Software Entwicklungsprojekte:• COOL:

– LCG Conditions Database Project

– provides specific software components and tools for the handling of the time variation and versioning of the experiment conditions data.

• POOL:– Pool Of persistent Objects for LHC

– hybrid technology store for C++ objects, using a mixture of streaming and relational technologies to implement both object persistency and object metadata catalogs and collections. It provides generic components that can be used by the experiments to store both their event data and their conditions data.

CERN Datenbank Schnittstellen

• CORAL: – COmmon Relational Abstraction Layer– is an abstraction layer with an SQL-free API to access data

stored using relational database technologies. It is used directly by experiment-specific applications and internally by both COOL and POOL.

• FRONTIER:– distributes data from central databases that are read by many

client systems around the world. The name comes from "N Tier" where N is any number and tiers are layers of locations of distribution. Based on HTTP technology.

– Limitations: Public Data only (no authorization), Subset of SQL (SELECT only)

NoSQL Datenbanken

• Interesse von CMS, ATLAS, PANDA (Job System)

• PANDA: Cassandra NoSQL DB

• ATLAS Distributed DataManagement System DQ2: MongoDB, Cassandra

• CMS: Hadoop, CouchDB,..

• IT Monitoring: Cassandra

Eigenschaften von NoSQL

• Bewegung, eine neue Art von Datenbanken voranzutreiben

• Keine Relationen zwischen Tabellen

• Clusterfähig (horizontal Skalierbar), hoher Durchsatz

• Keine Konsistenz, keine Transaktionen. Anwendung muss Konsitenz sichern.

• Schemalos, flexibel

• Effizient für genau definierte Abfragen, weniger für ad-hoc Queries

• Eher ein „verteilter strukturierter Speicher“

NoSQL database cartooon