1 / 8

Migrating CRISTAL from Objectivity to RDBMS

This presentation highlights the migration journey of the CRISTAL production tracking system for the CMS project, initiated in 1996. Originally based on Objectivity, the system faced multiple design challenges and waning support, prompting a complete redesign in CRISTAL 2, deployed in August 2003. The new system employed a more abstract architecture with plugin capabilities for various databases. This session discusses technology dependencies, the importance of abstraction, and strategies for safeguarding data to enable future-proofing and adaptability in database systems.

henry
Download Presentation

Migrating CRISTAL from Objectivity to RDBMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Migrating CRISTAL from Objectivity to RDBMS Andrew Branson University of the West of England CERN, 13/01/2014

  2. CRISTAL • Production tracking system for CMS • Project started 1996 • Tracked construction of CMS ECAL Barrel, Endcap, ECAL Electronics, Preshower. • Ran at CERN and other sites, or imported data from other remote construction software • Extremely object-oriented concept. • Objectivity was an obvious choice.

  3. CRISTAL 1 • Objectivity-based prototype (CRISTAL 1) completed 2000 • Collected prototype data: • Crystals and test ECAL modules at CERN and INFN, Rome • APD capsules at IN2P3, Lyon. • C++ backend, Java UIs. • Heavily integrated with OO DB, required extensive re-engineering to migrate to alternative database.

  4. Redesign • Prototype had design problems. • Object DBs had failed to catch on, support waning at CERN. • Large amount of work to remove Objectivity. • Small amount of production data to migrate. • Decision made to redesign and redevelop from scratch

  5. CRISTAL 2 • Production system deployed August 2003 • Storage still object based, but with abstraction layer. • Plugins for Oracle, MySQL, SQLite. • Fall-back XML file serialization.

  6. CRISTAL 2 • Application design implemented using descriptions - metamodels. • XML (text) based. Portable, human readable. • Self-documenting, web standards (XSD) • Some preservation against technology obsolescence • Investigating migrating to XMLDB for enhanced query capability.

  7. Conclusion Technology dependency comes in two flavours: • Dependency on Implementation • Prevent redesign through abstraction. • Small, self-contained redevelopment when obsolete. • Dependency on Philosophy • Could require large re-engineering. • Only protection is to safeguard data, schema and logic in a documented form that could be reinterpreted in the future.

  8. End

More Related