1. Evolution of the Configuration Database Design Andrei Salnikov, SLAC For BaBar Computing Group ACAT05 – DESY, Zeuthen

2. May 23, 2005ACAT 20052 Talk overview BaBar configuration database BaBar configuration database Migration of BaBar databases Migration of BaBar databases New configuration database API New configuration database API Choice of technologies Choice of technologies Implementation dynamic loading Implementation dynamic loading Lessons learned from migration Lessons learned from migration

3. May 23, 2005ACAT 20053 BaBar on-line databases Conditions database Conditions database Calibrations, geometry, alignment, etc. Calibrations, geometry, alignment, etc. Data accessed with the event time Data accessed with the event time Ambient database (simplified conditions) Ambient database (simplified conditions) Time history of the data-taking conditions (voltages, currents, temperatures, etc.) Time history of the data-taking conditions (voltages, currents, temperatures, etc.) Part of the on-line detector control Part of the on-line detector control Configuration database Configuration database Details follow Details follow Prompt Reconstruction databases Prompt Reconstruction databases Support for multi-node calibrations Support for multi-node calibrations Electronic Logbook Electronic Logbook Etc. Etc.

4. May 23, 2005ACAT 20054 Configuration database Important part of the on-line system Important part of the on-line system Configuration database keeps configuration data - detector and software settings for data taking Configuration database keeps configuration data - detector and software settings for data taking Support configuration of the on-line hardware and software in preparation for data taking Support configuration of the on-line hardware and software in preparation for data taking For more details see CHEP03 talk For more details see CHEP03 talk Worked reasonably well since the beginning of Run 1 in 1999 Worked reasonably well since the beginning of Run 1 in 1999

5. May 23, 2005ACAT 20055 BaBar database migration BaBar was using Objectivity/DB ODBMS for many of its databases BaBar was using Objectivity/DB ODBMS for many of its databases About two years ago started migration from Objectivity to ROOT for event store, which was a success and improvement About two years ago started migration from Objectivity to ROOT for event store, which was a success and improvement No reason to keep pricey Objectivity only because of secondary databases No reason to keep pricey Objectivity only because of secondary databases Migration effort started in 2004 for conditions, configuration, prompt reconstruction, and ambient databases Migration effort started in 2004 for conditions, configuration, prompt reconstruction, and ambient databases

6. May 23, 2005ACAT 20056 Scope of the migration Configuration database currently holds about 60MB (uncompressed) of configuration data Configuration database currently holds about 60MB (uncompressed) of configuration data About 30 persistent classes for representation of the configuration data About 30 persistent classes for representation of the configuration data Rather compact and simple compared to other BaBar databases (e.g. conditions database is 40GB and 400 classes) Rather compact and simple compared to other BaBar databases (e.g. conditions database is 40GB and 400 classes) Due to its size and simplicity configuration database is a perfect candidate for a pilot project within migration effort Due to its size and simplicity configuration database is a perfect candidate for a pilot project within migration effort

7. May 23, 2005ACAT 20057 Configuration database API Main problem of the old database – API exposed too much of the implementation technology: Main problem of the old database – API exposed too much of the implementation technology: Persistent object, handles, class names, etc. Persistent object, handles, class names, etc. API has to change but we dont want to make the same mistakes again (new mistakes are more interesting) API has to change but we dont want to make the same mistakes again (new mistakes are more interesting) Pure transient-level abstract API independent on any specific implementation technology Pure transient-level abstract API independent on any specific implementation technology Much easier to re-implement in different technology if we dont like one particular technology Much easier to re-implement in different technology if we dont like one particular technology Can support more than one technology if needed [vital] Can support more than one technology if needed [vital] Client code independent of any persistency technology Client code independent of any persistency technology

8. May 23, 2005ACAT 20058 Prototyping New API To test the details of new API and one specific implementation, a prototype implementation was built To test the details of new API and one specific implementation, a prototype implementation was built Great prototyping language used – Python Great prototyping language used – Python MySQL used for data storage MySQL used for data storage Prototype is not exact because languages are very different: Python – dynamic, C++ – static Prototype is not exact because languages are very different: Python – dynamic, C++ – static But helped a lot with quick testing of different ideas and optimizing SQL tables But helped a lot with quick testing of different ideas and optimizing SQL tables

9. May 23, 2005ACAT 20059 New Database API Defining new API is easy – after five years of experience it cant be done wrong Defining new API is easy – after five years of experience it cant be done wrong Expressing this API in C++ is not so easy Expressing this API in C++ is not so easy one particular problem – how to pass non- polymorphic types through abstract interface one particular problem – how to pass non- polymorphic types through abstract interface in C++ interfaces and templates do not mix in C++ interfaces and templates do not mix solution is to use RTTI at transient level solution is to use RTTI at transient level smart AnyPtr (void* with enough RTTI) smart AnyPtr (void* with enough RTTI) mechanism is hidden from client code, clients only see type-safe methods mechanism is hidden from client code, clients only see type-safe methods

10. May 23, 2005ACAT 200510 API migration – clients All clients should be changed to use new API All clients should be changed to use new API All client code should be made free of the old implementation details All client code should be made free of the old implementation details Most time-consuming task in the whole migration Most time-consuming task in the whole migration Re-examining dependencies, re-packaging code, re-thinking design at global level Re-examining dependencies, re-packaging code, re-thinking design at global level Process is hard, sometimes conflicting with other development, but the result is beneficial for everybody – cleaner code and fewer dependencies Process is hard, sometimes conflicting with other development, but the result is beneficial for everybody – cleaner code and fewer dependencies

11. May 23, 2005ACAT 200511 Bridge Implementation Having an abstract API we need to build specific implementation(s) Having an abstract API we need to build specific implementation(s) Start with obvious – we still have data in Objectivity. Build bridge implementation on top of old database Start with obvious – we still have data in Objectivity. Build bridge implementation on top of old database proof of a working API proof of a working API being used until migration is complete being used until migration is complete but the goal is to have different technology(-ies) but the goal is to have different technology(-ies)

12. May 23, 2005ACAT 200512 Choosing Technology Time to choose implementation technologies, real alternatives to Objectivity Time to choose implementation technologies, real alternatives to Objectivity Many considerations – data access and distribution, reliability, data modeling capabilities, etc. Many considerations – data access and distribution, reliability, data modeling capabilities, etc.

13. May 23, 2005ACAT 200513 Choosing technology Two classes of clients with different requirements: Two classes of clients with different requirements: production site needs reliable, fault-tolerant, concurrent read-write access to the data production site needs reliable, fault-tolerant, concurrent read-write access to the data remote sites need zero-management, easy-to- use, fast, scalable read-only access to the data remote sites need zero-management, easy-to- use, fast, scalable read-only access to the data It should be possible to use different implementation technologies at production and remote sites It should be possible to use different implementation technologies at production and remote sites

14. May 23, 2005ACAT 200514 Read-only implementation ROOT is an obvious decision for storing read-only data: ROOT is an obvious decision for storing read-only data: Data definition using C++ constructs allows easy migration of Objectivity schema Data definition using C++ constructs allows easy migration of Objectivity schema No servers and no management needed for small installations No servers and no management needed for small installations For large installations xrootd server could be used for load-balancing For large installations xrootd server could be used for load-balancing BaBar data distribution knows already about ROOT BaBar data distribution knows already about ROOT

15. May 23, 2005ACAT 200515 Read-only implementation Migration was straightforward Migration was straightforward ROOT-persistent classes are (almost) exact copy of Objectivity DDLs ROOT-persistent classes are (almost) exact copy of Objectivity DDLs Data size is small, everything fits in one file Data size is small, everything fits in one file Metadata and data objects are stored in TTrees, à la relational tables in SQL database Metadata and data objects are stored in TTrees, à la relational tables in SQL database Some complications due to lack of proper indexing support in ROOT TTrees, needed some additional structures Some complications due to lack of proper indexing support in ROOT TTrees, needed some additional structures

16. May 23, 2005ACAT 200516 Read-write implementation Need something more robust for this – real database Need something more robust for this – real database Practically only option is relational database – either commercial like Oracle, or free as MySQL Practically only option is relational database – either commercial like Oracle, or free as MySQL Need to augment it with the object-relational mapping, not quite trivial despite many databases call themselves object-relational Need to augment it with the object-relational mapping, not quite trivial despite many databases call themselves object-relational But we could reuse data definitions from ROOT read-only implementation But we could reuse data definitions from ROOT read-only implementation Not so critical for configuration database, but will be essential for conditions Not so critical for configuration database, but will be essential for conditions

17. May 23, 2005ACAT 200517 MySQL implementation Initial implementation in MySQL, but can switch to Oracle later if MySQL fails Initial implementation in MySQL, but can switch to Oracle later if MySQL fails Configuration objects are self-contained, store them as BLOBs in the relational tables Configuration objects are self-contained, store them as BLOBs in the relational tables Need to serialize object data for storage Need to serialize object data for storage convert to ROOT object convert to ROOT object call Streamer() to stream data into buffer call Streamer() to stream data into buffer compress buffer, store as BLOB compress buffer, store as BLOB De-serialization works in opposite direction De-serialization works in opposite direction Reuse of the persistent classes from ROOT read- only implementation! Reuse of the persistent classes from ROOT read- only implementation!

18. May 23, 2005ACAT 200518 Building applications Now we have three implementations: Bridge (temporary), ROOT, and MySQL Now we have three implementations: Bridge (temporary), ROOT, and MySQL Decision on which one to use should be delayed until run time, so that the same application could run everywhere Decision on which one to use should be delayed until run time, so that the same application could run everywhere Should link all implementations into all applications? Should link all implementations into all applications? Not good, dont want to install MySQL if need only ROOT read-only Not good, dont want to install MySQL if need only ROOT read-only Load implementations dynamically at run time Load implementations dynamically at run time

19. May 23, 2005ACAT 200519 Dynamic loading In principle it should be possible to split things into static/dynamic In principle it should be possible to split things into static/dynamic In practice it is very complex and needs extreme care In practice it is very complex and needs extreme care In BaBar we ended up with the dynamic loading of libmysqlclient.so only In BaBar we ended up with the dynamic loading of libmysqlclient.so only ROOT implementation is linked into application ROOT implementation is linked into application part of MySQL implementation too part of MySQL implementation too but no link dependency on MySQL but no link dependency on MySQL

20. May 23, 2005ACAT 200520 Current Status New API and all three implementations are now in production New API and all three implementations are now in production Bridge implementation is what we are currently using in production Bridge implementation is what we are currently using in production Data in two other implementations are constantly updated from production data Data in two other implementations are constantly updated from production data Preparing data distribution for ROOT configuration data Preparing data distribution for ROOT configuration data Planning to switch production to use MySQL implementation Planning to switch production to use MySQL implementation

21. May 23, 2005ACAT 200521 Lessons learned Always make abstract APIs to avoid problems in the future (this may be hard and need few iterations) Always make abstract APIs to avoid problems in the future (this may be hard and need few iterations) Client code should be free from any specific database implementation details Client code should be free from any specific database implementation details Early prototyping could answer a lot of questions, but five years of experience count too Early prototyping could answer a lot of questions, but five years of experience count too Use different implementations for clients with different requirements Use different implementations for clients with different requirements Implementation would benefit from features currently missing in C++: reflection, introspection (or from completely new language) Implementation would benefit from features currently missing in C++: reflection, introspection (or from completely new language)

22. May 23, 2005ACAT 200522 Conclusions We have redesigned and reimplemented BaBar configuration database We have redesigned and reimplemented BaBar configuration database Different alternative implementations exist for clients with different requirements Different alternative implementations exist for clients with different requirements No specific performance figures, but it should be better than original Objectivity performance No specific performance figures, but it should be better than original Objectivity performance Good experience which will be used in migration of other BaBar databases Good experience which will be used in migration of other BaBar databases