GOCDB evolution plans GAG, 22/09/2008 Gilles Mathieu

Outline Current situation and context Data access standardization Architecture evolution Provisional plan

Current situation and context Standard development work –Dev and maintenance are “on tracks” –Good progress on failover Evolution requirements –Standardization –Convergence –Distribution

Data access standardization All tier tools use direct DB connection –Need to maintain accounts and passwords –Not really failover-compliant –No transparent change in the DB schema We need standard access through services and/or APIs… –…and this is not a scoop, really

Data access standardization Objective in 1 month –Study possibilities –provide a suitable implementation plan Objective in 2 months –Implement/prototype chosen solution –In parallel, provide sustainable set of PL/SQL functions Objective in 6 to 8 months –Progressively replace external use of PL/SQL functions –Get rid of all direct DB connection

E.g. get downtimes per region Now SELECT DOWNTIMES.DOWNTIME_ID, DOWNTIMES.CLASSIFICATION, DOWNTIMES.SEVERITY, DOWNTIMES.DESCRIPTION, CONCAT (FORENAME, CONCAT ('' '', SURNAME)) AS CREATOR_NAME, UNIX_TIMESTAMP(DOWNTIMES.ACTUALSTARTDATE) AS STARTDATE, UNIX_TIMESTAMP (DOWNTIMES.ACTUALENDDATE) AS ENDDATE, CONCAT(DOWNTIME_PATHS.PATH,''.'') AS TARGET_PATH, SITES_VIEW.SITENAME, NODES_VIEW.HOSTNAME FROM DOWNTIMES LEFT JOIN DOWNTIME_PATHS ON (DOWNTIME_PATHS.DOWNTIME_ID = DOWNTIMES.DOWNTIME_ID) LEFT JOIN USERS ON (DOWNTIMES.USER_ID = USERS.USER_ID) LEFT JOIN SITES_VIEW ON (DOWNTIME_PATHS.PATH = SITES_VIEW.PATH) LEFT JOIN NODES_VIEW ON (NODES_VIEW.PATH = DOWNTIME_PATHS.PATH) WHERE (DOWNTIME_PATHS.PATH = :path) OR (DOWNTIME_PATHS.PATH LIKE CONCAT(CONCAT(:path, ''.''),''%'')) ORDER BY DOWNTIME_PATHS.PATH In December 2008 –select * from table(list_downtimes_per_entity('Italy')); In April 2009 –$mygocdb->getDowntimesPerEntity(‘Italy”); In January 2012 –Could you please give me all downtimes for Italy? –Of course, here you are. –Thanks.

Architecture evolution The distribution issue, or how to ensure: –Easy deployment and maintenance –Communication between instances –Data synchronization and cross-querying –General coherence in case of problem A possible solution –Object-oriented DB design –Use of standard DB technologies

Architecture evolution Main idea –Move the physical aspects of the DB into ‘meta-data’ –Maintain links and table info outside of the actual data tables –Data can be: Accessed in a uniform way changed with minimal, or no, changes to the actual design Benefits –Faster deployment –Standard data access routines –Ability to grow the system without the need to redesign or re- implement the actual database.

Architecture evolution Objective in 1 month –Produce a detailed design study Objective in 4 to 6 months –Prototype the solution in test/dev –Work on a distribution use case (NGS) Objective in 8 months –Have at least a fully working regional instance in parallel with central DB

Summary: provisional plan now Oct.08 Dec.08 Apr.09 Oct.09 Apr.10 Plans for web services, APIs and general architecture - Distribution use case study - First service implementation - On going work on DB prototype - Distribution use case study - First service implementation - On going work on DB prototype - Large scale tests on DB prototype - Working regional instance for NGS - No more external direct DB access - Large scale tests on DB prototype - Working regional instance for NGS - No more external direct DB access - New model in production - More distributed instances working - New model in production - More distributed instances working Go to bed